[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Since I am the guilty party, I had better take it :-) Cheers Paul
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Thu Jul 4 05:10:52 2019 New Revision: 273039 URL: https://gcc.gnu.org/viewcvs?rev=273039=gcc=rev Log: PR middle-end/91069 * gcc.dg/pr91069.c (v2df): Use 2 * sizeof (double) instead of hardcoded 16 for better portability. (v2di): Change from long vector to long long vector. Use 2 * sizeof (long long) instead of hardcoded 16. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr91069.c
[Bug tree-optimization/91074] [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91074 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jul 4 04:54:52 2019 New Revision: 273037 URL: https://gcc.gnu.org/viewcvs?rev=273037=gcc=rev Log: PR tree-optimization/91074 * omp-low.c (lower_omp_for_scan): Set DECL_GIMPLE_REG_P on cplx temporary. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c
[Bug c++/91082] New: Reference to function binds to pointer to function when given a template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91082
Bug ID: 91082
Summary: Reference to function binds to pointer to function
when given a template specialization
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
In the following code, gcc accepts the code in `c`, but rejects the code in
`d`. I believe both should be rejected, because it is attempting to bind a
pointer to a reference.
template
void a();
void b();
void c() {
static_cast();
}
void d() {
static_cast();
}
See it live: https://godbolt.org/z/zguy6D
[Bug rtl-optimization/90756] [7/8/9/10 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Thu Jul 4 04:49:22 2019 New Revision: 273036 URL: https://gcc.gnu.org/viewcvs?rev=273036=gcc=rev Log: PR rtl-optimization/90756 * explow.c (promote_ssa_mode): Always use TYPE_MODE, don't bypass it for VECTOR_TYPE_P. * gcc.dg/pr90756.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr90756.c Modified: trunk/gcc/ChangeLog trunk/gcc/explow.c trunk/gcc/testsuite/ChangeLog
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 Eric Gallager changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #17 from Eric Gallager --- Richard Sandiford had a series of patches radically overhauling how -Og works in general that might affect this bug: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html cc-ing him so he can comment on if it does in fact affect this bug.
[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77278 --- Comment #8 from Eric Gallager --- (In reply to Richard Biener from comment #6) > Confirmed. It was the original intent to allow this, esp. for libgfortran > for example. That's bug 77278
[Bug target/38629] target-specific parameters for inline heuristics not defined for AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38629 --- Comment #11 from Eric Gallager --- (In reply to Federico Fissore from comment #8) > I forgot to say: this result came out of avr-gcc 4.8.1 (packaged by Arduino: > it's a 4.8.1 with two small patches applied [1]). It uses -Os optimization > flag > > [1] https://github.com/arduino/toolchain-avr/tree/master/gcc-patches This link no longer works
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #31 from EML --- (In reply to dave.anglin from comment #26) > On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote: > > If I replace those 3 lines and run the assembler+linker by hand - the > > non-working foo.s will run correctly > So, HAVE_AS_LTOFFX_LDXMOV_RELOCS is probably not defined. The configure > script is > likely not detecting this assembler capability correctly. > > Are you using bash shell? If not, I suggest that you use it instead of HP > shell. This macro only seems to control whether you use ltoffx or ltoff. I can confirm I am using bash, and #define HAVE_AS_LTOFFX_LDXMOV_RELOCS 1 in gcc/config.h I also added in an #error to the code to make sure. It is definitely set.
[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924
--- Comment #5 from Ren Kimura ---
Yes. I can understand what you want to say. It may annoying for developers to
fix such nitpicky bugs.
But unfortunately these kind of bugs have been reported like, memory corruption
with *crafted* ELF file.
https://www.google.com/search?q=binutils+crafted+elf+cve
>From the perspective of attackers, they can prevent some kind of services by
sending crafted ELF file through network. i.e. Denial of Service.
Please consider our request of fixing.
Thanks
(In reply to Martin Liška from comment #4)
> (In reply to Ren Kimura from comment #3)
> > Hi. Sorry for late. I've just attached more simple one.
> >
> > PoC file for this bug can be created easily, just generating ELF file and
> > edit e_shstrndx in ELF header file to 0.
> >
> > Attached one is built from simple Hello World program.
> >
> > #include
> > int main() {
> > printf("Hello World\n");
> > };
> >
> > gcc -o memcorrupt_nm-2.30_gcc-9.1.0_gold_simple hello_world.c
> >
> > Edit e_shtrndx (offset 0x3E) to 0.
>
> What sense does it make to create a valid ELF container and then corrupt it?
> It's expected that various tools will crash then.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #27 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #26) > Jerry, you are working on a Linux box, right? What does > > stat -f -c %b . > > tell you? 13429330 Ryzen 2500U with M.2 SSD Fedora 30, Kernel 5.1.15-300.fc30.x86_64
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #30 from The Written Word --- (In reply to dave.anglin from comment #29) > On 2019-07-03 7:20 p.m., bugzilla-gcc at thewrittenword dot com wrote: > > configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc > > -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ > > -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i > > a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include > > -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 > > -g > > conftest.c >&5 > > configure:8057: $? = 0 > > configure:8057: ./conftest > > /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 > > Memoryfault(coredum > > p) > > The configure test needs to be debugged in the same manner as the "hello > world" program. Yeah, we've already looked at the difference between 4.9.4/8.3.0 assembly but want to rebuild 8.3.0 with as few patches as possible to ensure the issue isn't some patch we've introduced.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #29 from dave.anglin at bell dot net --- On 2019-07-03 7:20 p.m., bugzilla-gcc at thewrittenword dot com wrote: > configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc > -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ > -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i > a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include > -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g > conftest.c >&5 > configure:8057: $? = 0 > configure:8057: ./conftest > /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 > Memoryfault(coredum > p) The configure test needs to be debugged in the same manner as the "hello world" program.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #28 from The Written Word --- (In reply to EML from comment #17) > Note that in certain cases, the MPFR library won't build depending on the > CFLAGS used (in particular the default -g -O2), this is due to problems with > thread local storage. You can work around this by configuring MPFR with > --disable-thread-safe We are building GCC against mpfr-3.1.6 but MPFR wasn't a difficult build on HP-UX/IA. We are building with the HP C compiler though. The MPFR testsuite passed all but one test which was a PASS. And, ./configure shows -DMPFR_USE_THREAD_SAFE=1.
[Bug middle-end/90773] Improve piecewise operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #4 from Jeffrey A. Law --- But isn't -Os a better choice if we care about this? It gives more compact code. I guess I'm just not sure optimizing this using an overlapping store is all that important.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #27 from The Written Word --- (In reply to dave.anglin from comment #26) > On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote: > > If I replace those 3 lines and run the assembler+linker by hand - the > > non-working foo.s will run correctly > So, HAVE_AS_LTOFFX_LDXMOV_RELOCS is probably not defined. The configure > script is > likely not detecting this assembler capability correctly. > > Are you using bash shell? If not, I suggest that you use it instead of HP > shell. It's set to 1 for us. We're getting a segfault while building libstdc++-v3 with 8.3.0: configure:7964: checking for ANSI C header files configure:7984: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/ia64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-c -O2 -g conftest.c >&5 configure:7984: $? = 0 configure:8057: /opt/build/china/gcc-8.3.0/.obj/./gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/./gcc/ -B/opt/build/gcc8/ia64-hp-hpux11.31/bin/ -B/opt/build/gcc8/i a64-hp-hpux11.31/lib/ -isystem /opt/build/gcc8/ia64-hp-hpux11.31/include -isystem /opt/build/gcc8/ia64-hp-hpux11.31/sys-include-o conftest -O2 -g conftest.c >&5 configure:8057: $? = 0 configure:8057: ./conftest /opt/build/china/gcc-8.3.0/libstdc++-v3/configure[20]: 1572 Memoryfault(coredum p) configure:8057: $? = 139 Using the stage 1 8.3.0 compiler, we can get a simple "hello world" program to compile.
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #26 from dave.anglin at bell dot net --- On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote: > If I replace those 3 lines and run the assembler+linker by hand - the > non-working foo.s will run correctly So, HAVE_AS_LTOFFX_LDXMOV_RELOCS is probably not defined. The configure script is likely not detecting this assembler capability correctly. Are you using bash shell? If not, I suggest that you use it instead of HP shell.
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #7 from Alan Modra --- Huh, I'd forgotten that gas only reloads the opcode table when the cpu changes. Be aware that .machine isn't a complete solution as it doesn't fix a wrong gas command line for "gcc -c asm.S". You can't insert .machine in that case!
[Bug c++/83374] [DR1813] Bad std::is_standard_layout with two base class subobjects of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83374 Marek Polacek changed: What|Removed |Added Keywords||accepts-invalid, patch, ||rejects-valid --- Comment #4 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00304.html
[Bug c++/91081] New: [DR 2120] Array as first non-static data member in standard-layout class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91081
Bug ID: 91081
Summary: [DR 2120] Array as first non-static data member in
standard-layout class
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Cf. https://wg21.link/cwg2120
Test:
struct A {};
struct B : A {};
struct C { A a; };
struct D { C c[5]; };
struct E : B { D d; };
static_assert(__is_standard_layout(B), "");
static_assert(__is_standard_layout(D), "");
static_assert(!__is_standard_layout(E), "");
[Bug c++/91080] New: [DR 1672] Layout compatibility with multiple empty bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91080
Bug ID: 91080
Summary: [DR 1672] Layout compatibility with multiple empty
bases
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Cf. https://wg21.link/cwg1672
Test (from the clang testsuite):
struct Empty {};
struct A : Empty {};
struct B { Empty e; };
struct C : A { B b; int n; };
struct D : A { int n; B b; };
static_assert(!__is_standard_layout(C), "");
static_assert(__is_standard_layout(D), "");
struct E { B b; int n; };
struct F { int n; B b; };
union G { B b; int n; };
union H { int n; B b; };
struct X {};
template struct Y : X, A { T t; };
static_assert(!__is_standard_layout(Y), "");
static_assert(__is_standard_layout(Y), "");
static_assert(!__is_standard_layout(Y), "");
static_assert(!__is_standard_layout(Y), "");
static_assert(!__is_standard_layout(Y), "");
[Bug c++/91079] New: [DR 1881] Standard-layout classes and unnamed bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91079
Bug ID: 91079
Summary: [DR 1881] Standard-layout classes and unnamed
bit-fields
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Cf. https://wg21.link/cwg1881
Test:
struct A { int a : 4; };
struct B : A { int b : 3; };
static_assert(__is_standard_layout(A), "");
static_assert(!__is_standard_layout(B), "");
struct C { int : 0; };
struct D : C { int : 0; };
static_assert(__is_standard_layout(C), "");
static_assert(!__is_standard_layout(D), "");
[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #25 from EML ---
I have applied the patch and tried your other suggestions, still the stage1
compiler has the same problems generating executables.
In analyzing the intermediate files between working (gcc 4.93) and not
(bootstrap 8.3), the intermediate files seem similar until the "mach" stage
The problem seems to be in out the compiler decides to reference a string in
the source.
My program is:
#include
int main()
{
printf("Hellos World\n");
return 0;
}
The generated .s file for Working does this:
.LC0:
stringz "Hellos World"
addl r36 = @ltoffx(.LC0), r1
;;
ld8.mov r36 = [r36], .LC0
The non-working .s file does this:
.LC0:
stringz "Hellos World"
movl r36 = @gprel(.LC0)
;;
add r36 = r1, r36
If I replace those 3 lines and run the assembler+linker by hand - the
non-working foo.s will run correctly
[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-03 CC||pault at gcc dot gnu.org Known to work||7.4.0 Ever confirmed|0 |1 Known to fail||10.0, 8.3.0, 9.1.0 --- Comment #2 from Dominique d'Humieres --- Likely revision r251949 (r251946 is OK, wrong code at r251980).
[Bug lto/91078] [10 regression] All LTO tests FAIL: SIGBUS in lto1 (lto_file_finalize)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91078 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug lto/91078] New: [10 regression] All LTO tests FAIL: SIGBUS in lto1 (lto_file_finalize)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91078 Bug ID: 91078 Summary: [10 regression] All LTO tests FAIL: SIGBUS in lto1 (lto_file_finalize) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Between 20190702 (r272944) and 20190703 (r273009), all LTO tests started to FAIL on Solaris/SPARC. It boils down to $ cat /var/tmp//ccqNGG1b 20010124-1.o 20010124-1-lib.o main.o $ lto1 -quiet @/var/tmp//ccqNGG1b -o 20010124-1.s [...] lto1: internal compiler error: Bus Error 0x9d1597 crash_signal /vol/gcc/src/hg/trunk/local/gcc/toplev.c:326 0x3fea74 lto_file_finalize /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2202 0x3fea74 lto_create_files_from_ids /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2225 0x3fea74 lto_file_read /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2279 0x3fea74 read_cgraph_and_symbols(unsigned int, char const**) /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2731 0x3dd10b lto_main() /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:616 Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] lto_file_finalize (file=0x16a6370, file_data=0xfa886050) at /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2202 2202 file_data->lto_section_header = *(const lto_section *)data; (gdb) where #0 lto_file_finalize (file=0x16a6370, file_data=0xfa886050) at /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2202 #1 lto_create_files_from_ids (count=, file_data=0xfa886050, file=0x16a6370) at /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2225 #2 lto_file_read (count=, resolution_file=0x0, file=) at /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2279 #3 read_cgraph_and_symbols (nfiles=, fnames=) at /vol/gcc/src/hg/trunk/local/gcc/lto/lto-common.c:2731 #4 0x003dd10c in lto_main () at /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:616 #5 0x009d1610 in compile_file () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:456 #6 0x009d4128 in do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2209 #7 toplev::main (this=0xffbfe4de, argc=, argv=) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2344 #8 0x012f11ac in main (argc=27, argv=0xffbfe544) at /vol/gcc/src/hg/trunk/local/gcc/main.c:39 (gdb) p/x data $1 = 0xfb9d8429 gdb showing this as SIGSEGV is a gdb bug. This most likely affects all strict-alignment targets.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.3.0 Keywords||rejects-valid Last reconfirmed||2019-07-03 CC||paolo at gcc dot gnu.org Ever confirmed|0 |1 Summary|if constexpr no longer |[9/10 Regression] if |works directly with |constexpr no longer works |Concepts|directly with Concepts Known to fail||10.0, 9.1.0 --- Comment #1 from Jonathan Wakely --- Confirmed as a regression (GCC 8 accepts it, if 'concept HasInit' is replaced with 'concept bool HasInit'). It started to be rejected with r260482: PR c++/84588 * parser.c (cp_parser_maybe_commit_to_declaration, cp_parser_check_condition_declarator): New. (cp_parser_simple_declaration): Use the first above. (cp_parser_condition): Use both the above; enforce [stmt.stmt]/2 about the declarator not specifying a function or an array; improve error-recovery.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Fixed on trunk and for GCC 9.2, thanks for finding and reporting the bug!
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Wed Jul 3 21:09:13 2019 New Revision: 273025 URL: https://gcc.gnu.org/viewcvs?rev=273025=gcc=rev Log: PR libstdc++/91067 fix missing exports for filesystem iterators The copy assignment operator for recursive_directory_iterator was not exported despite being needed. The __shared_ptr default constructors are not needed when compiling with GCC but Clang requires them for -O1. PR libstdc++/91067 * acinclude.m4 (libtool_VERSION): Bump to 6:27:0. * configure: Regenerate. * config/abi/pre/gnu.ver (GLIBCXX_3.4.27): Add new version. Export missing symbols. * testsuite/27_io/filesystem/iterators/91067.cc: New test. * testsuite/util/testsuite_abi.cc: Add new symbol version. Added: branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/iterators/91067.cc Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/acinclude.m4 branches/gcc-9-branch/libstdc++-v3/config/abi/pre/gnu.ver branches/gcc-9-branch/libstdc++-v3/configure branches/gcc-9-branch/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Wed Jul 3 21:06:25 2019 New Revision: 273023 URL: https://gcc.gnu.org/viewcvs?rev=273023=gcc=rev Log: PR libstdc++/91067 fix missing exports for filesystem iterators The copy assignment operator for recursive_directory_iterator was not exported despite being needed. The __shared_ptr default constructors are not needed when compiling with GCC but Clang requires them for -O1. PR libstdc++/91067 * acinclude.m4 (libtool_VERSION): Bump to 6:27:0. * configure: Regenerate. * config/abi/pre/gnu.ver (GLIBCXX_3.4.27): Add new version. Export missing symbols. * testsuite/27_io/filesystem/iterators/91067.cc: New test. * testsuite/util/testsuite_abi.cc: Add new symbol version. Added: trunk/libstdc++-v3/testsuite/27_io/filesystem/iterators/91067.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug c++/91064] __is_standard_layout incorrect for a class with multiple bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91064 --- Comment #4 from Martin Sebor --- Yes, my example in comment #0 is missing the derivation from Q. So the sentence has at most one base class subobject of any given type doesn't mean that a std layout class cannot have multiple base class subobjects, just that none of them can be of a type that's derived, either directly or indirectly, from the same base class. Okay, thanks.
[Bug c++/91076] wrong class-key in mentioned in a diagnostic note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91076 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-03 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I'm testing (what I'm hoping will stay) a simple patch.
[Bug libstdc++/90409] std::move[_backward] could be more optimized for deque iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90409 François Dumont changed: What|Removed |Added Status|NEW |ASSIGNED CC||fdumont at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #1 from François Dumont --- Patch awaiting on mailing list: https://gcc.gnu.org/ml/libstdc++/2019-06/msg00097.html
[Bug c++/91064] __is_standard_layout incorrect for a class with multiple bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91064 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Note the testcase here is actually wrong; U *is* a standard-layout class. The standard has a different test.
[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077 Thomas Koenig changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Thomas Koenig --- Note that this works when the variable std is changed to an allocatable.
[Bug fortran/91077] New: [8/9/10 Regression] Wrong indexing when using a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
Bug ID: 91077
Summary: [8/9/10 Regression] Wrong indexing when using a
pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
From a c.l.f. post by ygalkl...@gmail.com (slightly modified):
program test
implicit none
integer, parameter :: length = 9
real(8), dimension(2) :: a, b
integer :: i
type point
real(8) :: x
end type point
type stored
type(point), dimension(:), allocatable :: np
end type stored
type(stored), dimension(:), pointer :: std =>null()
allocate(std(1))
allocate(std(1)%np(length))
std(1)%np(1)%x = 0.3d0
std(1)%np(2)%x = 0.3555d0
std(1)%np(3)%x = 0.26782d0
std(1)%np(4)%x = 0d0
std(1)%np(5)%x = 1.555d0
std(1)%np(6)%x = 7.3d0
std(1)%np(7)%x = 7.8d0
std(1)%np(8)%x = 6.3d0
std(1)%np(9)%x = 5.5d0
do i = 1, 2
write(*, "('std(1)%np(',i1,')%x = ',1e22.14)") i, std(1)%np(i)%x
end do
do i = 1, 2
write(*, "('std(1)%np(1:',i1,') = ',9e22.14)") i, std(1)%np(1:i)%x
end do
a = std(1)%np(1:2)%x
b = [std(1)%np(1)%x, std(1)%np(2)%x]
print *,a
print *,b
if (norm2(a - b) .gt. 1d-3) then
write(*,*) 'failure'
else
write(*, *) 'success'
end if
end program test
yields
std(1)%np(1)%x = 0.30E+00
std(1)%np(2)%x = 0.355500E+00
std(1)%np(1:1) = 0.30E+00
std(1)%np(1:2) = 0.30E+00 0.55E+01
0.25.5000
0.2 0.35548
failure
with gcc-8, gcc-9 and current trunk.
Something is rotten in the state of Denmark here.
[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |8.4
[Bug c++/91076] New: wrong class-key in mentioned in a diagnostic note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91076
Bug ID: 91076
Summary: wrong class-key in mentioned in a diagnostic note
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When a type defined with one class-key (such as "class") contains a member such
as a pointer to the same type that uses a different class-key (such as
"struct") the C++ front-end replaces the original class-key associated with the
type with the one used in the member. This causes problems in GCC code that
examines the class-key by using CLASSTYPE_DECLARED_CLASS (t) or by calling
class_key_or_enum_as_string (). A test case illustrating this bug is as
follows:
$ cat a.C && gcc -S -Wall -Wextra a.C
class A // uses CLASS
{
public:
struct A *p; // uses STRUCT
}
[[maybe_unused]]; // misleading warning refers to STRUCT
a.C:6:1: warning: attribute ignored in declaration of ‘struct A’ [-Wattributes]
6 | [[maybe_unused]]; // misleading warning refers to STRUCT
| ^
a.C:6:1: note: attribute for ‘struct A’ must follow the ‘struct’ keyword
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #20 from Evgeniy Dushistov ---
Also if add one line to code `printf("test\n");`
```
struct FooDeleter {
void operator()(FooOpaque *p) {
printf("test\n");
Foo_free(p);
}
};
```
gcc don't report any warning,
and valgrind also can not find any errors.
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Evgeniy Dushistov changed:
What|Removed |Added
CC||dushistov at mail dot ru
--- Comment #19 from Evgeniy Dushistov ---
I saw problem similar `std::optional` may be unitialized case as desribed here
with boost::variant/boost::optional (c++11) and std::variant/std::optional
(c++17),
but in my case I have not only gcc warning, but valgrind also reports problem,
is it the same problem or gcc code generation bug?
```
//Foo.cpp
#include "Foo.hpp"
struct FooOpaque {};
FooOpaque *Foo_new() {
auto p = new FooOpaque;
return p;
}
void Foo_free(FooOpaque *p) { delete p; }
std::variant, std::string> f_res_opt(int var) {
switch (var) {
case 0:
return {std::optional{Foo{Foo_new()}}};
case 1:
return {std::optional{}};
case 2:
return {std::string{}};
default:
std::abort();
}
}
```
```
//Foo.hpp
#include
#include
#include
struct FooOpaque;
FooOpaque *Foo_new();
void Foo_free(FooOpaque *);
struct FooDeleter {
void operator()(FooOpaque *p) { Foo_free(p); }
};
using Foo = std::unique_ptr;
std::variant, std::string> f_res_opt(int var);
```
```
//main.cpp
#include "Foo.hpp"
int main() {
auto res1 = f_res_opt(0);
auto res1_ok = std::get>(std::move(res1));
printf("step 2\n");
auto res2 = f_res_opt(1);
auto res2_ok = std::get>(std::move(res2));
printf("step 3\n");
auto res3 = f_res_opt(2);
auto res3_ok = std::get(std::move(res3));
}
```
gcc reports:
```
g++ -ggdb -Ofast -Wall -Wextra -std=c++17 -pedantic main.cpp Foo.cpp
In file included from main.cpp:1:
Foo.hpp: In function 'int main()':
Foo.hpp:10:43: warning: 'res2_ok.std::_Head_base<0, FooOpaque*,
false>::_M_head_impl' may be used uninitialized in this function
[-Wmaybe-uninitialized]
10 | void operator()(FooOpaque *p) { Foo_free(p); }
| ^~~
main.cpp:12:8: note: 'res2_ok.std::_Head_base<0, FooOpaque*,
false>::_M_head_impl' was declared here
12 | auto res2_ok = std::get>(std::move(res2));
|^~~
In file included from main.cpp:1:
Foo.hpp:10:43: warning: 'res1_ok.std::_Head_base<0, FooOpaque*,
false>::_M_head_impl' may be used uninitialized in this function
[-Wmaybe-uninitialized]
10 | void operator()(FooOpaque *p) { Foo_free(p); }
| ^~~
main.cpp:6:8: note: 'res1_ok.std::_Head_base<0, FooOpaque*,
false>::_M_head_impl' was declared here
6 | auto res1_ok = std::get>(std::move(res1));
|^~~
```
but valgrind also reports:
valgrind -v ./a.out
```
==7858== Conditional jump or move depends on uninitialised value(s)
==7858==at 0x109374: ~unique_ptr (unique_ptr.h:288)
==7858==by 0x109374: _M_destroy (optional:257)
==7858==by 0x109374: _M_reset (optional:277)
==7858==by 0x109374: ~_Optional_payload (optional:398)
==7858==by 0x109374: ~_Optional_base (optional:471)
==7858==by 0x109374: ~optional (optional:656)
==7858==by 0x109374: main (main.cpp:12)
```
gcc 9.1.0 and valgrind 3.15.0.GIT
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #26 from Thomas Koenig --- Jerry, you are working on a Linux box, right? What does stat -f -c %b . tell you?
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #6 from Peter Bergner --- (In reply to Peter Bergner from comment #5) > Shouldn't we check whether the new .machine is different than the > currently active cpu value before reloading the opcode table? I don't think > it would be too hard to do and would solve stupid user tricks like: Actually, gas' ppc_machine() already ignores .machine directives if it matches the currently active cpu, so no code needed. That means we'll never reload the opcode table unless we really have to.
[Bug tree-optimization/91074] [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91074 --- Comment #3 from seurer at gcc dot gnu.org --- I am running a check on the test and ... looks like it works! Problem test cases fixed and no other new issues.
[Bug c++/80785] warning for static definitions inside extern "C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80785 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug c++/91075] New: Wrong code generated for static variable with local redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91075
Bug ID: 91075
Summary: Wrong code generated for static variable with local
redeclaration
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrey.vihrov at gmail dot com
Target Milestone: ---
Consider the following C++ sample:
static int x;
int main()
{
int x = 1;
{
extern int x;
return x;
}
}
Compiling the above code with "g++ test.cpp" gives:
/usr/bin/ld: /tmp/ccZhQ3uF.o: in function `main':
test.cpp:(.text+0x6): undefined reference to `x'
collect2: error: ld returned 1 exit status
Removing the first "int x;" declaration from main() fixes the problem.
According to Note 3.3.2.11 of [1], the local "extern int x;" declaration should
refer to the static variable from the global namespace.
The problem is reproducible with GCC 9.1.0 and all GCC versions / targets
available on gcc.godbolt.org, while clang and other compilers produce correct
code.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
[Bug tree-optimization/91074] [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91074 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-03 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 46554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46554=edit gcc10-pr91074.patch Untested fix.
[Bug tree-optimization/91074] [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91074 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64*-unknown-linux-gn ||u CC||jakub at gcc dot gnu.org Host||powerpc64*-unknown-linux-gn ||u Build||powerpc64*-unknown-linux-gn ||u --- Comment #1 from seurer at gcc dot gnu.org --- Also apparent scan-5.c. From a powerpc BE system: > FAIL: c-c++-common/gomp/scan-3.c -std=c++14 (internal compiler error) > FAIL: c-c++-common/gomp/scan-3.c -std=c++14 (test for excess errors) > FAIL: c-c++-common/gomp/scan-3.c -std=c++17 (internal compiler error) > FAIL: c-c++-common/gomp/scan-3.c -std=c++17 (test for excess errors) > FAIL: c-c++-common/gomp/scan-3.c -std=c++98 (internal compiler error) > FAIL: c-c++-common/gomp/scan-3.c -std=c++98 (test for excess errors) > FAIL: c-c++-common/gomp/scan-3.c (internal compiler error) > FAIL: c-c++-common/gomp/scan-3.c (test for excess errors) > FAIL: c-c++-common/gomp/scan-5.c -std=c++14 (internal compiler error) > FAIL: c-c++-common/gomp/scan-5.c -std=c++14 (test for excess errors) > FAIL: c-c++-common/gomp/scan-5.c -std=c++17 (internal compiler error) > FAIL: c-c++-common/gomp/scan-5.c -std=c++17 (test for excess errors) > FAIL: c-c++-common/gomp/scan-5.c -std=c++98 (internal compiler error) > FAIL: c-c++-common/gomp/scan-5.c -std=c++98 (test for excess errors) > FAIL: c-c++-common/gomp/scan-5.c (internal compiler error) > FAIL: c-c++-common/gomp/scan-5.c (test for excess errors)
[Bug tree-optimization/91074] New: [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91074 Bug ID: 91074 Summary: [10 regression] c-c++-common/gomp/scan-3.c fails with ICE starting with r272958 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- FAIL: c-c++-common/gomp/scan-3.c (internal compiler error) FAIL: c-c++-common/gomp/scan-3.c (test for excess errors) FAIL: c-c++-common/gomp/scan-3.c -std=c++98 (internal compiler error) FAIL: c-c++-common/gomp/scan-3.c -std=c++98 (test for excess errors) FAIL: c-c++-common/gomp/scan-3.c -std=c++14 (internal compiler error) FAIL: c-c++-common/gomp/scan-3.c -std=c++14 (test for excess errors) FAIL: c-c++-common/gomp/scan-3.c -std=c++17 (internal compiler error) FAIL: c-c++-common/gomp/scan-3.c -std=c++17 (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/gomp/scan-3.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fopenmp -Wno-hsa -S -o scan-3.s during RTL pass: expand /home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/gomp/scan-3.c: In function 'f1': /home/seurer/gcc/gcc-test2/gcc/testsuite/c-c++-common/gomp/scan-3.c:4:1: internal compiler error: tree check: expected ssa_name, have var_decl in single_imm_use, at ssa-iterators.h:421 0x101cadc3 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /home/seurer/gcc/gcc-test2/gcc/tree.c:9900 0x10764b8f tree_check(tree_node const*, char const*, int, char const*, tree_code) /home/seurer/gcc/gcc-test2/gcc/tree.h:3473 0x10764b8f single_imm_use /home/seurer/gcc/gcc-test2/gcc/ssa-iterators.h:421 0x10764b8f expand_mul_overflow /home/seurer/gcc/gcc-test2/gcc/internal-fn.c:1590 0x107663a7 expand_arith_overflow /home/seurer/gcc/gcc-test2/gcc/internal-fn.c:2362 0x107615af expand_internal_call(internal_fn, gcall*) /home/seurer/gcc/gcc-test2/gcc/internal-fn.c:3573 0x107615af expand_internal_call(gcall*) /home/seurer/gcc/gcc-test2/gcc/internal-fn.c:3581 0x1041c397 expand_call_stmt /home/seurer/gcc/gcc-test2/gcc/cfgexpand.c:2638 0x1041c397 expand_gimple_stmt_1 /home/seurer/gcc/gcc-test2/gcc/cfgexpand.c:3708 0x1041dfdf expand_gimple_stmt /home/seurer/gcc/gcc-test2/gcc/cfgexpand.c:3867 0x104254e7 expand_gimple_basic_block /home/seurer/gcc/gcc-test2/gcc/cfgexpand.c:5907 0x104286c7 execute /home/seurer/gcc/gcc-test2/gcc/cfgexpand.c:6530
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 --- Comment #5 from Peter Bergner --- (In reply to Alan Modra from comment #3) > We don't always emit .machine because that is a waste of time if the > .machine cpu matches the original cpu passed on the command line to gas. > .machine reloads the gas opcode table, which may take a significant time. Shouldn't we check whether the new .machine is different than the currently active cpu value before reloading the opcode table? I don't think it would be too hard to do and would solve stupid user tricks like: .machine power8 .machine power8 .machine power8 ... I'll have a look at that after I fix gcc sending the wrong -m option to gas. Which is independent question of whether gcc should always emit .machine directives.
[Bug c++/83374] [DR1813] Bad std::is_standard_layout with two base class subobjects of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83374 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Clang 7 and newer now implement DR 1813. I'll take a look.
[Bug c++/91073] New: if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073
Bug ID: 91073
Summary: if constexpr no longer works directly with Concepts
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rwdougla at gmail dot com
Target Milestone: ---
It appears I can no longer use a Concept within the if-constexpr's expression.
I receive the error:
:26:58: error: expected unqualified-id before ')' token
Compiler Explorer link: https://godbolt.org/z/r8TXSM
Assuming it is not due to an intended change in concepts for c++20, as Clang
appears to support it when compiled with concepts branch:
https://godbolt.org/z/4liykV
Workaround exists by assigning Concept evaluation to a constexpr bool and using
that in the if-constexpr check.
In case Compiler Explorer link is insufficient, here is gcc params:
Using:
gcc 9.1.0
flags: -std=c++2a -fconcepts -O2 -Wall -Wextra -Werror -Wpedantic -Wconversion
Code:
#include
template
concept HasInit = requires(T t, Params... p) { t.init(p...); };
struct Initable { void init(int) { std::cout << "In init" << std::endl; } };
struct Createable { void create(int) { std::cout << "In create" << std::endl; }
};
struct Foo{
template
void for_each(CB&& cb)
{
Initable i;
Createable c;
cb(i);
cb(c);
}
Foo()
{
struct Bar { int x; };
for_each(
[&](auto& foo){
// constexpr bool has_init = HasInit;
// if constexpr (has_init)
if constexpr (HasInit)
{
foo.init(5);
}
});
}
};
int main()
{
Foo f;
return 0;
}
[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-03 Ever confirmed|0 |1 --- Comment #4 from Segher Boessenkool --- (In reply to Alan Modra from comment #3) > We don't always emit .machine because that is a waste of time if the > .machine cpu matches the original cpu passed on the command line to gas. > .machine reloads the gas opcode table, which may take a significant time. That is a legitimate concern, of course, but how bad is that? More and more code uses .machine freely, in inline asm directly, or with function attributes for example. It would be a lot simpler for GCC to always use .machine. Maybe gas should delay initialising these tables until it sees the first actual insn? Some of my configurations *always* use .machine, and I never noticed any slowdown. I'll benchmark something.
[Bug c++/83374] [DR1813] Bad std::is_standard_layout with two base class subobjects of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83374 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- *** Bug 91064 has been marked as a duplicate of this bug. ***
[Bug c++/91064] __is_standard_layout incorrect for a class with multiple bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91064 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Sebor --- Yes, it's a dupe. *** This bug has been marked as a duplicate of bug 83374 ***
[Bug middle-end/91072] New: does not reduce the size of a division by a constant on non-negative int / small unsigned long constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91072
Bug ID: 91072
Summary: does not reduce the size of a division by a constant
on non-negative int / small unsigned long constant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
The generated division by a constant is suboptimal when its size could be
reduced, e.g. on non-negative int divided by a small unsigned long constant
(which fits in an int). Consider the following example (the i <= 0 condition is
just there to have a similar source, otherwise this could just be i < 0 when i
is signed).
int f1 (unsigned int i)
{
return i <= 0 ? 0 : i / 3UL;
}
int f2 (int i)
{
return i <= 0 ? 0 : i / 3UL;
}
int f3 (int i)
{
return i <= 0 ? 0 : i / 3L;
}
With GCC 8.3.0 on x86_64, using -O3, f1 and f3 both use a 32-bit multiplication
(mull / imull) by a 32-bit constant, but f2 uses a 64-bit multiplication (mulq)
by a 64-bit constant.
With gcc (Debian 20190628-1) 10.0.0 20190628 (experimental) [trunk revision
272790], the only change is that f1 and f2 both use imulq (but still with a
32-bit constant). Wouldn't this be slower?
On a 64-bit PowerPC, this is similar with GCC 8.3.1 (mulhwu for f1 and f3,
mulhdu for f2).
[Bug debug/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981 --- Comment #6 from Mark Wielaard --- Author: mark Date: Wed Jul 3 13:08:01 2019 New Revision: 273008 URL: https://gcc.gnu.org/viewcvs?rev=273008=gcc=rev Log: PR debug/90981 Empty .debug_addr crashes -gdwarf-5 -gsplit-dwarf Even if there was no, or an empty address list we would try to generate a header for the .debug_addr section with -gdwarf-5 and -gsplit-dwarf. The skeleton DIE would also get a (dangling) DW_AT_addr_base in that case. PR debug/90981 * dwarf2out.c (add_top_level_skeleton_die_attrs): Only add DW_AT_addr_base if there is actually a .debug_addr section with addresses. (output_addr_table): Add DWARF5 table header generation here after checking there are actually any addresses from... (dwarf2out_finish): ...here. * testsuite/g++.dg/pr90981.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr90981.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug c++/90243] diagnostic notes that belong to a suppressed error about an uninitialized variable in a constexpr function are still shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90243 Jonathan Wakely changed: What|Removed |Added CC||bugs at qult dot net --- Comment #5 from Jonathan Wakely --- *** Bug 91070 has been marked as a duplicate of this bug. ***
[Bug c++/91070] Spurious notes about uninitialized members in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91070 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- I think it's same bug. *** This bug has been marked as a duplicate of bug 90243 ***
[Bug middle-end/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060 --- Comment #3 from Richard Biener --- I think this may be possibly a dup of the just fixed PR91069. Please close if the testcases now pass or report back otherwise.
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Jul 3 12:47:07 2019 New Revision: 273007 URL: https://gcc.gnu.org/viewcvs?rev=273007=gcc=rev Log: 2019-07-03 Richard Biener PR middle-end/91069 * match.pd (vec_perm -> bit_insert): Fix element read from first vector. * gcc.dg/pr91069.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr91069.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/91071] [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071
Martin Liška changed:
What|Removed |Added
Blocks||26163
--- Comment #6 from Martin Liška ---
The benchmark somehow iterates and we differ in in bwaves2.out, which is: "The
residual for convergence after each time step".
Following configuration tweak fixes the issue:
diff --git a/benchspec/CPU2006/410.bwaves/Spec/object.pm
b/benchspec/CPU2006/410.bwaves/Spec/object.pm
index 242ca26d..0a343023 100644
--- a/benchspec/CPU2006/410.bwaves/Spec/object.pm
+++ b/benchspec/CPU2006/410.bwaves/Spec/object.pm
@@ -4,7 +4,7 @@ $exename = 'bwaves';
$benchlang = 'F'; # was F77, in the olden days
@base_exe = ($exename);
-$reltol = {'bwaves2.out' => 0.015,
+$reltol = {'bwaves2.out' => 0.018,
'bwaves3.out' => 0.01,
'default' => undef};
I tend to close this as invalid..
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)
Complaint about webpage
Good Afternoon! I’ve just been looking at your website and I came across this webpage: https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple=9937 Unfortunately, when I click the link ‘ http://www.cuj.com/experts/2102/sutter.htm,’ it redirects me to a payday loan site. I thought I should let you know so that you can remove the link. With best regards, Tara
[Bug tree-optimization/91071] [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071 --- Comment #5 from Martin Liška --- It's really strange. I isolated the problematic __gcov_one_value_profiler_v2: __gcov_one_value_profiler_v2 (&__gcov3.flux_[36], ubound.56_347); but hard to guess why it's causing the issue. I also removed "leaf" attribute from __gcov_one_value_profiler_v2. And direct return in __gcov_one_value_profiler_v2 should verify that the fn is not corrupting a memory.
[Bug tree-optimization/91071] [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071 --- Comment #4 from Richard Biener --- The .optimized diff is more interesting since the disabled reassoc should simply happen later (after vectorization). Note for me the ref input passes comparison just fine... :/
[Bug tree-optimization/91071] [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071 --- Comment #3 from Martin Liška --- First diff: $ diff -u good/*120* bad/*120* --- good/block_solver.f.120t.reassoc1 2019-07-03 13:26:25.493543294 +0200 +++ bad/block_solver.f.120t.reassoc12019-07-03 13:25:54.597906149 +0200 @@ -116,6 +116,7 @@ integer(kind=8) _52; real(kind=8) _53; real(kind=8) _54; + real(kind=8) _55; real(kind=8) _56; integer(kind=8) _57; integer(kind=8) _58; @@ -124,6 +125,7 @@ integer(kind=8) _61; real(kind=8) _62; real(kind=8) _63; + real(kind=8) _64; real(kind=8) _65; integer(kind=8) _66; integer(kind=8) _67; @@ -133,6 +135,7 @@ integer(kind=8) _71; real(kind=8) _72; real(kind=8) _73; + real(kind=8) _74; real(kind=8) _75; integer(kind=8) _76; integer(kind=8) _77; @@ -140,6 +143,7 @@ integer(kind=8) _79; real(kind=8) _80; real(kind=8) _81; + real(kind=8) _82; real(kind=8) _83; integer(kind=8) _84; integer(kind=8) _85; @@ -148,6 +152,7 @@ integer(kind=8) _88; real(kind=8) _89; real(kind=8) _90; + real(kind=8) _91; real(kind=8) _92; integer(kind=8) _93; integer(kind=8) _94; @@ -158,12 +163,7 @@ real(kind=8) _99; real(kind=8) _100; real(kind=8) _101; - real(kind=8) _102; - real(kind=8) _103; - real(kind=8) _104; real(kind=8) _107; - real(kind=8) _108; - real(kind=8) _109; integer(kind=8) stride.88_115; integer(kind=8) stride.90_118; integer(kind=8) stride.90_119; @@ -416,6 +416,7 @@ _53 = (*x_142(D))[_52]; _54 = _48 * _53; _107 = _46 + _54; + _55 = _107 + _32; _56 = (*ayp_144(D))[_42]; _57 = (integer(kind=8)) jp1_136; _58 = _57 * stride.90_119; @@ -424,6 +425,7 @@ _61 = _39 + _60; _62 = (*x_142(D))[_61]; _63 = _56 * _62; + _64 = _55 + _63; _65 = (*azp_145(D))[_42]; _66 = (integer(kind=8)) kp1_134; _67 = _66 * stride.92_123; @@ -433,8 +435,7 @@ _71 = _39 + _70; _72 = (*x_142(D))[_71]; _73 = _65 * _72; - _104 = _63 + _73; - _109 = _107 + _104; + _74 = _64 + _73; _75 = (*axm_146(D))[_42]; _76 = (integer(kind=8)) im1_137; _77 = _76 * stride.88_115; @@ -442,6 +443,7 @@ _79 = _39 + _78; _80 = (*x_142(D))[_79]; _81 = _75 * _80; + _82 = _74 + _81; _83 = (*aym_147(D))[_42]; _84 = (integer(kind=8)) jm1_135; _85 = _84 * stride.90_119; @@ -450,7 +452,7 @@ _88 = _39 + _87; _89 = (*x_142(D))[_88]; _90 = _83 * _89; - _108 = _81 + _90; + _91 = _82 + _90; _92 = (*azm_148(D))[_42]; _93 = (integer(kind=8)) km1_133; _94 = _93 * stride.92_123; @@ -460,9 +462,7 @@ _98 = _39 + _97; _99 = (*x_142(D))[_98]; _100 = _92 * _99; - _103 = _100 + _32; - _102 = _108 + _103; - _101 = _109 + _102; + _101 = _91 + _100; (*y_139(D))[_31] = _101; m_150 = m_202 + 1; # DEBUG m => m_150
[Bug tree-optimization/91071] [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071 --- Comment #2 from Martin Liška --- The problematic file is: gfortran -c -o block_solver.o -Ofast -march=haswell -g -fprofile-generate -Ofast -std=legacy block_solver.f -fdump-tree-all
[Bug tree-optimization/91071] [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071 --- Comment #1 from Richard Biener --- Confirmed with -Ofast -march=haswell -fprofile-generate and the fix for PR91069 and the train run.
[Bug tree-optimization/91071] [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-03 CC||rguenth at gcc dot gnu.org Known to work||9.1.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug tree-optimization/91071] New: [10 Regression] Miscompare of 410.bwaves since r272644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91071 Bug ID: 91071 Summary: [10 Regression] Miscompare of 410.bwaves since r272644 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Following is causing a problem: $ runspec --config=spec2006 --size=train --iterations=1 --no-reportable --action run --tune=peak 410.bwaves (with -Ofast -march=skylake -g -flto=16 -fprofile-generate) *** Miscompare of bwaves2.out; for details see /home/marxin/Programming/cpu2006/benchspec/CPU2006/410.bwaves/run/run_peak_train_amd64-m64-mine./bwaves2.out.mis $ cat /home/marxin/Programming/cpu2006/benchspec/CPU2006/410.bwaves/run/run_peak_train_amd64-m64-mine./bwaves2.out.mis 0001: 294 289 ^
[Bug tree-optimization/91063] [10 Regression] ICE in set_vinfo_for_stmt, at tree-vectorizer.c:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91063
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-07-03
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Reduced testcase -O2 -fopenmp-simd -mavx512f:
struct S { void *s; };
int
foo (struct S *x)
{
int r = 0;
int i;
#pragma omp simd reduction (+ : r)
for (i = 0; i < 64; ++i)
r += (int) (x->s != 0);
return r;
}
I believe this has been introduced with r272623, but haven't verified that yet.
Untested fix below. vect_init_vector_1 inserts the stmt read from stmts
sequence into other spots, so it is unhealthy if we iterate using iterator that
contains it, it can very well create stmt referencing itself in ->next.
--- gcc/tree-vect-stmts.c.jj2019-07-03 10:24:33.463768431 +0200
+++ gcc/tree-vect-stmts.c 2019-07-03 12:35:48.998435660 +0200
@@ -1496,15 +1496,19 @@ vect_init_vector (stmt_vec_info stmt_inf
promotion of invariant/external defs. */
val = gimple_convert (, TREE_TYPE (type), val);
for (gimple_stmt_iterator gsi2 = gsi_start (stmts);
- !gsi_end_p (gsi2); gsi_next ())
- vect_init_vector_1 (stmt_info, gsi_stmt (gsi2), gsi);
+ !gsi_end_p (gsi2); )
+ {
+ init_stmt = gsi_stmt (gsi2);
+ gsi_remove (, false);
+ vect_init_vector_1 (stmt_info, init_stmt, gsi);
+ }
}
}
val = build_vector_from_val (type, val);
}
new_temp = vect_get_new_ssa_name (type, vect_simple_var, "cst_");
- init_stmt = gimple_build_assign (new_temp, val);
+ init_stmt = gimple_build_assign (new_temp, val);
vect_init_vector_1 (stmt_info, init_stmt, gsi);
return new_temp;
}
[Bug c++/91070] New: Spurious notes about uninitialized members in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91070
Bug ID: 91070
Summary: Spurious notes about uninitialized members in C++17
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at qult dot net
Target Milestone: ---
I what appears to be the minimal example below,
struct foo { int a; };
int main()
{
[](auto) {
if (int x = []{ return 0; }()) {
foo a;
(void) a;
}
}(0);
return 0;
}
GCC (-std=gnu++17) spits out the following:
: In instantiation of ‘main():: [with auto:1 = int]’:
:9:6: required from here
:1:8: note: ‘struct foo’ has no user-provided default constructor
struct foo { int a; };
^~~
:1:18: note: and the implicitly-defined constructor does not initialize
‘int foo::a’
struct foo { int a; };
^
This looks like orphaned notes as in bug #90243.
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069
--- Comment #8 from Richard Biener ---
It "mismatches" in
if (sel.series_p (1, 1, nelts + 1, 1))
{
/* After canonicalizing the first elt to come from the
first vector we only can insert the first elt from
the first vector. */
at = 0;
if ((ins = fold_read_from_vector (cop0, 0)))
op0 = op1;
}
it should read from element sel[0], not 0. Testing patch.
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #7 from Richard Biener ---
Testcase:
typedef double v2df __attribute__((vector_size(16)));
typedef long v2di __attribute__((vector_size(16)));
void foo (v2df *res, v2df *src)
{
v2df x = *src;
*res = __builtin_shuffle ((v2df) { 1.0, 0.0 }, x, (v2di) { 1, 3 });
}
int main()
{
v2df x = (v2df) { 0.0, 2.0 };
foo (, );
if (x[0] != 0.0 || x[1] != 2.0)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #6 from Richard Biener --- -march=x86-64 -mtune=generic (aka "default") is also broken, haswell (AVX2) is fine. -O3 is enough to trigger the issue for that. Disabling either of loop or SLP vectorization hides the issue. Inlining can be tuned down for Compute_Rotation_Transform by not inlining MTimesA, MTranspose (MATRIX *) and MTimesB. Disabling the BIT_INSERT_EXPR generation from match.pd seems to fix it though.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
--- Comment #6 from Jonathan Wakely ---
There are also some recursive_directory_iterator symbols missing. This fails
even compiled with GCC:
#include
int main()
{
std::filesystem::recursive_directory_iterator d;
d = d;
}
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #5 from Martin Liška --- Created attachment 46553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46553=edit FRE4 dump file with -O3 for the problematic function
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #4 from Martin Liška --- Created attachment 46552 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46552=edit FRE4 dump file with -Ofast
[Bug tree-optimization/91033] [10 Regression] ICE in vect_analyze_loop, at tree-vect-loop.c:2416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91033 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #3 from Martin Liška --- Created attachment 46551 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46551=edit pre-processed source file
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #2 from Martin Liška --- And the problematic function in the file is: void Compute_Rotation_Transform (TRANSFORM *transform, VECTOR vector)
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 --- Comment #1 from Martin Liška --- So the problematic file is: $ g++ -c -o matrices.o -DSPEC_CPU -DNDEBUG -Ofast -march=native -g -fpermissive -DSPEC_CPU_LP64 matrices.cpp
[Bug tree-optimization/91069] [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-03 CC||rguenth at gcc dot gnu.org Known to work||9.1.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug tree-optimization/91069] New: [10 Regression] Miscompare of 453.povray since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91069 Bug ID: 91069 Summary: [10 Regression] Miscompare of 453.povray since r272843 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Starting from the commit following fails: $ runspec --config=spec2006 --size=test --iterations=1 --no-reportable --action run --tune=peak 453.povray with -Ofast -march=native -g on a znver1 machine. I'll reduce that.
[Bug middle-end/90899] [8/9/10 Regression] ICE in add_to_same_comdat_group, at symtab.c:459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90899 Martin Liška changed: What|Removed |Added Known to work||10.0 Known to fail||8.3.0, 9.1.0 --- Comment #4 from Martin Liška --- Fixed on the trunk so far.
[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892 Martin Liška changed: What|Removed |Added Known to work||10.0 Known to fail|10.0| --- Comment #5 from Martin Liška --- Fixed on the trunk so far.
[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892 --- Comment #4 from Martin Liška --- Author: marxin Date: Wed Jul 3 08:32:25 2019 New Revision: 272993 URL: https://gcc.gnu.org/viewcvs?rev=272993=gcc=rev Log: Handle '\0' in strcmp in RTL expansion (PR tree-optimization/90892). 2019-07-03 Martin Liska PR tree-optimization/90892 * builtins.c (inline_expand_builtin_string_cmp): Handle '\0' in string constants. 2019-07-03 Martin Liska PR tree-optimization/90892 * gcc.dg/pr90892.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr90892.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/90899] [8/9/10 Regression] ICE in add_to_same_comdat_group, at symtab.c:459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90899 --- Comment #3 from Martin Liška --- Author: marxin Date: Wed Jul 3 08:31:35 2019 New Revision: 272992 URL: https://gcc.gnu.org/viewcvs?rev=272992=gcc=rev Log: Add to same comdate group only if set (PR middle-end/90899) 2019-07-03 Martin Liska PR middle-end/90899 * multiple_target.c (create_dispatcher_calls): Add to comdat group only if set for ifunc. 2019-07-03 Martin Liska PR middle-end/90899 * gcc.target/i386/pr90899.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr90899.c Modified: trunk/gcc/ChangeLog trunk/gcc/multiple_target.c trunk/gcc/testsuite/ChangeLog
[Bug target/88056] gcc/config/i386/host-mingw32.c:170: use of out of scope pointer ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88056 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 88056, which changed state. Bug 88056 Summary: gcc/config/i386/host-mingw32.c:170: use of out of scope pointer ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88056 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/88056] gcc/config/i386/host-mingw32.c:170: use of out of scope pointer ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88056 --- Comment #3 from Martin Liška --- Author: marxin Date: Wed Jul 3 08:29:48 2019 New Revision: 272991 URL: https://gcc.gnu.org/viewcvs?rev=272991=gcc=rev Log: Fix use-after-scope in host-mingw32.c (PR target/88056). 2019-07-03 Martin Liska PR target/88056 * config/i386/host-mingw32.c (mingw32_gt_pch_use_address): Define local_object_name in outer scope in order to handle use-after-scope issue. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/host-mingw32.c
[Bug rtl-optimization/91068] [10 regression][MIPS] New FAIL: madd-3.c and msub-5.c start with r272849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91068 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-07-03 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Mine then.
[Bug sanitizer/91056] Fail: asan reports stack-use-after-scope in valid program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91056 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Duplicate. *** This bug has been marked as a duplicate of bug 90570 ***
[Bug sanitizer/90570] AddressSanitizer: stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90570 Martin Liška changed: What|Removed |Added CC||grishalipenko at protonmail dot co ||m --- Comment #12 from Martin Liška --- *** Bug 91056 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/91033] [10 Regression] ICE in vect_analyze_loop, at tree-vect-loop.c:2416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91033 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Jul 3 08:25:22 2019 New Revision: 272989 URL: https://gcc.gnu.org/viewcvs?rev=272989=gcc=rev Log: PR tree-optimization/91033 * tree-vectorizer.h (vect_mark_stmts_to_be_vectorized, vect_analyze_data_refs): Add bool * arguments. * tree-vect-data-refs.c (vect_analyze_data_refs): Add fatal argument, if failure is due to scatter/gather, set *fatal to false if non-NULL. * tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized): Likewise. * tree-vect-loop.c (vect_analyze_loop_2): Adjust vect_mark_stmts_to_be_vectorized and vect_analyze_data_refs callers. * tree-vect-slp.c (vect_slp_analyze_bb_1): Adjust vect_analyze_data_refs caller. * gcc.target/i386/pr91033.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr91033.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug c++/91064] __is_standard_layout incorrect for a class with multiple bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91064 --- Comment #1 from Jonathan Wakely --- Dup of PR 83374 ?
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > This is a regression caused by moving the std::filesystem symbols into the > libstdc++.so shared library. It links OK with GCC 8 (using -lstdc++fs to > link to the static lib as needed for std::filesystem in GCC 8). To be clear, I meant it links OK with clang when using the headers+libs from GCC 8. (It also links OK when compiled with GCC 8, because it inlines differently.)
[Bug middle-end/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060
--- Comment #2 from Richard Biener ---
So the new FRE pass does things like
- _746 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _783 = BIT_FIELD_REF <_746, 16, 0>;
- _1801 = _783 + 2;
- _1800 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _1788 = BIT_FIELD_REF <_1800, 16, 16>;
- _1787 = _1788 + 2;
- _1775 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _1774 = BIT_FIELD_REF <_1775, 16, 32>;
- _1762 = _1774 + 2;
- _1761 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _1749 = BIT_FIELD_REF <_1761, 16, 48>;
- _1748 = _1749 + 2;
- _1736 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _1735 = BIT_FIELD_REF <_1736, 16, 64>;
- _748 = _1735 + 2;
- _784 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _1710 = BIT_FIELD_REF <_784, 16, 80>;
- _1709 = _1710 + 2;
- _1697 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _1696 = BIT_FIELD_REF <_1697, 16, 96>;
- _1684 = _1696 + 2;
- _1683 = {_2, 1, 2, 3, 4, 5, 6, 7};
- _1671 = BIT_FIELD_REF <_1683, 16, 112>;
- _1670 = _1671 + 2;
- _4 = {_1801, _1787, _1762, _1748, _748, _1709, _1684, _1670};
+ _1801 = _2 + 2;
+ _4 = {_1801, 3, 4, 5, 6, 7, 8, 9};
thus it improves vector lowering generated code. Unfortunately the
testcases / differences are too big and I'm not set up to do runtime
testing for big-endian arm.
Would it be possible to reduce the testcase to a single of the
v1 = 2 + v0; check (short, 8, v0, v1, 2, +, l);
v1 = 2 - v0; check (short, 8, v0, v1, 2, -, l);
v1 = 2 * v0; check (short, 8, v0, v1, 2, *, l);
v1 = 2 / v0; check (short, 8, v0, v1, 2, /, l);
v1 = 2 % v0; check (short, 8, v0, v1, 2, %, l);
...
lines?
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Known to work||8.3.0 Summary|Clang compiler can't link |[9/10 Regression] Clang |executable if |compiler can't link |std::filesystem::directory_ |executable if |iterator is encountered |std::filesystem::directory_ ||iterator is encountered Known to fail||10.0, 9.1.0 --- Comment #4 from Jonathan Wakely --- This is a regression caused by moving the std::filesystem symbols into the libstdc++.so shared library. It links OK with GCC 8 (using -lstdc++fs to link to the static lib as needed for std::filesystem in GCC 8). Adding the missing export will require GCC 9.2 to bump the version to libstdc++.so.6.0.27
[Bug tree-optimization/91059] [10 regression] gcc.c-torture/execute/builtins/snprintf-chk.c fails on aarch64-elf since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91059 Richard Biener changed: What|Removed |Added Keywords||wrong-code Component|middle-end |tree-optimization Target Milestone|--- |10.0
