[PR63238] output alignment debug information

Output DWARFv5+ DW_AT_alignment for non-default alignment of variables, fields and types. Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install? for include/ChangeLog PR debug/63238 * dwarf2.def (DW_AT_alignment): New. for gcc/ChangeLog PR debug/63238

Re: [Patch, libstdc++/77356] Support escape in regex bracket expression

On Fri, Aug 26, 2016 at 3:09 AM, Jonathan Wakely wrote: > OK for trunk, thanks. Committed as r239794. Thanks! -- Regards, Tim Shen

Re: [PATCH], Patch #7, Add PowerPC vector initialization tests

On Fri, Aug 26, 2016 at 03:29:50PM -0400, Michael Meissner wrote: > These patches add more tests to the PowerPC vector initialization tests. Four > of the tests added (#4, #5, #8, and #9) just try to do a bunch of vector > initializations for the different vector type (char, short, float, and >

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote: > Hello, > > Le 26/08/2016 à 20:27, Steve Kargl a écrit : > > Here are two possible patches for PR fortran/77391. The first > > patch treats the invalid code as a GNU Fortran extension as > > gfortran current accepts the invalid code.

[PATCH] AIX DWARF 64 bit offset (PR 77349)

The AIX assembler implicitly inserts the length information at the beginning of DWARF debugging sections. In 64 bit mode, it also implicitly inserts the 64 bit DWARF extension escape sequence. GCC must emit DWARF offsets with a size that matches the 64 bit extension. This patch overrides

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote: > Hello, > > Le 26/08/2016 à 20:27, Steve Kargl a écrit : > > Here are two possible patches for PR fortran/77391. The first > > patch treats the invalid code as a GNU Fortran extension as > > gfortran current accepts the invalid code.

Re: Make max_align_t respect _Float128

On Fri, 26 Aug 2016, Florian Weimer wrote: > The crucial question is whether GCC will start assuming that pointers returned > by malloc (or attribute-malloc functions) have such an alignment. That seems > impossible. GCC's assumptions about the alignment of pointers returned by malloc are more

Re: Make max_align_t respect _Float128

On 08/26/2016 02:45 PM, Florian Weimer wrote: In the end, max_align_t is ignored by allocators, and applications cannot rely on it as a result. Hmm, well, in that case I suppose I should change Emacs to ignore max_align_t as well. Thanks for the heads-up.

Re: Make max_align_t respect _Float128

On 08/26/2016 01:54 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; It should be fine, though I would like

Re: Make max_align_t respect _Float128

On 08/26/2016 10:54 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on

Re: Make max_align_t respect _Float128

On Fri, 26 Aug 2016, Marc Glisse wrote: > On Fri, 26 Aug 2016, Joseph Myers wrote: > > > And since __float128 is architecture-specific, there > > isn't a preprocessor conditional that means "__float128 is available" > > That's what __SIZEOF_FLOAT128__ was supposed to be for. I didn't add it to

[committed] Add validation and consolidation of fix-it hints

The first aspect of this patch is to add some checking of fix-it hints. The idea is to put this checking within the rich_location machinery, rather than requiring every diagnostic to implement it for itself. The fixits within a rich_location are "atomic": all must be valid for any to be

Re: Make max_align_t respect _Float128

On Fri, 26 Aug 2016, Joseph Myers wrote: And since __float128 is architecture-specific, there isn't a preprocessor conditional that means "__float128 is available" That's what __SIZEOF_FLOAT128__ was supposed to be for. I didn't add it to itanium because zombies, and it looks like powerpc

Make max_align_t respect _Float128

The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in such a way that they are basic types, meaning that max_align_t must be at least as aligned as those types. On 32-bit x86, max_align_t is currently 8-byte aligned, but _Decimal128 and _Float128 are 16-byte aligned, so the

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote: > Hello, > > Le 26/08/2016 à 20:27, Steve Kargl a écrit : > > Here are two possible patches for PR fortran/77391. The first > > patch treats the invalid code as a GNU Fortran extension as > > gfortran current accepts the invalid code.

[gomp4] lto dump of callee counts

I've committed this to gomp4 branch. The lto device compiler was ICEing when reading in the offload inline statistics. The root cause was due to it not having the function bodies of some functions, it therefore didn't try and read callee statistics. Thus starting reading the next function's

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

Hello, Le 26/08/2016 à 20:27, Steve Kargl a écrit : Here are two possible patches for PR fortran/77391. The first patch treats the invalid code as a GNU Fortran extension as gfortran current accepts the invalid code. The second patch enforces the standard. As I think gfortran should

[PATCH], Patch #7, Add PowerPC vector initialization tests

These patches add more tests to the PowerPC vector initialization tests. Four of the tests added (#4, #5, #8, and #9) just try to do a bunch of vector initializations for the different vector type (char, short, float, and double). These other patches (#6, #7) test the code generated in paches #5

Re: [ARM] mno-pic-data-is-text-relative & msingle-pic-base

Joey, Thanks for your understanding response and sorry for my late reply. I have been badly caught up in work related stuff, lately. As you might already be aware of, -mno-PDITR and -mSPB are primarily targeted for MMU-less targets (or where you do have MMU but do not want to/cannot use address

Re: [PATCH][AArch64] Fix symbol offset limit

Richard Earnshaw (lists) wrote: > > So isn't the real bug that we've permitted the user to create an object > that is too large for the data model? No that's a different issue I'm not trying to address here. The key is that as long as the start of the symbol is in

Re: [PATCH][AArch64 - v2] Simplify eh_return implementation

Jiong Wang wrote: > The -fomit-frame-pointer is really broken on aarch64_find_eh_return_addr Yes, that's a good conclusion. However even with the frame pointer there are cases that fail, for example it will access LR off SP even after alloca. In fact we're lucky it

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

Hi Steve, I am strongly for the enforcement of the standard. Please apply patch #2. Cheers Paul On 26 August 2016 at 20:27, Steve Kargl wrote: > Here are two possible patches for PR fortran/77391. The first > patch treats the invalid code as a GNU Fortran

[PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

Here are two possible patches for PR fortran/77391. The first patch treats the invalid code as a GNU Fortran extension as gfortran current accepts the invalid code. The second patch enforces the standard. As I think gfortran should encourage standard conformance, I am inclined to commit the

[committed] Tweak to colors of fix-it hints

Previous, fix-it hints were printed using the color of the severity of the diagnostic (magenta for warnings, red for errors, cyan for notes). This patch updates fix-it hints so that replacement text is printed in green, to better distinguish the suggested improvement from the current code. For

Re: [PATCH] selftest.h: mark failure functions with "noreturn"

On 8/26/16, Bernd Schmidt wrote: > On 08/26/2016 06:05 PM, David Malcolm wrote: >> selftest::fail and selftest::fail_formatted call abort. Marking >> them as "noreturn" can help eliminate false warnings about unreachable >> code in selftests. >> >> Successfully bootstrapped

Re: [Patch] Implement std::experimental::variant

Hi, On Fri, Aug 26, 2016 at 7:43 AM, Andre Vieira (lists) wrote: > I am seeing failures on arm-none-eabi for Cortex-M0 for these two tests: > .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant: In > member function

[PATCH] selftest.h: mark failure functions with ATTRIBUTE_NORETURN.

On Fri, 2016-08-26 at 18:00 +0200, Bernd Schmidt wrote: > On 08/26/2016 06:05 PM, David Malcolm wrote: > > selftest::fail and selftest::fail_formatted call abort. Marking > > them as "noreturn" can help eliminate false warnings about > > unreachable > > code in selftests. > > > > Successfully

Re: [PATCH] xtensa: report stack usage

On Fri, Aug 26, 2016 at 9:24 AM, augustine.sterl...@gmail.com wrote: > On Fri, Aug 26, 2016 at 12:02 AM, Max Filippov wrote: >> This enables options -fstack-usage and -Wstack-usage. >> >> 2016-08-21 Max Filippov >> gcc/ >>

Re: [RFC] ipa bitwise constant propagation

On 26 August 2016 at 21:53, Rainer Orth wrote: > Hi Prathamesh, > >> The attached version passes bootstrap+test on >> x86_64-unknown-linux-gnu, ppc64le-linux-gnu, >> and with c,c++,fortran on armv8l-linux-gnueabihf. >> Cross-tested on arm*-*-* and aarch64*-*-*. >>

[PATCH][msp430] Don't output __interrupt_vector sections for weak functions

The msp430 target supports an "interrupt" attribute, which can take an optional argument specifying the interrupt number. If this argument is provided then the compiler will output an __interrupt_vector_ section that the linker script can use to create a vector table. PR target/70713

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Fri, Aug 26, 2016 at 05:03:34PM +0200, Bernd Schmidt wrote: > On 08/26/2016 04:50 PM, Segher Boessenkool wrote: > >The head comment starts with > > > >+/* Separate shrink-wrapping > >+ > >+ Instead of putting all of the prologue and epilogue in one spot, we > >+ can put parts of it in

Re: [PATCH] xtensa: report stack usage

On Fri, Aug 26, 2016 at 12:02 AM, Max Filippov wrote: > This enables options -fstack-usage and -Wstack-usage. > > 2016-08-21 Max Filippov > gcc/ > * config/xtensa/xtensa.c (xtensa_expand_prologue): Update >

Re: [RFC] ipa bitwise constant propagation

Hi Prathamesh, > The attached version passes bootstrap+test on > x86_64-unknown-linux-gnu, ppc64le-linux-gnu, > and with c,c++,fortran on armv8l-linux-gnueabihf. > Cross-tested on arm*-*-* and aarch64*-*-*. > Verified the patch survives lto-bootstrap on x86_64-unknown-linux-gnu. > Ok to commit ?

Re: [PR59319] output friends in debug info

On Fri, Aug 19, 2016 at 2:46 PM, Alexandre Oliva wrote: > Handling non-template friends is kind of easy, but it required a bit > of infrastructure in dwarf2out to avoid (i) forcing debug info for > unused types or functions: DW_TAG_friend DIEs are only emitted if > their

Re: [PATCH] selftest.h: mark failure functions with "noreturn"

On 08/26/2016 06:05 PM, David Malcolm wrote: selftest::fail and selftest::fail_formatted call abort. Marking them as "noreturn" can help eliminate false warnings about unreachable code in selftests. Successfully bootstrapped on x86_64-pc-linux-gnu. OK for trunk? Don't we want to wrap this

Re: [PATCH 3/3] make stack_slot_list a vec

On 08/26/2016 06:03 PM, Trevor Saunders wrote: yeah, it was just from being overly careful to not change behavior, but that's silly we can always revert if it turns out to break something. Not silly at all - it's a good mindset to have. But in cases where the order doesn't matter I think it's

Re: PR35503 - warn for restrict pointer

On Fri, Aug 26, 2016 at 7:39 AM, Prathamesh Kulkarni wrote: > However with C++FE it appears TYPE_RESTRICT is not set for the > parameters (buf and fmt) > and hence the warning doesn't get emitted for C++. > C FE sets TYPE_RESTRICT for them. I am not sure how to

Re: [PATCH 3/3] make stack_slot_list a vec

On Thu, Aug 25, 2016 at 10:46:14AM +0200, Bernd Schmidt wrote: > On 08/25/2016 08:50 AM, tbsaunde+...@tbsaunde.org wrote: > > @@ -2626,8 +2626,10 @@ unshare_all_rtl_1 (rtx_insn *insn) > > This special care is necessary when the stack slot MEM does not > > actually appear in the insn

[PATCH] selftest.h: mark failure functions with "noreturn"

selftest::fail and selftest::fail_formatted call abort. Marking them as "noreturn" can help eliminate false warnings about unreachable code in selftests. Successfully bootstrapped on x86_64-pc-linux-gnu. OK for trunk? gcc/ChangeLog: * selftest.h (selftest::fail): Add __attribute__

[gomp4] check for sufficient parallelism when calling acc routines in fortran

This patch teaches the fortran FE how to verify that there is sufficient parallelism when calling acc routines inside acc loop. E.g. the fortran FE will now error if you call a gang routine from a vector loop, because there's no way for vector partitioned code to spawn new gangs with the OpenACC

Re: [PATCH, PR70955] Tag {ms,sysv}_va_list_type_node with {ms,sysv}_abi attribute

On 26/08/16 10:40, Richard Biener wrote: I suppose you could get away with using sth entirely private to the backend, like "sysv abi valist", also not ever user-creatable. Does this side-step the FE issue? It does. Added comments and second test-case, as requested previously. Bootstrapped

C++ PATCH for c++/57728 (explicit instantiation and defaulted functions)

The testcase in 57728 demonstrates that we have been treating functions explicitly defaulted in the class body inconsistently with explicit instantiation: an extern instantiation causes them not to be generated, but a normal explicit instantiation doesn't cause them to be emitted, leading to link

Re: [PATCH][AArch64 - v2] Simplify eh_return implementation

Wilco Dijkstra writes: > Ping > > I noticed it would still be a good idea to add an extra barrier in the epilog > as the > scheduler doesn't appear to handle aliases of frame accesses properly. > > This patch simplifies the handling of the EH return value. We force the use > of the > frame

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 08/26/2016 04:50 PM, Segher Boessenkool wrote: The head comment starts with +/* Separate shrink-wrapping + + Instead of putting all of the prologue and epilogue in one spot, we + can put parts of it in places where those components are executed less + frequently. and that is the long

Re: [PATCH v2 0/9] Separate shrink-wrapping

Hi Bernd, On Fri, Aug 26, 2016 at 03:03:43PM +0200, Bernd Schmidt wrote: > Not really, I'm afraid. There still seems to be no detailed explanation > of the algorithm. Instead, there is a vague outline Did you read the description of 8/9? If you think any of that needs to be in the code, please

Re: [Patch] Implement std::experimental::variant

On 19/08/16 09:18, Jonathan Wakely wrote: > On 18/08/16 13:32 -0700, Tim Shen wrote: >> Tested on x86_64-linux-gnu and checked in as r239590. > > This updates the status at > https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z > > Committed to trunk. > > Hi, I am

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 08/26/2016 03:48 PM, David Malcolm wrote: I'm nervous about the build_random_cfg function: randomness in selftests seems like a double-edged sword. On the one hand, we can use it to fuzz-test an optimization to rapidly gain a lot of coverage. On the other hand, does every host generate the

Re: [PATCH v2 0/9] Separate shrink-wrapping

On Fri, 2016-08-26 at 15:03 +0200, Bernd Schmidt wrote: > On 08/01/2016 03:42 AM, Segher Boessenkool wrote: > > This is the second version. Concern was renamed to component, and > > all > > other comments were addressed (I hope). > > Not really, I'm afraid. There still seems to be no detailed >

Re: Fix bogus warning with -Wlogical-not-parentheses (PR c/77292)

On Thu, Aug 25, 2016 at 11:35:53AM -0600, Martin Sebor wrote: > > +foo (int a, int b) > > +{ > > + int r = 0; > > + r += !a == (a < b); > > + r += !a == (a > b); > > + r += !a == (a >= b); > > + r += !a == (a <= b); > > + r += !a == (a != b); > > + r += !a == (a == b); > > + r += !a == (a

Re: Fix bogus warning with -Wlogical-not-parentheses (PR c/77292)

On Fri, Aug 26, 2016 at 11:18:46AM +0200, Richard Biener wrote: > On Fri, Aug 26, 2016 at 10:57 AM, Marek Polacek wrote: > > On Fri, Aug 26, 2016 at 10:53:01AM +0200, Richard Biener wrote: > >> On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote: > >> >

[PATCH] libstdc++/51960 move-construction for raw_storage_iterator

PR libstdc++/51960 * doc/xml/manual/intro.xml: Document DR 2127 change. * doc/html/*: Regenerate. * include/bits/stl_raw_storage_iter.h (operator=(_Tp&&)): Add. (operator++(), operator++(int)): Use injected class name. *

Re: [PATCH v2 0/9] Separate shrink-wrapping

On 08/01/2016 03:42 AM, Segher Boessenkool wrote: This is the second version. Concern was renamed to component, and all other comments were addressed (I hope). Not really, I'm afraid. There still seems to be no detailed explanation of the algorithm. Instead, there is a vague outline (which

[lto] remove unnecessary assignment

In chasing down an LTO read/write bug I came across some 'interesting' code in inline_write_summaries: if (cnode && (node = cnode)->definition && !node->alias) that in-test assignment isn't needed -- cnode is not modified until the next loop iteration. Fixed as obvious by removing the

[PATCH] Fix PR69047

The following fixes PR69047, update-address-taken can use the same trick as VN and re-write MEM[] into SSA when the size of the MEM and the size of d do not match by using a BIT_FIELD_REF. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. The patch contains a workaround for

Re: [RFC] ipa bitwise constant propagation

On 25 August 2016 at 19:14, Jan Hubicka wrote: >> Patch for performing interprocedural bitwise constant propagation. >> >> 2016-08-23 Prathamesh Kulkarni >> Martin Jambhor >> >> * common.opt: New option

Re: [PATCH] Use effective-target instead of -std options

On 26/08/16 12:42 +0100, Jonathan Wakely wrote: This large patch replaces most of the remaining uses of -std in dg-options with { target c++11 } or { target c++14 } effective targets. The advantage of this is that we will now test most things with the default gnu++14 mode. Previously most tests

Re: PR35503 - warn for restrict pointer

Arguments passed to diagnostic functions should not end with '\n'. -- Joseph S. Myers jos...@codesourcery.com

Release notes for _FloatN, _FloatNx

I've committed this patch to add release notes for the _FloatN, _FloatNx support. Index: gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.9 diff -u -r1.9 changes.html ---

PR35503 - warn for restrict pointer

Hi, The following patch adds option -Wrestrict that warns when an argument is passed to a restrict qualified parameter and it aliases with another argument. eg: int foo (const char *__restrict buf, const char *__restrict fmt, ...); void f(void) { char buf[100] = "hello"; foo (buf, "%s-%s",

Re: [PATCH] PR fortran/77372

On Thu, Aug 25, 2016 at 6:13 PM, Steve Kargl wrote: > I plan to commit the following patch on Saturday if > no one objects in the next 40 or so hours. > > 2016-08-25 Steven G. Kargl > > PR fortran/77372 > simplify.c

[PATCH] Fix Java with LTO

This re-syncs java_mange_decl with lhd_set_decl_assembler_name. Committed as obvious. Otherwise testing with -flto fails in libjava testing with ^[[01m^[[K:^[[m^[[K ^[[01;31m^[[Kinternal compiler error: ^[[m^[[Kin java_mangle_decl, at java/mangle.c:84^M 0x63a513 java_mangle_decl(tree_node*)^M

[PATCH] Add new std::basic_string constructor (LWG 2583)

This adds the new constructor required by the resolution of LWG 2583. The new symbols matched the greedy patterns for strings in old symbol versions, so I made them much more precise. It's possible some symbols that are supposed to be exported will now not match, but I checked that all symbols in

Re: [PATCH] Generalize overriding mechanism for debug info output options defaults

On 08/18/2016 04:41 PM, Jeff Law wrote: It's pie in the sky right now, but it's something many of us want to see happen. To that end we're trying to steer away from certain problematic idioms (like using macros to conditionalize behavior) towards schemes that would work in that world (hooks).

Re: [PATCH][AArch64] Fix symbol offset limit

On 23/08/16 15:10, Wilco Dijkstra wrote: > In aarch64_classify_symbol symbols are allowed full-range offsets on > relocations. > This means the offset can use all of the +/-4GB offset, leaving no offset > available > for the symbol itself. This results in relocation overflow and link-time >

[wwwdocs] Document libstdc++ changes in GCC 7

I've committed this patch for /gcc-7/changes.html Index: htdocs/gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.8 diff -u -r1.8 changes.html --- htdocs/gcc-7/changes.html 25 Aug

Re: [PATCH][ARM] PR target/70473: Reduce size of Cortex-A8 automaton

On Fri, Aug 26, 2016 at 11:14 AM, Kyrill Tkachov wrote: > Hi all, > > The scheduling automata sizes are getting a bit out of control (as the PR > complains about) and the Cortex-A8 > one is one of the largest offenders. An easy, low-hanging fruit in dealing > with

Re: [PATCH][ARM] PR target/70473: Reduce size of Cortex-A8 automaton

On 26/08/16 11:14, Kyrill Tkachov wrote: > Hi all, > > The scheduling automata sizes are getting a bit out of control (as the > PR complains about) and the Cortex-A8 > one is one of the largest offenders. An easy, low-hanging fruit in > dealing with this are some of the FP/NEON operations > that

[PATCH][ARM] PR target/70473: Reduce size of Cortex-A8 automaton

Hi all, The scheduling automata sizes are getting a bit out of control (as the PR complains about) and the Cortex-A8 one is one of the largest offenders. An easy, low-hanging fruit in dealing with this are some of the FP/NEON operations that have very large reservation durations specified for

Re: [PATCH][ARM] Refactor MOVW/MOVT fusion logic to allow extension

On 24/08/16 16:26, Kyrill Tkachov wrote: > Hi all, > > If we want to add more macro fusion cases in the arm backend we need to > rework the aarch_macro_fusion_pair_p a bit > to not return early during the MOVW/MOVT fusion checks. This simple > patch does that by adding a helper function > that

[PATCH][RFC] Early LTO debug

The patch below is my current development state of Early LTO debug lumped into one big patch (no changelog, sorry). It contains previously posted https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01089.html which extends dwarf2asm.h and adjusts a target hook which means the patch carries the

Re: [Patch, libstdc++/77356] Support escape in regex bracket expression

On 24/08/16 12:48 -0700, Tim Shen wrote: On Wed, Aug 24, 2016 at 1:41 AM, Jonathan Wakely wrote: On 24/08/16 00:18 -0700, Tim Shen wrote: I didn't realized that we can actually escape a dash inside bracket expression: R"([\-])", in which case the dash should be treated

Re: [PATCH][AArch64][GCC 5] Backport Work around for PR target/64971

On 26/08/16 09:52, Kyrill Tkachov wrote: > Hi all, > > I'd like to backport this fix for an ILP32 ICE. This was a simple > band-aid proposed by Andrew > that is self-contained and doesn't touch non-ILP32 or non-aarch64 code > so it should be pretty safe > to backport. It has been in trunk and GCC

Re: Fix bogus warning with -Wlogical-not-parentheses (PR c/77292)

On Fri, Aug 26, 2016 at 10:57 AM, Marek Polacek wrote: > On Fri, Aug 26, 2016 at 10:53:01AM +0200, Richard Biener wrote: >> On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote: >> > On Thu, Aug 25, 2016 at 11:17:37AM +0200, Richard Biener wrote: >> >> On

Re: [PR59319] output friends in debug info

On Fri, Aug 26, 2016 at 7:25 AM, Alexandre Oliva wrote: > On Aug 22, 2016, Richard Biener wrote: > >> Just throwing in a wrench from the side ... you should do this in >> dwarf2out_early_finish as late there will be no frontend around anymore. > >

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

On Fri, Aug 26, 2016 at 5:08 AM, Prasad Ghangal wrote: > On 24 August 2016 at 15:32, Richard Biener wrote: >> On Mon, Aug 22, 2016 at 8:40 PM, Prasad Ghangal >> wrote: >>> On 22 August 2016 at 16:55, Trevor Saunders

Re: Fix bogus warning with -Wlogical-not-parentheses (PR c/77292)

On Fri, Aug 26, 2016 at 10:53:01AM +0200, Richard Biener wrote: > On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote: > > On Thu, Aug 25, 2016 at 11:17:37AM +0200, Richard Biener wrote: > >> On Wed, Aug 24, 2016 at 7:43 PM, Marek Polacek wrote: > >> >

[PATCH][AArch64][GCC 5] Backport Work around for PR target/64971

Hi all, I'd like to backport this fix for an ILP32 ICE. This was a simple band-aid proposed by Andrew that is self-contained and doesn't touch non-ILP32 or non-aarch64 code so it should be pretty safe to backport. It has been in trunk and GCC 6 for quite some time without issues until

Re: Fix bogus warning with -Wlogical-not-parentheses (PR c/77292)

On Thu, Aug 25, 2016 at 3:39 PM, Marek Polacek wrote: > On Thu, Aug 25, 2016 at 11:17:37AM +0200, Richard Biener wrote: >> On Wed, Aug 24, 2016 at 7:43 PM, Marek Polacek wrote: >> > The -Wlogical-not-parentheses deliberately doesn't warn when the RHS has

Re: [PATCH, PR70955] Tag {ms,sysv}_va_list_type_node with {ms,sysv}_abi attribute

On Thu, 25 Aug 2016, Tom de Vries wrote: > On 25/08/16 13:48, Richard Biener wrote: > > On Wed, 24 Aug 2016, Tom de Vries wrote: > > > > > Hi, > > > > > > in PR70955, ix86_canonical_va_list_type fails to recognize a > > > __builtin_ms_va_list that was declared in a TU, because its type doesn't

[PATCH] xtensa: report stack usage

This enables options -fstack-usage and -Wstack-usage. 2016-08-21 Max Filippov gcc/ * config/xtensa/xtensa.c (xtensa_expand_prologue): Update current_function_static_stack_size variable with the static stack frame size of the current function when