[Bug testsuite/115294] [15 regression] dg-additional-files-options change broke several testsuites
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115294 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE --- I've identified the problem and tested a patch. Will commit shortly.
[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297 Richard Biener changed: What|Removed |Added Summary|[14 regression] alpha: ICE |[14/15 regression] alpha: |in simplify_subreg, at |ICE in simplify_subreg, at |simplify-rtx.cc:7554 with |simplify-rtx.cc:7554 with |-O1 |-O1 Target Milestone|--- |14.2
[Bug testsuite/115294] [15 regression] dg-additional-files-options change broke several testsuites
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115294 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ada/115292] [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115292 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Version|9.0 |15.0
[Bug c/115290] [12/13/14/15 Regression] tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/115278] [13/14/15 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115278 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #3 from Richard Biener --- I think we fixed similar bug on the read side.
[Bug middle-end/115277] [13/14/15 regression] ICF needs to match loop bound estimates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-05-31
Keywords||testsuite-fail
Ever confirmed|0 |1
Target Milestone|--- |15.0
--- Comment #1 from Richard Biener ---
Huh, I honestly have no idea how those targets would differ here ...
I do see
void h (char * s)
{
# PT = anything
char * s_3(D) = s;
char a[8];
:
__builtin_memset (&a, 0, 8);
__builtin_strncpy (&a, s_3(D), 8);
# USE = anything
# CLB = anything
frob (&a);
a ={v} {CLOBBER(eos)};
return;
for nds32-sim but
Deleted dead call: __builtin_memset (&a, 0, 8);
void h (char * s)
{
# PT = nonlocal null
char * s_3(D) = s;
char a[8];
:
__builtin_strncpy (&a, s_3(D), 8);
# USE = nonlocal escaped null { D.2716 } (escaped)
# CLB = nonlocal escaped null { D.2716 } (escaped)
frob (&a);
a ={v} {CLOBBER(eos)};
return;
for x86-64. But then the points-to solutions should not make any difference
for DSE in this case ... (the points-to difference is odd in the first place
of course).
So for the points-to difference this is caused by
-a = &NULL
+a = INTEGER
which likely means a different default of -fno-delete-null-pointer-checks
or ADDR_SPACE_ADDRESS_ZERO_VALID. That causes us to bring in what the
object at (void *)0 points to, and that's ANYTHING since we do not track
objects at constant addresses in any way, and those might alias all other
objects. The question is more why we generate a = &NULL at all, but that's
a pre-existing issue. We now simply handle all this correctly (we didn't
before, with latent wrong-code).
Ah, and the DSE effect then is obviously that now 'strncpy (&a, s_3(D),..)'
reads from a since s_3(D) points to anything now (which includes 'a'), so
we can no longer remove/trim an earlier store to 'a'.
Ah, and the a = &NULL constraint is from the memset.
Since we pass a to frob it escapes and everything escaped memory points
to also escapes so anything escapes.
So I'd say it works correctly now.
There might be a missing indirection between NONLOCAL and ESCAPED. Since
s = &NONLOCAL even when anything is in ESCAPED anything isn't NONLOCAL
itself (well, but of course technically s can point to NULL as well -
another latent incorrectness in PTA, we do not track NULL conservatively,
a correctness mistake with ADDR_SPACE_ADDRESS_ZERO_VALID).
Btw, changing the testcases to
extern void frob (char *);
void h (char *s)
{
char a[8];
__builtin_memset (a, 1, sizeof a);
__builtin_strncpy (a, s, sizeof a);
frob (a);
}
shows the same effect on x86_64 - suddenly 'a' points to ANYTHING
(0x010101010101...), which makes 's' point to ANYTHING and DSE is gone.
Confirmed for the testsuite regression. I don't see how this is a bug
though. Maybe the stack object 'a' can never be at address zero? Or
any "fixed" address? I'm not sure that such constraint can be modeled in PTA
("split" ANYTHING somehow).
Adding -fdelete-null-pointer-checks to the test makes it succeed also on
nds32le-elf.
[Bug target/115282] [15 regression] gcc.dg/vect/costmodel/ppc/costmodel-slp-12.c fails after r15-812-gc71886f2ca2e46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115282 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||testsuite-fail Component|other |target Summary|15 regression] |[15 regression] |gcc.dg/vect/costmodel/ppc/c |gcc.dg/vect/costmodel/ppc/c |ostmodel-slp-12.c fails |ostmodel-slp-12.c fails |after |after |r15-812-gc71886f2ca2e46 |r15-812-gc71886f2ca2e46 --- Comment #1 from Richard Biener --- I don't see a good reason why, but I don't have a BE cross around to check myself. Does BE vect maybe not have unsigned integer vector multiplication support?
[Bug target/115299] [14/15 regression] pr86722.c failed to eliminate branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115299 --- Comment #2 from Hongtao Liu --- > Maybe r14-53-g675b1a7f113adb . Probably, current cost model may need adjustment.
[Bug target/115299] [14/15 regression] pr86722.c failed to eliminate branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115299 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.2 Summary|[14 regression] pr86722.c |[14/15 regression] |failed to eliminate branch. |pr86722.c failed to ||eliminate branch.
[Bug target/115299] [14 regression] pr86722.c failed to eliminate branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115299 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- ce differences: 13: ``` == Pass 2 == IF-THEN-JOIN block found, pass 2, test 4, then 6, join 7 scanning new insn with uid = 68. scanning new insn with uid = 69. scanning new insn with uid = 70. scanning new insn with uid = 71. scanning new insn with uid = 72. scanning new insn with uid = 73. Removing jump 14. deleting insn with uid = 14. deleting insn with uid = 5. deleting block 6 Conversion succeeded on pass 2. ``` 14/trunk: ``` IF-THEN-JOIN block found, pass 2, test 4, then 6, join 7 == no more changes 3 possible IF blocks searched. 1 IF blocks converted. 1 true changes made. ``` Maybe r14-53-g675b1a7f113adb .
[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157 --- Comment #3 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:867d1264fe71d4291194373d1a1c409cac97a597 commit r15-933-g867d1264fe71d4291194373d1a1c409cac97a597 Author: Martin Uecker Date: Sun May 19 23:13:22 2024 +0200 C: allow aliasing of compatible types derived from enumeral types [PR115157] Aliasing of enumeral types with the underlying integer is now allowed by setting the aliasing set to zero. But this does not allow aliasing of derived types which are compatible as required by ISO C. Instead, initially set structural equality. Then set TYPE_CANONICAL and update pointers and main variants when the type is completed (as done for structures and unions in C23). PR tree-optimization/115157 PR tree-optimization/115177 gcc/c/ * c-decl.cc (shadow_tag-warned,parse_xref_tag,start_enum, finish_enum): Set SET_TYPE_STRUCTURAL_EQUALITY / TYPE_CANONICAL. * c-objc-common.cc (get_alias_set): Remove special case. (get_aka_type): Add special case. gcc/c-family/ * c-attribs.cc (handle_hardbool_attribute): Set TYPE_CANONICAL for hardbools. gcc/ * godump.cc (go_output_typedef): Use TYPE_MAIN_VARIANT instead of TYPE_CANONICAL. gcc/testsuite/ * gcc.dg/enum-alias-1.c: New test. * gcc.dg/enum-alias-2.c: New test. * gcc.dg/enum-alias-3.c: New test. * gcc.dg/enum-alias-4.c: New test.
[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177 --- Comment #3 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:867d1264fe71d4291194373d1a1c409cac97a597 commit r15-933-g867d1264fe71d4291194373d1a1c409cac97a597 Author: Martin Uecker Date: Sun May 19 23:13:22 2024 +0200 C: allow aliasing of compatible types derived from enumeral types [PR115157] Aliasing of enumeral types with the underlying integer is now allowed by setting the aliasing set to zero. But this does not allow aliasing of derived types which are compatible as required by ISO C. Instead, initially set structural equality. Then set TYPE_CANONICAL and update pointers and main variants when the type is completed (as done for structures and unions in C23). PR tree-optimization/115157 PR tree-optimization/115177 gcc/c/ * c-decl.cc (shadow_tag-warned,parse_xref_tag,start_enum, finish_enum): Set SET_TYPE_STRUCTURAL_EQUALITY / TYPE_CANONICAL. * c-objc-common.cc (get_alias_set): Remove special case. (get_aka_type): Add special case. gcc/c-family/ * c-attribs.cc (handle_hardbool_attribute): Set TYPE_CANONICAL for hardbools. gcc/ * godump.cc (go_output_typedef): Use TYPE_MAIN_VARIANT instead of TYPE_CANONICAL. gcc/testsuite/ * gcc.dg/enum-alias-1.c: New test. * gcc.dg/enum-alias-2.c: New test. * gcc.dg/enum-alias-3.c: New test. * gcc.dg/enum-alias-4.c: New test.
[Bug target/115299] New: [14 regression] pr86722.c failed to eliminate branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115299
Bug ID: 115299
Summary: [14 regression] pr86722.c failed to eliminate branch.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization, needs-bisection
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
void f(double*d,double*e){
for(;d
[Bug tree-optimization/115298] New: [15 Regression] Various targets failing DSE tests after recent changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298 Bug ID: 115298 Summary: [15 Regression] Various targets failing DSE tests after recent changes Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- A few targets (nds32be-elf, nds32le-elf, avr-elf) have started failing a few tests after recent aliasing changes: Tests that now fail, but worked before (9 tests): nds32-sim: gcc: gcc.c-torture/execute/strcpy-1.c -O3 -g (test for excess errors) nds32-sim: gcc: gcc.dg/tree-ssa/pr86061.c scan-tree-dump-times dse1 "Deleted dead call" 1 nds32-sim: gcc: gcc.dg/tree-ssa/pr86061.c scan-tree-dump-times dse1 "Deleted dead call" 1 nds32-sim: gcc: gcc.dg/tree-ssa/ssa-dse-37.c scan-tree-dump-times dse1 "Deleted dead call" 2 nds32-sim: gcc: gcc.dg/tree-ssa/ssa-dse-37.c scan-tree-dump-times dse1 "Deleted dead call" 2 nds32-sim: gcc: gcc.dg/tree-ssa/ssa-dse-37.c scan-tree-dump-times dse1 "Trimming statement " 4 nds32-sim: gcc: gcc.dg/tree-ssa/ssa-dse-37.c scan-tree-dump-times dse1 "Trimming statement " 4 nds32-sim: gcc: gcc.dg/tree-ssa/strncpy-1.c scan-tree-dump-not optimized "memset" nds32-sim: gcc: gcc.dg/tree-ssa/strncpy-1.c scan-tree-dump-not optimized "memset" This was bisected to: commit c08b0d3f7b3539b26031de31d88dea6b94474577 Author: Richard Biener Date: Mon May 27 10:41:02 2024 +0200 tree-optimization/115236 - more points-to *ANYTHING = x fixes The stored-to ANYTHING handling has more holes, uncovered by treating volatile accesses as ANYTHING. We fail to properly build the pred and succ graphs, in particular we may not elide direct nodes from receiving from STOREDANYTHING. PR tree-optimization/115236 * tree-ssa-structalias.cc (build_pred_graph): Properly handle *ANYTHING = X. (build_succ_graph): Likewise. Do not elide direct nodes from receiving from STOREDANYTHING. * gcc.dg/pr115236.c: New testcase. I haven't done any deeper analysis.
[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127 --- Comment #4 from Bi6c --- (In reply to Andrew Pinski from comment #1) > Can you attach the preprocessed source? Yes. I attached the preprocessed source file.
[Bug target/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 Hongyu Wang changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Hongyu Wang --- Fixed on GCC13/14/15.
[Bug target/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:173f8763a66622f2a70ad66f60573fcff7d6b49e commit r13-8811-g173f8763a66622f2a70ad66f60573fcff7d6b49e Author: Hongyu Wang Date: Wed May 15 11:24:34 2024 +0800 i386: Fix ix86_option override after change [PR 113719] In ix86_override_options_after_change, calls to ix86_default_align and ix86_recompute_optlev_based_flags will cause mismatched target opt_set when doing cl_optimization_restore. Move them back to ix86_option_override_internal to solve the issue. gcc/ChangeLog: PR target/113719 * config/i386/i386-options.cc (ix86_override_options_after_change): Remove call to ix86_default_align and ix86_recompute_optlev_based_flags. (ix86_option_override_internal): Call ix86_default_align and ix86_recompute_optlev_based_flags. (cherry picked from commit 499d00127d39ba894b0f7216d73660b380bdc325)
[Bug target/113719] [13/14/15 regression] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:cd161b335c2723d0dce1cab00ad216b423ec2767 commit r14-10262-gcd161b335c2723d0dce1cab00ad216b423ec2767 Author: Hongyu Wang Date: Wed May 15 11:24:34 2024 +0800 i386: Fix ix86_option override after change [PR 113719] In ix86_override_options_after_change, calls to ix86_default_align and ix86_recompute_optlev_based_flags will cause mismatched target opt_set when doing cl_optimization_restore. Move them back to ix86_option_override_internal to solve the issue. gcc/ChangeLog: PR target/113719 * config/i386/i386-options.cc (ix86_override_options_after_change): Remove call to ix86_default_align and ix86_recompute_optlev_based_flags. (ix86_option_override_internal): Call ix86_default_align and ix86_recompute_optlev_based_flags. (cherry picked from commit 499d00127d39ba894b0f7216d73660b380bdc325)
[Bug rtl-optimization/115297] New: [14 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
Bug ID: 115297
Summary: [14 regression] alpha: ICE in simplify_subreg, at
simplify-rtx.cc:7554 with -O1
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: matoro_gcc_bugzilla at matoro dot tk
Target Milestone: ---
Target: alpha-unknown-linux-gnu
Created attachment 58314
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58314&action=edit
gdb context and complete backtrace
Found this while building kernel with gcc-14. This reproduces on cross, so
using that as an example.
Minimized:
enum { BPF_F_USER_BUILD_ID } __bpf_get_stack_size;
long __bpf_get_stack_flags, bpf_get_stack___trans_tmp_2;
void bpf_get_stack() {
unsigned elem_size;
int err = elem_size = __bpf_get_stack_flags ?: sizeof(long);
if (__builtin_expect(__bpf_get_stack_size % elem_size, 0))
bpf_get_stack___trans_tmp_2 = err;
}
$ alpha-unknown-linux-gnu-gcc-14 -O1 -c stackmap.i
during RTL pass: combine
stackmap.i: In function ‘bpf_get_stack’:
stackmap.i:8:1: internal compiler error: in simplify_subreg, at
simplify-rtx.cc:7554
8 | }
| ^
Backtrace summary (more detailed bt with locals and snippets in attachment):
#0 internal_error (gmsgid=0x1033e41b0 "in %s, at %s:%d") at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/diagnostic.cc:2227
#1 0x000102ff9cac in fancy_abort (file=0x103272d20
"/var/tmp/portage/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/work/gcc-14-20240518/gcc/simplify-rtx.cc",
line=7554,
function=0x1032731f0 "simplify_subreg") at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/diagnostic.cc:2353
#2 0x0001017b5ea4 in simplify_context::simplify_subreg
(this=0x7fff9f00, outermode=E_DImode, op=0x75448c28,
innermode=E_SImode, byte=...)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/simplify-rtx.cc:7554
#3 0x0001017b8da8 in simplify_context::simplify_subreg
(this=0x7fff9f00, outermode=E_DImode, op=0x75449ff0,
innermode=E_SImode, byte=...)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/simplify-rtx.cc:7804
#4 0x0001017b988c in simplify_context::simplify_gen_subreg
(this=0x7fff9f00, outermode=E_DImode, op=0x75449ff0,
innermode=E_SImode, byte=...)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/simplify-rtx.cc:7875
#5 0x000100bb6224 in simplify_gen_subreg (outermode=E_DImode,
op=0x75449ff0, innermode=E_SImode, byte=...)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/rtl.h:3552
#6 0x0001028f87dc in if_then_else_cond (x=0x75449f60,
ptrue=0x7fffa528, pfalse=0x7fffa538)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:9423
#7 0x0001028f55ec in if_then_else_cond (x=0x75449f78,
ptrue=0x7fffa948, pfalse=0x7fffa958)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:9286
#8 0x0001028f55ec in if_then_else_cond (x=0x75449f90,
ptrue=0x7fffb148, pfalse=0x7fffb150)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:9286
#9 0x0001028bf07c in combine_simplify_rtx (x=0x75449f90,
op0_mode=E_VOIDmode, in_dest=false, in_cond=false)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:5758
#10 0x0001028bc3d8 in subst (x=0x75449f90, from=0x754488c8,
to=0x75451920, in_dest=false, in_cond=false, unique_copy=false)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:5619
#11 0x0001028bba88 in subst (x=0x75448cb8, from=0x754488c8,
to=0x75451920, in_dest=false, in_cond=false, unique_copy=false)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:5546
#12 0x0001028babe8 in subst (x=0x754a68a0, from=0x754488c8,
to=0x75451920, in_dest=false, in_cond=false, unique_copy=false)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:5480
#13 0x00010289ba0c in try_combine (i3=0x754e0540, i2=0x754e0500,
i1=0x754e06c0, i0=0x0, new_direct_jump_p=0x7fffe2df,
last_combined_insn=0x754e0540)
at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gcc/combine.cc:3349
#14 0x00010288c22c in combine_instructions (f=0x754009a0, nregs=88) at
/usr/src/debug/cross-alpha-unknown-linux-gnu/gcc-14.1.1_p20240518/gcc-14-20240518/gc
[Bug c++/115296] New: CTAD fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115296
Bug ID: 115296
Summary: CTAD fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
The following code compiles fine with clang and msvc, but fails with gcc.
https://godbolt.org/z/e4dP7rzar
```
#include
template
using array_view = std::span;
void fun(std::span s) {
[[maybe_unused]] auto _1 = std::span{s};
[[maybe_unused]] auto _2 = array_view{s};
}
```
Error:
```
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20240530/include/c++/15.0.0/span: In function
'void fun(std::span)':
/opt/compiler-explorer/gcc-trunk-20240530/include/c++/15.0.0/span:450:5: error:
size '18446744073709551615' of array exceeds maximum object size
'9223372036854775807'
450 | span(_Type(&)[_ArrayExtent]) -> span<_Type, _ArrayExtent>;
| ^~~~
/opt/compiler-explorer/gcc-trunk-20240530/include/c++/15.0.0/span:450:10:
error: size '18446744073709551615' of array exceeds maximum object size
'9223372036854775807'
450 | span(_Type(&)[_ArrayExtent]) -> span<_Type, _ArrayExtent>;
| ^~
:8:44: error: class template argument deduction failed:
8 | [[maybe_unused]] auto _2 = array_view{s};
|^
:8:44: error: call of overloaded 'span(std::span&)' is ambiguous
/opt/compiler-explorer/gcc-trunk-20240530/include/c++/15.0.0/span:464:5: note:
candidate: 'std::span(_Range&&)-> span >::type> requires
__is_deducible (array_view, std::span)()))&>)())>::type,
18446744073709551615>) [with _Range = span&; typename
remove_reference >::type = int;
ranges::range_reference_t<_Range&> = int&]'
464 | span(_Range &&)
| ^~~~
/opt/compiler-explorer/gcc-trunk-20240530/include/c++/15.0.0/span:54:11: note:
candidate: 'span(std::span<_Type, 18446744073709551615>)-> std::span<_Type,
18446744073709551615> [with T = int]'
54 | class span;
| ^~~~
/opt/compiler-explorer/gcc-trunk-20240530/include/c++/15.0.0/span:225:7: note:
candidate: 'span(const std::span<_Type, 18446744073709551615>&)->
std::span<_Type, 18446744073709551615> [with T = int]'
225 | span(const span&) noexcept = default;
| ^~~~
Compiler returned: 1
```
[Bug c++/115291] armv8-a GCC emits float32x2_t loads from uninitialized stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115291 --- Comment #2 from Andrew Pinski --- See https://libeigen.gitlab.io/docs/TopicPitfalls.html section "C++11 and the auto keyword" explictly. "In short: do not use the auto keywords with Eigen's expressions, unless you are 100% sure about what you are doing. In particular, do not use the auto keyword as a replacement for a Matrix<> type." Describes the issue you are having.
[Bug target/115102] [SH] GCC misunderstands swap.b instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115102
--- Comment #5 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:e715204f203d318524ae86f3f2a1e8d5d7cb08dc
commit r15-930-ge715204f203d318524ae86f3f2a1e8d5d7cb08dc
Author: Uros Bizjak
Date: Thu May 30 21:27:42 2024 +0200
i386: Rewrite bswaphi2 handling [PR115102]
Introduce *bswaphi2 instruction pattern and enable bswaphi2 expander
also for non-movbe targets. The testcase:
unsigned short bswap8 (unsigned short val)
{
return ((val & 0xff00) >> 8) | ((val & 0xff) << 8);
}
now expands through bswaphi2 named expander.
Rewrite bswaphi_lowpart insn pattern as bswaphisi2_lowpart in the RTX form
that combine pass can use to simplify:
Trying 6, 9, 8 -> 10:
6: r99:SI=bswap(r103:SI)
9: {r107:SI=r103:SI&0x;clobber flags:CC;}
REG_DEAD r103:SI
REG_UNUSED flags:CC
8: {r106:SI=r99:SI 0>>0x10;clobber flags:CC;}
REG_DEAD r99:SI
REG_UNUSED flags:CC
10: {r104:SI=r106:SI|r107:SI;clobber flags:CC;}
REG_DEAD r107:SI
REG_DEAD r106:SI
REG_UNUSED flags:CC
Successfully matched this instruction:
(set (reg:SI 104 [ _8 ])
(ior:SI (and:SI (reg/v:SI 103 [ val ])
(const_int -65536 [0x]))
(lshiftrt:SI (bswap:SI (reg/v:SI 103 [ val ]))
(const_int 16 [0x10]
allowing combination of insns 6, 8, 9 and 10
when compiling the following testcase:
unsigned int bswap8 (unsigned int val)
{
return (val & 0x) | ((val & 0xff00) >> 8) | ((val & 0xff) << 8);
}
to produce:
movl%edi, %eax
xchgb %ah, %al
ret
The expansion now always goes through a clobberless form of the bswaphi
instruction. The instruction is conditionally converted to a rotate at
peephole2 pass. This significantly simplifies bswaphisi2_lowpart
insn pattern attributes.
PR target/115102
gcc/ChangeLog:
* config/i386/i386.md (bswaphi2): Also enable for !TARGET_MOVBE.
(*bswaphi2): New insn pattern.
(bswaphisi2_lowpart): Rename from bswaphi_lowpart. Rewrite
insn RTX to match the expected form of the combine pass.
Remove rol{w} alternative and corresponding attributes.
(bswsaphisi2_lowpart peephole2): New peephole2 pattern to
conditionally convert bswaphisi2_lowpart to rotlhi3_1_slp.
(bswapsi2): Update expander for rename.
(rotlhi3_1_slp splitter): Conditionally split to bswaphi2.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr115102.c: New test.
[Bug libgomp/109452] omp_init_lock_with_hint() and omp_init_nest_lock_with_hint() are undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109452 Tobias Burnus changed: What|Removed |Added Keywords||openmp Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-30 CC||burnus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Tobias Burnus --- Confirmed for * omp_init_lock_with_hint * omp_init_nest_lock_with_hint Both have a prototype since ages but no actual implementation. Side note: libgomp.texi would need to be updated as well.
[Bug middle-end/115277] [13/14/15 regression] ICF needs to match loop bound estimates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277 --- Comment #3 from Jan Hubicka --- > What about gcc 13? GCC 13 also misoptimizes. Honza
[Bug d/115295] [15 regression] Various gdc testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug d/115295] New: [15 regression] Various gdc testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295 Bug ID: 115295 Summary: [15 regression] Various gdc testsuite regressions Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Between 20240529 (18f477980c8597fe3dca2c2e8bd533c0c2b17aa6) and 20240530 (71899d6b4e18145f005046681208db0137c95ede), quite a number of gdc.* tests regressed: +FAIL: gdc.dg/attr_module.d(test for warnings, line 12) +FAIL: gdc.dg/attr_module.d(test for warnings, line 18) +FAIL: gdc.dg/attr_module.d(test for warnings, line 24) +FAIL: gdc.dg/attr_module.d(test for warnings, line 36) +FAIL: gdc.dg/attr_module.d (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/attr_module.d:6:2: error: undefined identifier 'value_ignored' /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/attr_module.d:12:2: error: undefined identifier 'type_symbol' /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/attr_module.d:18:2: error: undefined identifier 'template_symbol' /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/attr_module.d:24:2: error: undefined identifier 'struct_wrong_field' /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/attr_module.d:30:2: error: undefined identifier 'struct_void_init' /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/attr_module.d:36:2: error: undefined identifier 'unknown_attribute' +FAIL: gdc.dg/gdc231.d (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gdc.dg/gdc231.d:5:8: error: unable to read module 'gdc231' import path[0] = /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libphobos/libdruntime import path[1] = /vol/gcc/src/hg/master/local/libphobos/libdruntime import path[2] = /vol/gcc/src/hg/master/local/libphobos/src +FAIL: gdc.dg/gdc253a.d (test for excess errors) +FAIL: gdc.dg/gdc27.d (test for excess errors) +FAIL: gdc.dg/pr108050.d (test for excess errors) +FAIL: gdc.test/compilable/test16348.d output-exists test16348.s +FAIL: gdc.test/compilable/test17541.d output-exists test17541.s compilable/test17541.d:8:8: error: unable to read module 'two' compilable/test17541.d:8:8: note: Expected 'two.d' or 'two/package.d' in one of the following import paths: import path[0] = /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libphobos/libdruntime import path[1] = /vol/gcc/src/hg/master/local/libphobos/libdruntime import path[2] = /vol/gcc/src/hg/master/local/libphobos/src import path[3] = /var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/gdc3/compilable compiler exited with status 1 +FAIL: gdc.test/fail_compilation/diag4479.d output-exists-not diag4479.o +FAIL: gdc.test/fail_compilation/fail11453a.d output-exists-not fail11453a.o +FAIL: gdc.test/fail_compilation/fail11453b.d output-exists-not fail11453b.o +FAIL: gdc.test/fail_compilation/fail18938.d output-exists-not fail18938.o +FAIL: gdc.test/fail_compilation/fail19911b.d output-exists-not fail19911b.o +FAIL: gdc.test/fail_compilation/fail23109.d output-exists-not fail23109.o +FAIL: gdc.test/fail_compilation/ice10598.d output-exists-not ice10598.o +FAIL: gdc.test/fail_compilation/ice11136.d output-exists-not ice11136.o +FAIL: gdc.test/fail_compilation/ice14116.d output-exists-not ice14116.o +FAIL: gdc.test/fail_compilation/no_Throwable.d output-exists-not no_Throwable.o +FAIL: gdc.test/fail_compilation/no_TypeInfo.d output-exists-not no_TypeInfo.o +FAIL: gdc.test/fail_compilation/verifyhookexist.d output-exists-not verifyhookexist.o I'm seeing this on at least Solaris/x86 (32 and 64-bit) and Linux/x86_64 (64 and 32-bit).
[Bug testsuite/115294] [15 regression] dg-additional-files-options change broke several testsuites
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115294 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug testsuite/115294] New: [15 regression] dg-additional-files-options change broke several testsuites
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115294
Bug ID: 115294
Summary: [15 regression] dg-additional-files-options change
broke several testsuites
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Between 20240529 (18f477980c8597fe3dca2c2e8bd533c0c2b17aa6) and 20240530
(71899d6b4e18145f005046681208db0137c95ede),
several testsuite results were lost completely.
libatomic, libgomp, libitm, and libphobos are affected. In each case, the
test logs show a variation of
ERROR: tcl error sourcing
/vol/gcc/src/hg/master/local/libatomic/testsuite/../../gcc/testsuite/lib/gcc-dg.exp.
wrong # args: should be "dg-additional-files-options options source dest type"
while executing
"check_cached_effective_target $prop {
eval [list check_no_compiler_messages_nocache $prop] $args
}"
(procedure "check_no_compiler_messages" line 2)
invoked from within
"check_no_compiler_messages lto object {
void foo (void) { }
} "-flto""
(procedure "check_effective_target_lto" line 11)
invoked from within
"check_effective_target_lto"
invoked from within
"if [info exists TORTURE_OPTIONS] {
set DG_TORTURE_OPTIONS $TORTURE_OPTIONS
} else {
# It is theoretically beneficial to group all of the O2/O3..."
(file
"/vol/gcc/src/hg/master/local/libatomic/testsuite/../../gcc/testsuite/lib/gcc-dg.exp"
line 82)
invoked from within
"source
/vol/gcc/src/hg/master/local/libatomic/testsuite/../../gcc/testsuite/lib/gcc-dg.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/vol/gcc/src/hg/master/local/libatomic/testsuite/../../gcc/testsuite/lib/gcc-dg.exp"
invoked from within
"catch "uplevel #0 source $file""
I'm seeing this on both i386-pc-solaris2.11 and x86_64-pc-linux-gnu; most
likely
this happens everywhere.
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #27 from Peter Cordes --- (In reply to Hongtao Liu from comment #26) > (In reply to Hongtao Liu from comment #25) > > (In reply to Peter Cordes from comment #22) > > > Why are we adding an alignment requirement to _mm_storel_pd, the intrinsic > > > for MOVLPD? > > > > > From Intel intrinsic guide[1], there's explict "mem_addr does not need to be > > aligned on any particular boundary" for mm_store_sd, but not for > > _mm_storel_pd. > > [1] https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html > > > But for mm_loadl_pd, it also says no need for alignment, I need to confirm > with my peers if there's any specific purpose on that. > And yes, for <16-byte memory access, there's no alignment requirement > functionally. Interesting, yes some entries explicitly say the memory can be unaligned, some don't. But I don't think we should read that as alignment required being the default if not stated. Every intrinsic that does require alignment explicitly says so. (Like _mm_load_si128.) We could make the same argument in the other direction, that if an alignment requirement isn't mentioned, we should assume there isn't one. And I already posted earlier about why we shouldn't assume C semantics based on the pointer type as Andrew Pinski had thought. Intel's intrinsic docs were originally written for ICC (classic), which takes intrinsics very literally: an intrinsic in the C source will (almost?) always compile to the corresponding asm instruction. And presumably not optimizing based on pointer-alignment UB even on a deref. And definitely not on strict-aliasing UB. So the C defaults for deref of a double* or __m64* shouldn't be assumed even when the docs don't say anything about alignment. They also don't mention aliasing but we know from Intel's examples of how to use intrinsics (I think) that the load/store intrinsics are all may_alias accesses. Intel's current ICX compiler is based on LLVM which does care about aliasing and alignment UB when optimizing, but their intrinsic docs still read like they're thinking more in terms of asm than in terms of the C abstract machine. Probably they haven't been rewritten with that in mind since they implement them (in their own compilers) so they Just Work even when aliasing other types or without alignment.
[Bug ada/115292] [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115292 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2024-05-30 --- Comment #1 from Eric Botcazou --- Can you post the list of ACATS regressions on the 32-bit host?
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #10 from Hans-Peter Nilsson --- (In reply to r...@cebitec.uni-bielefeld.de from comment #9) > > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE > Uni-Bielefeld.DE> --- > >> --- Comment #6 from Hans-Peter Nilsson --- > [...] > >> versions.) BTW, it'd be nice to know it it reproduces for sparc-linux as > >> well. > > > > I happen to have a Linux/sparc64 LDom around: I'll give it a whirl. > > The failure is even earlier here: in a sparc64-unknown-linux-gnu > bootstrap, building a libstdc++ .gch file in stage 2 breaks: Great, thanks! That means that tricking my pc into believing it's a sparc by means of using the binfmt machinery that Jeff mentioned in the thread where I mentioned the revert on gcc-patches, would work. (I don't have the details and don't remember if I'd actually tried it, certainly not recently; I just know about the concept.) What's not so great is that the described reproducer is a bootstrap, so the debug situation is unpleasant. The first step I'd do, would be to just do a cross-build (or native --disable-bootstrap) and just run the testsuite before/after the patch-set (or just 933ab59c59bdc1) and see if the problem manifests there. It's also not great (from the view of gcc targeting architectures with delay-slots) that this isn't at the top of my queue anymore, since the immediate situation was resolved; as mentioned I committed the revert. I'll get to it eventually, but if someone is intrigued enough by the prospect of a 0.36%-ish performance improvement (see commit log for the culprit commit) to do such a --disable-bootstrap regtest, that'd help. :) Thank you for your patience and for the help.
[Bug rtl-optimization/115281] [14 Regression] aarch64 ICE in go_through_subreg after r14-5129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115281 Richard Sandiford changed: What|Removed |Added Summary|[14/15 Regression] aarch64 |[14 Regression] aarch64 ICE |ICE in go_through_subreg|in go_through_subreg after |after r14-5129 |r14-5129 Known to work||15.0 Known to fail|15.0| --- Comment #3 from Richard Sandiford --- Fixed on trunk, will backport if there are no issues.
[Bug rtl-optimization/115281] [14/15 Regression] aarch64 ICE in go_through_subreg after r14-5129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115281 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:46d931b3dd31cbba7c3355ada63f155aa24a4e2b commit r15-929-g46d931b3dd31cbba7c3355ada63f155aa24a4e2b Author: Richard Sandiford Date: Thu May 30 16:17:58 2024 +0100 ira: Fix go_through_subreg offset calculation [PR115281] go_through_subreg used: else if (!can_div_trunc_p (SUBREG_BYTE (x), REGMODE_NATURAL_SIZE (GET_MODE (x)), offset)) to calculate the register offset for a pseudo subreg x. In the blessed days before poly-int, this was: *offset = (SUBREG_BYTE (x) / REGMODE_NATURAL_SIZE (GET_MODE (x))); But I think this is testing the wrong natural size. If we exclude paradoxical subregs (which will get an offset of zero regardless), it's the inner register that is being split, so it should be the inner register's natural size that we use. This matters in the testcase because we have an SFmode lowpart subreg into the last of three variable-sized vectors. The SUBREG_BYTE is therefore equal to the size of two variable-sized vectors. Dividing by the vector size gives a register offset of 2, as expected, but dividing by the size of a scalar FPR would give a variable offset. I think something similar could happen for fixed-size targets if REGMODE_NATURAL_SIZE is different for vectors and integers (say), although that case would trade an ICE for an incorrect offset. gcc/ PR rtl-optimization/115281 * ira-conflicts.cc (go_through_subreg): Use the natural size of the inner mode rather than the outer mode. gcc/testsuite/ PR rtl-optimization/115281 * gfortran.dg/pr115281.f90: New test.
[Bug plugins/115288] [15 Regression] File label-text.h not part of installation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115288 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-30 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I think this fixes the issue (which was introduced by r15-874-g9bda2c4c81b668 ): ``` [apinski@xeond2 gcc]$ git diff Makefile.in diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 66d42cc41f8..67c00a9c23f 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1038,6 +1038,7 @@ SYSTEM_H = system.h hwint.h $(srcdir)/../include/libiberty.h \ PREDICT_H = predict.h predict.def CPPLIB_H = $(srcdir)/../libcpp/include/line-map.h \ $(srcdir)/../libcpp/include/rich-location.h \ + $(srcdir)/../libcpp/include/label-text.h \ $(srcdir)/../libcpp/include/cpplib.h CODYLIB_H = $(srcdir)/../libcody/cody.hh INPUT_H = $(srcdir)/../libcpp/include/line-map.h input.h ``` Let me double check that and commit as obvious if it works.
[Bug plugins/115288] [15 Regression] File label-text.h not part of installation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115288 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Summary|File label-text.h not part |[15 Regression] File |of installation |label-text.h not part of ||installation
[Bug c/115290] [12/13/14/15 Regression] tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|tree check fail in |[12/13/14/15 Regression] |c_tree_printer, at |tree check fail in |c/c-objc-common.cc:330 |c_tree_printer, at ||c/c-objc-common.cc:330 Keywords||ice-on-valid-code Last reconfirmed||2024-05-30 Target Milestone|--- |12.4 Version|unknown |15.0 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- :4:50: note: use '&\204[0] == &tls13_handshakes[0]' to compare the addresses I think it was introduced with r12-4148-g2dda00b734888d which also introduced the warning. Since the diagnostic looks broken with release checking. + inform (location, "use %<&%D[0] %s &%D[0]%> to compare the addresses", + op0, op_symbol_code (code), op1); %D here is expecting a decl but we have an expression.
[Bug target/115289] PPC: Document the machine constraint 'Y' and make it non-internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115289 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-30 --- Comment #1 from Segher Boessenkool --- Yup. Thanks for the report! Note that you usually want "YZ", not just "Y", so that things always work (with just "Y" reloading does not always work).
[Bug driver/115293] Warn if a compiler flag downgrades protection provided by -fhardened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293 Siddhesh Poyarekar changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Siddhesh Poyarekar --- Invalid, since this is already implemented through -Whardened.
[Bug driver/115293] Warn if a compiler flag downgrades protection provided by -fhardened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293 --- Comment #2 from Siddhesh Poyarekar --- Oh, I had overlooked -Whardened; so it looks like we already do this.
[Bug driver/115293] Warn if a compiler flag downgrades protection provided by -fhardened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293 --- Comment #1 from Sam James --- We have -Whardened already which is maybe a good fit?
[Bug driver/115293] Warn if a compiler flag downgrades protection provided by -fhardened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293 Siddhesh Poyarekar changed: What|Removed |Added Version|13.0|14.0 CC||mpolacek at gcc dot gnu.org Severity|normal |enhancement
[Bug driver/115293] New: Warn if a compiler flag downgrades protection provided by -fhardened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115293 Bug ID: 115293 Summary: Warn if a compiler flag downgrades protection provided by -fhardened Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: siddhesh at gcc dot gnu.org Target Milestone: --- When -fhardened is passed alongside options it enables, the options could override behaviour enabled by -fhardened. This is by design, but there's a hole in this, in that accidentally passing, e.g. -fstack-protector alongside -fhardened could downgrade stack protection. Add a new warning (-Wweakened-hardening) that points out such a situation, allowing developers to turn off the warning if the downgrade in hardening is deliberate.
[Bug c++/115031] g++.dg/modules/pr99023_b.X FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031 Rainer Orth changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/653 ||136.html Target Milestone|--- |15.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Rainer Orth --- Fixed for GCC 15.0.
[Bug c++/115031] g++.dg/modules/pr99023_b.X FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115031 --- Comment #3 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:32f99225bcaae9b792aec143239d17f2b7e2c54b commit r15-927-g32f99225bcaae9b792aec143239d17f2b7e2c54b Author: Rainer Orth Date: Thu May 30 15:00:59 2024 +0200 ggc: Reduce GGC_QUIRE_SIZE on Solaris/SPARC [PR115031] g++.dg/modules/pr99023_b.X currently FAILs on 32-bit Solaris/SPARC: FAIL: g++.dg/modules/pr99023_b.X -std=c++2a 1 blank line(s) in output FAIL: g++.dg/modules/pr99023_b.X -std=c++2a (test for excess errors) Excess errors: cc1plus: out of memory allocating 1048344 bytes after a total of 7913472 bytes It turns out that this exhaustion of the 32-bit address space happens due to a combination of three issues: * the SPARC pagesize of 8 kB, * ggc-page.cc's chunk size of 512 * pagesize, i.e. 4 MB, and * mmap adding two 8 kB unmapped red-zone pages to each mapping which result in the 4 MB mappings to actually consume 4.5 MB of address space. To avoid this, this patch reduces the chunk size so it remains at 4 MB even when combined with the red-zone pages, as recommended by mmap(2). Tested on sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11. 2024-05-29 Rainer Orth gcc: PR c++/115031 * config/sparc/sol2.h (GGC_QUIRE_SIZE): Define as 510.
[Bug ada/115292] New: [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115292 Bug ID: 115292 Summary: [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Host: i686-darwin17 Target: i686-darwin17 Build: i686-darwin17 The fail occurs in stage #3 building libs. What is special about this configuration is that we are building i686-darwin17 on an x86_64-darwin17 box (I would expect this to be analogous to building i686-linux on a x86_64-linux box which has the 32b runtimes installed (but I did not try to relicate this there). So far this is the only version of Darwin (which supports this mode) on which I've tried this (it is a perfectly valid configuration and is expected to work). On a 32b host, the same revision (r15-889) built OK although there are massive [10s] (unanalysed) Acats regressions on earlier Darwin platforms (so I think things have become a bit unstable recently). Unfortunately, I don't have time to analyze further right now - but this at least brackets the change to a smallish commit range. === Depending on the jN we get different sources failing: +===GNAT BUG DETECTED==+ | 15.0.0 20240529 (experimental) [master revision r15-889-g241a6cc88d86] (i686-apple-darwin17) | | Assert_Failure sem_ch12.adb:17782| | Error detected at a-string.ads:27:66 | | Compiling g-socpol.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ The assert is in "function Save_And_Reset" if Indexed_Assoc.Act_Id'Valid then Result_Pair.Actual_Id := Indexed_Assoc.Act_Id; else pragma Assert (Index = Result'Last); Result_Pair.Actual_Id := Empty; end if;
[Bug middle-end/115277] [13/14/15 regression] ICF needs to match loop bound estimates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277 --- Comment #2 from Martin Jambor --- (In reply to Jan Hubicka from comment #1) > Reproduces on 14 and trunk. GCC 12 is not able to determine the loop bound > during early optimizations What about gcc 13?
[Bug c++/115291] armv8-a GCC emits float32x2_t loads from uninitialized stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115291
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
D.198035 = f (); [return slot optimization]
v.m_lhs = &D.198035;
MEM[(struct CwiseNullaryOp *)&v + 8B] ={v} {CLOBBER(bob)};
MEM[(struct scalar_constant_op *)&v + 12B] ={v} {CLOBBER(bob)};
MEM[(struct scalar_constant_op *)&v + 12B].m_other = 0.0;
D.198035 ={v} {CLOBBER(eos)};
_6 = &MEM[(struct Matrix *)_4(D)].D.198029;
_12 = v.m_lhs;
auto v = Eigen::Product(f(), Eigen::Vector2f::Zero());
The bug is there is a temporary created for the return value of f but that is
destoried at the end of the full statement but the product does not happen
until afterwards in the use of v happens.
Rewriting the code like:
```
auto t = f();
auto v = Eigen::Product(t, Eigen::Vector2f::Zero());
```
Fixes the code.
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803 --- Comment #8 from Alexandre Oliva --- -fsigned-char works around the fail on affected targets. I couldn't trigger it on arm-eabi, alas, not even with -funsigned-char.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #6 from Hans-Peter Nilsson ---
[...]
>> versions.) BTW, it'd be nice to know it it reproduces for sparc-linux as
>> well.
>
> I happen to have a Linux/sparc64 LDom around: I'll give it a whirl.
The failure is even earlier here: in a sparc64-unknown-linux-gnu
bootstrap, building a libstdc++ .gch file in stage 2 breaks:
n file included from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:60,
from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:64,
from
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/algorithm:60,
from
/vol/gcc/src/hg/master/solaris/libstdc++-v3/include/precompiled/stdc++.h:51:
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::integral_constant':
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:296:72:
required from here
296 |constexpr true_type __is_complete_or_unbounded(__type_identity<_Tp>)
| ^
/var/gcc/regression/master/6.8.9-gcc-gas-gld/build/sparc64-unknown-linux-gnu/libstdc++-v3/include/type_traits:92:17:
internal compiler error: tree check: expected tree that contains 'decl common'
structure, have 'function_decl' in tsubst_arg_types, at cp/pt.cc:15782
92 | constexpr operator value_type() const noexcept { return value; }
| ^~~~
0xfff8000100a2f087 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0xfff8000100a2f1a3 __libc_start_main_impl
./csu/libc-start.c:360
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #35 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #31) > Bisection points to r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 for > that remaining FAIL as well (and it isn't fixed by the new patch). > > It introduced a new warning which wasn't present before: > > /tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437: > warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' > writing between 2 and 9223372036854775806 bytes into a region of size 0 > overflows the destination [-Wstringop-overflow=] I don't know why we only get a warning for C++98 and not other modes, but this seems to fix it: --- a/libstdc++-v3/include/bits/vector.tcc +++ b/libstdc++-v3/include/bits/vector.tcc @@ -933,6 +933,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER const size_type __len = _M_check_len(__n, "vector::_M_range_insert"); + if (__len < (__n + (__old_finish - __old_start))) + __builtin_unreachable(); + pointer __new_start(this->_M_allocate(__len)); pointer __new_finish(__new_start); __try So it looks like the compiler can't tell that _M_check_len(n) doesn't undergo unsigned wraparound.
[Bug libstdc++/115285] [12/13/14/15 Regression] std::unordered_set can have duplicate value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #10 from Jonathan Wakely ---
When deciding whether a key already exists in the hash set we use these
overloads:
template
static __conditional_t<
__and_<__is_nothrow_invocable<_Hash&, const key_type&>,
__not_<__is_nothrow_invocable<_Hash&, _Kt>>>::value,
key_type, _Kt&&>
_S_forward_key(_Kt&& __k)
{ return std::forward<_Kt>(__k); }
static const key_type&
_S_forward_key(const key_type& __k)
{ return __k; }
If the value being inserted, __k, can be hashed directly using the hash
function then we return it unchanged, and then hash it. If it can't be hashed
directly, we convert it to the container's key_type, which is TrimmedStr.
In this case, a std::string can be hash directly without constructing a
TrimmedStr (because of the questionable std::hash specialization using
inheritance). So we don't convert it to TrimmedStr and just hash it directly.
Hashing "foo"s and "foo "s give different hash values, so we do not consider
them to be equivalent keys.
While I think the code is highly questionable, the standard does say that
inserting [first, last) is equivalent to insert(*first) for each iterator, and
that would force an implicit conversion to value_type.
So I'm not sure if the optimization to avoid temporaries (PR 96088) is actually
allowed by the standard.
[Bug libstdc++/115285] [12/13/14/15 Regression] std::unordered_set can have duplicate value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #7)
> I am suspecting it was
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=2c43f5ec9db163696de8691eb529df06c4999bcc which caused the issue.
Ah no, I think you're right about this.
The problem is not std::equal_to, but in std::hash, because it
takes an argument of type std::string not TrimmedStr.
This means that hashing "foo "s does not convert to a TrimmedStr first, so it
hashes the un-trimmed string.
This fixes the code:
template<> struct hash {
bool operator()(const TrimmedStr& s) const noexcept
{ return std::hash{}(s); }
};
I'm not sure if the code is valid or not. It certainly seems like a problem
that a plain std::string can be compared to a TrimmedStr using
std::equal_to *and* can be hashed using std::hash, when
a plain std::string is *not* a TrimmedStr.
Using inheritance this way is a bad idea, certainly for the std::hash
specialization. IMHO also for the TrimmedStr itself.
[Bug target/115102] [SH] GCC misunderstands swap.b instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115102
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> though on x86 there's no high word preserving swap of the lower 2 bytes.
There is, please try:
asm ("xchgb %h0, %b0" : "+Q" (val));
like:
--cut here--
#include
#include
uint32_t __attribute__((noinline))
bswap8(uint32_t val)
{
return (val & 0x) | ((val & 0xff00) >> 8) | ((val & 0xff) << 8);
}
uint32_t __attribute__((noinline))
bswap8_new(uint32_t val)
{
asm ("xchgb %h0, %b0" : "+Q" (val));
return val;
}
int main ()
{
uint32_t a = 0x10325476;
printf ("%x %x\n", bswap8 (a), bswap8_new (a));
return 0;
}
--cut here--
we already have:
(define_insn "bswaphi_lowpart"
[(set (strict_low_part (match_operand:HI 0 "register_operand" "+Q,r"))
(bswap:HI (match_dup 0)))
(clobber (reg:CC FLAGS_REG))]
""
"@
xchg{b}\t{%h0, %b0|%b0, %h0}
rol{w}\t{$8, %0|%0, 8}"
but bswaphi2 named pattern is enabled only for TARGET_MOVBE.
Time to fix this ;)
[Bug libstdc++/115285] [12/13/14/15 Regression] std::unordered_set can have duplicate value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #8 from Jonathan Wakely ---
Or r12-6272-ge3ef832a9e8d6a
I think the testcase is invalid. The unordered_set uses
std::equal_to to decide if a key already exists in the container,
and that just uses operator== which is not defined for TrimmedStr, so it uses
the equality comparison for std::string. When that is used to compare
TrimmedStr("foo") == "foo "s it's equivalent to "foo"s == "foo "s which is
obviously false.
[Bug c++/115291] New: armv8-a GCC emits float32x2_t loads from uninitialized stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115291
Bug ID: 115291
Summary: armv8-a GCC emits float32x2_t loads from uninitialized
stack
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akihiko.odaki at daynix dot com
Target Milestone: ---
Run the following commands:
git clone https://gitlab.com/libeigen/eigen.git -b
38b9cc263bbaeb03ce408a4e26084543a6c0dedb
cat main.cpp <<'EOF'
#include "Eigen/Core"
auto f() -> Eigen::Matrix2f {
return Eigen::Matrix2f::Zero();
}
auto g() -> Eigen::Vector2f {
auto v = Eigen::Product(f(), Eigen::Vector2f::Zero());
return v;
}
EOF
c++ -Ieigen -O1 -DNDEBUG main.cpp -S
Now main.s looks like:
.arch armv8-a
.file "main.cpp"
.text
.align 2
.global _Z1fv
.type _Z1fv, %function
_Z1fv:
.LFB13241:
.cfi_startproc
mov x0, x8
str wzr, [x8]
str wzr, [x8, 4]
str wzr, [x8, 8]
str wzr, [x8, 12]
ret
.cfi_endproc
.LFE13241:
.size _Z1fv, .-_Z1fv
.align 2
.global _Z1gv
.type _Z1gv, %function
_Z1gv:
.LFB13246:
.cfi_startproc
sub sp, sp, #16
.cfi_def_cfa_offset 16
mov x0, x8
moviv30.2s, 0
ldr d31, [sp]
fmulv31.2s, v31.2s, v30.2s
ldr d29, [sp, 8]
fmlav31.2s, v29.2s, v30.2s
str d31, [x8]
add sp, sp, 16
.cfi_def_cfa_offset 0
ret
.cfi_endproc
.LFE13246:
.size _Z1gv, .-_Z1gv
.align 2
.type _GLOBAL__sub_I__Z1fv, %function
_GLOBAL__sub_I__Z1fv:
.LFB14439:
.cfi_startproc
ret
.cfi_endproc
.LFE14439:
.size _GLOBAL__sub_I__Z1fv, .-_GLOBAL__sub_I__Z1fv
.ident "GCC: (GNU) 14.1.1 20240507 (Red Hat 14.1.1-1)"
.section.note.GNU-stack,"",@progbits
In _Z1gv, "ldr d31, [sp]" loads values from nowhere.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Hans-Peter Nilsson --- > BTW, I see the target list says sparc*-sun-solaris2.11 which seems a cutnpasto > from some ancient template: that particular version is installed on cfarm211 It's not: I've tried bootstraps on sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11 to check if it's just a 32-bit issue. > and a build log for a recent gcc checkout says "Configuration > sparc-sun-solaris2.11 not supported" for the gcc dir. (Please correct the While the configure triples have no way to distinguish between Solaris 11.3 and 11.4, gcc/config.gcc explicitly checks for hosts running 11.4. But I see what you mean: that's an error of mine moving 11.3 from obsolete to unsupported. The message should say sparc-sun-solaris2.11.3 not supported instead. Will fix. > versions.) BTW, it'd be nice to know it it reproduces for sparc-linux as > well. I happen to have a Linux/sparc64 LDom around: I'll give it a whirl.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Hans-Peter Nilsson --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > >> You should use cfarm216 instead: it's way faster than the others and >> runs Solaris 11.4, which is the only OS release supported on trunk. > I can't reach cfarm216, something with my ssh setup is too old. :( Strange: you're the first to report such an issue, and there are quite a number of users of the system. > Also, I just realized it can't be a plain NULL basic_block, because that'd > have > shown a SEGV in resource.c. All the more interest in a way to reproduce on > cfarm210 or cfarm211. There's no point in trying: trunk isn't supported on either Solaris 10 (cfarm210) or Solaris 11.3 (cfarm211). >> Ok. For this night's bootstrap, I'm using the tree at the revision >> before the culprit patch. I tried to revert just that one, but failed >> (conflicts and manual resolution failed compiling stage 1 libgcc). > There's two other commits after the culprit, that depends on it functionally > and contextually, so you have to revert those too. I suspected that much, but was in a bit of hurry to get the bootstraps going before I went to bed. > Either way, if you prefer to revert (the failing one and the two after that > one > obviously in opposite order, I'd be thankful. I'll likely land there myself > as > I currently have no way to reproduce the problem. I've no problem with just reverting locally for a day or two.
[Bug target/115102] [SH] GCC misunderstands swap.b instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115102 --- Comment #3 from Paul Cercueil --- Created attachment 58313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58313&action=edit Proposed fix Attached is the proposed fix. Credits go to Oleg for the original solution.
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #7 from Alexandre Oliva ---
FWIW, since the backport, this test started failing in gcc-13 on arm and
aarch64 targets. Presumably this affects earlier branches as well.
.../libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: In
instantiation of 'void maybe_test() [with T = char]':
.../libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc:87:
required from here
.../libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc:68:
error: invalid 'static_cast' from type 'V' {aka
'std::experimental::parallelism_v2::simd >'} to type
'uint8x16_t'
[Bug c/115290] New: tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290
Bug ID: 115290
Summary: tree check fail in c_tree_printer, at
c/c-objc-common.cc:330
Product: gcc
Version: unknown
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:
$ more bug1029.c
typedef enum { SERVER_HELLO_DONE } message_type_t;
message_type_t handshakes[256][32], tls13_handshakes[256][32];
void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes; }
$
compiled as follows:
$ ~/gcc/results/bin/gcc -c -Wall bug1029.c
does this:
bug1029.c:3:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
3 | void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes;
}
| ^~~~
bug1029.c: In function ‘main’:
bug1029.c:3:51: warning: comparison between two arrays [-Warray-compare]
3 | void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes;
}
| ^~
tree check: expected tree that contains ‘decl minimal’ structure, have
‘cond_exp
r’ in c_tree_printer, at c/c-objc-common.cc:330
3 | void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes;
}
| ^~~~
0x81bb1e tree_contains_struct_check_failed(tree_node const*,
tree_node_structure
_enum, char const*, int, char const*)
../../trunk.20210101/gcc/tree.cc:9169
0x6e18a8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*
, int, char const*)
../../trunk.20210101/gcc/tree.h:3770
0x6e18a8 c_tree_printer
../../trunk.20210101/gcc/c/c-objc-common.cc:330
The bug first appeared sometime before git hash 28b508233a12c132.
[Bug target/115289] New: PPC: Document the machine constraint 'Y' and make it non-internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115289
Bug ID: 115289
Summary: PPC: Document the machine constraint 'Y' and make it
non-internal
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mpe+gcc at ellerman dot id.au
Target Milestone: ---
Please document the "Y" inline asm constraint for powerpc. It's needed to
correctly pass arbitrary pointer arguments to inline asm using a DS-form
instruction.
The Linux Kernel plans to use the constraint, see:
https://lore.kernel.org/linuxppc-dev/20240529123029.146953-1-...@ellerman.id.au/
A minimal reproducer for the problem seen in the kernel is below.
$ cat test.c
struct {
long a;
long b;
short c;
char d[8];
} e;
void f(void) {
unsigned long v = 0;
unsigned long *g = (unsigned long *)&e.d;
asm goto("std%X0 %1,%0# put_user\n" : "=m"(*g) : "r"(v) : : out);
out:
}
$ gcc-14 -Wall -nostdinc -O2 -c -o test.o test.c
/tmp/ccsSkWJz.s: Assembler messages:
/tmp/ccsSkWJz.s:21: Error: operand out of domain (18 is not a multiple of 4)
[Bug plugins/115288] New: File label-text.h not part of installation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115288 Bug ID: 115288 Summary: File label-text.h not part of installation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I have just tried a linux kernel build with this morning's gcc trunk compiler and I got this: home/dcb40b/gcc/results.20240530.asan.ubsan/lib/gcc/x86_64-pc-linux-gnu/15.0.0/plugin/include/rich-location.h:25:10: fatal error: label-text.h: No such file or directory 25 | #include "label-text.h" | ^~ Doing this $ cp /home/dcb40b/gcc/trunk.20210101/libcpp/include/label-text.h /home/dcb40b/gcc/results.20240530.asan.ubsan/bin/../lib/gcc/x86_64-pc-linux-gnu/15.0.0/plugin/include/ $ seems to solve the problem. It looks to me like someone forgot to add file label-text.h to some list in the install make target.
[Bug rtl-optimization/101169] [10 regression] test case gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r10-9880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101169 --- Comment #7 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:ac5c6c90a7f1f432fe19bc058d70b08967c25e3e commit r15-923-gac5c6c90a7f1f432fe19bc058d70b08967c25e3e Author: Alexandre Oliva Date: Wed May 29 02:52:18 2024 -0300 [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract* Codegen changes caused add instruction count mismatches on ppc-*-linux-gnu and other 32-bit ppc targets. At some point the expected counts were adjusted for lp64, but ilp32 differences remained, and published test results confirm it. for gcc/testsuite/ChangeLog PR testsuite/101169 * gcc.target/powerpc/fold-vec-extract-double.p7.c: Adjust addi counts for ilp32. * gcc.target/powerpc/fold-vec-extract-float.p7.c: Likewise. * gcc.target/powerpc/fold-vec-extract-float.p8.c: Likewise. * gcc.target/powerpc/fold-vec-extract-int.p7.c: Likewise. * gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise. * gcc.target/powerpc/fold-vec-extract-short.p7.c: Likewise. * gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise.
