[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #20 from Sam James --- I'm going to throw my usual cvise setup for miscompiles at it for a few days and see if anything useful falls out.
[Bug middle-end/114371] New: [meta-bug] issues related to strict-volatile-bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114371 Bug ID: 114371 Summary: [meta-bug] issues related to strict-volatile-bitfields Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- There seems like a few fstrict-volatile-bitfields issues recorded so let's make a meta-bug dealing with so it is easier to track.
[Bug target/91861] invalid vectorization of isless, islessequal, etc. (with default of -ftrapping-math)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91861 --- Comment #4 from Matthias Kretz (Vir) --- > But NLT_UQ does not exist for non-VEX encoded Right, one needs to compare integers and check for NaN. Like noted in the description. Also implemented in the std::experimental::simd overloads: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/experimental/bits/simd_builtin.h;h=1a716f2dbb7cf3551622e2c1574b52573acf5c62;hb=HEAD#l2057 I actually noticed this bug (and the dup) when unit-testing stdx::simd, comparing against the scalar versions of the cmath functions.
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587 --- Comment #16 from Kaz Kylheku --- (In reply to Andrew Pinski from comment #14) > C++17 adds nodiscard attribute which can be placed on class/struct types, > functions, constructors and others and then you get a warning if you ignore > the value. In the case of struct/class types and constructors that will warn > when a temporary value is ignored. Exactly in the case you were asking for a > warning. > > Which was added to GCC by r7-377-gb632761d2c6a65 (and fixes afterwards). > > So closing as fixed. I'm afraid that this doesn't seem like a good resolution. The feature you are referring to is opt-in, per class, whereas the proposed warning imposes the behavior for every class. This is a big difference. The number of situations in which "classname(arg);" as an expression statement with a discarded value is correct is pretty small. This is almost always going to be a coding mistake. Where it isn't a coding mistake, the intent can be indicated using "(void) classname(arg);". The good news is that, at least it would seem that the implementation of the warning can be piggybacked on the nodiscard attribute implementation. The simplest possible requirement is that the option makes the compiler pretend that the attribute has been asserted for every class. (I say tentatively, without having studied the attribute's semantics in detail.) nodiscard could be "stronger" in that if it is asserted, then even the cast to (void) won't silence the diagnostic, so that it's still meaningful to use in spite of the warning option.
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587 --- Comment #15 from Kaz Kylheku --- (In reply to Manuel López-Ibáñez from comment #13) > (In reply to Kaz Kylheku from comment #11) > > I deployed that change to large team of developers, and the toolchain with > > that change went to customers also. The warning caught problems that were > > fixed and didn't appear to break anything. > > If the patch were to be upstreamed, it will be reviewed, regression tests > would be added to make sure it doesn't silently break, and your customers > could update to newer versions of GCC without losing the warning. In April 2020 I created a patch for the GNU C Preprocessor, with documentation, test cases and everything. I submitted it to the GCC Patches mailing list, exactly as comments in this ticket from 2015 advised me I should have done for this item back in 2008. I received absolutely no replies; not even to reject the submission. I "pinged" it a number of times, to no avail. The four year anniversary is coming up; I'm going to ping again. Then if I'm still ignored, one last time in April 2025.
[Bug testsuite/114320] New test case in r14-9439-g4aa87b856067d4 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114320 --- Comment #3 from Kewen Lin --- (In reply to Nathaniel Shead from comment #2) > Sorry about that. I've not been able to work out what configure flags I need > to pass to cause this to error in the first place (I don't normally develop > for powerpc and the machine I'm using doesn't seem to fail no matter what I guess the machine you are using (were referring to) isn't with powerpc chip, cfarm provides some powerpc machines (https://portal.cfarm.net/machines/list/), both ppc64le (LE -m64) and ppc64 (BE -m32/-m64), it's recommended to leverage them for building/testing. :) > flags I try), but am I correct in understanding that just adding > "-Wno-psabi" to the tests should stop them from failing? If so I'm happy to > push a patch to that effect. I think so, for now we don't have an effective target dedicated for __ibm128 type but it's guarded the same as what's for __float128 type (it would be relaxed though in future, even with that using ppc_float128_sw should just be more strict). Ideally we can add one effective target powerpc_vsx_ok (should be powerpc_vsx) to ensure VSX to be enabled, but considering we are going to rework it in next release and we don't normally disable vsx explicitly, this can be optional.
[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113986 --- Comment #18 from Andrew Pinski --- (In reply to Khem Raj from comment #17) > @wilco this commit is now regressing builds for musl/aarch64, where > libatomic fails to compile. With errors like Yes and already known is recorded as PR 113986 .
[Bug tree-optimization/69950] Allow more than one exit phi for reduction in try_create_reduction_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69950 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-18 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #17 from Khem Raj --- @wilco this commit is now regressing builds for musl/aarch64, where libatomic fails to compile. With errors like In file included from /home/kraj/work/gcc/libatomic/exch_n.c:25: /home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error: ‘export_exchange_16’ aliased to undefined symbol ‘libat_exchange_16’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ |^~~ /home/kraj/work/gcc/libatomic/libatomic_i.h:40:25: note: in definition of macro ‘C2_’ 40 | #define C2_(X,Y)X ## Y | ^ /home/kraj/work/gcc/libatomic/libatomic_i.h:288:37: note: in expansion of macro ‘C2’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ | ^~ /home/kraj/work/gcc/libatomic/exch_n.c:128:1: note: in expansion of macro ‘EXPORT_ALIAS’ 128 | EXPORT_ALIAS (SIZE(exchange)); | ^~~~ In file included from /home/kraj/work/gcc/libatomic/fop_n.c:25, from /home/kraj/work/gcc/libatomic/fand_n.c:3: /home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error: ‘export_fetch_and_16’ aliased to undefined symbol ‘libat_fetch_and_16’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ |^~~ /home/kraj/work/gcc/libatomic/libatomic_i.h:40:25: note: in definition of macro ‘C2_’ 40 | #define C2_(X,Y)X ## Y | ^ /home/kraj/work/gcc/libatomic/libatomic_i.h:288:37: note: in expansion of macro ‘C2’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ | ^~ /home/kraj/work/gcc/libatomic/fop_n.c:199:1: note: in expansion of macro ‘EXPORT_ALIAS’ 199 | EXPORT_ALIAS (SIZE(C2(fetch_,NAME))); | ^~~~ In file included from /home/kraj/work/gcc/libatomic/fadd_n.c:25: /home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error: ‘export_fetch_add_16’ aliased to undefined symbol ‘libat_fetch_add_16’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ |^~~
[Bug target/114334] [14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn and:HF?) with lroundf16() and -ffast-math -mavx512fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114334 Hongtao Liu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Hongtao Liu --- Fixed in GCC14.
[Bug target/114334] [14 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn and:HF?) with lroundf16() and -ffast-math -mavx512fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114334 --- Comment #2 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:942d470a5a4fb1baeff943127a81b441dffaa543 commit r14-9512-g942d470a5a4fb1baeff943127a81b441dffaa543 Author: liuhongt Date: Fri Mar 15 10:59:10 2024 +0800 Add missing hf/bf patterns. It will be used by copysignm3/xorsignm3/lroundmn2 expanders. gcc/ChangeLog: PR target/114334 * config/i386/i386.md (mode): Add new number V8BF,V16BF,V32BF. (MODEF248): New mode iterator. (ssevecmodesuffix): Hanlde BF and HF. * config/i386/sse.md (andnot3): Extend to HF/BF. (3): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr114334.c: New test.
[Bug tree-optimization/66862] OpenMP SIMD does not work (use SIMD instructions) on conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862
--- Comment #5 from Hongtao Liu ---
> Now, it seems AVX512BW (and AVX512VL in some cases) has the needed
> instructions,
> in particular VMOVDQU{8,16}, but it is not reflected in maskload and
> maskstore expanders. CCing Kyrill and Uros on this.
w/ -mavx512bw and -mavx512vl, the loop is vectorized since GCC 8.1.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #54 from John David Anglin --- The f-m-o issue is probably fixed.
[Bug c++/48026] #pragma optimize ignored for C++ for preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026 Andrew Pinski changed: What|Removed |Added CC||tellowkrinkle at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 114370 has been marked as a duplicate of this bug. ***
[Bug pch/114370] __OPTIMIZE__ is still defined after pop_options from a PCH file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114370 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Looking into PR 48026, I see the patch which was added there is basically this issue so marking it as a dup. *** This bug has been marked as a duplicate of bug 48026 ***
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #53 from GCC Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:f0fda1aff0b752e4182c009c5526b9306bd35f7c commit r14-9511-gf0fda1aff0b752e4182c009c5526b9306bd35f7c Author: John David Anglin Date: Mon Mar 18 00:19:36 2024 + hppa: Improve handling of REG+D addresses when generating PA 2.0 code In looking at PR 112415, it became clear that improvements could be made in the handling of loads and stores using REG+D addresses. A change in 2002 conflated two issues: 1) We can't generate insns with 14-bit displacements before reload completes when generating PA 1.x code since floating-point loads and stores only support 5-bit offsets in PA 1.x. 2) The GNU ELF 32-bit linker lacks relocation support for PA 2.0 floating point instructions with 14-bit displacements. These relocations affect instructions with symbolic references. The result of the change was to block creation of PA 2.0 instructions with 14-bit REG_D displacements for SImode, DImode, SFmode and DFmode on the GNU linux target before reload. This was unnecessary as these instructions don't need relocation. This change revises the INT14_OK_STRICT define to allow creation of instructions with 14-bit REG+D addresses before reload when generating PA 2.0 code. 2024-03-17 John David Anglin gcc/ChangeLog: PR rtl-optimization/112415 * config/pa/pa.cc (pa_emit_move_sequence): Revise condition for symbolic memory operands. (pa_legitimate_address_p): Revise LO_SUM condition. * config/pa/pa.h (INT14_OK_STRICT): Revise define. Move comment about GNU linker to predicates.md. * config/pa/predicates.md (floating_point_store_memory_operand): Revise condition for symbolic memory operands. Update comment.
[Bug c++/114370] New: _mm_srli_si128 fails to compile with PCH that uses pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114370
Bug ID: 114370
Summary: _mm_srli_si128 fails to compile with PCH that uses
pragma GCC optimize
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tellowkrinkle at gmail dot com
Target Milestone: ---
To reproduce:
1. Create the following files:
PCH.h:
#pragma once
#pragma GCC push_options
#pragma GCC optimize("Og")
struct monostate {
constexpr monostate() {}
};
#pragma GCC pop_options
GSState.cpp:
#include
__m128i GIFPackedRegHandlerXYZF2(const __m128i* r)
{
return _mm_srli_si128(*r, 4);
}
PCH.cpp:
2. `g++ -x c++-header -include PCH.h -c PCH.cpp -o PCH.h.gch`
3. `g++ -include PCH.h -c GSState.cpp -o GSState.o`
(3) fails with
In file included from
/usr/lib/gcc/x86_64-redhat-linux/13/include/xmmintrin.h:1322,
from
/usr/lib/gcc/x86_64-redhat-linux/13/include/immintrin.h:31,
from GSState.cpp:4:
In function ‘__m128i _mm_srli_si128(__m128i, int)’,
inlined from ‘__m128i GIFPackedRegHandlerXYZF2(const __m128i*)’ at
GSState.cpp:8:23:
/usr/lib/gcc/x86_64-redhat-linux/13/include/emmintrin.h:1229:10: error: the
last argument must be an 8-bit immediate
1229 | return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
| ^
`gcc -v`:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.2.1-20231205/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20231205 (Red Hat 13.2.1-6) (GCC)
[Bug testsuite/63719] gcc-set-multilib-library-path usage outside of gcc/testsuite/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63719 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed for GCC 10 by r10-5635-gd42b84f427e404 which was done for exactly this issue.
[Bug testsuite/87958] scan-tree-dump-times vs. (foo|bar)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87958
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-03-17
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
Confirmed.
Note scan-assembler-times most likely should have the same documentation.
Also note scan-tree-dump-times is documented under
`scan-@var{kind}-dump-times`.
[Bug debug/52658] struct/union types don't print out all of the field with -fdump-tree-original-raw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52658
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|RECORD_TYPE in generic tree |struct/union types don't
|dump file with non-complete |print out all of the field
|FIELD_DECL tree node|with
||-fdump-tree-original-raw
Last reconfirmed||2024-03-17
--- Comment #2 from Andrew Pinski ---
Confirmed.
Simplified testcase:
```
struct a
{ int field1;int field2;};
int f(struct a b)
{
return b.field1;
}
```
Only the first field1 shows up in the dump even though `struct a` contains
field2 too.
[Bug c/114364] Untranslatable string 'in intervening code'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364 --- Comment #3 from Roland Illig --- The diff looks good to me. Untested.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 --- Comment #7 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3f3f0b7ee8022776d69ecaed1375e1559716f226 commit r14-9509-g3f3f0b7ee8022776d69ecaed1375e1559716f226 Author: Harald Anlauf Date: Fri Mar 15 20:14:07 2024 +0100 Fortran: fix for absent array argument passed to optional dummy [PR101135] gcc/fortran/ChangeLog: PR fortran/101135 * trans-array.cc (gfc_get_dataptr_offset): Check for optional arguments being present before dereferencing data pointer. gcc/testsuite/ChangeLog: PR fortran/101135 * gfortran.dg/missing_optional_dummy_6a.f90: Adjust diagnostic pattern. * gfortran.dg/ubsan/missing_optional_dummy_8.f90: New test.
[Bug testsuite/40130] using RUNTESTFLAGS="--target_board 'foo{-mxyz,-mjkl,}'" screws up ieee.exp (and possibly others?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
--- Comment #10 from Andrew Pinski ---
(In reply to Uroš Bizjak from comment #9)
> BTW: Since you are looking in this area, can you add
> __attribute__((noinline)) to the tests? Some of them are too easy to
> optimize for recent optimizing passes ;)
-fno-inline was added by r0-95831-g9e2ceea07aaab0 .
I tried to reproduce the original reported bug on x86_64 with:
make -k check-gcc RUNTESTFLAGS="--target_board 'unix{,-m32}{-march=k8,}'
ieee.exp=20010114-2.c"
But it is looking like it is working:
Executing on host: /bajas/pinskia/src/upstream-gcc-match/gcc/objdir/gcc/xgcc
-B/bajas/pinskia/src/upstream-gcc-match/gcc/objdir/gcc/
/home/apinski/src/upstream-gcc-match/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/20010114-2.c
-m32 -march=k8 -fdiagnostics-plain-output -w -O0 -fno-inline
-ffloat-store -lm -o
/bajas/pinskia/src/upstream-gcc-match/gcc/objdir/gcc/testsuite/gcc/20010114-2.x0
(timeout = 300)
...
Executing on host: /bajas/pinskia/src/upstream-gcc-match/gcc/objdir/gcc/xgcc
-B/bajas/pinskia/src/upstream-gcc-match/gcc/objdir/gcc/
/home/apinski/src/upstream-gcc-match/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/20010114-2.c
-m32 -fdiagnostics-plain-output -w -O0 -fno-inline -ffloat-store -lm -o
/bajas/pinskia/src/upstream-gcc-match/gcc/objdir/gcc/testsuite/gcc/20010114-2.x0
(timeout = 300)
[Bug tree-optimization/56457] Bogus warning: loop-invariant.c:786:20: error: unused variable ‘regno’ when building vax-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56457 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #5 from Jeffrey A. Law --- Per c#4.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 56457, which changed state. Bug 56457 Summary: Bogus warning: loop-invariant.c:786:20: error: unused variable ‘regno’ when building vax-*-* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56457 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756 Bug 44756 depends on bug 56457, which changed state. Bug 56457 Summary: Bogus warning: loop-invariant.c:786:20: error: unused variable ‘regno’ when building vax-*-* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56457 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug testsuite/90113] Useless torture mode for gfortran.dg tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90113 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 28032. *** This bug has been marked as a duplicate of bug 28032 ***
[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032 Andrew Pinski changed: What|Removed |Added CC||zhroma at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- *** Bug 90113 has been marked as a duplicate of this bug. ***
[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-17 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- gfortran-dg-runtest is always torture. I am not sure if we want to change that but we definitely need a non torture area to run some testcases that have explicitly needs.
[Bug testsuite/28032] gfortran.dg/secnds.f test not honoring dg-options flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032 --- Comment #4 from Andrew Pinski --- Created attachment 57720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57720=edit more complete list of tests in gfortran.dg/ that contain dg-options that has -O in it
[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 Gerald Pfeifer changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||gerald at pfeifer dot com Last reconfirmed||2024-03-17 --- Comment #3 from Gerald Pfeifer --- I first reported this in July 2019; see https://gcc.gnu.org/pipermail/gcc/2019-July/229869.html and in particular the three responses https://gcc.gnu.org/pipermail/gcc/2019-July/229870.html https://gcc.gnu.org/pipermail/gcc/2019-July/229871.html https://gcc.gnu.org/pipermail/gcc/2019-July/229872.html for some more context.
[Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- (In reply to Dave Korn from comment #6) > That would work fine for --static, but as things stand now, it will still > fail when just --static-libstdc++ is in use. This is because of the > situation described in the two dependency PRs (Bug 41594 and Bug 41596) Both bugs upon which this one depends have been closed; time to revise this one's SUSPENDED status?
[Bug c++/57971] Improve copy elision when returning structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57971 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-17 --- Comment #2 from Andrew Pinski --- Confirmed. clang is able to optimize this case.
[Bug sanitizer/69443] -fsanitize=address should add -lpthread to linker call for older glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69443 Andrew Pinski changed: What|Removed |Added Summary|-fsanitize=address should |-fsanitize=address should |add -lpthread to linker |add -lpthread to linker |call|call for older glibc --- Comment #3 from Andrew Pinski --- This is not as much an issue any more since glibc has moved all (most?) functions pthread into libc proper now.
[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/85579 --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > The gcc altivec.h defines it as a function-like macro, so not a problem. > So perhaps a clang bug for not defining it as a function-like macro only? I filed it as https://github.com/llvm/llvm-project/issues/85579 also . Let's see what is mentioned htere.
[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 --- Comment #1 from Jakub Jelinek --- The gcc altivec.h defines it as a function-like macro, so not a problem. So perhaps a clang bug for not defining it as a function-like macro only?
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #33 from Andrew Pinski --- (In reply to Piotr Kubaj from comment #32) > (In reply to Iain Sandoe from comment #31) > > what is the current situation with this > > - what input are we waiting for? > > - is the problem now cleared for powerpc64-freebsd? > Probably not, but FreeBSD now uses ELFv2 and LLVM, GCC builds fine with LLVM > with one small patch: Filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 since I saw someone else having the same issue too. Otherwise closing as fixed.
[Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 Bug ID: 114369 Summary: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Forwarded from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 and https://lists.tetaneutral.net/pipermail/cfarm-users/2024-March/001074.html vec_step is used as a variable name in tree-vect-loop.cc a few times though it is an altivec intrinsics which causes building GCC with clang (libc++). We should work around this in the GCC sources.
[Bug d/109681] suggested preview switches use DMD preview flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109681 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Iain Buclaw --- For now, upstream has version condition around the error messages to give the gdc-style option names if version(IN_GCC). https://github.com/dlang/dmd/pull/15747 Downstreamed into mainline since r14-5083.
[Bug libstdc++/114368] New: FAIL: 25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc -std=gnu++17 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114368 Bug ID: 114368 Summary: FAIL: 25_algorithms/pstl/alg_sorting/set_symmetric_differenc e.cc -std=gnu++17 execution test Product: gcc Version: 14.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: hppa*-*-linux* Target: hppa*-*-linux* Build: hppa*-*-linux* spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home /dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gn u/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/. libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/ home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-14 /hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/inclu de -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/sys-include -fchecking= 1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -fmessage- length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOUR CE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd c++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc ++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/g cc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/tests uite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/25_algorithms/pstl/alg_s orting/set_symmetric_difference.cc -std=gnu++17 -ltbb -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/lib stdc++-v3/src/filesystem/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd c++-v3/src/experimental/.libs -lm -o ./set_symmetric_difference.exe In file included from /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl ude/hppa-linux-gnu/bits/c++config.h:887, from /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl ude/bits/requires_hosted.h:31, from /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl ude/execution:30, from /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/25_algorithm s/pstl/alg_sorting/set_symmetric_difference.cc:28: /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In func tion '_RandomAccessIterator __pstl::__internal::__brick_unique(_RandomAccessIter ator, _RandomAccessIterator, _BinaryPredicate, std::true_type)': /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:1219: no te: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplement ed, redirected to serial"' /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In func tion '_RandomAccessIterator __pstl::__internal::__brick_partition(_RandomAccessI terator, _RandomAccessIterator, _UnaryPredicate, std::true_type)': /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:1929: no te: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplement ed, redirected to serial"' /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In func tion '_RandomAccessIterator __pstl::__internal::__brick_stable_partition(_Random AccessIterator, _RandomAccessIterator, _UnaryPredicate, std::true_type)': /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:2029: no te: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplement ed, redirected to serial"' /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In func tion '_RandomAccessIterator3 __pstl::__internal::__brick_merge(_RandomAccessIter ator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2, _ RandomAccessIterator3, _Compare, std::true_type)': /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:2715: no te: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplement ed, redirected to serial"' /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In function 'void __pstl::__internal::__brick_inplace_merge(_RandomAccessIterator, _RandomAccessIterator, _RandomAccessIterator, _Compare, std::true_type)': /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:2764: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_OutputIterator __pstl::__internal::__brick_set_union(_RandomAccessIterator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2, _OutputIterator, _Compare, std::true_type)':
[Bug libstdc++/114316] assert failure with _GLIBCXX_DEBUG and empty range of singular iterators passed to std:: algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114316 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Francois Dumont : https://gcc.gnu.org/g:c1f57ff40738bbce9902ea25865ed6d729b10127 commit r13-8460-gc1f57ff40738bbce9902ea25865ed6d729b10127 Author: François Dumont Date: Thu Mar 14 22:13:57 2024 +0100 libstdc++: Implement N3644 on _Safe_iterator<> [PR114316] Consider range of value-initialized iterators as valid and empty. libstdc++-v3/ChangeLog: PR libstdc++/114316 * include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_valid_range): First check if both iterators are value-initialized before checking if singular. * testsuite/23_containers/set/debug/114316.cc: New test case. * testsuite/23_containers/vector/debug/114316.cc: New test case. (cherry picked from commit 07fad7a7fc245369989e9ca746728ea78b924715)
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 --- Comment #10 from dave.anglin at bell dot net --- Warning is fixed on hppa.
[Bug libstdc++/114316] assert failure with _GLIBCXX_DEBUG and empty range of singular iterators passed to std:: algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114316 --- Comment #2 from GCC Commits --- The master branch has been updated by Francois Dumont : https://gcc.gnu.org/g:07fad7a7fc245369989e9ca746728ea78b924715 commit r14-9507-g07fad7a7fc245369989e9ca746728ea78b924715 Author: François Dumont Date: Thu Mar 14 22:13:57 2024 +0100 libstdc++: Implement N3644 on _Safe_iterator<> [PR114316] Consider range of value-initialized iterators as valid and empty. libstdc++-v3/ChangeLog: PR libstdc++/114316 * include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_valid_range): First check if both iterators are value-initialized before checking if singular. * testsuite/23_containers/set/debug/114316.cc: New test case. * testsuite/23_containers/vector/debug/114316.cc: New test case.
[Bug modula2/114296] ICE when attempting to create a constant set with a variable element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114296
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Gaius Mulley ---
Closing now that the patch has been applied. The ICE was caused by assuming
that the set elements were constants. The patch contains a check and also
improves the token accuracy of the set sub expression.
The test code above now causes the following correct error message:
$ gm2 tiny2.mod
tiny2.mod:8:10: error: a constant set can only contain constant set elements,
‘x’ is not a constant
8 |ch := {7 .. x};
| ^~~~
[Bug modula2/114296] ICE when attempting to create a constant set with a variable element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114296 --- Comment #2 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:f065c582d9c8e0a4fee7ee563c584ee3b1975bea commit r14-9506-gf065c582d9c8e0a4fee7ee563c584ee3b1975bea Author: Gaius Mulley Date: Sun Mar 17 14:49:23 2024 + PR modula2/114296 ICE when attempting to create a constant set with a variable element This patch corrects the virtual token creation for the aggregate constant and also corrects tokens for constructor components. gcc/m2/ChangeLog: PR modula2/114296 * gm2-compiler/M2ALU.mod (ElementsSolved): Add tokenno parameter. Add constant checks and generate error messages. (EvalSetValues): Pass tokenno parameter to ElementsSolved. * gm2-compiler/M2LexBuf.mod (stop): New procedure. (MakeVirtualTok): Call stop if caret = BadTokenNo. * gm2-compiler/M2Quads.def (BuildNulExpression): Add tokpos parameter. (BuildSetStart): Ditto. (BuildEmptySet): Ditto. (BuildConstructorEnd): Add startpos parameter. (BuildTypeForConstructor): Add tokpos parameter. * gm2-compiler/M2Quads.mod (BuildNulExpression): Add tokpos parameter and push tokpos to the quad stack. (BuildSetStart): Add tokpos parameter and push tokpos. (BuildSetEnd): Rewrite. (BuildEmptySet): Add tokpos parameter and push tokpos with the set type. (BuildConstructorStart): Pop typepos. (BuildConstructorEnd): Add startpos parameter. Create valtok from startpos and cbratokpos. (BuildTypeForConstructor): Add tokpos parameter. * gm2-compiler/M2Range.def (InitAssignmentRangeCheck): Rename d to des and e to expr. Add destok and exprtok parameters. * gm2-compiler/M2Range.mod (InitAssignmentRangeCheck): Rename d to des and e to expr. Add destok and exprtok parameters. Save destok and exprtok into range record. (FoldAssignment): Pass exprtok to TryDeclareConstant. * gm2-compiler/P3Build.bnf (ComponentValue): Rewrite. (Constructor): Rewrite. (ConstSetOrQualidentOrFunction): Rewrite. (SetOrQualidentOrFunction): Rewrite. * gm2-compiler/PCBuild.bnf (ConstSetOrQualidentOrFunction): Rewrite. (SetOrQualidentOrFunction): Rewrite. * gm2-compiler/PHBuild.bnf (Constructor): Rewrite. (ConstSetOrQualidentOrFunction): Rewrite. gcc/testsuite/ChangeLog: PR modula2/114296 * gm2/pim/fail/badtype2.mod: New test. Signed-off-by: Gaius Mulley
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012
Anuj Mohite changed:
What|Removed |Added
CC||anujmohite001 at gmail dot com
--- Comment #4 from Anuj Mohite ---
can we split the original error message into two separate calls to gfc_error()
fuction. file: fortran/symbol.cc
Before changes:
gfc_error ("%s procedure at %L is already declared as %s "
"procedure. \nF2008: A pointer function assignment "
"is ambiguous if it is the first executable statement "
"after the specification block. Please add any other "
"kind of executable statement before it. FIXME",
After changes:
// Main error message
gfc_error ("%s procedure at %L is already declared as %s procedure",
gfc_code2string(procedures, t), where,
gfc_code2string(procedures, attr->proc));
// Additional information for F2008 standard
gfc_error("A pointer function assignment is ambiguous if it is the first "
"executable statement after the specification block. Please add "
"any other kind of executable statement before it.");
[Bug c++/66034] Enhancement request: fiber-local storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66034 --- Comment #3 from Avi Kivity --- Yes, this is relevant to user-level threads, not coroutines.
[Bug d/114155] gdc.test/runnable/literal.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 --- Comment #2 from Iain Buclaw --- Fix to format hexstrings as big endian has been committed from upstream merge. r14-9505 This should be resolved now.
[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 Xi Ruoyao changed: What|Removed |Added Target|riscv, loongarch, x86_64|riscv, loongarch, x86_64, ||mips --- Comment #26 from Xi Ruoyao --- Comment 14 test case also fails with GCC 13.2 on mips64el, but not aarch64.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #32 from Piotr Kubaj --- (In reply to Iain Sandoe from comment #31) > what is the current situation with this > - what input are we waiting for? > - is the problem now cleared for powerpc64-freebsd? Probably not, but FreeBSD now uses ELFv2 and LLVM, GCC builds fine with LLVM with one small patch: Index: gcc/tree-vect-loop.cc === --- gcc/tree-vect-loop.cc (revision 273856) +++ gcc/tree-vect-loop.cc (working copy) @@ -55,6 +55,8 @@ along with GCC; see the file COPYING3. If not see #include "vec-perm-indices.h" #include "tree-eh.h" +#define vec_step vec_step_ + /* Loop Vectorization Pass. This pass tries to vectorize loops. All the releases using GCC 4.2.1 are EOL now.
[Bug libstdc++/114367] std::vector constexpr initialization doesn't start lifetime of array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367 --- Comment #3 from Jonathan Wakely --- Yeah this needs to use construct_at
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275 --- Comment #4 from Nathaniel Shead --- I suspect there are a number of issues tied together here. Some of the things I've discovered so far: - 'tsubst_friend_class' calls 'lookup_name', which when called from a module that doesn't export the class that was befriended fails to find it, and so it substitutes in a new instance of that type (which then later fails duplicate_decls). - Instantiating an elaborated type specifier doesn't attach it to the module the containing template was declared in. - Sometimes it seems that the container of a MK_local_friend decl is not always correctly streamed: in particular, in the comment 2 testcase the container streamed is a complete type on write, but on read is not complete (TYPE_SIZE is null) and so is not properly read on stream-in in the first place. Additionally, it looks like you can hide some of the errors by making the importer a named module, because on instantiation it only calls 'duplicate_decls' on names imported from a partition.
[Bug c++/66034] Enhancement request: fiber-local storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66034 --- Comment #2 from Jonathan Wakely --- C++ coroutines are allocated on the heap though. https://wg21.link/p0876 is more relevant here, but not approved yet.
[Bug c++/66034] Enhancement request: fiber-local storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66034 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- C++20 adds coroutines which like fibers and already contains local storage state. https://en.cppreference.com/w/cpp/language/coroutines So this is a won't fix.
[Bug middle-end/60528] GCC puts out floating point constants differently depending on if long is 32bit or 64bit (due to use of long for encode_ieee_double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60528 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|GCC puts out floating point |GCC puts out floating point |constants differently |constants differently |depending on if long is |depending on if long is |32bit or 64bit |32bit or 64bit (due to use |(encode_ieee_double)|of long for ||encode_ieee_double) Last reconfirmed||2024-03-17 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug target/64753] Redundant cmp instruction on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64753 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |9.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- r8-647-g4f0473fe89e68b and some more improvement that was done in GCC 9.
[Bug middle-end/64457] NVCC like features CUDA/OpenCL support for GCC to use GPU's to speed up compile jobs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64457 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Andrew Pinski --- Fixed in GCC 5+, see https://gcc.gnu.org/wiki/Offloading for the support options and even how to do it.
[Bug c++/64053] asm labels to accept extra parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64053 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-17 Keywords||inline-asm Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- I wonder if doing constexpr is better similar in the way that is proposed for inline-asm : https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647821.html This would be easier to support I think and would be more obvious and stuff like fmt supports formating at compile time with constexpr even.
[Bug testsuite/63297] ASan reported heap-use-after-free in g++.old-deja/g++.law/virtual3.C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63297 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||testsuite-fail Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-17 --- Comment #1 from Andrew Pinski --- Confirmed. Note patches should sent to gcc-patches@ after reading https://gcc.gnu.org/contribute.html . The testcase dates from 1993 so I am not surprised at bugs like this in the testcase itself.
[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 --- Comment #16 from Amir Shahmoradi --- A new optional flag could be a viable (and in my opinion, very good) solution. Unfortunately, I do not have the expertise and experience with gfortran internals to propose and implement a patch for such an option.
[Bug c++/104343] improved error message for passing overloaded function to variadic(templated)-argument function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104343 --- Comment #8 from Andrew Pinski --- (In reply to Frank Heckenbach from comment #7) > #3 points out "Also, GCC 7 has been unsupported for a couple of years." My > new "duplicate" report shows that the problem still exists with current > versions. You might want to update the version number to make it clear that > it's still relevant. That comment about gcc 7 years being unsupported was partly due tobthe original bug report being not clear at what the issue was and being reported against a much older release than what was st the time being supported. I will update the known to fail field tomorrow to include new versions so it is more obvious it still fails. Note the version field is more for against when it was reported rather than if it fails with the latest version.
[Bug c++/104343] improved error message for passing overloaded function to variadic(templated)-argument function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104343 --- Comment #7 from Frank Heckenbach --- #3 points out "Also, GCC 7 has been unsupported for a couple of years." My new "duplicate" report shows that the problem still exists with current versions. You might want to update the version number to make it clear that it's still relevant. (Actually, I think it would be good if bugzilla would automatically set the version to the latest one when merging, but I don't know how hard this would be to implement.)
