[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #2 from Kip Warner --- Sorry, not same issue. It appears as though this was fixed in gcc-11.
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 Kip Warner changed: What|Removed |Added Version|10.2.0 |11.0 --- Comment #1 from Kip Warner --- Just tested with Git head (11.0.0 20201008) and same issue: $ gcc --version gcc (GCC) 11.0.0 20201008 (experimental) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -Q -mcpu=power9 --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=512 $ getconf -a | grep CACHE LEVEL1_ICACHE_SIZE 32768 LEVEL1_ICACHE_ASSOC32 LEVEL1_ICACHE_LINESIZE 128 LEVEL1_DCACHE_SIZE 32768 LEVEL1_DCACHE_ASSOC32 LEVEL1_DCACHE_LINESIZE 128 LEVEL2_CACHE_SIZE 524288 LEVEL2_CACHE_ASSOC 2048 LEVEL2_CACHE_LINESIZE 32 LEVEL3_CACHE_SIZE 10485760 LEVEL3_CACHE_ASSOC 40960 LEVEL3_CACHE_LINESIZE 32 LEVEL4_CACHE_SIZE 0 LEVEL4_CACHE_ASSOC 0 LEVEL4_CACHE_LINESIZE 0 $ cat /proc/cpuinfo processor : 0 cpu : POWER9, altivec supported clock : 2933.00MHz revision: 2.2 (pvr 004e 1202) (...) processor : 143 cpu : POWER9, altivec supported clock : 2166.00MHz revision: 2.2 (pvr 004e 1202) timebase: 51200 platform: PowerNV model : machine : PowerNV firmware: OPAL MMU : Radix
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 --- Comment #21 from Luke Dashjr --- Not entirely, I think? At least according to the docs: if you wish to enable built-in functions selectively when using -fno-builtin or -ffreestanding, you may define macros such as: #define abs(n) __builtin_abs ((n)) #define strcpy(d, s)__builtin_strcpy ((d), (s)) Which suggests code that calls __builtin_memcmp explicitly could still be broken.
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c1c62aec6751678e958ab5c61b2d903a09d7efd9 commit r11-3714-gc1c62aec6751678e958ab5c61b2d903a09d7efd9 Author: Patrick Palka Date: Thu Oct 8 00:05:41 2020 -0400 c++: ICE in dependent_type_p with constrained auto [PR97052] This patch fixes an "unguarded" call to coerce_template_parms in build_standard_check: processing_template_decl could be zero if we get here during processing of the first 'auto' parameter of an abbreviated function template, or if we're processing the type constraint of a non-templated variable. In the testcase below, this leads to an ICE when coerce_template_parms instantiates C's dependent default template argument. gcc/cp/ChangeLog: PR c++/97052 * constraint.cc (build_type_constraint): Temporarily increment processing_template_decl before calling build_concept_check. * pt.c (make_constrained_placeholder_type): Likewise. gcc/testsuite/ChangeLog: PR c++/97052 * g++.dg/cpp2a/concepts-defarg2.C: New test.
[Bug c++/96229] Invalid specialization accepted when also constrained in base template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96229 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6b1b5c255f859e75a2d74ae58a011e846d87a277 commit r11-3713-g6b1b5c255f859e75a2d74ae58a011e846d87a277 Author: Patrick Palka Date: Thu Oct 8 00:05:36 2020 -0400 c++: Set the constraints of a class type sooner [PR96229] In the testcase below, during processing (at parse time) of Y's base class X, convert_template_argument calls is_compatible_template_arg to check if the template argument Y is no more constrained than the parameter P. But at this point we haven't yet set Y's constraints, so get_normalized_constraints_from_decl yields NULL_TREE as the normal form and caches this result into the normalized_map. We set Y's constraints later in cp_parser_class_specifier_1 but the stale normal form in the normalized_map remains. This ultimately causes us to miss the constraint failure for Y because according to the cached normal form, Y is not constrained. This patch fixes this issue by moving up the call to associate_classtype_constraints so that we set constraints before we start processing a class's bases. gcc/cp/ChangeLog: PR c++/96229 * parser.c (cp_parser_class_specifier_1): Move call to associate_classtype_constraints from here to ... (cp_parser_class_head): ... here. * pt.c (is_compatible_template_arg): Correct documentation to say "argument is _no_ more constrained than the parameter". gcc/testsuite/ChangeLog: PR c++/96229 * g++.dg/cpp2a/concepts-class2.C: New test.
[Bug c++/96575] std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96575 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||ppalka at gcc dot gnu.org Last reconfirmed||2020-10-08 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Confirmed. Taking a look.
[Bug c/97329] New: POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 Bug ID: 97329 Summary: POWER9 default cache and line sizes appear to be wrong Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kip at thevertigo dot com Target Milestone: --- While investigating the memory hierarchy on my Romulus POWER9 (CPU revision 2.2) I discovered GCC's default L1 cache and line sizes on POWER9 are not correct. I think whoever specified the default cache size of 64KB may not have realized the L1 cache is banked, and not unified. On POWER9 that 64KB is split between separate instructions and data spaces. Only 32KB is actually available for data. GCC's documentation specifies that the l1-cache-size parameter is suppose to refer to data only, but not instructions. Further, the default l1-cache-line-size is wrong. It's currently set at 32 bytes. The correct value is actually four times that at 128 bytes. As things are right now, the resulting generated code may not be properly optimized because the optimizer plans around the wrong parameters. When this happens the generated program may have a higher than necessary cache miss rate. This could be a big deal since the CPU retrieving data from the L1 may only take one or two cycles, but a cache miss could mean several hundred while the block is transferred.
[Bug c++/97328] New: [ICE] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97328
Bug ID: 97328
Summary: [ICE] internal compiler error: in verify_ctor_sanity,
at cp/constexpr.c:3995
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Following code causes ICE, but *ONLY* when explicitly passing `-std=c++20`.
```
template
struct vector {
union storage {
T t;
constexpr storage() {}
} data[N];
};
constexpr auto foo() {
vector i;
return i;
}
auto f = foo();
```
See https://godbolt.org/z/hYYeq8.
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #20 from Rich Felker --- For what it's worth, -fno-builtin is a workaround for this entire class of bug.
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 --- Comment #1 from Christophe Lyon --- Similarly: -mcpu=cortex-m55+nomve -march=armv8.1-m.main+mve -mfloat-abi=softfp cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1-m.main' switch -mcpu=cortex-m55+nomve -march=armv8.1-m.main -mfloat-abi=softfp cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1-m.main' switch
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 Christophe Lyon changed: What|Removed |Added Target||arm Target Milestone|--- |11.0
[Bug target/97327] New: -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 Bug ID: 97327 Summary: -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- When compiling with -mthumb -mcpu=cortex-m55 I get: cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1-m.main' switch unless I add -mfloat-abi=hard or -march=armv8.1-m.main which is a bit counter-intuitive.
[Bug target/97322] [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 --- Comment #2 from Christophe Lyon --- Thanks, this patch does fix both builds for me.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #21 from anlauf at gcc dot gnu.org --- Please see PR96983 for the fallout. Note that my bandaid fix was rejected in favor of a "real solution" for powerpc*. See the other PR and the Fortran ML for background.
[Bug c++/97010] C++20 ADL and function templates that are not visible (P0846R0) fails on call with templated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:635072248a426c933c74ef4431e82401249b6218 commit r11-3709-g635072248a426c933c74ef4431e82401249b6218 Author: Marek Polacek Date: Thu Sep 10 17:27:43 2020 -0400 c++: Fix P0846 (ADL and function templates) in template [PR97010] To quickly recap, P0846 says that a name is also considered to refer to a template if it is an unqualified-id followed by a < and name lookup finds either one or more functions or finds nothing. In a template, when parsing a function call that has type-dependent arguments, we can't perform ADL right away so we set KOENIG_LOOKUP_P in the call to remember to do it when instantiating the call (tsubst_copy_and_build/CALL_EXPR). When the called function is a function template, we represent the call with a TEMPLATE_ID_EXPR; usually the operand is an OVERLOAD. In the P0846 case though, the operand can be an IDENTIFIER_NODE, when name lookup found nothing when parsing the template name. But we weren't handling this correctly in tsubst_copy_and_build. First we need to pass the FUNCTION_P argument from to , otherwise we give a bogus error. And then in we need to perform ADL. The rest of the changes is to give better errors when ADL didn't find anything. gcc/cp/ChangeLog: PR c++/97010 * pt.c (tsubst_copy_and_build) : Call tsubst_copy_and_build explicitly instead of using the RECUR macro. Handle a TEMPLATE_ID_EXPR with an IDENTIFIER_NODE as its operand. : Perform ADL for a TEMPLATE_ID_EXPR with an IDENTIFIER_NODE as its operand. gcc/testsuite/ChangeLog: PR c++/97010 * g++.dg/cpp2a/fn-template21.C: New test. * g++.dg/cpp2a/fn-template22.C: New test.
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 --- Comment #7 from Jonathan Wakely --- Oops, yes I can, I messed up my test.
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 --- Comment #6 from Jonathan Wakely --- I can't get the algorithm to ever produce an intermediate result that doesn't fit in 32 bits, so I'm not sure there's actually a problem here in practice.
[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #10 from Patrick Palka ---
Here's a more condensed testcase (accepted with -std=c++11/14, ICEs with
-std=c++17/20):
template class a {
template struct c {
template using t = int;
t m;
};
};
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 --- Comment #5 from Jonathan Wakely --- I don't see how manually written arithmetic with explicit % operations is going to beat using built-in types that do that automatically. If 64-bit arithmetic is faster than 32-bit arithmetic, I would expect the compiler to use 64-bit registers and mask them off to produce 32-bit results. If the user has to do that manually to get better performance, then the compiler has a bug. The only reason not to use uint32_t is because some platforms don't support it, and as I've already said that's not relevant for this implementation.
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 --- Comment #4 from Jonathan Wakely --- (In reply to Kristian Spangsege from comment #3) > bonus, the code will work on platforms that do not have std::uint32_t. GCC doesn't work on such platforms, and other parts of libstdc++ already assume it exists, so that's not useful.
[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 --- Comment #12 from Mark Wielaard --- (In reply to David Malcolm from comment #11) > (In reply to Mark Wielaard from comment #10) > > Created attachment 49293 [details] > > supergraph > > Thanks. Compared to my testing, I'm seeing what appear to be differences in > the inputs to the analyzer at the gimple level, which are likely due to > differences in the rest of the compiler. > > Is this with the same version of gcc as in comment #4, where you said "gcc > (GCC) 11.0.0 20200916 (experimental)". > > You don't happen to know exactly which revision, do you? I am afraid I don't know exactly. I have been experimenting with having DWARF 5 as default in my builds, which is another difference. > [The md5sum of the bzip2.c I'm using is 23f66348f80345353d5b5b98e299ff15. > There could also be differences in the system headers, I suppose] The MD5 matches. But I am indeed using system headers from RHEL7 with DTS9 installed to bootstrap my GCC builds.
[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 --- Comment #6 from Andreas Tobler --- First, excuse me Thomas, I was focused on 'Tobias' from the description text. It seems to pass bootstrap with /usr/bin/ld on FreeBSD-13. The test suite will tell more.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #6 from qinzhao at gcc dot gnu.org --- when using gcc10.2 to compile our application, we have the same compilation error.
[Bug rtl-optimization/97326] New: [11 Regression] s390: ICE in do_store_flag after 10843f830350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326
Bug ID: 97326
Summary: [11 Regression] s390: ICE in do_store_flag after
10843f830350
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
The following (minimized from
gcc/testsuite/gcc.target/s390/zvector/autovec-double-signaling-eq.c) produces
an ICE on s390:
build$ cat x.c
long *a;
double *b;
c;
d() {
for (; c; c++)
a[c] = 0 <= b[c] && 0 >= b[c];
}
build$ gcc/cc1 -O3 -march=z15 x.c
during RTL pass: expand
x.c: In function 'd':
x.c:4:1: internal compiler error: in do_store_flag, at expr.c:12388
0x150dd15 do_store_flag
../../gcc/expr.c:12388
0x1505e1b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9621
0x14ec50d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10165
0x14ef981 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:8480
0x1635191 expand_normal
../../gcc/expr.h:288
0x1635191 expand_vect_cond_optab_fn
../../gcc/internal-fn.c:2602
0x136d83d expand_call_stmt
../../gcc/cfgexpand.c:2612
0x136d83d expand_gimple_stmt_1
../../gcc/cfgexpand.c:3686
0x136d83d expand_gimple_stmt
../../gcc/cfgexpand.c:3851
0x1374f4b expand_gimple_basic_block
../../gcc/cfgexpand.c:5892
0x1377963 execute
../../gcc/cfgexpand.c:6576
Bisect points to:
commit 10843f8303509fcba880c6c05c08e4b4ccd24f36
Author: Richard Biener
Date: Thu Sep 24 10:14:33 2020 +0200
tree-optimization/97085 - fold some trivial bool vector ?:
[Bug c++/97052] Internal compiler error with substitution failure in template parameter list of concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97052 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org
[Bug tree-optimization/97325] [11 Regression] wrong code with __builtin_ffs() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325 --- Comment #4 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #2) > Looking at the evrp dump, I see > EVRP:hybrid: RVRP found singleton 0 > EVRP:hybrid: RVRP found singleton 0 > EVRP:hybrid: RVRP found singleton 0 > > Value ranges after Early VRP: > > _1: short unsigned int VARYING > _2: int [0, 65535] > _3: int [-65535, 0] > : int [0, 32] > : long long unsigned int [0, 0] > c_6(D): long long unsigned int VARYING > : long long unsigned int [0, 32] > > These entries with nothing before : look confusing... Huh, thats just an ssa_name dump. in my listing it shows up: _1: short unsigned int VARYING _2: int [0, 65535] _3: int [-65535, 0] _4: int [0, 32] iftmp.0_5: long long unsigned int [0, 32] c_6(D): long long unsigned int VARYING iftmp.0_8: long long unsigned int [0, 32] and without the fix, ahhh, i get the same . wonder if its because the code/names got removed at the end of the pass... I'll look into that
[Bug tree-optimization/97325] [11 Regression] wrong code with __builtin_ffs() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325 Andrew Macleod changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com --- Comment #3 from Andrew Macleod --- Created attachment 49327 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49327=edit patch to always evaluate in unsigned The range-op code for handling FFS and popcount doesn't take into account a possibly negative parameter. The code was simply using the upper bound, which for [-65535, 0] was 0, we we were getting a range o f[0, 0] instead of [0,32] fix is to cast the range to unsigned before doing such calculation. I'll add this patch to the test cycle.
[Bug tree-optimization/97325] [11 Regression] wrong code with __builtin_ffs() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325 --- Comment #2 from Jakub Jelinek --- Looking at the evrp dump, I see EVRP:hybrid: RVRP found singleton 0 EVRP:hybrid: RVRP found singleton 0 EVRP:hybrid: RVRP found singleton 0 Value ranges after Early VRP: _1: short unsigned int VARYING _2: int [0, 65535] _3: int [-65535, 0] : int [0, 32] : long long unsigned int [0, 0] c_6(D): long long unsigned int VARYING : long long unsigned int [0, 32] These entries with nothing before : look confusing...
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 --- Comment #3 from Kristian Spangsege --- I would recommend not locking arithmetic to std::uint32_t, and instead working with std::uint_fast32_t, because I can imaging a platform (current or future) where 32-bit arithmetic is slower that 64-bit arithmetic. As a bonus, the code will work on platforms that do not have std::uint32_t.
[Bug tree-optimization/97325] [11 Regression] wrong code with __builtin_ffs() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-10-07
Ever confirmed|0 |1
Target Milestone|--- |11.0
Status|UNCONFIRMED |NEW
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com,
||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Started with r11-3684 or r11-3685-gfcae5121154d1c3382b056bcc2c563cedac28e74
(the former commit doesn't build).
unsigned long long
foo (unsigned long long c)
{
return c ? __builtin_ffs (-(unsigned short) c) : 0;
}
int
main ()
{
if (foo (2) != 2)
__builtin_abort ();
return 0;
}
[Bug c++/96355] [10/11 Regression] [concepts] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96355 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #4 from Patrick Palka --- Looks like trunk now accepts the testcases in #c0 and #c3. I think this is the same issue as PR96531, thus marking this PR as a dup. *** This bug has been marked as a duplicate of bug 96531 ***
[Bug c++/96531] [10/11 Regression] ICE for concepts here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96531 Patrick Palka changed: What|Removed |Added CC||src at andyf dot de --- Comment #3 from Patrick Palka --- *** Bug 96355 has been marked as a duplicate of this bug. ***
[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 --- Comment #5 from Andreas Tobler --- Hi Tobias, on FreeBSD-12.1, the ld is from binutils 2.17, a really old one. Try to configure with '--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld '. Prerequisite is the installation of the binutils package. I just tried on FreeBSD-13-trunk, stage one passed with the above config parameters. (Today's gcc trunk) Now I try to use the llvm ld, the one which will be /usr/bin/ld from FreeBSD-13 up. Let me how it works, Andreas
[Bug target/97322] [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-10-07 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 49326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49326=edit gcc11-pr97322.patch Untested fix.
[Bug tree-optimization/97325] New: [11 Regression] wrong code with __builtin_ffs() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97325 Bug ID: 97325 Summary: [11 Regression] wrong code with __builtin_ffs() at -O2 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 49325 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49325=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-3698-20201007141249-ge089e43365f-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-3698-20201007141249-ge089e43365f-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20201007 (experimental) (GCC) It triggers also on different targets, such as: $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-3706-20201007180615-g1e247c60df5-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/11.0.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-3706-20201007180615-g1e247c60df5-checking-yes-rtl-df-extra-aarch64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20201007 (experimental) (GCC)
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315 Andrew Macleod changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com --- Comment #10 from Andrew Macleod --- Created attachment 49324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49324=edit Patch to fix the problem Running the following patch thru bootstrap and testing. a) removes the trap and instead annotates the listing. b) Changes any non-overflow calculation in which both bounds are overflow/underflow to be undefined. Which seems to resolve everything I am seeing in this PR.
[Bug c/97324] New: -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 Bug ID: 97324 Summary: -mcpu= isn't validated on x86 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kip at thevertigo dot com Target Milestone: --- On amd64 I see the following: $ gcc-10 -Q --help=param -mcpu=sdfdsf gcc-10: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead The following options control parameters: --param=align-loop-iterations=4 (...) On my POWER9 machine I see the following: $ gcc-10 -Q --help=param -mcpu=sdfdsf gcc-10: error: unrecognized argument in option ‘-mcpu=sdfdsf’ gcc-10: note: valid arguments to ‘-mcpu=’ are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power10 power3 power4 power5 power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le rs64 titan Note that on amd64 the CPU value's nonsensical value was not validated.
[Bug tree-optimization/97307] Optimization for pure vs. const function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307
--- Comment #8 from rguenther at suse dot de ---
On October 7, 2020 5:30:14 PM GMT+02:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307
>
>Jakub Jelinek changed:
>
> What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
>--- Comment #7 from Jakub Jelinek ---
>(In reply to Richard Biener from comment #3)
>> The patch will cause
>>
>> FAIL: gcc.dg/vect/pr65947-3.c scan-tree-dump-times vect "LOOP
>VECTORIZED" 2
>>
>> since the testcase has exactly such a pattern:
>>
>> unsigned int
>> condition_reduction (unsigned int *a, unsigned int min_v, unsigned
>int *b)
>> {
>> unsigned int last = N + 65;
>> unsigned int aval;
>>
>> for (unsigned int i = 0; i < N; i++)
>> {
>> aval = a[i];
>> if (b[i] < min_v)
>> last = aval;
>> }
>> return last;
>> }
>>
>> and sinking the aval = a[i] load causes if-conversion to no longer
>happen
>> because a[i] now appears to only conditionally trap. It will be
>vectorized
>> with masked loads if those are available though, so I'm considering
>to
>> XFAIL it for the moment.
>
>Isn't that an important real-world case though? I mean, people who
>care a lot
>about the vectorization often change code from the loads in the
>conditionals to
>preloading the value before the condition, such that it can be
>vectorized and
>now it won't (and masked loads are less common among architectures that
>can
>vectorize such loops than non-masked ones).
>So shouldn't we just sink that way calls before vectorization and after
>vectorization everything? Or have some way to tell ifcvt it can undo
>the
>sinking.
It is a general issue we might want to address. Either by if converting this
earlier (phiopt, had some patches with the min/max stuff I dropped the ball on)
or by doing sinking only after loop opts /vectorization (like we moved
predcom). That we didn't sink here is an artifact of the testcase surroundings,
not the actual kernel.
[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-10-07 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #9 from rguenther at suse dot de ---
On October 7, 2020 5:35:02 PM GMT+02:00, amacleod at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
>
>--- Comment #8 from Andrew Macleod ---
>(In reply to David Binderman from comment #6)
>> I get something similar with this test case:
>>
>> int a;
>> void b() {
>> if (a >= 2147483647)
>> c(a + 1);
>> }
>
>This one is slightly different.
>
>Still triggering in the same place, but the difference in the singleton
>is the
>result of the calculation of:
>
> [+INF, +INF] + 1
>
>EVRP is reporting [-INF, -INF], and range-ops is calculating [+INF,
>+INF]
>
>Is there a correct answer, or does it matter?
While we print +inf it's just a value we can apply +1 to in the "do what I
mean" sense. So I think for arithmetic we shouldn't saturate, even when
overflow is undefined (instead as, you say, UNDEFINED would be the correct
optimistic result).
>The code we imported for handling overflow always sets the bound to
>+INF if an
>overflow happens, and it happens on both bounds, so we get [+INF,
>+INF]. I'm
>guessing because its a single value EVRP actually folded the value
>regardless
>of overflow?
>
>Or maybe it should be UNDEFINED?
>
>Andrew
[Bug target/97323] New: [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323 Bug ID: 97323 Summary: [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- seen on the gcc-10 branch and trunk 20201003 on arm-linux-gnueabihf. Omitting -g works around the issue. $ cat signal.i typedef int a __attribute__((aligned(2))); a b[1]; $ gcc -c -g -O0 signal.i signal.i:2:1: error: 'TYPE_CANONICAL' is not compatible 2 | a b[1]; | ^ unit-size align:32 warn_if_not_align:0 symtab:-144899760 alias-set -1 canonical-type 0xf7a4f3c0 precision:32 min max pointer_to_this > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d7e0 domain unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf7a4f060 precision:32 min max > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d6c0 precision:32 min max >> signal.i:2:1: error: 'TYPE_MODE' of 'TYPE_CANONICAL' is not compatible unit-size align:32 warn_if_not_align:0 symtab:-144899760 alias-set -1 canonical-type 0xf7a4f3c0 precision:32 min max pointer_to_this > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d7e0 domain unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf7a4f060 precision:32 min max > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d6c0 precision:32 min max >> unit-size user align:16 warn_if_not_align:0 symtab:-144899808 alias-set -1 canonical-type 0xf7a4f3c0 precision:32 min max > no-force-blk BLK size unit-size user align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d7e0 domain unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf7a4f060 precision:32 min max > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf751d6c0 precision:32 min max >> signal.i:2:1: internal compiler error: 'verify_type' failed 0x980721 verify_type(tree_node const*) ../../src/gcc/tree.c:14727 0x3969e3 gen_type_die_with_usage ../../src/gcc/dwarf2out.c:25498 0x397fe9 gen_type_die ../../src/gcc/dwarf2out.c:25728 0x393fd5 gen_decl_die ../../src/gcc/dwarf2out.c:26399 0x394aed dwarf2out_decl ../../src/gcc/dwarf2out.c:26908 0x394f8f dwarf2out_early_global_decl ../../src/gcc/dwarf2out.c:26565 0x1c59b1 finish_decl(tree_node*, unsigned int, tree_node*, tree_node*, tree_node*) ../../src/gcc/c/c-decl.c:5453 0x223611 c_parser_declaration_or_fndef ../../src/gcc/c/c-parser.c:2336 0x22bbdf c_parser_external_declaration ../../src/gcc/c/c-parser.c:1745 0x22c451 c_parser_translation_unit ../../src/gcc/c/c-parser.c:1618 0x22c451 c_parse_file() ../../src/gcc/c/c-parser.c:21752 0x279abd c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1190 Please submit a full bug report, with preprocessed source if appropriate. gcc is configured with --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=yes,extra,rtl --enable-default-pie a gcc configured with --enable-checking=release doesn't show this, however segfaults in an unreproducible way in other places.
[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 Thomas Koenig changed: What|Removed |Added Component|target |bootstrap CC||andreast at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- Guess this should be component "bootstrap".
[Bug c++/97279] GCC ignores the operation definition of the template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97279 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-10-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- Thanks Harald. Confirmed then, I suppose.
[Bug sanitizer/97294] ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97294 --- Comment #3 from Jakub Jelinek --- Note I'm afraid we can't put the testcase into GCC testsuite easily, because we have testsuite for libgomp and testsuite for asan, but don't have *.exp to link against both libraries at their build locations at once.
[Bug sanitizer/97294] ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97294
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Jakub Jelinek ---
Created attachment 49323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49323=edit
gcc11-pr97294.patch
Untested fix.
Self-contained testcase with -O0 -fsanitize=address -fopenmp could be e.g.
__attribute__((noipa)) void
foo (int *p, int n)
{
int i;
#pragma omp parallel for num_threads(2) reduction(+:p[:n])
for (i = 0; i < 10; i++)
{
p[0]++;
p[n - 1] += 2;
}
}
__attribute__((noipa)) void
bar (void)
{
unsigned char buf[1024];
int i;
asm volatile ("" : : "r" ([0]) : "memory");
for (i = 0; i < 1024; i++)
buf[i] = i;
asm volatile ("" : : "r" ([0]) : "memory");
}
int
main ()
{
int p[50], i;
for (i = 0; i < 50; i++)
p[i] = 0;
foo (p, 50);
bar ();
if (p[0] != 10 || p[49] != 20)
__builtin_abort ();
return 0;
}
The problem was that nothing set cfun->calls_alloca flag in the child omp
function and thus the asan code wouldn't add __asan_allocas_unpoison call at
the end of the function. Normally when optimizing, DCE clears those flags and
recomputes them again, so this was only problematic with -O0.
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #8 from Andrew Macleod ---
(In reply to David Binderman from comment #6)
> I get something similar with this test case:
>
> int a;
> void b() {
> if (a >= 2147483647)
> c(a + 1);
> }
This one is slightly different.
Still triggering in the same place, but the difference in the singleton is the
result of the calculation of:
[+INF, +INF] + 1
EVRP is reporting [-INF, -INF], and range-ops is calculating [+INF, +INF]
Is there a correct answer, or does it matter?
The code we imported for handling overflow always sets the bound to +INF if an
overflow happens, and it happens on both bounds, so we get [+INF, +INF]. I'm
guessing because its a single value EVRP actually folded the value regardless
of overflow?
Or maybe it should be UNDEFINED?
Andrew
[Bug tree-optimization/97307] Optimization for pure vs. const function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> The patch will cause
>
> FAIL: gcc.dg/vect/pr65947-3.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
>
> since the testcase has exactly such a pattern:
>
> unsigned int
> condition_reduction (unsigned int *a, unsigned int min_v, unsigned int *b)
> {
> unsigned int last = N + 65;
> unsigned int aval;
>
> for (unsigned int i = 0; i < N; i++)
> {
> aval = a[i];
> if (b[i] < min_v)
> last = aval;
> }
> return last;
> }
>
> and sinking the aval = a[i] load causes if-conversion to no longer happen
> because a[i] now appears to only conditionally trap. It will be vectorized
> with masked loads if those are available though, so I'm considering to
> XFAIL it for the moment.
Isn't that an important real-world case though? I mean, people who care a lot
about the vectorization often change code from the loads in the conditionals to
preloading the value before the condition, such that it can be vectorized and
now it won't (and masked loads are less common among architectures that can
vectorize such loops than non-masked ones).
So shouldn't we just sink that way calls before vectorization and after
vectorization everything? Or have some way to tell ifcvt it can undo the
sinking.
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315 --- Comment #7 from Andrew Macleod --- OK, there are a couple of things at play in this PR. The original problem isn't actually unreachable code. well, sort of. The pass determines something is unreachable and changes the condition, which means it will be unreachable when its done.. but the dom walk will continue. The issue is that this triggers a case where EVRP gets a singleton that we miss, and thats what triggers the stmt rewrite., _2 = add_type_duplicate_type.2_1->base.code; _3 = (int) _2; Theres a chaining of conditions with _3 and _2 : if (_2 == 0) goto ; [INV] : if (_3 != 0) goto ; [66.00%] if (_3 != 1) goto ; [0.04%] else goto ; [99.96%] : if (add_type_duplicate_type.2_1 != 0B) goto ; [INV] : if (_3 != 0) goto ; [66.00%] And at some point (and I know where and why, the cast chain being in a different block than the condition... its on my list) ranger loses track that _3 is actually [0,0], and instead thinks its still [0,1] so EVRP finds the singlton [0,0] and turns vrp visiting stmt if (_3 != 0) Folding statement: if (_3 != 0) into if (0 != 0) Which of course makes some code look unreachable (and it will be when the CFG is updated.) Meanwhile we plug along, and since the ranger is dynamic, that condition now factors into any calculations, and when we get to a later statement, evrp visiting stmt if (_3 != 1) using this new found information, ranger says, aha, I can refine [0,1] for _3, is actually [1,1] on one edge, whereas evrp simply reports the [0,0] it already had. bottom line, its triggered by ranger missing something... I wasn't expecting this to trigger due to shortcomings... I was expecting it to be just bugs. given that, I think I will change this to again, flag the difference like I do with ranges, and use the value produced by whichever pass is going first. That way we wont be stopped by this sort of issue when its really just a shortcoming.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #20 from Andreas Schwab --- Any ICE is a bug.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #19 from kargl at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #18) > Any ICE is a bug. If powerpc64 does not have REAL(16), then you'll need to xfail the test.
[Bug rtl-optimization/97322] New: [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 Bug ID: 97322 Summary: [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Created attachment 49322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49322=edit preprocessed strtof_l.i Since r11-3671 (g:bf510679bb3f9bfd6019666065016bb26a5b5466), I've noticed an ICE while building the toolchains for arm. GCC crashes either while building glibc or newlib. I'm attaching a glibc reproducer: strtof_l.i arm-none-linux-gnueabihf-gcc strtof_l.i -O2 during RTL pass: expand In file included from strtof_l.c:45: strtod_l.c: In function 'strtof_l_internal': strtod_l.c:506:1: internal compiler error: in int_mode_for_mode, at stor-layout.c:404 506 | STRTOF_INTERNAL (const STRING_TYPE *nptr, STRING_TYPE **endptr, int group, | ^ 0xcf0afb int_mode_for_mode(machine_mode) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/stor-layout.c:404 0x92e70e emit_move_via_integer /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:3425 0x93e4fc emit_move_insn_1(rtx_def*, rtx_def*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:3793 0x93e82b emit_move_insn(rtx_def*, rtx_def*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:3935 0x7dc96f emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode, int, std::pair*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/calls.c:5601 0x10d2f34 emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, rtx_def*, machine_mode, rtx_def*, machine_mode) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/rtl.h:4258 0x10d2f34 arm_expand_divmod_libfunc /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/config/arm/arm.c:33280 0xa54846 expand_DIVMOD /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/internal-fn.c:3084 0x800fa7 expand_call_stmt /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:2612 0x800fa7 expand_gimple_stmt_1 /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:3686 0x800fa7 expand_gimple_stmt /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:3851 0x80771b expand_gimple_basic_block /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:5892 0x809e0b execute /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:6576
[Bug rtl-optimization/97322] [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 Christophe Lyon changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |11.0 Target||arm
[Bug tree-optimization/97307] Optimization for pure vs. const function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307 --- Comment #6 from Benjamin B. Meier --- Thanks for the super quick reaction:)!
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #18 from Andreas Schwab --- Any ICE is a bug.
[Bug tree-optimization/97307] Optimization for pure vs. const function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||11.0 Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/97307] Optimization for pure vs. const function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:dae673abd37d400408959497e50fe1f3fbef5533 commit r11-3705-gdae673abd37d400408959497e50fe1f3fbef5533 Author: Richard Biener Date: Wed Oct 7 10:42:12 2020 +0200 tree-optimization/97307 - improve sinking of loads This improves the heuristics finding a sink location for loads that does not cross any store. 2020-10-07 Richard Biener PR tree-optimization/97307 * tree-ssa-sink.c (statement_sink_location): Change heuristic for not skipping stores to look for virtual definitions rather than uses. * gcc.dg/tree-ssa/ssa-sink-17.c: New testcase. * gcc.dg/vect/pr65947-3.c: XFAIL.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #17 from Steve Kargl --- On Wed, Oct 07, 2020 at 07:19:18AM +, sch...@linux-m68k.org wrote: > > --- Comment #16 from Andreas Schwab --- > On powerpc64: > > FAIL: gfortran.dg/pr96711.f90 -O0 (internal compiler error) > FAIL: gfortran.dg/pr96711.f90 -O0 (test for excess errors) > Excess errors: > f951: internal compiler error: Could not find real kind with at least 128 bits > If powerpc64 does not have REAL(16), then you'll need to xfail the test.
[Bug libstdc++/97273] [8/9/10/11 Regression] Strange behaviour of unordered_set when vector is included (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97273 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:592fe221735bdaa375b1834dd49ce125d0b600d8 commit r11-3704-g592fe221735bdaa375b1834dd49ce125d0b600d8 Author: Patrick Palka Date: Wed Oct 7 10:49:00 2020 -0400 c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273] cp_tree_equal currently considers alignof the same as __alignof__, but these operators are semantically different ever since r8-7957. In the testcase below, this causes the second static_assert to fail on targets where alignof(double) != __alignof__(double) because the specialization table (which uses cp_tree_equal as its equality predicate) conflates the two dependent specializations integral_constant<__alignof__(T)> and integral_constant. This patch makes cp_tree_equal distinguish between these two operators by inspecting the ALIGNOF_EXPR_STD_P flag. gcc/cp/ChangeLog: PR c++/88115 PR libstdc++/97273 * tree.c (cp_tree_equal) : Return false if ALIGNOF_EXPR_STD_P differ. gcc/testsuite/ChangeLog: PR c++/88115 PR libstdc++/97273 * g++.dg/template/alignof3.C: New test.
[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:592fe221735bdaa375b1834dd49ce125d0b600d8 commit r11-3704-g592fe221735bdaa375b1834dd49ce125d0b600d8 Author: Patrick Palka Date: Wed Oct 7 10:49:00 2020 -0400 c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273] cp_tree_equal currently considers alignof the same as __alignof__, but these operators are semantically different ever since r8-7957. In the testcase below, this causes the second static_assert to fail on targets where alignof(double) != __alignof__(double) because the specialization table (which uses cp_tree_equal as its equality predicate) conflates the two dependent specializations integral_constant<__alignof__(T)> and integral_constant. This patch makes cp_tree_equal distinguish between these two operators by inspecting the ALIGNOF_EXPR_STD_P flag. gcc/cp/ChangeLog: PR c++/88115 PR libstdc++/97273 * tree.c (cp_tree_equal) : Return false if ALIGNOF_EXPR_STD_P differ. gcc/testsuite/ChangeLog: PR c++/88115 PR libstdc++/97273 * g++.dg/template/alignof3.C: New test.
[Bug tree-optimization/97307] Optimization for pure vs. const function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97307
--- Comment #3 from Richard Biener ---
The patch will cause
FAIL: gcc.dg/vect/pr65947-3.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
since the testcase has exactly such a pattern:
unsigned int
condition_reduction (unsigned int *a, unsigned int min_v, unsigned int *b)
{
unsigned int last = N + 65;
unsigned int aval;
for (unsigned int i = 0; i < N; i++)
{
aval = a[i];
if (b[i] < min_v)
last = aval;
}
return last;
}
and sinking the aval = a[i] load causes if-conversion to no longer happen
because a[i] now appears to only conditionally trap. It will be vectorized
with masked loads if those are available though, so I'm considering to
XFAIL it for the moment.
[Bug preprocessor/93606] -fdirectives-only and raw string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93606 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #1 from Nathan Sidwell --- fixed this b224c3763e0
[Bug c++/95263] [11 Regression] ICE in lookup_template_class_1 since r11-504-g74744bb1f2847b5b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95263 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Nathan Sidwell --- forgot to mark resolved
[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nathan Sidwell --- fixed 4e62aca0e05
[Bug c/97321] add warning for pointer casts that may lead to aliasing violation when dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97321 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Richard Biener --- > gcc t5.c -O2 -Wstrict-aliasing=2 t5.c: In function 'g': t5.c:5:32: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 5 | return f((unsigned char **)); |^~ so it already works.
[Bug c++/31775] static object mangling conflicts with extern object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Nathan Sidwell --- ReFixed 4e62aca0e05 This is DR1839, the original patch was supporting ill-formed code the static mangling is unchanged though
[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 --- Comment #11 from David Malcolm --- (In reply to Mark Wielaard from comment #10) > Created attachment 49293 [details] > supergraph Thanks. Compared to my testing, I'm seeing what appear to be differences in the inputs to the analyzer at the gimple level, which are likely due to differences in the rest of the compiler. Is this with the same version of gcc as in comment #4, where you said "gcc (GCC) 11.0.0 20200916 (experimental)". You don't happen to know exactly which revision, do you? [The md5sum of the bzip2.c I'm using is 23f66348f80345353d5b5b98e299ff15. There could also be differences in the system headers, I suppose]
[Bug c/97321] New: add warning for pointer casts that may lead to aliasing violation when dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97321
Bug ID: 97321
Summary: add warning for pointer casts that may lead to
aliasing violation when dereferenced
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
consider:
int f(unsigned char **);
int g(char *p)
{
return f((unsigned char **));
}
such code is almost surely wrong (if f dereferences its
argument) this is a common mistake and it seems gcc-11
will optimize such code more aggressively which can lead
to broken behavior, see bug 97264.
so it would be useful to simply warn about casts between
pointer types that cannot alias. e.g.:
"warning: dangerous cast from `char **` to `unsigned char **` can lead to
aliasing violation [-Wpointer-cast]"
does not have to be in -Wall, but the current aliasing
warnings are too weak to catch bugs like in the example.
[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47469 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #11 from Paul Thomas --- Fixed after a mere 3542 days. Thanks for the report :-) Paul
[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47469 --- Comment #10 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:7c7e841806aecf4187c69fc2ff07813c7be09582 commit r11-3702-g7c7e841806aecf4187c69fc2ff07813c7be09582 Author: Paul Thomas Date: Wed Oct 7 14:59:10 2020 +0100 This patch fixes PR47469 - a trivial bit of tidying up. 2020-07-10 Paul Thomas gcc/fortran PR fortran/47469 * trans-expr.c (arrayfunc_assign_needs_temporary): Tidy detection of pointer and allocatable functions.
[Bug analyzer/97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110 Bug 97110 depends on bug 97116, which changed state. Bug 97116 Summary: Fix argument numbering in C++ member function calls https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/97116] Fix argument numbering in C++ member function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/97116] Fix argument numbering in C++ member function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97116 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:2f7c50b7091c09d665aaf27173aacf34c9904e4c commit r11-3701-g2f7c50b7091c09d665aaf27173aacf34c9904e4c Author: David Malcolm Date: Tue Oct 6 17:59:07 2020 -0400 analyzer: handle C++ argument numbers and "this" [PR97116] gcc/analyzer/ChangeLog: PR analyzer/97116 * sm-malloc.cc (method_p): New. (describe_argument_index): New. (inform_nonnull_attribute): Use describe_argument_index. (possible_null_arg::describe_final_event): Likewise. (null_arg::describe_final_event): Likewise. gcc/testsuite/ChangeLog: PR analyzer/97116 * g++.dg/analyzer/pr97116.C: New test.
[Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-10-07 --- Comment #1 from Dominique d'Humieres --- The manual says Warn if an array subscript inside a DO loop could lead to an out-of-bounds access even if the compiler cannot prove that the statement is actually executed, in cases like or don't use -Wdo-subscript if there is an IF in the DO block.
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311
--- Comment #2 from Jonathan Wakely ---
Or something like:
auto __b = [__begin, __n](size_t __i) -> _Type& {
return __begin[__i % __n];
};
auto __b32 = [__b](size_t __i) { return (uint32_t)__b(__i); };
for (size_t __k = 0; __k < __m; ++__k)
{
uint32_t __arg = (__b32(__k) ^ __b32(__k + __p) ^ __b32(__k - 1));
uint32_t __r1 = 1664525u * (__arg ^ (__arg >> 27));
uint32_t __r2 = __r1;
if (__k == 0)
__r2 += __s;
else if (__k <= __s)
__r2 += __k % __n + _M_v[__k - 1];
else
__r2 += __k % __n;
__b(__k + __p) = __b32(__k + __p) + __r1;
__b(__k + __q) = __b32(__k + __q) + __r2;
__b(__k) = __r2;
}
for (size_t __k = __m; __k < __m + __n; ++__k)
{
uint32_t __arg = (__b32(__k) + __b32(__k + __p) + __b32(__k - 1));
uint32_t __r3 = (uint32_t)1566083941u * (__arg ^ (__arg >> 27));
uint32_t __r4 = __r3 - __k % __n;
__b(__k + __p) ^= __r3;
__b(__k + __q) ^= __r4;
__b(__k) = __r4;
}
The current code will work even if the implementation only provides
uint_least32_t and not uint32_t, but I don't think we support any targets
without uint32_t. So it could be a lot simpler.
[Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 Bug ID: 97320 Summary: False positive "Array reference out of bounds in loop" in a protecting if block Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- Compiling the following testcase with "gfortran -c -Wdo-subscript do-subscript-test.f90" leads to a bunch of warnings like the following: do-subscript-test.f90:13:26: 7 |i_: do i = 1, 10 | 2 .. 13 |a(i-4) > a(i-5)) & | 1 Warning: Array reference at (1) out of bounds (-4 < 1) in loop beginning at (2) [-Wdo-subscript] Given that all these accesses are in an "if (i > 5)" block, the warnings are false positives and the out-of-bounds accesses cannot really occur. Inspecting the .optimized output confirms this. I can reproduce this using GCC 8 through 10 (GNU Fortran (GCC) 10.2.1 20200827 (Red Hat 10.2.1-3)), with or without -O2. = do-subscript-test.f90 = subroutine do_subscript_test() implicit none integer :: i real :: a(10) i_: do i = 1, 10 if (i > 5) then if (a(i) > a(i-1) .and. & a(i-1) > a(i-2) .and. & a(i-2) > a(i-3) .and. & a(i-3) > a(i-4) .and. & a(i-4) > a(i-5)) & exit i_ end if end do i_ end subroutine
[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97311 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-10-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I wonder why we don't just use uint32_t everywhere instead of those metafunctions. uint32_t __r3 = ...; uint32_t __r4 = ...; // ... __begin[(__k + __p) % __n] = (uint32_t)__begin[(__k + __p) % __n] + __r3; __begin[(__k + __q) % __n] = (uint32_t)__begin[(__k + __q) % __n] + __r4;
[Bug target/97312] [11 regression] aarch64/pr90838.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97312
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2020-10-07
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Aldy Hernandez ---
Confirmed.
This test is checking the final assembly for a specific sequence. I don't
speak aarch64 assembly, but the IL is different coming out of evrp.
The first culprit is this difference in the mergephi1 dump:
_9 = .CTZ (x_6(D));
- _10 = _9 & 31;
+ _10 = _9;
These are unsigned ints, so assuming they are 32 bits on aarch64, __builtin_ctz
is always less than 32. This is because a CTZ of 0 is undefined according to
the GCC manual:
Built-in Function: int __builtin_ctz (unsigned int x)
Returns the number of trailing 0-bits in x, starting at the least
significant bit position. If x is 0, the result is undefined.
So a bitwise AND of anything less than 32 with 0x1f (31) is a no-op.
Are aarch64 int's 32-bits?
Here are the full IL differences:
--- legacy-evrp/pr90838.c.038t.mergephi12020-10-07 08:44:12.152358885
-0400
+++ ranger/pr90838.c.038t.mergephi1 2020-10-07 08:39:12.339296502 -0400
@@ -1,41 +1,41 @@
;; Function ctz1 (ctz1, funcdef_no=0, decl_uid=3587, cgraph_uid=1,
symbol_order=0)
ctz1 (unsigned int x)
{
static const char table[32] =
"\x00\x01\x1c\x02\x1d\x0e\x18\x03\x1e\x16\x14\x0f\x19\x11\x04\b\x1f\x1b\r\x17\x15\x13\x10\x07\x1a\f\x12\x06\v\x05\n\t";
unsigned int _1;
unsigned int _2;
unsigned int _3;
unsigned int _4;
char _5;
int _9;
int _10;
:
_1 = -x_6(D);
_2 = _1 & x_6(D);
_3 = _2 * 125613361;
_4 = _3 >> 27;
_9 = .CTZ (x_6(D));
- _10 = _9 & 31;
+ _10 = _9;
_5 = (char) _10;
return _10;
}
;; Function ctz2 (ctz2, funcdef_no=1, decl_uid=3591, cgraph_uid=2,
symbol_order=1)
ctz2 (unsigned int x)
{
static short int table[64] = {32, 0, 1, 12, 2, 6, 0, 13, 3, 0, 7, 0, 0, 0,
0, 14, 10, 4, 0, 0, 8, 0, 0, 25, 0, 0, 0, 0, 0, 21, 27, 15, 31, 11, 5, 0, 0, 0,
0, 0, 9, 0, 0,
24, 0, 0, 20, 26, 30, 0, 0, 0, 0, 23, 0, 19, 29, 0, 22, 18, 28, 17, 16, 0};
unsigned int _1;
unsigned int _2;
unsigned int _3;
short int _4;
int _8;
:
_1 = -x_5(D);
@@ -87,27 +87,27 @@
;; Function ctz4 (ctz4, funcdef_no=3, decl_uid=3601, cgraph_uid=4,
symbol_order=5)
ctz4 (long unsigned int x)
{
long unsigned int lsb;
long unsigned int _1;
long long unsigned int _2;
long long unsigned int _3;
char _4;
int _9;
int _10;
:
_1 = -x_5(D);
lsb_6 = _1 & x_5(D);
_2 = lsb_6 * 283881067100198605;
_3 = _2 >> 58;
_9 = .CTZ (x_5(D));
- _10 = _9 & 63;
+ _10 = _9;
_4 = (char) _10;
return _10;
}
The difference in assembly matches. We have 2 less AND's in the final output:
$ diff -u legacy.s ranger.s
--- legacy.s2020-10-07 09:06:13.420446783 -0400
+++ ranger.s2020-10-07 09:06:42.646646949 -0400
@@ -8,7 +8,6 @@
ctz1:
rbitw0, w0
clz w0, w0
- and w0, w0, 31
ret
.size ctz1, .-ctz1
.align 2
@@ -36,7 +35,6 @@
ctz4:
rbitx0, x0
clz x0, x0
- and w0, w0, 63
ret
.size ctz4, .-ctz4
If my analysis is correct, someone aarch64 savvy should adjust this:
/* { dg-final { scan-assembler-times "and\t" 2 } } */
[Bug bootstrap/97319] LTO profiledbootstrap (C/C++/Fotran only) fails with a segfault in selftest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97319 Martin Liška changed: What|Removed |Added Known to fail||11.0 CC||marxin at gcc dot gnu.org Target Milestone|--- |11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||10.2.0 Priority|P3 |P1 Last reconfirmed||2020-10-07
[Bug bootstrap/97319] New: LTO profiledbootstrap (C/C++/Fotran only) fails with a segfault in selftest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97319 Bug ID: 97319 Summary: LTO profiledbootstrap (C/C++/Fotran only) fails with a segfault in selftest Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: x86_64-linux Since Honza's commit c33f4742393, attempting to LTO-profiledbootstrap GCC, even when Ada is not enabled, fails in stageprofile with: /home/mjambor/gcc/mine/b-obj/./gcc/xgcc -B/home/mjambor/gcc/mine/b-obj/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/home/mjambor/gcc/mine/src/gcc/testsuite/selftests In function ‘test_fn’: cc1: internal compiler error: Segmentation fault 0x1770669 crash_signal /home/mjambor/gcc/mine/src/gcc/toplev.c:329 0xd86637 purge_dead_edges(basic_block_def*) /home/mjambor/gcc/mine/src/gcc/cfgrtl.c:3271 0x261dd78 find_bb_boundaries /home/mjambor/gcc/mine/src/gcc/cfgbuild.c:589 0x261f76f find_many_sub_basic_blocks(simple_bitmap_def*) /home/mjambor/gcc/mine/src/gcc/cfgbuild.c:672 0xd94a1a execute /home/mjambor/gcc/mine/src/gcc/cfgexpand.c:6675 0x26dd277 test_expansion_to_rtl /home/mjambor/gcc/mine/src/gcc/function-tests.c:609 0x26ddaad selftest::function_tests_c_tests() /home/mjambor/gcc/mine/src/gcc/function-tests.c:691 0x295bd86 selftest::run_tests() /home/mjambor/gcc/mine/src/gcc/selftest-run-tests.c:109 0x1774302 toplev::run_self_tests() /home/mjambor/gcc/mine/src/gcc/toplev.c:2381
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #17 from Richard Biener --- Same for #define VECT_SCALAR_BOOLEAN_TYPE_P(TYPE) \ - (INTEGRAL_TYPE_P (TYPE) \ - && TYPE_PRECISION (TYPE) == 1) + ((TREE_CODE (TYPE) == BOOLEAN_TYPE \ +&& TYPE_PRECISION (TYPE) == 1) \ + || ((TREE_CODE (TYPE) == INTEGER_TYPE \ + || TREE_CODE (TYPE) == ENUMERAL_TYPE) \ + && TYPE_PRECISION (TYPE) == 1 \ + && TYPE_UNSIGNED (TYPE))) so we do need to understand the Ada failure instead for which again I'm hoping for a (LTO) testcase. I'm not too familiar with the vector boolean pattern stuff so I'm not the appropriate person to dig into this. At least it seems this VECT_SCALAR_BOOLEAN_TYPE_P predicate is very much fragile.
[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #21 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:e089e43365f7f2a90979e2316aea25d44823f5a3 commit r11-3698-ge089e43365f7f2a90979e2316aea25d44823f5a3 Author: Martin Jambor Date: Wed Oct 7 14:12:49 2020 +0200 ipa-prop: Fix multiple-target speculation resolution As the FIXME which this patch removes states, the current code does not work when a call with multiple speculative targets gets resolved through parameter tracking during inlining - it feeds the inliner an edge it has already dealt with. The patch makes the code which should prevent it aware of the possibility that that speculation can have more than one target now. gcc/ChangeLog: 2020-09-30 Martin Jambor PR ipa/96394 * ipa-prop.c (update_indirect_edges_after_inlining): Do not add resolved speculation edges to vector of new direct edges even in presence of multiple speculative direct edges for a single call. gcc/testsuite/ChangeLog: 2020-09-30 Martin Jambor PR ipa/96394 * gcc.dg/tree-prof/pr96394.c: New test.
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #6 from David Binderman ---
I get something similar with this test case:
int a;
void b() {
if (a >= 2147483647)
c(a + 1);
}
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 --- Comment #2 from Aldy Hernandez --- operator_cast::op1_range() is creating a range with swapped operands here: // And union this with the entire outer types negative range. int_range_max neg (type, wi::min_value (TYPE_PRECISION (type), SIGNED), lim - 1); (gdb) ptg type (gdb) dd wmin [0x], precision = 17 (gdb) dd wmax [0x], precision = 17 This is an unsigned bit field, which I can never get right. Andrew, should we be creating a min in SIGNED precision here?
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315 --- Comment #5 from Richard Biener --- (In reply to Richard Biener from comment #4) > EVRP knows to "skip" unreachable edges. Not sure how you even "ask" EVRP > for values in unreachable blocks? It's lattice does never reflect its state? Also the substitute-and-fold stage avoided to even look at unreachable regions (for compile-time reasons and to avoid using "inconsistent" state)
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315 --- Comment #4 from Richard Biener --- EVRP knows to "skip" unreachable edges. Not sure how you even "ask" EVRP for values in unreachable blocks? It's lattice does never reflect its state?
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #3 from Aldy Hernandez ---
(In reply to Alex Coplan from comment #1)
> Seeing a similar ICE with the following simple C testcase:
>
> int a;
> int b(signed char c, int d) { return c < 0 ? 0 : c >> d; }
> void e(void)
> {
> for (int i = 0; i <= 0; i++)
> while (a)
> b(-(i != 1), i);
> }
>
> $ aarch64-elf-gcc -O2 test.c
evrp and ranger disagree on the singleton for i_6.
(gdb) ptg ranger_val
1
(gdb) ptg evrp_val
0
(gdb) ptgs stmt
iftmp.0_13 = _12 >> i_6;
This is the same issue. stmt is in BB4, which is unreachable.
[Bug lto/97290] Segmentation fault in lto-wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97290 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Known to work||10.2.1 Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Liška --- Fixed on GCC 10 branch with g:136256c32db63600168516e562441f73c26a187a. Closing now.
[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550 --- Comment #9 from Vittorio Zecca --- Intel ifort and ifx accept the test case without errors. They both accept pointer pi integer :: pi=>null() and integer :: pi=>null() pointer pi Anyway, it's easy to transfom it into integer, pointer :: pi=>null() which is accepted by gfortran. Evidently ifx and ifort have a different approach to symbol table and compilation passes.
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #2 from Aldy Hernandez ---
evrp and ranger disagree on the singleton range for _3 in the following stmt:
:
if (_3 != 1)
(gdb) ptg evrp_ret
0
(gdb) ptg ranger_ret
1
Which is interesting because BB5 is actually unreachable:
add_type_duplicate ()
{
struct tree_node * D.2384;
struct tree_node * add_type_duplicate_type.2_1;
short unsigned int _2;
int _3;
tree_code_class _4;
:
add_type_duplicate_type.2_1 = add_type_duplicate_type;
_2 = add_type_duplicate_type.2_1->base.code;
_3 = (int) _2;
_4 = tree_code_type[_3];
if (_4 != 0)
goto ; [INV]
else
goto ; [INV]
:
if (_2 == 0)
goto ; [INV]
else
goto ; [INV]
:
if (0 != 0)
goto ; [66.00%]
else
goto ; [34.00%]
:
goto ; [100.00%]
:
if (_3 != 1)
goto ; [0.04%]
else
goto ; [99.96%]
:
goto ; [100.00%]
:
tree_check_failed ();
:
:
:
if (0 != 0)
goto ; [66.00%]
else
goto ; [34.00%]
:
if (1 != 0)
goto ; [0.04%]
else
goto ; [99.96%]
:
tree_check_failed ();
:
if (1 != 0)
goto ; [INV]
else
goto ; [INV]
:
return;
}
I'm guessing evrp
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 --- Comment #16 from Richard Biener --- (In reply to Richard Biener from comment #15) > The patch causes g++.dg/vect/simd-bool-comparison-1.cc to FAIL because > it will result in signed BOOLEAN_TYPEs with precision 1 rejected. Those we > use for build_nonstandard_boolean_type via > > #0 0x01b93458 in build_truth_vector_type_for_mode (nunits=..., > mask_mode=E_DImode) at /home/rguenther/src/gcc3/gcc/tree.c:10931 > #1 0x01b935a2 in build_truth_vector_type_for (vectype= 0x769c0bd0>) at /home/rguenther/src/gcc3/gcc/tree.c:10949 > #2 0x01b96175 in truth_type_for (type=) > at /home/rguenther/src/gcc3/gcc/tree.c:11764 > #3 0x01ae92b6 in get_mask_type_for_scalar_type (vinfo=0x3beccd0, > scalar_type=, group_size=0) > at /home/rguenther/src/gcc3/gcc/tree-vect-stmts.c:11137 > #4 0x028cfaee in vect_recog_mask_conversion_pattern > (vinfo=0x3beccd0, stmt_vinfo=0x3da6ae0, type_out=0x7fffc320) > at /home/rguenther/src/gcc3/gcc/tree-vect-patterns.c:4354 > > which then causes the VECT_SCALAR_BOOLEAN_TYPE_P result to differ even for > C++ > at > > #1 0x01abfa11 in VECT_SCALAR_BOOLEAN_TYPE_P (TYPE= 0x769c01f8>) at /home/rguenther/src/gcc3/gcc/tree-vectorizer.h:1425 > #2 0x01ae41c1 in vect_is_simple_cond (cond= 22>, vinfo=0x3beccd0, stmt_info=0x3da7410, slp_node=0x0, > comp_vectype=0x7fffbbe0, dts=0x7fffbbb0, vectype= 0x768f7150>) at /home/rguenther/src/gcc3/gcc/tree-vect-stmts.c:9711 > #3 0x01ae49bf in vectorizable_condition (vinfo=0x3beccd0, > stmt_info=0x3da7410, gsi=0x0, vec_stmt=0x0, slp_node=0x0, > cost_vec=0x7fffc1b8) > at /home/rguenther/src/gcc3/gcc/tree-vect-stmts.c:9876 > > now the Ada issue was about non-1 precision BOOLEAN_TYPE, so we could narrow > down the fix. But then the question is why we allow signed 1-bit bools > but not signed 1-bit integers... > > So I'm first re-testing > > #define VECT_SCALAR_BOOLEAN_TYPE_P(TYPE) \ > - (TREE_CODE (TYPE) == BOOLEAN_TYPE\ > - || ((TREE_CODE (TYPE) == INTEGER_TYPE \ > - || TREE_CODE (TYPE) == ENUMERAL_TYPE) \ > - && TYPE_PRECISION (TYPE) == 1 \ > - && TYPE_UNSIGNED (TYPE))) > + (INTEGRAL_TYPE_P (TYPE) \ > + && TYPE_PRECISION (TYPE) == 1) FAIL: gcc.dg/vect/vect-cond-reduc-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "LOOP VECTORIZED" 2 FAIL: gcc.dg/vect/vect-cond-reduc-4.c scan-tree-dump-times vect "LOOP VECTORIZED" 2 FAIL: gcc.target/i386/avx512vl-pr88464-1.c scan-tree-dump-times vect "loop vectorized using 32 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-1.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/avx512vl-pr88464-11.c scan-tree-dump-times vect "loop vectorized using 16 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-11.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/avx512vl-pr88464-13.c scan-tree-dump-times vect "loop vectorized using 32 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-13.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/avx512vl-pr88464-15.c scan-tree-dump-times vect "loop vectorized using 16 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-15.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/avx512vl-pr88464-3.c scan-tree-dump-times vect "loop vectorized using 16 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-3.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/avx512vl-pr88464-5.c scan-tree-dump-times vect "loop vectorized using 32 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-5.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/avx512vl-pr88464-7.c scan-tree-dump-times vect "loop vectorized using 16 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-7.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/avx512vl-pr88464-9.c scan-tree-dump-times vect "loop vectorized using 32 byte vectors" 4 FAIL: gcc.target/i386/avx512vl-pr88464-9.c scan-tree-dump-times vect "vectorized 1 loops in function" 4 FAIL: gcc.target/i386/pr87007-4.c scan-assembler-times vxorps[^\\n\\r]*xmm[0-9] 0 FAIL: gcc.target/i386/pr87007-5.c scan-assembler-times vxorps[^\\n\\r]*xmm[0-9] 0 FAIL: gcc.target/i386/vectorize10.c scan-tree-dump vect "vectorized 1 loops"
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2016 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #5 from Richard Biener --- It also reproduces on Haswell x86_64 (czery).
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-07 CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Priority|P3 |P1 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed on x86_64-linux-gnu target as well.
[Bug target/97318] New: [nvptx] Function splitting results in invalid function name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97318 Bug ID: 97318 Summary: [nvptx] Function splitting results in invalid function name Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Created attachment 49321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49321=edit openmp test-case While minimizing PR97203 - I ran into: ... FAIL: libgomp.c/test.c (test for excess errors) Excess errors: ptxas /tmp/ccTfIxsQ.o, line 23; fatal : Parsing error near '.part': syntax error ptxas fatal : Ptx assembly aborted due to errors nvptx-as: ptxas returned 255 exit status ... The problem is that this: ... .func (.param .f32 %value_out) sinf.part.0 (.param .f32 %in_ar0); ... is not supported by nvptx (as indicated by NO_DOT_IN_LABEL).
[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317 Alex Coplan changed: What|Removed |Added Build||x86_64-linux-gnu Target Milestone|--- |11.0 Keywords||ice-on-valid-code Known to fail||11.0 Host||x86_64-linux-gnu Target||aarch64-elf
[Bug tree-optimization/97317] New: [11 Regression] ICE in verify_range, at value-range.cc:369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97317
Bug ID: 97317
Summary: [11 Regression] ICE in verify_range, at
value-range.cc:369
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
struct a {
unsigned c : 17;
};
struct a b;
int d(void) {
short e = b.c;
return e ? 0 : b.c;
}
AArch64 GCC ICEs at -O2 with:
during GIMPLE pass: evrp
test.c: In function 'd':
test.c:8:1: internal compiler error: in verify_range, at value-range.cc:369
8 | }
| ^
0x1126f4a irange::verify_range()
/home/alecop01/toolchain/src/gcc/gcc/value-range.cc:369
0x1127050 irange::irange_set(tree_node*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/value-range.cc:172
0x1127ef5 irange::set(tree_node*, tree_node*, value_range_kind)
/home/alecop01/toolchain/src/gcc/gcc/value-range.cc:226
0x19ec5cd operator_cast::op1_range(irange&, tree_node*, irange const&, irange
const&) const
/home/alecop01/toolchain/src/gcc/gcc/range-op.cc:1847
0x1a85dc7 gimple_range_calc_op1(irange&, gimple const*, irange const&, irange
const&)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:333
0x1a9563a gori_compute::compute_name_range_op(irange&, gimple*, irange const&,
tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-gori.cc:490
0x1a9886a gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-gori.cc:590
0x1a990b3 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-gori.cc:1276
0x1a95d23 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-gori.cc:903
0x1a989bc gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-gori.cc:602
0x1a990b3 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-gori.cc:1276
0x1a9614a gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-gori.cc:1001
0x1a90b9e ranger_cache::iterative_cache_update(tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-cache.cc:636
0x1a91933 ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-cache.cc:808
0x1a91dab ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-cache.cc:589
0x1a84f0c gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:875
0x1a89634 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:846
0x1a8dba1 gimple_ranger::range_of_range_op(irange&, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:418
0x1a8ddb6 gimple_ranger::calc_stmt(irange&, gimple*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:369
0x1a8e70d gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:952
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/97295] ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97295 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #5 from Martin Liška --- So it's pretty clear what happens, it's about mixing of different flags: TestFloatingPoint.o: '-fno-openmp' '-fno-openacc' '-mtune=generic' '-march=x86-64' '-O3' '-O0' '-Wno-error=maybe-uninitialized' '-Wno-error=deprecated-declarations' '-Wno-error=array-bounds' '-Wno-error=coverage-mismatch' '-Wno-error=free-nonheap-object' '-Wno-error=class-memaccess' '-Wno-error=deprecated-copy' '-Wno-error=shadow' '-flto' '-flifetime-dse=1' '-fstack-protector-strong' '-fPIC' '-fno-strict-aliasing' '-ffunction-sections' '-fdata-sections' '-fno-exceptions' '-fno-math-errno' '-fomit-frame-pointer' '-funwind-tables' while Unified_cpp_mfbt0.o: '-fno-openmp' '-fno-openacc' '-mtune=generic' '-march=x86-64' '-O3' '-Wno-error=maybe-uninitialized' '-Wno-error=deprecated-declarations' '-Wno-error=array-bounds' '-Wno-error=coverage-mismatch' '-Wno-error=free-nonheap-object' '-Wno-error=class-memaccess' '-Wno-error=deprecated-copy' '-flto' '-flifetime-dse=1' '-fstack-protector-strong' '-fPIC' '-fno-strict-aliasing' '-ffunction-sections' '-fdata-sections' '-fno-exceptions' '-fno-math-errno' '-fomit-frame-pointer' '-funwind-tables' '-fprofile-use' '-fprofile-correction' the profiles are merged in ipa_merge_profiles where match=false due to a different CFG and we forget to drop back dst->count. I'll prepare a patch for it.
[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment #1 from Alex Coplan ---
Seeing a similar ICE with the following simple C testcase:
int a;
int b(signed char c, int d) { return c < 0 ? 0 : c >> d; }
void e(void)
{
for (int i = 0; i <= 0; i++)
while (a)
b(-(i != 1), i);
}
$ aarch64-elf-gcc -O2 test.c
during GIMPLE pass: evrp
test.c: In function 'e':
test.c:8:1: internal compiler error: in choose_value, at gimple-ssa-evrp.c:282
8 | }
| ^
0x18d93f0 hybrid_folder::choose_value(tree_node*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-ssa-evrp.c:282
0x18d94e4 hybrid_folder::value_of_expr(tree_node*, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-ssa-evrp.c:236
0xf8e112 substitute_and_fold_engine::replace_uses_in(gimple*)
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-propagate.c:871
0xf8e912 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-propagate.c:1141
0x18a5d5b dom_walker::walk(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/domwalk.c:309
0xf8f885 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-propagate.c:1283
0x18d9828 execute_early_vrp
/home/alecop01/toolchain/src/gcc/gcc/gimple-ssa-evrp.c:328
0x18d9bf8 execute
/home/alecop01/toolchain/src/gcc/gcc/gimple-ssa-evrp.c:375
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 --- Comment #15 from Richard Biener --- The patch causes g++.dg/vect/simd-bool-comparison-1.cc to FAIL because it will result in signed BOOLEAN_TYPEs with precision 1 rejected. Those we use for build_nonstandard_boolean_type via #0 0x01b93458 in build_truth_vector_type_for_mode (nunits=..., mask_mode=E_DImode) at /home/rguenther/src/gcc3/gcc/tree.c:10931 #1 0x01b935a2 in build_truth_vector_type_for (vectype=) at /home/rguenther/src/gcc3/gcc/tree.c:10949 #2 0x01b96175 in truth_type_for (type=) at /home/rguenther/src/gcc3/gcc/tree.c:11764 #3 0x01ae92b6 in get_mask_type_for_scalar_type (vinfo=0x3beccd0, scalar_type=, group_size=0) at /home/rguenther/src/gcc3/gcc/tree-vect-stmts.c:11137 #4 0x028cfaee in vect_recog_mask_conversion_pattern (vinfo=0x3beccd0, stmt_vinfo=0x3da6ae0, type_out=0x7fffc320) at /home/rguenther/src/gcc3/gcc/tree-vect-patterns.c:4354 which then causes the VECT_SCALAR_BOOLEAN_TYPE_P result to differ even for C++ at #1 0x01abfa11 in VECT_SCALAR_BOOLEAN_TYPE_P (TYPE=) at /home/rguenther/src/gcc3/gcc/tree-vectorizer.h:1425 #2 0x01ae41c1 in vect_is_simple_cond (cond=, vinfo=0x3beccd0, stmt_info=0x3da7410, slp_node=0x0, comp_vectype=0x7fffbbe0, dts=0x7fffbbb0, vectype=) at /home/rguenther/src/gcc3/gcc/tree-vect-stmts.c:9711 #3 0x01ae49bf in vectorizable_condition (vinfo=0x3beccd0, stmt_info=0x3da7410, gsi=0x0, vec_stmt=0x0, slp_node=0x0, cost_vec=0x7fffc1b8) at /home/rguenther/src/gcc3/gcc/tree-vect-stmts.c:9876 now the Ada issue was about non-1 precision BOOLEAN_TYPE, so we could narrow down the fix. But then the question is why we allow signed 1-bit bools but not signed 1-bit integers... So I'm first re-testing #define VECT_SCALAR_BOOLEAN_TYPE_P(TYPE) \ - (TREE_CODE (TYPE) == BOOLEAN_TYPE\ - || ((TREE_CODE (TYPE) == INTEGER_TYPE \ - || TREE_CODE (TYPE) == ENUMERAL_TYPE) \ - && TYPE_PRECISION (TYPE) == 1 \ - && TYPE_UNSIGNED (TYPE))) + (INTEGRAL_TYPE_P (TYPE) \ + && TYPE_PRECISION (TYPE) == 1)
[Bug bootstrap/97305] options-save.c:8526:26: error: unused variable 'mask'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97305 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Should be fixed now.
[Bug libgcc/97316] New: config/libbid/bid64_noncomp.c: 7 * pointless test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97316
Bug ID: 97316
Summary: config/libbid/bid64_noncomp.c: 7 * pointless test ?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
1.
trunk.git/libgcc/config/libbid/bid64_noncomp.c:91:39: style: Mismatching
assignment and comparison, comparison 'sig_x==0' is always false.
[assignIfError]
The source code is
sig_x = (x & MASK_BINARY_SIG2) | MASK_BINARY_OR2;
// check for zero or non-canonical
if (sig_x > ull || sig_x == 0) {
but
$ fgrep MASK_BINARY_OR2 `find trunk.git/libgcc/config/libbid -name \*.h -print`
trunk.git/libgcc/config/libbid/bid_internal.h:#define MASK_BINARY_OR2
0x0020ull
$
so the test for sig_x == 0 does look pointless to me.
Some duplicates in the same file:
trunk.git/libgcc/config/libbid/bid64_noncomp.c:143:39: style: Mismatching
assignment and comparison, comparison 'sig_x==0' is always false.
[assignIfError]
trunk.git/libgcc/config/libbid/bid64_noncomp.c:391:37: style: Mismatching
assignment and comparison, comparison 'sig_x==0' is always false.
[assignIfError]
trunk.git/libgcc/config/libbid/bid64_noncomp.c:614:37: style: Mismatching
assignment and comparison, comparison 'sig_x==0' is always false.
[assignIfError]
trunk.git/libgcc/config/libbid/bid64_noncomp.c:629:37: style: Mismatching
assignment and comparison, comparison 'sig_y==0' is always false.
[assignIfError]
trunk.git/libgcc/config/libbid/bid64_noncomp.c:836:37: style: Mismatching
assignment and comparison, comparison 'sig_x==0' is always false.
[assignIfError]
trunk.git/libgcc/config/libbid/bid64_noncomp.c:852:37: style: Mismatching
assignment and comparison, comparison 'sig_y==0' is always false.
[assignIfError]
