Hi,
This is a simple fix for PR94026.
With this fix, combine will try make an extraction if we are in a equality
comparison and this is an AND
with a constant which is power of two minus one. Shift here should be an
constant. For example, combine
will transform (compare (and (lshiftr
Done đ Thank you for your review,
Claudiu
From: Martin Sebor
Sent: Tuesday, March 3, 2020 6:47 PM
To: Claudiu Zissulescu ; gcc-patches@gcc.gnu.org
Cc: ger...@pfeifer.com ; l...@redhat.com ;
Francois Bedard ; Claudiu Zissulescu
; andrew.burg...@embecosm.com
Su
I will rework the patches preserving the option. Shall I add a deprecate
message as well?
//Claudiu
From: Jeff Law
Sent: Tuesday, March 3, 2020 7:00 PM
To: Richard Biener ; Claudiu Zissulescu
Cc: GCC Patches ; Francois Bedard
; Claudiu Zissulescu ; Andrew
Bur
On Tue, Mar 3, 2020 at 5:41 PM Egeyar Bagcioglu
wrote:
>
> This patch is for .GCC.command.line sections in LTO objects to be copied
> into the final objects as in the following example:
>
> [egeyar@localhost lto]$ gcc -flto -O3 demo.c -c -g --record-gcc-command-line
> [egeyar@localhost lto]$ gcc -
On Wed, Mar 4, 2020 at 9:52 AM Claudiu Zissulescu
wrote:
>
> I will rework the patches preserving the option. Shall I add a deprecate
> message as well?
There's no need for that I think.
Richard.
> //Claudiu
>
> From: Jeff Law
> Sent: Tuesday, March 3, 2020 7:
On 3/3/20 3:44 PM, Egeyar Bagcioglu wrote:
Hello,
Hi.
I would like to propose the second version of the patches which introduce a
compile option --record-gcc-command-line. When passed to gcc, it saves the
command line invoking gcc into the produced object file. The option makes it
trivial
Pointers eventually need intermediate conversions in code generation.
Allowing them is much easier than fending them off since niter
and scev expansion easily drag those in.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-02-03 Richard Biener
PR tree-optimiza
On Tue, 3 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following patch attempts to avoid dangerous overflows in the various
> push_partial_def HOST_WIDE_INT computations.
> This is achieved by performing the subtraction offset2i - offseti in
> the push_partial_def function and before doing that d
on 2020/3/4 ä¸ĺ3:24, binbin wrote:
> Hi
>
> On 2020/3/4 ä¸ĺ8:33, Segher Boessenkool wrote:
>> Hi!
>>
>> On Tue, Mar 03, 2020 at 10:13:56AM -0600, Bin Bin Lv wrote:
>>> Rewrite the declaration of toc_section from the source file rs6000.c to its
>>> header file for standardizing the code.
>>
>>> diff
> I'll have to look into this.. Any pointers? This assertion is not a language
> rule assertion.
Of course, neither of the 117 assertions in gcc-interface is, instead they are
assertions meant to prevent wrong-code generation from occuring.
> As you see, the assertion being modified already test
On March 3, 2020 9:13:01 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>In the following testcase we emit wrong debug info for the karg
>parameter in the DW_TAG_inlined_subroutine into main.
>The problem is that the karg PARM_DECL is DECL_BY_REFERENCE and thus
>in the IL has const K & type, but in the
Hi.
I've noticed during working on VEC_COND_EXPR, that code added in
r10-2910-g9151048d854e352a9b83b771c6711b8221c73f7e is not executed.
It's also seen on our LCOV instance:
https://users.suse.com/~mliska/lcov/gcc/optabs.c.gcov.html
line 5889.
It started with the revision where we changed defaul
On Wed, Mar 04, 2020 at 12:53:58PM +0100, Martin LiĹĄka wrote:
> Hi.
>
> I've noticed during working on VEC_COND_EXPR, that code added in
> r10-2910-g9151048d854e352a9b83b771c6711b8221c73f7e is not executed.
> It's also seen on our LCOV instance:
> https://users.suse.com/~mliska/lcov/gcc/optabs.c.g
Hi!
On Wed, Mar 04, 2020 at 11:33:06AM +0100, Richard Biener wrote:
> > where POINTER_PLUS_EXPR last operand has sizetype type, thus unsigned,
> > and in the testcase gimple_assign_rhs2 (def) is thus 0xf001ULL
> > which multiplied by 8 doesn't fit into signed HWI. If it would be treat
On Wed, 4 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> On Wed, Mar 04, 2020 at 11:33:06AM +0100, Richard Biener wrote:
> > > where POINTER_PLUS_EXPR last operand has sizetype type, thus unsigned,
> > > and in the testcase gimple_assign_rhs2 (def) is thus 0xf001ULL
> > > which multiplied b
For the zTPF we must not use floating point registers.
gcc/ChangeLog:
2020-03-04 Andreas Krebbel
* config/s390/s390.c (s390_secondary_memory_needed): Disallow
direct FPR-GPR copies.
(s390_register_info_gprtofpr): Disallow GPR content to be saved in
FPRs.
---
g
libgcc is supposed to be built with the trace skip flags and branch
targets. Add a zTPF header file fragment and add the -mtpf-trace-skip
option.
libgcc/ChangeLog:
2020-03-04 Andreas Krebbel
* config.host: Include the new makefile fragment.
* config/s390/t-tpf: New file.
---
The zTPF OS implements a tracing facility for function entry and exit
which uses global flags and trace function addresses. The addresses of
the flags as well as the trace functions are currently hard-coded in
the zTPF specific GCC parts of the IBM Z back-end.
With this patch these addresses can b
Building a zTPF cross currently fails when building libstdc++
complaining about the __UINTPTR_TYPE__ to be missing.
Fixed by including the glibc-stdint.h header.
2020-03-04 Andreas Krebbel
* config.gcc: Include the glibc-stdint.h header for zTPF.
---
gcc/config.gcc | 2 +-
1 file cha
On Wed, Mar 4, 2020 at 1:26 AM Martin Sebor wrote:
>
> On 3/3/20 11:50 AM, Richard Biener wrote:
> > On March 3, 2020 4:39:34 PM GMT+01:00, Martin Sebor
> > wrote:
> >> On 3/3/20 2:42 AM, Richard Biener wrote:
> >>> On Tue, Mar 3, 2020 at 12:04 AM Martin Sebor
> >> wrote:
>
> The wide
> -Original Message-
> From: Eric Botcazou
> Sent: March 4, 2020 6:18 AM
> To: Richard Wai
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Ada: gcc-interface: fixed assertion for aliased
entities
>
> > I'll have to look into this.. Any pointers? This assertion is not a
> > languag
Hi,
The previous version of this patch shared part of its code with the
store intrinsics patch
(https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00145.html) so I removed
any duplicated code. This patch now depends on the previously mentioned
store intrinsics patch.
Here is the latest version a
Hi Kyrill,
Ok for backporting this patch to GCC 8 and GCC 9?
Thanks,
Tamar
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Kyrill Tkachov
> Sent: Thursday, January 30, 2020 14:55
> To: Stam Markianos-Wright ; gcc-
> patc...@gcc.gnu.org
> Cc: ni...@redhat.com; R
On 3/4/20 2:14 PM, Tamar Christina wrote:
Hi Kyrill,
Ok for backporting this patch to GCC 8 and GCC 9?
Ok assuming bootstrap and test shows no problems.
Thanks,
Kyrill
Thanks,
Tamar
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org
On Behalf Of Kyrill Tkachov
Sent: Thu
On 3/4/20 10:00 AM, Richard Biener wrote:
On Tue, Mar 3, 2020 at 5:41 PM Egeyar Bagcioglu
wrote:
This patch is for .GCC.command.line sections in LTO objects to be copied
into the final objects as in the following example:
[egeyar@localhost lto]$ gcc -flto -O3 demo.c -c -g --record-gcc-comma
On Mär 04 2020, Richard Biener wrote:
> --record-gcc-command-line is not a FSF GCC option, there's
> -frecord-gcc-switches though which
--record-gcc-command-line is translated to -frecord-gcc-switches by the
driver. That happens for all double-dash options that match an -f
option.
Andreas.
--
Several algorithms check the is_trivially_copyable trait to decide
whether to dispatch to memmove or memcmp as an optimization. Since
r271435 (CWG DR 2094) the trait is true for volatile-qualified scalars,
but we can't use memmove or memcmp when the type is volatile. We need to
also check for volat
Martin, I'd like your thoughts here.
As noted in the BZ our #pragmas aren't working to suppress a warning.
I did some debugging and ultimately found that the location passed down to the
diagnostic code is indeed outside the scope of the pragmas.
Further digging uncovered that we had a reasonabl
On Mon, 2 Mar 2020 16:48:26 -0500
David Malcolm wrote:
> +static inline bool
> +is_std_function_p (const_tree fndecl)
> +{
> + tree name_decl = DECL_NAME (fndecl);
> + if (!name_decl)
> +return false;
> + if (!DECL_CONTEXT (fndecl))
> +return false;
> + if (TREE_CODE (DECL_CONTEXT (f
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 13e3ba14eccc0b1ccf1ba9de90443ec7e524f2a6.
gcc/analyzer/ChangeLog:
* engine.cc (worklist::worklist): Remove unused field m_eg.
(class viz_callgraph_edge): Remove unused field m_call_sedge.
(cl
PR analyzer/93993 reports another ICE within
diagnostic_manager::prune_for_sm_diagnostic in which the expression
of interest becomes a non-lvalue (similar to PR 93544, PR 93647, and
PR 93950), due to attempting to get an lvalue for a non-lvalue with a
NULL context, leading to an ICE when the failur
On 3/4/20 4:34 PM, Andreas Schwab wrote:
On Mär 04 2020, Richard Biener wrote:
--record-gcc-command-line is not a FSF GCC option, there's
-frecord-gcc-switches though which
--record-gcc-command-line is translated to -frecord-gcc-switches by the
driver. That happens for all double-dash opti
The false warning:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL â_6â [CWE-690]
[-Wanalyzer-possible-null-dereference]
in the reproducer for PR analyzer/93993 is due to a BUILTIN_EXPECT in
the chain of
On Wed, Mar 04, 2020 at 04:54:54PM +0100, Bernhard Reutner-Fischer wrote:
> On Mon, 2 Mar 2020 16:48:26 -0500
> David Malcolm wrote:
>
> > +static inline bool
> > +is_std_function_p (const_tree fndecl)
> > +{
> > + tree name_decl = DECL_NAME (fndecl);
> > + if (!name_decl)
> > +return fals
On Wed, 2020-03-04 at 16:54 +0100, Bernhard Reutner-Fischer wrote:
> On Mon, 2 Mar 2020 16:48:26 -0500
> David Malcolm wrote:
>
> > +static inline bool
> > +is_std_function_p (const_tree fndecl)
> > +{
> > + tree name_decl = DECL_NAME (fndecl);
> > + if (!name_decl)
> > +return false;
> >
On Wed, 2020-03-04 at 11:05 -0500, Marek Polacek wrote:
> On Wed, Mar 04, 2020 at 04:54:54PM +0100, Bernhard Reutner-Fischer
> wrote:
> > On Mon, 2 Mar 2020 16:48:26 -0500
> > David Malcolm wrote:
> >
> > > +static inline bool
> > > +is_std_function_p (const_tree fndecl)
> > > +{
> > > + tree n
On 3/4/20 8:54 AM, Jeff Law wrote:
Martin, I'd like your thoughts here.
As noted in the BZ our #pragmas aren't working to suppress a warning.
I did some debugging and ultimately found that the location passed down to the
diagnostic code is indeed outside the scope of the pragmas.
Further digg
On 3/4/20 1:18 AM, Fangrui Song wrote:
On 2020-03-03, Joseph Myers wrote:
On Tue, 3 Mar 2020, Egeyar Bagcioglu wrote:
Although we discussed after the submission of the first version that
there are several other options performing similar tasks, I believe we
established that there is still a
On 3/4/20 5:28 PM, Egeyar Bagcioglu wrote:
On 3/4/20 1:18 AM, Fangrui Song wrote:
On 2020-03-03, Joseph Myers wrote:
On Tue, 3 Mar 2020, Egeyar Bagcioglu wrote:
Although we discussed after the submission of the first version that
there are several other options performing similar tasks,
Hi Delia,
On 3/4/20 2:05 PM, Delia Burduv wrote:
Hi,
The previous version of this patch shared part of its code with the
store intrinsics patch
(https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00145.html) so I removed
any duplicated code. This patch now depends on the previously mentioned
store i
Hi Delia,
On 3/3/20 5:23 PM, Delia Burduv wrote:
Hi,
I noticed that the patch doesn't apply cleanly. I fixed it and this is
the latest version.
Thanks,
Delia
On 3/3/20 4:23 PM, Delia Burduv wrote:
Sorry, I forgot the attachment.
On 3/3/20 4:20 PM, Delia Burduv wrote:
Hi,
I made a mistak
Hi,
This is the latest version of the patch.
Thanks,
Delia
On 2/21/20 11:41 AM, Kyrill Tkachov wrote:
Hi Delia,
On 2/19/20 5:23 PM, Delia Burduv wrote:
Hi,
Here is the latest version of the patch. It just has some minor
formatting changes that were brought up by Richard Sandiford in the
A
On 3/4/20 4:25 PM, Egeyar Bagcioglu wrote:
Thanks Richard.
I do not have write-access to the GCC repo. I'd be glad if someone commits itÂ
for me.
Can we please wait? I'm really convinced we do not want one another very similar
functionality. I would definitely recommend to change the semantics
The bug has been fixed for a while. I added the two tests from
the report in 97bd1d6b513..3ca63e1c76b (attached).
Martin
commit 3ca63e1c76b7693b5d3f5ba2567421defc764249 (HEAD -> master)
Author: Martin Sebor
Date: Wed Mar 4 10:23:49 2020 -0700
PR middle-end/81401 - false positive -Wformat
On Wed, Mar 04, 2020 at 06:23:10PM +0100, Martin LiĹĄka wrote:
> On 3/4/20 4:25 PM, Egeyar Bagcioglu wrote:
> > Thanks Richard.
> >
> > I do not have write-access to the GCC repo. I'd be glad if someone commitsÂ
> > it for me.
>
> Can we please wait? I'm really convinced we do not want one another
On 2/14/20 3:06 PM, Martin Sebor wrote:
On 2/13/20 3:59 PM, Jason Merrill wrote:
On 2/12/20 9:21 PM, Martin Sebor wrote:
On 2/11/20 5:28 PM, Jason Merrill wrote:
On 2/11/20 9:00 PM, Martin Sebor wrote:
r270155, committed in GCC 9, introduced a transformation that strips
redundant trailing zer
On 3/4/20 6:33 PM, Jakub Jelinek wrote:
On Wed, Mar 04, 2020 at 06:23:10PM +0100, Martin LiĹĄka wrote:
On 3/4/20 4:25 PM, Egeyar Bagcioglu wrote:
Thanks Richard.
I do not have write-access to the GCC repo. I'd be glad if someone commits itÂ
for me.
Can we please wait? I'm really convinced we
On Wed, Mar 04, 2020 at 06:42:29PM +0100, Martin LiĹĄka wrote:
> > I must say I don't really see advantages of this over
> > -grecord-gcc-switches, recording all options looks very bloaty and will
> > include mostly stuff you don't really care about (such as, e.g. the -I
> > options without knowing
On Wed, Mar 04, 2020 at 03:08:41PM +0800, binbin wrote:
> >>* config/rs6000/rs6000.h (MAX_MACHINE_MODE): Include the header file
> >>for MAX_MACHINE_MODE.
> >
> >The changelog entry should say *what* file is included, and under what
> >condition. It doesn't have to say why (that belongs in
Hi!
On Wed, Mar 04, 2020 at 03:13:51PM +0800, Kewen.Lin wrote:
> As PR94019 shows, without misaligned vector access support but with
> realign load, the vectorized loop will end up with realign scheme.
> It generates mask (control vector) with return type vector signed
> char which breaks the not
"Kewen.Lin" writes:
> Hi,
>
> As PR94023 shows, the expected SLP requires misaligned vector access
> support. This patch is to guard the check under the target condition
> vect_hw_misalign to ensure that.
>
> Verified it on ppc64-redhat-linux (Power7 BE).
>
> Is it ok for trunk, and backport to G
"Kewen.Lin" writes:
> Hi,
>
> As PR94019 shows, without misaligned vector access support but with
> realign load, the vectorized loop will end up with realign scheme.
> It generates mask (control vector) with return type vector signed
> char which breaks the not check.
>
> The fix is to differenti
-
Mentor Graphics (Deutschland) GmbH, ArnulfstraĂe 201, 80634 MĂźnchen / Germany
Registergericht Mßnchen HRB 106955, Geschäftsfßhrer: Thomas Heurung, Alexander
Walter
--- Begin Message ---
Hi!
On 2019-05-17T21:16:57+0200, I wrote:
> Now committed to trunk in [...]
> r271345 "[PR894
On 3/4/20 6:23 PM, Martin LiĹĄka wrote:
On 3/4/20 4:25 PM, Egeyar Bagcioglu wrote:
Thanks Richard.
I do not have write-access to the GCC repo. I'd be glad if someone
commits it for me.
Can we please wait? I'm really convinced we do not want one another
very similar
functionality.
I am
On Wed, 04 Mar 2020 11:16:35 -0500
David Malcolm wrote:
> On Wed, 2020-03-04 at 11:05 -0500, Marek Polacek wrote:
> > On Wed, Mar 04, 2020 at 04:54:54PM +0100, Bernhard Reutner-Fischer
> > wrote:
> > > On Mon, 2 Mar 2020 16:48:26 -0500
> > > David Malcolm wrote:
> > >
> > > > +static inlin
On Wed, Mar 04, 2020 at 08:27:10PM +0100, Thomas Schwinge wrote:
> ... which as of PR89433 commit b48f44bf77a39fefc238a16cf1225c6464c82406 causes
> an ICE. Not sure if this is actually supposed to be valid or invalid code.
> Until the interactions between OpenACC and OpenMP 'target' get defined
>
Hi!
On Wed, Mar 04, 2020 at 03:24:52PM +0800, binbin wrote:
> >>+extern union GTY(()) section *toc_section;
> >
> >Why does this add "union"?
>
> If "union" is not added, it reports error showing unknown type name
> âsectionâ
> in file included from ../../host-powerpc64le-unknown-linux-gnu/gcc/t
Hi!
On Wed, Mar 04, 2020 at 06:35:23PM +0800, Kewen.Lin wrote:
> Another try seems to move it into #ifndef USED_FOR_TARGET hunk.
> Since "typedef union section section" is guard by #ifndef USED_FOR_TARGET
> in coretypes.h. It can make them consistent.
Yes, that should work, good idea.
Segher
While backporting our 90505 fix to 9 I noticed a bunch of concepts regressions.
Fortunately I think the following variant of the fix is safe and still fixes
the deduction issue. In 9, we want to reject 'auto' when tf_partial before
returning cp_build_qualified_type_real for TEMPLATE_TYPE_PARM and
A 2017 change that propagated call location to GIMPLE statements
had the unexpected (though not incorrect) effect of setting
the location on calls to __builtin_alloca. When such calls are
the result of the expansion of the alloca macro defined in
a system header like , the change prevents -Walloc
On 3/4/20 10:41 AM, Jason Merrill wrote:
On 2/14/20 3:06 PM, Martin Sebor wrote:
On 2/13/20 3:59 PM, Jason Merrill wrote:
On 2/12/20 9:21 PM, Martin Sebor wrote:
On 2/11/20 5:28 PM, Jason Merrill wrote:
On 2/11/20 9:00 PM, Martin Sebor wrote:
r270155, committed in GCC 9, introduced a transfo
On Wed, Mar 04, 2020 at 02:06:58PM -0700, Martin Sebor wrote:
> +#ifndef alloca
> +// Simulate a definition in a system header.
> +# 13 "/usr/include/alloca.h"
> +# define alloca(n) __builtin_alloca (n)
> +# 15 "Walloca-larger-than-3.c"
> +#endif
This isn't correct simulation of definition in a
âââ Original Message âââ
On Monday, March 2, 2020 12:14 PM, Bill Schmidt wrote:
> On 3/2/20 11:10 AM, Tulio Magno Quites Machado Filho wrote:
>
> > Bill Schmidt writes:
> >
> > > One tiny nit on the document: For the "b" value, let's just say
> > > "VSX" rather than
> > > "VSX as defi
The C++ reproducer for PR analyzer/94028 generates a similar ICE
to that of the Fortran reproducer for PR analyzer/93993 and, like
it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa.
This patch adds the C++ reproducer as a regression test.
Successfully regrtested on x86_64-pc-lin
This patch converts region::validate to a vfunc, implementing
additional checking per subclass: verifying that various
region_id fields within map_region, array_region, stack_region and
root_region are valid, rather than just those within the base class.
Doing so caught bugs earlier in follow-up w
On 3/4/20 4:02 PM, Marek Polacek wrote:
While backporting our 90505 fix to 9 I noticed a bunch of concepts regressions.
Fortunately I think the following variant of the fix is safe and still fixes
the deduction issue. In 9, we want to reject 'auto' when tf_partial before
returning cp_build_quali
On 3/4/20 4:14 PM, Martin Sebor wrote:
On 3/4/20 10:41 AM, Jason Merrill wrote:
On 2/14/20 3:06 PM, Martin Sebor wrote:
On 2/13/20 3:59 PM, Jason Merrill wrote:
On 2/12/20 9:21 PM, Martin Sebor wrote:
On 2/11/20 5:28 PM, Jason Merrill wrote:
On 2/11/20 9:00 PM, Martin Sebor wrote:
r270155,
output_constructor doesn't like two consecutive entries with fields at the
same position; let's avoid adding the one for the empty field.
Tested x86_64-pc-linux-gnu, applying to trunk and 9.
gcc/cp/ChangeLog
2020-03-04 Jason Merrill
PR c++/90432
* init.c (perform_member_init):
On 3/4/20 6:33 PM, Jakub Jelinek wrote:
On Wed, Mar 04, 2020 at 06:23:10PM +0100, Martin LiĹĄka wrote:
On 3/4/20 4:25 PM, Egeyar Bagcioglu wrote:
Thanks Richard.
I do not have write-access to the GCC repo. I'd be glad if someone commits itÂ
for me.
Can we please wait? I'm really convinced w
PR 93962 reports a bootstrap failure on FreeBSD 11.3 due to a format warning.
Andrew Pinski recommended using std::abs rather than a naked abs. I
bootstrapped
and regression tested that on x86_64-linux-gnu.
I was unable to reproduce the failure in a FreeBSD VM. However Gerald (the
reporter) w
On Wed, 4 Mar 2020, Andreas Krebbel wrote:
> Building a zTPF cross currently fails when building libstdc++
> complaining about the __UINTPTR_TYPE__ to be missing.
>
> Fixed by including the glibc-stdint.h header.
To confirm: TPF provides a header, which uses the same types
as glibc's does?
I
On Wed, 2020-03-04 at 09:22 -0700, Martin Sebor wrote:
>
> I don't remember why the code in -Wrestrict unconditionally overwrites
> the statement location rather than only when it's not available, but
> I do remember adding conditional code like in your patch in r277076
> to deal with missing loca
On 3/4/20 4:49 PM, Jeff Law wrote:
On Wed, 2020-03-04 at 09:22 -0700, Martin Sebor wrote:
I don't remember why the code in -Wrestrict unconditionally overwrites
the statement location rather than only when it's not available, but
I do remember adding conditional code like in your patch in r2770
Hi Segher,
On 2020/3/5 ä¸ĺ2:35, Segher Boessenkool wrote:
On Wed, Mar 04, 2020 at 03:08:41PM +0800, binbin wrote:
* config/rs6000/rs6000.h (MAX_MACHINE_MODE): Include the header file
for MAX_MACHINE_MODE.
The changelog entry should say *what* file is included, and under what
co
Hi,
PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
relates to max of '-inf' and 'nan'. This regression occur on P9 which has
new instruction 'xsmaxcdp/xsmincdp'.
The similar issue also could be find on `a < b ? b : a` which is also
generated as `xsmaxcdp` under -O2 for
Hi Segher,
on 2020/3/5 ä¸ĺ2:44, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Mar 04, 2020 at 03:13:51PM +0800, Kewen.Lin wrote:
>> As PR94019 shows, without misaligned vector access support but with
>> realign load, the vectorized loop will end up with realign scheme.
>> It generates mask (control
Hi Richard,
on 2020/3/5 ä¸ĺ3:09, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>>
>> --- a/gcc/testsuite/gcc.dg/vect/vect-over-widen-17.c
>> +++ b/gcc/testsuite/gcc.dg/vect/vect-over-widen-17.c
>> @@ -41,6 +41,10 @@ main (void)
>> }
>>
>> /* { dg-final { scan-tree-dump-not {vect_recog
Hi!
The following testcase fails to assemble, as CONST_STRING in the DEBUG_INSNs
is printed as is, so if it contains \n and/or \r, we are in trouble:
.loc 1 14 3
# DEBUG haystack => [si]
# DEBUG needle => "
"
In the gimple dumps we print those (STRING_CSTs) as
# DEBUG hay
On Wed, Mar 4, 2020 at 5:28 PM Egeyar Bagcioglu
wrote:
>
>
>
> On 3/4/20 1:18 AM, Fangrui Song wrote:
> > On 2020-03-03, Joseph Myers wrote:
> >> On Tue, 3 Mar 2020, Egeyar Bagcioglu wrote:
> >>
> >>> Although we discussed after the submission of the first version that
> >>> there are several othe
On Wed, Mar 4, 2020 at 8:39 PM Egeyar Bagcioglu
wrote:
>
>
>
> On 3/4/20 6:23 PM, Martin LiĹĄka wrote:
> > On 3/4/20 4:25 PM, Egeyar Bagcioglu wrote:
> >> Thanks Richard.
> >>
> >> I do not have write-access to the GCC repo. I'd be glad if someone
> >> commits it for me.
> >
> > Can we please wait?
Hi!
As the testcases shows, the -Wconversion warning behaves quite differently
when -fsanitize=undefined vs. when not sanitizing, but in the end it is
not something specific to sanitizing, if a user uses
return static_cast(static_cast((d++, a) << 1U) | b) | c;
instead of
return static_cast(sta
On Thu, Mar 5, 2020 at 12:49 AM Jeff Law wrote:
>
> On Wed, 2020-03-04 at 09:22 -0700, Martin Sebor wrote:
> >
> > I don't remember why the code in -Wrestrict unconditionally overwrites
> > the statement location rather than only when it's not available, but
> > I do remember adding conditional co
On Thu, 5 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails to assemble, as CONST_STRING in the DEBUG_INSNs
> is printed as is, so if it contains \n and/or \r, we are in trouble:
> .loc 1 14 3
> # DEBUG haystack => [si]
> # DEBUG needle => "
> "
> In th
^
../../src/gcc/json.cc:73:23: warning: unterminated quote character '"' in
format [-Wformat-diag]
73 | pp_printf (pp, "\"%s\": ", key); // FIXME: escaping?
| ^~
/<>/build/./prev-gcc/xg++ -B/<>/build/
84 matches
Mail list logo
