[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 Mikhail Maltsev changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment

Re: Need suggestion about bug 68425

I was working on PR68425, my untested patch : diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c --- a/trunk/gcc/c/c-typeck.c(revision 232768) +++ b/trunk/gcc/c/c-typeck.c(working copy) @@ -5856,7 +5856,7 @@ component name is taken from the spelling stack. */ static

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Sat, Feb 20, 2016 at 9:47 PM, Richard Smith wrote: > On 20 Feb 2016 6:54 p.m., "H.J. Lu" wrote: >> >> On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin >> wrote: >> > On 20 February 2016 at 23:35, H.J. Lu

[Bug tree-optimization/69887] New: gcc ICE at -O1 and above on x86_64-linux-gnu in mark_jump_label_1

/trunk/root-gcc --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 6.0.0 20160220 (experimental) [trunk revision 233587] (GCC) $ gcc-trunk -O1 abc.c abc.c: In function 'main': abc.c:6:1: internal compiler error: in mark_jump_label_1, at jump.c:1159

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin wrote: > On 20 February 2016 at 23:35, H.J. Lu wrote: >> Can a compiler tell if a copy constructor or destructor is trivial >> from the class declaration without function body? > > Yes, the mere

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #30 from Mark Wielaard --- https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01433.html

[PATCH] PR28901 Add two levels for -Wunused-const-variable.

There is some controversy about enabling -Wunused-const-variable for all unused static const variables because some feel there are too many errors exposed in header files. Create two levels for -Wunused-const-variable. One level to only check for unused static const variables in the main

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #29 from Mark Wielaard --- (In reply to Manuel López-Ibáñez from comment #27) > (In reply to Mark Wielaard from comment #21) > > Although in C a static const is not really like a #define I suspect that > > there are cases where they

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #28 from Mark Wielaard --- (In reply to Panu Matilainen from comment #26) > On main files warning on unused junk is certainly useful but static const is > commonly and deliberately used in headers (eg for arrays such as in comment >

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 20 February 2016 at 23:35, H.J. Lu wrote: > Can a compiler tell if a copy constructor or destructor is trivial > from the class declaration without function body? Yes, the mere presence of the declaration suffices to render it non-trivial (unless explicitly declared "=

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Sat, Feb 20, 2016 at 11:40 AM, Matthijs van Duin wrote: > On 20 February 2016 at 20:34, H.J. Lu wrote: >> Is there a class, which meets the above definition, with a member function >> which can't be passed without a memory slot or a register? >

[PATCH] Fix PR c++/69694 (non-dependent MODOP_EXPR with NULL type)

The problem here is that when processing_template_decl, the non-compound MODOP_EXPRs we build (i.e. a = b and not a += b) are given a NULL TREE_TYPE even if none of its operands are dependent. This causes decltypes such as "decltype (a = b)" (where a and b are not dependent) to fail to get

Re: [PATCH] Fix Bug 17896: The expression (a>0 & b>0) should give clearer warning message (-Wparentheses)

On Sat, 2016-01-30 at 19:05 +0530, Prasad Ghangal wrote: > Hi! > > This is my first proposed patch for > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896. I was willing to > do it using "APPEARS_TO_BE_BOOLEAN_EXPR_P(CODE, ARG)" to check > booleans but gcc doesn't allow (bootstraping fails).

[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3

[Bug target/69886] New: ICE: in process_insert_insn, at gcse.c:1976 with --param=gcse-unrestricted-cost=0 @ aarch64

usr/aarch64-unknown-linux-gnu --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-233588-checking-yes-rtl-df-nographite-aarch64 Thread model: posix gcc version 6.0.0 20160220 (experimental) (GCC) $ aarch64-unknown-linux-gnu-gcc -Os --param=gcse-unrestricted-cost=0 testcase.c testcas

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

Hi Paul, More importantly, now that it has happened in the field, I must fix the collisions in SELECT TYPE. The only way that I know to do this reliably is to drop the use of a has and to use the extended type names directly Can you also use the hash in the usual case and only do a

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

On Fri, Feb 19, 2016 at 09:15:16PM -0500, Tony V E wrote: > There's at least one easy answer in there: > > > ‎If implementations must support annotation, what form should that > annotation take?  P0190R0 recommends the [[carries_dependency]] > attribute, but I am not picky as long as

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 20 February 2016 at 20:34, H.J. Lu wrote: > Is there a class, which meets the above definition, with a member function > which can't be passed without a memory slot or a register? The EmptyInt class in my first post in this thread. It has no non-static data members, has

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Sat, Feb 20, 2016 at 10:50 AM, Matthijs van Duin wrote: > On 20 February 2016 at 18:55, H.J. Lu wrote: >> struct dummy0 >> { >> }; >> >> struct dummy >> { >> dummy0 d[20]; >> >> dummy0 * foo (int i); >> }; >> >> dummy0 * >> dummy::foo (int

[Bug bootstrap/69885] New: [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6903 on arm-linux-gnueabihf

Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen building a m68k-linux-gnu cross compiler, trunk 20160220: $ cat libgcc2.i typedef int DItype __attribute__

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

Le 20/02/2016 19:35, Paul Richard Thomas a écrit : The only way that I know to do this reliably is to drop the use of a has and to use the extended type names directly. This will take a bit of work! Maybe the vtab pointer can be used to discriminate between types? There is one vtab struct for

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156 --- Comment #6 from Jerry DeLisle --- Proposed patch: diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c index c1d79457..c4e7974e 100644 --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -336,7 +336,7 @@ add_path_to_list

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On 20 February 2016 at 18:55, H.J. Lu wrote: > struct dummy0 > { > }; > > struct dummy > { > dummy0 d[20]; > > dummy0 * foo (int i); > }; > > dummy0 * > dummy::foo (int i) > { > return [i]; > } > > dummy0 * > bar (dummy d, int i) > { > return d.foo (i); > } 1. This

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #13 from Bernd Edlinger --- (In reply to Jonathan Wakely from comment #12) > (In reply to Bernd Edlinger from comment #9) > > right now I am trying to boot-strap this: > > > > Index: c/cstddef > >

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

Dear Dominique, dear all, Many thanks for picking up the regression, which turned out to have a trivial cause. I have taken the liberty of assuming that this is tantamount to approval and have committed the patch as revision 233589. Any style or other wrinkles can be corrected later. The reason

[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69423 --- Comment #11 from Paul Thomas --- Author: pault Date: Sat Feb 20 18:26:59 2016 New Revision: 233589 URL: https://gcc.gnu.org/viewcvs?rev=233589=gcc=rev Log: 2016-02-20 Paul Thomas PR fortran/69423 *

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Sat, 20 Feb 2016, H.J. Lu wrote: On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote: On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote: Hi, On Thu, 18 Feb 2016, Richard Smith wrote: An empty type is a type where it and all of its subobjects

[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884 --- Comment #2 from Markus Trippelsdorf --- At least there should be way to silence this warning. There is a patch already: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02256.html

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote: > On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote: >> Hi, >> >> On Thu, 18 Feb 2016, Richard Smith wrote: >> >>> >> An empty type is a type where it and all of its subobjects >>> >> (recursively) are

[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884 --- Comment #1 from Markus Trippelsdorf --- Created attachment 37744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37744=edit unreduced testcase markus@x4 build % g++ -O2 -c sparse_product.ii 2>&1 | grep "ignoring attributes on template

[Bug c++/69884] New: [6 Regression] warning: ignoring attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884 Bug ID: 69884 Summary: [6 Regression] warning: ignoring attributes on template argument Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal

[Fortran, Patch] (Coarrays) Wrong events size

Dear all, currently, the compiler doesn't pass the right size to the registration routine of OpenCoarrays for event variables: size.15 = 0; ev.data = (void * restrict) _gfortran_caf_register (MAX_EXPR , 6, , 0B, 0B, 0); The attached patch solves the problem. I don't understand the

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #12 from Jonathan Wakely --- (In reply to Bernd Edlinger from comment #9) > right now I am trying to boot-strap this: > > Index: c/cstddef > === > --- c/cstddef

[PATCH] Add testcase for PR61033

This patch adds a testcase for PR61033 [1]. The bug is about compiler going into infinite loop while solving data-flow in vt_find_locations on arm-* targets. The issue in fixed in GCC 5 and later by Richard B.'s r211624 [2]. The bug affects GCC 4.8 and 4.9, but is unlikely to be fixed there.

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #26 from David Malcolm --- (In reply to David Malcolm from comment #25) [...] > I have a patch that seems to work for this test case; am testing it more > thoroughly now. Candidate patch posted here:

[PATCH 1/2] RFC: Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning (PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558). This patch attempts to add more test coverage for this, for the various combinations of: - various warnings: -Wunused-variable -Wuninitialized

[PATCH 2/2] PR preprocessor/69126: avoid comparing ad-hoc and non-ad-hoc locations

Comment #18 of PR preprocessor/69126 reported a difficult-to-reproduce re-occurrence of that bug, where attempts to suppress -Wdeprecated-declarations via a _Pragma could fail. The root cause is a bug in linemap_compare_locations when comparing certain macro expansions with certain non-macro

Re: [PATCH] Fix Bug 17896: The expression (a>0 & b>0) should give clearer warning message (-Wparentheses)

PING Sorry I didn't include [Fix PR c/17896] in prev mail https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02361.html On 30 January 2016 at 19:05, Prasad Ghangal wrote: > Hi! > > This is my first proposed patch for > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896. I

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883 --- Comment #4 from Bernd Edlinger --- (In reply to char...@adacore.com from comment #3) > > I could understand that I can not build something form 1992 with todays > > tools, but what I do not understand conceptionally, why the host compiler >

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883 --- Comment #3 from charlet at adacore dot com --- > I could understand that I can not build something form 1992 with todays > tools, but what I do not understand conceptionally, why the host compiler > seems to link with the target compiler's

Re: [Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

> I could understand that I can not build something form 1992 with todays > tools, but what I do not understand conceptionally, why the host compiler > seems to link with the target compiler's runtime, would it work as a > cross build then? No, for a cross build you need an identical native

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883 --- Comment #2 from Bernd Edlinger --- (In reply to Arnaud Charlet from comment #1) > You must use an older (or equal) version of GNAT to build GNAT, using a more > recent version won't work in general, as shown by this PR, and isn't >

Re: [PATCH 1/3] gdb.trace: Move more target dependencies to trace-support.exp

Whoops, sorry for that mail - I typoed gdb-patches to gcc-patches. On 20/02/16 14:56, Marcin Kościelnicki wrote: While groveling through the old PPC64 tracepoint support patch, I've noticed a few target dependencies in the testsuite that both me and Antoine missed for s390 and ARM tracepoints,

[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883 Arnaud Charlet changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug ada/69883] New: gcc-6.0 unable to build gcc-4.9 with ada

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883 Bug ID: 69883 Summary: gcc-6.0 unable to build gcc-4.9 with ada Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada

[Bug testsuite/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

Re: [RFC] Add contrib/fix-ChangeLog.sh

On 20/02/16 15:04, Tom de Vries wrote: Hi, this patch adds a script contrib/fix-ChangeLog.sh. It fixes whitespace issues, and shows ChangeLog lines that look suspicious. Using the script, I was able to find a stray changelog entry (removed in rr233583,

Re: New tests for PRs 52531 and 57365

Committed on trunk as revision r233588. Dominique > Le 15 févr. 2016 à 14:53, Dominique d'Humières a écrit : > > PRs 52531 and 57365 are fixed on trunk and gcc5 branch. Unless someone > objects I am planing to add the following tests in the coming days. > > Tested on

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531 --- Comment #12 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat Feb 20 14:10:55 2016 New Revision: 233588 URL: https://gcc.gnu.org/viewcvs?rev=233588=gcc=rev Log: 2016-02-20 Dominique d'Humieres PR

[Bug fortran/57365] [OOP] Sourced allocation fails with unlimited polymorphism

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57365 --- Comment #5 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat Feb 20 14:10:55 2016 New Revision: 233588 URL: https://gcc.gnu.org/viewcvs?rev=233588=gcc=rev Log: 2016-02-20 Dominique d'Humieres PR

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #59 from Dominique d'Humieres --- > We already warn about mismatches sizes at LTO link time Confirmed [Book15] f90/bug% gfc -c -O2 pr69368_a.f90 -flto [Book15] f90/bug% gfc -O2 pr69368_a.o pr69368_b.f90 -flto pr69368_a.f90:3:0:

[RFC] Add contrib/fix-ChangeLog.sh

Hi, this patch adds a script contrib/fix-ChangeLog.sh. It fixes whitespace issues, and shows ChangeLog lines that look suspicious. Using the script, I was able to find a stray changelog entry (removed in rr233583, https://gcc.gnu.org/viewcvs?rev=233583=gcc=rev ). And I've Any comments?

[PATCH 1/3] gdb.trace: Move more target dependencies to trace-support.exp

While groveling through the old PPC64 tracepoint support patch, I've noticed a few target dependencies in the testsuite that both me and Antoine missed for s390 and ARM tracepoints, respectively. This patch moves them all to one place, so that anyone working on a new target will hopefully see the

[PATCH 3/3] gdb.trace: Remove unnecessary target check from ftrace.exp.

The check used hardcoded targets and wasn't doing anything useful anyway, since unsupported architectures blow up on link due to missing the IPA library before they ever get to that check. gdb/testsuite/ChangeLog: * gdb.trace/ftrace.exp: Remove unnecessary target check. ---

[PATCH 2/3] gdb.trace: Surround $call_insn with \y in entry-values.exp

The PPC64 tracepoint patch added \y at the end of the call_insn pattern - without that, it embarassed itself and matched the 'bl' in "Dump of assem*bl*er code for function" as the powerpc call opcode. Since that sounds like a generally good idea, I've added \y before and after call_insn for every

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #11 from Bernd Edlinger --- (In reply to Jakub Jelinek from comment #10) > Why should libstdc++ try to workaround a bug in gmp.h? Just fix gmp.h... Yes, and probably it is already fixed with gmp-6.1.0, I did not check. I am trying

Re: [RFC] Formation of vector function name

2015-06-16 17:23 GMT+03:00 Joseph Myers : > On Mon, 15 Jun 2015, Andrew Pinski wrote: > >> > results in asm redirection for log to __log_finite and final vector >> > function name becomes _ZGVbN2v___log_finite. >> > >> > With point of view from C Library side, it reflects

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

[Bug tree-optimization/69882] [6 regression] Excessive reduction statements generated by SLP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69882 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: Wonly-top-basic-asm

On 20.02.2016 02:03, David Wohlferd wrote: > @example > -/* Note that this code will not compile with -masm=intel */ > -#define DebugBreak() asm("int $3") > +/* Define macro at file scope with basic asm. */ > +/* Add macro parameter p to eax. */ > +asm (".macro testme p\n\t" > +"addl $\\p,

[Bug tree-optimization/69882] New: [6 regression] Excessive reduction statements generated by SLP

ase emits wrong reduction statements. Compile: $ trunk/64/20160220/bin/gfortran -o repro -static -m64 -Ofast -mavx repro.f90 Execution ABORTs Works fine when compiled w/ -O0 Extract from vectorizer dump: : # k_239 = PHI <k.4_11(48), k_266(56)> # c_I_lsm.10_241 = PHI <c_I_lsm.10_48(

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #9 from Bernd Edlinger --- right now I am trying to boot-strap this: Index: c/cstddef === --- c/cstddef (revision 233581) +++ c/cstddef (working copy) @@ -31,10

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #8 from Bernd Edlinger --- BTW: the free-standing cstddef is also buggy: #define __need_size_t #define __need_ptrdiff_t #define __need_NULL #define __need_offsetof #include_next but GCC's stddef.h does not implement

Re: [PATCH][RFC][Offloading] Fix PR68463

On Fri, Feb 19, 2016 at 15:53:08 +0100, Jakub Jelinek wrote: > On Wed, Feb 10, 2016 at 08:19:34PM +0300, Ilya Verbin wrote: > > This patch adds crtoffload{begin,end}.o to all -fopenmp programs, if they > > exist. > > I couldn't think of a better solution... > > Tested using the testcase from the

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #7 from Bernd Edlinger --- Index: include/c_global/cstddef === --- include/c_global/cstddef(revision 233581) +++ include/c_global/cstddef(working copy) @@ -41,6

[Bug fortran/64324] Deferred character specific functions not permitted in generic operator interface

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64324 --- Comment #4 from Paul Thomas --- (In reply to Paul Thomas from comment #3) > Fixed on trunk. I will wait a few weeks before fixing on 5-branch. > > Paul This has been on hold awaiting a fix for PR69423 on trunk. It looks as if the wait is

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #6 from Bernd Edlinger --- (In reply to Jonathan Wakely from comment #4) > The patch seems wrong, your new sections don't add anything to namespace std. yes. I think probably cstddef is free to ignore __need_size_t. right? Then it

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #5 from Jonathan Wakely --- (In reply to Bernd Edlinger from comment #3) > or > > #undef all these __need_XXX before including stddef.h, > after all it is a bit bogus ghat gmp.h does: > > #define __need_size_t /* tell gcc

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #4 from Jonathan Wakely --- The patch seems wrong, your new sections don't add anything to namespace std.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881 --- Comment #3 from Bernd Edlinger --- or #undef all these __need_XXX before including stddef.h, after all it is a bit bogus ghat gmp.h does: #define __need_size_t /* tell gcc stddef.h we only want size_t */ #include /* for size_t */

Re: [PATCH, PR middle-end/68134] Reject scalar modes in default get_mask_mode hook

2016-02-19 20:36 GMT+03:00 Alan Lawrence : > On 17/11/15 11:49, Ilya Enkovich wrote: >> >> Hi, >> >> Default hook for get_mask_mode is supposed to return integer vector modes. >> This means it should reject calar modes returned by mode_for_vector. >> Bootstrapped and

Re: i386: add a variant peephole for decl (mem)

(please CC me on x86 specific patches) > PR 49095 requested the following optimization: [...] > * config/i386/i386.md (operation on memory peephole): Duplicate an > existing peephole and adapt it to match lea rather than an operation > that clobbers CC. OK for mainline and release branches

[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806 --- Comment #10 from Oleg Endo --- (In reply to Jakub Jelinek from comment #9) > Please see PR69671 then, that CSE change is right, so you really need to > find some solution at the backend side. Look what fwprop* dumps show etc. I've checked

Re: [PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align

Martin Sebor writes: > +in bits (not bytes). @var{size} must be positive and not exceed the stack > +size limit. @var{align} must be a constant integer expression that Don't use a lowercase word at the start of a sentence. > +The @code{__builtin_alloca_with_align} function