[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[eb at emlix dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #14 from Rolf Eike Beer  ---
See https://bugreports.qt.io/browse/QTBUG-74196

That's how I found this at all: the latest current releases don't build
together. And I guess that most projects that somehow are descendants of KJS
will be affected, as seen here: https://bugs.gentoo.org/679330

The other thing is: given that 8.3 does not show a diagnostic message that is
at least remotely helpful this looks for any end user just like a compiler bug.
I hope gcc 9 will say what it doesn't like, and maybe even suggest a fixit. For
8.x I would very much welcome that it just works as before, maybe with a clear
error message.

[Bug c/89569] line number is not accurate on large file with more than UINT32_MAX actual lines

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89569

--- Comment #2 from Jonathan Wakely  ---
Why would 3 be the expected value? Line numbers are natural numbers, not
uint32.

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952

--- Comment #19 from Martin Liška  ---
Ok, I updated the benchmark and push it here:
https://github.com/marxin/microbenchmark-1

And I see following on my Haswell machine:

$ ./test.py 
 normal   retpolineretpo+no-JT  retpo+JT=20  retpo+JT=40
cases:8: 0.34 (100%)  1.80 (529%)  0.39 (114%)  0.39 (115%)  0.39 (115%) 
cases:   16: 0.33 (100%)  1.77 (541%)  0.51 (156%)  0.51 (157%)  0.51 (157%) 
cases:   32: 1.01 (100%)  1.82 (179%)  0.57 ( 56%)  1.82 (179%)  0.54 ( 54%) 
cases:   64: 0.78 (100%)  1.76 (225%)  0.58 ( 74%)  1.76 (225%)  1.75 (224%) 
cases:  128: 0.34 (100%)  1.94 (577%)  0.64 (191%)  1.93 (574%)  1.93 (573%) 
cases:  256: 0.34 (100%)  1.94 (579%)  0.76 (225%)  1.95 (581%)  1.94 (580%) 
cases: 1024: 1.21 (100%)  2.00 (166%)  0.97 ( 80%)  2.00 (165%)  2.00 (166%) 
cases: 2048: 1.48 (100%)  2.03 (137%)  2.06 (139%)  2.01 (136%)  2.00 (135%) 
cases: 4096: 1.67 (100%)  2.09 (125%)  3.78 (226%)  2.10 (126%)  2.20 (132%) 

From the number I see recommend to disable jump tables with
-mindirect-branch=*.
Thoughts?

[Bug c++/89538] [8.3.0] GCC miscompiling LLVM because of wrong vectorization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
(In reply to Taewook Oh from comment #7)
> I'm Sorry I was confused about our internal gcc version, and it turns out
> that the version was 8.3 not 7.3.
> 
> I downloaded latest 8.3 source and tried it but couldn't repro the problem.
> Is there a chance that the bug is fixed after the release? Our internal
> version suggests that it is based on 8.3 around 20180827.

THat is even more confusing, because gcc 8.2.0 has been released on 2018-07-26,
then the snapshots would declare themselves as 8.2.1, gcc 8.3.0 has been
released on 2019-02-22 and then the snapshots would become 8.3.1.  So, 8.3
based snapshot from 20180827 is not possible.

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[steve at sk2 dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568

--- Comment #17 from Stephen Kitt  ---
Thanks for the fix Jakub, I’ve verified it on Qt and Andre Heinecke has
verified it on Gpg4Win  (see https://bugs.debian.org/923214 for details).

jon_y, you can have your weekend back ;-).

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568

--- Comment #18 from Jakub Jelinek  ---
(In reply to Stephen Kitt from comment #17)
> Thanks for the fix Jakub, I’ve verified it on Qt and Andre Heinecke has
> verified it on Gpg4Win  (see https://bugs.debian.org/923214 for details).

Thanks.

> jon_y, you can have your weekend back ;-).

Well, it should be tested also with a GCC bootstrap/regtest, that is a usual
procedure for testing GCC changes.

[Bug tree-optimization/14721] jump optimization involving a sibling call within a jump table

[steven at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14721

Steven Bosscher  changed:

   What|Removed |Added

   Last reconfirmed|2006-03-05 03:52:08 |2019-3-6
 CC||marxin at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
  Build|pessimizes-code |

--- Comment #3 from Steven Bosscher  ---
Maybe something for tree-switch-conversion?

[Bug c++/89538] [8.3.0] GCC miscompiling LLVM because of wrong vectorization

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538

--- Comment #9 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Taewook Oh from comment #7)
> > I'm Sorry I was confused about our internal gcc version, and it turns out
> > that the version was 8.3 not 7.3.
> > 
> > I downloaded latest 8.3 source and tried it but couldn't repro the problem.
> > Is there a chance that the bug is fixed after the release? Our internal
> > version suggests that it is based on 8.3 around 20180827.
> 
> THat is even more confusing, because gcc 8.2.0 has been released on
> 2018-07-26, then the snapshots would declare themselves as 8.2.1, gcc 8.3.0
> has been released on 2019-02-22 and then the snapshots would become 8.3.1. 
> So, 8.3 based snapshot from 20180827 is not possible.

I can only confirm that:

commit 75a99965334c6932d813ef3cf536a085901ec7e7 (HEAD)
Author: gccadmin 
Date:   Wed Feb 27 00:16:31 2019 +

Daily bump.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-8-branch@269238
138bc75d-0d04-0410-961f-82ee72b054a4

can't expose the vectorization.

As Jakub said, please try to build vanilla GCC and provide which revision you
used to reproduce the problem.

[Bug other/16996] [meta-bug] code size improvements

[steven at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996
Bug 16996 depends on bug 24647, which changed state.

Bug 24647 Summary: two copies of a constant in two different registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24647

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug fortran/89603] New: unclassifiable statement error in code that is ok in compaq visual fortran

[yumashev at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89603

Bug ID: 89603
   Summary: unclassifiable statement error in code that is ok in
compaq visual fortran
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yumashev at mail dot ru
  Target Milestone: ---

Small source code example "test.f90" giving "unclassifiable statement" error

module drglob
 implicit none
  type vartype1
   double precision :: mu
   double precision :: inc
  end type vartype1
 type(vartype1), allocatable :: cm(:)
end module drglob

module drut
 use drglob
 implicit none
 contains

subroutine initial
 allocate (cm(5))
 cm(1).mu=2.8d-2
 cm(1).inc=7.5527d-1
end subroutine initial

end module drut

program main
 use drglob
 use drut
 call initial
end program main  

Compilation on OpenSUSE 11.3, 12.3: gfortran test.f90
(gfortran versions from 4.3 to 4.7 make no difference)

test.f90:17.9:

 cm(1).mu=2.8d-2
1
Error: Unclassifiable statement at (1)
test.f90:18.9:

 cm(1).inc=7.5527d-1
1
Error: Unclassifiable statement at (1)
test.f90:25.17:

 use drut
1
Fatal Error: Can't open module file 'drut.mod' for reading at (1): No such file
or directory

This code normally compiles and runs in Compaq visual fortran on XP platform
but I strongly prefer Linux !

[Bug target/24647] two copies of a constant in two different registers

[steven at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24647

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||steven at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from Steven Bosscher  ---
Trunk today:

f():
movlf()::i, %eax
testl   %eax, %eax
jne .L1 # or je for the != case
movl$2, f()::i
movl$2, %eax
.L1:
ret

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[steve at sk2 dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568

--- Comment #19 from Stephen Kitt  ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Stephen Kitt from comment #17)
> > jon_y, you can have your weekend back ;-).
> 
> Well, it should be tested also with a GCC bootstrap/regtest, that is a usual
> procedure for testing GCC changes.

Ah, right, of course. I’ve run a cross-bootstrap, but not a bootstrap on
Windows, nor have I run the test suite on Windows.

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568

--- Comment #20 from Jakub Jelinek  ---
(In reply to Stephen Kitt from comment #19)
> (In reply to Jakub Jelinek from comment #18)
> > (In reply to Stephen Kitt from comment #17)
> > > jon_y, you can have your weekend back ;-).
> > 
> > Well, it should be tested also with a GCC bootstrap/regtest, that is a usual
> > procedure for testing GCC changes.
> 
> Ah, right, of course. I’ve run a cross-bootstrap, but not a bootstrap on
> Windows, nor have I run the test suite on Windows.

Cross compilers don't bootstrap (build themselves multiple times), only build.
Sure, I have built a cross compiler to write and verify this change too, but I
have no access to Windows to bootstrap/regtest it natively.  As I said on
gcc-patches, it is highly unlikely it will regress something, because if it
doesn't crash in the newly added condition, then it partially reverts to the
January state.

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[steve at sk2 dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568

--- Comment #21 from Stephen Kitt  ---
(In reply to Jakub Jelinek from comment #20)
> Cross compilers don't bootstrap (build themselves multiple times), only
> build.

Sorry, I meant I did a library-less cross-build, followed by a MinGW-w64 build
using the new compiler, followed by a full cross-build. Obviously that’s
nowhere near as useful as a native build on Windows.

> Sure, I have built a cross compiler to write and verify this change too, but
> I have no access to Windows to bootstrap/regtest it natively.  As I said on
> gcc-patches, it is highly unlikely it will regress something, because if it
> doesn't crash in the newly added condition, then it partially reverts to the
> January state.

Yes, it does seem highly unlikely.

(Now I get to chase down another GCC 7-to-8 regression in SEH. Well, this
evening...)

[Bug middle-end/42972] Very bad bit field code

[steven at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42972

Steven Bosscher  changed:

   What|Removed |Added

   Last reconfirmed|2012-03-18 12:45:53 |2019-3-6

--- Comment #7 from Steven Bosscher  ---
GCC 8.2 (still -march=armv5te -O3):

.arch armv5te
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file   "example.c"
.text
.align  2
.global func
.syntax unified
.arm
.fpu softvfp
.type   func, %function
func:
mov ip, #0
.L9:
ldrbr3, [r0]@ zero_extendqisi2
add ip, ip, #1
tst r3, #1
beq .L16
str lr, [sp, #-4]!
.L10:
ldr r3, [r0]
add lr, r2, r3, lsr #1
and r3, r3, #1
orr r3, r3, lr, lsl #1
str r3, [r0]
.L2:
cmp ip, r1
add r0, r0, #4
ldrge   pc, [sp], #4
ldrbr3, [r0]@ zero_extendqisi2
add ip, ip, #1
tst r3, #1
beq .L2
b   .L10
.L16:
cmp ip, r1
add r0, r0, #4
blt .L9
bx  lr
.size   func, .-func
.ident  "GCC: (GNU) 8.2.0"
.section.note.GNU-stack,"",%progbits

[Bug fortran/89603] unclassifiable statement error in code that is ok in compaq visual fortran

[steven at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89603

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||steven at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Steven Bosscher  ---
Your code is not standard-conforming. Do this:

 cm(1)%mu=2.8d-2
 cm(1)%inc=7.5527d-1

and you have standard-conforming Fortran.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #15 from Segher Boessenkool  ---
(In reply to Rolf Eike Beer from comment #14)

> The other thing is: given that 8.3 does not show a diagnostic message that
> is at least remotely helpful this looks for any end user just like a
> compiler bug.

Don't exaggerate please.  It gives exactly the same error as when you would
say "asm double" or similar.  It is perfectly clear: the "volatile" there
was not expected, it is a programming mistake, it has no meaning.

How do you expect "end users" who have no idea what they are doing to compile
anything ever?

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #16 from Harald van Dijk  ---
(In reply to Segher Boessenkool from comment #15)

Please stop with the unnecessary and unhelpful insults. This is the second time
I've had to ask you that.

[Bug tree-optimization/14721] jump optimization involving a sibling call within a jump table

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14721

--- Comment #4 from Martin Liška  ---
(In reply to Steven Bosscher from comment #3)
> Maybe something for tree-switch-conversion?

Yes, would be possible to implement, but I'm not fully convinced it's a common
pattern that happens in switch statements :)

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #17 from Segher Boessenkool  ---
Hello Harald,

Yes, that is what I would like you guys to do.  But I'll stop working
on this now, that is fine as well.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[eb at emlix dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #18 from Rolf Eike Beer  ---
I would have expected something that is more like the error message in this
case:

class foo {
  static void bar() const;
};

error: static member function ‘static void foo::bar()’ cannot have cv-qualifier

[Bug driver/89604] New: Type conversion from signed char to a wider integer generates wrong assembly for ARM,

[christalization at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604

Bug ID: 89604
   Summary: Type conversion from signed char to a wider integer
generates wrong assembly for ARM,
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christalization at gmail dot com
  Target Milestone: ---

Created attachment 45902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45902&action=edit
Preprocessed file

So I've stumbled upon this bug when compiling a project on the Raspberry pi.
I created a barebone test project to verify that nothing else was causing it,
and indeed, I got the same result.

What happens is that when you're converting a signed char type to a signed
integer, the conversion fails to move the sign bit, instead it just extends the
bits like it would with an unsigned conversion.
I've verified that this does not happen on x86/64 builds so it appears to be
specific for ARM builds. Compiling exactly the same piece of code on Windows
yields the correct result:

int main()
{
char c = -40;
double s = c;
printf("%f", s);
return 0;
}

Windows: -40
Raspbian: 226

226 is what you get when interpreting the bits of the char as unsigned.
I got around the problem for now by explicitly moving the sign bit as such:
((int)c & ~0x80) | ~0x7FFF

Here is the compiler output along with the commandline arguments:

g++ -v -save-temps test.cpp -o test
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian
6.3.0-18+rpi1+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=arm-linux-gnueabihf- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-shared-libgcc'
'-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' '-mtls-dialect=gnu'
 /usr/lib/gcc/arm-linux-gnueabihf/6/cc1plus -E -quiet -v -imultilib .
-imultiarch arm-linux-gnueabihf -D_GNU_SOURCE test.cpp -march=armv6
-mfloat-abi=hard -mfpu=vfp -mtls-dialect=gnu -fpch-preprocess -o test.ii
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf/c++/6"
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/6
 /usr/include/arm-linux-gnueabihf/c++/6
 /usr/include/c++/6/backward
 /usr/lib/gcc/arm-linux-gnueabihf/6/include
 /usr/local/include
 /usr/lib/gcc/arm-linux-gnueabihf/6/include-fixed
 /usr/include/arm-linux-gnueabihf
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-shared-libgcc'
'-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' '-mtls-dialect=gnu'
 /usr/lib/gcc/arm-linux-gnueabihf/6/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -march=armv6 -mfloat-abi=hard -mfpu=vfp -mtls-dialect=gnu
-auxbase test -version -o test.s
GNU C++14 (Raspbian 6.3.0-18+rpi1+deb9u1) version 6.3.0 20170516
(arm-linux-gnueabihf)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=93 --param ggc-min-heapsize=118680
GNU C++14 (Raspbian 6.3.0-18+rpi1+deb9u1) version 6.3.0 20170516
(arm-linux-gnueabihf)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=93 --param ggc-min-heapsize=118680
Compiler executable checksum: 79dca666fccaa96025c9107a8b3f60f3
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test' '-shared-libgcc'
'-march=armv6' '-mfloat-abi=hard' '

[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|driver  |target
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
char is unsigned on arm.  This is documented in the ARM ABI as documented here:
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Characters-implementation.html#Characters-implementation

[Bug target/88530] [8 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530

--- Comment #8 from Tamar Christina  ---
Author: tnfchris
Date: Wed Mar  6 09:34:04 2019
New Revision: 269412

URL: https://gcc.gnu.org/viewcvs?rev=269412&root=gcc&view=rev
Log:
AArch64: Have empty HWCAPs string ignored during native feature detection.

This patch makes the feature detection code for AArch64 GCC not add features
automatically when the feature had no hwcaps string to match against.

This means that -mcpu=native no longer adds feature flags such as +profile.
The behavior wasn't noticed before because at the time +profile was added a bug
was preventing any feature bits from being added by native detections.

The loop has also been changed as Jakub specified in order to avoid a memory
leak that was present in the existing code and to be slightly more efficient.

gcc/ChangeLog:

Backport from trunk.
2019-02-28  Tamar Christina  

PR target/88530
* config/aarch64/aarch64-option-extensions.def: Document it.
* config/aarch64/driver-aarch64.c (host_detect_local_cpu): Skip feature
if empty hwcaps.

gcc/testsuite/ChangeLog:

Backport from trunk.
2019-02-28  Tamar Christina  

PR target/88530
* gcc.target/aarch64/options_set_10.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_10.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/aarch64/aarch64-option-extensions.def
branches/gcc-8-branch/gcc/config/aarch64/driver-aarch64.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #19 from Jakub Jelinek  ---
Created attachment 45903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45903&action=edit
gcc9-pr89585.patch

Untested patch for better diagnostics of this in GCC 9, for GCC 8 we could just
not diagnose volatile and ignore it.

Now, looking at documentation, I'd say that the C parser didn't match the
documentation and the C++ parser did (and no longer does), because we said that
volatile is optional on Basic Asm, volatile and goto are allowed on Extended
Asm, that at toplevel only Basic Asm is allowed and for Basic Asm:
"The optional volatile qualifier has no effect.
All basic asm blocks are implicitly volatile."

To me that looks like a strong reason to at least accept it again in 8.x, it
wasn't any kind of unspecified behavior, it was documented to be ignored.
And perhaps we could reconsider this even for GCC 9 and allow and ignore even
in C at toplevel.

[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604

--- Comment #2 from Andrew Pinski  ---
In C, plain char can either be signed or unsigned; this is unlike int.

Which of signed char or unsigned char has the same range, representation, and
behavior as “plain” char (C90 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and
C11 6.3.1.1).

[Bug fortran/89601] [8/9 Regression] ICE: Segmentation fault (in resolve_component)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.4
Summary|ICE: Segmentation fault (in |[8/9 Regression] ICE:
   |resolve_component)  |Segmentation fault (in
   ||resolve_component)

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89598

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[daniel at iogearbox dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952

--- Comment #20 from Daniel Borkmann  ---
(In reply to Martin Liška from comment #19)
> Ok, I updated the benchmark and push it here:
> https://github.com/marxin/microbenchmark-1
> 
> And I see following on my Haswell machine:

Thanks for working on it! Bit strange why some of your numbers are quite
fluctuating e.g. in your 'normal' column. What do you use to tune your setup
for testing? I've been running the `make prep` part which I added back then,
and the numbers I see are quite stable. I ran a quick test this morning with
your repo, and here's what I got for the round-robin walk:

* Xeon E3-1240 (3.7GHz):

# ./test.py 
 normal   retpolineretpo+no-JT  retpo+JT=20  retpo+JT=40
cases:8: 0.49 (100%)  2.09 (426%)  0.53 (108%)  0.53 (108%)  0.53 (108%) 
cases:   16: 0.49 (100%)  2.09 (426%)  0.58 (119%)  0.58 (119%)  0.58 (119%) 
cases:   32: 0.49 (100%)  2.09 (426%)  0.61 (125%)  2.09 (426%)  0.61 (125%) 
cases:   64: 0.49 (100%)  2.26 (458%)  0.69 (140%)  2.27 (459%)  2.27 (459%) 
cases:  128: 0.50 (100%)  2.37 (476%)  0.76 (153%)  2.32 (466%)  2.41 (483%) 
cases:  256: 0.52 (100%)  2.33 (451%)  0.91 (175%)  2.33 (450%)  2.36 (456%) 
cases: 1024: 1.05 (100%)  2.54 (242%)  1.08 (103%)  2.59 (246%)  2.54 (242%) 
cases: 2048: 1.63 (100%)  2.56 (157%)  1.94 (119%)  2.61 (160%)  2.59 (159%) 
cases: 4096: 2.19 (100%)  3.12 (143%)  3.22 (147%)  3.09 (142%)  3.13 (143%) 

* Xeon Gold 5120 (2.6GHz):

# ./test.py 
 normal   retpolineretpo+no-JT  retpo+JT=20  retpo+JT=40
cases:8: 0.70 (100%)  2.98 (425%)  0.75 (107%)  0.75 (107%)  0.75 (107%) 
cases:   16: 0.70 (100%)  2.98 (425%)  0.82 (117%)  0.82 (117%)  0.82 (117%) 
cases:   32: 0.70 (100%)  3.01 (430%)  0.87 (124%)  2.98 (426%)  0.87 (124%) 
cases:   64: 0.70 (100%)  3.52 (501%)  0.94 (134%)  3.52 (501%)  3.52 (501%) 
cases:  128: 0.71 (100%)  3.51 (495%)  1.07 (151%)  3.50 (495%)  3.50 (494%) 
cases:  256: 0.76 (100%)  3.14 (414%)  1.27 (167%)  3.14 (414%)  3.14 (414%) 
cases: 1024: 1.46 (100%)  3.36 (230%)  1.49 (102%)  3.36 (230%)  3.36 (230%) 
cases: 2048: 2.25 (100%)  3.19 (142%)  2.70 (120%)  3.19 (142%)  3.19 (142%) 
cases: 4096: 2.90 (100%)  3.74 (129%)  4.48 (155%)  3.73 (129%)  3.72 (129%) 

Probably makes sense to also add other walk tests aka input distributions for
foo{,_no_table,_no_retpol}() for further comparison if plan would be to
disable jump tables entirely.

[Bug target/88530] [8 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530

--- Comment #9 from Tamar Christina  ---
Author: tnfchris
Date: Wed Mar  6 09:49:00 2019
New Revision: 269413

URL: https://gcc.gnu.org/viewcvs?rev=269413&root=gcc&view=rev
Log:
AArch64: Fix command line options canonicalization version.

Commandline options on AArch64 don't get canonicalized into the smallest
possible set before output to the assembler. This means that overlapping
feature
sets are emitted with superfluous parts.

Normally this isn't an issue, but in the case of crypto we have retro-actively
split it into aes and sha2. We need to emit only +crypto to the assembler
so old assemblers continue to work.

Because of how -mcpu=native and -march=native work they end up enabling all
feature bits. Instead we need to get the smallest possible set, which would
also
fix the problem with older the assemblers and the retro-active split.

The function that handles this is called quite often.  It is called for any
push/pop options or attribute that changes arch, cpu etc.  In order to not make
this search for the smallest set too expensive we sort the options based on the
number of features (bits) they enable.  This allows us to process the list
linearly instead of quadratically (Once we have enabled a feature, we know that
anything else that enables it can be ignored.  By sorting we'll get the biggest
groups first and thus the smallest combination of commandline flags).

The Option handling structures have been extended to have a boolean to indicate
whether the option is synthetic, with that I mean if the option flag itself
enables a new feature.

e.g. +crypto isn't an actual feature, it just enables other features, but
others
like +rdma enable multiple dependent features but is itself also a feature.

There are two ways to solve this.

1) Either have the options that are feature bits also turn themselves on, e.g.
   change rdma to turn on FP, SIMD and RDMA as dependency bits.

2) Make a distinction between these two different type of features and have the
   framework handle it correctly.

Even though it's more code I went for the second approach, as it's the one
that'll be less fragile (people can't forget it) and gives the least surprises.

Effectively this patch changes the following:

The values before the => are the old compiler and after the => the new code.

-march=armv8.2-a+crypto+sha2 => -march=armv8.2-a+crypto
-march=armv8.2-a+sha2+aes => -march=armv8.2-a+crypto

The remaining behaviors stay the same.

gcc/ChangeLog:

Backport from trunk.
2019-02-25  Tamar Christina  

PR target/88530
* common/config/aarch64/aarch64-common.c
(struct aarch64_option_extension): Add is_synthetic.
(all_extensions): Use it.
(TARGET_OPTION_INIT_STRUCT): Define hook.
(struct gcc_targetm_common): Moved to end.
(all_extensions_by_on): New.
(opt_ext_cmp, typedef opt_ext): New.
(aarch64_option_init_struct): New.
(aarch64_contains_opt): New.
(aarch64_get_extension_string_for_isa_flags): Output smallest set.
* config/aarch64/aarch64-option-extensions.def
(AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto.
(fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3,
sm4, fp16fml, sve):
Set is_synthetic to false.
(crypto): Set is_synthetic to true.
* config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Add
SYNTHETIC.

gcc/testsuite/ChangeLog:

Backport from trunk.
2019-02-25  Tamar Christina  

PR target/88530
* gcc.target/aarch64/options_set_1.c: New test.
* gcc.target/aarch64/options_set_2.c: New test.
* gcc.target/aarch64/options_set_3.c: New test.
* gcc.target/aarch64/options_set_4.c: New test.
* gcc.target/aarch64/options_set_5.c: New test.
* gcc.target/aarch64/options_set_6.c: New test.
* gcc.target/aarch64/options_set_7.c: New test.
* gcc.target/aarch64/options_set_8.c: New test.
* gcc.target/aarch64/options_set_9.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_1.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_2.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_3.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_4.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_5.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_6.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_7.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_8.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/options_set_9.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/common/config/aarch64/aarch64-common.c
branches/gcc-8-branch/gcc/config/aarch64/aarch64-option-extensions.d

[Bug target/88530] [8 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530

Tamar Christina  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Tamar Christina  ---
Backport committed.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #20 from Harald van Dijk  ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 45903 [details]
> gcc9-pr89585.patch

Thanks. I'll test this on GCC 8, with trivial changes to accept asm volatile,
when I get back home.

[Bug gcov-profile/89577] In the manual, replace -fprofile-arcs -ftest-coverage by the simpler --coverage

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89577

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Wed Mar  6 10:01:16 2019
New Revision: 269415

URL: https://gcc.gnu.org/viewcvs?rev=269415&root=gcc&view=rev
Log:
Use --coverage instead of -fprofile-arcs -ftest-coverage in documentation (PR
gcov-profile/89577).

2019-03-06  Martin Liska  

PR gcov-profile/89577
* doc/gcov.texi: Prefer to use --coverage.
* doc/sourcebuild.texi: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi
trunk/gcc/doc/sourcebuild.texi

[Bug gcov-profile/89577] In the manual, replace -fprofile-arcs -ftest-coverage by the simpler --coverage

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89577

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug middle-end/89551] [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails after r269302

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89551

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Mar  6 10:13:08 2019
New Revision: 269416

URL: https://gcc.gnu.org/viewcvs?rev=269416&root=gcc&view=rev
Log:
2019-03-06  Richard Biener  

PR testsuite/89551
* gcc.dg/uninit-pred-8_b.c: Force logical-op-non-short-circuit
the way that makes the testcase PASS.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/uninit-pred-8_b.c

[Bug middle-end/89551] [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails after r269302

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89551

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
Bug 89497 depends on bug 89551, which changed state.

Bug 89551 Summary: [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails 
after r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89551

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 89551, which changed state.

Bug 89551 Summary: [9 regression] Test case gcc.dg/uninit-pred-8_b.c fails 
after r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89551

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #21 from Jakub Jelinek  ---
Created attachment 45904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45904&action=edit
gcc8-pr89585.patch

The 8.x version would be like this.

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89592

--- Comment #6 from Richard Biener  ---
I think it only makes sense to pass aggregates with a flexarray member by
reference and pass the return slot by reference as well.  Only the caller
can know the complete type used here.  This means passing by value needs
to do a copy at the caller side.

OTOH

struct S { int i; char c[]; };
struct S foo (struct S val) { return val; }

is compiled to

foo:
.LFB0:
.cfi_startproc
movl%edi, %eax
ret

and the C FE warns:

t.c: In function ‘foo’:
t.c:2:22: note: the ABI of passing struct with a flexible array member has
changed in GCC 4.4
 struct S foo (struct S val) { return val; }

before that ABI change we had

foo:
.LFB2:
movl8(%rsp), %eax
movl%eax, (%rdi)
movq%rdi, %rax
ret

so it was passed on the stack and there was a return slot?  The C++ compiler
still produces the above with GCC 8, even when marking foo extern "C",
so that's another inconsistency / bug.

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89592

--- Comment #7 from Jakub Jelinek  ---
It depends if the users can expect that they can actually access the flexible
array members or if it is like if they declare a new variable with that type
without initializer and then copy it over.  In the latter case the flexible
array member can't be dereferenced.

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89592

--- Comment #8 from Richard Biener  ---
For the original testcase clang++ produces

leaq16(%rbp), %rdx
...
movq%rdx, -56(%rbp) # 8-byte Spill
...
movq-56(%rbp), %rcx # 8-byte Reload
movl(%rcx), %esi
cmpls2227, %esi
movq%rax, -96(%rbp) # 8-byte Spill
je  .LBB0_2

so it agrees with what we have now.

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89592

--- Comment #9 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #7)
> It depends if the users can expect that they can actually access the
> flexible array members or if it is like if they declare a new variable with
> that type without initializer and then copy it over.  In the latter case the
> flexible array member can't be dereferenced.

True.  That would mean the flexarray member could be ignored for ABI
purposes for example.

[Bug c++/89605] New: A method cannot have two identical lambdas as default arguments

[xavier at cremaschi dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89605

Bug ID: 89605
   Summary: A method cannot have two identical lambdas as default
arguments
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xavier at cremaschi dot fr
  Target Milestone: ---

$ g++ --version
g++ (Debian 8.2.0-21) 8.2.0


The following code does not compile : 

#include 
#include 
#include 

using namespace std;

class S {
public:
using ConverterFunction = function;

void _foo(
const ConverterFunction& converter = [](double value) -> double
{ return value; },
const ConverterFunction& converterBack = [](double value) ->
double { return value; }
);
};


void S::_foo(
const ConverterFunction& converter,
const ConverterFunction& converterBack)
{
cout << "foo " << converter(42) << endl;
}

int main() {
S s;
s._foo();
return 0;
}



It triggers the following error :

/tmp/ccW5xjuM.s: Assembler messages:
/tmp/ccW5xjuM.s:183: Error: symbol
`_ZZN1S4_fooERKSt8functionIFddEES4_Ed_NKUldE_clEd' is already defined
/tmp/ccW5xjuM.s:514: Error: symbol
`_ZSt4moveIRZN1S4_fooERKSt8functionIFddEES5_Ed_UldE_EONSt16remove_referenceIT_E4typeEOS9_'
is already defined
/tmp/ccW5xjuM.s:534: Error: symbol
`_ZNSt8functionIFddEEC2IZN1S4_fooERKS1_S5_Ed_UldE_vvEET_' is already defined
/tmp/ccW5xjuM.s:788: Error: symbol
`_ZNSt14_Function_base13_Base_managerIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_E21_M_not_empty_functionIS7_EEbRKT_'
is already defined
/tmp/ccW5xjuM.s:807: Error: symbol
`_ZNSt14_Function_base13_Base_managerIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_E15_M_init_functorERSt9_Any_dataOS7_'
is already defined
/tmp/ccW5xjuM.s:836: Error: symbol
`_ZNSt17_Function_handlerIFddEZN1S4_fooERKSt8functionIS0_ES5_Ed_UldE_E9_M_invokeERKSt9_Any_dataOd'
is already defined
/tmp/ccW5xjuM.s:873: Error: symbol
`_ZNSt14_Function_base13_Base_managerIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_E10_M_managerERSt9_Any_dataRKS9_St18_Manager_operation'
is already defined
/tmp/ccW5xjuM.s:1099: Error: symbol
`_ZNSt14_Function_base13_Base_managerIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_E15_M_init_functorERSt9_Any_dataOS7_St17integral_constantIbLb1EE'
is already defined
/tmp/ccW5xjuM.s:1129: Error: symbol
`_ZNSt14_Function_base13_Base_managerIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_E14_M_get_pointerERKSt9_Any_data'
is already defined
/tmp/ccW5xjuM.s:1156: Error: symbol
`_ZNSt9_Any_data9_M_accessIPZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_EERT_v' is
already defined
/tmp/ccW5xjuM.s:1178: Error: symbol
`_ZNSt14_Function_base13_Base_managerIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_E8_M_cloneERSt9_Any_dataRKS9_St17integral_constantIbLb1EE'
is already defined
/tmp/ccW5xjuM.s:1208: Error: symbol
`_ZNSt14_Function_base13_Base_managerIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_E10_M_destroyERSt9_Any_dataSt17integral_constantIbLb1EE'
is already defined
/tmp/ccW5xjuM.s:1297: Error: symbol
`_ZNKSt9_Any_data9_M_accessIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_EERKT_v' is
already defined
/tmp/ccW5xjuM.s:1319: Error: symbol
`_ZSt11__addressofIKZN1S4_fooERKSt8functionIFddEES5_Ed_UldE_EPT_RS8_' is
already defined
/tmp/ccW5xjuM.s:1339: Error: symbol
`_ZNSt9_Any_data9_M_accessIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_EERT_v' is
already defined



The exact same code compiles with clang++-6.0 or MSVC (Visual Studio 2017
15.9.4).
It also compiles with g++ as soon as implementation is inlined in class
definition.

[Bug c++/89605] A method cannot have two identical lambdas as default arguments

[xavier at cremaschi dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89605

--- Comment #1 from xavier at cremaschi dot fr ---
FYI it also compiles if there is no class but just a free function :

#include 
#include 
#include 

using namespace std;

using ConverterFunction = function;

void _foo(
const ConverterFunction& converter = [](double value) -> double
{ return value; },
const ConverterFunction& converterBack = [](double value) ->
double { return value; }
);

void _foo(
const ConverterFunction& converter,
const ConverterFunction& converterBack)
{
cout << "foo " << converter(42) << endl;
}

int main() {
_foo();
return 0;
}

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[eb at emlix dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #22 from Rolf Eike Beer  ---
I can confirm that with gcc 8.3 with the gcc8-patch Qt 5.12.1 builds fine.

[Bug target/89578] [9 Regression] 5% runtime regression for 481.wrf at -Ofast -flto

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89578

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
Investigating, but I guess there's nothing to fix :/

[Bug fortran/89603] unclassifiable statement error in code that is ok in compaq visual fortran

[yumashev at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89603

--- Comment #2 from Vladimir Yumashev  ---
Great !   Thanks a lot !


>Среда,  6 марта 2019, 12:04 +03:00 от steven at gcc dot gnu.org 
>:
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89603
>
>Steven Bosscher  changed:
>
>   What|Removed |Added
>
> Status|UNCONFIRMED |RESOLVED
> CC||steven at gcc dot gnu.org
> Resolution|--- |INVALID
>
>--- Comment #1 from Steven Bosscher  ---
>Your code is not standard-conforming. Do this:
>
> cm(1)%mu=2.8d-2
> cm(1)%inc=7.5527d-1
>
>and you have standard-conforming Fortran.
>
>-- 
>You are receiving this mail because:
>You reported the bug.

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952

--- Comment #21 from Martin Liška  ---
(In reply to Daniel Borkmann from comment #20)
> (In reply to Martin Liška from comment #19)
> > Ok, I updated the benchmark and push it here:
> > https://github.com/marxin/microbenchmark-1
> > 
> > And I see following on my Haswell machine:
> 
> Thanks for working on it! Bit strange why some of your numbers are quite
> fluctuating e.g. in your 'normal' column. What do you use to tune your setup
> for testing? I've been running the `make prep` part which I added back then,
> and the numbers I see are quite stable. I ran a quick test this morning with
> your repo, and here's what I got for the round-robin walk:

Yes, it's without taskset and tuned. I don't have any experience with tuned.

> 
> * Xeon E3-1240 (3.7GHz):
> 
> # ./test.py 
>  normal   retpolineretpo+no-JT  retpo+JT=20  retpo+JT=40
> cases:8: 0.49 (100%)  2.09 (426%)  0.53 (108%)  0.53 (108%)  0.53 (108%) 
> cases:   16: 0.49 (100%)  2.09 (426%)  0.58 (119%)  0.58 (119%)  0.58 (119%) 
> cases:   32: 0.49 (100%)  2.09 (426%)  0.61 (125%)  2.09 (426%)  0.61 (125%) 
> cases:   64: 0.49 (100%)  2.26 (458%)  0.69 (140%)  2.27 (459%)  2.27 (459%) 
> cases:  128: 0.50 (100%)  2.37 (476%)  0.76 (153%)  2.32 (466%)  2.41 (483%) 
> cases:  256: 0.52 (100%)  2.33 (451%)  0.91 (175%)  2.33 (450%)  2.36 (456%) 
> cases: 1024: 1.05 (100%)  2.54 (242%)  1.08 (103%)  2.59 (246%)  2.54 (242%) 
> cases: 2048: 1.63 (100%)  2.56 (157%)  1.94 (119%)  2.61 (160%)  2.59 (159%) 
> cases: 4096: 2.19 (100%)  3.12 (143%)  3.22 (147%)  3.09 (142%)  3.13 (143%) 
> 
> * Xeon Gold 5120 (2.6GHz):
> 
> # ./test.py 
>  normal   retpolineretpo+no-JT  retpo+JT=20  retpo+JT=40
> cases:8: 0.70 (100%)  2.98 (425%)  0.75 (107%)  0.75 (107%)  0.75 (107%) 
> cases:   16: 0.70 (100%)  2.98 (425%)  0.82 (117%)  0.82 (117%)  0.82 (117%) 
> cases:   32: 0.70 (100%)  3.01 (430%)  0.87 (124%)  2.98 (426%)  0.87 (124%) 
> cases:   64: 0.70 (100%)  3.52 (501%)  0.94 (134%)  3.52 (501%)  3.52 (501%) 
> cases:  128: 0.71 (100%)  3.51 (495%)  1.07 (151%)  3.50 (495%)  3.50 (494%) 
> cases:  256: 0.76 (100%)  3.14 (414%)  1.27 (167%)  3.14 (414%)  3.14 (414%) 
> cases: 1024: 1.46 (100%)  3.36 (230%)  1.49 (102%)  3.36 (230%)  3.36 (230%) 
> cases: 2048: 2.25 (100%)  3.19 (142%)  2.70 (120%)  3.19 (142%)  3.19 (142%) 
> cases: 4096: 2.90 (100%)  3.74 (129%)  4.48 (155%)  3.73 (129%)  3.72 (129%) 
> 
> Probably makes sense to also add other walk tests aka input distributions
> for foo{,_no_table,_no_retpol}() for further comparison if plan would be
> to disable jump tables entirely.

There are number for:
+int x = i % 57;
+foo ((3 * x * x + 17 * x) / 100);

distribution:

 normal   retpolineretpo+no-JT  retpo+JT=20  retpo+JT=40
cases:8: 1.55 (100%)  2.65 (171%)  0.59 ( 38%)  0.60 ( 39%)  0.60 ( 39%) 
cases:   16: 1.53 (100%)  2.66 (174%)  0.67 ( 44%)  0.66 ( 43%)  0.66 ( 43%) 
cases:   32: 1.76 (100%)  2.68 (152%)  0.70 ( 40%)  2.69 (153%)  0.70 ( 39%) 
cases:   64: 1.31 (100%)  2.71 (206%)  0.75 ( 57%)  2.69 (205%)  2.66 (202%) 
cases:  128: 0.53 (100%)  2.75 (515%)  0.78 (147%)  2.73 (513%)  2.75 (516%) 
cases:  256: 0.55 (100%)  2.76 (504%)  0.85 (154%)  2.76 (504%)  2.76 (503%) 
cases: 1024: 0.54 (100%)  2.73 (506%)  0.96 (178%)  2.76 (511%)  2.74 (507%) 
cases: 2048: 0.54 (100%)  2.74 (507%)  1.23 (228%)  2.73 (505%)  2.71 (501%) 
cases: 4096: 0.54 (100%)  2.73 (503%)  1.44 (266%)  2.73 (502%)  2.73 (503%) 

Conclusion is the same for me, I'm going to prepare a patch that will disable
JTs for retpolines.
Thank you for testing.

[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Wed Mar  6 11:46:15 2019
New Revision: 269419

URL: https://gcc.gnu.org/viewcvs?rev=269419&root=gcc&view=rev
Log:
Charry pick libsanitizer r355488 (PR sanitizer/88684).

2019-03-06  Martin Liska  

PR sanitizer/88684
* sanitizer_common/sanitizer_platform.h (defined): Cherry pick.
(SANITIZER_NON_UNIQUE_TYPEINFO): Likewise.
* ubsan/ubsan_type_hash_itanium.cc (isDerivedFromAtOffset):
Likewise.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform.h
trunk/libsanitizer/ubsan/ubsan_type_hash_itanium.cc

[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Martin Liška  ---
Fixed on trunk, not planning to backport that.

[Bug ipa/88235] [7/8/9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88235

--- Comment #5 from Martin Jambor  ---
I have proposed such patch on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00262.html

[Bug c++/89605] A method cannot have two identical lambdas as default arguments

[xavier at cremaschi dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89605

--- Comment #2 from xavier at cremaschi dot fr ---
rguenth are you sure for the 'link-failure' keyword ? 

It's truly a compilation error, triggered while compiling a given c++ file, it
does NOT wait until linking to fail.

[Bug libstdc++/85517] std::variant exception safety problems

[ville at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517

--- Comment #4 from ville at gcc dot gnu.org ---
Author: ville
Date: Wed Mar  6 12:56:05 2019
New Revision: 269422

URL: https://gcc.gnu.org/viewcvs?rev=269422&root=gcc&view=rev
Log:
Rewrite variant, also PR libstdc++/85517

* include/std/variant (__do_visit): New.
(__variant_cast): Likewise.
(__variant_cookie): Likewise.
(__erased_*): Remove.
(_Variant_storage::_S_vtable): Likewise.
(_Variant_storage::__M_reset_impl): Adjust to use __do_visit.
(_Variant_storage::__M_reset): Adjust.
(__variant_construct): New.
(_Copy_ctor_base(const _Copy_ctor_base&)): Adjust to use
__variant_construct.
(_Move_ctor_base(_Move_ctor_base&&)): Likewise.
(_Move_ctor_base::__M_destructive_copy): New.
(_Move_ctor_base::__M_destructive_move): Adjust to use
__variant_construct.
(_Copy_assign_base::operator=): Adjust to use __do_visit.
(_Copy_assign_alias): Adjust to check both copy assignment
and copy construction for triviality.
(_Move_assign_base::operator=): Adjust to use __do_visit.
(_Multi_array): Add support for visitors that accept and return
a __variant_cookie.
(__gen_vtable_impl::_S_apply_all_alts): Likewise.
(__gen_vtable_impl::_S_apply_single_alt): Likewise.
(__gen_vtable_impl::__element_by_index_or_cookie): New. Generate
a __variant_cookie temporary for a variant that is valueless and..
(__gen_vtable_impl::__visit_invoke): ..adjust here.
(__gen_vtable::_Array_type): Conditionally make space for
the __variant_cookie visitor case.
(__variant_construct_by_index): New.
(get_if): Adjust to use std::addressof.
(relops): Adjust to use __do_visit.
(variant): Add __variant_cast and __variant_construct_by_index
as friends.
(variant::emplace): Use _M_reset() and __variant_construct_by_index
instead of self-destruction.
(variant::swap): Adjust to use __do_visit.
(visit): Reimplement in terms of __do_visit.
(__variant_hash_call_base_impl::operator()): Adjust to use __do_visit.
* testsuite/20_util/variant/compile.cc: Adjust.
* testsuite/20_util/variant/run.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant
trunk/libstdc++-v3/testsuite/20_util/variant/compile.cc
trunk/libstdc++-v3/testsuite/20_util/variant/run.cc

[Bug target/89602] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89602

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
We don't even have such instructions in the machine description.

So I guess the first question is how to represent those.

Here is a possible draft:

--- sse.md.jj2  2019-02-20 23:40:17.119140235 +0100
+++ sse.md  2019-03-06 13:48:26.286128346 +0100
@@ -1151,6 +1151,75 @@
(set_attr "memory" "none,load")
(set_attr "mode" "")])

+(define_insn "avx512f_mov_mask"
+  [(set (match_operand:VF_128 0 "register_operand" "=v")
+   (vec_merge:VF_128
+ (vec_merge:VF_128
+   (match_operand:VF_128 2 "register_operand" "v")
+   (match_operand:VF_128 3 "nonimm_or_0_operand" "0C")
+   (match_operand:QI 4 "register_operand" "Yk"))
+ (match_operand:VF_128 1 "register_operand" "v")
+ (const_int 1)))]
+  "TARGET_AVX512F"
+  "vmov\t{%2, %1, %0%{%4%}%N3|%0%{%4%}%N3, %1, %2}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_expand "avx512f_load_mask"
+  [(set (match_operand: 0 "register_operand")
+   (vec_merge:
+ (vec_merge:
+   (vec_duplicate:
+ (match_operand:MODEF 1 "memory_operand"))
+   (match_operand: 2 "nonimm_or_0_operand")
+   (match_operand:QI 3 "nonmemory_operand"))
+ (match_dup 4)
+ (const_int 1)))]
+  "TARGET_AVX512F"
+  "operands[4] = CONST0_RTX (mode);")
+
+(define_insn "*avx512f_load_mask"
+  [(set (match_operand: 0 "register_operand" "=v")
+   (vec_merge:
+ (vec_merge:
+   (vec_duplicate:
+ (match_operand:MODEF 1 "memory_operand" "m"))
+   (match_operand: 2 "nonimm_or_0_operand" "0C")
+   (match_operand:QI 3 "nonmemory_operand" "Yk"))
+ (match_operand: 4 "const0_operand" "C")
+ (const_int 1)))]
+  "TARGET_AVX512F"
+  "vmov\t{%1, %0%{%3%}%N2|%0%{3%}%N2, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "evex")
+   (set_attr "memory" "load")
+   (set_attr "mode" "")])
+
+(define_insn "avx512f_store_mask"
+  [(set (match_operand:MODEF 0 "memory_operand" "=m,m")
+   (if_then_else:MODEF
+ (ne:QI (and:QI (match_operand:QI 2 "nonmemory_operand" "Yk,n")
+(const_int 1))
+(const_int 0))
+ (vec_select:MODEF
+   (match_operand: 1 "register_operand" "v,v")
+   (parallel [(const_int 0)]))
+ (match_dup 0)))]
+  "TARGET_AVX512F"
+{
+  if (which_alternative == 0)
+return "vmov\t{%1, %0%{%2%}|%0%{%2%}, %1}";
+  else if ((INTVAL (operands[2]) & 1) != 0)
+return "vmov\t{%1, %0|%0, %1}";
+  else
+return "";
+}
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "evex,maybe_evex")
+   (set_attr "memory" "store")
+   (set_attr "mode" "")])
+
 (define_insn "_blendm"
   [(set (match_operand:V48_AVX512VL 0 "register_operand" "=v")
(vec_merge:V48_AVX512VL

Guess we might want some patterns to catch the case where the mask is known
constant with LSB set.  The case when the mask is known constant with LSB clear
doesn't seem to be representable easily, at least in some cases (especially {z}
for vmovs{s,d} 3 register form and vmovs{s,d} load without {z}).

[Bug libstdc++/86655] std::assoc_legendre should not constrain the value of m

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86655

--- Comment #7 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Wed Mar  6 13:38:32 2019
New Revision: 269423

URL: https://gcc.gnu.org/viewcvs?rev=269423&root=gcc&view=rev
Log:
2019-03-06  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/86655 - std::assoc_legendre should not constrain
the value of m (or x).
* include/tr1/legendre_function.tcc (__assoc_legendre_p,
__sph_legendre): If degree > order Don't throw, return 0.
(__legendre_p, __assoc_legendre_p): Don't constrain x either.
* testsuite/special_functions/02_assoc_legendre/pr86655.cc: New test.
* testsuite/special_functions/20_sph_legendre/pr86655.cc: New test.
* testsuite/tr1/5_numerical_facilities/special_functions/
02_assoc_legendre/pr86655.cc: New test.
* testsuite/tr1/5_numerical_facilities/special_functions/
22_sph_legendre/pr86655.cc: New test.


Added:
trunk/libstdc++-v3/testsuite/special_functions/02_assoc_legendre/pr86655.cc
trunk/libstdc++-v3/testsuite/special_functions/20_sph_legendre/pr86655.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/02_assoc_legendre/pr86655.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/22_sph_legendre/pr86655.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/legendre_function.tcc

[Bug target/89578] [9 Regression] 5% runtime regression for 481.wrf at -Ofast -flto

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89578

--- Comment #5 from Richard Biener  ---
So it looks like the change from r269097 to r269098 is only 2.5% (I've included
the followup fix ontop of r269098):

481.wrf 11170245   45.7 *   11170251   44.5 S
481.wrf 11170246   45.4 S   11170251   44.5 *

Checking r269096 reveals (BASE = r269096, PEAK = r269098 + followup):

481.wrf 11170244   45.7 S   11170254   44.0 S
481.wrf 11170244   45.8 *   11170252   44.3 *

Note that fortran guarantees on parameter aliasing are stronger than
those of restrict qualified pointers so using restrict isn't perfect
and it might suffer from the correctness fix unnecessarily.  In a
similar fashion performing inlining might make PTA do more conservative
choices than when looking at the fnspec guarantees.

For r269096 there's the possibility of simply never recomputing restrict
(gate it with !cfun->after_inlining).

Overall I see

   9.90%201223  wrf_peak.amd64-  wrf_peak.amd64-m64-gcc42-nn  [.]
solve_interface_
   8.50%172668  wrf_base.amd64-  wrf_base.amd64-m64-gcc42-nn  [.]
solve_interface_

which explains why we only see this with -flto (this function does nothing
but call other functions...).  It doesn't really explain why r269096 makes
such a big difference though (I guess it must be the PRE PTA recompute
triggering this).

But the function is a huge mess and the profile quite flat and similar...

[Bug target/89606] New: Extra mov after structure load instructions on aarch64

[yyc1992 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606

Bug ID: 89606
   Summary: Extra mov after structure load instructions on aarch64
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

Code to reproduce,

```
#include 

#ifdef __aarch64__
float64x2x2_t f(const double *p1, const double *p2)
{
float64x2x2_t v = vld2q_f64(p1);
return vld2q_lane_f64(p2, v, 1);
}

float32x2x2_t f2(const float *p1, const float *p2)
{
float32x2x2_t v = vld2_f32(p1);
return vld2_lane_f32(p2, v, 1);
}
#endif

void f3(float32x2x2_t *p, const float *p1, const float *p2)
{
float32x2x2_t v = vld2_f32(p1);
*p = vld2_lane_f32(p2, v, 1);
}
```

GCC produces (aarch64, -O1/-O2/-O3/-Ofast/-Os),

```
f:
ld2 {v4.2d - v5.2d}, [x0]
mov v0.16b, v4.16b
mov v1.16b, v5.16b
ld2 {v0.d - v1.d}[1], [x1]
ret
f2:
ld2 {v0.2s - v1.2s}, [x0]
mov v2.8b, v0.8b
mov v3.8b, v1.8b
ld2 {v2.s - v3.s}[1], [x1]
mov v1.8b, v3.8b
mov v0.8b, v2.8b
ret
f3:
ld2 {v2.2s - v3.2s}, [x1]
mov v0.8b, v2.8b
mov v1.8b, v3.8b
ld2 {v0.s - v1.s}[1], [x2]
stp d0, d1, [x0]
ret
```

For all three functions, none of the mov's seems necessary. Even if there's
some performance issue when reusing the registers (I highly doubt it...) at
least the `-Os` version should not have those mov's.

Clang produces what I expect in this case,

```
f:
ld2 { v0.2d, v1.2d }, [x0]
ld2 { v0.d, v1.d }[1], [x1]
ret
f2:
ld2 { v0.2s, v1.2s }, [x0]
ld2 { v0.s, v1.s }[1], [x1]
ret
f3:
ld2 { v0.2s, v1.2s }, [x1]
ld2 { v0.s, v1.s }[1], [x2]
stp d0, d1, [x0]
ret
```

Aarch32 doesn't have this issue either with GCC,

```
f3:
vld2.32 {d16-d17}, [r1]
vld2.32 {d16[1], d17[1]}, [r2]
vst1.64 {d16-d17}, [r0:64]
bx  lr
```

so this seems to be aarch64 specific.

[Bug target/89607] New: Missing optimization for store of multiple registers on arm and aarch64

[yyc1992 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607

Bug ID: 89607
   Summary: Missing optimization for store of multiple registers
on arm and aarch64
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

Test code, Compiled for arm/aarch64 with -O1/-O2/-O3/-Os/-Ofast

```
#include 

void f4(float32x4x2_t *p, const float *p1)
{
*p = vld2q_f32(p1);
}

void f5(float32x4x2_t *p, float32x4_t v1, float32x4_t v2)
{
p->val[0] = v1;
p->val[1] = v2;
}
```

arm:

```
f4:
vld2.32 {d16-d19}, [r1]
vst1.64 {d16-d19}, [r0:64]
bx  lr
f5:
vst1.64 {d0-d1}, [r0:64]
vstrd2, [r0, #16]
vstrd3, [r0, #24]
bx  lr
```

aarch64:

```
f4:
ld2 {v0.4s - v1.4s}, [x1]
str q0, [x0]
str q1, [x0, 16]
ret
f5:
str q0, [x0]
str q1, [x0, 16]
ret
```

For arm, it seems that f5 could follow f4 and uses a `vst1.64 {d0-d3}, [r0:64]`
instead. For aarch64, both function should have used a `stp q0, q1, [x0]`

Clang produces what I expected on aarch64 but it only uses pair store
instruction on arm, which use one more instuction for `f4` and one fewer for
`f5`. (I'm not sure why GCC decided to use a pair store and then two single
stores)

Similar to pr89606, this optimization should at least happen with `-Os` if not
for all other optimization levels.

Tested with 8.2.1 on arm and 8.3.0 on aarch64.

[Bug target/89602] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89602

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45905&action=edit
gcc9-pr89602-wip.patch

Untested patch without testsuite.

[Bug libstdc++/89608] New: Undetected iterator invalidations on unordered containers in debug mode

[mafrasi2 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89608

Bug ID: 89608
   Summary: Undetected iterator invalidations on unordered
containers in debug mode
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mafrasi2 at gmail dot com
  Target Milestone: ---

Created attachment 45906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45906&action=edit
Partial fix for unordered_set

Many iterator invalidations on unordered containers are not detected in debug
mode:

```
#include 
#include 

int main() {
  __gnu_debug::unordered_set myset;
  myset.insert(0);
  myset.insert(1);
  for (auto it = myset.begin(), end = myset.end(); it != end; ++it) {
std::cout << *it << "\n";
myset.insert(2);
  }
}
```

This example outputs `1` on my system and doesn't report the access to an
invalidated iterator.

The attached patch fixes the example and the same thing can be done to the
other affected containers. The bug can still be triggered with an explicit
rehash, though.

That said, this may very well be intended behavior since I'm not very
knowledgeable of the C++ standard in general, but using the libc++ debug mode,
it is reported as invalidation both in the example and with the explicit
rehash.

[Bug c++/87378] False -Wredundant-move (derived vs. base)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87378

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Wed Mar  6 15:34:50 2019
New Revision: 269427

URL: https://gcc.gnu.org/viewcvs?rev=269427&root=gcc&view=rev
Log:
PR c++/87378 - bogus -Wredundant-move warning.
* typeck.c (maybe_warn_pessimizing_move): See if the maybe-rvalue
overload resolution would actually succeed.

* g++.dg/cpp0x/Wredundant-move1.C (fn4): Drop dg-warning.
* g++.dg/cpp0x/Wredundant-move7.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/Wredundant-move1.C

[Bug rtl-optimization/88845] ICE in lra_set_insn_recog_data, at lra.c:1010

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88845

--- Comment #4 from Peter Bergner  ---
Author: bergner
Date: Wed Mar  6 15:36:43 2019
New Revision: 269428

URL: https://gcc.gnu.org/viewcvs?rev=269428&root=gcc&view=rev
Log:
gcc/
PR rtl-optimization/88845
* config/rs6000/rs6000.c (rs6000_emit_move_si_sf_subreg): Enable during
LRA.
* lra.c (remove_scratches_1): New function.
(remove_scratches): Use it.
(lra_emit_move): Likewise.

gcc/testsuite/
PR rtl-optimization/88845
* gcc.target/powerpc/pr88845.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr88845.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87378] False -Wredundant-move (derived vs. base)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87378

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug rtl-optimization/88845] ICE in lra_set_insn_recog_data, at lra.c:1010

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88845

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-03/msg00148.ht
   ||ml
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #5 from Peter Bergner  ---
Fixed with the LRA version of the patch linked above.

[Bug c++/29843] [meta-bug] C++98 standard conformance issues

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29843

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
After discussion on IRC we've decided to close this. There are a number of
C++98 conformance issues not tracked by this bug, and we don't have a meta-bug
for c++11/c++14/c++17/... conformance, and the outstanding bugs it depends on
(2316 12333 28985 29027 29040) are all also relevant to later standards, so are
not specific to c++98 anyway.

INVALID doesn't really describe the situation, but it'll do.

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 29843, which changed state.

Bug 29843 Summary: [meta-bug] C++98 standard conformance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29843

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug c++/29040] missing access control checks in subclasses for nested types

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29040

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2006-09-12 20:59:08 |2019-3-6

--- Comment #8 from Jonathan Wakely  ---
Paolo, do you still have a patch for this?

[Bug libstdc++/86655] std::assoc_legendre should not constrain the value of m

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86655

emsr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from emsr at gcc dot gnu.org ---
Fixed with 269423.

[Bug go/89598] [9 Regression] go frontend fails to build against mpfr 2.4.2

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89598

--- Comment #6 from David Malcolm  ---
(In reply to Ian Lance Taylor from comment #5)
> This time for sure.

Indeed: r269411 did fix the build against mpfr 2.4.2 for my test config.

Thanks.

[Bug target/89592] FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_alt.o-cp_compat_y_tst.o execute against GCC4.8

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89592

--- Comment #10 from Martin Sebor  ---
The standard is clear that flexible array members are not copied but ignored:

In most situations, the flexible array member is ignored. In particular, the
size of the structure is as if the flexible array member were omitted except
that it may have more trailing padding than the omission would imply.

The rest of the text describes when their elements can be accessed.

[Bug libstdc++/89608] Undetected iterator invalidations on unordered containers in debug mode

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89608

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-06
 CC||fdumont at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
François, could you take a look please? The standard says:

> The insert and emplace members shall not affect the validity of iterators if 
> (N+n) <= z * B, where N is the number of elements in the container prior to 
> the insert operation, n is the number of elements inserted, B is the 
> container’s bucket count, and z is the container’s maximum load factor.

The insertion does rehash, so should invalidate the iterators. It looks like
the _M_check_rehashed function only invalidates local iterators, despite the
order of elements changing.

[Bug c++/89605] A method cannot have two identical lambdas as default arguments

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89605

--- Comment #3 from Jonathan Wakely  ---
The code *does* compile, but GCC outputs duplicate symbols, so it doesn't
assemble (or link).

[Bug c++/89605] A method cannot have two identical lambdas as default arguments

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89605

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-06
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
Although with trunk it crashes the compiler:

l.cc: In member function 'void S::_foo(const ConverterFunction&, const
ConverterFunction&)':
l.cc:20:34: warning: unused parameter 'converterBack' [-Wunused-parameter]
   20 | const ConverterFunction& converterBack)
  | ~^
l.cc: At global scope:
l.cc:29:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   29 | }
  | ^
_ZNSt9_Any_data9_M_accessIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_EERT_v/919
(_Tp& std::_Any_data::_M_access() [with _Tp = S::])
@0x7f0881f599d8
  Type: function definition analyzed
  Visibility: no_reorder public weak comdat
comdat_group:_ZNSt9_Any_data9_M_accessIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_EERT_v
one_only visibility_specified
  previous sharing asm name: 915
  References: 
  Referring: 
  Function flags: body
  Called by: static void
std::_Function_base::_Base_manager<_Functor>::_M_destroy(std::_Any_data&,
std::true_type) [with _Functor = S::]/877 
  Calls: void* std::_Any_data::_M_access()/279 
_ZNSt9_Any_data9_M_accessIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_EERT_v/915
(_Tp& std::_Any_data::_M_access() [with _Tp = S::])
@0x7f0881f59438
  Type: function definition analyzed
  Visibility: no_reorder public weak comdat
comdat_group:_ZNSt9_Any_data9_M_accessIZN1S4_fooERKSt8functionIFddEES6_Ed_UldE_EERT_v
one_only visibility_specified
  next sharing asm name: 919
  References: 
  Referring: 
  Function flags: body
  Called by: static void
std::_Function_base::_Base_manager<_Functor>::_M_destroy(std::_Any_data&,
std::true_type) [with _Functor = S::]/872 
  Calls: void* std::_Any_data::_M_access()/279 
l.cc:29:1: internal compiler error: symtab_node::verify failed
0xb050c9 symtab_node::verify_symtab_nodes()
/home/jwakely/src/gcc/gcc/gcc/symtab.c:1260
0xb18564 symtab_node::checking_verify_symtab_nodes()
/home/jwakely/src/gcc/gcc/gcc/cgraph.h:637
0xb18564 symbol_table::compile()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2602
0xb1a99c symbol_table::compile()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2599
0xb1a99c symbol_table::finalize_compilation_unit()
/home/jwakely/src/gcc/gcc/gcc/cgraphunit.c:2865
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ada/89609] New: bug box caused by access to function as a record component via a limited with

[nicolas at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89609

Bug ID: 89609
   Summary: bug box caused by access to function as a record
component via a limited with
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas at debian dot org
  Target Milestone: ---

These sources should be legal. Execution would dereference a null pointer, but
this is easy to fix without changing the bug box below.

limited with Rs;   
package As is  
   type A is access function return Rs.R;  
end As;

with As;   
package Rs is  
   type R is record
  F : As.A;
   end record; 
   X : R;  
   Y : R := X.F.all;   
end Rs;

gnatmake -c rs.ads
produces:

+===GNAT BUG DETECTED==+
| 8.2.0 (x86_64-linux-gnu) GCC error:  |
| in save_gnu_tree, at ada/gcc-interface/utils.c:337   |
| Error detected at rs.ads:3:4 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

This has similarities with Bug 89159, but no tagged type is implied.

[Bug fortran/89603] unclassifiable statement error in code that is ok in compaq visual fortran

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89603

--- Comment #3 from Dominique d'Humieres  ---
> Your code is not standard-conforming. Do this: ...

You can also use -fdec, but it's better to fix the code.

[Bug fortran/89601] [8/9 Regression] ICE: Segmentation fault (in resolve_component)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-06
 CC||pault at gcc dot gnu.org
 Blocks||82173
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Not really a regression, but a bug in the implementation of a new feature
(parameterized derived types) not implemented in 7.4.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
[Bug 82173] [meta-bug] Parameterized derived type errors

[Bug c++/78511] ICE on using concept name as a "requires" parameter

[arthur.j.odwyer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78511

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #1 from Arthur O'Dwyer  ---
Duplicate of 71543.

[Bug c++/82768] ICE in synthesize_implicit_template_parm, at cp/parser.c:39338

[arthur.j.odwyer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82768

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #3 from Arthur O'Dwyer  ---
Duplicate of 71543.

[Bug libstdc++/89610] New: Move-assigning a pmr container sometimes copies the elements instead of moving them

[arthur.j.odwyer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89610

Bug ID: 89610
   Summary: Move-assigning a pmr container sometimes copies the
elements instead of moving them
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

When we move-assign an allocator-aware container, and the allocator does POCMA,
and the allocators of the left-hand and right-hand sides are not equal, then we
must request a new batch of memory from the left-hand allocator and transfer
the elements over from the right-hand heap to the left-hand heap.
libstdc++ does this mostly correctly. But, for the actual transfer of the
elements' values, it appears to use "move_if_noexcept" rather than vanilla
"move". So if the element type's move-constructor is non-nothrow,
MOVE-ASSIGNING a pmr::container will COPY-CONSTRUCT each of its elements!

MSVC's containers will unconditionally use the move-constructor in this
situation.
libc++'s containers will unconditionally use the move-constructor in this
situation.
libstdc++ is the odd one out (and the inefficient one).

Casey Carter says, "The IS says it should move the Widgets:
http://eel.is/c++draft/container.requirements.general#16.sentence-41";. I'm not
sure it's *required* to move them, but I certainly think it would be
*preferable* to move them, for reasons of efficiency and
portability-of-user-code-between-vendors.

Here's my test case. You can replace `deque` with `vector` or `list` (or with
appropriate tweaks `forward_list` or `set`) and observe libstdc++'s inefficient
"COPY widget" behavior in each case.

=

// https://wandbox.org/permlink/SXi0LYt5D6QN1BBJ
#include 
#include 
#include 

struct Widget {
const char *data_ = "uninitialized";
Widget(const char *s) : data_(s) {}
Widget(const Widget& rhs) : data_(rhs.data_) { puts("COPY widget"); }
Widget(Widget&& rhs) /*NOT NOEXCEPT*/ : data_(rhs.data_) { puts("MOVE
widget"); rhs.data_ = "moved-from"; }
Widget& operator=(const Widget& rhs) { data_ = rhs.data_; puts("COPY-ASSIGN
widget"); return *this; }
Widget& operator=(Widget&& rhs) { data_ = rhs.data_; rhs.data_ =
"moved-from"; puts("MOVE-ASSIGN widget"); return *this; }
};

int main()
{
std::pmr::monotonic_buffer_resource mr1;
std::pmr::monotonic_buffer_resource mr2;
std::pmr::deque v1(&mr1);
std::pmr::deque v2(&mr2);
v1.emplace_back("foo");
v1.emplace_back("bar");
v2 = std::move(v1);
// libstdc++ prints "COPY widget" twice
// everyone else prints "MOVE widget" twice
}

=

[Bug fortran/66089] [7/8/9 Regression] elemental dependency mishandling when class array are involved

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

[Bug c++/89611] New: Compilation ok with 'class', but ko with 'struct'

[xavier at cremaschi dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89611

Bug ID: 89611
   Summary: Compilation ok with 'class', but ko with 'struct'
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xavier at cremaschi dot fr
  Target Milestone: ---

$ g++ --version
g++ (Debian 8.2.0-21) 8.2.0


The following code compiles : 


#include 
#include 
#include 

using namespace std;

template struct Visitor : Ts... {
using Ts::operator()...;
};
template Visitor(Ts...) -> Visitor;

int main()
{
std::variant package;

auto x = Visitor {
[](int){ cout << "int\n"; },
[](string) { cout << "string\n"; },
}
;
std::visit(x, package);
}





But if I replace 'struct Visitor' by a class and add public visibility, it
doesn't :

#include 
#include 
#include 


using namespace std;


template class Visitor : Ts... {
public:
using Ts::operator()...;
};
template Visitor(Ts...) -> Visitor;

int main()
{
std::variant package;

auto x = Visitor {
[](int){ cout << "int\n"; },
[](string) { cout << "string\n"; },
}
;
std::visit(x, package);
}


AFAIK class or struct is just a matter of default visibility, so I think both
cases should work.

[Bug c++/88820] [7/8/9 Regression] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88820

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot 
gnu.org

--- Comment #8 from Marek Polacek  ---
(In reply to Marek Polacek from comment #7)
> A little bit more simplified:
> 
> template  struct S;
> 
> template  struct W {
>   template  static int foo();
>   bool b = foo();
> };

But that's probably invalid, because the template parameter S is missing a
template argument list?  I don't know what to do with this PR.

[Bug c++/89612] New: internal compiler error: in push_access_scope, at cp/pt.c:237

[peter.cpp at sommerlad dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89612

Bug ID: 89612
   Summary: internal compiler error: in push_access_scope, at
cp/pt.c:237
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.cpp at sommerlad dot ch
  Target Milestone: ---

Created attachment 45907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45907&action=edit
preprocessed source for ICE

my code for implementing P0052 unique_resource gets an ICE with the following
constellation:

* template class with CTAD
* friend declaration of template factory function with conditional noexcept
* template factory function with conditional noexcept for this class (the
friend)

- example code triggering ice -

#include 

template
struct unique_resource
{
   template
>
unique_resource(RR &&r, DD &&d)
noexcept(true)
{}
template
friend
auto make_unique_resource_checked(MR &&r, const S &invalid, MD &&d)
noexcept(std::is_nothrow_constructible_v,MR> &&
std::is_nothrow_constructible_v,MD>)
;
};
template
unique_resource(R, D)
-> unique_resource;

template
[[nodiscard]]
auto make_unique_resource_checked(R &&r, const S &invalid, D &&d)
noexcept(std::is_nothrow_constructible_v,R> &&
std::is_nothrow_constructible_v,D>)
{
}

int main() {
auto guard=unique_resource(0,[]{});
}

-- end example -

compilation command and output:

g++ -std=c++17 -O0 -g3 -pedantic -Wall -Wextra -c -fmessage-length=0
-Wno-attributes -save-temps -MMD -MP -MF"src/gcc-ice-test.d"
-MT"src/gcc-ice-test.o" -o "src/gcc-ice-test.o" "../src/gcc-ice-test.cpp"
../src/gcc-ice-test.cpp: In instantiation of 'template auto make_unique_resource_checked(MR&&, const S&, MD&&)':
../src/gcc-ice-test.cpp:14:7:   required from 'struct unique_resource >'
../src/gcc-ice-test.cpp:34:36:   required from here
../src/gcc-ice-test.cpp:14:7: internal compiler error: in push_access_scope, at
cp/pt.c:237
  auto make_unique_resource_checked(MR &&r, const S &invalid, MD &&d)
   ^~~~
---end

preprocessed source attached

[Bug c++/89612] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89612

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-06
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/89602] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89602

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45908&action=edit
gcc9-pr89602.patch

Full untested patch.

[Bug c++/89611] Compilation ok with 'class', but ko with 'struct'

[xavier at cremaschi dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89611

--- Comment #1 from xavier at cremaschi dot fr ---
I forgot that default inheritance is private. My bad. This is NOT a bug.

[Bug c++/89576] [8/9 Regression] constexpr not working if implicitly captured in a lambda in a function template (gcc 8.3+)

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89576

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Mar  6 18:39:24 2019
New Revision: 269433

URL: https://gcc.gnu.org/viewcvs?rev=269433&root=gcc&view=rev
Log:
PR c++/89576 - if constexpr of lambda capture.

Now that we're doing implicit lambda capture in templates, we see x here as
the lambda capture.  maybe_convert_cond was doing nothing in a template, so
we never called mark_rvalue_use on x.  As part of the broad move toward
doing more processing of non-dependent expressions, let's do this
conversion.

* semantics.c (maybe_convert_cond): Do convert a non-dependent
condition in a template.
* typeck.c (condition_conversion): Handle being called in a
template.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if28.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if15.C

[Bug c++/89576] [8 Regression] constexpr not working if implicitly captured in a lambda in a function template (gcc 8.3+)

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89576

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] constexpr  |[8 Regression] constexpr
   |not working if implicitly   |not working if implicitly
   |captured in a lambda in a   |captured in a lambda in a
   |function template (gcc  |function template (gcc
   |8.3+)   |8.3+)

--- Comment #3 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/89612] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89612

--- Comment #2 from Marek Polacek  ---
Reduced (invalid):

template  bool b;

template  
struct C {
  template  friend int foo() noexcept(b<1>);
};

template  int foo() noexcept(b<1>);

auto a = C();

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #45903|0   |1
is obsolete||

--- Comment #23 from Jakub Jelinek  ---
Created attachment 45909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45909&action=edit
gcc9-pr89585.patch

Updated trunk patch based on IRC discussions with Segher.

[Bug tree-optimization/89550] [8/9 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #3 from Jason Merrill  ---
Changing to tree-optimization.

[Bug c++/87148] [7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  6 18:46:32 2019
New Revision: 269434

URL: https://gcc.gnu.org/viewcvs?rev=269434&root=gcc&view=rev
Log:
PR c++/87148
* init.c (build_value_init_noctor): Ignore flexible array members.

* g++.dg/ext/flexary34.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/flexary34.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89612] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89612

--- Comment #3 from Marek Polacek  ---
(In reply to Marek Polacek from comment #2)
> Reduced (invalid):
> 
> template  bool b;
> 
> template  
> struct C {
>   template  friend int foo() noexcept(b<1>);
> };
> 
> template  int foo() noexcept(b<1>);
> 
> auto a = C();

Started to ICE with r214396.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585

--- Comment #24 from Harald van Dijk  ---
Created attachment 45910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45910&action=edit
gcc-8-pr89585-warn.patch

(In reply to Jakub Jelinek from comment #21)
> Created attachment 45904 [details]
> gcc8-pr89585.patch
> 
> The 8.x version would be like this.

Depending on whether this will remain an error in GCC 9, would it make sense to
have a warning for file scope asm volatile, like so? (Minimally tested so far.
If it makes sense, I can re-do it based on the updated GCC 9 patch.)

[Bug c++/89381] [7/8/9 Regression] Implicit copy constructor cannot be generated after unrelated class definition

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89381

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,

[christalization at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604

--- Comment #3 from christopher békési  ---
(In reply to Andrew Pinski from comment #2)
> In C, plain char can either be signed or unsigned; this is unlike int.
> 
> Which of signed char or unsigned char has the same range, representation,
> and behavior as “plain” char (C90 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5,
> C99 and C11 6.3.1.1).

Indeed, I had completely missed that, I assumed the char was conforming to the
same rules as the int when it comes to assuming its signed-ness.
Explicitly specifying 'signed char' did yield the expected result.

How come that it was decided to make the char on ARM unsigned whereas on x86
platforms it's signed by default?

Thanks for the input, I'm sorry if I wasted anyone's time on this.

[Bug target/89604] Type conversion from signed char to a wider integer generates wrong assembly for ARM,

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89604

--- Comment #4 from Andrew Pinski  ---
(In reply to christopher békési from comment #3)
> How come that it was decided to make the char on ARM unsigned whereas on x86
> platforms it's signed by default?

I don't know, you are going to have to ask ARM that question.  The ABI was
defined by them.  We are just users of it.  There are other ABIs which also use
unsigned as the plain char too (PowerPC); for that one you will have to ask IBM
(they defined the original ABI).

[Bug c++/89612] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89612

--- Comment #4 from Marek Polacek  ---
And a better testcase, and actually valid:

template  
struct C {
  template 
  friend int foo() noexcept(N);
};

template 
int foo() noexcept(N);

C c;

[Bug c++/89611] Compilation ok with 'class', but ko with 'struct'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89611

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
That is change:
template class Visitor : Ts... {

To:
template class Visitor : public Ts... {