-finline is not a explicit option, search word "-finline" in page
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
will miss the explicit option "-fno-inline".
gcc/ChangeLog:
2019-11-01 Xiong Hu Luo
doc/invoke.texi (inline): Add description for -finlin
Hi Segher,
on 2019/11/1 上午2:49, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 31, 2019 at 05:35:22PM +0800, Kewen.Lin wrote:
+/* Half VMX/VSX vector (for select) */
+VECTOR_MODE (FLOAT, SF, 2); /* V2SF */
+VECTOR_MODE (INT, SI, 2); /* V2SI
On Wed, 30 Oct 2019 at 03:11, H.J. Lu wrote:
>
> On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanandarajah
> wrote:
> >
> > Hi Richard,
> >
> > Thanks for the review.
> >
> > On Wed, 23 Oct 2019 at 23:07, Richard Biener
> > wrote:
> > >
> > > On Mon, Oct 21, 2019 at 10:04 AM Kugan Vivekanandarajah
Hi uros:
This patch is about to fix inefficient vector constructor.
Currently in ix86_expand_vector_init_concat, vector are initialized
per 2 elements which can miss some optimization opportunity like
pr92295.
Bootstrap and i386 regression test is ok.
Ok for trunk?
Changelog
gcc/
On Thu, Oct 31, 2019 at 4:41 PM Jim Wilson wrote:
> gcc/
> PR middle-end/92263
> * expr.c (emit_move_complex): Only use BLOCK_OP_NO_LIBCALL when
> optimize_insn_for_speed_p is true.
>
> gcc/testsuite/
> PR middle-end/92263
> * gcc.dg/pr92263.
The RISC-V backend wants to use a libcall when optimizing for size if
more than 6 instructions are needed. Emit_move_complex asks for no
libcalls. This case requires 8 insns for rv64 and 16 insns for rv32,
so we get fallback code that emits a loop. Commit_one_edge_insertion
doesn't allow code in
On 25/10/19 00:22 +0100, Jonathan Wakely wrote:
On 23/10/19 20:28 +0100, Jonathan Wakely wrote:
* include/std/functional (invoke): Add constexpr for C++20.
* include/std/version (__cpp_lib_constexpr_invoke): Define.
* testsuite/20_util/function_objects/invoke/constexpr.cc
On Wed, Oct 23, 2019 at 04:42:19PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 23, 2019 at 05:00:58PM -0400, Michael Meissner wrote:
> > On Tue, Oct 22, 2019 at 05:27:19PM -0500, Segher Boessenkool wrote:
> > > On Wed, Oct 16, 2019 at 09:35:33AM -0400, Michael Meissner wrote:
> > > > - int n =
Jeff Law sent me an email that showed my patch for
PR fortran/90988 caused a regression for fixed-form
source code. The attached patch address that regression.
Briefly, the original patch fixed free-form souce code
parsing for 'PUBLICX' where the required whitespace was
missing (i.e., 'PUBLIC X')
Hi!
On Tue, Oct 29, 2019 at 01:34:15PM -0600, Jeff Law wrote:
> That needs to turn into a define_insn_and_split. The idea is the form
> above is what's seen prior to register allocation and reloading. After
> reloading we turn it into a form with an attached clobber. We achieve
> this by rewrit
Hi, this adds the possibility to enable IEEE compatible double
and long double support in avr-gcc.
It supports 2 configure options
--with-double={32|64|32,64|64,32}
--with-long-double={32|64|32,64|64,32|double}
which select the default layout of these types and also chose
which mutlilib variant
* doc/doxygen/user.cfg.in: Add new header.
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/precompiled/stdc++.h: Include new header.
* include/std/ranges: New header.
(ranges::sentinel_t, ranges::range_value_t, ran
On Thu, 31 Oct 2019, Jakub Jelinek wrote:
> Hi!
>
> Seems libcpp has been ICEing on push_macro of a builtin macro since 2010,
In fact, we have both bug 69665 and bug 87181 for that.
--
Joseph S. Myers
jos...@codesourcery.com
On 10/30/19 9:07 AM, Mihailo Stojanović wrote:
> Hello Jeff,
>
> I already have write access on this e-mail address (but not on
> the @wavecomp.com address, which you have been putting
> into ChangeLogs), so I guess I could commit any further patches
> that get approved.
OK. I'll let you commit t
Iain Sandoe wrote:
> Iain Sandoe wrote:
>
>> Iain Sandoe wrote:
>>
>>> Martin Sebor wrote:
>>>
On 10/20/2019 07:27 AM, Iain Sandoe wrote:
> Martin Sebor wrote:
>> On 10/19/19 2:56 AM, Iain Sandoe wrote:
>>> Andreas Schwab wrote:
On Okt 19 2019, Iain Sandoe wrote
On Thu, Oct 31, 2019 at 09:30:26PM +0200, Janne Blomqvist wrote:
>
> I'd personally prefer the current behavior. I.e. just let the
> underlying OS/libc handle it as it sees fit. No need to invent our own
> semantics here. Tobias quoted the relevant part of the standard, which
> the current impleme
On Thu, Oct 31, 2019 at 7:03 PM Steve Kargl
wrote:
>
> On Thu, Oct 31, 2019 at 05:51:38PM +0100, Tobias Burnus wrote:
> > On 10/31/19 5:42 PM, Steve Kargl wrote:
> > > I suspect the other BSDs also follow posix. I wonder if gfortran
> > > should either apply a mask to the stop code or simply map n
On 10/11/19 10:34 AM, Martin Sebor wrote:
> I've fixed the bug in the attached patch. The rest can be suppressed
> by replacing the zero-length arrays with flexible array members but
> that's just trading one misuse for another. If the code can't be
> changed to avoid this (likely not an option s
Hi!
On Thu, Oct 31, 2019 at 05:35:22PM +0800, Kewen.Lin wrote:
> >> +/* Half VMX/VSX vector (for select) */
> >> +VECTOR_MODE (FLOAT, SF, 2); /* V2SF */
> >> +VECTOR_MODE (INT, SI, 2); /* V2SI */
> >
> > Or "for internal use", in general. What happens if
In preparation for an upcoming patch, I've moved devices-main.c from
gcc.target/msp430/devices-main.c to gcc.target/msp430/devices/devices-main.c
and updated references to it in the test source files.
Committed as obvious.
>From c2c40bdeb6d8212bfe6435154e1f31882ce36478 Mon Sep 17 00:00:00 2001
Fro
Hi Julian!
On 2019-10-29T12:15:01+, Julian Brown wrote:
> This is a new version of the patch which hopefully addresses all review
> comments. Further commentary below.
Thanks, great, looking into that one -- I see you're removing more and
more special-case, strange code, replacing it with ge
On Thu, Oct 31, 2019 at 06:02:02PM +, Andre Vieira (lists) wrote:
> When I debug the vect_analyze_loop calls loop->simdlen is 0 everywhere, with
> or without epilogue vectorization turned on. However, I also noticed that
> excluding -fopenmp and -fopenmp-simd will yield the generation of vmova
Jason,
Can you please review this,
let me know how can we handle -fabi-version?
On Wed, Oct 23, 2019 at 7:55 AM Kamlesh Kumar wrote:
>
> ---
> gcc/cp/mangle.c| 3 ++-
> gcc/testsuite/g++.dg/cpp0x/nullptr27.C | 2 +-
> gcc/testsuite/g++.dg/cpp0x/pr91979.C | 15
Hi,
After my patch I believe the only way orig_loop_vinfo is not null when
calling vect_analyze_loop is when it is called for an epilogue and in
that case we no longer use that variable, since
LOOP_VINFO_ORIG_LOOP_INFO is already set for the epilogue's
loop_vec_info. This patch removes that
On 31/10/2019 14:04, Jakub Jelinek wrote:
On Thu, Oct 31, 2019 at 01:55:26PM +, Andre Vieira (lists) wrote:
I used to have this testcase in my patch when testing but forgot to include
it in the patch I sent upstream. This testcase checks that a vmovaps isn't
generated when vectorizing the l
On Thu, Oct 31, 2019 at 06:09:28PM +0100, Tobias Burnus wrote:
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -71,6 +71,33 @@ gfc_omp_is_optional_argument (const_tree decl)
> && GFC_DECL_OPTIONAL_ARGUMENT (decl));
> }
>
> +
> +/* Returns tree with NULL if it i
On 10/31/19 1:17 PM, Jakub Jelinek wrote:
Hi!
Seems libcpp has been ICEing on push_macro of a builtin macro since 2010,
but it became more urgent with Martin's __has_builtin builtin macro
addition, because the mingw headers already do use
#pragma push_macro("__has_builtin")
#ifndef __has_builtin
This had been failing since a mass renaming. Noticed it a few times
before but somehow never got around to fixing it.
Tested on aarch64-linux-gnu and applied as r277683.
Richard
2019-10-31 Richard Sandiford
gcc/testsuite/
* g++.target/aarch64/sve/vcond_1_run.C: Update test name.
I
vcond_4.c combined too much stuff into one test, so that when we needed
to add XFAILs for one set of routines, we lost testing of others that
used the same instructions. This patch splits it into four:
vcond_4.c:
The main test for selects between a vector and a scalar, with all
elements havin
This patch splits gcc.target/aarch64/sve/reduc_strict_3.c into one
test per function, so that it's easier to see what each scan is
matching and also so that we no longer rely on the number of times
that each dump message is printed.
The patch also generalises the tests to work with scalable vector
On Wed, Oct 30, 2019 at 05:06:00PM -0400, Jason Merrill wrote:
> build_cplus_new does the magic of replacing a dummy argument, e.g.
>
> > if (obj_arg && is_dummy_object (obj_arg))
> > {
> > call = build_cplus_new (DECL_CONTEXT (fndecl), call,
> > complain);
> >
Hi!
On Thu, Oct 31, 2019 at 10:19:49AM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Wed, Oct 30, 2019 at 11:34:42AM +0800, Jiufu Guo wrote:
> >> In this patch, loop unroll adjust hook is introduced for powerpc. In this
> >> hook,
> >> we can do target related hueristic adjustment.
Hi!
Seems libcpp has been ICEing on push_macro of a builtin macro since 2010,
but it became more urgent with Martin's __has_builtin builtin macro
addition, because the mingw headers already do use
#pragma push_macro("__has_builtin")
#ifndef __has_builtin
#define __has_builtin(x) 0
#endif
...
#prag
Andreas Schwab writes:
> This breaks boostrap.
>
> /opt/gcc/gcc-20191030/Build/./prev-gcc/xgcc
> -B/opt/gcc/gcc-20191030/Build/./prev-gcc/ -B/usr/aarch64-suse-linux/bin/
> -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
> /usr/aarch64-suse-linux/include -isystem /usr/aarc
On Wed, Oct 30, 2019 at 11:05:29PM +0100, Jakub Jelinek wrote:
> > Looks like there used to be a TREE_CALLS_NEW flag in TREE_LANG_FLAG_1, but
> > that flag is now free for CALL_EXPR.
>
> I'll try a CALL_EXPR flag first.
TREE_LANG_FLAG_1 is also STMT_IS_FULL_EXPR_P, and while it is mostly guarded
Thanks for the review and the suggestions! – The new patch is now much
nicer!
Changes: The hook now optionally returns a TREE_TYPE – which doesn't
generate a new tree.
Hence, the extra item in the ctx is gone and is uses – as suggested
&DECL_NAME.
Bootstrapped and regtested* on x86_64-gnu-li
On Thu, Oct 31, 2019 at 05:51:38PM +0100, Tobias Burnus wrote:
> On 10/31/19 5:42 PM, Steve Kargl wrote:
> > I suspect the other BSDs also follow posix. I wonder if gfortran
> > should either apply a mask to the stop code or simply map nonzero
> > values to one of EXIT_FAILURE, SIGQUIT, or SIGABR
On Wed, Oct 30, 2019 at 06:16:43PM +, Andre Vieira (lists) wrote:
> 2019-10-30 Andre Vieira
>
> * params.def (PARAM_VECT_EPILOGUES_NOMASK): Enable by default.
This broke quite a few tests in libgomp, and as they are execution failures,
just trying to work around it in the test is n
On Thu, Oct 31, 2019 at 05:46:38PM +0100, Jakub Jelinek wrote:
> On Thu, Oct 31, 2019 at 09:42:07AM -0700, Steve Kargl wrote:
> > On Thu, Oct 31, 2019 at 05:12:39PM +0100, Tobias Burnus wrote:
> > > At some point, 'call abort()' was changed to 'stop'; this works fine as
> > > long as exit status i
On 10/31/19 5:42 PM, Steve Kargl wrote:
I suspect the other BSDs also follow posix. I wonder if gfortran
should either apply a mask to the stop code or simply map nonzero
values to one of EXIT_FAILURE, SIGQUIT, or SIGABRT. Perhaps,
- exit (code);
+ exit (EXIT_FAILURE);
Or "exit (code > 25
On Thu, Oct 31, 2019 at 09:42:07AM -0700, Steve Kargl wrote:
> On Thu, Oct 31, 2019 at 05:12:39PM +0100, Tobias Burnus wrote:
> > At some point, 'call abort()' was changed to 'stop'; this works fine as
> > long as exit status is != 0. At least on my Linux system, this works
> > until 255. (Which
On 10/30/19 3:58 AM, Claudiu Zissulescu wrote:
> Hi Jeff,
>
>> So I'm going to have to trust you on this one. It looks like you did
>> more than just reorder the alternatives. For example, the constraints
>> for operand0 look significantly different to me. THey're slightly
>> different for oper
On Thu, Oct 31, 2019 at 05:12:39PM +0100, Tobias Burnus wrote:
> At some point, 'call abort()' was changed to 'stop'; this works fine as
> long as exit status is != 0. At least on my Linux system, this works
> until 255. (Which matches POSIX, which requires 8 bits.) For "stop 256",
> I get an ex
On Thu, Oct 31, 2019 at 12:29:05AM +0100, Tobias Burnus wrote:
> gcc/testsuite/
> PR fortran/92284.
Note, no . at the end
> * gfortran.dg/bind-c-intent-out.f90: Update expected dump;
> extend comment.
> * gfortran.dg/bind_c_array_params_3.f90: New.
> * gfortran
On 10/8/19 5:51 PM, Martin Sebor wrote:
> Attached is a resubmission of the -Wrestrict implementation for
> the sprintf family of functions. The original patch was posted
> in 2017 but never approved. This revision makes only a few minor
> changes to the original code, mostly necessitated by reba
At some point, 'call abort()' was changed to 'stop'; this works fine as
long as exit status is != 0. At least on my Linux system, this works
until 255. (Which matches POSIX, which requires 8 bits.) For "stop 256",
I get an exit status == 0.
I am not sure whether other systems break earlier, bu
Thumb2 code now uses the Arm implementation of legitimize_address. That
code has a case to handle addresses that are absolute CONST_INT values,
which is a common use case in deeply embedded targets (eg: void *p =
(void*)0x12345678). Since thumb has very limited negative offsets from
a constan
On ARM, the SBC instruction is defined as
Ra - Rb - ~C
where C is the carry flag. But -Rb = ~Rb + 1, so this is equivalent to
Ra + ~Rb + 1 - ~C
which then simplifies to
Ra + ~Rb + C
which is essentially an add-with-carry with one operand inverted. We
can define RTL patterns to match
Hi.
operand_equal_p can properly handle situation where we have a CONSTRUCTOR
where indices are NULL:
if (!operand_equal_p (c0->value, c1->value, flags)
/* In GIMPLE the indexes can be either NULL or matching i.
Double check this so we won't ge
Hi.
This is one another dead code removal.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch.
Thanks,
Martin
gcc/ChangeLog:
2019-10-31 Martin Liska
* ipa-icf-gimple.c (func_checker::compare_tree_ssa_label): Remove.
* ipa-i
The test case present a real embedded case, yes it is not functional
benchmark, it is a test case, but on our days, most of the MCU's for IoT
devices acts as controllers and less as computing/algorithm units. This
days, functional algorithms are done on HW and managed by SW with
snippet as the
Hi,
yesterday I noticed that we want to forward the location parameter of
cp_build_binary_op to composite_pointer_type and then
composite_pointer_error. Note, for the time being at least, this is
always for CPO_COMPARISON, the other two composite_pointer_operation
cases aren't involved - and
Hi, Richard
This is a new patch to support more generalized semi-invariant condition,
which uses
control dependence analysis.
Thanks,
Feng
From: Feng Xue OS
Sent: Friday, October 25, 2019 11:43 AM
To: Richard Biener
Cc: Michael Matz; Philipp Tomsich;
This patch seems to break
libgomp.fortran/examples-4/simd-3.f90
at run time as the calculated value is way off: "diff = sum - sum_ref"
is -12576 while abs(diff) < 1e-16 is the check.
It works with -O0 or without -mavx; (Hence, -Os or -O1 + -mavx cause the
fail.)
Please have a look.
Tobias
The type trait depends on is_void so the tests should check those cases.
* testsuite/20_util/add_pointer/value.cc: Check void types.
Tested x86_64-linux, committed to trunk.
commit 5b35f49aeb052513b4580ed4d9ea0ef3118a200d
Author: Jonathan Wakely
Date: Thu Oct 31 14:05:47 2019 +
On Thu, Oct 31, 2019 at 01:55:26PM +, Andre Vieira (lists) wrote:
> I used to have this testcase in my patch when testing but forgot to include
> it in the patch I sent upstream. This testcase checks that a vmovaps isn't
> generated when vectorizing the loop. When I turn epilogue vectorizatio
Hi,
I used to have this testcase in my patch when testing but forgot to
include it in the patch I sent upstream. This testcase checks that a
vmovaps isn't generated when vectorizing the loop. When I turn epilogue
vectorization it seems to come back.
@Jakub: This test has -fopenmp but I deb
With the compiler bug fixed we can simplify the __sizable concept to use
a return-type-requirement again. I also realised it was redundantly
re-checking a subset of the sized_sentinel_for requirements.
The compiler fix also revealed bugs in two tests which started to fail
and are fixed by this pa
On 10/31/19 2:16 PM, Martin Liška wrote:
> On 10/31/19 2:01 PM, Martin Liška wrote:
>> Hi.
>>
>> Based on the discussion with Honza and Richard I'm sending a proposal
>> for conversion of param machinery into the existing option machinery.
>> Our motivation for the change is to provide per function
This combines the overloads for arrays with the non-array overloads,
using if-constexpr to choose between the cases, and also enforces the
following:
- ADL should only be used for class types and enumeration types.
- ranges::begin should be ill-formed for rvalue arrays.
- ranges::end should be il
On 30/10/19 23:05 +0100, Jakub Jelinek wrote:
On Wed, Oct 30, 2019 at 04:26:17PM -0400, Jason Merrill wrote:
OK.
Thanks, committed.
> Now, for the accepts invalid issues.
> From what I understood, in constant evaluation
> ::operator new{,[]} or ::operator delete{,[]}
> can't be called from
On 10/31/19 2:01 PM, Martin Liška wrote:
> Hi.
>
> Based on the discussion with Honza and Richard I'm sending a proposal
> for conversion of param machinery into the existing option machinery.
> Our motivation for the change is to provide per function param values,
> similarly what 'Optimization'
Hi,
In my '[vect]Make vect-epilogues-nomask=1 default' patch, revision
r277659, I apparently put dg-additional-options before dg-options which
seems to be overwritten. This moves the additional options such that
they are used. Sorry if I caused any testism noise!
Committed in r277664 as obvi
On 31/10/2019 09:35, Jakub Jelinek wrote:
> On Thu, Oct 31, 2019 at 09:16:00AM +, Richard Sandiford wrote:
>>> Yes, it is indeed not clear, subject to ongoing discussions.
>>> My reading of the spec was that all the *-name-list are comma
>>> separated lists of identifiers, some others in the co
Nevertheless, as Jim observed, it's a great burden on the RISC-V
backend maintainers to support all these passes. Are you saying WD is
willing to put its money where its mouth is and will provide active
support for these passes?
On Thu, Oct 31, 2019 at 2:42 AM Nidal Faour wrote:
>
> A tests case
Installed as obvious. The previously linked report was sent out just
before the 9.2 releases but a few days after the release/report, a new
status report was sent (for 9.3).
Tobias
commit 067400fa54e757506312c9d74404d22048dc8812
Author: Tobias Burnus
Date: Thu Oct 31 10:49:02 2019 +0100
Hi Tobias,
OK for trunk and for 9-branch. As with the patch for PR92277, you will
have to get release manager approval for 9.2.
Thanks for working on this.
Cheers
Paul
On Wed, 30 Oct 2019 at 23:29, Tobias Burnus wrote:
>
> Playing with the PR92284 test case revealed two issues related to
> gf
Hi Tobias,
OK for trunk and for 9-branch. For the latter, you will have to get
release manager approval of course.
Thanks for picking up my doo-doos.
Cheers
Paul
On Wed, 30 Oct 2019 at 15:40, Tobias Burnus wrote:
>
> The attached test case (w/o optional and with "this") gave an ICE as
> "*thi
A tests case for this patch has been written and pushed to WD github repository
at the following link:
https://github.com/westerndigitalcorporation/riscv32-Code-density-test-bench/tree/master/common_load_store_base_address_offset
the test case itself has been written based on a real product scena
This precondition is the subject of a national body comment on the C++20
CD. This just adds a test to ensure we enforce the precondition.
Also move existing 24_iterator/range_access*.cc tests to a dedicated
directory for the [iterator.range] subclause.
* testsuite/24_iterators/range_acce
Hi Segher,
Thanks a lot for the comments.
on 2019/10/31 上午2:49, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Oct 23, 2019 at 05:42:45PM +0800, Kewen.Lin wrote:
>> Following the previous one 2/3, this patch is to update the
>> vector conversions between fixed point and floating point
>> with diffe
On Thu, Oct 31, 2019 at 09:16:00AM +, Richard Sandiford wrote:
> > Yes, it is indeed not clear, subject to ongoing discussions.
> > My reading of the spec was that all the *-name-list are comma
> > separated lists of identifiers, some others in the committee
> > want now (yesterday's discussion
Thanks for implementing this.
Jakub Jelinek writes:
> On Wed, Oct 30, 2019 at 02:12:30PM +, Szabolcs Nagy wrote:
>> On 29/10/2019 17:15, Jakub Jelinek wrote:
>> > +void f03 (void);
>> > +#pragma omp declare variant (f03) match
>> > (device={kind(any),arch(x86_64),isa(avx512f,avx512bw)})
>> >
On 10/30/19 11:23 PM, Jeff Law wrote:
> On 10/30/19 4:06 PM, Joseph Myers wrote:
>> On Wed, 30 Oct 2019, Joseph Myers wrote:
>>
>>> This appears to have broken the build for Arm.
>>
>> And probably bfin and c6x as well, based on grep, but my bot only covers
>> glibc targets so doesn't test those.
On October 31, 2019 8:26:47 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01645.html patch
>in the form it was committed as r263880 and later tweaks essentially
>replaced DECL_BUILT_IN with fndecl_built_in_p (or the further class
>and/or function cod
Hi!
The https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01645.html patch
in the form it was committed as r263880 and later tweaks essentially
replaced DECL_BUILT_IN with fndecl_built_in_p (or the further class
and/or function code checks with it), but most importantly while
it was perhaps intended e
76 matches
Mail list logo
