[Bug c++/69571] [C++11] invalid alignas on a typedef accepted, reduces alignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69571 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug bootstrap/81995] [8.0 Regression] gcc/reg-stack.c:2073:1: error: unrecognizable insn:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81995 Gerald Pfeifer changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #1

Re: [PATCH, i386]: Use btr/bts/btc some more (PR target/46091)

On Sun, 27 Aug 2017, Gerald Pfeifer wrote: >> 2017-08-21 Uros Bizjak >> >> PR target/46091 >> * config/i386/i386.md (*btsq_imm): Rename from *btsq. >> (*btrq_imm): Rename from *btrq. >> (*btcq_imm): Rename from *btcq. >> (btsc): New code attribute. >>

Re: Quantitative analysis of -Os vs -O3

FYI - I’ve updated the stats to include -O2 in addition to -O3 and -Os: - https://rv8.io/bench#optimisation There are 57 plots and 31 tables. It’s quite a bit of data. It will be quite interesting to run these on new gcc releases to monitor changes. The Geomean for -O2 is 0.98 of -O3 on

Re: [PATCH, i386]: Use btr/bts/btc some more (PR target/46091)

On Mon, 21 Aug 2017, Uros Bizjak wrote: > 2017-08-21 Uros Bizjak > > PR target/46091 > * config/i386/i386.md (*btsq_imm): Rename from *btsq. > (*btrq_imm): Rename from *btrq. > (*btcq_imm): Rename from *btcq. > (btsc): New code attribute. > (*): New

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #10 from Jack Howarth --- I managed to reproduce this issue on an 8 core non-HT system booted from an APFS volume on an old SATA2 HDD so the issue doesn't seem to be dependent on really fast IO... Making all in include mkdir -p

[Bug bootstrap/81995] New: [8.0 Regression] gcc/reg-stack.c:2073:1: error: unrecognizable insn:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81995 Bug ID: 81995 Summary: [8.0 Regression] gcc/reg-stack.c:2073:1: error: unrecognizable insn: Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal

Re: [patch, libgfortran] PR78387 OpenMP segfault/stack size exceeded writing to internal file

ping - I will commit if I hear no objections. Jerry On 08/19/2017 10:12 PM, Jerry DeLisle wrote: > Hi all, > > I have decided to simply delete the internal unit stack altogether. > > The original intent was to save time with internal unit I/O by avoiding > reallocating a gfc_unit structure

Re: [patch, fortran] Fix regression with inline matmul

On 08/26/2017 11:24 AM, Thomas Koenig wrote: > Hello world, > > to relieve the boredom on the fortran mailing list and to fix > a regression I thought I'd submit a patch :-) > > Apparently, a call to CONJG wasn't picking up the right > typespec, which led to an ICE with gimplification later. >

[Bug c/81994] New: [C++11]Internal error: same_comdat_group list across different groups

elo de hilos: posix gcc versión 5.4.0-pre 20170826 (Gentoo 5.4.0_pre) With this configuration the code works: /var/tmp/portage/sys-devel/gcc-5.4.0_pre/work/gcc-5.4.0-/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linu

[patch, fortran] Fix regression with inline matmul

Hello world, to relieve the boredom on the fortran mailing list and to fix a regression I thought I'd submit a patch :-) Apparently, a call to CONJG wasn't picking up the right typespec, which led to an ICE with gimplification later. Regression-tested. OK for trunk? Regards Thomas

Re: Regression with gcc 7.2 ? Undefined references ?

On 26/08/2017 17:56, Markus Trippelsdorf wrote: > On 2017.08.26 at 17:18 +0200, Sylvestre Ledru wrote: >> >> On 26/08/2017 13:10, Markus Trippelsdorf wrote: >>> On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote: Hello, I have been trying to build the llvm toolchain with gcc 7.2

[Bug debug/81993] New: gcc 7.X -gsplit-dwarf removes some symbols, causing some undefined references

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81993 Bug ID: 81993 Summary: gcc 7.X -gsplit-dwarf removes some symbols, causing some undefined references Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity:

[Bug target/81988] [7/8 Regression] sparc64: emits STD instruction with odd register

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81988 --- Comment #2 from Mikael Pettersson --- Started with r244034, i.e. when SPARC switched to LRA by default. -mno-lra works around it.

Re: Regression with gcc 7.2 ? Undefined references ?

On 2017.08.26 at 17:18 +0200, Sylvestre Ledru wrote: > > > On 26/08/2017 13:10, Markus Trippelsdorf wrote: > > On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote: > >> Hello, > >> > >> I have been trying to build the llvm toolchain with gcc 7.2 using the > >> Debian packages. > >> However, it

[Bug c++/81992] New: C++ toupper symbol clash?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81992 Bug ID: 81992 Summary: C++ toupper symbol clash? Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

Re: Regression with gcc 7.2 ? Undefined references ?

On 26/08/2017 13:10, Markus Trippelsdorf wrote: > On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote: >> Hello, >> >> I have been trying to build the llvm toolchain with gcc 7.2 using the >> Debian packages. >> However, it is currently failing with some undefined reference. >> Seems that some

[Bug c++/70328] default generated destructors cause 'inlining failed' warnings.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70328 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug fortran/81974] [8 Regression] ICE verify_gimple failed type mismatch in binary expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81974 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

Re: Quantitative analysis of -Os vs -O3

On Samstag, 26. August 2017 12:59:06 CEST Markus Trippelsdorf wrote: > On 2017.08.26 at 12:40 +0200, Allan Sandfeld Jensen wrote: > > On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote: > > > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > > > First let me put into some

[Bug c++/70328] default generated destructors cause 'inlining failed' warnings.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70328 --- Comment #3 from Morwenn --- Looks like providing a testcase will be hard: I switched to GCC 7.1 since then, and can't reproduce the bug anymore, be it in C++14 or C++17 mode. That said, a few things have changed since then and they may be

Re: Regression with gcc 7.2 ? Undefined references ?

On 2017.08.26 at 13:04 +0200, Sylvestre Ledru wrote: > Hello, > > I have been trying to build the llvm toolchain with gcc 7.2 using the > Debian packages. > However, it is currently failing with some undefined reference. > Seems that some symbols are removed during the build phase (too strong >

Regression with gcc 7.2 ? Undefined references ?

Hello, I have been trying to build the llvm toolchain with gcc 7.2 using the Debian packages. However, it is currently failing with some undefined reference. Seems that some symbols are removed during the build phase (too strong optim?) I haven't seen something relevant to this in the gcc

Re: Quantitative analysis of -Os vs -O3

On 2017.08.26 at 12:40 +0200, Allan Sandfeld Jensen wrote: > On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote: > > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > > First let me put into some perspective on -Os usage and some history: > > > 1) -Os is not useful for

Re: Quantitative analysis of -Os vs -O3

On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote: > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > First let me put into some perspective on -Os usage and some history: > > 1) -Os is not useful for non-embedded users > > 2) the embedded folks really need the smallest

[Bug driver/81829] [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81829 --- Comment #3 from Xi Ruoyao --- marxin's patch: http://gcc.gnu.org/ml/gcc-patches/2017-08/msg01116.html But this patch doesn't work while /my_bin/bin contains a symlink.

Re: Quantitative analysis of -Os vs -O3

> On 26 Aug 2017, at 8:39 PM, Andrew Pinski wrote: > > On Sat, Aug 26, 2017 at 1:23 AM, Michael Clark wrote: >> Dear GCC folk, >> I have to say that’s GCC’s -Os caught me by surprise after several years >> using Apple GCC and more recently LLVM/Clang

RE: Quantitative analysis of -Os vs -O3

> 4) -Os is used heavily by the arm/thumb2 folks in bare metal applications. Also by the x86 in bare-mental firmware, e.g. http://www.uefi.org/ > For many applications using -flto does reduce code size more than just > going from -O2 to -Os. Yes. -flto is must to have, but the -Os is still

Re: Quantitative analysis of -Os vs -O3

On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > First let me put into some perspective on -Os usage and some history: > 1) -Os is not useful for non-embedded users > 2) the embedded folks really need the smallest code possible and > usually will be willing to afford the performance hit >

Re: Quantitative analysis of -Os vs -O3

On Sat, Aug 26, 2017 at 1:23 AM, Michael Clark wrote: > Dear GCC folk, > I have to say that’s GCC’s -Os caught me by surprise after several years > using Apple GCC and more recently LLVM/Clang in Xcode. Over the last year and > a half I have been working on RISC-V

[Bug debug/81936] ICE in dwarf2out_die_ref_for_decl, at dwarf2out.c:5543

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81936 --- Comment #20 from Tom de Vries --- (In reply to Richard Biener from comment #19) > Fixed. Thanks for fixing this. libgomp with nvptx offloading is back to known fails: ... # of unexpected failures24 # of expected passes

Quantitative analysis of -Os vs -O3

Dear GCC folk, I have to say that’s GCC’s -Os caught me by surprise after several years using Apple GCC and more recently LLVM/Clang in Xcode. Over the last year and a half I have been working on RISC-V development and have been exclusively using GCC for RISC-V builds, and initially I was

[Bug other/78889] GCC fails to build due to graphite-dependences.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78889 --- Comment #2 from Martin Jossic --- Hello ! Sorry for the late answer but I finally found a solution. Thanks for your help !

[Bug driver/81991] gcc-ar segfaults if we run it with the full path

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81991 --- Comment #2 from Xi Ruoyao --- > --- Comment #1 from Andrew Pinski --- > Dup. > Oh. Only searched with term gcc-ar and didn't find PR81829.

[Bug driver/81829] [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81829 Andrew Pinski changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn ---

[Bug driver/81991] gcc-ar segfaults if we run it with the full path

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81991 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/69433] missing -Wreturn-local-addr assigning address of a local to a static

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69433 --- Comment #4 from Andrew Pinski --- >IMO we should look into why this optimization doesn't happen before PRE (why >not FRE for instance?). Because the reads from s are only partially redundant (PRE) and not fully (vs FRE). :)

[Bug driver/81991] New: gcc-ar segfaults if we run it with the full path

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81991 Bug ID: 81991 Summary: gcc-ar segfaults if we run it with the full path Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/69433] missing -Wreturn-local-addr assigning address of a local to a static

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69433 --- Comment #3 from Marc Glisse --- f3: the inliner silently removes s (and the assignment to it) as write-only. You need to add a function that reads s (we don't warn in that case either, of course, but that's a first step). f2: the (atomic)

Re: [PATCH] Fix PR81921

On August 26, 2017 12:51:57 AM GMT+02:00, Joseph Myers wrote: >I'm seeing a build failure for s390x-linux-gnu that looks like it could >be >related to this change (build was OK at r251332, failed at r251358). Can you please open a bug? Can you confirm it fails the same