[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.2
[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-31 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- https://gcc.gnu.org/wiki/LibstdcxxTodo has an up-to-date list, but it should be in the manual too.
[Bug rtl-optimization/88751] Performance regression reload vs lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88751 --- Comment #4 from Andreas Krebbel --- (In reply to Babneet Singh from comment #3) > Hi Andreas and Richard: What's the status for this issue? Which approach > will be used to resolve this issue? I would like to have Vladimir comment on this first, since he wrote the code and definitely knows this stuff best. Richard, would it be ok with you to raise the prio? OpenJ9 is a pretty important workload I think.
[Bug libstdc++/90686] New: Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686 Bug ID: 90686 Summary: Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays" Product: gcc Version: unknown Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ensadc at mailnesia dot com CC: redi at gcc dot gnu.org Target Milestone: --- P1357R1 "Traits for [Un]bounded Arrays" has been implemented in r269420 (and feature test macro added in r269426), but this is not mentioned in the status table (https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020). It seems that other papers approved in Kona 2019 are also missing.
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 --- Comment #1 from Ian Lance Taylor --- What kind of system are you running on? What is the output of ../gcc-9.1.0/config.guess ?
[Bug rtl-optimization/88751] Performance regression reload vs lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88751 sbabneet at ca dot ibm.com changed: What|Removed |Added CC||sbabneet at ca dot ibm.com --- Comment #3 from sbabneet at ca dot ibm.com --- Hi Andreas and Richard: What's the status for this issue? Which approach will be used to resolve this issue?
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #20 from Qi Feng ---
I have tried to merge signed and unsigned together:
/* x > y && x != ( 0 or XXX_MIN ) --> x > y */
(for and (truth_and bit_and)
(simplify
(and:c (gt:c@3 @0 @1) (ne @0 INTEGER_CST@2))
(if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1)))
(if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1))
&& integer_zerop (@2))
|| (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1))
&& wi::eq_p (wi::to_wide (@2),
wi::min_value (TYPE_PRECISION (TREE_TYPE (@2)),
SIGNED
@3
/* x > y || x != ( 0 or XXX_MIN ) --> x != ( 0 or XXX_MIN ) */
(for or (truth_or bit_ior)
(simplify
(or:c (gt:c @0 @1) (ne@3 @0 INTEGER_CST@2))
(if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1)))
(if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1))
&& integer_zerop (@2))
|| (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1))
&& wi::eq_p (wi::to_wide (@2),
wi::min_value (TYPE_PRECISION (TREE_TYPE (@2)),
SIGNED
@3
/* x < y && x != ( UXXX_MAX or XXX_MAX ) --> x < y */
(for and (truth_and bit_and)
(simplify
(and:c (lt:c@3 @0 @1) (ne @0 INTEGER_CST@2))
(if (INTEGRAL_TYPE_P (TREE_TYPE(@0)) && INTEGRAL_TYPE_P (TREE_TYPE(@1)))
(if ((TYPE_UNSIGNED (TREE_TYPE(@0)) && TYPE_UNSIGNED (TREE_TYPE(@1))
&& wi::eq_p (wi::to_wide (@2),
wi::max_value (TYPE_PRECISION (TREE_TYPE (@2)),
UNSIGNED)))
|| (!TYPE_UNSIGNED (TREE_TYPE(@0)) && !TYPE_UNSIGNED (TREE_TYPE(@1))
&& wi::eq_p (wi::to_wide (@2),
wi::max_value (TYPE_PRECISION (TREE_TYPE (@2)),
SIGNED
@3
(That's not all of them, for that would be too long and I think it's not
necessary.)
I also tried it on a x86 laptop, seems it does work. But I got a bootstrap
issue. I don't know if it's caused by my patch or the version of gcc I used to
compile.
Another problem is that I can't craft some c/c++ code to test truth_and. Maybe
it's used by other languages? Is it necessary to use truth_and along side
bit_and?
I have to make this work on a ppc64le machine, could you give me some hints of
where to look into?
BTW, the following tests may be useful if you want test it on your machine:
#include
/* x > y && x != ( 0 or INT_MIN ) --> x > y */
_Bool f0 (unsigned x, unsigned y)
{
return x > y && x != 0;
}
_Bool f1 (unsigned x, unsigned y)
{
return y < x && x != 0;
}
_Bool f2 (unsigned x, unsigned y)
{
return x != 0 && x > y;
}
_Bool f3 (unsigned x, unsigned y)
{
return x != 0 && y < x;
}
_Bool f4 (int x, int y)
{
return x > y && x != INT_MIN;
}
_Bool f5 (int x, int y)
{
return y < x && x != INT_MIN;
}
_Bool f6 (int x, int y)
{
return x != INT_MIN && x > y;
}
_Bool f7 (int x, int y)
{
return x != INT_MIN && y < x;
}
_Bool f8 (unsigned char x, unsigned char y)
{
return x > y && x != 0;
}
/* x > y || x != ( 0 or XXX_MIN ) --> x != ( 0 or XXX_MIN ) */
_Bool f10 (unsigned x, unsigned y)
{
return x > y || x != 0;
}
_Bool f11 (int x, int y)
{
return x > y || x != INT_MIN;
}
_Bool f12 (unsigned char x, unsigned char y)
{
return x > y || x != 0;
}
_Bool f13 (signed char x, signed char y)
{
return x > y || x != SCHAR_MIN;
}
/* x < y && x != ( UXXX_MAX or XXX_MAX ) --> x < y */
_Bool f20 (unsigned x, unsigned y)
{
return x < y && x != UINT_MAX;
}
_Bool f21 (int x, int y)
{
return x < y && x != INT_MAX;
}
_Bool f22 (unsigned char x, unsigned char y)
{
return x < y && x != UCHAR_MAX;
}
_Bool f23 (signed char x, signed char y)
{
return x < y && x != SCHAR_MIN;
}
[Bug c++/68489] arrays of flexible array members are silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68489
--- Comment #6 from joseph at codesourcery dot com ---
I'm not sure about arrays of structs, but glibc uses [0] at end of struct
in some cases where proper flexible array members would not be accepted.
E.g.
struct __gconv_info
{
size_t __nsteps;
struct __gconv_step *__steps;
__extension__ struct __gconv_step_data __data[0];
}
which is then used as a non-last member of another structure.
[Bug go/90685] New: failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 Bug ID: 90685 Summary: failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu Product: gcc Version: 9.1.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: democritus7 at att dot net CC: cmang at google dot com Target Milestone: --- Here are the error msgs showing the build failure /home/me/gcc/buildgo/./gcc/gccgo -B/home/me/gcc/buildgo/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -g -O2 -I ../i686-pc-linux-gnu/libgo -static-libstdc++ -static-libgcc -L ../i686-pc-linux-gnu/libgo -L ../i686-pc-linux-gnu/libgo/.libs -o go ../../gcc-9.1.0/gotools/../libgo/go/cmd/go/alldocs.go ../../gcc-9.1.0/gotools/../libgo/go/cmd/go/go11.go ../../gcc-9.1.0/gotools/../libgo/go/cmd/go/main.go ../i686-pc-linux-gnu/libgo/libgotool.a go1: error: ‘-fsplit-stack’ currently only supported on GNU/Linux go1: error: ‘-fsplit-stack’ is not supported by this compiler configuration Makefile:821: recipe for target 'go' failed make[2]: *** [go] Error 1 make[2]: Leaving directory '/home/me/gcc/buildgo/gotools' Makefile:15524: recipe for target 'all-gotools' failed make[1]: *** [all-gotools] Error 2 make[1]: Leaving directory '/home/me/gcc/buildgo' Makefile:993: recipe for target 'all' failed Here's the configuration I started the build with in a clean folder ../gcc-9.1.0/configure --prefix=/usr --enable-libada --enable-libssp --enable-lto --enable-languages=go
[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90682
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-05-30
Ever confirmed|0 |1
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> I think we should treat a null handler as equivalent to abort, e.g.
>
> --- a/libstdc++-v3/libsupc++/eh_terminate.cc
> +++ b/libstdc++-v3/libsupc++/eh_terminate.cc
> @@ -44,7 +44,8 @@ __cxxabiv1::__terminate (std::terminate_handler handler)
> throw ()
> {
>__try
> {
> - handler ();
> + if (handler)
> + handler ();
>std::abort ();
> }
>__catch(...)
Another option would be to make set_terminate(nullptr) consistent with
pmr::set_default_resource(nullptr), i.e. restore the default:
--- a/libstdc++-v3/libsupc++/eh_terminate.cc
+++ b/libstdc++-v3/libsupc++/eh_terminate.cc
@@ -73,6 +73,14 @@ std::unexpected ()
std::terminate_handler
std::set_terminate (std::terminate_handler func) throw()
{
+#if _GLIBCXX_HOSTED && _GLIBCXX_VERBOSE && __cpp_exceptions
+ if (!func)
+func = __gnu_cxx::__verbose_terminate_handler;
+#else
+ if (!func)
+func = std::abort;
+#endif
+
std::terminate_handler old;
#if ATOMIC_POINTER_LOCK_FREE > 1
__atomic_exchange (&__terminate_handler, &func, &old, __ATOMIC_ACQ_REL);
This would mean that std::get_terminate() never returns a null pointer, and we
don't need to check for null in std::terminate(). This is what libc++ does.
Whatever we do for terminate/set_terminate we should also do for
unexpected/set_unexpected, e.g.
@@ -100,6 +108,9 @@ std::get_terminate () noexcept
std::unexpected_handler
std::set_unexpected (std::unexpected_handler func) throw()
{
+ if (!func)
+func = std::terminate;
+
std::unexpected_handler old;
#if ATOMIC_POINTER_LOCK_FREE > 1
__atomic_exchange (&__unexpected_handler, &func, &old, __ATOMIC_ACQ_REL);
[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #7 from Segher Boessenkool --- FAIL: g++.dg/cpp0x/pr90598.C -std=c++14 (test for excess errors) Excess errors: /home/segher/src/gcc/gcc/testsuite/g++.dg/cpp0x/pr90598.C:12:8: error: redefinition of 'struct A' /home/segher/src/gcc/gcc/testsuite/g++.dg/cpp0x/pr90598.C:15:20: error: redefinition of 'struct C' /home/segher/src/gcc/gcc/testsuite/g++.dg/cpp0x/pr90598.C:16:6: error: redefinition of 'C t' (on powerpc64-linux; sane with -std=c++17).
[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90682 --- Comment #2 from Jonathan Wakely --- It doesn't seem appropriate to me. If we don't want to support it we could just add __attribute__((__nonnull__)) to std::set_terminate, but I think we should support it (and so don't want it to produce any warnings).
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > Compiling > > print *, lshift(1,-1) > end > > gives the following error > > lshift.f90:1:16: > > 1 | print *, lshift(1,-1) > |1 > Error: Second argument of LSHIFT is negative at (1) > > While > > print *, ishft(2,-1) > end > > gives > >1 Can you please explain what you expect? Keep the current implementation, where negative shifts are disallowed for lshift/rshift? Then fix the documentation, explaining that negative shifts have undefined behavior. Related testcases in the testsuite need to be fixed. Or allow negative shifts, as in ishft?
[Bug d/89254] std.net.curl and std.parallelism unittests hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89254 --- Comment #3 from Rainer Orth --- (In reply to Iain Buclaw from comment #1) > I don't think you should be seeing a thread deadlock in std.net.curl after > r268746. Indeed, thanks. > I've not been able to reproduce the never timing out part. The process has > always been killed after 600 seconds. I've finally found what was wrong: DejaGnu 1.6.1 is toxic, sometimes failing to handle the timeouts. That why I saw that failure on different platforms (Linux, Solaris, ...) with different versions of expect. That part is gone with DejaGnu 1.6.2. I've now looked a bit closer at this hang (32-bit Linux/x86_64 only): WARNING: libphobos.phobos_shared/std/parallelism.d execution test program timed out. FAIL: libphobos.phobos_shared/std/parallelism.d execution test For one, the test raises an exception: core.thread.ThreadError@/vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/thread.d(3065): Error creating thread Since I didn't manage to print errno from gdb directly, I've just printed it: errno = Cannot allocate memory although pthread_create(3) doesn't document that error code. Stacktrace at that point is #0 core.thread.Thread.start() (this=) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/thread.d:733 #1 0x08063da8 in std.parallelism.TaskPool.this(uint) (this=0xf751c6c0, nWorkers=159) at /vol/gcc/src/hg/trunk/local/libphobos/testsuite/../src/std/parallelism.d:1461 #2 0x08063bf1 in std.parallelism.TaskPool.this() (this=0xf751c6c0) at /vol/gcc/src/hg/trunk/local/libphobos/testsuite/../src/std/parallelism.d:1432 #3 0x080672e4 in std.parallelism.__unittestL3941_11() () at /vol/gcc/src/hg/trunk/local/libphobos/testsuite/../src/std/parallelism.d:4148 #4 0x080691e2 in std.parallelism.__modtest() () at :1 #5 0xf789659c in __foreachbody2 (this=0xd208, m=0x80d0240 ) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/runtime.d:561 #6 0xf78c5631 in rt.minfo.__foreachbody2 (this=0xd194, sg=...) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/minfo.d:777 #7 0xf78ab899 in gcc.sections.elf_shared.DSO.opApply(scope int(ref gcc.sections.elf_shared.DSO) delegate) (dg=...) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/gcc/sections/elf_shared.d:109 #8 0xf78c771f in rt.minfo.moduleinfos_apply(scope int(immutable(object.ModuleIn fo*)) delegate) (dg=...) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/minfo.d:770 #9 0xf78b8f8f in object.ModuleInfo.opApply(scope int(object.ModuleInfo*) delegate) (dg=...) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/object.d:1598 #10 0xf7896990 in runModuleUnitTests () at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/runtime.d:551 #11 0xf78c1cdd in runAll (this=0xd4fc) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/dmain2.d:496 #12 0xf78c1861 in tryExec (this=this@entry=0xd4fc, dg=...) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/dmain2.d:472 #13 0xf78c1a6c in _d_run_main (argc=1, argv=0xd5f4, mainFunc=0x8069238 ) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/dmain2.d:505 #14 0x0806922d in main (argc=1, argv=0xd5f4) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/__entrypoint.di:44 #15 0xf7641c09 in __libc_start_main () from /lib/libc.so.6 #16 0x080627f6 in _start () This is on an 8-socket system with 10-core Xeon E7-8870. With hyperthreading, this makes for 160 threads. I've found no way to limit the degree of parallelism from the environment, std.parallelism.totalCPUs is always set to the number of cores. If I let the test continue from here, it hangs here #0 0xf7fd2b59 in __kernel_vsyscall () #1 0xf76f7080 in sched_yield () from /lib/libc.so.6 #2 0xf789e029 in core.thread.Thread.yield() () at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/thread.d:1326 #3 thread_joinAll () at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/core/thread.d:2361 #4 0xf78c1c0c in rt_term () at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/dmain2.d:218 #5 0xf78c1cb9 in runAll (this=0xd4fc) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/dmain2.d:501 #6 0xf78c1861 in tryExec (this=this@entry=0xd4fc, dg=...) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/dmain2.d:472 #7 0xf78c1a6c in _d_run_main (argc=1, argv=0xd5f4, mainFunc=0x8069238 ) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/rt/dmain2.d:505 #8 0x0806922d in main (argc=1, argv=0xd5f4) at /vol/gcc/src/hg/trunk/local/libphobos/libdruntime/__entrypoint.di:44 #9 0xf7641c09 in __libc_start_main () from /lib/libc.so.6 #10 0x080627f6 in _start () until it runs into the DejaGnu timeout.
[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 --- Comment #5 from Jim Wilson --- OK, sounds like we need to move STARTFILE_PREFIX_SPEC into various OS header files then. That will require some testing. I caught a virus last week and am behind on everything, so I haven't had a chance to try to do this yet.
[Bug go/90665] undefined C type 'int' with gcc 9.1.0 on solaric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90665 --- Comment #3 from Ian Lance Taylor --- Building with GCC is fine, and your configure options look fine. Please attach the output of go build -x ./... Thanks.
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 --- Comment #8 from martin --- Thanks for the clarification.
[Bug go/90665] undefined C type 'int' with gcc 9.1.0 on solaric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90665 --- Comment #2 from Thorsten A. Knieling --- May be I use the wrong configure options. I used a gcc compiler rather then an Solaris compiler to build gcc 9.1.0. My configure looks like this ../configure --prefix=/gcc-solaris-9.1.0 --enable-languages=c,c++,go,objc,lto Could you give an hint?
[Bug target/47099] i686-pc-msdosdjgpp fails to build i386.o: ASM_DECLARE_FUNCTION_NAME undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47099 Andris Pavenis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||andris at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Andris Pavenis --- Fix committed long time ago: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=acb1c4c499938d3bc00dacb1ca8179e4635f8a2b SVN revision 202016 from 2013
[Bug target/47093] [meta-bug]: broken configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093 Bug 47093 depends on bug 47099, which changed state. Bug 47099 Summary: i686-pc-msdosdjgpp fails to build i386.o: ASM_DECLARE_FUNCTION_NAME undefined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47099 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug testsuite/90683] new test case g++.dg/cpp0x/pr90598.C in r271752 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90683 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Sorry, seems I've applied it twice, fixed now.
[Bug c++/90598] [9/10 Regression] Return type of explicit destructor call wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90598 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu May 30 17:23:32 2019 New Revision: 271783 URL: https://gcc.gnu.org/viewcvs?rev=271783&root=gcc&view=rev Log: PR c++/90598 * tree.c (lvalue_kind): Return clk_none for expressions with with VOID_TYPE_P. * g++.dg/cpp0x/pr90598.C: New test. Modified: trunk/gcc/testsuite/g++.dg/cpp0x/pr90598.C
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 --- Comment #5 from Dominique d'Humieres --- Compiling print *, lshift(1,-1) end gives the following error lshift.f90:1:16: 1 | print *, lshift(1,-1) |1 Error: Second argument of LSHIFT is negative at (1) While print *, ishft(2,-1) end gives 1
[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90682 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- Is this something -Wterminate could warn about?
[Bug go/90665] undefined C type 'int' with gcc 9.1.0 on solaric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90665 --- Comment #1 from Ian Lance Taylor --- I built gccgo on a SPARC Solaris 12 machine, but was unable to recreate the problem. For me your program built and ran fine. Please attach the output of go build -x ./... Thanks.
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 --- Comment #7 from Ian Lance Taylor --- Among the requirements for gccgo is support for Thread Local Storage. If your system does not support that, gccgo cannot work.
[Bug fortran/61180] surprising -Wsurprising warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61180 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > This is the kind of PR I cannot contribute without some feedback. > > I did not get any for over five years: unassigning myself and in favor to > close the PR as WONTFIX. Did you submit a patch to fort...@gcc.gnu.org? Most discussion occurs in the fortran@ list not in the bugzilla database.
[Bug driver/90684] New alignment options incorrectly report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90684 Wilco changed: What|Removed |Added Component|middle-end |driver Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org --- Comment #1 from Wilco --- Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg02030.html
[Bug c++/71482] Add -Wglobal-constructors warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01860.html
[Bug fortran/61180] surprising -Wsurprising warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61180 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|ASSIGNED|WAITING Assignee|dominiq at lps dot ens.fr |unassigned at gcc dot gnu.org --- Comment #5 from Dominique d'Humieres --- This is the kind of PR I cannot contribute without some feedback. I did not get any for over five years: unassigning myself and in favor to close the PR as WONTFIX.
[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 --- Comment #14 from Martin Sebor --- Changing the size to zero is a variant of one the solutions I was referring to in comment #12: replacing the call with __builtin_unreachable. Rather than (possibly) eliminating (most of) the path leading up to it and everything after it, setting the size to zero would eliminate just the excessive call.
[Bug middle-end/90684] New: New alignment options incorrectly report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90684 Bug ID: 90684 Summary: New alignment options incorrectly report error Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: wilco at gcc dot gnu.org Target Milestone: --- GCC9 always reports an error when using -falign-functions=16:8:8 cc1: error: invalid number of arguments for ‘-falign-functions’ option: ‘16:8:8’ This is not working as documented in https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options. The issue is that the parser expects an undocumented macro SUBALIGN_LOG to be defined eventhough that is not necessary for the option parsing.
[Bug testsuite/90683] new test case g++.dg/cpp0x/pr90598.C in r271752 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90683 Dominique d'Humieres changed: What|Removed |Added Target|powerpc64*-unknown-linux-gn |powerpc64*-unknown-linux-gn |u |u, x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-30 Host|powerpc64*-unknown-linux-gn |powerpc64*-unknown-linux-gn |u |u, x86_64-*-* Ever confirmed|0 |1 Build|powerpc64*-unknown-linux-gn |powerpc64*-unknown-linux-gn |u |u, x86_64-*-* --- Comment #1 from Dominique d'Humieres --- Also seen on x86_64-*-*, e.g., https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg03267.html.
[Bug c++/68901] UBSan triggers false -Wpadded warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901 --- Comment #9 from Manuel López-Ibáñez --- (In reply to Trass3r from comment #7) > Created attachment 46435 [details] > cleanup > > The previous patch should also allow removing these hacks (untested). > Though TYPE_ARTIFICIAL wasn't set in any of these cases. Is that normal? You need to test it (and add testcases) and submit it. See: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug c++/68901] UBSan triggers false -Wpadded warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Trass3r from comment #5) > Wpadded only checks for input_location != BUILTINS_LOCATION currently > (stor-layout.c). > Maybe something like !DECL_ARTIFICIAL(rli->t) should be added there. Using input_location is very often wrong: https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Locations We are slowly moving to remove it.
[Bug testsuite/90683] New: new test case g++.dg/cpp0x/pr90598.C in r271752 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90683 Bug ID: 90683 Summary: new test case g++.dg/cpp0x/pr90598.C in r271752 has excess errors Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- The new test case has more errors than it thinks it should. Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -S -o pr90598.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -S -o pr90598.s /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:12:8: error: redefinition of 'struct A' /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:4:8: note: previous definition of 'struct A' /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:15:20: error: redefinition of 'struct C' /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:7:20: note: previous definition of 'struct C' /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:16:6: error: redefinition of 'C t' /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:8:6: note: 'C t' previously declared here compiler exited with status 1 FAIL: g++.dg/cpp0x/pr90598.C -std=c++17 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:12:8: error: redefinition of 'struct A' /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:15:20: error: redefinition of 'struct C' /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp0x/pr90598.C:16:6: error: redefinition of 'C t' testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/dg.exp completed in 0 seconds === g++ Summary === # of unexpected failures2 # of unsupported tests 1
[Bug c++/68901] UBSan triggers false -Wpadded warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901 --- Comment #7 from krux --- Created attachment 46435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46435&action=edit cleanup The previous patch should also allow removing these hacks (untested). Though TYPE_ARTIFICIAL wasn't set in any of these cases. Is that normal?
[Bug c++/68901] UBSan triggers false -Wpadded warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901 --- Comment #6 from krux --- Created attachment 46434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46434&action=edit proposed patch
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #49 from Martin Liška --- (In reply to Martin Liška from comment #48) > I see the performance is back as seen here: > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=21.270.0 > > -Ofast periodic tester hasn't finished yet, but I would close the PR. > Thank you Thomas! -Ofast -march native is also fine: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=23.270.0
[Bug libstdc++/90682] New: std::terminate() will happily call a null terminate handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90682
Bug ID: 90682
Summary: std::terminate() will happily call a null terminate
handler
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
std::set_terminate(nullptr);
std::terminate();
}
$ ./a.out
Segmentation fault (core dumped)
In C++98 this program had undefined behaviour, because set_terminate require a
non-null pointer argument. That was relaxed by
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm to make it
unspecified:
- Relax the current strong invariants of the set_unexpected and set_terminate
functions - the handler is never a null pointer value. This reduces
requirements on the implementor to define a non-null default handler. The
suggested wording does make the effects of setting a null pointer handler
unspecified, though.
I think we should treat a null handler as equivalent to abort, e.g.
--- a/libstdc++-v3/libsupc++/eh_terminate.cc
+++ b/libstdc++-v3/libsupc++/eh_terminate.cc
@@ -44,7 +44,8 @@ __cxxabiv1::__terminate (std::terminate_handler handler)
throw ()
{
__try
{
- handler ();
+ if (handler)
+ handler ();
std::abort ();
}
__catch(...)
[Bug tree-optimization/90681] [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90681 Martin Liška changed: What|Removed |Added Blocks||26163 --- Comment #1 from Martin Liška --- It's reduced from 416.gamess benchmark. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/90681] [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90681 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||9.1.0 Version|unknown |10.0 Keywords||ice-on-valid-code Last reconfirmed||2019-05-30 CC||alejandro.martinezvicente@a ||rm.com Ever confirmed|0 |1 Target Milestone|--- |10.0 Known to fail||10.0
[Bug tree-optimization/90681] New: [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90681 Bug ID: 90681 Summary: [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 46433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46433&action=edit test-case I see ICE in the attached test-case: $ gcc -O3 -march=znver1 ice.f -c during GIMPLE pass: vect ice.f:1:0: 1 | SUBROUTINE HMU (H1) | internal compiler error: in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 0x71222a vect_slp_analyze_node_operations_1 /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2513 0x71222a vect_slp_analyze_node_operations /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2604 0x1044ef7 vect_slp_analyze_node_operations /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2568 0x1044ef7 vect_slp_analyze_node_operations /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2568 0x10455c4 vect_slp_analyze_operations(vec_info*) /home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2633 0x1032505 vect_analyze_loop_2 /home/marxin/Programming/gcc/gcc/tree-vect-loop.c:2028 0x1034ee9 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*) /home/marxin/Programming/gcc/gcc/tree-vect-loop.c:2345 0x104e018 try_vectorize_loop_1 /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:884 0x104ed01 vectorize_loops() /home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1112
[Bug c/90680] New: Misleading fixit warning with pointers to pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90680
Bug ID: 90680
Summary: Misleading fixit warning with pointers to pointers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
Consider:
int main(void) {
struct { int a; } **p;
p->a; // error
}
gcc gives me:
: In function 'main':
:3:6: error: '*p' is a pointer; did you mean to use '->'?
3 | p->a;
| ^~
| ->
I realize that the error is good enough, since it does say that *p is a pointer
type, which is correct. But it should not tell me to use ->.
[Bug c/90677] [9/10 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.3.1 Keywords||rejects-valid Last reconfirmed||2019-05-30 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 Summary|gcc-9.1.0 fails to build|[9/10 Regression] gcc-9.1.0 |__gcc_diag__ souce: error: |fails to build __gcc_diag__ |'cgraph_node' is not|souce: error: 'cgraph_node' |defined as a type |is not defined as a type Target Milestone|--- |9.2 Known to fail||10.0, 9.1.0 --- Comment #4 from Jonathan Wakely --- Sorry, I misunderstood the report and the reduced example. I agree that your reduced code should compile. The regression started with r265918. It seems that after this change the identifier 'cgraph_node' can only be used for types, not variables. Since it's not a reserved name and could occur in user code, that's a bug. dump_printf: add "%C" for dumping cgraph_node * This patch implements support for %C in dump_printf for dumping cgraph_node *. (I would have preferred to have a code for printing symtab_node * and both subclasses, but there doesn't seem to be a good way for -Wformat to handle inheritance, so, failing that, I went with this approach). gcc/c-family/ChangeLog: * c-format.c (local_cgraph_node_ptr_node): New variable. (gcc_dump_printf_char_table): Add entry for %C. (get_pointer_to_named_type): New function, taken from the handling code for "gimple *" from... (init_dynamic_diag_info): ...here. Add handling for "cgraph_node *". * c-format.h (T_CGRAPH_NODE): New. gcc/ChangeLog: * dump-context.h (ASSERT_IS_CGRAPH_NODE): New macro. * dumpfile.c (make_item_for_dump_cgraph_node): Move to before... (dump_pretty_printer::decode_format): Implement "%C" for cgraph_node *. (selftest::test_capture_of_dump_calls): Rename "where" to "stmt_loc". Convert test_decl to a function decl and set its location. Add a symbol_table_test RAII instance and a cgraph_node, using it to test "%C" and dump_symtab_node. gcc/testsuite/ChangeLog: * gcc.dg/format/gcc_diag-10.c (cgraph_node): New typedef. (test_dump): Add testing of %C.
[Bug c++/90679] New: Template specialization with const: “ambiguous template instantiation” error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90679
Bug ID: 90679
Summary: Template specialization with const: “ambiguous
template instantiation” error
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nikolaus+...@nikolaus-demmel.de
Target Milestone: ---
The below repro-example should compile (IMHO), but it fails with "ambiguous
template instantiation". Same on gcc 7,8,9,trunk according to
https://godbolt.org/z/69Bomq, so probably not a regression.
clang compiles this just fine. See also
https://stackoverflow.com/q/56333067/1813258
Specializing traits> and traits> works fine, as does
traits> and traits>, so it seems to be this
combination.
In my real code `first_type` has some additional template parameters for
SFINAE.
$ g++-9 -Wall -Wextra foobar.cpp
foobar.cpp: In function 'int main()':
foobar.cpp:36:38: error: ambiguous template instantiation for 'struct
traits >'
36 | std::cout << traits>::N << std::endl;
| ^~
foobar.cpp:24:8: note: candidates are: 'template struct
traits > > [with C = const Foo]'
24 | struct traits>> {
|^~
foobar.cpp:30:8: note: 'template struct
traits > > [with C = Foo]'
30 | struct traits>> {
|^~~~
foobar.cpp:36:40: error: incomplete type 'traits >' used in
nested name specifier
36 | std::cout << traits>::N << std::endl;
|^
$ g++-9 -v
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/9.1.0/libexec/gcc/x86_64-apple-darwin16/9.1.0/lto-wrapper
Target: x86_64-apple-darwin16
Configured with: ../configure --build=x86_64-apple-darwin16
--prefix=/usr/local/Cellar/gcc/9.1.0
--libdir=/usr/local/Cellar/gcc/9.1.0/lib/gcc/9 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-9 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 9.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
Thread model: posix
gcc version 9.1.0 (Homebrew GCC 9.1.0)
$ cat foobar.cpp
#include
#include
class Foo {};
template
using first_type = T;
template
class Map {};
template
struct traits {};
//#define FIX_GCC
#ifdef FIX_GCC
template
struct traits {
static constexpr int N = 2;
};
#else
template
struct traits>> {
static constexpr int N = 2;
};
#endif
template
struct traits>> {
static constexpr int N = 3;
};
int main() {
std::cout << traits>::N << std::endl;
std::cout << traits>::N << std::endl;
return 0;
}
[Bug c++/68489] arrays of flexible array members are silently accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68489 --- Comment #5 from Nathan Sidwell --- if GCC rejects such arrays of trailing-array structs, and my assumption that glibc is in C, I don't think it can be using them. IMHO they don't make sense and a compile time error would be good.
[Bug middle-end/90673] A problem with 'copy destination size is too small' error in copy_from_user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90673 --- Comment #4 from Yaro Slav --- (In reply to Andrew Pinski from comment #1) > Can you provide the preprocessed source and the exact options being used? Options and version are here (apparently it's present in gcc 9.1.0 as well): https://gist.github.com/nathanchance/e36ad0fe2a4c2fb02aa630945a3bd70a Preprocessed file: https://gist.github.com/nathanchance/4afa9e39add076a1d2423f720fba07c0
[Bug c/90677] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 --- Comment #3 from Sergei Trofimovich --- Created attachment 46432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46432&action=edit tree-mudflap.i.gz If it helps here is complete tree-mudflap.i from gcc-4.6.4 as is: // fails: // $ x86_64-pc-linux-gnu-gcc-9.1.0 -c tree-mudflap.i -o tree-mudflap.o // works: // $ x86_64-pc-linux-gnu-gcc-8.3.0 -c tree-mudflap.i -o tree-mudflap.o
[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577
--- Comment #4 from Iain Sandoe ---
(In reply to Dominique d'Humieres from comment #3)
> Has the code
>
> /* Left and right shift C routines, to compare to Fortran results. */
> int c_lshift_ (int *x, int *y) { return (*x) << (*y); }
> int c_rshift_ (int *x, int *y) { return (*x) >> (*y); }
>
> a defined behavior for y<0?
No.
6.5.7 Bitwise shift operators
1 shift-expression: additive-expression
shift-expression << additive-expression
shift-expression >> additive-expression
Constraints
2 Each of the operands shall have integer type.
Semantics
3 The integer promotions are performed on each of the operands. The type of the
result is that of the promoted left operand. If the value of the right operand
is negative or is greater than or equal to the width of the promoted left
operand, the behavior is undefined.
[Bug c/90677] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 --- Comment #2 from Sergei Trofimovich --- (In reply to Jonathan Wakely from comment #1) > If the GCC 4.6.4 code is not valid C then it's not a bug to reject it. Can you clarify what specifically here is not valid C? Should gcc-8 also reject it? >From what I see gcc-9 has the same code in gcc/pretty-print.h as it used to be in gcc-4.6.4. I don't understand what requrements __gcc_diag__ imposes on the source to be "valid C". I can re-reduce tree-mudflap.i again to maintain the property.
[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577
--- Comment #3 from Dominique d'Humieres ---
Has the code
/* Left and right shift C routines, to compare to Fortran results. */
int c_lshift_ (int *x, int *y) { return (*x) << (*y); }
int c_rshift_ (int *x, int *y) { return (*x) >> (*y); }
a defined behavior for y<0?
The test succeeds if I use
do j = 0, 30
[Bug middle-end/12849] testing divisibility by constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12849 Wilco changed: What|Removed |Added Status|NEW |RESOLVED CC||wilco at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Wilco --- Fixed in GCC9.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #48 from Martin Liška --- I see the performance is back as seen here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=21.270.0 -Ofast periodic tester hasn't finished yet, but I would close the PR. Thank you Thomas!
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90539, which changed state. Bug 90539 Summary: [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #47 from Thomas Koenig --- Waiting for feedback on the speed issue.
[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646 --- Comment #9 from Jonathan Wakely --- (In reply to myLC from comment #8) > This is possible. I built 9.1.0 from source and got new issues, though. > Chances are, my system could be too old. The std::filesystem code (and everything else in libstdc++) should work fine on old systems, albeit with slightly degraded functionality or less efficient implementations for some features. I'll leave it with you, please feel free to reopen this bug if you do find a problem in GCC.
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #15 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #14) > It's true that the standard does not require path::iterator to be usable in > generic algorithms that expect forward iterators or bidirectional iterators. Indeed! Ability to run a modifying algorithm on a path's elements is extremely useful. Sorting path's components makes a lot of practical sense. So does std::random_shuffle them. And ability to heapify them (std::make_heap) is basically unavoidable in any app, which has to deal with filesystem::path. But what weirdo would want to store hundreds of thousands of paths without x10 memory overhead, right? So i agree. Just screw the C++ standard and do what you think is best for ppl out there. Thanks for your great work!
[Bug c++/68901] UBSan triggers false -Wpadded warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901 --- Comment #5 from krux --- Wpadded only checks for input_location != BUILTINS_LOCATION currently (stor-layout.c). Maybe something like !DECL_ARTIFICIAL(rli->t) should be added there.
[Bug go/90669] go/gofrontend/types.cc:2805 contains range-based ‘for’ loops which are not C++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90669 --- Comment #4 from Jonathan Wakely --- shabits.assign(digest.begin(), digest.end()) would've worked too, and not required any vector reallocations as it grows.
[Bug c/52981] Separate -Wpadded into two options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52981 --- Comment #8 from Manuel López-Ibáñez --- (In reply to krux from comment #6) > (In reply to Manuel López-Ibáñez from comment #4) > > This is quite easy to implement. > > It's not as trivial as one might think. > There's some copy-paste code to disable the flag in various places (instead > of handling it inside if possible). You can still have a global -Wpadded that implies the two new warning options and only warn, for example, if warn_padded && warn_packed_size are both true. Even better would be to mark these types as internal/ARTIFICIAL, look for all places where OPT_Wpadded is used and, if not already done, avoid warning for anything internal /ARTIFICIAL, then remove this hack. This should require no major surgery in the compiler nor any deep knowledge about the code.
[Bug c++/68901] UBSan triggers false -Wpadded warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68901 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez --- (In reply to krux from comment #3) > Yeah the warning is for an internal data structure, > see .Lubsan_data: https://godbolt.org/z/hFo8dZ It is possible to check that some code is compiler-generated and prevent warning. Search for ARTIFICIAL in the source code (maybe UBSAN code is marked in some other special way).
[Bug target/90678] [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90678
--- Comment #3 from Martin Liška ---
Reduced test-case:
$ cat strstream.ii
class basic_ios {
public:
virtual ~basic_ios();
};
class basic_ostream : virtual basic_ios {};
class strstream : basic_ostream {
~strstream();
};
strstream::~strstream() {}
$ ssh mli...@needle.suse.cz /home/mliska/Programming/gcc/objdir/gcc/xgcc
-B/home/mliska/Programming/gcc/objdir/gcc/ /tmp/x.ii
/tmp/x.ii: In member function ‘virtual void
strstream::_ZTv0_n24_N9strstreamD1Ev()’:
/tmp/x.ii:10:26: internal compiler error: in
aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865
10 | strstream::~strstream() {}
| ^
0x12555ef aarch64_return_address_signing_enabled()
../../gcc/config/aarch64/aarch64.c:4865
0x1255603 aarch64_post_cfi_startproc(_IO_FILE*, tree_node*)
../../gcc/config/aarch64/aarch64.c:15373
0xa75aff dwarf2out_do_cfi_startproc
../../gcc/dwarf2out.c:972
0xa9554f dwarf2out_begin_prologue(unsigned int, unsigned int, char const*)
../../gcc/dwarf2out.c:1106
0xb3abb7 final_start_function_1
../../gcc/final.c:1738
0xb3b44b final_start_function(rtx_insn*, _IO_FILE*, int)
../../gcc/final.c:1818
0x1257c5f aarch64_output_mi_thunk
../../gcc/config/aarch64/aarch64.c:6085
0xa1b81b cgraph_node::expand_thunk(bool, bool)
../../gcc/cgraphunit.c:1830
0xa1ce77 cgraph_node::assemble_thunks_and_aliases()
../../gcc/cgraphunit.c:2122
0xa1ce4b cgraph_node::assemble_thunks_and_aliases()
../../gcc/cgraphunit.c:2140
0xa1d08b cgraph_node::expand()
../../gcc/cgraphunit.c:2259
0xa1e3ab output_in_order
../../gcc/cgraphunit.c:2438
0xa1e3ab symbol_table::compile()
../../gcc/cgraphunit.c:2682
0xa214d7 symbol_table::compile()
../../gcc/cgraphunit.c:2864
0xa214d7 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2861
[Bug target/90678] [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90678 --- Comment #2 from Martin Liška --- $ as --version GNU assembler (GNU Binutils; openSUSE Leap 15.1) 2.31.1.20180828-lp151.2 $ ld --version GNU ld (GNU Binutils; openSUSE Leap 15.1) 2.31.1.20180828-lp151.2 $ uname -a Linux needle 4.12.14-lp151.27-default #1 SMP Fri May 10 14:13:15 UTC 2019 (862c838) aarch64 aarch64 aarch64 GNU/Linux
[Bug target/90678] [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90678 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||9.1.0 Version|unknown |10.0 Keywords||ice-on-valid-code Last reconfirmed||2019-05-30 CC||samtebbs at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |10.0 Known to fail||10.0
[Bug target/90678] [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90678 --- Comment #1 from Martin Liška --- libtool: compile: /home/mliska/Programming/gcc/objdir/./gcc/xgcc -shared-libgcc -B/home/mliska/Programming/gcc/objdir/./gcc -nostdinc++ -L/home/mliska/Programming/gcc/objdir/aarch64-unknown-linux-gnu/libstdc++-v3/src -L/home/mliska/Programming/gcc/objdir/aarch64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/mliska/Programming/gcc/objdir/aarch64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/mliska/bin/gcc/aarch64-unknown-linux-gnu/bin/ -B/home/mliska/bin/gcc/aarch64-unknown-linux-gnu/lib/ -isystem /home/mliska/bin/gcc/aarch64-unknown-linux-gnu/include -isystem /home/mliska/bin/gcc/aarch64-unknown-linux-gnu/sys-include -I/home/mliska/Programming/gcc/libstdc++-v3/../libgcc -I/home/mliska/Programming/gcc/objdir/aarch64-unknown-linux-gnu/libstdc++-v3/include/aarch64-unknown-linux-gnu -I/home/mliska/Programming/gcc/objdir/aarch64-unknown-linux-gnu/libstdc++-v3/include -I/home/mliska/Programming/gcc/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=strstream.lo -g -O2 -D_GNU_SOURCE -I/home/mliska/Programming/gcc/objdir/aarch64-unknown-linux-gnu/libstdc++-v3/include/backward -Wno-deprecated -c ../../../../../libstdc++-v3/src/c++98/strstream.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o strstream.o ../../../../../libstdc++-v3/src/c++98/strstream.cc: In member function ‘virtual void std::istrstream::_ZTv0_n24_NSt10istrstreamD1Ev()’: ../../../../../libstdc++-v3/src/c++98/strstream.cc:417:1: internal compiler error: in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 417 | } // namespace | ^ 0x12555ef aarch64_return_address_signing_enabled() ../../gcc/config/aarch64/aarch64.c:4865 0x1255603 aarch64_post_cfi_startproc(_IO_FILE*, tree_node*) ../../gcc/config/aarch64/aarch64.c:15373 0xa75aff dwarf2out_do_cfi_startproc ../../gcc/dwarf2out.c:972 0xa9554f dwarf2out_begin_prologue(unsigned int, unsigned int, char const*) ../../gcc/dwarf2out.c:1106 0xb3a7c7 final_start_function_1 ../../gcc/final.c:1734 0xb3b44b final_start_function(rtx_insn*, _IO_FILE*, int) ../../gcc/final.c:1818 0x1257c5f aarch64_output_mi_thunk ../../gcc/config/aarch64/aarch64.c:6085 0xa1b81b cgraph_node::expand_thunk(bool, bool) ../../gcc/cgraphunit.c:1830 0xa1ce77 cgraph_node::assemble_thunks_and_aliases() ../../gcc/cgraphunit.c:2122 0xa1ce4b cgraph_node::assemble_thunks_and_aliases() ../../gcc/cgraphunit.c:2140 0xa1d08b cgraph_node::expand() ../../gcc/cgraphunit.c:2259 0xa1e4ef expand_all_functions ../../gcc/cgraphunit.c:2332 0xa1e4ef symbol_table::compile() ../../gcc/cgraphunit.c:2683 0xa214d7 symbol_table::compile() ../../gcc/cgraphunit.c:2864 0xa214d7 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2861
[Bug target/90678] New: [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90678 Bug ID: 90678 Summary: [10 Regression] ICE in aarch64_return_address_signing_enabled, at config/aarch64/aarch64.c:4865 since r271735 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- I see it on my aarch64 machine, I'll provide a reduced test-case soon.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 krux changed: What|Removed |Added CC||hoganmeier at gmail dot com --- Comment #34 from krux --- Also fixes the duplicate https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12849. Can't close it though.
[Bug tree-optimization/90671] [10 Regression] ICE on valid code at -Os and above with -g enabled in gsi_split_seq_after, at gimple-iterator.c:345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90671 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 46431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46431&action=edit gcc10-pr90671.patch Untested fix. If during the first call the template block is empty, neither gsi_split_seq_after nor gsi_insert_seq_after can actually work. My understanding is in that case we want to hide the whole bb_seq from the create_block_for_threading because it contains only debug stmts we do not want to copy there.
[Bug target/90523] lto1 segfault in arm_parse_cpu_option_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523 krux changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from krux --- The callstacks are slightly different but probably it's still a duplicate. *** This bug has been marked as a duplicate of bug 87076 ***
[Bug target/87076] -mcpu/-march not propagated through LTO bytecode (ice/segfault if arch flags do not match)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87076 krux changed: What|Removed |Added CC||hoganmeier at gmail dot com --- Comment #5 from krux --- *** Bug 90523 has been marked as a duplicate of this bug. ***
[Bug c/90677] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 --- Comment #1 from Jonathan Wakely --- If the GCC 4.6.4 code is not valid C then it's not a bug to reject it.
[Bug c/90677] New: gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 Bug ID: 90677 Summary: gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- Minimal reproducer: $ cat tree-mudflap.i int cgraph_node; void a() __attribute__((__format__(__gcc_diag__, 2, 3))); $ LANG=C gcc-8.3.0 -fsyntax-only -c tree-mudflap.i $ LANG=C gcc-9.1.0 -fsyntax-only -c tree-mudflap.i tree-mudflap.i:2:1: error: 'cgraph_node' is not defined as a type 2 | void a() __attribute__((__format__(__gcc_diag__, 2, 3))); | ^~~~ The original build failure was observed on gcc-4.6.4. gcc-9.1.0 failed to to build gcc-4.6.4 while gcc-8.3.0 succeeded. I was not able to produce a reasonable workaround to make 4.6.4 compile again. gcc-4.6.4 failure looks like that: In file included from /tmp/portage/sys-devel/gcc-4.6.4-r1/work/gcc-4.6.4/gcc/diagnostic.h:25, from /tmp/portage/sys-devel/gcc-4.6.4-r1/work/gcc-4.6.4/gcc/tree-mudflap.c:41: /tmp/portage/sys-devel/gcc-4.6.4-r1/work/gcc-4.6.4/gcc/pretty-print.h:322:6: error: 'cgraph_node' is not defined as a type 322 | ATTRIBUTE_GCC_PPDIAG(2,3); | ^ /tmp/portage/sys-devel/gcc-4.6.4-r1/work/gcc-4.6.4/gcc/pretty-print.h:325:6: error: 'cgraph_node' is not defined as a type 325 | ATTRIBUTE_GCC_PPDIAG(2,3); | ^ I think there are two bugs here: - (major) gcc-9.1.0 fails to build the code that used to compile - (minor) diagnostic complains about 'cgraph_node' but does not mention it in warning text.
[Bug target/82920] cet test failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920 --- Comment #14 from Iain Sandoe --- Author: iains Date: Thu May 30 08:00:45 2019 New Revision: 271766 URL: https://gcc.gnu.org/viewcvs?rev=271766&root=gcc&view=rev Log: Darwin, backport fix for PR82920 part3 (other CET test fixes). gcc/testsuite/ 2019-05-30 Iain Sandoe Backport from mainline. 2019-05-15 Iain Sandoe PR target/82920 * g++.dg/cet-notrack-1.C: Adjust scan assembler for Darwin. * gcc.target/i386/cet-notrack-5a.c: Likewise. * gcc.target/i386/cet-notrack-5b.c: Likewise. * gcc.target/i386/cet-notrack-6b.c: Likewise. * gcc.target/i386/cet-notrack-icf-1.c: Likewise. * gcc.target/i386/cet-notrack-icf-2.c: Likewise. * gcc.target/i386/cet-notrack-icf-3.c: Likewise. * gcc.target/i386/cet-notrack-icf-4.c: Likewise. * gcc.target/i386/cet-sjlj-3.c: Likewise. * gcc.target/i386/cet-sjlj-5.c: Likewise. Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/g++.dg/cet-notrack-1.C branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-notrack-5a.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-notrack-5b.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-notrack-6b.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-notrack-icf-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-notrack-icf-2.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-notrack-icf-3.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-notrack-icf-4.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-sjlj-3.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-sjlj-5.c
[Bug target/82920] cet test failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920 --- Comment #13 from Iain Sandoe --- Author: iains Date: Thu May 30 07:56:10 2019 New Revision: 271765 URL: https://gcc.gnu.org/viewcvs?rev=271765&root=gcc&view=rev Log: Darwin, backport fix for PR82920 part2 (mx32 is not supported) gcc/ 2019-05-30 Iain Sandoe Backport from mainline. 2019-05-12 Iain Sandoe PR target/82920 * config/i386/darwin.h (CC1_SPEC): Report -mx32 as an error for Darwin. gcc/testsuite/ 2019-05-30 Iain Sandoe Backport from mainline. 2019-05-14 Iain Sandoe PR target/82920 * gcc.target/i386/cet-sjlj-6b.c: Require effective target x32. * gcc.target/i386/pr52146.c: Likewise. * gcc.target/i386/pr52698.c: Likewise. * gcc.target/i386/pr52857-1.c: Likewise. * gcc.target/i386/pr52857-2.c: Likewise. * gcc.target/i386/pr52876.c: Likewise. * gcc.target/i386/pr53698.c: Likewise. * gcc.target/i386/pr54157.c: Likewise. * gcc.target/i386/pr55049-1.c: Likewise. * gcc.target/i386/pr55093.c: Likewise. * gcc.target/i386/pr55116-1.c: Likewise. * gcc.target/i386/pr55116-2.c: Likewise. * gcc.target/i386/pr55597.c: Likewise. * gcc.target/i386/pr59929.c: Likewise. * gcc.target/i386/pr66470.c: Likewise. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/i386/darwin.h branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr52146.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr52698.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr52857-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr52857-2.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr52876.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr53698.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr54157.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr55049-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr55093.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr55116-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr55116-2.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr55597.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr59929.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr66470.c
[Bug target/82920] cet test failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920 --- Comment #12 from Iain Sandoe --- Author: iains Date: Thu May 30 07:51:32 2019 New Revision: 271764 URL: https://gcc.gnu.org/viewcvs?rev=271764&root=gcc&view=rev Log: Darwin, backport fix for pr82920 (part1, code) gcc/ 2019-05-30 Iain Sandoe Backport from mainline. 2019-05-12 Iain Sandoe PR target/82920 * config/i386/i386.c (ix86_output_jmp_thunk_or_indirect): New. (ix86_output_indirect_branch_via_reg): Use output mechanism accounting for __USER_LABEL_PREFIX__. (ix86_output_indirect_branch_via_push): Likewise. (ix86_output_function_return): Likewise. (ix86_output_indirect_function_return): Likewise. gcc/testsuite/ 2019-05-30 Iain Sandoe Backport from mainline. 2019-05-12 Iain Sandoe Dominique d'Humieres PR target/82920 * gcc.target/i386/indirect-thunk-1.c: Adjust scan-asms for Darwin, do not use -fno-pic on Darwin. * gcc.target/i386/indirect-thunk-2.c: Likewise. * gcc.target/i386/indirect-thunk-3.c: Likewise. * gcc.target/i386/indirect-thunk-4.c: Likewise. * gcc.target/i386/indirect-thunk-7.c: Likewise. * gcc.target/i386/indirect-thunk-attr-1.c: Likewise. * gcc.target/i386/indirect-thunk-attr-2.c: Likewise. * gcc.target/i386/indirect-thunk-attr-3.c: Likewise. * gcc.target/i386/indirect-thunk-attr-4.c: Likewise. * gcc.target/i386/indirect-thunk-attr-5.c: Likewise. * gcc.target/i386/indirect-thunk-attr-6.c: Likewise. * gcc.target/i386/indirect-thunk-attr-7.c: Likewise. * gcc.target/i386/indirect-thunk-attr-8.c: Likewise. * gcc.target/i386/indirect-thunk-extern-1.c: Likewise. * gcc.target/i386/indirect-thunk-extern-2.c: Likewise. * gcc.target/i386/indirect-thunk-extern-3.c: Likewise. * gcc.target/i386/indirect-thunk-extern-4.c: Likewise. * gcc.target/i386/indirect-thunk-extern-7.c: Likewise. * gcc.target/i386/indirect-thunk-inline-1.c: Likewise. * gcc.target/i386/indirect-thunk-inline-2.c: Likewise. * gcc.target/i386/indirect-thunk-inline-3.c: Likewise. * gcc.target/i386/indirect-thunk-inline-4.c: Likewise. * gcc.target/i386/indirect-thunk-inline-7.c: Likewise. * gcc.target/i386/indirect-thunk-register-1.c: Likewise. * gcc.target/i386/indirect-thunk-register-2.c: Likewise. * gcc.target/i386/indirect-thunk-register-3.c: Likewise. * gcc.target/i386/indirect-thunk-register-4.c: Likewise. * gcc.target/i386/ret-thunk-1.c: Likewise. * gcc.target/i386/ret-thunk-10.c: Likewise. * gcc.target/i386/ret-thunk-11.c: Likewise. * gcc.target/i386/ret-thunk-12.c: Likewise. * gcc.target/i386/ret-thunk-13.c: Likewise. * gcc.target/i386/ret-thunk-14.c: Likewise. * gcc.target/i386/ret-thunk-15.c: Likewise. * gcc.target/i386/ret-thunk-16.c: Likewise. * gcc.target/i386/ret-thunk-2.c: Likewise. * gcc.target/i386/ret-thunk-22.c: Likewise. * gcc.target/i386/ret-thunk-23.c: Likewise. * gcc.target/i386/ret-thunk-24.c: Likewise. * gcc.target/i386/ret-thunk-3.c: Likewise. * gcc.target/i386/ret-thunk-4.c: Likewise. * gcc.target/i386/ret-thunk-5.c: Likewise. * gcc.target/i386/ret-thunk-6.c: Likewise. * gcc.target/i386/ret-thunk-7.c: Likewise. * gcc.target/i386/ret-thunk-8.c: Likewise. * gcc.target/i386/ret-thunk-9.c: Likewise. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/i386/i386.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-2.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-3.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-4.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-5.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-6.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-8.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-2.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/in
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 --- Comment #6 from Eric Botcazou --- > Are there any chances to get gccgo build on this machine by the following > options? > - crosscompiling > - update libc Cross-compiling doesn't really matter here if you ultimately need to run the Go programs on the machines. You probably need to update the entire system.
[Bug middle-end/90676] [9 Regression] ambiguous GIMPLE after store merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90676 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Maybe the way to go in this case, if the alias type doesn't match the access size and size can't be determined say from SSA_NAME on the rhs might be to write an explicit cast on the rhs. And, it might be useful to have a -fdump-tree-*- flag that would annotate all loads/stores in the IL with bit offsets/sizes of the access, I remember a few months ago I was trying to debug some bug that involved a lot of C++ std::pair constructions and extractions, most of the temporaries had pair type (so impossible to find out which exact one it is, if it is say std::pair, std::pair> or whatever other pair of pairs or what else), some MEMs used visible offsets, other accesses used COMPONENT_REFs with artificial fields etc., so without actually dumping the bitsize/bitoffset the dump was impossible to understand.
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 --- Comment #5 from martin --- Are there any chances to get gccgo build on this machine by the following options? - crosscompiling - update libc
[Bug gcov-profile/90672] FAIL: gcc.misc-tests/gcov-pr86536.c line 21: is 1:should be 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90672 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-30 Ever confirmed|0 |1
[Bug debug/90674] [7/8/9/10 Regression] ICE in gen_subprogram_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90674 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||6.5.0 Version|10.0|7.4.0 Keywords||ice-on-valid-code Last reconfirmed||2019-05-30 CC||aoliva at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|[7.1 Regression] ICE in |[7/8/9/10 Regression] ICE |gen_subprogram_die |in gen_subprogram_die Target Milestone|--- |7.5 Known to fail||10.0, 7.4.0, 8.3.0, 9.1.0 --- Comment #2 from Martin Liška --- Confirmed, started with Alexander's r239403.
[Bug tree-optimization/90671] [10 Regression] ICE on valid code at -Os and above with -g enabled in gsi_split_seq_after, at gimple-iterator.c:345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90671 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||9.1.0 Version|unknown |10.0 Keywords||ice-on-valid-code Last reconfirmed||2019-05-30 CC||aoliva at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE on valid code at -Os|[10 Regression] ICE on |and above with -g enabled |valid code at -Os and above |in gsi_split_seq_after, at |with -g enabled in |gimple-iterator.c:345 |gsi_split_seq_after, at ||gimple-iterator.c:345 Target Milestone|--- |10.0 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with Alexander's r271477.
