[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #9 from Kewen Lin --- (In reply to Kewen Lin from comment #6) > (In reply to Hongtao.liu from comment #5) > > (In reply to Kewen Lin from comment #3) > > > (In reply to Hongtao.liu from comment #2) > > > > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html > > > > help? > > > > > > Sorry, I just measured those degraded bmks with this fix, the results > > > showed > > > it didn't help. > > > > Sorry for the inconvience, could you try again with attached patch. > > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and > > GENERAL_REGS(which is the case in PR109610), hope it can also fix this > > regression. > > Thanks for the prompt fix, I'll do the perf evaluation once the perf boxes > get released (they are used by others now) and get back to you. I re-evaluated all SPEC2017 bmks on Power9 and Power10 with this patch (r14-171 vs. r14-172 + this fix), and confirmed it does fix all three degradation found before and it doesn't cause any new degradation (btw, all the >1% improvements are gone as well, all the results are neutral).
[Bug middle-end/90663] [10/11/12/13/14 Regression] strcmp ([i], a + i) not folded for arrays and constant index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90663 --- Comment #10 from Andrew Pinski --- Created attachment 55097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55097=edit Patch which I am testing
[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-May/618 ||762.html --- Comment #5 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618762.html
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #15 from Jerry DeLisle --- (In reply to gary.wh...@colostate.edu from comment #11) > I've never used valgrind -- what would it do? > valgrind tracks and checks memory allocations during execution and can spot where things, such as pointers that go astray. This sometimes happens with optimization bugs. >From the man page. It has many tools and is very useful. Valgrind is a flexible program for debugging and profiling Linux executables. It consists of a core, which provides a synthetic CPU in software, and a series of debugging and profiling tools. The architecture is modular, so that new tools can be created easily and without disturbing the existing structure.
[Bug target/106708] [rs6000] 64bit constant generation with oris xoris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:5eb7d560626e427673c53723ed430c4bb5721f33
commit r14-923-g5eb7d560626e427673c53723ed430c4bb5721f33
Author: Jiufu Guo
Date: Sat Dec 10 21:18:51 2022 +0800
rs6000: use lis;xoris to build constant
For constant C:
If '(c & 0xULL) == 0x' or say:
32(1) || 1(0) || 15(x) || 16(0), we could use "lis; xoris" to build.
Here N(M) means N continuous bit M, x for M means it is ok for either
1 or 0; '||' means concatenation.
This patch update rs6000_emit_set_long_const to support those constants.
Compare with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608292.html
This patch updates test function names only.
Bootstrap and regtest pass on ppc64{,le}.
PR target/106708
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Support
building
constants through "lis; xoris".
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr106708.c: Add test function.
[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 --- Comment #8 from Hongtao.liu --- (In reply to Segher Boessenkool from comment #7) > > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and > > GENERAL_REGS(which is the case in PR109610), hope it can also fix this > > regression. > > That sounds more reasonable. But, why use any heuristics like this? Can't > you > just look at the actual costs of using mem and regs? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610#c2
[Bug testsuite/109880] [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109880 Peter Bergner changed: What|Removed |Added Target Milestone|--- |14.0 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |aagarwa at gcc dot gnu.org Last reconfirmed||2023-05-17 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Peter Bergner --- Confirmed. The difference I see is: gcc.target/powerpc/fold-vec-extract-int.p8.c: \\mrldicl\\M found 5 times FAIL: gcc.target/powerpc/fold-vec-extract-int.p8.c scan-assembler-times \\mrldicl\\M 7 ...which makes sense, since the rldicl is used as a zero extend, so it does look like just an instruction count update is needed. Ajit, can you please confirm the 2 missing rldicl were removed because of zero extends? Bill's build seems pretty normal, so did you not see this failure during your testing?
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #14 from GARY.WHITE at ColoState dot edu --- Clarification on the last post. I'm compiling everything with -O3, except va09ad.f90. If va09ad.f90 is compiled with -O3, you get the bug. If va09ad.f90 is compiled with -O0, the code produces correct answers. Since LAPACK is a common library, you should be able to duplicate the bug with little difficulty by changing the makefile.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #12 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0. --- Comment #13 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #12 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0. --- Comment #13 from GARY.WHITE at ColoState dot edu --- I just checked, and the bug occurs with the LAPACK routines instead of LinPack. So "make type=markLAPACK" will generate markLAPACK that will fail with -O3, but work with -O0.
[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #5 from Sam James --- All of the benchmarks in that report are from https://github.com/phoronix-test-suite/phoronix-test-suite. For GraphicsMagick, the relevant benchmark seems to be: https://github.com/phoronix-test-suite/phoronix-test-suite/blob/dea5e68ba7bc0eaa3646713a8e07100ffab929b5/ob-cache/test-profiles/pts/graphics-magick-1.6.1/test-definition.xml (it might be a different version of the test, but note that '1.6.1' does NOT equal the graphicsmagick version) with a script at https://github.com/phoronix-test-suite/phoronix-test-suite/blob/dea5e68ba7bc0eaa3646713a8e07100ffab929b5/ob-cache/test-profiles/pts/graphics-magick-1.6.1/install.sh#L25. I think it runs individual commands like this (OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert DSC_6782.png $@ null), so: * OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert DSC_6782.png -colorspace HWB null * OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert DSC_6782.png -blur 0x1.0 null * OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert DSC_6782.png -lat 10x10-5% null * OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert DSC_6782.png -resize 50% HWB null * OMP_NUM_THREADS="$NUM_CPU_CORES" ./gm benchmark -duration 60 convert DSC_6782.png -sharpen 0x1.0 HWB null with GraphicsMagick (gm) built as with -fopenmp -O3 -march=native -flto -ltiff -lfreetype -ljpeg -lXext -lSM -lICE -lX11 -lbz2 -lz -lzstd -lpthread. But I can't actually find the test image DSC_6782.png, so... I think we really need more information here before it's actionable. Perhaps the reporter could reach out to Michael Larabel and ask him to comment here.
[Bug rtl-optimization/4079] unnecessary register move on simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4079 Andrew Pinski changed: What|Removed |Added Known to work||8.1.0 Target Milestone|--- |8.0 Status|SUSPENDED |RESOLVED Known to fail||4.8.5 Resolution|--- |FIXED --- Comment #10 from Andrew Pinski --- This has been fixed for a while. At least in GCC 8. Maybe even before.
[Bug sanitizer/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-16 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- The header is included since r13-2677-g0abc63a5ea4550 (and r12-9342-g0cec4e9cd44e25 on the branch), and not including it would mean not being able to annotate atomic>. I agree with Andrew, this is a bug in libsanitizer. The correct way to use __has_feature in a public header is to test with #ifdef __has_feature not to define the fallback definition.
[Bug ada/109881] GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881 --- Comment #2 from John Marino --- I found the problematic line. I changed this line: data_in := read_compressed_data (input_stream, planned, bytes_read); to: bytes_read := read_compressed_data (input_stream => input_stream, bytes_planned => planned, data_in => data_in); and the read_compressed_data function was changed from: function read_compressed_data (input_stream : not null SIO.Stream_Access; bytes_planned : Natural; bytes_read: out Natural) return data_in_type; to: function read_compressed_data (input_stream : not null SIO.Stream_Access; bytes_planned : Natural; data_in : out data_in_type) return Natural; The rearrangement of the function avoided the GNAT bug.
[Bug rtl-optimization/43616] Extra register move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43616 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||5.1.0, 9.1.0 --- Comment #3 from Andrew Pinski --- The arm code generation was fixed in GCC 5 for the testcase in comment #0. The x86_64 code generation was fixed in GCC 9 for the testcase in comment #2. So fixed a long time ago for both.
[Bug sanitizer/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882 --- Comment #3 from Andrew Pinski --- Then you should file this bug upstream with the sanitizer for the way __has_feature is handled incorrectly.
[Bug sanitizer/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |sanitizer CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- Anyways I am going to declare this a bug in the sanitizer headers rather than libstdc++ headers.
[Bug libstdc++/109882] -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882 --- Comment #1 from Andrew Pinski --- __has_feature is being added
[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109879 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug tree-optimization/68086] Expression explicitly defined outside the loop is moved inside the loop by the optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68086 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|tree-optimization --- Comment #3 from Andrew Pinski --- So we start with: : _1 = (long unsigned int) i_13; _2 = _1 * 4; _3 = -_2; rebased_15 = data_14(D) + _3; goto ; [INV] : _4 = (long unsigned int) i_10; _5 = _4 * 4; _6 = rebased_15 + _5; _7 = *_6; And then forwprop turns it into: _4 = (long unsigned intD.16) i_10; _5 = _4 * 4; _11 = _4 - _1; _21 = _11 * 4; _6 = data_14(D) + _21; # VUSE <.MEM_16(D)> _7 = *_6; Except then IVOPT does not know how to handle this correctly.
[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109879
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:509eef9314b24eff20a5dbdd92f6ab52e2c0c786
commit r14-920-g509eef9314b24eff20a5dbdd92f6ab52e2c0c786
Author: Gaius Mulley
Date: Wed May 17 00:18:56 2023 +0100
PR modula2/109879 WholeIO.ReadCard and ReadInt should consume leading space
The Read{TYPE} procedures in LongIO, LongWholeIO, RealIO, ShortWholeIO and
WholeIO all require skip space functionality. A new module TextUtil
is supplied with this functionality and the previous modules have been
changed to call SkipSpaces.
gcc/m2/ChangeLog:
PR modula2/109879
* gm2-libs-iso/LongIO.mod (ReadReal): Call SkipSpaces.
* gm2-libs-iso/LongWholeIO.mod (ReadInt): Call SkipSpaces.
(ReadCard): Call SkipSpaces.
* gm2-libs-iso/RealIO.mod (ReadReal): Call SkipSpaces.
* gm2-libs-iso/ShortWholeIO.mod: (ReadInt): Call SkipSpaces.
(ReadCard): Call SkipSpaces.
* gm2-libs-iso/TextIO.mod: Import SkipSpaces.
* gm2-libs-iso/WholeIO.mod (ReadInt): Call SkipSpaces.
(ReadCard): Call SkipSpaces.
* gm2-libs-iso/TextUtil.def: New file.
* gm2-libs-iso/TextUtil.mod: New file.
libgm2/ChangeLog:
PR modula2/109879
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* libm2cor/Makefile.in: Regenerate.
* libm2iso/Makefile.am (M2DEFS): Add TextUtil.def.
(M2MODS): Add TextUtil.mod.
* libm2iso/Makefile.in: Regenerate.
* libm2log/Makefile.in: Regenerate.
* libm2min/Makefile.in: Regenerate.
* libm2pim/Makefile.in: Regenerate.
gcc/testsuite/ChangeLog:
PR modula2/109879
* gm2/isolib/run/pass/testreadint.mod: New test.
Signed-off-by: Gaius Mulley
[Bug libstdc++/109882] New: -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882 Bug ID: 109882 Summary: -fsanitize=thread #include transitively includes sanitizer/common_interface_defs.h Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ed at catmur dot uk Target Milestone: --- Since 12.3.0, when compiled under tsan (-fsanitize=thread), #include transitively includes sanitizer/common_interface_defs.h: #include #if defined SANITIZER_COMMON_INTERFACE_DEFS_H #error :( #endif This is problematic for us because sanitizer/common_interface_defs.h has #define __has_feature(x) 0 https://github.com/gcc-mirror/gcc/blame/5d85b5d649fff675ff00adcc99371bccf4ef5944/libsanitizer/include/sanitizer/common_interface_defs.h#L20 which makes our sanitizer detector incorrectly believe that __has_feature is available and that tsan is not in fact present since __has_feature(thread_sanitizer) evaluates to 0. We will fix the order of checks to put `#ifdef __SANITIZE_THREAD__` first but thought we should probably report this to help other users.
[Bug rtl-optimization/79148] stack addresses are spilled to stack slots on x86-64 at -Os instead of rematerializing the addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79148 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-16 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- The testcase at https://people.mozilla.org/~nfroyd/Unified_cpp_widget0.ii.gz is no longer downloadable. Do anyone know where a testcase for this can be get from?
[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812 JuzheZhong changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #4 from JuzheZhong --- Thanks for reporting this. Unfortunately, a single report can not help us. Would you mind file a bug with simple piece of code that we can reproduce such issue and this issue matters for the benchmark. Besides, I have read this report. I think this may be the X86 backend issue. We (downstream) RISC-V GCC have tested various workloads, turns out GCC is better than Clang in traditional CPU benchmark. Also, Clang is much better than GCC in AI program benchmark (For example mlperf). Start with the benchmark you mentioned (GraphicsMagick), Could you post the most important piece of code belongging to this benchmark ? Thanks.
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #11 from GARY.WHITE at ColoState dot edu --- I've never used valgrind -- what would it do? The problem isn't that the code is wrong -- otherwise -O0 would not generate correct results. The compiler is optimizing something incorrectly with -O1 that causes the numerical optimizer, i.e., va09ad code, to not work correctly. I included 2 files in the zip file that show incorrect and correct results -- basically va09ad just doesn't go anywhere, not finding an optimum after running to the maximum number of function calls. It's not blowing up or aborting -- just producing wrong answers. I am willing to walk you through where the critical code is located, but need to know more of what system you're working on and how I can help.
[Bug ada/109881] GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881 --- Comment #1 from John Marino --- I commented out the "file_to_file_decompression" function and the GNAT BUG disappeared.
[Bug rtl-optimization/66890] function splitting only works with profile feedback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66890
--- Comment #6 from Andrew Pinski ---
Really for this loop, I would have assume to be split into 3 different loops
like:
volatile int count;
int main()
{
int i;
for (i = 0; i < 999; i++) {
if (i == 999)
count *= 2;
count++;
}
for (; i < 999+1; i++) {
if (i == 999)
count *= 2;
count++;
}
for (; i < 10; i++) {
if (i == 999)
count *= 2;
count++;
}
}
And then it would not have an extra branch inside the loop itself either.
[Bug ada/109881] New: GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881
Bug ID: 109881
Summary: GNAT BUG DETECTED during RTL pass, raised
TYPES.UNRECOVERABLE_ERROR
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: gnugcc at marino dot st
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Created attachment 55096
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55096=edit
The three ada source files requested in the GNAT BUG message
During development, I hit this error on GCC 11.2.0 and also got a very similar
one on Community 2020 (Windows). It just happened so if a future change
resolves it, I'll reattach those source files.
during RTL pass: expand
+===GNAT BUG DETECTED==+
| 11.2.0 (x86_64-raven-dragonfly6.2) GCC error:|
| in operand_subword_force, at emit-rtl.c:1806 |
| Error detected around
/home/marino/rvn-format/src/zstandard/zstandard-streaming_decompression.adb:249:8|
| 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. |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
/home/marino/rvn-format/src/zstandard/zstandard-streaming_decompression.adb
zstandard/zstandard-streaming_decompression.ads
zstandard/zstandard.ads
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407
commands that built it:
gcc -c unix/stat_opsc.c -o stat_opsc.o
PROG=/raven/share/raven/toolchain/ravensys-gcc/bin/gnatmake
${PROG} unrvn.adb -Izstandard -Iblake3 -Iunix -lzstd -largs -L/raven/lib
-lzstd_pic -lblake3_pic stat_opsc.o
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805 --- Comment #12 from Sergio Durigan Junior --- Sorry, I have been busy with other things, but I'm paying attention to the developments here. I still have to test the workaround I suggested (passing -fdebug-prefix-map to LDFLAGS) more broadly, because I think I may have found at least one scenario where it doesn't work. Something else that's puzzling me is the fact that I don't see this behaviour everywhere; some packages do have the expected DW_AT_comp_dir even after being compiled with LTO enabled.
[Bug testsuite/109880] New: [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109880 Bug ID: 109880 Summary: [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:9417b30499ce09996b4f1b4e2ce75a2853865ed4, r14-916-g9417b30499ce09 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/fold-vec-extract-int.p8.c" FAIL: gcc.target/powerpc/fold-vec-extract-int.p8.c scan-assembler-times \\mrldicl\\M 7 # of expected passes11 # of unexpected failures1 The test case may just need updating. The ones that count assembler instructions can be fragile. commit 9417b30499ce09996b4f1b4e2ce75a2853865ed4 (HEAD, refs/bisect/bad) Author: <80><9C>Ajit Kumar Agarwal<80><9D> Date: Tue May 16 10:47:15 2023 -0500 rs6000: Enable REE pass by default
[Bug fortran/109865] different results when routine moved inside the contains statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 --- Comment #10 from Steve Kargl --- On Tue, May 16, 2023 at 03:55:51PM +, Gary.White at ColoState dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865 > > --- Comment #9 from GARY.WHITE at ColoState dot edu dot edu> --- > Another clue. I'm seeing the same bug in gfortran-13, except that I have to > use -O0 for both cases of mc11ad.f90 in or out of the contains statement. > > Similarly, if I put the set of va09ad.f90 routines in a module, I have to use > -O0 to get correct answers. -O3 causes a bug with va09ad.f90 in a module as > well. > Can you use valgrind? I got the zip file, but reducing that will be a pain. First, the included lapack, blas, and linpack archives are useless to me. Second, there is just way too much code with a complete lack of familiarity to try to reduce this. I suspect you may have to go old school with 'print *' debugging in the problematic subroutine.
[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109879 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-05-16 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Gaius Mulley --- Confirmed as a bug.
[Bug modula2/109879] ReadCard and ReadInt from WholeIO have problems with leading space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109879 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #1 from Gaius Mulley --- Created attachment 55095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55095=edit Proposed fix Here is a proposed patch and testcase.
[Bug modula2/109879] New: ReadCard and ReadInt from WholeIO have problems with leading space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109879 Bug ID: 109879 Summary: ReadCard and ReadInt from WholeIO have problems with leading space Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- As reported on the gn2 mailing list, leading spaces are not skipped when performing ReadInt or ReadCard. module port_test10a_gm2; from ChanConsts IMPORT OpenResults, old, read, write; from IOChan IMPORT ChanId; from StdChans IMPORT StdOutChan; import StreamFile; from TextIO IMPORT SkipLine, WriteLn, WriteString; from WholeIO IMPORT ReadCard, ReadInt, WriteCard, WriteInt; procedure ReadNumbersTest(); const arr_len=128; type arr_type= ARRAY[0..arr_len-1] of char; var cid_file: ChanId; cid_out:ChanId; file_name: arr_type; res:OpenResults; c1: cardinal; ival: integer; cval: cardinal; begin (* procedure ReadNumbersTest *) cid_out:=StdOutChan(); file_name:='test_data'; (* create file and write (integer) numbers to it *) WriteString(cid_out, 'write (integer) numbers to file...'); WriteLn(cid_out); StreamFile.Open(cid_file, file_name, write+old, res); if res=opened THEN WriteString(cid_file, ' 123'); WriteLn(cid_file); WriteString(cid_file, '234'); WriteLn(cid_file); StreamFile.Close(cid_file); end;(* if res=opened *) (* (re-)open file and read numbers with ReadCard *) WriteString(cid_out, 'read numbers with ReadCard...'); WriteLn(cid_out); StreamFile.Open(cid_file, file_name, read, res); if res=opened THEN for c1:=1 TO 2 DO ReadCard(cid_file, cval); WriteCard(cid_out, cval, 1); WriteLn(cid_out); SkipLine(cid_file); end; (* for c1 *) StreamFile.Close(cid_file); end;(* if res=opened *) WriteLn(cid_out); (* (re-)open file and read numbers with ReadInt *) WriteString(cid_out, 'read numbers with ReadInt...'); WriteLn(cid_out); StreamFile.Open(cid_file, file_name, read, res); if res=opened THEN for c1:=1 TO 2 DO ReadInt(cid_file, ival); WriteInt(cid_out, ival, 1); WriteLn(cid_out); SkipLine(cid_file); end; (* for c1 *) StreamFile.Close(cid_file); end;(* if res=opened *) WriteLn(cid_out); end ReadNumbersTest; begin (* module port_test10a_gm2 *) ReadNumbersTest(); end port_test10a_gm2.
[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-05-16 --- Comment #4 from Andrew Pinski --- I am just going to test: diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc index 06f19868ade..0326e6733e8 100644 --- a/gcc/tree-ssa-forwprop.cc +++ b/gcc/tree-ssa-forwprop.cc @@ -1231,14 +1231,14 @@ simplify_builtin_call (gimple_stmt_iterator *gsi_p, tree callee2) tree size = gimple_call_arg (stmt2, 2); /* Size must be a constant which is <= UNITS_PER_WORD and <= the string length. */ - if (TREE_CODE (size) != INTEGER_CST || integer_zerop (size)) + if (TREE_CODE (size) != INTEGER_CST) break; if (!tree_fits_uhwi_p (size)) break; unsigned HOST_WIDE_INT sz = tree_to_uhwi (size); - if (sz > UNITS_PER_WORD || sz >= slen) + if (sz == 0 || sz > UNITS_PER_WORD || sz >= slen) break; tree ch = gimple_call_arg (stmt2, 1); This does not change the behavior of the code at all, just makes it obvious sz cannot be 0 and therefore isize won't be 0 either.
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094 --- Comment #26 from Jonathan Wakely --- Thanks!
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #25 from John David Anglin --- No.
[Bug libstdc++/109814] [13/14 Regression] freestanding using cmath does not compile anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.2
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094 Jonathan Wakely changed: What|Removed |Added Status|NEW |WAITING --- Comment #24 from Jonathan Wakely --- Dave, is this still an issue on the currently supported hp-ux targets?
[Bug analyzer/109570] detect fclose on unopened or NULL files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- The glibc change is now causing failures in the GCC testsuite: FAIL: gcc.dg/analyzer/torture/conftest-1.c -O0 (test for excess errors) Excess errors: /gcc/testsuite/gcc.dg/analyzer/torture/conftest-1.c:6:24: warning: use of possibly-NULL 'f' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors) Excess errors: /gcc/testsuite/gcc.dg/analyzer/data-model-4.c:11:24: warning: use of possibly-NULL 'f' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #6 from Jakub Jelinek --- That is generally the case for the standard C/C++ attributes (arguments just need to be a balanced token sequence), but not for GNU attributes. Although, all standard C/C++ attributes we support right now other than OpenMP ones follow the GNU attribute rules as well.
[Bug libstdc++/33578] __gnu_parallel::yield means what?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33578
--- Comment #10 from Jonathan Wakely ---
For std::this_thread::yield() we do:
inline void
yield() noexcept
{
#if defined _GLIBCXX_HAS_GTHREADS && defined _GLIBCXX_USE_SCHED_YIELD
__gthread_yield();
#endif
}
And gthr-win32.h has:
__GTHREAD_WIN32_INLINE int
__gthread_yield (void)
{
Sleep (0);
return 0;
}
For atomics we also support using the x86 pause instruction
inline void
__thread_yield() noexcept
{
#if defined _GLIBCXX_HAS_GTHREADS && defined _GLIBCXX_USE_SCHED_YIELD
__gthread_yield();
#endif
}
inline void
__thread_relax() noexcept
{
#if defined __i386__ || defined __x86_64__
__builtin_ia32_pause();
#else
__thread_yield();
#endif
}
For Parallel Mode maybe we should just use __gthread_yield() everywhere?
gthr-win32.h already takes care of hiding the Win32 API. Since Parallel Mode is
likely to get removed at some point (now that we have the parallel STL algos
from C++17) I don't see any point in revisiting its implementation w.r.t using
of yield at all (comment 1).
tl;dr let's not reinvent the wheel when we already have portable code for
yielding, and don't want to redesign the parallel mode.
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #5 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #4) > (In reply to Andrew Pinski from comment #2) > > This style of attributes is bad. Because the GNU style attribute is just > > token(expression,expression,expression) it seems odd that they added these > > kind of attributes without thinking maybe it would be rejected somewhere > > else. > > To be precise, some attributes have the first argument an identifier rather > than expression (e.g. mode/format/cleanup/access attribute). > So, the macOS as first argument is acceptable, but not the second one. As far as I can tell (and what my current implementation does) is to say that everything in the inner parentheses cam be lexed/parsed in a manner specific to the attribute ID. so in: availability() the is parsed specifically to "availability" and presumably: another_attr() could have a different set of rules. As noted, we [at least, all I have spoken to] agree that this is bad (in respect of deviating from GNU style without any other mechanism to differentiate). However, once stuff is in the wild
[Bug target/77579] Missed multiple add (int) for CSEd case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77579
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #3 from Andrew Pinski ---
Thinking about this some more, doing the multiply multiple times is actually
slower on most cores.
So this is not something you want to do normally but with a constant multiply
you do for small power of 2 constant.
E.g.:
```
void f(int x, int y, int z, int *s)
{
int t = y * 2;
s[0] = t + x;
s[1] = x - t;
}
```
You should get:
add w2, w0, w1 lsl 1
sub w0, w0, w1 lsl 1
stp w2, w0, [x3]
And no seperate lsl instruction as the cost to do the lsl is free in this case.
Anyways I am not working on this any more.
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #20 from palmer at gcc dot gnu.org --- (In reply to rvalue from comment #19) > (In reply to Aurelien Jarno from comment #18) > > I wonder if the following patch should also be backported, as it > > doesn't make sense to link with -latomic anymore with inline subword atomic > > operations > > Agreed. It's now meaningless to keep this workaround for RISC-V as the > problem has been resolved. Yep. Can someone send the backport?
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #2) > This style of attributes is bad. Because the GNU style attribute is just > token(expression,expression,expression) it seems odd that they added these > kind of attributes without thinking maybe it would be rejected somewhere > else. To be precise, some attributes have the first argument an identifier rather than expression (e.g. mode/format/cleanup/access attribute). So, the macOS as first argument is acceptable, but not the second one.
[Bug tree-optimization/109878] New: missed simplifications of MAX and MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109878
Bug ID: 109878
Summary: missed simplifications of MAX and
MIN
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int max_and(int a, int b)
{
b = a & 3;
a = a & 1;
if (b > a)
return b;
else
return a;
}
int min_and(int a, int b)
{
b = a & 3;
a = a & 1;
if (b < a)
return b;
else
return a;
}
```
max_and should just be optimized to `a&3` while min_and should be just
optimized to `a&1` The general rule is:
MAX -> a & CST0 IFF CST0 == CST1, that is CST1 is a
true subset of CST0.
I found this on accident while thinking about some generated code in
insn-automata.cc on x86_64.
MIN -> a & CST0 IFF CST0 == CST0, that is CST0 is a true
subset of CST1.
[Bug c++/109774] template function causes Spurious dangling reference warning while non-template does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109774 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/109774] template function causes Spurious dangling reference warning while non-template does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109774 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:22741a09a8cbf8a360e99e530b016233dd705ce4 commit r13-7337-g22741a09a8cbf8a360e99e530b016233dd705ce4 Author: Marek Polacek Date: Tue May 16 14:12:06 2023 -0400 c++: -Wdangling-reference not suppressed in template [PR109774] In check_return_expr, we suppress the -Wdangling-reference warning when we're sure it would be a false positive. It wasn't working in a template, though, because the suppress_warning call was never reached. PR c++/109774 gcc/cp/ChangeLog: * typeck.cc (check_return_expr): In a template, return only after suppressing -Wdangling-reference. gcc/testsuite/ChangeLog: * g++.dg/warn/Wdangling-reference13.C: New test. (cherry picked from commit f25d2de17663a0132f9fe090dee39d3b1132067b)
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #3 from Iain Sandoe --- (In reply to Andrew Pinski from comment #2) > This style of attributes is bad. Because the GNU style attribute is just > token(expression,expression,expression) it seems odd that they added these > kind of attributes without thinking maybe it would be rejected somewhere > else. Actually, the folks from clang I've spoken to agree it is bad; however, it's also in the wild and so unfixable - at least for the key attributes such as availability. I hope that future additions will not take advantage of the extra flexibility. >From the PoV of the platform I'm kinda stuck [and it seems those attributes are also used by, at least, android, z/OS and hlsl from the list in the clang sources].
[Bug c++/98202] C++ cannot parse F128 suffix for float128 literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98202 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Other option would be just hardcode those 4 constants by hand: #define __FLT128_MAX__ 1.18973149535723176508575932662800702e+4932F128 #define __FLT128_NORM_MAX__ 1.18973149535723176508575932662800702e+4932F128 #define __FLT128_MIN__ 3.36210314311209350626267781732175260e-4932F128 #define __FLT128_EPSILON__ 1.92592994438723585305597794258492732e-34F128 #define __FLT128_DENORM_MIN__ 6.47517511943802511092443895822764655e-4966F128 with __extension__ before it and Q suffix instead of F128. For __float128 I think those constants aren't going to change. Advantage of doing that would be that even various versions of clang++ support that, while F128 suffix isn't supported. So, use: (__extension__ 0x1.p+16383Q) (__extension__ 0x1.p+16383Q) (__extension__ 0x1.p-16382Q) (__extension__ 0x1.p-112Q) (__extension__ 0x0.0001p-16382Q) instead of those 4 constants.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #32 from Jonathan Wakely --- Hmm, yes. Well I think we can at least make std::is_integral<__int128> true, which will remove once source of surprises for users.
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #19 from rvalue --- (In reply to Aurelien Jarno from comment #18) > I wonder if the following patch should also be backported, as it > doesn't make sense to link with -latomic anymore with inline subword atomic > operations Agreed. It's now meaningless to keep this workaround for RISC-V as the problem has been resolved.
[Bug libstdc++/44015] template parameters not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44015 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #23 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug libstdc++/40380] class documentation should mention include file to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #11 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug libstdc++/21772] exception safety testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772 Andrew Pinski changed: What|Removed |Added Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #24 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug libstdc++/9780] issues with time_get, time_put not being tied to correct _punct facet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9780 Andrew Pinski changed: What|Removed |Added Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- Reassining since Benjamin has not been active in GCC development for a few years now.
[Bug libstdc++/18571] document wstring/wfilebuf code conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18571 Andrew Pinski changed: What|Removed |Added Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #3 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug libstdc++/5499] True name and named locales
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5499 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug libstdc++/16006] Conversions of numbers in fi_FI.UTF-8 produces incorrect UTF-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug libstdc++/33578] __gnu_parallel::yield means what?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33578 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|bkoz at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- Unassigning since Benjamin since not been active in GCC development for over 8 years now.
[Bug c++/109774] template function causes Spurious dangling reference warning while non-template does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109774 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:f25d2de17663a0132f9fe090dee39d3b1132067b commit r14-919-gf25d2de17663a0132f9fe090dee39d3b1132067b Author: Marek Polacek Date: Tue May 16 14:12:06 2023 -0400 c++: -Wdangling-reference not suppressed in template [PR109774] In check_return_expr, we suppress the -Wdangling-reference warning when we're sure it would be a false positive. It wasn't working in a template, though, because the suppress_warning call was never reached. PR c++/109774 gcc/cp/ChangeLog: * typeck.cc (check_return_expr): In a template, return only after suppressing -Wdangling-reference. gcc/testsuite/ChangeLog: * g++.dg/warn/Wdangling-reference13.C: New test.
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 --- Comment #2 from Andrew Pinski --- This style of attributes is bad. Because the GNU style attribute is just token(expression,expression,expression) it seems odd that they added these kind of attributes without thinking maybe it would be rejected somewhere else.
[Bug target/104338] RISC-V: Subword atomics result in library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338 --- Comment #18 from Aurelien Jarno --- Thanks Patrick for working on that and for the backport to the gcc-13 branch. I wonder if the following patch should also be backported, as it doesn't make sense to link with -latomic anymore with inline subword atomic operations: commit 203f3060dd363361b172f7295f42bb6bf5ac0b3b Author: Andreas Schwab Date: Sat Apr 23 15:48:42 2022 +0200 riscv/linux: Don't add -latomic with -pthread Now that we have support for inline subword atomic operations, it is no longer necessary to link against libatomic. This also fixes testsuite failures because the framework does not properly set up the linker flags for finding libatomic. The use of atomic operations is also independent of the use of libpthread. gcc/ * config/riscv/linux.h (LIB_SPEC): Don't redefine.
[Bug c++/109877] Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 Iain Sandoe changed: What|Removed |Added Blocks||90709 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed||2023-05-16 --- Comment #1 from Iain Sandoe --- I have a working draft for c-family (I do not know if D and M2 are interested in attributes) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709 [Bug 90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.
[Bug c++/109877] New: Support for clang-style attributes is needed to parse Darwin SDK headers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877 Bug ID: 109877 Summary: Support for clang-style attributes is needed to parse Darwin SDK headers properly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- clang has GNU-style attribute support, but with essentially per-attribute parsing of the attribute argument list. This extends to, for example: __attribute__((availability(macOS, introduced=12.3.4))) and: __attribute__((availability(macOS, message="partial string" "more string"))) These are examples that GCC rejects; The issue actually need addressing during lexing since the first is an invalid token for a number (it's intended to represent a version) and we reject it before the parser has a chance to treat it specially. Ergo, we need a way to escape clang-specific attributes so that we can parse them.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #31 from joseph at codesourcery dot com --- It can be an extended integer type in C2x, but then stdint.h would be required to have int128_t / uint128_t / int_least128_t / uint_least128_t typedefs, and integer constant suffixes would be needed for the corresponding macros INT128_C / UINT128_C (and the other stdint.h macros for the types would need to be defined as well), and printf/scanf support would be required as well.
[Bug target/55610] cc1 is calling munmap() on part of itself on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55610 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Build|x86_64-apple-darwin12 |*-*-darwin* Host|x86_64-apple-darwin12 |*-*-darwin* Target|x86_64-apple-darwin12 |*-*-darwin* --- Comment #13 from Iain Sandoe --- this is fixed in gcc-12+ .. it is probably not a viable back port to earlier upstream branches, but can be maintained on Darwin-specific ones.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #37 from Iain Sandoe --- fixed on open branches, but is relevant on any older maintained outside of the GCC repo.
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
Bug 41991 depends on bug 44107, which changed state.
Bug 44107 Summary: gcc emits frame (epilogue) info incompatible with the darwin
{8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #4 from Marek Polacek ---
On trunk we no longer create a static temporary var for { 1, 2 }, because the
code in finish_compound_literal is now guarded by '&& fcl_context == fcl_c99'
but it's fcl_functional here.
[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 --- Comment #20 from Iain Sandoe --- leaving open, I think this might also be needed on 10.x
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 Iain Sandoe changed: What|Removed |Added Target Milestone|13.2|10.5 --- Comment #17 from Iain Sandoe --- needed on 10.x
[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105599 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Iain Sandoe --- fixed for affected open branches
[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 --- Comment #19 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:72f004746d87f01e5e3872af3214e3fa1b48dfa8 commit r11-10788-g72f004746d87f01e5e3872af3214e3fa1b48dfa8 Author: Iain Sandoe Date: Thu Mar 30 13:14:23 2023 +0530 c++,coroutines: Stabilize names of promoted slot vars [PR101118]. When we need to 'promote' a value (i.e. store it in the coroutine frame) it is given a frame entry name. This was based on the DECL_UID for slot vars. However, when LTO is used, the names from multiple TUs become visible at the same time, and the DECL_UIDs usually differ between units. This leads to a "ODR mismatch" warning for the frame type. The fix here is to use the current promoted temporaries count to produce the name, this is stable between TUs and computed per coroutine. Signed-off-by: Iain Sandoe PR c++/101118 gcc/cp/ChangeLog: * coroutines.cc (flatten_await_stmt): Use the current count of promoted temporaries to build a unique name for the frame entries. (cherry picked from commit fc4cde2e6aa4d6ebdf7f70b7b4359fb59a1915ae)
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:f4ad0b2287a334613f570c69b7c5320a5a7d7554 commit r11-10785-gf4ad0b2287a334613f570c69b7c5320a5a7d7554 Author: Iain Sandoe Date: Wed Jan 18 19:58:33 2023 + Darwin, fixincludes: Handle MacOS13 SDK Apple-specific deprecations [PR107568]. The SDK for MacOS13 includes Apple-specific deprecations of some functions that are not deprecated in Posix, C or C++ and widely used in GCC. The fix makes the deprecation conditional on __APPLE_LOCAL_DEPRECATIONS so that end users may still observe them but they are hidden from normal compilations. Signed-off-by: Iain Sandoe PR target/107568 fixincludes/ChangeLog: * fixincl.x: Regenerate. * inclhack.def: Add a fix for MacOS13 SDK function deprecations in stdio.h. * tests/base/stdio.h (__deprecated_msg): New test. (cherry picked from commit 442d2bdc1d2a98aba0b18aeaa3e87fa946ac8031)
[Bug c++/98202] C++ cannot parse F128 suffix for float128 literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98202 --- Comment #3 from Jonathan Wakely --- With GCC 13 it's now a pedwarn: f128.cc:1:1: warning: 'f128' or 'F128' suffix on floating constant only available with '-std=c++2b' or '-std=gnu++2b' [-Wpedantic]
[Bug target/104871] macosx-version-min wrong for macOS >= Big Sur (darwin20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104871 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:3417f095f149ba09ca9d4f62bfaf661819a04333 commit r11-10782-g3417f095f149ba09ca9d4f62bfaf661819a04333 Author: Simon Wright Date: Sun Jun 12 17:01:22 2022 +0100 Darwin: Truncate kernel-provided version to OS major for Darwin >= 20. In common with system tools, GCC uses a version obtained from the kernel as the prevailing macOS target, when that is not overridden by command line or environment versions (i.e. mmacosx-version-min=, MACOSX_DEPLOYMENT_TARGET). Presently, GCC assumes that if the OS version is >= 20, the value used should include both major and minium version identifiers. However the system tools (for those versions) truncate the value to the major version - this leads to link errors when combining objects built with clang and GCC for example: ld: warning: object file (null.o) was built for newer macOS version (12.2) than being linked (12.0) The change here truncates the values GCC uses to the major version. gcc/ChangeLog: PR target/104871 * config/darwin-driver.c (darwin_find_version_from_kernel): If the OS version is darwin20 (macOS 11) or greater, truncate the version to the major number. (cherry picked from commit add1adaa17a294ea25918ffb4fdd40f115362632)
[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105599 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a8307cfd66d29efae9c28f5b32bd677398c92dfe commit r11-10780-ga8307cfd66d29efae9c28f5b32bd677398c92dfe Author: Iain Sandoe Date: Sun May 29 16:14:32 2022 +0100 Darwin: Fix empty g++ command lines [PR105599]. An empty g++ command line should produce a diagnostic that there are no inputs. The PR is that currently Darwin produces a dignostic about missing link items instead - this is because (errnoeously), for this driver, we are creating a link job for empty command lines. The problem occurs in four stages: The g++ driver appends -shared-libgcc to the command line. The Darwin driver_init code in the backend does not see this (it sees an empty command line). When the back end driver code driver sees an empty command line, it does not add any supplementary flags (e.g. asm-macosx-version-min) - precisely to avoid anything being claimed as an input_file and therefore triggering a link line. Since we do not have a value for asm-macosx-version-min when processing the driver specs, we unconditionally inject 'multiply_defined suppress' which is used with shared libgcc (but only intended on very old Darwin). This then causes the generation of a link job. The solution, for the present, is to move version-specific link params to the LINK_SPEC so that they are only processed when a link job has already been decided. Signed-off-by: Iain Sandoe PR target/105599 gcc/ChangeLog: * config/darwin.h: Move versions-specific handling of multiply_defined from SUBTARGET_DRIVER_SELF_SPECS to LINK_SPEC. (cherry picked from commit 794737976b9a6418eab817f143bb4eb2d0c834d2)
[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772 --- Comment #5 from Jonathan Wakely --- That would be great :-)
[Bug c/39985] Type qualifiers not actually ignored on function return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #11 from Marek Polacek --- Closing as fixed then.
[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Perhaps we could change that if (cxx_dialect < cxx23) pedwarn (input_location, OPT_Wpedantic, "% or % suffix on floating constant only " "available with %<-std=c++2b%> or %<-std=gnu++2b%>", n, n); into if (cxx_dialect < cxx23 && !in_system_header_at (input_location))
[Bug testsuite/36443] [10/11/12/13/14 Regression]: HOSTCC doesn't work with installed gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|janis at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #71 from Andrew Pinski --- Janis has not been active in GCC development for a few years now so unassigning.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #30 from Jonathan Wakely --- (In reply to John Maddock from comment #26) > (In reply to jos...@codesourcery.com from comment #25) > > On Thu, 20 Nov 2014, john at johnmaddock dot co.uk wrote: > > > > > While we're opening cans of worms intmax_t should clearly be > > > __int128... > > > just saying! > > > > Existing ABIs where intmax_t in libc is 64-bit are why __int128 is what I > > call a sui generis extended type, not an integer type. > > So it's an integer that's not an integer? I'm sorry but that's just > nonesense. Of course I realise that ABI issues may trump other concerns, > but please call a spade a spade! In any case this is a glibc issue and > we're off topic here... With changes to the definition of intmax_t in C2x (and C++23) that problem is gone. __int128 can be an extended integer type, and intmax_t doesn't need to change, so there's no ABI problem. Order is restored to the galaxy.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Jonathan Wakely --- (In reply to Marc Glisse from comment #22) > __float128 is still missing a specialization of numeric_limits. We're still missing that, but I created PR libstdc++/104772 for it. I don't think we need full and I/O support for __float128, so let's close this one.
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 --- Comment #3 from Andrew Pinski --- What fixed it on the GCC 8 branch?
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Andrew Pinski changed: What|Removed |Added Known to fail||9.1.0, 9.5.0 Last reconfirmed|2023-05-16 00:00:00 | Priority|P2 |P3 Known to work||8.5.0 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |10.5 Ever confirmed|0 |1 Last reconfirmed||2023-05-16 Priority|P3 |P2 Keywords||rejects-valid Summary|initializer_list not usable |[10/11/12/13/14 Regression] |in constant expressions in |initializer_list not usable |a template |in constant expressions in ||a template CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Stopped working with r8-509-g6064858051d6e0 commit 6064858051d6e07bb89f3384c0d828f07c576c7a Author: Jason Merrill Date: Tue May 9 09:48:58 2017 -0400 PR c++/70167 - array prvalue treated as lvalue
[Bug c++/109876] New: initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
Bug ID: 109876
Summary: initializer_list not usable in constant expressions in
a template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider this example:
#include
template
struct Array {
};
#ifdef USE_TEMPLATE
template
#endif
struct Foo
{
static constexpr std::initializer_list num = { 1, 2 };
Array ctx;
};
#ifdef USE_TEMPLATE
void f(Foo<5>) { }
#else
void f(Foo) { }
#endif
In all recent versions of gcc, compiling with -DUSE_TEMPLATE fails with an
error like:
:15:17: in 'constexpr' expansion of
'Foo::num.std::initializer_list::size()'
:15:19: error: the value of 'Foo::num' is not usable in a constant
expression
15 | Array ctx;
| ^
This used to work in gcc 7 and gcc 8 (except 8.1), and I don't think there's
anything about Foo being a template that should prevent this from working. The
non-template case works on all gcc versions I've tried.
[Bug c++/109623] constexpr restrictions are not relaxed enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109623
--- Comment #3 from Marek Polacek ---
// PR c++/109623
struct U {
U() { }
};
struct S {
constexpr S() = default;
U u;
};
[Bug testsuite/23867] libstdc++ ABI testsuite should work for installed compiler testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23867 Andrew Pinski changed: What|Removed |Added Assignee|mark at codesourcery dot com |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #2 from Andrew Pinski --- Mark has not been active in GCC development in years so unassigning.
[Bug libstdc++/43622] Incomplete C++ library support for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #28 from Andrew Pinski --- I suspect this has now been fixed with the additional of full _Float128 support in the C++ front-end and the library work.
[Bug target/65139] Improve register allocation for aarch64_*_sisd_or_int3 patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65139 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed in GCC 6: r6-2459-gad7b853a10903e
[Bug middle-end/69976] Zero the local stack on function exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 --- Comment #14 from Andrew Pinski --- There is an option now to zero out the call used registers: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html#index-fzero-call-used-regs But there is not one for zeroing of arrays.
[Bug tree-optimization/30334] [meta-bug] Request for -Wundefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334 Andrew Pinski changed: What|Removed |Added Assignee|gdr at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #19 from Andrew Pinski --- GDR has not been active in GCC development for years now.
[Bug libgomp/109875] New: [OpenMP] nteams-var / OMP_NUM_TEAMS → ICV not passed to the device / default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109875
Bug ID: 109875
Summary: [OpenMP] nteams-var / OMP_NUM_TEAMS → ICV not passed
to the device / default value
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Related: https://github.com/SOLLVE/sollve_vv/pull/728 and
OpenMP Spec Issue 3619.
The following is with host fallback - and I might miss something because of
this.
However, I get only a single team with the following code;
even though max_num_teams == 3.
Replacing the set_num_teams by
OMP_NUM_TEAMS=7 OMP_NUM_TEAMS_DEV=8
will yield the expected 7 for max_teams.
But it will still execute with a single team. — Using num_teams(3) as clause
will have an effect, however.
TODO:
* Check whether TEAMS = 1 makes sense for host fallback
and what the result is with actual offloading.
EXPECTED:
* The value of the ICV is honored on the device side
* Possibly, the initial value should be not 0 but a different value,
but that depends on the OpenMP Spec Issue 3619.
NOTE: While the init value is now changed, as omp_get_max_teams()
is confusingly written, just changing the default is undetectable
inside the program as only omp_get_max_teams() or display-env can be
used to determine the value - and the values returned by the latter
is not really available for consumption inside of the program.
* On the host side, the default seems to be 3, given that there is:
libgomp/teams.c:num_teams = gomp_nteams_var ? gomp_nteams_var : 3;
It seems as if get_gomp_offload_icvs sets the ICV for the device but it does
not seem to get actually get used. – At least not for host fallback.
#include
int main ()
{
int num_teams;
#if 1 // set to 0 to test the environment variables
omp_set_num_teams(2);
#pragma omp target
omp_set_num_teams(3);
#endif
__builtin_printf("max_teams: %d\n", omp_get_max_teams());
#pragma omp target teams map(tofrom: num_teams) //num_teams(4)
{
if (omp_get_team_num() == 0) {
num_teams = omp_get_num_teams();
}
}
__builtin_printf("num_teams: %d\n", num_teams);
return 0;
}
[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.5
[Bug libstdc++/109741] alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741 --- Comment #16 from Jonathan Wakely --- This should be fixed on trunk now.
