[Bug c++/116981] wrongly accepted non-more-specialized partial specialization of class template member for an instantiated enclosing template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981 --- Comment #7 from mauro russo --- ok. Maybe the comment in PR 32071 about this as duplicated may also be removed.
[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945 philippe.waroquiers at skynet dot be changed: What|Removed |Added CC||philippe.waroquiers@skynet. ||be --- Comment #10 from philippe.waroquiers at skynet dot be --- (In reply to Mark Wielaard from comment #8) > (In reply to Eric Botcazou from comment #7) > > > Sure. But I assume the unitialized part isn't accessed when resolving the > > > 'Valid attribute. Does checking for the 'Valid attribute depend on any > > > uninitialized bits? > > > > Testing 'Valid means comparing the value with the allowed range, so how can > > you do that without accessing that value? > > I don't know, my Ada foo isn't very strong. How is the allowed range > defined? How do you test for it? Doesn't that mean the value needs to be > defined at least for that range check? If not, is the 'Valid attribute check > non-deterministic because you cannot rely on the value being or not being in > the allowed range? The allowed range is defined as part of the type or subtype definition. For example, you can declare a new type such as: type Month is new Integer range 1 .. 12; The 'Valid attribute will then check that the variable is in the range. It is for sure a little bit special to use 'Valid with non initialized values. (a more classical usage is to check that some binary value read from a file or network or ... is in the allowed range).
[Bug tree-optimization/116990] [15 Regression] ICE on valid code at -O3 "-fno-tree-ccp -fno-tree-loop-im -fno-tree-dse" on x86_64-linux-gnu: in single_pred_edge, at basic-block.h:342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116990 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Version|unknown |15.0 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116879 Summary|ICE on valid code at -O3|[15 Regression] ICE on |"-fno-tree-ccp |valid code at -O3 |-fno-tree-loop-im |"-fno-tree-ccp |-fno-tree-dse" on |-fno-tree-loop-im |x86_64-linux-gnu: in|-fno-tree-dse" on |single_pred_edge, at|x86_64-linux-gnu: in |basic-block.h:342 |single_pred_edge, at ||basic-block.h:342 Last reconfirmed||2024-10-06 Target Milestone|--- |15.0 --- Comment #1 from Andrew Pinski --- Confirmed. Looks to be introduced by r15-3960-g18e905b461a713 .
[Bug middle-end/116994] New: [15 regression] GCC trunk generates larger code than GCC 14 at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116994
Bug ID: 116994
Summary: [15 regression] GCC trunk generates larger code than
GCC 14 at -Os
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dccitaliano at gmail dot com
Target Milestone: ---
I found this at -Os and I figured I could report it. For this specific
(reduced) small example, GCC trunk generates code that's 7% larger than GCC
14.
long patatino() {
long x = 0;
for (int i = 0; i < 5; ++i) {
while (x < 10) {
x += ((x % 2 == 0 && x % 3 != 0 && x % 7 != 0) ||
(x % 2 != 0 && x % 5 == 0 && x % 11 != 0)) ? 2 : 1;
}
}
return x;
}
Godbolt example: https://godbolt.org/z/3bqfq4nM7
[Bug lto/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #29 from Sam James --- Honza, can you try with --enable-checking=yes,extra,rtl? I couldn't reproduce with release checking (and maybe even default too).
[Bug lto/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #30 from Andrew Pinski --- What I found is that the testcases are very much violatile on producing or not. Even different slightly different whitespaces and/or line #s sometimes cause no longer to reproduce the issue. Even using slightly different gc parameters will cause no longer to reproduce the issue. That is using both =0 or both =1, while =1 can reproduce it but =0 does not.
[Bug target/116994] [15 regression] GCC trunk generates larger code than GCC 14 at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116994 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |15.0 --- Comment #1 from Andrew Pinski --- So this looks like just an accident. One extra callee saved register usage (rbx) caused by using a cmov instead of branch. testq %rdx, %rdx cmovne %rbx, %rsi vs: testq %rdx, %rdx je .L4 movl$2, %esi .L4:
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #378 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #375)
> (In reply to Kazumoto Kojima from comment #374)
> > Created attachment 59286 [details]
> > a patch for c#367
> >
> > We use movsf_ie as a fall-back for for moving fp-reg from/to multiword
> > subreg in 59190. Looks this confuses LRA with the SI mode scratch
> > constrained to "y".
> >
> > The patch uses a new pattern instead of movsf_ie. It's a mini movsf_ie in a
> > sense but with the SFmode scratch.
> >
> > Tested only with target libgcc/libstdc++v3 build and c testsuite.
>
> I've updated my branch https://github.com/olegendo/gcc/commits/devel/sh-lra/
>
> * Merged the patch from comment #374 into the commit "SH: Try to workaround
> fp-reg related move insns pt.2".
>
> * Tidied up the other patches on the stash a bit (add/fix commit messages,
> ..)
>
> * The patch "SH: Tighten memory predicates and constraints" now seems to
> work without LRA. At least the testsuite on sh-sim for the common variants
> shows no new failures. My plan is to merge this commit into mainline soon,
> as a start.
>
> Briefly confirmed that the previous problematic cases mentioned here still
> work with it (will add them to the testsuite eventually). Also confirmed
> that sh-elf / newlib toolchain and target libs can build OK. Testsuite
> results pending. Hope I didn't miss anything, please re-confirm if you have
> a chance.
I just tried a full bootstrap using that tree with all languages but Rust and
Go enabled and it fails with:
during RTL pass: subreg3
../../gcc/ipa-sra.cc: In function 'void
{anonymous}::isra_read_edge_summary(lto_input_block*, cgraph_edge*)':
../../gcc/ipa-sra.cc:2933:1: internal compiler error: in
decompose_multiword_subregs, at lower-subreg.cc:1731
2933 | }
| ^
/home/glaubitz/gcc-oleg/build/./prev-gcc/xg++
-B/home/glaubitz/gcc-oleg/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -nostdinc++
-B/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/include/sh4-unknown-linux-gnu
-I/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/include
-I/home/glaubitz/gcc-oleg/libstdc++-v3/libsupc++
-L/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fPIC -c -g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -DHAVE_CONFIG_H -fPIC -I. -Irtl-ssa -I../../gcc
-I../../gcc/rtl-ssa -I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libcody -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace
-o rtl-ssa/functions.o -MT rtl-ssa/functions.o -MMD -MP -MF
rtl-ssa/.deps/functions.TPo ../../gcc/rtl-ssa/functions.cc
0x3560f93 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x35261e3 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1512
0x32a5bcf decompose_multiword_subregs
../../gcc/lower-subreg.cc:1731
0x32a625f execute
../../gcc/lower-subreg.cc:1894
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
Will test Kaz's patch seprately applied to sh-lra-take3.
[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #5 from Feng Xue ---
(In reply to Tamar Christina from comment #4)
> (In reply to Richard Biener from comment #3)
> > I would suggest to add a STMT_VINFO_ENSURE_NOTRAP or so and delay actual
> > verification to vectorizable_load when both vector type and VF are fixed.
> > We'd then likely need a LOOP_VINFO_MUST_USE_PARTIAL_VECTORS_P set
> > conservatively the other way around from
> > LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P.
> > Alignment peeling could then peel if STMT_VINFO_ENSURE_NOTRAP and the target
> > cannot do full loop masking.
>
>
> Yeah the original reported testcase is fine as the alignment makes it safe.
> For the manually misaligned case that Andrew posted it makes sense to delay
> and re-evaluate later on.
>
> I don't think we should bother peeling though, I don't think they're that
> common and alignment peeling breaks some dominators and exposes some
> existing vectorizer bugs, which is being fixed in Alex's patch.
>
> So at least alignment peeling I'll defer to a later point and instead just
> reject loops that are loading from structures the user misaligned wrt to the
> vector mode.
>
>
> So mine..
Actually, what I wish is that we could allow vectorization on early break case
for arbitrary address pointer (knowing nothing about alignment and bound) based
on some sort of assumption specified via command option under -Ofast, as the
mentioned example:
char * find(char *string, size_t n, char c)
{
for (size_t i = 0; i < n; i++) {
if (string[i] == c)
return &string[i];
}
return 0;
}
and example for which there is no way to do peeling to align more than one
address pointers:
int compare(char *string1, char *string2, size_t n)
{
for (size_t i = 0; i < n; i++) {
if (string1[i] != string2[i])
return string1[i] - string2[i];
}
return 0;
}
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 --- Comment #5 from Andrew Pinski --- > but it is already in reliable real-world use. Then that real world use is broken. >It's a pretty isolated change and doesn't impact any later stages of >compilation. It is not exactly isolated, that is if there is an option, someone will try it and then get broken code. Did you run the full GCC testsuite with it turned on to see what breaks? Do you have a formal definition of what works with it and what does NOT? Why have a seperate option for the seed? Rather than reuse -frandomize-layout-seed ? Is it because you want to force folks to always use a different seed from the seed which is going to be there for reproducibility or just because it is another obscure option? This could introduce new security issues just by having it, rather than security by obscurity. For an example someone's code is not ready for this layout change but then it messes up. Also why only C and not C++? At least in C++ you have local linkage structs (e.g. structs defined inside an anonymous namespaces) so you don't have a push to force things to be consistent between TUs. Does clang (or the plugin) warn if a struct with randomize_layout is used with an exported symbol? what about taking the address and then passing it around? Do es it have some kind of flow sensitive warning because without that it is 100% a security issue waiting to happen.
[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #6 from Tamar Christina ---
> Actually, what I wish is that we could allow vectorization on early break
> case for arbitrary address pointer (knowing nothing about alignment and
> bound) based on some sort of assumption specified via command option under
> -Ofast, as the mentioned example:
>
> char * find(char *string, size_t n, char c)
> {
> for (size_t i = 0; i < n; i++) {
> if (string[i] == c)
> return &string[i];
> }
> return 0;
> }
>
> and example for which there is no way to do peeling to align more than one
> address pointers:
>
> int compare(char *string1, char *string2, size_t n)
> {
> for (size_t i = 0; i < n; i++) {
> if (string1[i] != string2[i])
> return string1[i] - string2[i];
> }
> return 0;
> }
in Alex's patch for alignment peeling we'll allow them by inserting a mutual
alignment check between all the pointers when not fully masked. This should be
upstream soon.
For fully masked architectures we can do better by using First Faulting Loads
here, but that won't be ready for GCC 15.
[Bug tree-optimization/116985] [15 Regression] ICE in vectorizer with --param=vect-partial-vector-usage=2 -mavx512vbmi2 since r15-2097-gdb3c8c9726d0ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116985 --- Comment #1 from Andrew Pinski --- Created attachment 59287 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59287&action=edit Reduced testcase
[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112358 --- Comment #11 from John David Anglin --- glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32245
[Bug tree-optimization/116985] [15 Regression] ICE in vectorizer with --param=vect-partial-vector-usage=2 -mavx512vbmi2 since r15-2097-gdb3c8c9726d0ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116985 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-10-06 Status|UNCONFIRMED |NEW Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu aarch64 --- Comment #2 from Andrew Pinski --- Also ICEs on aarch64 with `--param=vect-partial-vector-usage=2 -march=armv9-a -O2`.
[Bug libstdc++/116991] New: FAIL: 26_numerics/complex/ext_c++23.cc -std=gnu++23 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116991 Bug ID: 116991 Summary: FAIL: 26_numerics/complex/ext_c++23.cc -std=gnu++23 (test for excess errors) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc -B/ho me/dave/gnu/gcc/objdir64/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir64/hppa64- hp-hpux11.11/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/ libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc ++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/ -B/opt/gn u64/gcc/gcc-15/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-15/hppa64-hp -hpux11.11/include -isystem /opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-includ e -fchecking=1 -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/ src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-section s -O2 -g -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/home/dave/gnu/gcc/objdir64/hp pa64-hp-hpux11.11/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/g cc/gcc/libstdc++-v3/testsuite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite /26_numerics/complex/ext_c++23.cc -std=gnu++23 -include bits/stdc++.h -fdiagnost ics-plain-output ./libtestc++.a -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.1 1/libstdc++-v3/src/experimental/.libs -lm -o ./ext_c++23.exe In file included from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++- v3/include/ccomplex:41, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++- v3/include/hppa64-hp-hpux11.11/bits/stdc++.h:127, from : /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex: In instantiation of 'std::complex<_Tp> std::__complex_acos(const complex<_Tp>&) [w ith _Tp = _Float32]': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:222 7: required from 'std::complex<_Tp> std::acos(const complex<_Tp>&) [with _Tp = _Float32]' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:3 9: required from 'void test_functions(T*, std::complex<_Tp>*) [with T = _Float 32]' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:6 2: required from here /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:204 3: warning: ISO C++ does not allow converting to '_Float32' from 'long double' w ith greater conversion rank [-Wnarrowing] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex: In instantiation of 'std::complex<_Tp> std::__complex_acos(const complex<_Tp>&) [w ith _Tp = _Float64]': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2227: required from 'std::complex<_Tp> std::acos(const complex<_Tp>&) [with _Tp = _Float64]' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:39: required from 'void test_functions(T*, std::complex<_Tp>*) [with T = _Float64]' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:69: required from here /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2043: warning: ISO C++ does not allow converting to '_Float64' from 'long double' with greater conversion rank [-Wnarrowing] FAIL: 26_numerics/complex/ext_c++23.cc -std=gnu++23 (test for excess errors) Excess errors: /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2043: warning: ISO C++ does not allow converting to '_Float32' from 'long double' with greater conversion rank [-Wnarrowing] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2043: warning: ISO C++ does not allow converting to '_Float64' from 'long double' with greater conversion rank [-Wnarrowing] Similar fail: FAIL: 26_numerics/complex/ext_c++23.cc -std=gnu++26 (test for excess errors)
[Bug libstdc++/116992] New: FAIL: 30_threads/semaphore/platform_try_acquire_for.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116992 Bug ID: 116992 Summary: FAIL: 30_threads/semaphore/platform_try_acquire_for.cc -std=gnu++20 (test for excess errors) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc -B/ho me/dave/gnu/gcc/objdir64/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir64/hppa64- hp-hpux11.11/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/ libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc ++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/ -B/opt/gn u64/gcc/gcc-15/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-15/hppa64-hp -hpux11.11/include -isystem /opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-includ e -fchecking=1 -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/ src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-section s -O2 -g -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/home/dave/gnu/gcc/objdir64/hp pa64-hp-hpux11.11/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/g cc/gcc/libstdc++-v3/testsuite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite /30_threads/semaphore/platform_try_acquire_for.cc -std=gnu++20 -D_GLIBCXX_USE_PO SIX_SEMAPHORE -pthread -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libat omic/ -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs -latom ic -fdiagnostics-plain-output ./libtestc++.a -L/home/dave/gnu/gcc/objdir64/hppa6 4-hp-hpux11.11/libstdc++-v3/src/experimental/.libs -lm -o ./platform_try_acquire _for.exe In file included from /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/s emaphore/try_acquire_for.cc:23, from /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/s emaphore/platform_try_acquire_for.cc:7: /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:4 9: error: '__semaphore_impl' has not been declared /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:5 3: error: '__semaphore_impl' has not been declared [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:5 5: error: '__semaphore_impl' does not name a type [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7 2: error: '_M_sem' was not declared in this scope [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7 6: error: '_M_sem' was not declared in this scope [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:8 0: error: '_M_sem' was not declared in this scope [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore: In constructor 'std::counting_semaphore<__least_max_value>::counting_semaphore(s td::ptrdiff_t)': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:5 9: error: class 'std::counting_semaphore<__least_max_value>' does not have any f ield named '_M_sem' [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore: In member function 'void std::counting_semaphore<__least_max_value>::release(std ::ptrdiff_t)': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7 3: error: '_M_sem' was not declared in this scope [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore: In member function 'void std::counting_semaphore<__least_max_value>::acquire()': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7 7: error: '_M_sem' was not declared in this scope [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore: In member function 'bool std::counting_semaphore<__least_max_value>::try_acquire ()': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:8 1: error: '_M_sem' was not declared in this scope [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore: In member function 'bool std::counting_semaphore<__least_max_value>::try_acquire _for(const std::chrono::duration<_Rep, _Period>&)': /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:8 6: error: '_M_sem' was not declared in this scope [-Wtemplate-body] /home/dave/gnu/gcc/objdir64/hppa
[Bug tree-optimization/116990] New: ICE on valid code at -O3 "-fno-tree-ccp -fno-tree-loop-im -fno-tree-dse" on x86_64-linux-gnu: in single_pred_edge, at basic-block.h:342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116990
Bug ID: 116990
Summary: ICE on valid code at -O3 "-fno-tree-ccp
-fno-tree-loop-im -fno-tree-dse" on x86_64-linux-gnu:
in single_pred_edge, at basic-block.h:342
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 14.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/GWej7xzKM
[526] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241006 (experimental) (GCC)
[527] %
[527] % gcctk -O3 -fno-tree-ccp -fno-tree-loop-im -fno-tree-dse -c small.c
during GIMPLE pass: vect
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in single_pred_edge, at basic-block.h:342
3 | int main() {
| ^~~~
0x25fd2a5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0xa7b60a fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1617
0x8f0f8d single_pred_edge(basic_block_def const*)
../../gcc-trunk/gcc/basic-block.h:342
0x8f0f8d single_pred(basic_block_def const*)
../../gcc-trunk/gcc/basic-block.h:361
0x8f0f8d vect_analyze_loop_form(loop*, vect_loop_form_info*)
../../gcc-trunk/gcc/tree-vect-loop.cc:1862
0x14d61ae vect_analyze_loop(loop*, vec_info_shared*)
../../gcc-trunk/gcc/tree-vect-loop.cc:3541
0x1523c03 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.cc:1070
0x1523c03 try_vectorize_loop
../../gcc-trunk/gcc/tree-vectorizer.cc:1186
0x15244dc execute
../../gcc-trunk/gcc/tree-vectorizer.cc:1302
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[528] %
[528] % cat small.c
extern void f();
int a, b, c, d;
int main() {
int e, *g;
if (a)
while (1) {
g = &c;
if (a)
f();
for (b = 2; b; b--)
g = &e;
if (g == &e)
if (a && d)
return 0;
e = 0;
}
return 0;
}
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #379 from Oleg Endo --- (In reply to Oleg Endo from comment #375) > > I've updated my branch https://github.com/olegendo/gcc/commits/devel/sh-lra/ > > Testsuite results pending. Comparing latest commit 90d5d797 (LRA enabled) vs. "SH: Tighten memory predicates and constraints" 5a53b0a (LRA disabled) New failues: sh-sim/-m2/-mb: FAIL: 20_util/hash/chi2_q_uniform_random.cc -std=gnu++17 execution test FAIL: 23_containers/map/modifiers/swap/2.cc -std=gnu++17 execution test FAIL: 23_containers/map/modifiers/swap/3.cc -std=gnu++17 execution test FAIL: 23_containers/set/modifiers/swap/2.cc -std=gnu++17 execution test FAIL: 23_containers/set/modifiers/swap/3.cc -std=gnu++17 execution test FAIL: 23_containers/unordered_map/erasure.cc -std=gnu++20 execution test FAIL: 23_containers/unordered_map/erasure.cc -std=gnu++26 execution test FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36 sh-sim/-m2/-ml: FAIL: 20_util/hash/chi2_q_uniform_random.cc -std=gnu++17 execution test FAIL: 23_containers/map/modifiers/swap/2.cc -std=gnu++17 execution test FAIL: 23_containers/map/modifiers/swap/3.cc -std=gnu++17 execution test FAIL: 23_containers/set/modifiers/swap/2.cc -std=gnu++17 execution test FAIL: 23_containers/set/modifiers/swap/3.cc -std=gnu++17 execution test FAIL: 23_containers/unordered_map/erasure.cc -std=gnu++20 execution test FAIL: 23_containers/unordered_map/erasure.cc -std=gnu++26 execution test FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36 sh-sim/-m2a/-mb: FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O3 -g FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36 sh-sim/-m4/-mb: FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O3 -fomit-frame-pointer -funro
[Bug lto/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #26 from Jan Hubicka --- GGC should not release blocks that are still in use. They are linked by function's block tree and only if dead they are removed by tree-ssa-live.cc So the question is why that expr has dangliing pointer to dead scope block. We also stream out blocks by: stream_write_tree_ref (ob, TREE_BLOCK (expr)) in tree-streamer-out.C, so removing that call will just postpone the problem to later ICE.
[Bug lto/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #27 from Jan Hubicka --- Hmm, I can not seem to reproduce it. Basically we need to work out why that expression is streamed. If it is part of function body or part of summary. For summary it may be missing call to unshare_expr_without_location which IPA passes should do when pulling random expressions out of the function bodies.
[Bug libstdc++/116993] New: FAIL: g++.dg/tm/pr46270.C -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116993 Bug ID: 116993 Summary: FAIL: g++.dg/tm/pr46270.C -std=gnu++17 (test for excess errors) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++1/../../xg++ - B/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++1/../../ /home/dave/gnu/gcc/gcc/gc c/testsuite/g++.dg/tm/pr46270.C -fdiagnostics-plain-output -nostdinc++ -I/home/d ave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.1 1 -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include -I/home /dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/i nclude/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-l ength=0 -std=gnu++17 -fgnu-tm -S -o pr46270.s In file included from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++- v3/include/bits/new_allocator.h:34, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++- v3/include/hppa64-hp-hpux11.11/bits/c++allocator.h:33, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++- v3/include/bits/allocator.h:46, from /home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++- v3/include/list:65, from /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/tm/pr46270.C:5 : /home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:168:26: warning: new declarati on 'void* operator new(std::size_t, std::align_val_t)' ambiguates built-in decla ration 'void* operator new(long unsigned int, std::align_val_t) transaction_safe ' [-Wbuiltin-declaration-mismatch] /home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:179:26: warning: new declarati on 'void* operator new [](std::size_t, std::align_val_t)' ambiguates built-in de claration 'void* operator new [](long unsigned int, std::align_val_t) transactio n_safe' [-Wbuiltin-declaration-mismatch] FAIL: g++.dg/tm/pr46270.C -std=gnu++17 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:168:26: warning: new declaration 'void* operator new(std::size_t, std::align_val_t)' ambiguates built-in declaration 'void* operator new(long unsigned int, std::align_val_t) transaction_safe' [-Wbuiltin-declaration-mismatch] /home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:179:26: warning: new declaration 'void* operator new [](std::size_t, std::align_val_t)' ambiguates built-in declaration 'void* operator new [](long unsigned int, std::align_val_t) transaction_safe' [-Wbuiltin-declaration-mismatch] Similar fail: FAIL: g++.dg/tm/pr46270.C -std=gnu++26 (test for excess errors)
[Bug lto/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #28 from Eric Botcazou --- > We also stream out blocks by: > stream_write_tree_ref (ob, TREE_BLOCK (expr)) > in tree-streamer-out.C, so removing that call will just postpone the problem > to later ICE. Of course we'd remove all the bits that link expressions to their TREE_BLOCK in the LTO machiney, not just this particular call. Otherwise we'll probably be chasing this kind of dangling TREE_BLOCK for a while... unless we resort to kludges like unshare_expr_without_location of course!
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 --- Comment #8 from Arsen Arsenović --- (In reply to Andrew Pinski from comment #7) > (In reply to Arsen Arsenović from comment #6) > > (In reply to Andrew Pinski from comment #5) > > > > but it is already in reliable real-world use. > > > > > > Then that real world use is broken. > > > > > > >It's a pretty isolated change and doesn't impact any later stages of > > > >compilation. > > > > > > It is not exactly isolated, that is if there is an option, someone will > > > try > > > it and then get broken code. Did you run the full GCC testsuite with it > > > turned on to see what breaks? Do you have a formal definition of what > > > works > > > with it and what does NOT? > > That isn't really a useful measure - I suspect a lot of the testsuite would > > break with -Ofast forced-on, for instance. > > I am more worried about getting it correct and warning/error message > detection without that this feature should never go in because it is too > easy to shoot yourself in the foot. I'm not sure what's there to warn/error on. > On the -Ofast side of things, most of the ieee tests are limited to the ieee > directory on purpose since there are some floating point representations > that don't have NaNs/Infs (or denormals flush to zero); so I doubt there > will be much fall out even from -Ofast due to the tests happening in the > past on those targets (spu float for an example which was supported until I > think GCC 6). > > > > > > WRT possible user error, one needs to opt-in for this (via an attribute, but > > the plugin this'd replace currently also automatically shuffles vtable-style > > structs and I think that is a footgun but it is what it is) > > User error but allowing it is not a good idea. Again it should warn/error > out and there needs to be a lot of tests added. Otherwise you will get the > wrong answer even in the kernel sometimes and a security issue slipping in > due to incorrect usage is 100% not something you want. could you provide an example > > > > > Why have a seperate option for the seed? Rather than reuse > > > -frandomize-layout-seed ? Is it because you want to force folks to always > > > use a different seed from the seed which is going to be there for > > > reproducibility or just because it is another obscure option? > > > > I see at least one reason: not having to interact with Kconfig more than > > absolutely necessary. > > That is not answer to the question. Just what the Linux kernel does. the semantics of the two do not match. The STRING should be different for every file you compile. ^ this is not how -frandomize-layout-seed works > > > > > This could introduce new security issues just by having it, rather than > > > security by obscurity. For an example someone's code is not ready for this > > > layout change but then it messes up. > > > > > > Also why only C and not C++? At least in C++ you have local linkage > > > structs > > > (e.g. structs defined inside an anonymous namespaces) so you don't have a > > > push to force things to be consistent between TUs. > > this wouldn't be the first kernel-induced C-only feature, really > > And there was a movement to use C++ in the kernel. indeed - and sadly I don't think it went anywhere > Is there some mechanism in the design to make sure this does not leave the > TU? Because it is not obvious from any of the designs currently nor from > clang implementation (which is missing a lot of the warning/error part to > make sure it would still stay valid). no - there's no need for such prevention > > > > > Does clang (or the plugin) warn if a struct with randomize_layout is used > > > with an exported symbol? what about taking the address and then passing it > > > around? Do es it have some kind of flow sensitive warning because without > > > that it is 100% a security issue waiting to happen. > > no, the plugin is extremely primitive. due to the seed being constant > > across a kernel build, there isn't really a problem wrt linking TUs > > together. > > what happens if you have 2 structs marked as randomize_layout but the order > of the definition is different between 2 TUs? Then this breaks unless you > only have them not going outside the TU. > > If you allow outside of the TU usage, then that is 100% a security issue > because then you still need to write out somewhere the order and expose that > to maybe even modules. I'm not sure what you mean - yes, someone with access to the binaries with debug info or the sources with the randomization seed in them can recover the layouts - there's a presumption of no such access here. > This is why I said this is not a good idea at all > unless you can prove it does not go outside of the TU and from what I > understand that is not useful for the Linux kernel folks, they need > something that works across TUs. yes - and this does (the seed stays the same across the entire program)
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #381 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #378)
> I just tried a full bootstrap using that tree with all languages but Rust
> and Go enabled and it fails with:
>
> during RTL pass: subreg3
> ../../gcc/ipa-sra.cc: In function 'void
> {anonymous}::isra_read_edge_summary(lto_input_block*, cgraph_edge*)':
> ../../gcc/ipa-sra.cc:2933:1: internal compiler error: in
> decompose_multiword_subregs, at lower-subreg.cc:1731
Compression of the huge test case is still in progress. It seems it happens
for -O2 -fpic for the original test case. A quick look at an intermediate test
case with gdb shows that the compiler complains
(set (mem:QI (plus:SI (reg:SI 555)
(reg:SI 0 r0)) [0 S1 A8])
(subreg:QI (reg:DI 214 [ bp$word ]) 0))
can't be recognized. I've missed that devel/sh-lra removed the following
patterns
(define_insn "*mov_store_mem_index"
[(set (mem:QIHI
(plus:SI (match_operand:SI 0 "arith_reg_operand" "%r")
(match_operand:SI 1 "arith_reg_operand" "z")))
(match_operand:QIHI 2 "arith_reg_operand" "r"))]
"TARGET_SH1 && ! TARGET_SH2A && sh_lra_p ()
&& REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
"mov. %2,@(%1,%0)"
[(set_attr "type" "store")])
(define_insn "*movsf_ie_store_mem_index"
[(set (mem:SF
(plus:SI (match_operand:SI 0 "arith_reg_operand" "%r")
(match_operand:SI 1 "arith_reg_operand" "z")))
(match_operand:SF 2 "fp_arith_reg_operand" "f"))
(use (reg:SI FPSCR_MODES_REG))]
"TARGET_SH2E && sh_lra_p ()
&& REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
"fmov.s%2,@(%1,%0)"
[(set_attr "type" "store")])
(define_insn "*movsf_ie_load_mem_index"
[(set (match_operand:SF 0 "fp_arith_reg_operand" "=f")
(mem:SF
(plus:SI (match_operand:SI 1 "arith_reg_operand" "%r")
(match_operand:SI 2 "arith_reg_operand" "z"
(use (reg:SI FPSCR_MODES_REG))]
"TARGET_SH2E && sh_lra_p ()
&& REG_P (operands[2]) && REGNO (operands[2]) == R0_REG"
"fmov.s@(%2,%1),%0"
[(set_attr "type" "load")])
required as no-clobber versions of the similar patterns. The ICE in c#378 is
fixed here with adding the above patterns to devel/sh-lra.
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #9 from Andrew Pinski ---
(In reply to Arsen Arsenović from comment #8)
> > what happens if you have 2 structs marked as randomize_layout but the order
> > of the definition is different between 2 TUs? Then this breaks unless you
> > only have them not going outside the TU.
This part was never answered on the semantics here?
And the clang documentation for
frandomize-layout-seed/frandomize-layout-seed-file is weak.
Say you have (assuming all three have the randomize attribute on it)
header1:
```
struct a
{
...
};
```
header2:
```
struct b
{
...
};
```
You include header1 before header2 in TU1 but in TU2 the opposite is true.
Or say you sometimes include header3 which contains `struct c{...};`
how do you set the seed for each struct?
This is not documented at all.
The documentation for these 2 options in clang just say:
"File holding the seed used by the randomize structure layout feature"
Nothing more. The attribute randomize_layout is not even documented either.
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/111320 --- Comment #10 from Andrew Pinski --- Filed https://github.com/llvm/llvm-project/issues/111320 for the documentation of the attribute on the clang side. Let's see what happens there.
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #11 from Arsen Arsenović ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Arsen Arsenović from comment #8)
> > > what happens if you have 2 structs marked as randomize_layout but the
> > > order
> > > of the definition is different between 2 TUs? Then this breaks unless you
> > > only have them not going outside the TU.
>
> This part was never answered on the semantics here?
> And the clang documentation for
> frandomize-layout-seed/frandomize-layout-seed-file is weak.
>
> Say you have (assuming all three have the randomize attribute on it)
>
> header1:
> ```
> struct a
> {
> ...
> };
> ```
>
> header2:
> ```
> struct b
> {
> ...
> };
> ```
>
>
> You include header1 before header2 in TU1 but in TU2 the opposite is true.
>
> Or say you sometimes include header3 which contains `struct c{...};`
> how do you set the seed for each struct?
you don't - they all start from the same seed amended by the hash of the
structure name or something; see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/gcc-plugins/randomize_layout_plugin.c
in any case - it is stable
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #382 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #381)
> (In reply to John Paul Adrian Glaubitz from comment #378)
> > I just tried a full bootstrap using that tree with all languages but Rust
> > and Go enabled and it fails with:
> >
> > during RTL pass: subreg3
> > ../../gcc/ipa-sra.cc: In function 'void
> > {anonymous}::isra_read_edge_summary(lto_input_block*, cgraph_edge*)':
> > ../../gcc/ipa-sra.cc:2933:1: internal compiler error: in
> > decompose_multiword_subregs, at lower-subreg.cc:1731
>
> Compression of the huge test case is still in progress. It seems it happens
> for -O2 -fpic for the original test case. A quick look at an intermediate
> test case with gdb shows that the compiler complains
>
> (set (mem:QI (plus:SI (reg:SI 555)
> (reg:SI 0 r0)) [0 S1 A8])
> (subreg:QI (reg:DI 214 [ bp$word ]) 0))
>
> can't be recognized. I've missed that devel/sh-lra removed the following
> patterns
>
> (define_insn "*mov_store_mem_index"
> [(set (mem:QIHI
> (plus:SI (match_operand:SI 0 "arith_reg_operand" "%r")
> (match_operand:SI 1 "arith_reg_operand" "z")))
> (match_operand:QIHI 2 "arith_reg_operand" "r"))]
> "TARGET_SH1 && ! TARGET_SH2A && sh_lra_p ()
>&& REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
> "mov. %2,@(%1,%0)"
> [(set_attr "type" "store")])
>
> (define_insn "*movsf_ie_store_mem_index"
> [(set (mem:SF
>(plus:SI (match_operand:SI 0 "arith_reg_operand" "%r")
> (match_operand:SI 1 "arith_reg_operand" "z")))
>(match_operand:SF 2 "fp_arith_reg_operand" "f"))
> (use (reg:SI FPSCR_MODES_REG))]
> "TARGET_SH2E && sh_lra_p ()
>&& REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
> "fmov.s%2,@(%1,%0)"
> [(set_attr "type" "store")])
>
> (define_insn "*movsf_ie_load_mem_index"
> [(set (match_operand:SF 0 "fp_arith_reg_operand" "=f")
> (mem:SF
>(plus:SI (match_operand:SI 1 "arith_reg_operand" "%r")
> (match_operand:SI 2 "arith_reg_operand" "z"
>(use (reg:SI FPSCR_MODES_REG))]
> "TARGET_SH2E && sh_lra_p ()
>&& REG_P (operands[2]) && REGNO (operands[2]) == R0_REG"
> "fmov.s@(%2,%1),%0"
> [(set_attr "type" "load")])
>
> required as no-clobber versions of the similar patterns. The ICE in c#378
> is fixed here with adding the above patterns to devel/sh-lra.
OK, thanks. So it was wrong to remove these after all. I will modify the
corresponding commits and reinstate these patterns.
Instead of ...
&& REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
... could we also write it as...
(define_predicate "hard_reg_r0"
(and (match_code "reg")
(match_test "REGNO (op) == R0_REG")))
(match_operand:SI 1 "hard_reg_r0" "z")))
... if you have a chance, can you please try?
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 --- Comment #9 from John David Anglin --- Noticed in LRA testing - the label operand in the indirect_goto pattern is an input, not an output. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f6539107b8804bcc3532e748f3f596c5a8b29b44
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #380 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #378) > Will test Kaz's patch seprately applied to sh-lra-take3. This bootstraps fine (tested without Go and Rust). So, it's an issue with Oleg's tree.
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 --- Comment #10 from John David Anglin --- This commit https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=29f47b0929e00ef9b880e9157f156c78ff924f5b fixes an ICE in add_stores. The clobbers of the frame_pointer_rtx in the nonlocal_goto and builtin_setjmp patterns don't get hard registers with LRA. Fixed by removing them.
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 --- Comment #7 from Andrew Pinski --- (In reply to Arsen Arsenović from comment #6) > (In reply to Andrew Pinski from comment #5) > > > but it is already in reliable real-world use. > > > > Then that real world use is broken. > > > > >It's a pretty isolated change and doesn't impact any later stages of > > >compilation. > > > > It is not exactly isolated, that is if there is an option, someone will try > > it and then get broken code. Did you run the full GCC testsuite with it > > turned on to see what breaks? Do you have a formal definition of what works > > with it and what does NOT? > That isn't really a useful measure - I suspect a lot of the testsuite would > break with -Ofast forced-on, for instance. I am more worried about getting it correct and warning/error message detection without that this feature should never go in because it is too easy to shoot yourself in the foot. On the -Ofast side of things, most of the ieee tests are limited to the ieee directory on purpose since there are some floating point representations that don't have NaNs/Infs (or denormals flush to zero); so I doubt there will be much fall out even from -Ofast due to the tests happening in the past on those targets (spu float for an example which was supported until I think GCC 6). > > WRT possible user error, one needs to opt-in for this (via an attribute, but > the plugin this'd replace currently also automatically shuffles vtable-style > structs and I think that is a footgun but it is what it is) User error but allowing it is not a good idea. Again it should warn/error out and there needs to be a lot of tests added. Otherwise you will get the wrong answer even in the kernel sometimes and a security issue slipping in due to incorrect usage is 100% not something you want. > > > Why have a seperate option for the seed? Rather than reuse > > -frandomize-layout-seed ? Is it because you want to force folks to always > > use a different seed from the seed which is going to be there for > > reproducibility or just because it is another obscure option? > > I see at least one reason: not having to interact with Kconfig more than > absolutely necessary. That is not answer to the question. Just what the Linux kernel does. > > > This could introduce new security issues just by having it, rather than > > security by obscurity. For an example someone's code is not ready for this > > layout change but then it messes up. > > > > Also why only C and not C++? At least in C++ you have local linkage structs > > (e.g. structs defined inside an anonymous namespaces) so you don't have a > > push to force things to be consistent between TUs. > this wouldn't be the first kernel-induced C-only feature, really And there was a movement to use C++ in the kernel. Is there some mechanism in the design to make sure this does not leave the TU? Because it is not obvious from any of the designs currently nor from clang implementation (which is missing a lot of the warning/error part to make sure it would still stay valid). > > > Does clang (or the plugin) warn if a struct with randomize_layout is used > > with an exported symbol? what about taking the address and then passing it > > around? Do es it have some kind of flow sensitive warning because without > > that it is 100% a security issue waiting to happen. > no, the plugin is extremely primitive. due to the seed being constant > across a kernel build, there isn't really a problem wrt linking TUs together. what happens if you have 2 structs marked as randomize_layout but the order of the definition is different between 2 TUs? Then this breaks unless you only have them not going outside the TU. If you allow outside of the TU usage, then that is 100% a security issue because then you still need to write out somewhere the order and expose that to maybe even modules. This is why I said this is not a good idea at all unless you can prove it does not go outside of the TU and from what I understand that is not useful for the Linux kernel folks, they need something that works across TUs.
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 --- Comment #6 from Arsen Arsenović --- (In reply to Andrew Pinski from comment #5) > > but it is already in reliable real-world use. > > Then that real world use is broken. > > >It's a pretty isolated change and doesn't impact any later stages of > >compilation. > > It is not exactly isolated, that is if there is an option, someone will try > it and then get broken code. Did you run the full GCC testsuite with it > turned on to see what breaks? Do you have a formal definition of what works > with it and what does NOT? That isn't really a useful measure - I suspect a lot of the testsuite would break with -Ofast forced-on, for instance. WRT possible user error, one needs to opt-in for this (via an attribute, but the plugin this'd replace currently also automatically shuffles vtable-style structs and I think that is a footgun but it is what it is) > Why have a seperate option for the seed? Rather than reuse > -frandomize-layout-seed ? Is it because you want to force folks to always > use a different seed from the seed which is going to be there for > reproducibility or just because it is another obscure option? I see at least one reason: not having to interact with Kconfig more than absolutely necessary. > This could introduce new security issues just by having it, rather than > security by obscurity. For an example someone's code is not ready for this > layout change but then it messes up. > > Also why only C and not C++? At least in C++ you have local linkage structs > (e.g. structs defined inside an anonymous namespaces) so you don't have a > push to force things to be consistent between TUs. this wouldn't be the first kernel-induced C-only feature, really > Does clang (or the plugin) warn if a struct with randomize_layout is used > with an exported symbol? what about taking the address and then passing it > around? Do es it have some kind of flow sensitive warning because without > that it is 100% a security issue waiting to happen. no, the plugin is extremely primitive. due to the seed being constant across a kernel build, there isn't really a problem wrt linking TUs together. FWIW, I mentioned at Cauldron that I have a fix that makes the plugin not break debug info generation, that'd also work for this case I think. I'm yet to polish it because testing the Linux side of it seems non-trivial, and because I'll need to edit all frontends to add the new hook, so testing the GCC side is also not too trivial. I need to finish up a lot of non-GCC-related work currently, though :/ doing this in the C frontend only solves some of those issues, though ;)
[Bug middle-end/116920] GCC should warn about fall through from a case to a default (without any expressions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116920 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- (In reply to Xi Ruoyao from comment #0) > In this test case "case 1919:" is either redundant, De facto redundant, sure. > or indicating a > programming error. Thus it'd be better if we emit a warning here. That's debatable. A special warning option may be in order, but I can very well see the above as a coding style issue, with arguments for both sides.
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 --- Comment #12 from Andrew Pinski --- (In reply to Kees Cook from comment #4) > This feature is designed as a "security through obscurity" feature that has > real-world benefits to specialized high-security deployments where > performance is not a concern. > > It is never expected to be compatible with the C standard; it operates as a > language extension. And it is C only -- there's no desire to have this work > with C++. > > As for "security issue waiting to happen", I'd be curious to hear what > you're considering. Both designated initialization and casting is already > explicitly considered in the Clang and GCC plugin implementations. Not really. I looked into the implementation of the warning: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/gcc-plugins/randomize_layout_plugin.c#n717 And it is just as bad as the way GCC outputs strict aliasing warnings in the front-end, very easy worked around by using `void*` or even a pointer addition (since there is no case for POINTER_PLUS). Or even just doing: struct a *b = &c; int *d = (int*)b; Since you get 2 statements right after ssa (before ccp). And no warning when dealing with casting to an integer type. > > So, no doubt, it's a really wild feature, but it is already in reliable > real-world use. Not bringing it upstream into GCC doesn't make much sense to > me. It's a pretty isolated change and doesn't impact any later stages of > compilation. Without the full IPA based analysis of making sure people don't use it incorrectly, this should NOT go in. And right now there is there is none and I don't think anyone is willing to implement it since it will take some time. So many other random features make better sense to add for security than implementing this. Like doing better static anlaysis and better auditing of code.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #383 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #382) > Instead of ... > > && REG_P (operands[1]) && REGNO (operands[1]) == R0_REG" > > ... could we also write it as... > > (define_predicate "hard_reg_r0" > (and (match_code "reg") >(match_test "REGNO (op) == R0_REG"))) > > (match_operand:SI 1 "hard_reg_r0" "z"))) > > ... if you have a chance, can you please try? Test cases for c#214 and c#331, which were the targets of these patterns, compiled successfully with the above changes.
[Bug c/116457] Add -frandomize-layout-seed and -frandomize-layout-seed-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 --- Comment #4 from Kees Cook --- This feature is designed as a "security through obscurity" feature that has real-world benefits to specialized high-security deployments where performance is not a concern. It is never expected to be compatible with the C standard; it operates as a language extension. And it is C only -- there's no desire to have this work with C++. As for "security issue waiting to happen", I'd be curious to hear what you're considering. Both designated initialization and casting is already explicitly considered in the Clang and GCC plugin implementations. So, no doubt, it's a really wild feature, but it is already in reliable real-world use. Not bringing it upstream into GCC doesn't make much sense to me. It's a pretty isolated change and doesn't impact any later stages of compilation.
[Bug tree-optimization/116990] [15 Regression] ICE on valid code at -O3 "-fno-tree-ccp -fno-tree-loop-im -fno-tree-dse" on x86_64-linux-gnu: in single_pred_edge, at basic-block.h:342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116990 --- Comment #2 from Andrew Pinski --- Looks like we assume if the latch is empty it has one predecessor which is not true here.
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 --- Comment #11 from John David Anglin --- This commit fixes the secondary memory needed issue mentioned comment 7. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=220402bfc03cf6a6c5bff11da8497b5374dccfe0
[Bug target/113933] Switch pa to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933 John David Anglin changed: What|Removed |Added Attachment #59178|0 |1 is obsolete|| --- Comment #12 from John David Anglin --- Created attachment 59288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59288&action=edit Patch LRA patch as of commit 220402bfc03cf6a6c5bff11da8497b5374dccfe0. Need to check compatibility of changes with reload, and add "-mlra" option. We need to be able to fallback to reload for a period of time.
[Bug c++/116981] wrongly accepted non-more-specialized partial specialization of class template member for an instantiated enclosing template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981 --- Comment #5 from mauro russo --- yes, `B` needs to be changed to `B`. Please, may you remove the dup-relation with PR 32071 ?
[Bug c++/116981] wrongly accepted non-more-specialized partial specialization of class template member for an instantiated enclosing template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116981 --- Comment #6 from Andrew Pinski --- (In reply to mauro russo from comment #5) > Please, may you remove the dup-relation with PR 32071 ? I did right away; now it is just a related (see also) relationship; I was too fast as marking as a dup sorry about that.
