[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147 --- Comment #3 from rguenther at suse dot de --- On Tue, 5 Apr 2022, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147 > > Segher Boessenkool changed: > >What|Removed |Added > > Status|WAITING |NEW > > --- Comment #2 from Segher Boessenkool --- > This is an error from 2005 (g:4d3e6fae4dd3, r96124). It is generic code that > makes this an error (instead of a warning), not the rs6000 backend, which just > provides the string (via the invalid_arg_for_unprototyped_fn hook). > > s390 has this exact same error btw. I see. So please add an appropriate dg-skip
[Bug target/105002] [12 regression] gcc.target/powerpc/float128-minmax-3.c fails starting with r12-7687-g3a7ba8fd0cda38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Kewen Lin --- Should be fixed on latest trunk.
[Bug target/105002] [12 regression] gcc.target/powerpc/float128-minmax-3.c fails starting with r12-7687-g3a7ba8fd0cda38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002 --- Comment #6 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:83b43c74bbbdc6b6903350b220b932c6f774bdfd commit r12-8010-g83b43c74bbbdc6b6903350b220b932c6f774bdfd Author: Kewen Lin Date: Tue Apr 5 22:18:30 2022 -0500 rs6000: Support UN[GL][ET] in rs6000_maybe_emit_maxc_minc [PR105002] Commit r12-7687 exposed one miss optimization chance in function rs6000_maybe_emit_maxc_minc, for now it only considers comparison codes GE/GT/LE/LT, but it can support more variants with codes UNLT/UNLE/UNGT/UNGE by reversing them into the equivalent ones with GE/GT/LE/LT. gcc/ChangeLog: PR target/105002 * config/rs6000/rs6000.cc (rs6000_maybe_emit_maxc_minc): Support more comparison codes UNLT/UNLE/UNGT/UNGE.
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Andrew Pinski --- > So that I can decide whether I am allowed to do things totally randomly > or if I must follow some sort of seeded determinism. That is almost always the wrong approach really. Just assume the seed it always set and then use the seed as given. Don't ever do something non-determinstic if you can avoid it. GCC has changed away from that years ago. The randomness in GCC is only needed to get unique symbol names across two translation units which might have the same file name. The seed is there so you can set it to get the same symbol across builds if you know if the file names are unique in the first place. The coverage.cc is a non-issue as libgcov will do the right thing as mentioned.
[Bug target/105172] RV64: gcc generates R_RISCV_ALIGN with a non-power-of-two value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172 --- Comment #1 from Andrew Pinski --- Are you sure this is not an assembler bug which then you should report to binutils.
[Bug c++/105174] New: [Concepts] Example from temp.func.order-p6 selects wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105174 Bug ID: 105174 Summary: [Concepts] Example from temp.func.order-p6 selects wrong overload Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roi.jacobson1 at gmail dot com Target Milestone: --- This example from the standard: https://timsong-cpp.github.io/cppwp/temp.func.order#example-6 fails to compile with GCC (all versions >= 10), because the wrong overload is selected for operator==. I _think_ the problem might be that the permutation on the template arguments between the specializations prevents GCC from recognizing the second is more constrained, but I'm not too sure.
[Bug lto/105133] lto/gold: lto failed to link --start-lib/--end-lib in gold for duplicate libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105133 --- Comment #2 from luoxhu at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > (In reply to luoxhu from comment #0) > > > > cat hellow.res > > 3 > > hello.o 2 > > 192 ccb9165e03755470 PREVAILING_DEF main > > 197 ccb9165e03755470 PREVAILING_DEF_IRONLY s > > ./B/libhello.c.o 1 > > 205 68e0b97e93a52d7a PREEMPTED_REG hello > > ./C/libhello.c.o 1 > > 205 18fe2d3482bfb511 PREEMPTED_REG hello > > This looks like a gold bug - we have 'hello' pre-empted twice but no > prevailing > symbol in the IR - are you ending up with fat LTO objects? It is not fat LTO objects since I didn't add -ffat-lto-objects when generating lib: nm libhello.a libhello.c.o: nm: libhello.c.o: plugin needed to handle lto object 0001 C __gnu_lto_slim > > OTOH PREEMPTED_REG seems then handled wrongly by LTO as well - it should > throw away both copies since the linker told us it found a preempting > definition in a non-IR object file. So I'd expect a unresolved reference > to 'hello' rather than LTO complaining about multiple definitions ... Will you fix it? :) > > Note gold is really unmaintained, so you should probably avoid using it. Thanks. Will try lld instead.
[Bug tree-optimization/105173] New: [10/11/12 Regression] ICE: during GIMPLE pass: reassoc: verify_ssa failed (definition in block 2 follows the use) at -Ofast with decimals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105173
Bug ID: 105173
Summary: [10/11/12 Regression] ICE: during GIMPLE pass:
reassoc: verify_ssa failed (definition in block 2
follows the use) at -Ofast with decimals
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-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 52758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52758=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -Ofast testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: error: definition in block 2 follows the use
4 | foo(char c, _Decimal32 d) {
| ^~~
for SSA_NAME: _12 in statement:
_14 = _12 * -1.0e+0;
during GIMPLE pass: reassoc
testcase.c:4:1: internal compiler error: verify_ssa failed
0x15cee2b verify_ssa(bool, bool)
/repo/gcc-trunk/gcc/tree-ssa.cc:1211
0x1286b7d execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2092
0x1286fae execute_todo
/repo/gcc-trunk/gcc/passes.cc:2139
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ 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-r12-7994-20220405095446-ge68f5c90bae-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/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-r12-7994-20220405095446-ge68f5c90bae-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220405 (experimental) (GCC)
[Bug c/105172] New: RV64: gcc generates R_RISCV_ALIGN with a non-power-of-two value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172 Bug ID: 105172 Summary: RV64: gcc generates R_RISCV_ALIGN with a non-power-of-two value Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- It is reported against the mold linker (https://github.com/rui314/mold/issues/419), but I believe it's GCC"s bug. It looks like GCC sometimes create a R_RISCV_ALIGN relocation with a non-power-of-two requirement alignment, as you can see in the above bug report. That simply doesn't make sense and strongly suggests that something is not working as intended in GCC. I believe all R_RISV_ALIGN relocations have a power-of-two value.
[Bug c++/104461] cody requires -fmodule-mapper hostname to have an IPv6 address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104461 Xi Ruoyao changed: What|Removed |Added CC||jwakely.gcc at gmail dot com, ||xry111 at mengyan1223 dot wang --- Comment #1 from Xi Ruoyao --- It's because the paper (https://wg21.link/p1184) explicitly says "an ipv6 domain socket & port", I think. It's not clear if AI_V4MAPPED addresses are allowed. The problem is there is no "elegent" way for a distro maintainer to ensure an IPv6 address for localhost is available on Linux/GNU. If /etc/nsswitch.conf contains hosts: files dns (this is the default of Glibc and used by many distros), and /etc/hosts contains 127.0.0.1 localhost ::1 localhost By default Glibc will ignore "::1" for localhost, unless "multi on" is specified in /etc/host.conf. But Glibc doc explicitly says it may cause a performance issue (see man host.conf). On systems using systemd, the distro can specify nss_myhostname in /etc/nsswitch.conf, but it does not exist on non-systemd distros.
[Bug libstdc++/102301] make_from_tuple can not work with subrange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102301 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #8 from Jiang An --- I've submitted an LWG issue for this. BTW, it's unfortunate that the standard library has both tuple-like and variant-like std::get overloads, and they are not clearly distinguished in the specification...
[Bug c/105134] tree-vectorize produces error code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134 --- Comment #6 from piliu at redhat dot com --- Created attachment 52757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52757=edit precompiled code of sha256 compile command: gcc -E -fno-zero-initialized-in-bss -mcmodel=large -Os -fno-builtin -ffreestanding -fno-zero-initialized-in-bss -fno-PIC -fno-PIE -fno-stack-protector -O2 -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/usr/lib/gcc/x86_64-redhat-linux/12/include -c -o purgatory/sha256.o util_lib/sha256.c
[Bug c/105134] tree-vectorize produces error code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134 --- Comment #5 from piliu at redhat dot com --- Created attachment 52756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52756=edit -ftree-vectorize can not produce correct code for kexec-tools
[Bug c/105134] tree-vectorize produces error code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134 --- Comment #4 from piliu at redhat dot com --- (In reply to Richard Biener from comment #3) > Can you provide preprocessed source of the TU containing sha256_starts and > the full compiler command-line used to compile it? For a single file. gcc -fno-zero-initialized-in-bss -mcmodel=large -Os -fno-builtin -ffreestanding -fno-zero-initialized-in-bss -fno-PIC -fno-PIE -fno-stack-protector -O2 -mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude -I/usr/lib/gcc/x86_64-redhat-linux/12/include -c -o purgatory/sha256.o util_lib/sha256.c For the complete compile log, please see the attachment.
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #4 from Jason A. Donenfeld --- (In reply to Andrew Pinski from comment #2) > >local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000; > > The only place where local_tick is used is inside coverage.cc: > if (!flag_branch_probabilities && flag_test_coverage > && (!local_tick || local_tick == (unsigned)-1)) > /* Only remove the da file, if we're emitting coverage code and >cannot uniquely stamp it. If we can stamp it, libgcov will DTRT. */ > unlink (da_file_name); > > > This does not make a difference really here. Really? Looks to me like the behavior changes. If it doesn't make a difference, then remove that part of the condition clause? If you object to doing that, then the overflow seems like an issue. > Plus inside a plugin, I don't see why you care about if -frandom-seed was > supplied or not. So that I can decide whether I am allowed to do things totally randomly or if I must follow some sort of seeded determinism. The broader answer is of course, "because plugins can do many things." > You mean toplev.cc right? I guess I'm reading gcc 11 source code, but yea, sure, same difference.
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 --- Comment #3 from Andrew Pinski --- >toplev.c You mean toplev.cc right?
[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Component|driver |plugins Last reconfirmed||2022-04-05 --- Comment #2 from Andrew Pinski --- >local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000; The only place where local_tick is used is inside coverage.cc: if (!flag_branch_probabilities && flag_test_coverage && (!local_tick || local_tick == (unsigned)-1)) /* Only remove the da file, if we're emitting coverage code and cannot uniquely stamp it. If we can stamp it, libgcov will DTRT. */ unlink (da_file_name); This does not make a difference really here. Plus inside a plugin, I don't see why you care about if -frandom-seed was supplied or not.
[Bug driver/105171] gcc/toplev.c: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
Jason A. Donenfeld changed:
What|Removed |Added
Component|plugins |driver
--- Comment #1 from Jason A. Donenfeld ---
Hi Andrew - I see you just changed the component to "plugins". That's partially
right, but partially wrong too, because this also affects components of gcc
itself. In particular, from gcc/coverage.c:
--
void
coverage_finish (void)
{
if (bbg_file_name && gcov_close ())
unlink (bbg_file_name);
if (!flag_branch_probabilities && flag_test_coverage
&& (!local_tick || local_tick == (unsigned)-1))
/* Only remove the da file, if we're emitting coverage code and
cannot uniquely stamp it. If we can stamp it, libgcov will DTRT. */
unlink (da_file_name);
--
Here we have two chances for local_tick to wrap around to 0 or to -1, when
perhaps that wasn't the intention.
So I'm going to set the component field back to driver, where the bug lives, as
this clearly affects multiple things (coverage, plugins, maybe other stuff I
don't know).
[Bug debug/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105041 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #5 from Segher Boessenkool --- It is not so uncommon at all: it is enabled by -funroll-loops, which is used quite often.
[Bug driver/105171] New: `local_tick` can overflow and become -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 Bug ID: 105171 Summary: `local_tick` can overflow and become -1 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jason at zx2c4 dot com Target Milestone: --- In gcc/toplev.c, there's the comment: /* A local time stamp derived from the time of compilation. It will be zero if the system cannot provide a time. It will be -1u, if the user has specified a particular random seed. */ unsigned local_tick; This is affirmed by init_local_tick()'s comment: /* Initialize local_tick with the time of day, or -1 if flag_random_seed is set. */ static void init_local_tick (void) And indeed we see it assigned -1 when flag_random_seed != NULL: else local_tick = -1; So far so good. However, in the case where flag_random_seed == NULL, local_tick is assigned like this: struct timeval tv; gettimeofday (, NULL); local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000; Recall that local_tick is of type "unsigned". Somewhat often, that expression calculates to be 0x, which means local_tick winds up being -1 even when flag_random_seed == NULL. This is a problem for plugins that follow the documentation comments in order to determine whether -frandom-seed is being used. To work around this bug, these plugins should just call get_random_seed(noinit=true) in their plugin init functions and check there whether the return value is zero. If they use a local_tick==-1 check, once in a blue moon, it'll be wrong. Probably, though, the type of local_tick should be changed to a HOST_WIDE_INT, or something similar to that.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-April/5 ||92808.html
[Bug ipa/104303] [12 regression] gnatmake is miscompiled by IPA/modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #6 from Jan Hubicka ---
OK, tree-ssa-alias is using:
if (ref_may_access_global_memory_p (ref))
to determine if the access to S9b.6_22 may be used by the call. I expected
this to return true because memory pointed to S9b.6_22 is escaping and thus it
is accessible from global memory accesses.
However the implementation does:
/* Return ture if REF may access global memory. */
bool
ref_may_access_global_memory_p (ao_ref *ref)
{
if (!ref->ref)
return true;
tree base = ao_ref_base (ref);
if (TREE_CODE (base) == MEM_REF
|| TREE_CODE (base) == TARGET_MEM_REF)
{
if (ptr_deref_may_alias_global_p (TREE_OPERAND (base, 0)))
return true;
}
else
{
if (!auto_var_in_fn_p (base, current_function_decl)
|| pt_solution_includes (>gimple_df->escaped,
base))
return true;
}
return false;
}
so for automatic variables we check "escaped" flag, but since this is heap
alocated we go the ptr_deref_may_alias_global_p path which checks:
/* Return true, if dereferencing PTR may alias with a global variable. */
bool
ptr_deref_may_alias_global_p (tree ptr)
{
struct ptr_info_def *pi;
/* If we end up with a pointer constant here that may point
to global memory. */
if (TREE_CODE (ptr) != SSA_NAME)
return true;
pi = SSA_NAME_PTR_INFO (ptr);
/* If we do not have points-to information for this variable,
we have to punt. */
if (!pi)
return true;
/* ??? This does not use TBAA to prune globals ptr may not access. */
return pt_solution_includes_global (>pt);
}
So this predicate tests something different - it tests if the deref can alias
global variable, not global memory in a sense of anything accessible from
outside world.
So I want to also return true on points to set that contains escaped?
diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index 50bd47b31f3..9e34f76c3cb 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -2578,8 +2578,24 @@ ref_may_access_global_memory_p (ao_ref *ref)
if (TREE_CODE (base) == MEM_REF
|| TREE_CODE (base) == TARGET_MEM_REF)
{
- if (ptr_deref_may_alias_global_p (TREE_OPERAND (base, 0)))
+ struct ptr_info_def *pi;
+ tree ptr = TREE_OPERAND (base, 0);
+
+ /* If we end up with a pointer constant here that may point
+to global memory. */
+ if (TREE_CODE (ptr) != SSA_NAME)
+ return true;
+
+ pi = SSA_NAME_PTR_INFO (ptr);
+
+ /* If we do not have points-to information for this variable,
+we have to punt. */
+ if (!pi)
return true;
+
+ /* ??? This does not use TBAA to prune globals ptr may not access. */
+ return pt_solution_includes_global (>pt)
+|| pi->pt.vars_contains_escaped;
}
else
{
[Bug c++/105164] new warning in clang, missing in gcc: -Wbitwise-instead-of-logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105164 --- Comment #1 from David Binderman --- Interestingly, I tried a build of gcc trunk with the new clang-14 and got many cases of this warning. $ grep "warning:.*Wbitwise-instead-of-logical" mk.out | sort | uniq -c > /tmp/0 $ wc -l /tmp/0 16 /tmp/0 $ cat /tmp/0 1 :184:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/c-family/c-attribs.cc:2384:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/decl.cc:11850:7: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 2 ../../trunk.git/gcc/cp/lex.cc:124:24: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/lex.cc:571:11: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/module.cc:16843:11: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/name-lookup.cc:7528:12: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/cp/parser.cc:883:11: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 51 ../../trunk.git/gcc/function-abi.h:177:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 49 ../../trunk.git/gcc/function-abi.h:184:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/function-abi.h../../trunk.git/gcc/loop-unroll.cc::1841750::1319:: warning: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds] 1 ../../trunk.git/gcc/gimple-ssa-sprintf.cc:1225:19: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/gimple-ssa-sprintf.cc:1664:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] 1 ../../trunk.git/gcc/rtl.h:../../trunk.git/gcc/function-abi.h:184:13: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] 1 :../../trunk.git/gcc/rtl.h warning: :use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical]1237 5 ../../trunk.git/gcc/rtl-ssa/internals.inl:436:25: warning: use of bitwise '&' with boolean operands [-Wbitwise-instead-of-logical] On the evidence of the source code of gcc, this new clang warning might be worth implementing in gcc.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 Sebastian Pop changed: What|Removed |Added Attachment #52750|0 |1 is obsolete|| --- Comment #3 from Sebastian Pop --- Created attachment 52755 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52755=edit patch LSE atomics do not need a barrier. Updated the patch to only generate the barriers after outline-atomics calls.
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
--- Comment #5 from Jan Hubicka ---
It is indeed missing logic to merge the side_effect and nondeterministic flag
while updating after inlining. I am testing the following
diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
index acfd7d80ff8..556816ab429 100644
--- a/gcc/ipa-modref.cc
+++ b/gcc/ipa-modref.cc
@@ -5281,6 +5281,29 @@ ipa_merge_modref_summary_after_inlining (cgraph_edge
*edge)
if (!ignore_stores)
to_info_lto->stores->collapse ();
}
+ /* Merge side effects and non-determinism.
+ PURE/CONST flags makes functions deterministic and if there is
+ no LOOPING_CONST_OR_PURE they also have no side effects. */
+ if (!(flags & (ECF_CONST | ECF_NOVOPS | ECF_PURE))
+ || (flags & ECF_LOOPING_CONST_OR_PURE))
+{
+ if (to_info)
+ {
+ if (!callee_info || callee_info->side_effects)
+ to_info->side_effects = true;
+ if ((!callee_info || callee_info->nondeterministic)
+ && !ignore_nondeterminism_p (edge->caller->decl, flags))
+ to_info->nondeterministic = true;
+ }
+ if (to_info_lto)
+ {
+ if (!callee_info_lto || callee_info_lto->side_effects)
+ to_info_lto->side_effects = true;
+ if ((!callee_info_lto || callee_info_lto->nondeterministic)
+ && !ignore_nondeterminism_p (edge->caller->decl, flags))
+ to_info_lto->nondeterministic = true;
+ }
+ }
if (callee_info || callee_info_lto)
{
auto_vec parm_map;
[Bug c++/100608] [10/11/12 Regression] -Wshadow=compatible-local false positive: function local type declaration shadows variable of different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100608 Jason Merrill changed: What|Removed |Added Depends on||92024 Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED CC||edlinger at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill --- This was changed by the patch for PR92024. In the comment for that patch, Bernd wrote "I think shadowing one type with another type of the same name is always a no no" but then warns if either old or new decl is a type. I think a type and a non-type can't really be considered compatible. Testing a patch. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024 [Bug 92024] crash in check_local_shadow
[Bug fortran/105170] New: Invalid finalization in intrinsic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105170 Bug ID: 105170 Summary: Invalid finalization in intrinsic assignment Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baradi09 at gmail dot com Target Milestone: --- Created attachment 52754 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52754=edit Minimal working example demonstrating the bug I have a derived type (TWrapper), which has a component with defined assignment. The containing derived type itself has no defined assignment. Upon an assignment between two TWrapper instances, a copy of the RHS seems to get finalized. The attached MWE demonstrates the problem. Expected output (as delivered by current Intel and NAG compilers): RefCounter_final, id:0 TRefCounter_init: id:42 -> Assignment wrapper2 = wrapper TRefCounter_final, id:0 TRefCounter_final, id:0 TRefCounter_assign: this%id, other%id: 0 42 GFortran output: TRefCounter_final, id:0 TRefCounter_init: id:42 -> Assignment wrapper2 = wrapper TRefCounter_final, id:42 TRefCounter_assign: this%id, other%id: 0 42 One finalization seems to be missing. Additionally, the finalized instance seems to be a copy of the RHS. (A copy, because after the finalization, the RHS still seems to have kept its id-value...)
[Bug c++/102593] [10/11/12 Regression] ICE in cp_oacc_check_attachments, at cp/semantics.c:6561 since r10-5596-g519d7496beac32c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102593 Jason Merrill changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill --- I'm not entirely clear on the restrictions on the var-list argument, but "t.a" can't be valid: "t" is a type, not an expression. cp_parser_omp_var_list_no_open mysteriously goes out of its way to accept it anyway: if (identifier_p (name)) decl = cp_parser_lookup_name_simple (parser, name, token->location); this lookup will return any kind of decl. I don't know what this code is trying to allow, but the effect is to build a nonsense COMPONENT_REF which understandably confuses later code.
[Bug tree-optimization/24021] VRP does not work with floating points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 --- Comment #19 from Andrew Macleod --- We can use the original testcase as the litmus test for basic support if we compile it with -O2 -fno-tree-fre -fno-tree-dominator-opts The unroller will unroll the loop and the VRP2 pass will be presented with: [local count: 97603129]: i_1 = 1.100149011611438876201418679556809365749359130859375e-1; i_17 = i_1 + 1.0001490116119384765625e-1; i_22 = i_17 + 1.0001490116119384765625e-1; i_27 = i_22 + 1.0001490116119384765625e-1; i_32 = i_27 + 1.0001490116119384765625e-1; i_37 = i_32 + 1.0001490116119384765625e-1; i_42 = i_37 + 1.0001490116119384765625e-1; i_47 = i_42 + 1.0001490116119384765625e-1; i_52 = i_47 + 1.0001490116119384765625e-1; if (i_52 == 0.0) goto ; [50.00%] else goto ; [50.00%] [local count: 48801565]: [local count: 97603129]: # lastPoint_12 = PHI return lastPoint_12; Which is we can track floating point ranges in VRP and simplification, recognize that i_52 != 0.0 and VRP2 should be able to resolve this to return 2.0e+0;
[Bug fortran/105168] [9/10/11/12 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P4 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100155 Last reconfirmed||2022-04-05 --- Comment #1 from anlauf at gcc dot gnu.org --- Likely related to pr100155 or a duplicate.
[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329 --- Comment #5 from Jason Merrill --- Created attachment 52753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52753=edit fix? I can't reproduce this with the top of either the 11 or 12 branches; if you can, does this fix it?
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 105139, which changed state. Bug 105139 Summary: [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 Uroš Bizjak changed: What|Removed |Added CC|uros at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Uroš Bizjak --- Fixed.
[Bug target/105139] [12 Regression] GCC produces vmovw instruction with an incorrect argument for -O3 -march=sapphirerapids since r12-6215-g708b87dcb6e48cb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139 --- Comment #7 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:cbc9dd66484a51d450f78ab748a872b939c90c3f commit r12-8004-gcbc9dd66484a51d450f78ab748a872b939c90c3f Author: Uros Bizjak Date: Tue Apr 5 21:03:18 2022 +0200 i386: Fix movv2qi_internal xmm reg to xmm reg move for AVX512FP16 [PR105139] 2022-04-05 Uroš Bizjak gcc/ChangeLog: PR target/105139 * config/i386/mmx.md (*movv2qi_internal): Change insn mode of alternative 5 to HF for TARGET_AVX512FP16. gcc/testsuite/ChangeLog: PR target/105139 * gcc.target/i386/pr105139.c: New test.
[Bug c/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149 --- Comment #7 from joseph at codesourcery dot com --- I think it's valid to reject this at compile time (rather than just generating a runtime trap): the "such that the type of a pointer to an object that has the specified type can be obtained simply by postfixing a * to type" can never be satisfied for a function type, even if e.g. a typedef name is used so that postfixing '*' produces valid syntax for the corresponding pointer type, because it still wouldn't be "the type of a pointer to an object".
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 --- Comment #15 from Andrew Macleod --- no... we won't process ranges for anything unless it passes supports_type_p (): (INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type))) oh oh oh. Never mind. I see. we are generating a range for i_2, and I'm now using the type of op1... we probably are NOT generating ranges for x_1... but I am looking at its type in this case. Doh! my bad. I shall use element_precision. problem solved. Thanks
[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Priority|P3 |P4 Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 --- Comment #3 from kargl at gcc dot gnu.org --- Patch attached.
[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 52752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52752=edit Patch to fix PR The problem is two-fold. First, there is the infamous NULL pointer dereference in resolve.cc(resolve_variable). Second, if the variable 'n' is implicitly defined and it is in a PROGRAM or MODULE specification part of the scoping unit, it cannot be a variable.
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 --- Comment #14 from Jakub Jelinek --- INTEGRAL_TYPE_P is only true for scalar integral types (integer, enum and boolean). Do you mean ANY_INTEGRAL_TYPE_P instead which is true also for integral vector and complex types? Anyway, one can use element_precision (type) to query the precision for scalar types and precision of each element (for vector and complex types).
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
--- Comment #13 from Andrew Macleod ---
huh, so even after fixing the testcase, ranger is still tripping over this test
case.
uv1ti ashl_v1ti (uv1ti x, unsigned int i)
{
uv1ti _3;
:
_3 = x_1(D) << i_2(D);
return _3;
we have an ssa_name for x_1 with a type of uvlti.
This passes the INTEGRAL_TYPE_P test and an ssa_name is created, but is it
actually a vector_type. This seems to be OK, but being unaware of this, and
having a type which passes the INTEGRAL_TYPE_P (type), I was using
TYPE_PRECISION (type) to find the upper bounds for i_2.
It appears that if VECTOR_TYPE_P (type) is true, then TYPE_PRECISION (type) is
not a valid request? but it silently returns 0 and happily moves on.
As near as I can tell, I am suppose to ask for:
TYPE_PRECISION (TREE_TYPE (type)) when its a VECTOR_TYPE?
IS there a good reason we don't fill in the TYPE_PRECISION field? Or if its
not suppose to be used, then can we trap on it if its passed a vector type? It
seems like the sort of thing that is easy to trip over. Are their other bits
which make VECTOR_TYPE incompatible with scalar INTGERAL_TYPEs that should not
be queried?
[Bug fortran/105138] [7,8,9,10,11,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[7,8,9,10,11,12,F95] Bogus |[7,8,9,10,11,F95] Bogus |error when function name|error when function name |does not shadow an |does not shadow an |intrinsic when RESULT |intrinsic when RESULT |clause is used |clause is used --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 so far.
[Bug fortran/104210] [11 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104210 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[11 Regression] ICE in |gfc_zero_size_array, at |gfc_zero_size_array, at |fortran/arith.cc:1685 since |fortran/arith.cc:1685 since |r11-1814-gcc9a9229285a26ac |r11-1814-gcc9a9229285a26ac --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 so far.
[Bug fortran/104210] [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104210 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:892c7f03ae63121766a8be48f7e3b672547fd627 commit r12-8003-g892c7f03ae63121766a8be48f7e3b672547fd627 Author: Harald Anlauf Date: Tue Mar 29 23:33:23 2022 +0200 Fortran: improve error recovery for invalid coarray function declarations gcc/fortran/ChangeLog: PR fortran/104210 * arith.cc (eval_intrinsic): Avoid NULL pointer dereference. (gfc_zero_size_array): Likewise. gcc/testsuite/ChangeLog: PR fortran/104210 * gfortran.dg/pr104210.f90: New test.
[Bug fortran/105138] [7,8,9,10,11,12,F95] Bogus error when function name does not shadow an intrinsic when RESULT clause is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138 --- Comment #12 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d46685b04071a485b56de353d997a866bfc8caba commit r12-8002-gd46685b04071a485b56de353d997a866bfc8caba Author: Harald Anlauf Date: Mon Apr 4 20:42:51 2022 +0200 Fortran: a RECURSIVE procedure cannot be an INTRINSIC gcc/fortran/ChangeLog: PR fortran/105138 * intrinsic.cc (gfc_is_intrinsic): When a symbol refers to a RECURSIVE procedure, it cannot be an INTRINSIC. gcc/testsuite/ChangeLog: PR fortran/105138 * gfortran.dg/recursive_reference_3.f90: New test. Co-authored-by: Steven G. Kargl
[Bug fortran/104812] Construct-name with same variable name in scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 --- Comment #6 from Mike K. --- Thanks a lot for the guidance, posted patch.
[Bug ipa/105166] [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:863 since r12-5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105166
--- Comment #2 from Jakub Jelinek ---
Testcase without warnings:
void
bar (foo, a)
void (**foo) ();
int a;
{
(foo)[1] = bar;
foo[1] (1);
}
[Bug ipa/105166] [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:863 since r12-5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105166 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P1 Status|UNCONFIRMED |NEW Component|c |ipa CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Summary|[12 Regression] ICE in |[12 Regression] ICE in |ao_ref_init_from_ptr_and_ra |ao_ref_init_from_ptr_and_ra |nge, at |nge, at |tree-ssa-alias.cc:863 |tree-ssa-alias.cc:863 since ||r12-5244 --- Comment #1 from Jakub Jelinek --- Started with r12-5244-g64f3e71c302b4a13e61656ee509e7050b9bce978
[Bug c++/105169] New: Compiling C++ code with -fpatchable-function-entry=16,14 results in references to discarded sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169 Bug ID: 105169 Summary: Compiling C++ code with -fpatchable-function-entry=16,14 results in references to discarded sections Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: giuliano.belinassi at gmail dot com Target Milestone: --- Created attachment 52751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52751=edit Small project to reproduce claimed failure. Compiling the attached project running `make` results in the following messages from ld (GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-7.26): `.text._ZN21WinsockInterfaceClass12Get_ProtocolEv' referenced in section `__patchable_function_entries' of wsproto.o: defined in discarded section `.text._ZN21WinsockInterfaceClass12Get_ProtocolEv[_ZN21WinsockInterfaceClass12Get_ProtocolEv]' of wsproto.o The project compiles fine without -fpatchable-function-entry. PS: I could not manage to reduce the testcase into a single file.
[Bug tree-optimization/105163] [9/10/11/12 Regression] ICE: SSA corruption since r0-122928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-04-05 Ever confirmed|0 |1 Target Milestone|--- |9.5 CC||jakub at gcc dot gnu.org Summary|ICE: SSA corruption |[9/10/11/12 Regression] ||ICE: SSA corruption since ||r0-122928 Priority|P3 |P2 Status|UNCONFIRMED |NEW
[Bug tree-optimization/105163] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163 --- Comment #2 from Jakub Jelinek --- #c0 started to ICE with r0-122928-gf6b64c35014ca111711e753be85bb99280a1e115 #c1 as well if you don't omit the argument name.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #2 from Sebastian Pop --- Created attachment 52750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52750=edit patch Fix.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 --- Comment #1 from Sebastian Pop --- Also happens when compiling with LSE: -march=armv8.1-a or later.
[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 Bug 104552 depends on bug 104897, which changed state. Bug 104897 Summary: wrong plural form in diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/104897] wrong plural form in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 103852, which changed state. Bug 103852 Summary: [10/11/12 Regression] Alias template argument deduction is available in C++17 mode https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- GCC 12 will give a pedwarn about the testcase. Not backporting.
[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103147 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:14814e20161d7b6a4e9cac244c7013fa56f71f55 commit r12-8000-g14814e20161d7b6a4e9cac244c7013fa56f71f55 Author: Richard Sandiford Date: Tue Apr 5 17:31:35 2022 +0100 aarch64: Fix -fpack-struct + [PR103147] This PR is about -fpack-struct causing a crash when is included. The new register_tuple_type code was expecting a normal unpacked structure layout instead of a packed one. For SVE we got around this by temporarily suppressing -fpack-struct, so that the tuple types always have their normal ABI. However: (a) The SVE ACLE tuple types are defined to be abstract. The fact that GCC uses structures is an internal implementation detail. (b) In contrast, the ACLE explicitly defines the Advanced SIMD tuple types to be particular structures. (c) Clang and previous versions of GCC are consistent in applying -fpack-struct to these tuple structures. This patch therefore honours -fpack-struct and -fpack-struct=. It also adds tests for some other combinations, such as -mgeneral-regs-only and -fpack-struct -mstrict-align. gcc/ PR target/103147 * config/aarch64/aarch64-protos.h (aarch64_simd_switcher): New class. * config/aarch64/aarch64-sve-builtins.h (sve_switcher): Inherit from aarch64_simd_switcher. * config/aarch64/aarch64-builtins.cc (aarch64_simd_tuple_modes): New variable. (aarch64_lookup_simd_builtin_type): Use it instead of TYPE_MODE. (register_tuple_type): Add more asserts. Expect the alignment of the structure to be subject to flag_pack_struct and maximum_field_alignment. Set aarch64_simd_tuple_modes. (aarch64_simd_switcher::aarch64_simd_switcher): New function. (aarch64_simd_switcher::~aarch64_simd_switcher): Likewise. (handle_arm_neon_h): Hold an aarch64_simd_switcher throughout. (aarch64_general_init_builtins): Hold an aarch64_simd_switcher while calling aarch64_init_simd_builtins. * config/aarch64/aarch64-sve-builtins.cc (sve_switcher::sve_switcher) (sve_switcher::~sve_switcher): Remove code now performed by aarch64_simd_switcher. gcc/testsuite/ PR target/103147 * gcc.target/aarch64/pr103147-1.c: New test. * gcc.target/aarch64/pr103147-2.c: Likewise. * gcc.target/aarch64/pr103147-3.c: Likewise. * gcc.target/aarch64/pr103147-4.c: Likewise. * gcc.target/aarch64/pr103147-5.c: Likewise. * gcc.target/aarch64/pr103147-6.c: Likewise. * gcc.target/aarch64/pr103147-7.c: Likewise. * gcc.target/aarch64/pr103147-8.c: Likewise. * gcc.target/aarch64/pr103147-9.c: Likewise. * gcc.target/aarch64/pr103147-10.c: Likewise. * g++.target/aarch64/pr103147-1.C: Likewise. * g++.target/aarch64/pr103147-2.C: Likewise. * g++.target/aarch64/pr103147-3.C: Likewise. * g++.target/aarch64/pr103147-4.C: Likewise. * g++.target/aarch64/pr103147-5.C: Likewise. * g++.target/aarch64/pr103147-6.C: Likewise. * g++.target/aarch64/pr103147-7.C: Likewise. * g++.target/aarch64/pr103147-8.C: Likewise. * g++.target/aarch64/pr103147-9.C: Likewise. * g++.target/aarch64/pr103147-10.C: Likewise.
[Bug target/104897] wrong plural form in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e8bc70cc17b0105e2c463a98c9ff76039d03ff60 commit r12-7999-ge8bc70cc17b0105e2c463a98c9ff76039d03ff60 Author: Richard Sandiford Date: Tue Apr 5 17:31:35 2022 +0100 aarch64: Use error_n for plural text [PR104897] Use error_n rather than error_at for â%d vectorsâ, so that translators can pick different translations based on the number (2 vs more than 2, etc.) gcc/ PR target/104897 * config/aarch64/aarch64-sve-builtins.cc (function_resolver::infer_vector_or_tuple_type): Use error_n for "%d vectors" messages.
[Bug fortran/104812] Construct-name with same variable name in scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |--- Ever confirmed|0 |1 Priority|P3 |P4 Status|RESOLVED|REOPENED Last reconfirmed||2022-04-05 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Mike K. from comment #4) > Created attachment 52749 [details] > propose to return an error if constuct-name clashes with variable name > > > Note, the prohibition in the standard is not a numbered > > constraint, which means a compiler need not issue an > > error or warning. It is expected that the programmer > > writes conforming code. > > Could we enforce this constraint and print error message instead of relying > on programmer? I think that explicit error is better than silently accepting > non-conforming code for some corner-cases. > > Attached patch with proposed fix, wdyth? Thanks for the patch. I no longer commit due to the migration to git. I've changed the Status to Reopened so that another gfortran developer might take a look. You can likely get some attention for this PR and your patch if you post it in fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org. Ask someone to committed. You might need to ping the email after a week or so if no one respondes.
[Bug c/105165] [11/12 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.cc:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105165 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-04-05 --- Comment #1 from Jakub Jelinek --- This started with r11-5002-ge3b3b59683c1e7d31a9d313dd97394abebf644be so not really sure if we can call it a regression. It is a regression in that something that didn't ICE before now ICEs, but it was invalid before and now is valid.
[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5d583d24200ac33a1cb281b7ddee9aad351151b5 commit r12-7998-g5d583d24200ac33a1cb281b7ddee9aad351151b5 Author: Jason Merrill Date: Mon Apr 4 11:56:38 2022 -0400 c++: alias template equivalence and CTAD [PR103852] I had been thinking about DR1286 "equivalence" as meaning generally interchangeable, but looking back at the proposed resolution in the context of this PR, I see that it's just about use as a template argument. So let's give a pedwarn if we look through a renaming alias. PR c++/103852 DR 1286 gcc/cp/ChangeLog: * pt.cc (do_class_deduction): Pedwarn for renaming alias in C++17. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction-alias1.C: Expect warning.
[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1de6612d994ada8edaab18bbc6afd8e9a57413aa commit r12-7997-g1de6612d994ada8edaab18bbc6afd8e9a57413aa Author: Jason Merrill Date: Sun Mar 27 22:31:51 2022 -0400 c++: elaborated-type-spec in requires-expr [PR101677] We were failing to declare class S in the global namespace because we were treating the requires-expression parameter scope as a normal block scope, so the implicit declaration went there. It seems to me that the requires parameter scope is more like a function parameter scope (not least in the use of the word "parameter"), so let's change the scope kind. But then we need to adjust the prohibition on placeholders declaring implicit template parameters. PR c++/101677 gcc/cp/ChangeLog: * name-lookup.h (struct cp_binding_level): Add requires_expression bit-field. * parser.cc (cp_parser_requires_expression): Set it. (synthesize_implicit_template_parm): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr67178.C: Adjust error. * g++.dg/cpp2a/concepts-requires28.C: New test.
[Bug fortran/105168] New: [9/10/11/12 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168 Bug ID: 105168 Summary: [9/10/11/12 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r8, changed between 20190503 and 20190614 : (follow-up of pr104430) $ cat z1.f90 module m type t integer :: a end type contains function f(x) result(z) class(t) :: x(:) type(t) :: z(size(x%a)) end end program p use m class(t), allocatable :: y(:), z(:) z = f((y)) end $ gfortran-7 -c z1.f90 $ $ gfortran-12-20220403 -c z1.f90 z1.f90:14:13: 14 |z = f((y)) | 1 internal compiler error: Segmentation fault 0xcce34f crash_signal ../../gcc/toplev.cc:322 0x7d8cfd gfc_maybe_dereference_var(gfc_symbol*, tree_node*, bool, bool) ../../gcc/fortran/trans-expr.cc:2870 0x7e06fb gfc_conv_variable ../../gcc/fortran/trans-expr.cc:3065 0x7dc7da gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9413 0x7df570 gfc_conv_expr_lhs(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9443 0x7afdf8 gfc_conv_ss_descriptor ../../gcc/fortran/trans-array.cc:3219 0x7ba85b gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.cc:7501 0x7f10ff gfc_conv_intrinsic_size ../../gcc/fortran/trans-intrinsic.cc:7975 0x807f8b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.cc:10646 0x7dc7ba gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9405 0x7deb8a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:4867 0x7aeb57 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) ../../gcc/fortran/trans-array.cc:1080 0x7ea037 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:7479 0x7eb93c gfc_trans_arrayfunc_assign ../../gcc/fortran/trans-expr.cc:10880 0x7ef614 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:12045 0x7ab6c7 trans_code ../../gcc/fortran/trans.cc:1916 0x7d4b7e gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7654 0x75734e translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x75734e gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7a47df gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/105167] ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 G. Steinmetz changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Interestingly, this type-spec "character(n)" with undefined "n" is simply ignored in following test case : $ cat z7.f90 program p print *, len([character(n) :: '']) print *, len([character(n) :: '1']) print *, len([character(n) :: '12']) print *, len([character(n) :: '123']) print *, len([character(n) :: '123456789']) print *, len([character(n) :: '1234567890123456789']) end $ gfortran-12-20220403 z7.f90 && ./a.out 0 1 2 3 9 19
[Bug fortran/105167] New: ICE in gfc_set_default_type, at fortran/symbol.cc:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105167 Bug ID: 105167 Summary: ICE in gfc_set_default_type, at fortran/symbol.cc:298 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Gives an ICE with undefined "n" (also sporadically before 20210926) : $ cat z1.f90 program p if ( len([character(n) :: '']) /= 0 ) stop end $ gfortran-12-20210905 -c z1.f90 z1.f90:2:23: 2 |if ( len([character(n) :: '']) /= 0 ) stop | 1 Error: Scalar INTEGER expression expected at (1) z1.f90:2:23: 2 |if ( len([character(n) :: '']) /= 0 ) stop | 1 Error: Scalar INTEGER expression expected at (1) $ gfortran-12-20220403 -c z1.f90 f951: internal compiler error: Segmentation fault 0xcce34f crash_signal ../../gcc/toplev.cc:322 0x7919da gfc_get_default_type(char const*, gfc_namespace*) ../../gcc/fortran/symbol.cc:231 0x795734 gfc_set_default_type(gfc_symbol*, int, gfc_namespace*) ../../gcc/fortran/symbol.cc:298 0x765671 resolve_variable ../../gcc/fortran/resolve.cc:5886 0x765671 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7189 0x767024 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:12657 0x767024 resolve_charlen ../../gcc/fortran/resolve.cc:12607 0x773809 resolve_charlen ../../gcc/fortran/resolve.cc:12598 0x773809 resolve_types ../../gcc/fortran/resolve.cc:17482 0x76ecbc gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17599 0x756c44 resolve_all_program_units ../../gcc/fortran/parse.cc:6604 0x756c44 gfc_parse_file() ../../gcc/fortran/parse.cc:6860 0x7a47df gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug c/105166] New: [12 Regression] ICE in ao_ref_init_from_ptr_and_range, at tree-ssa-alias.cc:863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105166
Bug ID: 105166
Summary: [12 Regression] ICE in ao_ref_init_from_ptr_and_range,
at tree-ssa-alias.cc:863
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20211107 and 2024, at -O1+ :
$ cat z1.c
bar (foo, a)
int (**foo) ();
{
(foo)[1] = bar;
foo[1] (1);
}
$ gcc-12-20220403 -c z1.c -O2
z1.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | bar (foo, a)
| ^~~
z1.c: In function 'bar':
z1.c:1:1: warning: type of 'a' defaults to 'int' [-Wimplicit-int]
during GIMPLE pass: dse
z1.c:1:1: internal compiler error: in ao_ref_init_from_ptr_and_range, at
tree-ssa-alias.cc:863
0xcfd747 ao_ref_init_from_ptr_and_range(ao_ref*, tree_node*, bool, poly_int<1u,
long>, poly_int<1u, long>, poly_int<1u, long>)
../../gcc/tree-ssa-alias.cc:863
0xa1080b modref_access_node::get_ao_ref(gcall const*, ao_ref*) const
../../gcc/ipa-modref-tree.cc:688
0xd03eb3 stmt_kills_ref_p(gimple*, ao_ref*)
../../gcc/tree-ssa-alias.cc:3461
0xd28b56 dse_classify_store(ao_ref*, gimple*, bool, simple_bitmap_def*, bool*,
tree_node*)
../../gcc/tree-ssa-dse.cc:1053
0xd2aecf dse_optimize_stmt
../../gcc/tree-ssa-dse.cc:1385
0xd2aecf execute
../../gcc/tree-ssa-dse.cc:1491
[Bug c/105165] New: [11/12 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.cc:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105165
Bug ID: 105165
Summary: [11/12 Regression] ICE in
gimple_redirect_edge_and_branch, at tree-cfg.cc:6136
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20201108 and 20201115, at -O1+ :
(derived from pr100329.c)
$ cat z1.c
unsigned int _Complex a0;
unsigned int _Complex
foo (unsigned int _Complex a1, unsigned int _Complex a2)
{
unsigned int _Complex x;
asm goto ("" : "=r" (x) : : : lab);
a0 = x;
lab:
return x + a1 + a2 + 1;
}
$ gcc-12-20220403 -c z1.c -O2
during GIMPLE pass: pre
z1.c: In function 'foo':
z1.c:3:1: internal compiler error: in gimple_redirect_edge_and_branch, at
tree-cfg.cc:6136
3 | foo (unsigned int _Complex a1, unsigned int _Complex a2)
| ^~~
0xc611c5 gimple_redirect_edge_and_branch
../../gcc/tree-cfg.cc:6136
0x7d3139 redirect_edge_and_branch(edge_def*, basic_block_def*)
../../gcc/cfghooks.cc:388
0xc593b8 gimple_split_edge
../../gcc/tree-cfg.cc:2983
0x7d37c5 split_edge(edge_def*)
../../gcc/cfghooks.cc:668
0xc61f67 split_critical_edges(bool)
../../gcc/tree-cfg.cc:9172
0xda6ab1 split_edges_for_insertion()
../../gcc/tree-cfg.h:130
0xda6ab1 execute
../../gcc/tree-ssa-pre.cc:4402
[Bug c/105163] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163
G. Steinmetz changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
Keywords||ice-on-valid-code
--- Comment #1 from G. Steinmetz ---
A corrupted variant starts to give an ICE between 20201018 and 20201108 :
$ cat z2.c
typedef struct __jmp_buf_tag { char buf[1024]; } jmp_buf[1];
extern int setjmp (jmp_buf);
extern jmp_buf *baz (void);
struct A { int b; };
void foo (struct A, int *z, int c)
{
unsigned d = 0;
long e;
setjmp (*baz());
e = 1 + ~d;
d = 8;
if ((!0) && !c && bar(z)) *z = 1 + e;
}
[Bug c++/105164] New: new warning in clang, missing in gcc: -Wbitwise-instead-of-logical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105164
Bug ID: 105164
Summary: new warning in clang, missing in gcc:
-Wbitwise-instead-of-logical
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
extern bool f1( int);
extern void f3( int);
void
f2( int n)
{
if (!f1(n) & !f1( n + 1))
f3( n - 1);
if (!f1(n) | !f1( n + 1))
f3( n + 1);
}
recent gcc trunk says not a lot:
$ /home/dcb/gcc/results/bin/g++ -g -O2 -Wall -Wextra -pedantic -c jul01a.cc
$
However, new clang-14 says:
$ clang++ -g -O2 -Wall -Wextra -pedantic -c jul01a.cc
jul01a.cc:8:6: warning: use of bitwise '&' with boolean operands
[-Wbitwise-instead-of-logical]
if (!f1(n) & !f1( n + 1))
^~~~
&&
jul01a.cc:8:6: note: cast one or both operands to int to silence this warning
jul01a.cc:11:6: warning: use of bitwise '|' with boolean operands
[-Wbitwise-instead-of-logical]
if (!f1(n) | !f1( n + 1))
^~~~
||
jul01a.cc:11:6: note: cast one or both operands to int to silence this warning
2 warnings generated.
$
Static analyser cppcheck also finds the problem:
$ /home/dcb/cppcheck/trunk.git/cppcheck --enable=all jul01a.cc
jul01a.cc:8:13: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
if (!f1(n) & !f1( n + 1))
^
jul01a.cc:11:13: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
if (!f1(n) | !f1( n + 1))
^
jul01a.cc:6:0: style: The function 'f2' is never used. [unusedFunction]
^
[Bug c/105163] New: ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163
Bug ID: 105163
Summary: ICE: SSA corruption
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5, at -O1+ :
(follow-up of pr79411.c)
$ cat z1.c
typedef struct __jmp_buf_tag { char buf[1024]; } jmp_buf[1];
extern int setjmp (jmp_buf);
extern int bar (unsigned int *);
extern jmp_buf *baz (void);
struct C { int c1; };
void foo (struct C *x, int *z, int e)
{
unsigned int d = 0;
long f;
setjmp (*baz());
f = 1 + ~d;
d = 8;
if ((!0) && !e && bar(z)) *z = 1 + f;
}
$ gcc-12-20220403 -c z1.c -O2
Unable to coalesce ssa_names 5 and 17 which are marked as MUST COALESCE.
d_5(ab) and d_17(ab)
during RTL pass: expand
z1.c: In function 'foo':
z1.c:6:6: internal compiler error: SSA corruption
6 | void foo (struct C *x, int *z, int e)
| ^~~
0xd18bc8 fail_abnormal_edge_coalesce
../../gcc/tree-ssa-coalesce.cc:1003
0xd18bc8 coalesce_partitions
../../gcc/tree-ssa-coalesce.cc:1425
0xd18bc8 coalesce_ssa_name(_var_map*)
../../gcc/tree-ssa-coalesce.cc:1755
0xcc26a0 remove_ssa_form
../../gcc/tree-outof-ssa.cc:1065
0xcc26a0 rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.cc:1323
0x7cfa73 execute
../../gcc/cfgexpand.cc:6585
[Bug target/105162] New: [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162
Bug ID: 105162
Summary: [AArch64] outline-atomics drops dmb ish barrier on
__sync builtins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: spop at gcc dot gnu.org
Target Milestone: ---
With -mno-outline-atomics gcc produces a `dmb ish` barrier on __sync builtins
as required by the Intel specification
(see fix for https://gcc.gnu.org/PR65697
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f70fb3b635f9618c6d2ee3848ba836914f7951c2
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ab876106eb689947cdd8203f8ecc6e8ac38bf5ba
)
$ cat a.c
int foo(int a)
{
return __sync_bool_compare_and_swap(, 4, 5);
}
$ gcc -O2 a.c -S -o- -mno-outline-atomics
foo:
sub sp, sp, #16
mov w1, 5
str w0, [sp, 12]
add x0, sp, 12
.L4:
ldxrw2, [x0]
cmp w2, 4
bne .L5
stlxr w3, w1, [x0]
cbnzw3, .L4
.L5:
dmb ish
csetw0, eq
add sp, sp, 16
ret
With -moutline-atomics gcc does not generate the barrier:
$ gcc -O2 a.c -S -o- -moutline-atomics
foo:
stp x29, x30, [sp, -32]!
mov w1, 5
mov x29, sp
add x2, sp, 28
str w0, [sp, 28]
mov w0, 4
bl __aarch64_cas4_acq_rel
cmp w0, 4
csetw0, eq
ldp x29, x30, [sp], 32
ret
Happens on gcc-8, 9, 10, 11, and trunk.
[Bug fortran/104812] Construct-name with same variable name in scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 --- Comment #4 from Mike K. --- Created attachment 52749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52749=edit propose to return an error if constuct-name clashes with variable name > Note, the prohibition in the standard is not a numbered > constraint, which means a compiler need not issue an > error or warning. It is expected that the programmer > writes conforming code. Could we enforce this constraint and print error message instead of relying on programmer? I think that explicit error is better than silently accepting non-conforming code for some corner-cases. Attached patch with proposed fix, wdyth?
[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Segher Boessenkool --- This is an error from 2005 (g:4d3e6fae4dd3, r96124). It is generic code that makes this an error (instead of a warning), not the rs6000 backend, which just provides the string (via the invalid_arg_for_unprototyped_fn hook). s390 has this exact same error btw.
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- Mine. The inliner pass is supposed to update the summary so it seems like a bug there. I will take a look tonight.
[Bug testsuite/93260] Deal with missing CUDA etc. installation in libgomp '-lcuda' etc. test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93260
Thomas Schwinge changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
Component|libgomp |testsuite
Target||nvptx
--- Comment #3 from Thomas Schwinge ---
Need to verify what remains to be done here after Jakub's commit
r12-1098-g79e3f7d54bc4e34b096082d3b90042d9f0fbaf1a "libgomp: Add
openacc_{cuda,cublas,cudart} effective targets and use them in openacc
testsuite".
[Bug debug/105161] New: variable constant-folded in its uses appears as optimized out depending on where it is assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105161
Bug ID: 105161
Summary: variable constant-folded in its uses appears as
optimized out depending on where it is assigned
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C code, variable j is shown as optimized out when debugging
line 8, where it is used to index an access to global array b for assigning
volatile global variable a. The other two variables i and k used for the access
are instead available. This happens at possibly any optimization level: we
tested -Og, -O1, -O2, and -O3.
We suppose the operation (j)*k is constant-folded to 0 when computing the
offset for accessing b. The variable remains optimized out also under other
value choices for j that we tested. But it becomes visible if we make j
non-constant (for instance with “(j++)*k” at line 8).
We also note that if the assignment is done at declaration time (e.g., “int i =
0, j = 0, k;” with line 6 becoming simply “k=0;”), then variable j becomes
visible with 0 value.
Furthemore, for the modified code, older versions of gdb (e.g. 8.1) will not
list j among local variables: we believe this may be a then-fixed gdb bug, but
perhaps still worth mentioning.
We provide details for -Og on x64 and a quick assessment of older gcc versions
below.
$ cat a.c
volatile int a;
int b[10][2];
int main() {
int i = 0, j, k;
for (; i < 10; i++) {
j = k = 0;
for (; k < 1; k++)
a = b[i][(j)*k];
}
}
GCC and GDB version:
- gcc (GCC) 12.0.0 20211227 (experimental) - commit id: 500d3f0a302
- GNU gdb (GDB) 11.2
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 8
Breakpoint 1 at 0x40048d: file a.c, line 8.
(gdb) r
Starting program: /home/stepping/37/reduce/opt
Breakpoint 1, main () at a.c:8
8 a = b[i][(j)*k];
(gdb) info loc
i = 0
j =
k = 0
ASM of main function at Og:
00400486 :
400486: ba 00 00 00 00 mov$0x0,%edx
40048b: eb 1a jmp4004a7
40048d: 48 63 camovslq %edx,%rcx
400490: 8b 0c cd 60 10 60 00mov0x601060(,%rcx,8),%ecx
400497: 89 0d 13 0c 20 00 mov%ecx,0x200c13(%rip)#
6010b0
40049d: 83 c0 01add$0x1,%eax
4004a0: 85 c0 test %eax,%eax
4004a2: 7e e9 jle40048d
4004a4: 83 c2 01add$0x1,%edx
4004a7: 83 fa 09cmp$0x9,%edx
4004aa: 7f 07 jg 4004b3
4004ac: b8 00 00 00 00 mov$0x0,%eax
4004b1: eb ed jmp4004a0
4004b3: b8 00 00 00 00 mov$0x0,%eax
4004b8: c3 retq
4004b9: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
DWARF at -Og:
0x009b: DW_TAG_variable
DW_AT_name("i")
DW_AT_decl_column (0x07)
DW_AT_type(0x0041 "int")
DW_AT_location(0x0010:
[0x00400486, 0x0040048d): DW_OP_lit0,
DW_OP_stack_value
[0x0040048d, 0x004004b9): DW_OP_reg1 RDX)
DW_AT_GNU_locviews
(0x000c)
0x00ab: DW_TAG_variable
DW_AT_name("j")
DW_AT_decl_file ("/home/stepping/37/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x0e)
DW_AT_type(0x0041 "int")
0x00b5: DW_TAG_variable
DW_AT_name("k")
DW_AT_decl_column (0x11)
DW_AT_type(0x0041 "int")
DW_AT_location(0x001e:
[0x0040048d, 0x004004a7): DW_OP_reg0 RAX)
DW_AT_GNU_locviews
(0x001c)
>From DWARF information, attributes location and const value are completely
missing for variable j, while other variables have a correct location
definition that makes them available at line 8.
Interestingly, if we modify the source code by initializing variable j earlier
at line 4, the const value attribute is correctly added to variable’s DIE and
therefore the variable is correctly available at line 8 at every optimization
level.
DWARF at -Og (with j initialization at line 4):
0x009b: DW_TAG_variable
DW_AT_name("i")
DW_AT_decl_column (0x07)
DW_AT_type(0x0041 "int")
DW_AT_location(0x0010:
[0x00400486, 0x0040048d): DW_OP_lit0,
[Bug jit/104293] Add support for setting the alignment of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293 David Malcolm changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/jit/2022q1/001494.html Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-04-05
[Bug jit/104073] Add option to hide stderr logging in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/jit/attachments/20220123 ||/22c69b0c/attachment.bin Ever confirmed|0 |1 Keywords||patch Last reconfirmed||2022-04-05
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148
--- Comment #4 from Richard Biener ---
- MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: _6 * 4}[i_2]
= 0;
+ MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: <<< error
>>>}[i_2] = 0;
find_interesting_uses_op fails to consider _6 * 4, in fact idx_record_use
does
if (TREE_CODE (base) == ARRAY_REF || TREE_CODE (base) == ARRAY_RANGE_REF)
{
find_interesting_uses_op (data, array_ref_element_size (base));
find_interesting_uses_op (data, array_ref_low_bound (base));
}
but it should probably pass down the raw TREE_OPERANDs, not the scaled
array_ref_element_size ().
I have a patch:
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index b0305c494cd..81b536f9304 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -2124,8 +2124,10 @@ idx_record_use (tree base, tree *idx,
find_interesting_uses_op (data, *idx);
if (TREE_CODE (base) == ARRAY_REF || TREE_CODE (base) == ARRAY_RANGE_REF)
{
- find_interesting_uses_op (data, array_ref_element_size (base));
- find_interesting_uses_op (data, array_ref_low_bound (base));
+ if (TREE_OPERAND (base, 2))
+ find_interesting_uses_op (data, TREE_OPERAND (base, 2));
+ if (TREE_OPERAND (base, 3))
+ find_interesting_uses_op (data, TREE_OPERAND (base, 3));
}
return true;
}
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148
Jakub Jelinek changed:
What|Removed |Added
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #3 from Jakub Jelinek ---
This looks like an ivopts bug and I'm unfortunately not familiar enough with
that pass.
Before ivopts we have:
[local count: 8687547547]:
# i_2 = PHI
# ivtmp_19 = PHI
saved_stack.2_4 = __builtin_stack_save ();
foo ();
_6 = (sizetype) i_2;
_7 = _6 * 4;
y.1_8 = __builtin_alloca_with_align (_7, 32);
MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: _6 * 4}[i_2]
= 0;
__builtin_stack_restore (saved_stack.2_4);
i_10 = i_2 + 1;
ivtmp_11 = ivtmp_19 - 1;
if (ivtmp_11 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 7731917322]:
goto ; [100.00%]
loop and ivopts decides to create a new unsigned long ivtmp.9 IV going from
0 with step 1. But it doesn't properly adjust the ARRAY_REF with sz:, so it
keeps referencing a freed SSA_NAME _6:
[local count: 8687547547]:
# ivtmp.9_5 = PHI
_20 = (unsigned int) ivtmp.9_5;
i_2 = (int) _20;
saved_stack.2_4 = __builtin_stack_save ();
foo ();
_3 = ivtmp.9_5 * 4;
_7 = _3;
y.1_8 = __builtin_alloca_with_align (_7, 32);
MEM [(int[1][0:D.1996] *)y.1_8][5]{lb: 0 sz: <<< error
>>>}[i_2] = 0;
__builtin_stack_restore (saved_stack.2_4);
ivtmp.9_9 = ivtmp.9_5 + 1;
if (ivtmp.9_9 != 5)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 7731917322]:
goto ; [100.00%]
I believe it should use ivtmp.9_5 (printed as ivtmp.9_5 * 4).
[Bug jit/104071] Add support for bitcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 David Malcolm changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/jit/2022q1/001475.html --- Comment #1 from David Malcolm --- Latest version of patch seems to be: https://gcc.gnu.org/pipermail/jit/2022q1/001475.html
[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 --- Comment #3 from Richard Biener --- Created attachment 52748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52748=edit patch
[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I have a patch.
[Bug c/105148] [11/12 Regression] ICE in verify_use, at tree-ssa.cc:881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105148
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
extern void foo (void);
static inline int
bar (int n)
{
for (int i = 0; i < n; i++)
{
foo ();
int y[1][i];
y[n][i] = 0;
}
}
int
baz (void)
{
return bar (5);
}
[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|ftree-ccp drops DWARF const |ftree-ccp (CFG cleanup) |value attribute at |drops DWARF const value |-Og/-O1/-O2/-O3 |attribute at ||-Og/-O1/-O2/-O3 Severity|normal |enhancement Last reconfirmed||2022-04-05 --- Comment #1 from Richard Biener --- The issue is that the definition we put the debug stmt into is in : [t.c:4:5] # DEBUG BEGIN_STMT [t.c:4:16] # DEBUG l_174 => 0 [t.c:4:27] # DEBUG l_188 => 0 [t.c:4:38] # DEBUG l_191 => 0 [t.c:4:49] # DEBUG l_240 => 1 [t.c:5:5] # DEBUG BEGIN_STMT [t.c:6:5] # DEBUG BEGIN_STMT [t.c:6:20] # DEBUG l_169 => 0 [t.c:6:25] if (0 != 0) goto ; [INV] else goto ; [INV] : : [t.c:6:11] # DEBUG l_171 => 0 [t.c:7:5] # DEBUG BEGIN_STMT [t.c:7:5] goto ; [INV] : # l_169_3 = PHI <[t.c:6:20] 0(6), [t.c:7:30] l_169_19(7)> # DEBUG l_169 => l_169_3 [t.c:7:18] # DEBUG BEGIN_STMT [t.c:7:18] if (l_169_3 <= 9) goto ; [INV] else goto ; [INV] and when CFG cleanup merges all the forwarders it finds no location to put the debug stmt to - it tries to move the debug stmts to the successor but that doesn't have a single predecessor so that's not a valid thing to do. Moving to the predecessor would be valid if that has a single successor though but that's not implemented. In this case the predecessor is block 2 at the point in question and it has a single successor plus the last stmt in it doesn't end the BB.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #9 from Jakub Jelinek --- Besides missing AMD response, it isn't fully fixed, because the change is on the libatomic side only. So we still pay the cost to call those functions (and often PLT cost too) and return from them. For GCC 13, we should add some option that optionally reverts the change to use library calls all the time, and default that option for -march= Intel CPUs with AVX support or something similar (perhaps only if AVX is also enabled).
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #8 from Xi Ruoyao --- Shall I close it as FIXED, or keep it opening waiting for AMD response?
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
--- Comment #3 from Richard Biener ---
Hmm, we ignore inlined edges during propagation!?
for (cgraph_edge *callee_edge = cur->callees; callee_edge;
callee_edge = callee_edge->next_callee)
{
int flags = flags_from_decl_or_type (callee_edge->callee->decl);
modref_summary *callee_summary = NULL;
modref_summary_lto *callee_summary_lto = NULL;
struct cgraph_node *callee;
if (!callee_edge->inline_failed
|| ((flags & (ECF_CONST | ECF_NOVOPS))
&& !(flags & ECF_LOOPING_CONST_OR_PURE)))
continue;
but we also ignore calls during local analysis in IPA mode. Where are we
supposed to factor in flags from inline clones? Is the IPA inline pass
supposed to update summaries somehow?
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
The odd thing is that during IPA propagation (modref_propagate_in_scc), the
summary of sctlr_read is
(gdb) p *cur_summary
$2 = {loads = 0x7665af00, stores = 0x7665af10,
kills = {> = {
m_vec = 0x0}, },
arg_flags = {> = {
m_vec = 0x0}, }, retslot_flags = 0,
static_chain_flags = 0, writes_errno = 0, side_effects = 0,
nondeterministic = 0, calls_interposable = 0, load_accesses = 0,
global_memory_read = 0, global_memory_written = 0, try_dse = 1}
which is because we access the summary of cur->inlined_to (sctlr_rmw) here
but that hasn't been processed. But the non-inlined node doesn't have a
summary.
So somehow we fail to merge the info from the inlined clones?
But even using ->clone_of instead of ->inlined_to doesn't make a difference
(no summary for that node either).
Something is wrong. Honza?
[Bug ipa/105160] [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |12.0
Last reconfirmed||2022-04-05
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
Agreed, 'volatile' is documented as
@item volatile
The typical use of extended @code{asm} statements is to manipulate input
values to produce output values. However, your @code{asm} statements may
also produce side effects. If so, you may need to use the @code{volatile}
qualifier to disable certain optimizations. @xref{Volatile}.
so for the side-effects the asms should make the functions non-pure/const.
[Bug ipa/105160] New: [12 regression] ipa modref marks functions with asm volatile as const or pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160
Bug ID: 105160
Summary: [12 regression] ipa modref marks functions with asm
volatile as const or pure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
the following code is miscompiled with gcc -O1
#define sysreg_read(regname)\
({ \
unsigned long __sr_val; \
asm volatile( \
"mrs %0, " #regname "\n"\
: "=r" (__sr_val)); \
\
__sr_val; \
})
#define sysreg_write(regname, __sw_val) \
do {\
asm volatile( \
"msr " #regname ", %0\n"\
: \
: "r" (__sw_val)); \
} while (0)
#define isb() \
do {\
asm volatile( \
"isb" \
: \
: \
: "memory");\
} while (0)
static unsigned long sctlr_read(void)
{
return sysreg_read(sctlr_el1);
}
static void sctlr_write(unsigned long val)
{
sysreg_write(sctlr_el1, val);
}
static void sctlr_rmw(void)
{
unsigned long val;
val = sctlr_read();
val |= 1UL << 7;
sctlr_write(val);
}
void sctlr_read_multiple(void)
{
sctlr_read();
sctlr_read();
sctlr_read();
sctlr_read();
}
void sctlr_write_multiple(void)
{
sctlr_write(0);
sctlr_write(0);
sctlr_write(0);
sctlr_write(0);
sctlr_write(0);
}
void sctlr_rmw_multiple(void)
{
sctlr_rmw();
sctlr_rmw();
sctlr_rmw();
sctlr_rmw();
}
void function(void)
{
sctlr_read_multiple();
sctlr_write_multiple();
sctlr_rmw_multiple();
isb();
}
aarch64-linux-gnu-gcc -O1 compiles it to
(note 'function' and 'sctlr_rmw_multiple'):
sctlr_rmw:
mrs x0, sctlr_el1
orr x0, x0, 128
msr sctlr_el1, x0
ret
sctlr_read_multiple:
mrs x0, sctlr_el1
mrs x0, sctlr_el1
mrs x0, sctlr_el1
mrs x0, sctlr_el1
ret
sctlr_write_multiple:
mov x0, 0
msr sctlr_el1, x0
msr sctlr_el1, x0
msr sctlr_el1, x0
msr sctlr_el1, x0
msr sctlr_el1, x0
ret
sctlr_rmw_multiple:
ret
function:
isb
ret
a similar issue in linux (but lager source file) got bisected to
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=1b62cddcf091fb8cadf575246a7d3ff778650a6b
commit 1b62cddcf091fb8cadf575246a7d3ff778650a6b
Author: Jan Hubicka
Date: Fri Nov 12 14:00:47 2021 +0100
Fix ipa-modref pure/const discovery
PR ipa/103200
* ipa-modref.c (analyze_function, modref_propagate_in_scc): Do
not mark pure/const function if there are side-effects.
with -fdump-ipa-all
$ grep found t.c.087i.modref
Function found to be const: sctlr_rmw/2
Function found to be const: sctlr_read_multiple/3
Function found to be const: sctlr_write_multiple/4
Function found to be const: sctlr_rmw_multiple/5
even though t.c.086i.pure-const correctly identifies asm volatile
as not const/pure.
[Bug d/104740] gdc.dg/simd_ctfe.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104740 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Iain Buclaw --- > I think all are covered now. Yes and no: while the test is now UNSUPPORTED on SPARC, it also became UNSUPPORTED on x86 (both 32 and 64-bit) where it previously PASSed. ISTM the requirements have become too strict now.
[Bug sanitizer/105155] -fsanitize=signed-integer-overflow failed to check an overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105155
--- Comment #3 from Jakub Jelinek ---
-fsanitize=signed-integer-overflow
currently instruments (unlike e.g. the shift or division instrumentation) only
what falls through unfolded from the early passes (generic folding,
gimplification and up to switching into ssa form), with some
!TYPE_OVERFLOW_SANITIZED checks in match.pd; the reason for that is that there
are simply way too many spots in the FE that produce the arithmetics and we
need to ensure that sanitization doesn't break constant expressions.
We don't even instrument
int bar (int a) { return __INT_MAX__ + 1; }
but do:
int baz (int a) { int x = __INT_MAX__; return x + 1; }
(but there is a warning in the bar case).
E.g. to instrument it even in bar, we'd need to change e.g. in the C FE:
/* Treat expressions in initializers specially as they can't trap. */
if (int_const_or_overflow)
ret = (require_constant_value
? fold_build2_initializer_loc (location, resultcode, build_type,
op0, op1)
: fold_build2_loc (location, resultcode, build_type, op0, op1));
else
ret = build2 (resultcode, build_type, op0, op1);
such that if for the int_const_or_overflow && !require_constant_value case
ret has TREE_OVERFLOW on it and signed-integer-overflow is enabled, we'd
do build2 instead.
[Bug debug/105159] New: -fipa-reference-addressable causes drop of DWARF location info at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105159
Bug ID: 105159
Summary: -fipa-reference-addressable causes drop of DWARF
location info at -Og
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dc.delia at protonmail dot com
Target Milestone: ---
In this code, pointer variable l_515 assigned at line 4 appears as optimized
out at line 6 during source-level debugging, then the newly assigned value at
line 7 is available at line 8. This happens with -Og where
-fipa-reference-addressable makes the involved DWARF location information go
away but the compiled code stays the same. By disabling this option, the value
from line 4 becomes visible too.
We found this issue on gcc commit 500d3f0a302 on an x64 target using gdb 11.2,
while on prior gcc versions the behavior is either the same or the variable is
marked as optimized out the whole time.
$ cat -n a.c
int a, b;
static char c, d;
void foo() {
char *l_515 =
char **f = _515;
b++;
*f =
d = 0;
}
int main() {
foo();
a = c;
}
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x400486: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/57/reduce/opt
Breakpoint 1, foo () at a.c:6
6 b++;
(gdb) info locals
l_515 =
f =
(gdb) n
8 d = 0;
(gdb) info locals
l_515 = 0x601034 ""
f =
Compiled code of foo function:
00400486 :
400486: 83 05 9f 0b 20 00 01addl $0x1,0x200b9f(%rip)#
60102c
40048d: c6 05 a0 0b 20 00 00movb $0x0,0x200ba0(%rip)#
601034
400494: c3 retq
The first two instructions of function foo are associated with line 6 and 8,
respectively.
DWARF at -Og:
0x00cc: DW_TAG_variable
DW_AT_name("l_515")
DW_AT_decl_file ("/home/stepping/57/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x09)
DW_AT_type(0x00f3 "char*")
DW_AT_location(0x000e:
[0x0040048d, 0x00400494): DW_OP_addr
0x601034, DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
In the DWARF information, there is only one location entry associated with the
instruction at 40048d which is mapped to line 8.
We found out that the optimization that makes the variable disappear is likely
-fipa-reference-addressable. After disabling it, when stepping at line 6 we can
now see the value of pointer l_515, since a new entry appeared in the list in
the DWARF location info of l_515 and is associated with the instruction at
400486, which is mapped to line 6.
DWARF at -Og with -fno-ipa-reference-addressable:
0x00d2: DW_TAG_variable
DW_AT_name("l_515")
DW_AT_decl_file ("/home/stepping/57/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x09)
DW_AT_type(0x00f9 "char*")
DW_AT_location(0x0010:
[0x00400486, 0x0040048d): DW_OP_addr
0x601035, DW_OP_stack_value
[0x0040048d, 0x00400494): DW_OP_addr
0x601034, DW_OP_stack_value)
DW_AT_GNU_locviews(0x000c)
This is what we found for a selection of prior gcc versions:
- 6.4, 7.5, 8.4, 9.3: l_515 is marked as optimized out the whole time and DWARF
location info is missing entirely
- 10.3, 11.1: the behavior is like the 500d3f0a302 git version that we tested
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #43 from Mikael Morin --- I’m working on it.
[Bug debug/105158] New: ftree-ccp drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158
Bug ID: 105158
Summary: ftree-ccp drops DWARF const value attribute at
-Og/-O1/-O2/-O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dc.delia at protonmail dot com
Target Milestone: ---
In this code, variable l_171 is displayed optimized out at every stepped line
when debugging, including line 10 where it is used as a call argument to an
externally defined function. We tested with -Og/O1/O2/O3 and the issue is
present at all these levels.
Apparently, -ftree-ccp drops the const value attribute in the DWARF DIE for
l_171 while the final compiled code stays the same. By turning it off, the
debugger can display the value of the variable.
We found this issue on gcc commit 500d3f0a302 using gdb 11.2 and the behavior
seems consistent with prior gcc versions (e.g., 6.4, 7.5, 8.4, 9.3, 10.3,
11.1).
$ cat a.c
int a;
void b()
{
int l_169, l_174 = 0, l_188 = 0, l_191 = 0, l_240 = 1;
short l_171 ;
l_171 = (l_169 = 0) && a;
for (; l_169 <= 9; l_169 = l_169 + 3)
{
int l_187 = 0, l_189 = 0, l_190 = 8;
test(l_169, l_171, l_174, l_188, l_191, l_240, l_187, l_189, l_190);
}
}
int main ()
{
b();
}
$ cat lib.c
#include
void test(int l_169, int l_171, int l_174, int l_188, int l_191, int l_240, int
l_187, int l_189, int l_190) {
printf("%d %d %d %d %d %d %d %d %d", l_169, l_171, l_174, l_188, l_191,
l_240, l_187, l_189, l_190);
}
GDB trace:
$ gcc -O1 -g a.c lib.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 10
Breakpoint 1 at 0x4004fc: file a.c, line 10.
(gdb) r
Starting program: /tmp/opt
Breakpoint 1, b () at a.c:10
10 test(l_169, l_171, l_174, l_188, l_191, l_240, l_187, l_189,
l_190);
(gdb) info locals
l_187 = 0
l_189 = 0
l_190 = 8
l_169 = 0
l_174 = 0
l_188 = 0
l_191 = 0
l_240 = 1
l_171 =
Code at -O1:
004004f6 :
4004f6: 53 push %rbx
4004f7: bb 00 00 00 00 mov$0x0,%ebx
4004fc: 48 83 ec 08 sub$0x8,%rsp
400500: 6a 08 pushq $0x8
400502: 6a 00 pushq $0x0
400504: 6a 00 pushq $0x0
400506: 41 b9 01 00 00 00 mov$0x1,%r9d
40050c: 41 b8 00 00 00 00 mov$0x0,%r8d
400512: b9 00 00 00 00 mov$0x0,%ecx
400517: ba 00 00 00 00 mov$0x0,%edx
40051c: be 00 00 00 00 mov$0x0,%esi
400521: 89 df mov%ebx,%edi
400523: b8 00 00 00 00 mov$0x0,%eax
400528: e8 26 00 00 00 callq 400553
40052d: 83 c3 03add$0x3,%ebx
400530: 48 83 c4 20 add$0x20,%rsp
400534: 83 fb 0ccmp$0xc,%ebx
400537: 75 c3 jne4004fc
400539: 5b pop%rbx
40053a: c3 retq
The code at higher optimization levels is very similar, besides where strength
reduction, we suppose, kicks in (e.g. mov $0, %edi => xor %edi, %edi).
DWARF at -O1:
0x00e8: DW_TAG_variable
DW_AT_name("l_171")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x0b)
DW_AT_type(0x0167 "short int")
If we add -fno-tree-ccp to the compilation command line used above, the code of
function b remains unchanged but the DWARF const value information is preserved
for the variable, meaning its value 0 is visible when debugging throughout its
whole lifetime.
DWARF at -O1 with -fno-tree-ccp:
0x00e8: DW_TAG_variable
DW_AT_name("l_171")
DW_AT_decl_file ("/tmp/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x0b)
DW_AT_type(0x0167 "short int")
