/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/powerpc-linux-gnu/bin/ -nostdinc++
-B/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/src/.libs
-B/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/<>/build/prev-powerpc-linux-gnu/libstdc++-v3/include/power
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
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
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
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
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
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
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
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,
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: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
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
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
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?
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)
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
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
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
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,
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
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
‐‐‐ 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
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
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
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
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
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
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
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
>
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
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
-
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
"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
"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
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
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
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
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 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
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
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
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
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
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
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
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,
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
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
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
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, 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
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 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
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
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.
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
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
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
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.
--
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
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:
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;
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
> -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
> >
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
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
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
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.
---
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.
---
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
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
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:
>
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
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
> 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
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
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
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
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
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
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
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
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
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
84 matches
Mail list logo
