[Bug driver/115440] unrecognized command-line option '--c++17'; did you mean '--stdc++17'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115440
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Untested fix:
--- gcc/opts-common.cc.jj 2024-05-21 10:19:35.694512065 +0200
+++ gcc/opts-common.cc 2024-06-11 23:10:43.428656210 +0200
@@ -524,6 +524,7 @@ add_misspelling_candidates (auto_vecsafe_push (alternative);
}
}
In my limited understanding, if opt1 is non-NULL in option_map, so the
{ "--machine", "", "-m", false, false },
{ "--machine", "no-", "-m", false, true },
...
{ "--std", "", "-std=", false, false },
entries, I think that is about mapping --machine foobar to -mfoobar or
--machine no-foobar to -mfoobar or --std foobar to -std=foobar
We do accept --std c++17 with the same meaning as -std=c++17 but just don't add
the space in between because opt1 is for the case where the option is present
as two separate options.
[Bug c/105863] RFE: C23 #embed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Working on this now.
[Bug middle-end/110027] [11 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 regression] Stack|[11 regression] Stack |objects with extended |objects with extended |alignments (vectors etc)|alignments (vectors etc) |misaligned on |misaligned on |detect_stack_use_after_retu |detect_stack_use_after_retu |rn |rn --- Comment #28 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug c++/114580] Bogus warning on if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580 --- Comment #7 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug c++/114537] bit_cast does not work NSDMI of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537 --- Comment #8 from Jakub Jelinek --- Should be fixed for 12.4+ and 13.4+ too.
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 --- Comment #11 from Jakub Jelinek --- Should be fixed for 12.4+, 13.4+ and 14.2+ too.
[Bug c/114493] [11 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11 Regression] internal |internal compiler error: in |compiler error: in |fld_incomplete_type_of with |fld_incomplete_type_of with |may_alias |may_alias --- Comment #16 from Jakub Jelinek --- Should be fixed for 12.4+ and 13.4+ too.
[Bug tree-optimization/114876] [11 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] |-fprintf-return-value |-fprintf-return-value |mishandles %lc with a '\0' |mishandles %lc with a '\0' |argument. |argument. --- Comment #12 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug target/115324] [12/13 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Should be fixed for 12.4+ and 13.4+ too.
[Bug sanitizer/114956] [11 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] |Segmentation fault with |Segmentation fault with |-fsanitize=address |-fsanitize=address |-fsanitize=null -O2 when|-fsanitize=null -O2 when |attribute |attribute |no_sanitize_address is |no_sanitize_address is |enabled since r9-5742 |enabled since r9-5742 --- Comment #10 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug c++/114691] [11 Regression] Bogus ignoring loop annotation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] Bogus|[11 Regression] Bogus |ignoring loop annotation|ignoring loop annotation |warning |warning --- Comment #7 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768 --- Comment #13 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug fortran/114825] [11 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] Compiler |[11 Regression] Compiler |error using gfortran and|error using gfortran and |OpenMP since r5-1190|OpenMP since r5-1190 --- Comment #10 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug middle-end/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753 --- Comment #13 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug c++/114634] [11 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] Crash|[11 Regression] Crash Issue |Issue Encountered in GCC|Encountered in GCC |Compilation of Template |Compilation of Template |Code with Aligned Attribute |Code with Aligned Attribute |since r9-1745 |since r9-1745 --- Comment #9 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572 --- Comment #8 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug tree-optimization/114566] [11 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] Misaligned |Misaligned vmovaps when |vmovaps when compiling with |compiling with |stack-protector-strong for |stack-protector-strong for |znver4 |znver4 | --- Comment #21 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533 --- Comment #16 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug target/114310] [11 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114310 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] [aarch64] |[aarch64] |__sync_val_compare_and_swap |__sync_val_compare_and_swap |fails on __int128_t with |fails on __int128_t with|newval = 0 |newval = 0 | --- Comment #10 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug rtl-optimization/110079] [11 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE with |[11 Regression] ICE with |-freorder-blocks-and-partit |-freorder-blocks-and-partit |ion and inline-asm goto |ion and inline-asm goto --- Comment #10 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug target/114184] [12 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with _Complex long double and vector VCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114184 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #32 from Jakub Jelinek --- Should be fixed for 12.4+ too (the same way as for 13.3).
[Bug c++/113674] [11 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] |[[attr]] causes |[[attr]] causes |internal compiler error: in |internal compiler error: in |decl_attributes, at |decl_attributes, at |attribs.cc:776 |attribs.cc:776 --- Comment #12 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug target/113122] Assembler messages: Error: operand type mismatch for `movabs' / bad expression / invalid use of register with -fprofile -mcmodel=large -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113122 --- Comment #6 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug tree-optimization/113603] [12 Regression] ICE Segfault during GIMPLE pass: strlen at -O3 since r12-145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113603 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug middle-end/110115] [11 Regression] Wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] Wrong|[11 Regression] Wrong code |code at -O1 on |at -O1 on x86_64-linux-gnu |x86_64-linux-gnu| --- Comment #11 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug middle-end/90348] [11 Regression] Partition of char arrays is incorrect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] Partition |Partition of char arrays is |of char arrays is incorrect |incorrect in some cases |in some cases --- Comment #35 from Jakub Jelinek --- Should be worked around for 12.4+ too.
[Bug libgomp/113192] [11 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ERROR: |[11 Regression] ERROR: |couldn't execute|couldn't execute |"../../../gcc/libgomp/tests |"../../../gcc/libgomp/tests |uite/flock": no such file |uite/flock": no such file |or directory|or directory Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-06-11 Ever confirmed|0 |1 --- Comment #13 from Jakub Jelinek --- Should be fixed for 12.4+ too.
[Bug c/113262] [11 Regression] ICE when using [[gnu::copy("")]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12 Regression] ICE when |[11 Regression] ICE when
|using [[gnu::copy("")]] |using [[gnu::copy("")]]
|attribute |attribute
--- Comment #9 from Jakub Jelinek ---
Should be fixed for 12.4+ too.
[Bug middle-end/115405] wrong code with _BitInt() sign-extension with -fno-strict-aliasing -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115405
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The IL before expansion doesn't have a VCE, just
MEM[(_BitInt(17) *)]
where b has unsigned _BitInt(17) type.
Then
/* Handle expansion of non-aliased memory with non-BLKmode. That
might end up in a register. */
if (mem_ref_refers_to_non_mem_p (exp))
{
poly_int64 offset = mem_ref_offset (exp).force_shwi ();
base = TREE_OPERAND (base, 0);
poly_uint64 type_size;
if (known_eq (offset, 0)
&& !reverse
&& poly_int_tree_p (TYPE_SIZE (type), _size)
&& known_eq (GET_MODE_BITSIZE (DECL_MODE (base)), type_size))
return expand_expr (build1 (VIEW_CONVERT_EXPR, type, base),
target, tmode, modifier);
in expr.cc turns that into a VCE.
And VCE doesn't really EXTEND_BITINT because the upper bits generally in a VCE
are undefined.
Finally the NOP_EXPR expansion sees a SImode signed _BitInt(17) extension to
SImode 32-bit int and assumes for something in an automatic var to be already
properly extended.
Dunno where the bug is, whether trying to use VCE for the _BitInt cases as in
the snippet above, or VCE not doing EXTEND_BITINT, or NOP_EXPR handling that
should extend even in this case.
[Bug c/115374] fmod() in x86_64 -O3 not using return value from the glibc's implementation if x87 FPU fprem returns NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115374 --- Comment #13 from Jakub Jelinek --- The bug is mixing MMX with floating point and expecting it to work, it will never work properly, you need manual emms in between, or better yet, avoid MMX altogether, it really isn't worth it. Just use SSE and higher.
[Bug c/115374] fmod() in x86_64 -O3 not using return value from the glibc's implementation if x87 FPU fprem returns NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115374 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- (In reply to Mario Hros from comment #10) > That _.265t.optimized posted matches my observation. So the call into glibc > fmod() is made to set errno eventually, ok. But shouldn't the returned value > from the glibc call be used instead of returning NaN? Why? We know the result should be NaN and we have a NaN from the inline fmod expansion. The glibc call is purely to set errno.
[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115352 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed, thanks for the report.
[Bug c/114493] [11/12/13 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Summary|[11/12/13/14/15 Regression] |[11/12/13 Regression] |internal compiler error: in |internal compiler error: in |fld_incomplete_type_of with |fld_incomplete_type_of with |may_alias |may_alias Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Should be fixed now for 14.2+ and 15+ for now.
[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115352 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 58368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58368=edit gcc15-pr115352.patch Full so far just lightly tested patch.
[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115352
--- Comment #2 from Jakub Jelinek ---
I've first tried
--- gcc/gimple-lower-bitint.cc.jj 2024-04-12 10:59:48.233153262 +0200
+++ gcc/gimple-lower-bitint.cc 2024-06-06 11:05:29.845597763 +0200
@@ -4324,7 +4324,8 @@ bitint_large_huge::lower_addsub_overflow
else
g = gimple_build_assign (this_ovf, NE_EXPR, l, cmp);
insert_before (g);
- if (cmp_code == GT_EXPR)
+ if (cmp_code == GT_EXPR
+ || (cmp_code == GE_EXPR && single_comparison))
{
tree t = make_ssa_name (boolean_type_node);
g = gimple_build_assign (t, BIT_IOR_EXPR, ovf, this_ovf);
which fixes the #c0 testcase. But on the reduced
int
foo (_BitInt (385) b)
{
return __builtin_sub_overflow_p (0, b, (_BitInt (65)) 0);
}
int
main ()
{
if (!foo (-(_BitInt (385))
0x0c377e8a3fd1881fff035bb487a51c9ed1f7350befa7ec445a3cf8d1ebb723981wb))
__builtin_abort ();
if (!foo
(-0x1c377e8a3fd1881fff035bb487a51c9ed1f7350befa7ec445a3cf8d1ebb723981uwb))
__builtin_abort ();
if (!foo (-(_BitInt (385))
0x0a3cf8d1ebb723981wb))
__builtin_abort ();
if (!foo
(-0x1a3cf8d1ebb723981uwb))
__builtin_abort ();
}
testcase it only fixes the first 2 calls but not the last 2.
So, I'm afraid I just need to kill the optimization instead:
--- gcc/gimple-lower-bitint.cc.jj 2024-04-12 10:59:48.233153262 +0200
+++ gcc/gimple-lower-bitint.cc 2024-06-06 12:06:57.065717651 +0200
@@ -4286,11 +4286,7 @@ bitint_large_huge::lower_addsub_overflow
bool single_comparison
= (startlimb + 2 >= fin || (startlimb & 1) != (i & 1));
if (!single_comparison)
- {
- cmp_code = GE_EXPR;
- if (!check_zero && (start % limb_prec) == 0)
- single_comparison = true;
- }
+ cmp_code = GE_EXPR;
else if ((startlimb & 1) == (i & 1))
cmp_code = EQ_EXPR;
else
The idea behind the optimization was that arith_overflow_extract_bits in those
cases is the same, we just extract all bits from the limb, whether it is the
limb at the boundary (i.e. EQ_EXPR to the compared limb index) or above
(GT_EXPR), so GE_EXPR would do. Except without the first patch it completely
ignored the previously accumulated mismatches (i.e. overflows) from lower
limbs, and while that no longer is the case with the first patch, it still
ignores whether the upper bits were all 0s or all 1s previously and as long as
they are again all 0s or all 1s, it happily makes it non-overflow case and what
the next limb should compare against.
[Bug libgomp/115367] The implementation of OMP_DYNAMIC is not dynamic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115367 --- Comment #1 from Jakub Jelinek --- (In reply to Niklas Hambüchen from comment #0) > Those docs sound like the behaviour is nice "runtime-dynamic" when in fact > it is fixed across the process's liftime, and based on ultra-slow rolling > averages. That is not the case. It really calls getloadavg each time when trying to determine the number of threads and uses the 15min average then. Using say 1min average is IMHO highly undesirable for decisions in a program that usually will last longer than that.
[Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345 --- Comment #8 from Jakub Jelinek --- Also, if building with GCC 11 works and with GCC 12 doesn't, can you build two trees, one with either compiler and then bisect first among the shared libraries or binaries (find out which shared library or binary is affected), among the static libraries (GCC 11 and 12 ought to be ABI compatible, so try linking some *.a libraries from one build and other from another build, among the object files (start with linking half of the objects built by one compiler and another half by another compiler and depending on if it works as expected or not change the set of objects to link). If you get to one object file which when compiled with GCC 11 works even when everything else has been compiled with GCC 12 or vice versa, you can then try different options on that one (e.g. the -fno-strict-aliasing Andrew mentioned, -O0 etc.), and/or bisect inside of the source using #pragma GCC optimize(0) etc. Anyway, if there is a single translation unit like that and ideally if you find out which function is problematic, trying to stub functions it calls and add a caller which calls that single function with the right arguments turns it into a self-contained reproducer.
[Bug c/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-06-04 Summary|[12/13/14 REGRESSION] / |[12/13/14/15 Regression] |Different outputs compared |Different outputs compared |to GCC 11- and MSVC/Clang |to GCC 11- and MSVC/Clang Status|UNCONFIRMED |WAITING CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Please see https://gcc.gnu.org/bugs/ for what we need, we need a self-contained preprocessed testcase, which you haven't provided. You should start by compiling the code with -fsanitize=undefined and/or -fsanitize=address, see if it reports anything, if not, create a minimal self-contained reproducer.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #12 from Jakub Jelinek --- Should be fixed now. I think we want to backport the fold-const.cc first patch to older branches too, but it will be different there.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- .
[Bug target/115324] [12/13 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13 Regression] PCH of |PCH of rs6000 builtins |rs6000 builtins broken |broken | --- Comment #5 from Jakub Jelinek --- Should be fixed for 14.2+/15.1+ for now.
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 Bug 115092 depends on bug 114902, which changed state. Bug 114902 Summary: [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/114902] [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Jakub Jelinek --- Fixed.
[Bug c++/110137] implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #12 from Jakub Jelinek ---
Is the option supposed to be only about the standard global scope operator
new/delete (_Znam etc.) or also user operator new/delete class methods? If the
former, then I agree it is a global property (or at least a per shared
library/binary property, one can arrange stuff with symbol visibility etc.).
Otherwise it is a property of whatever operator new/delete you call.
I think DECL_IS_OPERATOR_{NEW,DELETE} is set on both of these, the standard
ones have
also DECL_IS_REPLACEABLE_OPERATOR flag on them.
Anyway, handling this just in IRA doesn't seem to be enough, surely it should
be also handled during alias analysis etc.
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Jakub Jelinek --- Fixed for 15.1+ so far.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #7 from Jakub Jelinek --- Created attachment 58342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58342=edit gcc15-pr115337-4.patch And finally, I think tree_call_expr_nonzero can handle CTZ the same as CLZ now.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #6 from Jakub Jelinek --- Created attachment 58341 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58341=edit gcc15-pr115337-3.patch Improve ranger handling of .CLZ (x, -1). As the stdbit.h builtins now use that value, it is worth special casing it in the CLZ handling, so that we get e.g. [-1, 128] range rather than VARYING.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #5 from Jakub Jelinek --- Created attachment 58340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58340=edit gcc15-pr115337-2.patch Fixes for some formatting issues I found during the debugging.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #4 from Jakub Jelinek --- Created attachment 58339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58339=edit gcc15-pr115337-1.patch Untested fix.
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- cfn_clz::fold_range is actually correct (but given the use of -1 second argument perhaps could special case that case too). What is wrong is tree_call_nonnegative_warnv_p.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #10 from Jakub Jelinek --- Created attachment 58337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58337=edit gcc15-pr114493.patch Untested fix.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #9 from Jakub Jelinek --- That was added for C++ in PR70512.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
This doesn't ICE in C++, because the C++ FE forcibly updates the corresponding
pointer types in:
#0 fixup_may_alias (klass=) at
../../gcc/cp/class.cc:2328
#1 0x00456835 in fixup_attribute_variants (t=) at ../../gcc/cp/class.cc:2354
#2 0x006f3024 in cp_parser_class_head (parser=0x7fffea2dea80,
nested_name_specifier_p=0x7fffd5ff) at ../../gcc/cp/parser.cc:27831
/* KLASS is a class that we're applying may_alias to after the body is
parsed. Fixup any POINTER_TO and REFERENCE_TO types. The
canonical type(s) will be implicitly updated. */
static void
fixup_may_alias (tree klass)
{
tree t, v;
for (t = TYPE_POINTER_TO (klass); t; t = TYPE_NEXT_PTR_TO (t))
for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
TYPE_REF_CAN_ALIAS_ALL (v) = true;
for (t = TYPE_REFERENCE_TO (klass); t; t = TYPE_NEXT_REF_TO (t))
for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
TYPE_REF_CAN_ALIAS_ALL (v) = true;
}
Now, fixup_attribute_variants also does:
for (variants = TYPE_NEXT_VARIANT (t);
variants;
variants = TYPE_NEXT_VARIANT (variants))
{
/* These are the two fields that check_qualified_type looks at and
are affected by attributes. */
TYPE_ATTRIBUTES (variants) = attrs;
unsigned valign = align;
if (TYPE_USER_ALIGN (variants))
valign = MAX (valign, TYPE_ALIGN (variants));
else
TYPE_USER_ALIGN (variants) = user_align;
SET_TYPE_ALIGN (variants, valign);
TYPE_PACKED (variants) = packed;
if (may_alias)
fixup_may_alias (variants);
}
I think the TYPE_ATTRIBUTES update isn't needed, because
decl_attributes (, attributes, (int) ATTR_FLAG_TYPE_IN_PLACE);
should update the variants already:
984 TYPE_ATTRIBUTES (*anode) = r;
985 /* If this is the main variant, also push the
attributes
986 out to the other variants. */
987 if (*anode == TYPE_MAIN_VARIANT (*anode))
988 {
989 for (tree variant = *anode; variant;
990variant = TYPE_NEXT_VARIANT (variant))
991 {
992 if (TYPE_ATTRIBUTES (variant) == old_attrs)
993 TYPE_ATTRIBUTES (variant)
994 = TYPE_ATTRIBUTES (*anode);
995 else if (!find_same_attribute
996(attr, TYPE_ATTRIBUTES (variant)))
997 TYPE_ATTRIBUTES (variant) = tree_cons
998 (name, args, TYPE_ATTRIBUTES (variant));
999 }
1000}
Seems finish_struct doesn't actually call layout_type on the type variants,
wonder what does that, but I'd think that stuff like TYPE_USER_ALIGN,
TYPE_ALIGN would be finalized when layout_type is performed for those.
TYPE_PACKED is apparently done in
finish_record_layout even for the variants (called from layout_type).
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Jakub Jelinek changed: What|Removed |Added CC||mr.bossman075 at gmail dot com --- Comment #13 from Jakub Jelinek --- *** Bug 115332 has been marked as a duplicate of this bug. ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 --- Comment #3 from Jakub Jelinek --- Oops. *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 44268 ***
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268 Jakub Jelinek changed: What|Removed |Added CC||mr.bossman075 at gmail dot com --- Comment #11 from Jakub Jelinek --- *** Bug 115332 has been marked as a duplicate of this bug. ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- It behaves exactly as designed. There needs to be an edge in the control flow graph to the label, if there isn't, even when the label is referenced in some & computed value, it can't be validly called and thus the label becomes a "deleted label" and can move anywhere in the function.
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 58336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58336=edit gcc15-pr108789.patch Untested fix.
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 --- Comment #4 from Jakub Jelinek --- Note, fold_builtin_arith_overflow just does tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2, arg0, arg1); tree tgt = save_expr (call); and then uses tgt twice, so it is save_expr decision whether it can be evaluated twice or needs to be done once. And save_expr adds SAVE_EXPR only to the second case when it sees non-const VAR_DECLs, in the first case the arguments are TREE_READONLY and so the ifn call is as well and so causes tree_invariant_p_1 to return true.
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 --- Comment #2 from Jakub Jelinek --- I think this is just invalid testcase. The compiler is told that *a is const, but it is changed through a different lvalue.
[Bug target/115324] [12/13/14/15 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324 --- Comment #2 from Jakub Jelinek --- Created attachment 58331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58331=edit gcc15-pr115324.patch Untested fix.
[Bug target/115324] [12/13/14/15 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |12.4
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
|PCH (and maybe GC) of |PCH of rs6000 builtins
|rs6000 builtins broken |broken
Ever confirmed|0 |1
Last reconfirmed||2024-06-03
--- Comment #1 from Jakub Jelinek ---
While for GC everything looks ok, in particular we have
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided so that they cover just the fntype fields in
rs6000_instance_info and rs6000_builtin_info, it causes problems for PCH,
because
PCH saves/restores the whole rs6000_instance_info/rs6000_builtin_info arrays,
which are huge and worse the contain quite a lot of pointers to .rodata/.data
sections besides the tree fntype members.
In struct bifdata it is
const char *GTY((skip(""))) bifname;
...
const char *GTY((skip(""))) attr_string;
and in struct ovlddata
const char *GTY((skip(""))) bifname;
...
ovlddata *GTY((skip(""))) next;
fields. bifname and attr_string members point to string literals, so .rodata
section,
and next is either NULL or _instance_info[RS6000_INST_XXX]
Now, the problem is when cc1/cc1plus etc. are PIEs, the saving is done when
.rodata/.data sections are loaded at one address, but the restoring can be done
when they are loaded at different address, so the pointers are garbage after
PCH restore.
We could extend GTY, to have a similar flag to callback where we'd somehow fix
up those pointers in global GTY roots.
Or I think we can just move the fntype members from those structures to
separate arrays, making the original arrays non-GTY and only GTY the new
*_fntype arrays.
I've implemented the latter, will attach it momentarily.
It seems to decrease the size of .data arrays.
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
On a cross from x86_64 -> powerpc64le it increases .text size in the
_Z30rs6000_init_generated_builtinsv function, but will need to find out if that
is also the case on powerpc64le native where section anchors are used, the
changes in the source are like:
rs6000_overload_info[RS6000_OVLD_VEC_VSUBFP - base].first_instance
-= _instance_info[RS6000_INST_VSUBFP_DEPR1];
+= RS6000_INST_VSUBFP_DEPR1;
- rs6000_instance_info[RS6000_INST_VSUBSBS_DEPR1].fntype
+ rs6000_instance_info_fntype[RS6000_INST_VSUBSBS_DEPR1]
= v16qi_ftype_v16qi_v16qi;
and
- rs6000_builtin_info[RS6000_BIF_CFSTRING].fntype
+ rs6000_builtin_info_fntype[RS6000_BIF_CFSTRING]
= v_ftype_v;
so there is IMO nothing inherently larger.
[Bug target/115324] New: [12/13/14/15 Regression] PCH (and maybe GC) of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
Bug ID: 115324
Summary: [12/13/14/15 Regression] PCH (and maybe GC) of rs6000
builtins broken
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: belegdol at gmail dot com, dan at danny dot cz
Depends on: 104323
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #104323 +++
The PR104323 fix doesn't seem to work with --enable-host-pie.
cat pr104323.h
#include
cat pr104323.c
/* { dg-require-effective-target powerpc_altivec_ok } */
/* { dg-options "-maltivec" } */
#include "pr104323.h"
__vector int a1 = { 100, 200, 300, 400 };
__vector int a2 = { 500, 600, 700, 800 };
__vector int r;
int
main ()
{
r = vec_add (a1, a2);
return 0;
}
./xgcc -B ./ -c pr104323.h -o pr104323.h.gch
./xgcc -B ./ -S pr104323.c
pr104323.c: In function ‘main’:
pr104323.c:13:3: internal compiler error: Segmentation fault
13 | r = vec_add (a1, a2);
| ^
0x5625e2834b83 crash_signal
../../gcc/toplev.cc:319
0x5625e228c56d altivec_resolve_overloaded_builtin(unsigned int, tree_node*,
void*)
../../gcc/config/rs6000/rs6000-c.cc:1997
0x5625e2190392 c_build_function_call_vec(unsigned int, vec const&, tree_node*, vec*,
vec*)
../../gcc/c/c-typeck.cc:3440
0x5625e21c4536 c_parser_postfix_expression_after_primary
../../gcc/c/c-parser.cc:12682
0x5625e21a99a5 c_parser_postfix_expression
../../gcc/c/c-parser.cc:12234
0x5625e21ae60a c_parser_unary_expression
../../gcc/c/c-parser.cc:9894
0x5625e21b01df c_parser_cast_expression
../../gcc/c/c-parser.cc:9735
0x5625e21b04db c_parser_binary_expression
../../gcc/c/c-parser.cc:9503
0x5625e21b1a93 c_parser_conditional_expression
../../gcc/c/c-parser.cc:9198
0x5625e21b2324 c_parser_expr_no_commas
../../gcc/c/c-parser.cc:9111
0x5625e21b23ea c_parser_expr_no_commas
../../gcc/c/c-parser.cc:9154
0x5625e21b2773 c_parser_expression
../../gcc/c/c-parser.cc:12822
0x5625e21b2c57 c_parser_expression_conv
../../gcc/c/c-parser.cc:12862
0x5625e21d5b57 c_parser_statement_after_labels
../../gcc/c/c-parser.cc:7800
0x5625e21a942b c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:7287
0x5625e21d2136 c_parser_compound_statement
../../gcc/c/c-parser.cc:6564
0x5625e21d45af c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:3019
0x5625e21deb73 c_parser_external_declaration
../../gcc/c/c-parser.cc:2048
0x5625e21df5cb c_parser_translation_unit
../../gcc/c/c-parser.cc:1902
0x5625e21df5cb c_parse_file()
../../gcc/c/c-parser.cc:27269
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #18 from Jakub Jelinek --- (In reply to Natalie Perlin from comment #17) > Brief note on the errors is below. Does it need to be submitted as a > separate ticket/different bug? Yes. > I'd prepare a preprocessed file where the error occurs. Just try -freport-bug, if that works, upload what it prepares, otherwise follow https://gcc.gnu.org/bugs/
[Bug debug/115235] Non-standard .debug_addr section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115235 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I don't see any difference between in debug info including .debug_addr between -O2 -g -gsplit-dwarf and -O2 -gdwarf-5 -gsplit-dwarf (except for DW_AT_producer reflecting the different command line options), both with current GCC trunk and 13.3.1 on target where we default to DWARF 5, while with -O2 -gdwarf-4 -gsplit-dwarf it expectedly emits the older .debug_addr format. You haven't provided any testcase, nor said on which target it is (e.g. some targets default to DWARF 4, 3 or 2).
[Bug tree-optimization/115226] [15 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115226 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1 --- Comment #5 from Jakub Jelinek --- Started with r15-815-g5b9b3bae33cae7fca2e3c3e3028be6b8bee9b698
[Bug c++/115245] Fails to demangle some concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115245 --- Comment #3 from Jakub Jelinek --- We can't even demangle what has been added to the testsuite in that commit, e.g. _ZN1C1fIiEEvDTtlNS_UlT_TL0__E_EEE
[Bug c++/115245] Fails to demangle some concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115245 --- Comment #2 from Jakub Jelinek --- In particular cp/mangle.cc implements https://github.com/itanium-cxx-abi/cxx-abi/issues/31#issuecomment-528122117 while demangler does not.
[Bug c++/115245] Fails to demangle some concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115245
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-05-27
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
I can't find the concept mangling in the Itanium mangling docs specified at
all.
The comments in cp/mangle.cc and cp-demangle.cc suggest it is
Q
where
constraint-expression: expression
r14-6064-gc3f281a0c1ca5 commit that started the corresponding ICE refers
to https://github.com/itanium-cxx-abi/cxx-abi/pull/166 but that doesn't seem to
define Q either.
Anyway, seems the d_expression in
static struct demangle_component *
d_maybe_constraints (struct d_info *di, struct demangle_component *dc)
{
if (d_peek_char (di) == 'Q')
{
d_advance (di, 1);
struct demangle_component *expr = d_expression (di);
fails (returns NULL).
After Q there is 3cstITL0__...
llvm-cxxfilt demangles this as
void Outer::method() requires cst::Inner::operator
new(unsigned long)
but that can't be right either, there is nothing called TL0_ in the source.
d_expression_1 parses the 3cst part and because of I following it calls
3542 if (d_peek_char (di) == 'I')
3543return d_make_comp (di, DEMANGLE_COMPONENT_TEMPLATE, name,
3544d_template_args (di));
The TL0__ part comes during mangling from write_template_param on
TEMPLATE_TYPE_PARM U
with level 2 and parm_index 1 (as it writes level - 1 that is the 0_ in there
and _
for parm_index).
Now, this 'L' part has been added there with r14-4544 of PR109422.
So, my guess is the bug is that r14-4544 didn't include corresponding changes
to the demangler,
/* ::= T_
::= T <(parameter-2 non-negative) number> _
*/
static struct demangle_component *
d_template_param (struct d_info *di)
{
int param;
if (! d_check_char (di, 'T'))
return NULL;
param = d_compact_number (di);
if (param < 0)
return NULL;
return d_make_template_param (di, param);
}
can't handle the L with d_compact_number in there.
[Bug c++/115239] [14/15 Regression] ICE: Segmentation fault with ambiguous function call in some cases (`const char*` vs `char` with `long` vs `unsigned`) since r14-6522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115239 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Summary|[14/15 Regression] ICE: |[14/15 Regression] ICE: |Segmentation fault with |Segmentation fault with |ambiguous function call in |ambiguous function call in |some cases (`const char*` |some cases (`const char*` |vs `char` with `long` vs|vs `char` with `long` vs |`unsigned`) |`unsigned`) since r14-6522 --- Comment #4 from Jakub Jelinek --- Started with r14-6522-gb24c09bfb626271cda345f5a6f0d3a6b6480593d
[Bug sanitizer/115225] signed integer overflow check missing with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115225 Jakub Jelinek changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jakub Jelinek --- Yes, it is. Intentionally, so that sanitized code with optimizations isn't unnecessarily too slow.
[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115192
--- Comment #8 from Jakub Jelinek ---
(In reply to Richard Biener from comment #7)
> int main()
> {
> const int n = 3;
> float d[n*n];
> float4_t a[n*n];
I'd recommend using #define n 3 or enum { n = 3 }; instead of const int n = 3;
so that the arrays aren't unnecessary VLAs.
[Bug tree-optimization/115199] [15 regression] gettext (libtextstyle) testsuite miscompiled since r15-579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115199 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1 Summary|[15 regression] gettext |[15 regression] gettext |(libtextstyle) testsuite|(libtextstyle) testsuite |miscompiled |miscompiled since r15-579 --- Comment #5 from Jakub Jelinek --- r15-579-ga9251ab3c91c8c559d0306838575a666ae62dff4
[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115192 Jakub Jelinek changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- The #c4 testcase changed behavior with r11-6380-g9fa5b473b5b8e289b6542adfd5cfaddfb3036048
[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115192 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-22 Target Milestone|--- |14.2 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Priority|P3 |P2 Status|UNCONFIRMED |NEW Summary|[14/15 regression] -O3 |[14/15 regression] -O3 |miscompilation on x86-64|miscompilation on x86-64 |(loops with vectors and |(loops with vectors and |scalars)|scalars) since r14-2117 --- Comment #3 from Jakub Jelinek --- Since r14-2117-gdd86a5a69cbda40cf76388a65d3317c91cb2b501
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #13 from Jakub Jelinek --- So provide fixes upstream and hope they apply them soon.
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172 --- Comment #11 from Jakub Jelinek --- Fixed for 13.4+/14.2+/15.1+ so far.
[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed for 13.4+/14.2+/15.1+.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #19 from Jakub Jelinek --- (In reply to Alexander Monakov from comment #18) > No, allowing value-changing transformations under -ftrapping-math is really > not appropriate. Invoking the intrinsic on a large floating-point value is > not UB. If we guarantee that we never constant fold FIX/UNSIGNED_FIX with -ftrapping-math (we shouldn't, as the exceptions should be raised), then using FIX/UNSIGNED_FIX is ok in flag_trapping_math guarded patterns even if the intrinsics have some specific value they want in those cases, because they will never be folded. While for !flag_trapping_math, we should use UNSPEC because FIX/UNSIGNED_FIX can be folded and would be folded to whatever the generic code decides, which might disagree to what the intrinsics need.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #17 from Jakub Jelinek --- I don't think the cost of using UNSPEC would be significant if the backend tried to constant fold more target builtins. Anyway, with the proposed changes perhaps you could keep using FIX/UNSIGNED_FIX for flag_trapping_math case even for the intrinsics and use UNSPECs only for !flag_trapping_math.
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #11 from Jakub Jelinek --- You want to fix the code as described in e.g. https://gcc.gnu.org/gcc-14/porting_to.html , not find workarounds. The code was apparently never valid C99+.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 Jakub Jelinek changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- (In reply to Hongtao Liu from comment #11) > (In reply to Jakub Jelinek from comment #10) > > Any of the floating point to integer intrinsics if they have out of range > > value (haven't checked whether floating point to unsigned intrinsic is a > > problem too or not). > > No matter if it is float or double (dunno if _Float16 too, or __bf16), and > > no matter if it is scalar intrinsic (ss/sd etc.) or vector and how many > > vector elements. > > But, this isn't really a regression, GCC has always behaved that way, the > > only thing that actually changed is that perhaps we can constant fold more > > than we used to do in the past. > > When not using intrinsics, IMNSHO we should keep doing what we did before. > > Can we restrict them under flag_trapping_math? If we do that, we should do it on the fold-const.cc side as well. There we fold it but add TREE_OVERFLOW flag in the overflow cases to the resulting tree, whether it prevents folding or not during GIMPLE passes would need to be figured out. C23 in F.4 says: If the integer type is bool, 6.3.1.2 applies and the conversion raises no floating-point exceptions if the floating-point value is not a signaling NaN. Otherwise, if the floating value is infinite or NaN or if the integral part of the floating value exceeds the range of the integer type, then the "invalid" floating-point exception is raised and the resulting value is unspecified. Otherwise, the resulting value is determined by 6.3.1.4. Conversion of an integral floating value that does not exceed the range of the integer type raises no floating-point exceptions; whether conversion of a non-integral floating value raises the "inexact" floating-point exception is unspecified. That said, this change really won't help the backend which supposedly should have the same behavior regardless of -fno-trapping-math, because in that case it is the value of the result (which is unspecified by the standards) rather than whether an exception is triggered or not.
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172 --- Comment #7 from Jakub Jelinek --- (In reply to Fedor Pchelkin from comment #6) > (In reply to Uroš Bizjak from comment #5) > > (In reply to Jakub Jelinek from comment #4) > > > Created attachment 58261 [details] > > > gcc15-pr115172.patch > > > > > > Full untested patch. > > > > I can confirm that this patch fixes boot for the kernel config from > > PR115172#43. > > Yep. I may confirm, too. Thanks for the prompt fix! > > If all goes well, is it expected to land in 14.2 and 13.4? If it is approved yes. 14.2 is expected likely in July this year, but 13.4 roughly in a year from now, as it just missed 13.3 (released today).
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #10 from Jakub Jelinek --- Any of the floating point to integer intrinsics if they have out of range value (haven't checked whether floating point to unsigned intrinsic is a problem too or not). No matter if it is float or double (dunno if _Float16 too, or __bf16), and no matter if it is scalar intrinsic (ss/sd etc.) or vector and how many vector elements. But, this isn't really a regression, GCC has always behaved that way, the only thing that actually changed is that perhaps we can constant fold more than we used to do in the past. When not using intrinsics, IMNSHO we should keep doing what we did before.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #9 from Jakub Jelinek --- In that case we should separate *.md patterns which are used for C conversions from the patterns used by the intrinsics, keep using what we are right now for the former and either use UNSPEC (the quickest but not best code generating variant) or something more complex. If UNSPEC is used, we could get some constant folding back by adding gimple_fold handling for those and the like of __builtin_ia32_psubusb128 or __builtin_ia32_pminub128. For __builtin_ia32_cvttps2dq etc. obviously the folding should either punt folding if some argument is out of range or fold those to what the hw does.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #6 from Jakub Jelinek --- The standard GCC behavior is that out of range floating conversions to integers result in signed integer maximum if the floating point value sign is clear and signed integer minimum otherwise (including infinities/nans).
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #5 from Jakub Jelinek ---
Trying
#include
int
main ()
{
float f = 0x0.8p+33f;
float __attribute__((vector_size (16))) vf = { 0x0.8p+33f, 0x0.8p+33f,
0x0.8p+33f, 0x0.8p+33f };
int a = f;
int __attribute__((vector_size (16))) vi = __builtin_convertvector (vf, int
__attribute__((vector_size (16;
int __attribute__((vector_size (16))) vi2 = (int __attribute__((vector_size
(16 _mm_cvttps_epi32 ((__m128) vf);
__builtin_printf ("%d\n", a);
__builtin_printf ("{%d, %d, %d, %d}\n", vi[0], vi[1], vi[2], vi[3]);
__builtin_printf ("{%d, %d, %d, %d}\n", vi2[0], vi2[1], vi2[2], vi2[3]);
}
with gcc and clang both with -O0 and -O2, this prints
-2147483648
{-2147483648, -2147483648, -2147483648, -2147483648}
{-2147483648, -2147483648, -2147483648, -2147483648}
with both compilers at -O0, clang at -O2 prints
-1720305736
{8524448, 0, 1, 135169}
{-2147483648, -2147483648, -2147483648, -2147483648}
i.e. complete garbage for the non-intrinsic cases, but what the HW does for the
intrinsic cases, while gcc at -O2 prints
2147483647
{2147483647, 2147483647, 2147483647, 2147483647}
{2147483647, 2147483647, 2147483647, 2147483647}
i.e. treats intrinsics and non-intrinsics the same.
GCC behaves this way consistently since GCC 9 (before __builtin_convertvector
hasn't been supported), but if the vi related lines are commented out, even GCC
4.7 works that way.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
(In reply to Sergei Trofimovich from comment #3)
> Looking at -O2's bug.cc.265t.optimized tree optimizations come up with
> unfolded saturated sub8:
>
> _12 = __builtin_ia32_psubusb128 ({ -65, 0, 0, 0, -65, 0, 0, 0, -65, 0, 0,
> 0, -65, 0, 0, 0 }, { -99, 0, 0, 0, -99, 0, 0, 0, -99, 0, 0, 0, -99, 0, 0, 0
> });
> _13 = __builtin_ia32_pminub128 (_12, { 32, 0, 0, 0, 32, 0, 0, 0, 32, 0, 0,
> 0, 32, 0, 0, 0 });
> ...
>
>
> bug.cc.272r.cse1 still has that subtraction:
>
> 5: r119:V16QI=[`*.LC0']
> REG_EQUAL const_vector
> 6: r120:V16QI=[`*.LC1']
> REG_EQUAL const_vector
> 7: r118:V16QI=us_minus(r119:V16QI,r120:V16QI)
>
> bug.cc.273r.fwprop1 does not anymore:
>
> 3: NOTE_INSN_BASIC_BLOCK 2
> 2: NOTE_INSN_FUNCTION_BEG
> 9: r122:V16QI=[`*.LC2']
> REG_EQUAL const_vector
>13: r123:V4SI=r122:V16QI#0<<0x17
> REG_EQUAL const_vector
>16: r128:SI=0x5f80
>15: r127:V4SI=vec_duplicate(r128:SI)
>
> Could it be that constant folder "forgot" to generate anything for
> unsupported saturated-sub instead of leaving it as is?
No. It is normal constant folding on RTL (not done on GIMPLE because
the i386 backend doesn't try to gimple fold __builtin_ia32_psubusb128
or __builtin_ia32_psubusb128). 0xbf - 0x9d is 0x22, so the us_minus works
actually in this case exactly like minus and because 0x20 is smaller than that,
the minimum is a vector with 0x20 elements (plus min (0 - 0, 0) = 0 elements).
The reason the testcase FAILs is the same as in the other PRs, it is trying to
convert
{0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f}
V4SFmode vector to V4SImode, and because the backend sees the constant operand
of the
fix, it folds it to the unspecified value as with scalar conversion.
Consider:
int
main ()
{
volatile float f = 0x0.8p+33f;
volatile float __attribute__((vector_size (16))) vf = { 0x0.8p+33f,
0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f };
int a = f;
int __attribute__((vector_size (16))) vi = __builtin_convertvector (vf, int
__attribute__((vector_size (16;
__builtin_printf ("%d\n", a);
__builtin_printf ("{%d, %d, %d, %d}\n", vi[0], vi[1], vi[2], vi[3]);
}
This prints
-2147483648
{-2147483648, -2147483648, -2147483648, -2147483648}
at -O0 or -O2, but with -O2 -Dvolatile= prints
2147483647
{2147483647, 2147483647, 2147483647, 2147483647}
instead.
Either is IMHO fine, the C standard doesn't specify what should be the result
of the conversion.
Now, whether for _mm_cvttps_epi32 etc. such cases are also unspecified or not
is debatable. The Intel spec obviously specifies what the CPU instructions do
even in those otherwise unspecified cases, the question is if the intrinsic
must behave the same or if those invalid conversions are still unspecified.
If they'd be well defined when using the intrinsics, arguably the backend
shouldn't use FIX RTL but some UNSPEC, or should use the FIX RTL conditionally
(if_then_else:SI (argument_is_in_bounds) (fix arg) (const_int 0x800)).
[Bug c++/115160] Enabling undefined behaviour sanitizer causes or'ed bit shift to report wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115160
--- Comment #6 from Jakub Jelinek ---
There is no inc in the last term.
Anyway, simplified example would be
int deref (int *);
int *inc (int *&);
int
baz (int *p)
{
return deref (inc (p)) | (deref (inc (p)) << 8) | (deref (inc (p)) << 16) |
(deref (p) << 24);
}
and while without the sanitization GCC chooses to evaluate this left to right,
with
sanitization it first turns it into essentially:
return deref (inc (p)) | ((tmp1 = deref (inc (p))), check_shift (tmp1, 8),
tmp1 << 8) | ((tmp2 = deref (inc (p))), check_shift (tmp2, 16), tmp2 << 16) |
((tmp3 = deref (p)), check_shift (tmp3, 24), tmp3 << 24);
but then further optimizations move the comma expression left hand sides before
the whole |, so it first evaluates the second deref+inc + checks the shift by
8, then
the third deref+inc + checks the shift by 16 etc. and then only the |
expressions and this is still valid due to the unspecified order of | operand
evaluations.
[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152 --- Comment #8 from Jakub Jelinek --- Created attachment 58262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58262=edit gcc15-pr115152.patch Untested fix.
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 58261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58261=edit gcc15-pr115172.patch Full untested patch.
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172 --- Comment #2 from Jakub Jelinek --- That said, --- gcc/ubsan.cc.jj 2024-03-22 09:23:37.695296775 +0100 +++ gcc/ubsan.cc2024-05-21 12:10:24.261454107 +0200 @@ -1776,13 +1776,17 @@ instrument_bool_enum_load (gimple_stmt_i || TREE_CODE (gimple_assign_lhs (stmt)) != SSA_NAME) return; + addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (rhs)); + if (as != TYPE_ADDR_SPACE (utype)) +utype = build_qualified_type (utype, TYPE_QUALS (utype) +| ENCODE_QUAL_ADDR_SPACE (as)); bool ends_bb = stmt_ends_bb_p (stmt); location_t loc = gimple_location (stmt); tree lhs = gimple_assign_lhs (stmt); tree ptype = build_pointer_type (TREE_TYPE (rhs)); tree atype = reference_alias_ptr_type (rhs); gimple *g = gimple_build_assign (make_ssa_name (ptype), - build_fold_addr_expr (rhs)); + build_fold_addr_expr (rhs)); gimple_set_location (g, loc); gsi_insert_before (gsi, g, GSI_SAME_STMT); tree mem = build2 (MEM_REF, utype, gimple_assign_lhs (g), seems to fix that. But wonder how many of the other ~180 spots that create MEM_REFs don't need similar fixes.
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-05-21
--- Comment #1 from Jakub Jelinek ---
Reduced testcase for -O2 -fsanitize=address,bool --param
asan-instrumentation-with-call-threshold=100:
extern struct S { _Bool b; } s;
void bar (void);
void
foo (void)
{
if (*(volatile _Bool __seg_gs *) (__UINTPTR_TYPE__) )
bar ();
}
What the kernel does is terrible, why they just don't declare the extern with
__seg_gs attribute?
[Bug c++/115160] Enabling undefined behaviour sanitizer causes or'ed bit shift to report wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115160 --- Comment #3 from Jakub Jelinek --- There is no sequence point analyzer in any compiler I'm aware of and I think it would be extremely hard to implement that. GCC has -Wsequence-point warning, which can handle lots of cases, but with the C++ abstractions the front-end can't really know what the different function calls will do and whether they have some undesirable side-effects or not. With the pointers, the compiler sees the post-increment operations, with overloaded operators it doesn't, it sees calls to some operator and it doesn't know what the operator will do. Those functions could be pure and not change anything on the shared object, or they can change it.
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #15 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
[Bug tree-optimization/115152] [13/14/15 Regression] wrong code at -O3 with "-fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" on x86_64-linux-gnu since r13-455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115152 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #7 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
[Bug analyzer/114677] [13/14/15 Regression] -Wanalyzer-fd-leak false positive writing to int * param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114677 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #2 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
[Bug c++/114992] [13/14/15 Regression] ICE during IPA pass: targetclone in add_to_same_comdat_group with calling a target clone with a lamdba in a comdat function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114992 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #2 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
