[Bug target/93418] [9 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] GCC |[9 Regression] GCC |incorrectly constant|incorrectly constant |propagates |propagates |_mm_sllv/srlv/srav |_mm_sllv/srlv/srav --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bff948aa337807260344c83ac9079d6386410094
commit r10-6273-gbff948aa337807260344c83ac9079d6386410094
Author: Jakub Jelinek
Date: Tue Jan 28 08:46:23 2020 +0100
i386: Fix ix86_fold_builtin shift folding [PR93418]
The following testcase is miscompiled, because the variable shift left
operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
we call builder.new_unary_operation, builder.encoded_nelts () will be just
1
and thus we encode the resulting vector as if all the elements were the
same.
For non-masked is_vshift, we could perhaps call
builder.new_binary_operation
(TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
shifts, for non-is_vshift we could perhaps call it too but with args[2]
instead of args[1], but there is no builder.new_ternary_operation.
All this stuff is primarily for aarch64 anyway, on x86 we don't have any
variable length vectors, and it is not a big deal to compute all elements
and just let builder.finalize () find the most efficient VECTOR_CST
representation of the vector. So, instead of doing too much, this just
keeps using new_unary_operation only if only one VECTOR_CST is involved
(i.e. non-masked shift by constant) and for the rest just compute all elts.
2020-01-28 Jakub Jelinek
PR target/93418
* config/i386/i386.c (ix86_fold_builtin) : If mask is not
-1 or is_vshift is true, use new_vector with number of elts npatterns
rather than new_unary_operation.
* gcc.target/i386/avx2-pr93418.c: New test.
[Bug tree-optimization/93454] [10 Regression] buffer overflow in fold_array_ctor_reference since r10-1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93454 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/93454] [10 Regression] buffer overflow in fold_array_ctor_reference since r10-1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93454 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3c076c9642fd8877def0a0597ec7e4adfb5aa3b3 commit r10-6272-g3c076c9642fd8877def0a0597ec7e4adfb5aa3b3 Author: Jakub Jelinek Date: Tue Jan 28 08:44:07 2020 +0100 gimple-fold: Fix buffer overflow in fold_array_ctor_reference [PR93454] libgcrypt FAILs to build on aarch64-linux with *** stack smashing detected ***: terminated when gcc is compiled with -D_FORTIFY_SOURCE=2. The problem is if fold_array_ctor_reference is called with size equal to or very close to MAX_BITSIZE_MODE_ANY_MODE bits and non-zero inner_offset. The first native_encode_expr is called with that inner_offset and bufoff 0, the subsequent ones with offset of 0, and bufoff elt_size - inner_offset, 2 * elt_size - inner_offset etc. So, e.g. on the testcase where we start with inner_offset 1 and size is e.g. 256 bytes and elt_size 4 bytes we then call native_encode_expr at bufoff 251 and then 255, but that one overwrites 3 bytes beyond the buf array. The following patch fixes that. In addition, it avoids calling elt_size.to_uhwi () all the time, and punts if elt_sz would be too large. 2020-01-28 Jakub Jelinek PR tree-optimization/93454 * gimple-fold.c (fold_array_ctor_reference): Perform elt_size.to_uhwi () just once, instead of calling it in every iteration. Punt if that value is above size of the temporary buffer. Decrease third native_encode_expr argument when bufoff + elt_sz is above size of buf. * gcc.dg/pr93454.c: New test.
[Bug middle-end/93399] [8/9/10 Regression] Annotate assembler option failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399 --- Comment #5 from Alexandre Oliva --- I suppose it would make sense for str_pattern_slim to quote line breaks and other active characters when printing out string literals. And perhaps to eliminate one more use of str_pattern_slim while at that...
[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 --- Comment #5 from Andreas Krebbel --- (In reply to Vladimir Makarov from comment #4) > (In reply to Andreas Krebbel from comment #3) > > Created attachment 47714 [details] > > IRA EH fix - only when added at start of BB > > > > A probably better version of the fix. This version only reverts the > > allocation decision if the move is about to be added at the start of an EH > > basic block. > > Andreas, thank you for explaining the problem. Your patch should solve the > problem but my worry is that the final assignment can be worse (especially > if the pseudo in a loop goes into an EH bb). > > I think that such pseudo should have the right conflicting hard regnos > **before** the assignment. In this case the pseudo did not get a hard > register living into EH but still can get another hard register. > If you don't mind, I will take it from here and try to create such patch. > If you want to continue this work by yourself, please let me know. Please do. Thanks!
[Bug c++/92169] crash on referring to a local class member by unqualified name from outside the enclosing function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92169
Dmitry G. Dyachenko changed:
What|Removed |Added
CC||dimhen at gmail dot com
--- Comment #1 from Dmitry G. Dyachenko ---
r257061 PASS for me
r10-6221-g53d172975f269138ba227f6d4560950265c36df8 PASS too
g++ -std=c++{14,17,2a} -fchecking=2 -Ofast -c x.cc
[Bug target/92137] [ia32] Missing documentation for ia32 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92137 --- Comment #7 from Eric Gallager --- (In reply to Ariel Torti from comment #6) > (In reply to Eric Gallager from comment #5) > > (In reply to Jakub Jelinek from comment #3) > > > Those are intrinsics and most of them are documented in the Intel > > > architecture manuals, or various web sites. Not sure it is a good idea to > > > duplicate that documentation. > > > > Might be worthwhile to at least provide a link to the manuals or websites > > then, if we're not going to duplicate the info contained in them... > > Could you provide an example on how you would add them ? I'm pretty sure the file to edit would be gcc/doc/extend.texi; it's written in texinfo, so standard texinfo URL syntax would probably be the way to go. There are already some other URLs in the file, so you can just grep for "https://; and then copy the markup around them to add your own links.
[Bug c/93476] int bit fields waste space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93476 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is the ABI that specifies the size/alignment of the structs. GCC is just following that. The alignment of the struct with an int field is 4 bytes on most if not all targets where the sizeof(int) == 4.
[Bug c/93476] New: int bit fields waste space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93476
Bug ID: 93476
Summary: int bit fields waste space
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: doug at cs dot dartmouth.edu
Target Milestone: ---
sizeof(struct{ unsigned int a:2; }) is 4. 3 out of the 4
bytes are gratuitously wasted.
A workaround is struct{ unsigned char a:2; }, whose size is 1,
but this is implementation-defined syntax and not portable.
[Bug c++/93475] New: With 100k+ mangled names, appears to incorrectly mangle about 15% causing demangle failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93475 Bug ID: 93475 Summary: With 100k+ mangled names, appears to incorrectly mangle about 15% causing demangle failure Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: simonhf at gmail dot com Target Milestone: --- When looking at over 100k mangled C++ names, many of them fail to demangle using common command line tools. Initially I thought this was the fault of the demangler and opened a bug here [1]. However, after opening a similar bug here [2] for the LLVM demangler, a detailed response from LLVM developers appears to suggest that g++ itself is mangling incorrect, so I opened this bug! [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93035 [2] https://bugs.llvm.org/show_bug.cgi?id=44428
[Bug middle-end/82407] [meta-bug] qsort_chk fallout tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407 Bug 82407 depends on bug 93451, which changed state. Bug 93451 Summary: ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/93451] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug preprocessor/93452] [10 Regression] __has_include changes broke compilation of -fdirectives-only preprocessed sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93452 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-28 CC||nathan at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |blocker --- Comment #2 from Andrew Pinski --- .
[Bug analyzer/93451] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93451
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:8c08c983015e675f555d57a30e15d918abef2b93
commit r10-6271-g8c08c983015e675f555d57a30e15d918abef2b93
Author: David Malcolm
Date: Mon Jan 27 16:23:43 2020 -0500
analyzer: fix ICE when canonicalizing NaN (PR 93451)
PR analyzer/93451 reports an ICE when canonicalizing the constants
in a region_model, with a failed qsort_chk when attempting to sort
the constants within the region_model.
The svalues in the model were:
sv0: {poisoned: uninit}
sv1: {type: ‘double’, ‘0.0’}
sv2: {type: ‘double’, ‘1.0e+0’}
sv3: {type: ‘double’, ‘ Nan’}
The qsort_chk of the 3 constants fails due to tree_cmp using the
LT_EXPR ordering of the REAL_CSTs, which doesn't work for NaN.
This patch adjusts tree_cmp to impose an arbitrary ordering during
canonicalization for UNORDERED_EXPR cases w/o relying on the LT_EXPR
ordering, fixing the ICE.
gcc/analyzer/ChangeLog:
PR analyzer/93451
* region-model.cc (tree_cmp): For the REAL_CST case, impose an
arbitrary order on NaNs relative to other NaNs and to non-NaNs;
const-correctness tweak.
(ana::selftests::build_real_cst_from_string): New function.
(ana::selftests::append_interesting_constants): New function.
(ana::selftests::test_tree_cmp_on_constants): New test.
(ana::selftests::test_canonicalization_4): New test.
(ana::selftests::analyzer_region_model_cc_tests): Call the new
tests.
gcc/testsuite/ChangeLog:
PR analyzer/93451
* gcc.dg/analyzer/torture/pr93451.c: New test.
[Bug rtl-optimization/90688] [8/9/10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r235297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90688 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #3 from Jeffrey A. Law --- This was fixed some time ago by Jakub. *** This bug has been marked as a duplicate of bug 92610 ***
[Bug rtl-optimization/92610] [10 Regression] ICE in calc_dfs_tree, at dominance.c:458 since r270940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92610 --- Comment #5 from Jeffrey A. Law --- *** Bug 90688 has been marked as a duplicate of this bug. ***
[Bug c/93474] no warning for nonstandard bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93474 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- GCC documents this: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html#Structures-unions-enumerations-and-bit-fields-implementation Allowable bit-field types other than _Bool, signed int, and unsigned int (C99 and C11 6.7.2.1). Other integer types, such as long int, and enumerated types are permitted even in strictly conforming mode. --- CUT It is up to each other compiler to document the implementation defined behavior. GCC does document what happens.
[Bug c++/91075] Wrong code generated for static variable with local redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91075 --- Comment #1 from joseph at codesourcery dot com --- This would definitely be invalid C (the prior declaration visible in the inner scope has no linkage, so the inner declaration has external linkage and "If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined." applies). For C++, it appears the example in 3.5 paragraph 6 in the (old) document you linked to is the relevant one, explicitly saying the inner declaration refers to an entity with external linkage which is different from the static variable with internal linkage. In C++17, [basic.link] paragraph 6 says this example is ill-formed; no doubt one of our C++ experts can give details of when and why this changed and whether it was a defect fix.
[Bug c/93474] New: no warning for nonstandard bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93474
Bug ID: 93474
Summary: no warning for nonstandard bit field
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: doug at cs dot dartmouth.edu
Target Milestone: ---
struct { char x:1; } is implementation-defined syntax
per www.open-std.org/jtc1/sc22/wg14/www/docs/n2433.pdf,
Section 6.7.2.1, Constraint 5, which requires support
of only _Bool, signed int and unsigned int declarators.
gcc -Wall -Wpedantic -Wextra does not report this
nonstandard usage.
[Bug rtl-optimization/93455] aarch64: Q constraint address is recomputed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93455 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|target |rtl-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- This is most likely just a weird interaction between predicates and constraints.
[Bug debug/93380] Variable Length Array Evaluation will be wrong or cause GDB to crash due to GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93380 --- Comment #3 from Andrew Pinski --- (In reply to Robert Dumitru from comment #2) > Hi Andrew, > > Thank you for your pointing out that. I will report the issue to ARM as well. > However, regarding 1 and 2: > > 1. I understand this looks like a gdb bug, but my investigation pointed me > to consider that what gdb does is correct- at least partially. It tries to > read the memory to find the size of the array. If the memory is not > initialised with the correct value, the size can be huge - hence - virtual > memory exhausted bug. > I will try and check with a newer gdb. Maybe gdb should know the expression > can not be evaluated before right instructions are executed? But there should be a limit inside GDB to know the size is most likely bogus.
[Bug target/86793] mips port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-27 Ever confirmed|0 |1
[Bug rtl-optimization/61926] const-anchor optimisation is sensitive to ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61926 --- Comment #4 from Andrew Pinski --- (In reply to Martin Liška from comment #3) > Can the bug be marked as resolved? No, the testcases are just xfailed.
[Bug libfortran/91543] [10 Regression] nf failure ( Handling stack overflow more sensibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- For the case where you want some kind of recovery, -fstack-check is a better approach than -fstack-clash-protection as -fstack-check ensures there's always a page available to the segfault handler.
[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #12 from Andrew Pinski --- Fixed.
[Bug target/80306] ICE in cfgexpand.c during cross-compilation for mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80306 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #3 from Andrew Pinski --- Fixed so closing as GCC 7.x and before are no longer supported.
[Bug target/80306] ICE in cfgexpand.c during cross-compilation for mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80306 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- .
[Bug libgcc/63882] internal compiler error: in int_mode_for_mode, at stor-layout.c:395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63882 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Andrew Pinski --- mips64-linux-gnu builds have been working for me for a long time now including a native builds. So closing as works for me. Also no comments in over 3 years.
[Bug ipa/92550] [10 Regression] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92550 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug lto/92588] [10 Regression] ICE nodes with unreleased memory found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92588 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |WORKSFORME --- Comment #4 from Jeffrey A. Law --- I scanned all my build logs for Fedora 32 and couldn't find any instance of this either. I think we should just CLOSED/WORKSFORME.
[Bug target/86793] mips port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793 --- Comment #1 from Andrew Pinski --- So I can fix this for the Marvell/Cavium produced cores; Spectre workaround is not needed though. Someone inside WaveComputing/MIPS would have to implement this for those ones.
[Bug libgcc/86290] Go cross build fails, "with libgcc_s.so.1 [...] not found"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86290 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Andrew Pinski --- Works for me in GCC 7.3 and the trunk so closing as worksforme.
[Bug bootstrap/80656] mips64-linux cross build fails: Link tests are not allowed after GCC_NO_EXECUTABLES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80656 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Andrew Pinski --- This works for me; I am able to build a full toolchain with GCC 7.3 and the trunk for MIPS64.
[Bug target/28126] gcc moves an expensive (tls) instruction outside of a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126 --- Comment #13 from Andrew Pinski --- > For now it is always emulated by kernel Not on MIPS64r3/MIPS32r3 and above cores. Octeon2/3 implements this register. There might be other cores which implement this register too.
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 --- Comment #2 from Andrew Benson --- Problem occurs in set_syms_host_assoc() where the "parent1" and "parent2" variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This is insufficient when the parent names are a module+submodule name concatenated with a ".". The patch above fixes this by increasing their length to 2*GFC_MAX_SYMBOL_LEN+2.
[Bug fortran/93473] ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 --- Comment #1 from Andrew Benson --- Created attachment 47722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47722=edit Proposed patch
[Bug fortran/93473] New: ICE on valid with long module + submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473 Bug ID: 93473 Summary: ICE on valid with long module + submodule names Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code causes a bogus "symbol is already defined" error (using git commit 472dc648ce3e7661762931d584d239611ddca964): module aModestlyLongModuleName type :: aTypeWithASignificantlyLongNameButStillAllowedOK end type aTypeWithASignificantlyLongNameButStillAllowedOK interface module function aFunctionWithALongButStillAllowedName(parameters) result(self) type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self end function aFunctionWithALongButStillAllowedName end interface end module aModestlyLongModuleName submodule (aModestlyLongModuleName) aTypeWithASignificantlyLongNameButStillAllowedOK_ contains module procedure aFunctionWithALongButStillAllowedName class(*), pointer :: genericObject end procedure aFunctionWithALongButStillAllowedName end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_ submodule (aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_) aSubmoduleWithASignificantlyLongButStillAllowedName__ end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__ $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200127 (experimental) (GCC) $ gfortran -c 1057.F90 -o test.o -ffree-line-length-none f951: internal compiler error: Segmentation fault 0xe1021f crash_signal ../../gcc-git/gcc/toplev.c:328 0x7fd1480c91ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x891106 do_traverse_symtree ../../gcc-git/gcc/fortran/symbol.c:4173 0x85739b parse_module ../../gcc-git/gcc/fortran/parse.c:6111 0x85782d gfc_parse_file() ../../gcc-git/gcc/fortran/parse.c:6427 0x8a7f2f gfc_be_parse_file ../../gcc-git/gcc/fortran/f95-lang.c:210 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/90731] [9/10 Regression] noexcept broken for forward declarations with decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90731 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/93437] On protobuf generated code, -Warray-bounds is brittle and not very helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437 --- Comment #2 from Andrew Pinski --- (In reply to Rafael Avila de Espindola from comment #1) > The warning is no longer issued after > 6889a3acfeed47265886676c6d43b04ef799fb82. g:6889a3acfeed47265886676c6d43b04ef799fb82 > > Martin, is this a duplicate of middle-end/91631?
[Bug c++/93437] On protobuf generated code, -Warray-bounds is brittle and not very helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437 Rafael Avila de Espindola changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Rafael Avila de Espindola --- The warning is no longer issued after 6889a3acfeed47265886676c6d43b04ef799fb82. Martin, is this a duplicate of middle-end/91631?
[Bug c/93472] New: Document extended forms of constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93472 Bug ID: 93472 Summary: Document extended forms of constant expression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- GCC accepts extended forms of constant expression. An example that came up recently was: const int a = 5; const int b = a; IIUC the standard permits the compiler to accept other forms of constant expression. However, I couldn't find this in the documentation, and I think it would be good if GCC documented the extensions it supports. Perhaps a new node in the "C Implementation-Defined Behavior" section would be appropriate.
[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461 --- Comment #2 from Andrew Benson --- The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus function name (plus the additional "_"'s that get prepended), but insufficient if a submodule name is included. The name then gets truncated and can lead to two different functions having the same (truncated) symbol name. The fix is to increase this length to GFC_MAX_SYMBOL_LEN*3+5 - which allows for the submodule name plus the "." added between module and submodule names. Patch attached.
[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461 --- Comment #1 from Andrew Benson --- Created attachment 47721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47721=edit Patch for PR93461
[Bug libstdc++/93470] [9/10 Regression] [C++2a] std::reference_wrapper to function type is broken with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 --- Comment #4 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #3) > (In reply to frankhb1989 from comment #2) > > Sorry, I missed to mention it only failed with `clang++ -std=c++2a` > > If you're going to claim something is broken please don't forget the most > critical piece of information. > True, I should have been mention this in the title of the bug. My mistake to leave "C++2a" but not "Clang++" and forget to rephrase it in the comment with a proper case. > GCC accepts it as an extension, which is also correct. > > You get a diagnostic with -Wsystem-headers, but not by default. Fair point. Glad to see this not depending on the compiler.
[Bug libstdc++/93470] [9/10 Regression] [C++2a] std::reference_wrapper to function type is broken with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 Jonathan Wakely changed: What|Removed |Added Status|WAITING |ASSIGNED Target Milestone|--- |9.3 Summary|[C++2a] |[9/10 Regression] [C++2a] |std::reference_wrapper to |std::reference_wrapper to |function type is broken |function type is broken ||with Clang --- Comment #3 from Jonathan Wakely --- (In reply to frankhb1989 from comment #2) > Sorry, I missed to mention it only failed with `clang++ -std=c++2a` If you're going to claim something is broken please don't forget the most critical piece of information. Bugzilla reminds you to read https://gcc.gnu.org/bugs/ before creating every bug, please be sure to do that, and provide the requested information. > Clang++ 9.0.1). G++ with `-std=c++2a` still accepts the code. However, it > seems that Clang++ is correct here. GCC accepts it as an extension, which is also correct. You get a diagnostic with -Wsystem-headers, but not by default.
[Bug go/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Ian Lance Taylor --- Go frontend is fixed.
[Bug target/89627] Miscompiled constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89627 Jim Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot gnu.org --- Comment #5 from Jim Wilson --- Was fixed in gcc 9 last year.
[Bug go/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 --- Comment #8 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:2f195832a12ff4fb54d723f32019d4175db1b5da commit r10-6267-g2f195832a12ff4fb54d723f32019d4175db1b5da Author: Ian Lance Taylor Date: Fri Jan 24 12:39:23 2020 -0800 compiler: cleanups permitted by GCC requirement of MPFR 3.1.0 For MPFR functions, change from GMP_RND* to MPFR_RND*. Also change mp_exp_t to mpfr_expt_t. Fixes PR go/92463 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/216417
[Bug target/93459] ix86_fold_builtin should handle __builtin_ia32_pcmpeqd128_mask and similar builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93459 --- Comment #2 from Marc Glisse --- For __builtin_ia32_vec_ext_v4si, shouldn't we lower it to an array access in gimple, when the second argument is constant? I assume we don't want to do it directly in smmintrin.h for diagnostic purposes.
[Bug libstdc++/93470] [C++2a] std::reference_wrapper to function type is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470
--- Comment #2 from frankhb1989 at gmail dot com ---
Case:
#include
void foo() {}
int main()
{
std::ref(foo)();
}
Sorry, I missed to mention it only failed with `clang++ -std=c++2a` (using
Clang++ 9.0.1). G++ with `-std=c++2a` still accepts the code. However, it seems
that Clang++ is correct here.
[Bug libgomp/93471] New: GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
Bug ID: 93471
Summary: GCC-9.2.0 libgomp configuration passes bogus mingw32
library search paths
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.marshall at mailinator dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Building GCC-9.2.0 for mingw32 target, initially as GNU/Linux hosted
cross-compiler, and subsequently using that cross-compiler to build
cross-native for Win32 deployment, both builds fail at libgomp configuration
step, because libpthread.a cannot be found ... in spite of it being available
at its correctly installed location, relative to the associated pthreads header
files, which are found.
Specifically, failure to find the library is because the GCC-9.2.0 build
system, which does pass valid -I search paths, passes two entirely bogus -L
search paths, and no valid -L path, to the linker; both -L paths which are
passed lie within the non-existent, and never created,
${top_builddir}/mingw32/winsup hierarchy.
I can kludge around this, by manually creating the
${top_builddir}/mingw32/winsup/mingw directory, and creating libpthread.a
within it, as a hard link to the properly installed library, (which in my build
case is /home/keith/mingw32/lib/pthread.a), but that's a hideous kludge, to
work around a failing of the build system itself. Furthermore, it does have to
be a hard link, or a physical copy ... logically I had hoped that creating
${top_builddir}/mingw32/winsup as a physical directory hierarchy, with mingw as
a symbolic link within that, as a reference to /home/keith/mingw32/lib, would
have been sufficient, but apparently it is not.
I've never encountered any such issue, building previous GCC versions back as
far as GCC-4.8.2, and through to GCC-8.2.0, so it appears that this is a newly
introduced build system defect, with GCC-9.x
[Bug tree-optimization/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 --- Comment #25 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8f25c39c454d7d3d323edf014a653649946352bd commit r10-6266-g8f25c39c454d7d3d323edf014a653649946352bd Author: Jason Merrill Date: Sun Jan 26 22:19:47 2020 -0500 c++: Fix array of char typedef in template (PR90966). Since Martin Sebor's patch for PR 71625 to change braced array initializers to STRING_CST in some cases, we need to be ready for STRING_CST with types that are changed by tsubst. fold_convert doesn't know how to deal with STRING_CST, which is reasonable; we really shouldn't expect it to here. So let's handle STRING_CST separately. PR c++/90966 * pt.c (tsubst_copy) [STRING_CST]: Don't use fold_convert.
[Bug c++/90966] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90966 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8f25c39c454d7d3d323edf014a653649946352bd commit r10-6266-g8f25c39c454d7d3d323edf014a653649946352bd Author: Jason Merrill Date: Sun Jan 26 22:19:47 2020 -0500 c++: Fix array of char typedef in template (PR90966). Since Martin Sebor's patch for PR 71625 to change braced array initializers to STRING_CST in some cases, we need to be ready for STRING_CST with types that are changed by tsubst. fold_convert doesn't know how to deal with STRING_CST, which is reasonable; we really shouldn't expect it to here. So let's handle STRING_CST separately. PR c++/90966 * pt.c (tsubst_copy) [STRING_CST]: Don't use fold_convert.
[Bug libstdc++/93470] [C++2a] std::reference_wrapper to function type is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Testcase please, as requested by https://gcc.gnu.org/bugs/
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #2 from Jonathan Wakely --- This is a bug in your libc headers (and I'm guessing you're on OS X). The aligned_alloc function should be declared for C++17 and later, irrespective of the _XOPEN_SOURCE value.
[Bug middle-end/93194] -fpatchable-function-entries : __patchable_function_entries has wrong sh_addralign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Should be fixed by the commit referenced in c#2.
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-27 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Please provide the rest of the info requested by https://gcc.gnu.org/bugs (especially the output of gcc -v)
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #8 from Devin Hussey --- Seems to work. ~ $ ~/gcc-test/bin/x86_64-pc-cygwin-gcc.exe -mavx2 -O3 _mm_sllv_bug.c ~ $ ./a.exe Without optimizations (correct result): 8000 fff8 With optimizations (incorrect result): 8000 fff8 ~ $ And checking the assembly, the shifts are constant propagated. The provided test file also passes.
[Bug libstdc++/93470] New: [C++2a] std::reference_wrapper to function type is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470 Bug ID: 93470 Summary: [C++2a] std::reference_wrapper to function type is broken Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Target Milestone: --- In `std::reference_wrapper::operator()` in : #if __cplusplus > 201703L static_assert(sizeof(type), "type must be complete"); #endif The static assertion is ill-formed when `type` is a function type, required by instantiation of function template specialization `std::reference_wrapper::operator()` when `T` is a function type.
[Bug c++/93443] gcc/cp/coroutines.cc:3555:23: runtime error: load of value 255, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:1f2e84238c9f079747804026b6225ec8c1d0e4b7 commit r10-6265-g1f2e84238c9f079747804026b6225ec8c1d0e4b7 Author: Iain Sandoe Date: Mon Jan 27 10:13:09 2020 + coroutines: Ensure the ramp return object is checked (PR93443). As the PR shows, there is a pathway through the code where the no_warning value is not set, which corresponds to a missing check of the ramp return when it was constructed from the 'get return object' Fixed by ensuring that the check of the return value is carried out for both return cases. gcc/cp/ChangeLog: 2020-01-27 Iain Sandoe PR c++/93443 * coroutines.cc (morph_fn_to_coro): Check the ramp return value when it is constructed from the 'get return object'.
[Bug libstdc++/93469] New: memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 Bug ID: 93469 Summary: memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: karen.arutyunov at gmail dot com Target Milestone: --- While packaging ICU 65.1 for build2 toolchain I end up with the following error on macOS 10.15.2 with g++ 9.2.0 (Homebrew GCC 9.2.0_2): In file included from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/stl_algo.h:59, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/string:52, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/stdexcept:39, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/array:39, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/tuple:39, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/bits/unique_ptr.h:37, from /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/memory:80, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/unicode/localpointer.h:45, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/unicode/udata.h:23, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/udatamem.h:24, from /Users/build/cfg/libicuuc-65.1.0-a.0.20200127171539.77d49624ec32/libicu/uc/umapfile.cpp:26: /usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/cstdlib:132:11: error: '::aligned_alloc' has not been declared 132 | using ::aligned_alloc; | ^ The issue seems to relate to libstdc++ headers and pops up if the C++20 standard is specified on the command line and a program defines the _XOPEN_SOURCE macro and includes the memory header. It can be reproduced with the following commands: % cat
[Bug go/93468] New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 --- Comment #2 from Svante Signell --- Created attachment 47720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47720=edit Add hurd to // +build
[Bug go/93468] New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 --- Comment #1 from Svante Signell --- Created attachment 47719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47719=edit Add hurd to // +build
[Bug go/93468] New: New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 Bug ID: 93468 Summary: New patches to build gcc-10 on GNU/Hurd Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: svante.signell at gmail dot com CC: cmang at google dot com Target Milestone: --- Created attachment 47718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47718=edit netpoll_hurd.go update Fixes FTBFS for gcc-snapshot-20200124 on GNU/Hurd Hello, Test-compiling Debian Version gcc-10-10-20200124-1 reveals that three small fixes are needed for a successful build, one in runtime/netpoll_hurd.go, one in syscall/sockcmsg_unix_other.go and one in runtime/nbpipe_pipe2.go. The attached patches fixes the build and tests of libgo. There are still two tests failing due to linkage problems. When time permits I'll investigate these problems. Thanks!
[Bug c++/93467] New: [concepts] getting "type constraint differs in template redeclaration" error after friend declaration in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93467
Bug ID: 93467
Summary: [concepts] getting "type constraint differs in
template redeclaration" error after friend declaration
in template
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.zavalczki at gmail dot com
Target Milestone: ---
I know the C++ standard says:
> "A constrained declaration may only be redeclared using the same syntactic
> form. No diagnostic is required."
However, that specification causes this supposedly correct program to fail:
///
// compile with: g++-9 -fconcepts -std=c++2a
template concept True = true;
template
struct S1 {
template friend struct S2; // friend declaration for S2
};
S1 s; // instantiate S1
template struct S2; // another declaration for S2
///
You can test the above snippet on godbolt.org: https://godbolt.org/z/V6uJPe
[Bug bootstrap/93214] [10 Regression] Ada LTO bootstrap fails with undefined reference to __gnat_debug_raise_assert_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93214 Jan Hubicka changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Jan Hubicka --- I can bootstrap as well. Ada has some -O0 filed linked into the final binary which means no-reorder and there was bug, fixed recently, which led to undefined symbols in some scenarios. So hopefully this is fixed. Different DECL_ASSEMBLER_NAME should not be a problem.
[Bug gcov-profile/93466] New: [9/10 regression] New naming scheme for -fprofile-dir= dump files hits filename length limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93466 Bug ID: 93466 Summary: [9/10 regression] New naming scheme for -fprofile-dir= dump files hits filename length limits Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Filename length limit for ext4 is 256 characters which is not that hard to hit with the new flattened names (which use # instead of directory structure)
[Bug c++/92948] internal compiler error: in tsubst_copy, at cp/pt.c:15788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948
--- Comment #4 from Marek Polacek ---
A related test that I think should compile:
struct A {
constexpr A(int) { }
};
template
struct B {
};
template
void foo()
{
B b; // works with B<1>
}
void
fn ()
{
foo<1>();
}
[Bug c++/93465] New: [10 Regression] ICE in oacc_verify_routine_clauses, at omp-general.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93465
Bug ID: 93465
Summary: [10 Regression] ICE in oacc_verify_routine_clauses, at
omp-general.c:1802
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20190512 and 20190519, rejects C variant :
$ cat z0.c
#pragma omp declare target
#include
$ cat z1.cc
#pragma omp declare target
#include
$ gcc-10-20200126 -c z0.c -fopenmp -fopenacc
z0.c:3: error: '#pragma omp declare target' without corresponding '#pragma omp
end declare target'
$ g++-10-20190512 -c z1.cc -fopenmp -fopenacc
$
$ g++-10-20200126 -c z1.cc -fopenmp -fopenacc
In file included from z1.cc:2:
.../lib64/gcc/x86_64-pc-linux-gnu/10.0.1/include/openacc.h: In function 'int
acc_on_device(acc_device_t)':
.../lib64/gcc/x86_64-pc-linux-gnu/10.0.1/include/openacc.h:162:1: internal
compiler error: Segmentation fault
162 | {
| ^
0xc3085f crash_signal
../../gcc/toplev.c:328
0xb17d41 oacc_verify_routine_clauses(tree_node*, tree_node**, unsigned int,
char const*)
../../gcc/omp-general.c:1802
0x6e2732 cp_finalize_oacc_routine
../../gcc/cp/parser.c:42750
0x718bdc cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:28734
0x718bdc cp_parser_init_declarator
../../gcc/cp/parser.c:20590
0x6fc6ee cp_parser_simple_declaration
../../gcc/cp/parser.c:13669
0x71f6d9 cp_parser_declaration
../../gcc/cp/parser.c:13368
0x6f786a cp_parser_oacc_routine
../../gcc/cp/parser.c:42669
0x6f786a cp_parser_pragma
../../gcc/cp/parser.c:43459
0x71fe51 cp_parser_translation_unit
../../gcc/cp/parser.c:4731
0x71fe51 c_parse_file()
../../gcc/cp/parser.c:43675
0x7e2560 c_common_parse_file()
../../gcc/c-family/c-opts.c:1186
[Bug sanitizer/93433] sanitizer_linux.cc contains non-Linux-specific code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433 --- Comment #7 from Roland Illig --- (In reply to Martin Liška from comment #6) > (In reply to Roland Illig from comment #4) > > Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433 > > > > Hello. > > You probably posted a wrong link. I would expect one to LLVM bugzilla. Indeed, thanks for the note. The correct link to the LLVM bug report is: https://bugs.llvm.org/show_bug.cgi?id=44665
[Bug fortran/93464] New: [10 Regression] ICE in gfc_omp_check_optional_argument, at fortran/trans-openmp.c:104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93464 Bug ID: 93464 Summary: [10 Regression] ICE in gfc_omp_check_optional_argument, at fortran/trans-openmp.c:104 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20191215 and 20200105 : $ cat z1.f90 program p character :: c(2) = 'a' character, allocatable :: z(:) !$acc parallel z = c !$acc end parallel print *, z end $ gfortran-10-20191215 -c z1.f90 -fopenacc $ $ gfortran-10-20200126 -c z1.f90 -fopenacc z1.f90:4:0: 4 |!$acc parallel | internal compiler error: Segmentation fault 0xbac5cf crash_signal ../../gcc/toplev.c:328 0x758818 gfc_omp_check_optional_argument(tree_node*, bool) ../../gcc/fortran/trans-openmp.c:104 0x75a57c gfc_omp_finish_clause(tree_node*, gimple**) ../../gcc/fortran/trans-openmp.c:1278 0x9521b9 gimplify_adjust_omp_clauses_1 ../../gcc/gimplify.c:10094 0x1511863 splay_tree_foreach_helper ../../libiberty/splay-tree.c:244 0x1511863 splay_tree_foreach ../../libiberty/splay-tree.c:577 0x943ec5 gimplify_adjust_omp_clauses ../../gcc/gimplify.c:10584 0x948d08 gimplify_omp_workshare ../../gcc/gimplify.c:12803 0x94a35a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14110 0x94d198 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6822 0x94b46b gimplify_statement_list ../../gcc/gimplify.c:1869 0x94b46b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:14025 0x94d198 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6822 0x94db31 gimplify_bind_expr ../../gcc/gimplify.c:1424 0x94ac8a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:13782 0x94d198 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6822 0x94e5da gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:14830 0x94e8c5 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:14974 0x7f4ae7 cgraph_node::analyze() ../../gcc/cgraphunit.c:669 0x7f7597 analyze_functions ../../gcc/cgraphunit.c:1210
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 H.J. Lu changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2020-01/msg01777.ht ||ml Target Milestone|9.3 |10.0
[Bug fortran/93463] New: ICE in oacc_code_to_statement, at fortran/openmp.c:6007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93463 Bug ID: 93463 Summary: ICE in oacc_code_to_statement, at fortran/openmp.c:6007 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Combination of -fopenmp -fopenacc affects versions down to r5 : $ cat z1.f90 program p integer :: i, x !$omp parallel do do i = 1, 4 !$acc enter data create(x) end do end $ cat z2.f90 program p integer :: i, x !$omp parallel do do i = 1, 4 !$acc cache(x) end do end $ cat z6.f90 program p !$omp parallel !$acc wait(1) !$omp end parallel end $ cat z9.f90 program p !$omp parallel !$acc update self(a) !$omp end parallel end $ gfortran-10-20200126 -c z1.f90 -fopenmp -fopenacc f951: internal compiler error: in oacc_code_to_statement, at fortran/openmp.c:6007 0x69037d oacc_code_to_statement ../../gcc/fortran/openmp.c:6007 0x6994a2 resolve_oacc_directive_inside_omp_region ../../gcc/fortran/openmp.c:6017 0x6994a2 gfc_resolve_oacc_directive(gfc_code*, gfc_namespace*) ../../gcc/fortran/openmp.c:6333 0x6b719b gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:12047 0x6c6f2f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10715 0x6b6d68 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11678 0x6c6f2f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10715 0x69908d gfc_resolve_omp_do_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/openmp.c:5533 0x69a61b gfc_resolve_omp_parallel_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/openmp.c:5586 0x6b6d54 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11654 0x6b95e7 resolve_codes ../../gcc/fortran/resolve.c:17205 0x6b96ae gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17240 0x6a7a0c resolve_all_program_units ../../gcc/fortran/parse.c:6244 0x6a7a0c gfc_parse_file() ../../gcc/fortran/parse.c:6491 0x6f265f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug target/89229] Incorrect xmm16-xmm31/ymm16-ymm31 in vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 --- Comment #27 from H.J. Lu --- *** Bug 89346 has been marked as a duplicate of this bug. ***
[Bug target/89346] Unnecessary EVEX encoding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89346 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from H.J. Lu --- Dup
[Bug target/89346] Unnecessary EVEX encoding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89346 H.J. Lu changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 89229 ***
[Bug fortran/93462] New: ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462 Bug ID: 93462 Summary: ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Follow-up of pr92977, with pragma acc instead of omp : $ cat z1.f90 program p integer :: n = 1 integer :: a !$acc atomic write a = f(n) - f(n) contains integer function f(x) integer, intent(in) :: x f = x end end $ gfortran-10-20200126 -c z1.f90 -O2 -fopenacc z1.f90:4:0: 4 | !$acc atomic write | internal compiler error: in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771 0x7b2fa5 gfc_trans_omp_atomic ../../gcc/fortran/trans-openmp.c:3771 0x7c4667 gfc_trans_oacc_directive(gfc_code*) ../../gcc/fortran/trans-openmp.c:5742 0x731387 trans_code ../../gcc/fortran/trans.c:2158 0x76899d gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6823 0x6e2796 translate_all_program_units ../../gcc/fortran/parse.c:6305 0x6e2796 gfc_parse_file() ../../gcc/fortran/parse.c:6544 0x72d8ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
[Bug fortran/93461] New: Bogus "symbol is already defined" with long subroutine names in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461 Bug ID: 93461 Summary: Bogus "symbol is already defined" with long subroutine names in submodule Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code causes a bogus "symbol is already defined" error (using git commit 472dc648ce3e7661762931d584d239611ddca964): module aModuleWithAnAllowedName interface module subroutine aShortName() end subroutine aShortName end interface end module aModuleWithAnAllowedName submodule (aModuleWithAnAllowedName) aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName contains subroutine aShortName() call aSubroutineWithAVeryLongNameThatWillCauseAProblem() call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() end subroutine aShortName subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem() end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso() end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c symlength.F90 -o symlength.o -ffree-line-length-none -frecursive -pthread -Wall -fbacktrace -ffpe-trap=invalid,zero,overflow -fdump-core -O3 -ffinite-math-only -fno-math-errno -fopenmp -g /tmp/cc8B4Hmp.s: Assembler messages: /tmp/cc8B4Hmp.s:20: Error: symbol `__amodulewithanallowedname.asubmodulewithaveryveryverylongbutentirelylegalname_MOD_asubroutinewithaverylongnamethatwillcauseaprobl' is already defined
[Bug testsuite/93460] New: [10 regression] new test case gcc.dg/torture/pr93170.c fails with excess errors in r10-6246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93460 Bug ID: 93460 Summary: [10 regression] new test case gcc.dg/torture/pr93170.c fails with excess errors in r10-6246 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: --- g:150760dd6dd1899705790183d646fa5fc004554e r10-6246 FAIL: gcc.dg/torture/pr93170.c -O0 (test for excess errors) FAIL: gcc.dg/torture/pr93170.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr93170.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr93170.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr93170.c -Os (test for excess errors) FAIL: gcc.dg/torture/pr93170.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/pr93170.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr93170.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never-O1-lm -o ./pr93170.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr93170.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O1 -lm -o ./pr93170.exe /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr93170.c: In function 'foo': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr93170.c:17:1: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee [-Wpsabi] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr93170.c:16:1: warning: GCC vector passed by reference: non-standard ABI extension with no compatibility guarantee [-Wpsabi] FAIL: gcc.dg/torture/pr93170.c -O1 (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr93170.c:17:1: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee [-Wpsabi] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr93170.c:16:1: warning: GCC vector passed by reference: non-standard ABI extension with no compatibility guarantee [-Wpsabi]
[Bug target/91461] Don't turn on X86_TUNE_SSE_TYPELESS_STORES for AVX/AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91461 H.J. Lu changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2020-01/msg01774.ht ||ml Target Milestone|--- |10.0 --- Comment #3 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01774.html
[Bug tree-optimization/93447] Value range propagation not working at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93447 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The # RANGE [-35, 0] NONZERO 4294967261 # d_5 = PHI <0(2), -35(3)> _4 = d_5 != 0; # RANGE [0, 1] NONZERO 1 _12 = (int) _4; return _12; to: # RANGE [-35, 0] NONZERO 4294967261 # d_5 = PHI <0(2), -35(3)> # RANGE [0, 1] NONZERO 1 # prephitmp_13 = PHI <0(2), 1(3)> return prephitmp_13; optimization is performed by PRE, which is enabled also for -Os, so not sure why it doesn't trigger here. Richard? -O1 is a different thing, we intentionally don't enable various compile time or memory expensive optimizations at that level.
[Bug bootstrap/93214] [10 Regression] Ada LTO bootstrap fails with undefined reference to __gnat_debug_raise_assert_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93214 --- Comment #3 from Martin Jambor --- I don't know what helped but I was able to LTO bootstrap Ada today, specifically master commit r10-6244-e97a3063fb1 (on x86_64-linux).
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 47717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47717=edit gcc10-pr93418.patch Untested fix.
[Bug target/71727] -O3 -mstrict-align produces code which assumes unaligned vector accesses work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71727 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from rsandifo at gcc dot gnu.org --- Fixed on master.
[Bug tree-optimization/93440] scalar unrolled loop makes vectorized code unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93440 --- Comment #3 from ikonomisma at googlemail dot com --- (In reply to Richard Biener from comment #2) > Hmm, I get > > /home/space/rguenther/install/gcc-9.2/include/c++/9.2.0/pstl/execution_defs. > h:155:7: error: no type named ‘type’ in ‘struct std::enable_if’ > 155 | using __enable_if_execution_policy = > | ^~~~ > > trying to compile this with the FSF 9.2.0 release. Well, as far as I understand there should be an overload without an execution policy, both https://en.cppreference.com/w/cpp/algorithm/transform_reduce and the n4659 c++ draft standard include it.
[Bug c++/92948] internal compiler error: in tsubst_copy, at cp/pt.c:15788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92948
--- Comment #3 from Marek Polacek ---
Test I've been playing with:
struct A {
constexpr A(int) { }
};
template
struct B {
using U = unsigned;
};
template
using U = B;
//template::U> // ok
template::U> // ICE
//template::U> // error
void foo()
{
}
void
g ()
{
foo<1>();
}
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #37 from Wilco --- (In reply to Andrew Pinski from comment #36) > MIPS is still broken. I might look into MIPS brokenness next week. Yes it seems builtin_longjmp has the exact same fp corruption issue: move$fp,$17 lw $sp,8($fp) jr $16 lw $28,12($fp)
[Bug rtl-optimization/93170] [10 Regression] wrong code due to use of a call-clobbered register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93170 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug target/93459] ix86_fold_builtin should handle __builtin_ia32_pcmpeqd128_mask and similar builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93459
--- Comment #1 from Jakub Jelinek ---
Also
__builtin_ia32_pbroadcastd512_gpr_mask
__builtin_ia32_psllv16si_mask
__builtin_ia32_vec_ext_v4si
__builtin_ia32_extracti32x4_mask
and many others.
#include
void link_error (void);
void
foo (void)
{
__m128i a = _mm_set1_epi32 (0xU);
__m128i b = _mm_setr_epi32 (16, 31, -34, 3);
__m128i c = _mm_sllv_epi32 (a, b);
__m512i d = _mm512_set1_epi32 (0xU);
__m512i e = _mm512_setr_epi32 (16, 31, -34, 3, 4, 3, 4, 3, 4, 3, 4, 3, 4, 3,
4, 3);
__m512i f = _mm512_sllv_epi32 (d, e);
if (_mm_extract_epi32 (c, 0) != 0xU
|| _mm_extract_epi32 (c, 1) != 0x8000U
|| _mm_extract_epi32 (c, 2) != 0
|| _mm_extract_epi32 (c, 3) != 0xfff8U)
link_error ();
__m128i g = _mm512_extracti32x4_epi32 (f, 0);
if (_mm_extract_epi32 (g, 0) != 0xU
|| _mm_extract_epi32 (g, 1) != 0x8000U
|| _mm_extract_epi32 (g, 2) != 0
|| _mm_extract_epi32 (g, 3) != 0xfff8U)
link_error ();
}
[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 --- Comment #4 from Vladimir Makarov --- (In reply to Andreas Krebbel from comment #3) > Created attachment 47714 [details] > IRA EH fix - only when added at start of BB > > A probably better version of the fix. This version only reverts the > allocation decision if the move is about to be added at the start of an EH > basic block. Andreas, thank you for explaining the problem. Your patch should solve the problem but my worry is that the final assignment can be worse (especially if the pseudo in a loop goes into an EH bb). I think that such pseudo should have the right conflicting hard regnos **before** the assignment. In this case the pseudo did not get a hard register living into EH but still can get another hard register. If you don't mind, I will take it from here and try to create such patch. If you want to continue this work by yourself, please let me know.
[Bug c++/93458] ICE using coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458 Tom Tromey changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from Tom Tromey --- I think it's invalid.
[Bug c++/93458] New: ICE using coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458
Bug ID: 93458
Summary: ICE using coroutines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm using git master gcc from today.
I tried a simple coroutine program:
int func(int *x) {
for (int i = 0; i < 23; ++i)
co_yield x[i];
}
Compiling causes gcc to ICE:
murgatroyd. ./install/bin/g++ -fcoroutines -g -c -o /tmp/qq.o /tmp/qq.cc
/tmp/qq.cc: In function ‘int func(int*)’:
/tmp/qq.cc:3:5: error: cannot find ‘coroutine traits’ template
3 | co_yield x[i];
| ^~~~
/tmp/qq.cc:3:17: internal compiler error: in coro_promise_type_found_p, at
cp/coroutines.cc:390
3 | co_yield x[i];
| ^
0x5ff2fd coro_promise_type_found_p
../../gcc/gcc/cp/coroutines.cc:390
0x94aeae finish_co_yield_expr(unsigned int, tree_node*)
../../gcc/gcc/cp/coroutines.cc:862
0xa163a0 cp_parser_yield_expression
../../gcc/gcc/cp/parser.c:26176
0xa163a0 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9816
0xa1668d cp_parser_expression
../../gcc/gcc/cp/parser.c:9992
0xa19498 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11633
0xa250e3 cp_parser_statement
../../gcc/gcc/cp/parser.c:11429
0xa45c36 cp_parser_already_scoped_statement
../../gcc/gcc/cp/parser.c:13198
0xa45f24 cp_parser_iteration_statement
../../gcc/gcc/cp/parser.c:12848
0xa25154 cp_parser_statement
../../gcc/gcc/cp/parser.c:11298
0xa26792 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11780
0xa26868 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11730
0xa3f085 cp_parser_function_body
../../gcc/gcc/cp/parser.c:22963
0xa3f085 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:23014
0xa42421 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:28846
0xa431c1 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:28762
0xa431c1 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20590
0xa22eb3 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13669
0xa4b197 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13368
0xa4b917 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug bootstrap/93416] [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93416 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #1 from David Malcolm --- Probably fixed by 6a81cabc14426b642271647b03218a3af19d600f; looks like a dup of the report in: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01485.html but it looks like that bug never made it into BZ. Does 6a81cabc14426b642271647b03218a3af19d600f fix this? Thanks
[Bug target/93459] New: ix86_fold_builtin should handle __builtin_ia32_pcmpeqd128_mask and similar builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93459
Bug ID: 93459
Summary: ix86_fold_builtin should handle
__builtin_ia32_pcmpeqd128_mask and similar builtins
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Just noticed we don't fold e.g.
#include
void link_error (void);
void
foo (void)
{
__m128i a = _mm_setr_epi32 (0xU, 0x8000U, 0, 0xfff8U);
if (_mm_cmpeq_epi32_mask (a, a) != 15)
link_error ();
}
with -O2 -mavx512vl, neither at GIMPLE time (ix86_fold_builtin), nor at RTL opt
time.
[Bug analyzer/93457] New: ICE in make_region_for_type, at analyzer/region-model.cc:5983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93457
Bug ID: 93457
Summary: ICE in make_region_for_type, at
analyzer/region-model.cc:5983
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.1-alpha20200126 snapshot (g:787c79e559f5f011989b94298346d89542eb9052)
ICEs when compiling the following testcase w/ -fanalyzer:
void
p5 (const void *);
void
s5 (const void *cl)
{
p5 ([1]);
}
% gcc-10.0.1-alpha20200126 -fanalyzer -w -c tjscjfme.c
during IPA pass: analyzer
tjscjfme.c: In function 's5':
tjscjfme.c:7:3: internal compiler error: in make_region_for_type, at
analyzer/region-model.cc:5983
7 | p5 ([1]);
| ^~~
0x71c05f make_region_for_type
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:5983
0x11032cc ana::region_model::add_region_for_type(ana::region_id, tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:5993
0x11032cc ana::array_region::get_or_create(ana::region_model*, ana::region_id,
int, tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:2331
0x1103829 ana::region_model::get_or_create_mem_ref(tree_node*, ana::svalue_id,
ana::svalue_id, ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:6526
0x110a3ac ana::region_model::get_or_create_pointer_plus_expr(tree_node*,
ana::svalue_id, ana::svalue_id, ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:6546
0x110a3ac ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/region-model.cc:3977
0x10e4f92 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:948
0x10e5b21 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:2439
0x10e6002 ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:2259
0x10e6689 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:3580
0x10e7123 ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/engine.cc:3634
0x10dcbe8 execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200126/work/gcc-10-20200126/gcc/analyzer/analyzer-pass.cc:84
I believe this ICE is different from PR93350.
[Bug analyzer/93349] ICE: verify_gimple failed (error: location references block not in block tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93349 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Should be fixed by above commit.
[Bug analyzer/93349] ICE: verify_gimple failed (error: location references block not in block tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93349 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:2fbea4190e76a59c4880727cf84706fe083c00ae commit r10-6263-g2fbea4190e76a59c4880727cf84706fe083c00ae Author: David Malcolm Date: Thu Jan 23 18:28:54 2020 -0500 analyzer: restore input_location (PR 93349) PR analyzer/93349 reports an ICE in IPA pass: simdclone for some input files when -fanalyzer is supplied, with: error: location references block not in block tree The root cause is that the analyzer touches input_location in some places (to make it easier to track down which source construct the analyzer can't handle in the case of an analyzer ICE) and fails to reset it. For the ICE in question, this sets input_location to a location_t that references some arbitrary block (specifically, that of the last statement to be analyzed, within the original CFG of whichever is the last such function to be analyzed). Later, within omp-simd-clone.c, input_location is used by gimplify_expr (called via gimplify_and_add), which has: 14492 if (!gimple_seq_empty_p (*pre_p)) 14493 annotate_all_with_location_after (*pre_p, pre_last_gsi, input_location); thus using whatever the value of input_location is, leading to statements that reference some arbitrary block in the original CFG. For the reproducer, this happens to be a block in the CFG for the original function, rather than that of the clone, but in general it could be some arbitrary other function in the TU. This code appears to assume that input_location has some arbitrary value *not* in the block tree, which is potentially violated by the analyzer's changes to input_location. This patch adds a save and restore of input_location at the top-level function of the analyzer, fixing the ICE. gcc/analyzer/ChangeLog: PR analyzer/93349 * engine.cc (run_checkers): Save and restore input_location. gcc/testsuite/ChangeLog: PR analyzer/93349 * gcc.dg/analyzer/torture/pr93349.c: New test.
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Should be fixed by the above commit
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f89e844f9c589d1717248597641d25d81a4acb41 commit r10-6262-gf89e844f9c589d1717248597641d25d81a4acb41 Author: David Malcolm Date: Fri Jan 17 11:03:15 2020 -0500 analyzer: fix pattern-test-2.c (PR 93291) Amongst the inputs to the analyzer state machines that can lead to state transitions are conditions on CFG edges, such as a test for a pointer being non-NULL. These conditionals can be non-trivial to determine in the face of optimization. For example, at -O2: if (p == NULL || q == NULL) is optimized on some targets (e.g. x86_64) to a bitwise-or: _1 = p_5(D) == 0B; _2 = q_6(D) == 0B; _3 = _1 | _2; if (_3 != 0) goto ; [51.12%] else goto ; [48.88%] but on other targets (e.g. powerpc64le) as control flow: if (p_2(D) == 0B) goto ; [18.09%] else goto ; [81.91%] [local count: 879501929]: if (q_3(D) == 0B) goto ; [30.95%] else goto ; [69.05%] region_model::add_any_constraints_from_ssa_def_stmt attempts to walk SSA def chains to reconstruct the conditions that hold, so that e.g. in the above case of bitwise-or, the state machine for "p" can transition to the "known-null" state along the edge leading to bb 3. In gcc.dg/analyzer/pattern-test-2.c I attempted to write test coverage for this, but the test fails on those targets for which the || is expressed via control flow. This patch rewrites the test to make explicit use of bitwise-or, and adds coverage for bitwise-and for good measure. gcc/testsuite/ChangeLog: PR analyzer/93291 * gcc.dg/analyzer/pattern-test-2.c: Remove include of stdlib.h. (test_2): Rewrite to explicitly perform a bitwise-or of two boolean conditions. (test_3): New function, to test bitwise-and.
