^
../../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/
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
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
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 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?
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
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
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 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
co
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
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 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
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 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
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 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,
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
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
‐‐‐ 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
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
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
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
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 ../../host-powerpc64le-unknown-linux-gnu/gcc/t
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 inlin
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 "[PR894
"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
"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
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 in
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 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 zer
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
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 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
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
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 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
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 a
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 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 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 fals
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 opti
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
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
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
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
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
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 --record-gcc-comma
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
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
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
> -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
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
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
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
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.
---
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
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, 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.
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 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
> 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 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 d
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 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
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 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
Bur
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
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
84 matches
Mail list logo
