[Bug c/93537] gcc 9.2 takes a Segmentation Violation when attached file is compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93537 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- I can't figure what fixed it ... But it seems to have been fixed in GCC 10.1.0.
[Bug c/88642] Accepts ill-formed program with invalid scalar initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88642 --- Comment #3 from Andrew Pinski --- So this code is quiet old. There was an error back before r0-5028-g790e949032a94b (1993, change by RMS) and mailing lists don't exist that far back ...
[Bug c/88642] Accepts ill-formed program with invalid scalar initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88642
--- Comment #2 from Andrew Pinski ---
We do warn:
: In function 'main':
:3:5: warning: braces around scalar initializer
3 | int x = { { 0 } } ;
| ^~~
Maybe this should be a pedantic warning instead ...
if (constructor_type != error_mark_node)
warning_init (input_location, 0, "braces around scalar initializer");
[Bug c/86885] gcc erroneously allows constructor/destructor attributes on nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86885
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.1.2
--- Comment #2 from Andrew Pinski ---
Hmm, the code does:
if (TREE_CODE (decl) == FUNCTION_DECL
&& TREE_CODE (type) == FUNCTION_TYPE
&& decl_function_context (decl) == 0)
{
Which means this was supposed to be rejected (decl_function_context is supposed
to return if the context of a function is a function or not) but maybe we set
the DECL_CONTEXT of the function too late now.
The decl_function_context check has been there since constructor attribute
support was added by Jason in 1995 (r0-8721-g2c5f4139a91db2) . I am 90% sure
this worked at one point but I have no way to test anything earlier than 4.1.2
though.
[Bug c/86885] gcc erroneously allows constructor/destructor attributes on nested functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86885 --- Comment #1 from Andrew Pinski --- Created attachment 57908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57908=edit testcase
[Bug middle-end/87535] multiple attribute assume_aligned interpreted inconsistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87535 Andrew Pinski changed: What|Removed |Added Depends on||64236 --- Comment #3 from Andrew Pinski --- I think this is basically a dup of bug 64236. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64236 [Bug 64236] [c++11] last alignas overrides stricter on a class definition
[Bug c/65007] __builtin_uaddll_overflow wrong *res declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65007 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |7.0 Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed by r7-3104-g6e395fcb44dafb for GCC 7.
[Bug c/56335] Optimization assumes __attribute__((aligned(N))) always works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87795, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89357 Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |9.3 --- Comment #3 from Andrew Pinski --- > .comm a,512,134217728 The linker should fail to link if it can't link to 128 MB here. >From JSM's email: > MAX_OFILE_ALIGNMENT (presently just a warning), That was PR 87795 and was fixed in r9-3979-g4c7bd36194e13c . > an object with automatic storage duration has an alignment greater than > MAX_STACK_ALIGNMENT See PR 89357 which removed the constraint for C++ _Alignas as the middle-end supports huge alignments now. So closing as fixed for GCC 9.3.0.
[Bug c/87795] Excessive alignment permitted for functions and labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/58806] New attribute for functions that access memory only through their arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-09 Keywords||missed-optimization --- Comment #6 from Andrew Pinski --- I thought there was a way already to do this. But nope.
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #7 from Li Pan --- Looks this commit from bisect acc22d56e140220e7dc6c138918cb6754b6d1c0b, will take a look into it.
[Bug other/57956] missing 'msgstr' section errors when building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956 Andrew Pinski changed: What|Removed |Added Keywords||build, documentation Last reconfirmed||2024-04-09 Resolution|FIXED |--- Ever confirmed|0 |1 Status|RESOLVED|ASSIGNED --- Comment #4 from Andrew Pinski --- Actually It looks like it still says: gettext version 0.14.5 (or later) Needed to regenerate gcc.pot. Let me update that to the same as what is required to build GCC (if --enable-nls is used and libintl is not supported).
[Bug other/57956] missing 'msgstr' section errors when building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- The page says now: The in-tree configuration requires GNU gettext version 0.22 or later.
[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624 --- Comment #4 from Andrew Pinski --- Hmm, Does this matter that much since HLE has been disabled on all cores?
[Bug target/55139] __atomic store does not support __ATOMIC_HLE_RELEASE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.8.0 --- Comment #7 from Andrew Pinski --- Fixed a long time ago.
[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #13 from Kewen Lin --- (In reply to Giuliano Belinassi from comment #12) > With your patch we have: > > > .LPFE0: > > ... > Which seems what is expected. Hi Giuliano, thanks for your time on testing it! Could you kindly help to explain a bit on why "In such way we can't use the this space to place a trampoline to the new function"? Is it due to inefficient code like needing more branches? global entry: [b localentry] L1: [patched code] localentry: [b L1] Or some other reason which makes it unused at all?
[Bug target/55966] __atomic_fetch_* generate wrong code for HLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #10 from Andrew Pinski --- Dropping __ATOMIC_HLE_ACQUIRE/__ATOMIC_HLE_RELEASE is always ok thing to do, it is only there for a hint anyways. So closing as won't fix as Intel also disable HLE on almost all cores anyways: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2955f270a84762343000f103e0640d29c7a96f3
[Bug target/55947] non constant memory models lose HLE qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- Invalid as explained.
[Bug target/114587] -mapxf should define a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587 --- Comment #4 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:18e94e04dae724c61cbc13ace85fa68f2deda900 commit r14-9852-g18e94e04dae724c61cbc13ace85fa68f2deda900 Author: H.J. Lu Date: Mon Apr 8 18:57:49 2024 -0700 x86: Define __APX_INLINE_ASM_USE_GPR32__ Define __APX_INLINE_ASM_USE_GPR32__ for -mapx-inline-asm-use-gpr32. When __APX_INLINE_ASM_USE_GPR32__ is defined, inline asm statements should contain only instructions compatible with r16-r31. gcc/ PR target/114587 * config/i386/i386-c.cc (ix86_target_macros_internal): Define __APX_INLINE_ASM_USE_GPR32__ for -mapx-inline-asm-use-gpr32. gcc/testsuite/ PR target/114587 * gcc.target/i386/apx-3.c: Likewise.
[Bug target/56009] Nested global destruction semantics not working (mingw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56009 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=2474 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > This is IIRC the whole atexit vs __cxa_atexit issue. Which is PR 2474 .
[Bug target/56009] Nested global destruction semantics not working (mingw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56009 --- Comment #3 from Andrew Pinski --- This is IIRC the whole atexit vs __cxa_atexit issue.
[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > (In reply to Andrew Pinski from comment #5) > > for try blocks, I do need the catch blocks so do it as the siblings. > > For catch blocks, the child will be type that is being caught as a > > DW_TAG_formal_parameter/DW_TAG_unspecified_parameters . > > Note DW_TAG_unspecified_parameters is for the catch(...) case. > > I am adding this more for my usage when I am coding this up to make sure I > understand how this works. for the VAR_DECL of the catch, I think I should be able to use gen_formal_parameter_die. This means the block structure will need to grow since I need another tree here. Or maybe not. Since there seems like there are 2 BLOCKs here for the catch.
[Bug testsuite/114614] New test case gcc.misc-tests/gcov-20.c from r14-9789-g08a52331803f66 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614 Kewen Lin changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Kewen Lin --- Should be fixed on latest trunk.
[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > for try blocks, I do need the catch blocks so do it as the siblings. > For catch blocks, the child will be type that is being caught as a > DW_TAG_formal_parameter/DW_TAG_unspecified_parameters . Note DW_TAG_unspecified_parameters is for the catch(...) case. I am adding this more for my usage when I am coding this up to make sure I understand how this works.
[Bug testsuite/114614] New test case gcc.misc-tests/gcov-20.c from r14-9789-g08a52331803f66 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614 --- Comment #2 from GCC Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:9c97de682303b81c8886ac131fcfb3b122f2f1a6 commit r14-9851-g9c97de682303b81c8886ac131fcfb3b122f2f1a6 Author: Kewen Lin Date: Mon Apr 8 21:02:17 2024 -0500 testsuite: Add profile_update_atomic check to gcov-20.c [PR114614] As PR114614 shows, the newly added test case gcov-20.c by commit r14-9789-g08a52331803f66 failed on targets which do not support atomic profile update, there would be a message like: warning: target does not support atomic profile update, single mode is selected Since the test case adopts -fprofile-update=atomic, it requires effective target check profile_update_atomic, this patch is to add the check accordingly. PR testsuite/114614 gcc/testsuite/ChangeLog: * gcc.misc-tests/gcov-20.c: Add effective target check profile_update_atomic.
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 --- Comment #7 from GCC Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:26eb5f8fd173e2425ae7505528fc426de4b7e34c commit r14-9850-g26eb5f8fd173e2425ae7505528fc426de4b7e34c Author: Kewen Lin Date: Mon Apr 8 21:01:36 2024 -0500 rs6000: Fix wrong align passed to build_aligned_type [PR88309] As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch is to fix them by converting bytes to bits, add an assertion on positive align_unit value and notes function build_aligned_type requires align measured in bits in its function comment. PR target/88309 Co-authored-by: Andrew Pinski gcc/ChangeLog: * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Fix wrong align passed to function build_aligned_type. * tree-ssa-loop-prefetch.cc (is_miss_rate_acceptable): Add an assertion to ensure align_unit should be positive. * tree.cc (build_qualified_type): Update function comments. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr88309.c: New test.
[Bug testsuite/114642] new test case gcc.dg/debug/btf/btf-datasec-3.c from r14-6195-gb8cf266f4ca4ff fails for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642 --- Comment #3 from Andrew Pinski --- (In reply to Kewen Lin from comment #2) > David posted a fix (see URL). Oh yes that should fix it for MIPS and RISCV too.
[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436 --- Comment #5 from Andrew Pinski --- for try blocks, I do need the catch blocks so do it as the siblings. For catch blocks, the child will be type that is being caught as a DW_TAG_formal_parameter/DW_TAG_unspecified_parameters .
[Bug testsuite/114642] new test case gcc.dg/debug/btf/btf-datasec-3.c from r14-6195-gb8cf266f4ca4ff fails for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642 Kewen Lin changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-April/6 ||48994.html CC||linkw at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |david.faust at oracle dot com --- Comment #2 from Kewen Lin --- David posted a fix (see URL).
[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436 --- Comment #4 from Andrew Pinski --- So for space, on LP64 (and LLP64) hosts, there is a free 32bits in the BLOCK structure: ``` tree chain; unsigned block_num; location_t locus; // unsigned location_t end_locus; // unsigned tree vars; ``` So I can at least add a 3bit field without increasing the size too.
[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Interesting it was mentioned here: https://gcc.gnu.org/legacy-ml/gcc/2003-12/msg00336.html I wonder if we could mark the BLOCK as being the try block and then output DW_TAG_try_block instead of DW_TAG_lexical_block . Likewise for catch. Maybe I will give that a go for GCC 15. Though I might be only handle the C++ front-end. Others will need to handle other FEs.
[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/14523 --- Comment #2 from Andrew Pinski --- LLVM's bug report: https://github.com/llvm/llvm-project/issues/14523 :).
[Bug debug/39436] g++ does not emit DW_TAG_try_block or DW_TAG_catch_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- So I could get ICC to produce them but clang does not.
[Bug modula2/114648] compiler by default does not handle C pre-processor file and line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Gaius Mulley --- Closing now the patch has been applied.
[Bug modula2/114648] compiler by default does not handle C pre-processor file and line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648 --- Comment #5 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:600bf396799a022e65938de572ad1a79a951b95a commit r14-9849-g600bf396799a022e65938de572ad1a79a951b95a Author: Gaius Mulley Date: Tue Apr 9 02:35:11 2024 +0100 PR modula2/114648 cc1gm2 by default does not handle C pre-processor file and line directives This patch fixes the default behavior of cc1gm2 to the description in the documentation. By default cc1gm2 will allow C preprocessor directives (they can be turned off via -fno-cpp). gcc/m2/ChangeLog: PR modula2/114648 * gm2-compiler/M2Options.mod (LineDirectives): Initially set to true. gcc/testsuite/ChangeLog: PR modula2/114648 * gm2/cpp/default/pass/AdvParse.def: New test. * gm2/cpp/default/pass/AdvParse.mod: New test. * gm2/cpp/default/pass/cpp-default-pass.exp: New test. Signed-off-by: Gaius Mulley
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #6 from JuzheZhong --- Definitely it is a regression: https://compiler-explorer.com/z/e68x5sT9h GCC 13.2 is ok, but GCC 14 ICE. I think you should bisect first.
[Bug libgomp/45025] Memory ordering issues with libgomp critical sections and __sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45025 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.7.0 --- Comment #6 from Andrew Pinski --- This was fixed by r0-113642-gb40c885f183cb7 which added the C11 atomics barrier.
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #5 from Li Pan ---
(In reply to Kito Cheng from comment #4)
> Reduced case:
> ```c
> typedef long c;
> #pragma riscv intrinsic "vector"
> template struct d {};
> struct e {
> using f = d<0>;
> };
> struct g {
> using f = e::f;
> };
> template using h = g::f;
> template long k(d);
> vbool16_t j(vuint64m4_t a) {
> c b;
> return __riscv_vmsne_vx_u64m4_b16(a, b, k(h()));
> }
>
> ```
Thanks Kito, reproduced on reduced case with option "riscv64-unknown-elf-g++
-O2 -march=rv64gcv". will take a look into it.
during RTL pass: mode_sw
test.c: In function ‘vbool16_t j(vuint64m4_t)’:
test.c:15:1: internal compiler error: in create_pre_exit, at
mode-switching.cc:451
15 | }
| ^
0x3978f12 create_pre_exit
/home/pli/gcc/555/riscv-gnu-toolchain/gcc/__RISCV_BUILD__/../gcc/mode-switching.cc:451
0x3979e9e optimize_mode_switching
/home/pli/gcc/555/riscv-gnu-toolchain/gcc/__RISCV_BUILD__/../gcc/mode-switching.cc:849
0x397b9bc execute
/home/pli/gcc/555/riscv-gnu-toolchain/gcc/__RISCV_BUILD__/../gcc/mode-switching.cc:1324
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug modula2/114648] compiler by default does not handle C pre-processor file and line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648 --- Comment #4 from Gaius Mulley --- Created attachment 57907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57907=edit Proposed fix Trivial patch fix proposed with test code.
[Bug testsuite/39091] x86_64/abi should add tests __float128, __int128 and DFP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39091 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-04-09 Summary|x86_64/abi doesn't test |x86_64/abi should add tests |__float128, __int128 nor|__float128, __int128 and |DFP |DFP Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- (In reply to H.J. Lu from comment #0) > gcc.target/x86_64/abi doesn't test __float128, __int128 nor DFP. __float128 has some tests: test_basic_alignment.c: check_align(__float128, TYPE_ALIGN_FLOAT128); test_basic_array_size_and_align.c: check_array_size_and_align(__float128, TYPE_SIZE_FLOAT128, TYPE_ALIGN_FLOAT128); test_basic_sizes.c: check_size(__float128, TYPE_SIZE_FLOAT128); test_basic_struct_size_and_align.c: check_basic_struct_size_and_align(__float128, TYPE_SIZE_FLOAT128, TYPE_ALIGN_FLOAT128); test_basic_union_size_and_align.c: check_basic_union_size_and_align(__float128, TYPE_SIZE_FLOAT128, TYPE_ALIGN_FLOAT128) So does __int128: test_basic_alignment.c: run_signed_tests2(check_align, __int128, TYPE_ALIGN_INT128); test_basic_array_size_and_align.c: run_signed_tests3(check_array_size_and_align, __int128, TYPE_SIZE_INT128, TYPE_ALIGN_INT128); test_basic_sizes.c: run_signed_tests2(check_size, __int128, TYPE_SIZE_INT128); test_basic_struct_size_and_align.c: run_signed_tests3(check_basic_struct_size_and_align, __int128, TYPE_SIZE_INT128, TYPE_ALIGN_INT128); test_basic_union_size_and_align.c: run_signed_tests3(check_basic_union_size_and_align, __int128, TYPE_SIZE_INT128, TYPE_ALIGN_INT128); But not argument passing now DFP has none of that. I see _Float16 and __bf16 was added though.
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #4 from Kito Cheng ---
Reduced case:
```c
typedef long c;
#pragma riscv intrinsic "vector"
template struct d {};
struct e {
using f = d<0>;
};
struct g {
using f = e::f;
};
template using h = g::f;
template long k(d);
vbool16_t j(vuint64m4_t a) {
c b;
return __riscv_vmsne_vx_u64m4_b16(a, b, k(h()));
}
```
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #3 from Li Pan --- Reproduced from my side too.
[Bug target/111937] offloading from x86_64-linux-gnu to riscv*-linux-gnu will have issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-09 Status|RESOLVED|NEW Resolution|DUPLICATE |--- Summary|[RISCV][lto][offload] When |offloading from |`NUM_POLY_INT_COEFFS` > 1, |x86_64-linux-gnu to |the `poly_xxx` made|riscv*-linux-gnu will have |`lto_input_mode_table` |issues |unable to parse binary | |gimple data.| --- Comment #7 from Andrew Pinski --- Actually this is the opposite way as PR 96265. Confirmed.
[Bug ipa/96265] offloading to nvptx-none from aarch64-linux-gnu (and riscv*-linux-gnu) does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96265 --- Comment #6 from Andrew Pinski --- *** Bug 111937 has been marked as a duplicate of this bug. ***
[Bug target/111937] [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 96265 ***
[Bug ipa/96265] offloading to nvptx-none from aarch64-linux-gnu (and riscv*-linux-gnu) does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96265 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-09 Component|target |ipa Ever confirmed|0 |1 Keywords||ice-on-valid-code, lto, ||openacc, openmp Summary|building nvptx-none on |offloading to nvptx-none |aarch64-linux-gnu |from aarch64-linux-gnu (and ||riscv*-linux-gnu) does not ||work --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug modula2/114648] compiler by default does not handle C pre-processor file and line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648 --- Comment #3 from Gaius Mulley --- it will handle both, implemented in: gcc/m2/m2.flex:171 but the default was inverted during a recent bugfix. The particular test code example which provoked the bug was: # 2 "AdvParse.bnf" IMPLEMENTATION MODULE AdvParse ;
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > While you are at it, it would be useful to add a link to the rust langauge > specification (like there is for almost all other languages [I see > objective-C is not listed]) to https://gcc.gnu.org/readings.html . Also it would be useful to update https://gcc.gnu.org/frontends.html too.
[Bug c++/97710] diagnostic for invalid pointer-to-member (not function) as template argument with base to derived should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW Keywords||diagnostic Severity|normal |enhancement Summary|Help with breaking change? |diagnostic for invalid |cast pointer-to-member |pointer-to-member (not |address in template |function) as template |parameter list |argument with base to ||derived should be improved --- Comment #7 from Andrew Pinski --- Note EDG, GCC and clang all agree this is invalid C++98 - C++14. GCC rejects it (when corrected the types to be all char) for C++17+ though (that is recorded as PR 114620). I am not going to mark this as a dup of bug 114620 (because I recorded that) but instead going to mark this as the diagnostic needing to be improved.
[Bug c++/114620] Pointer-to-member template argument which is the member of a base class is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114620
--- Comment #2 from Andrew Pinski ---
This also should be valid for C++17 +:
```
template struct T{};
struct A{char x;};
struct B:A{ };
struct C:A{ T y; };
```
Note the constexpr case is only valid for C++17 + too.
[Bug c++/114620] Pointer-to-member template argument which is the member of a base class is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114620 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-09 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- The first one is rejected by EDG, clang, GCC and MSVC for similar reasons. MSVC: (13): error C2440: 'specialization': cannot convert from 'int Base::* ' to 'int Derived::* ' (13): note: Standard conversion from pointer-to-member of base to pointer-to-member of derived is not applied for template arguments But the constexpr version is definitely a GCC bug as it is accepted by all 3 other compilers.
[Bug web/114650] New: CodeView debug information format documentation should be linked from https://gcc.gnu.org/readings.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114650 Bug ID: 114650 Summary: CodeView debug information format documentation should be linked from https://gcc.gnu.org/readings.html Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Like PR 114649 but this time for the codeview debug information specifications.
[Bug modula2/114648] compiler by default does not handle C pre-processor file and line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid --- Comment #2 from Andrew Pinski --- Which ones are we talking about, the GNU extension `# LINE "FILE" ...` or the `#line LINE "FILE"` version? Or both?
[Bug web/114649] New: Would be useful to link to CTF and BTF debug information specifications from https://gcc.gnu.org/readings.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114649 Bug ID: 114649 Summary: Would be useful to link to CTF and BTF debug information specifications from https://gcc.gnu.org/readings.html Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: btf-debug, ctf-debug, documentation Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- While I noticed that rust langauge readings where not listed from readings. I also noticed that the information on BTF and CTF debug information was not linked from there. Dwarf is linked already.
[Bug modula2/114648] compiler by default does not handle C pre-processor file and line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-09 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Gaius Mulley --- Confirmed.
[Bug modula2/114648] New: compiler by default does not handle C pre-processor file and line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648 Bug ID: 114648 Summary: compiler by default does not handle C pre-processor file and line directives 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: --- The compiler currently rejects C preprocessor file and line directives which is a mismatch from the description in the documentation.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 --- Comment #5 from Andrew Pinski --- (In reply to Pierre-Emmanuel Patry from comment #2) > I can see the problem with the message, but I don't think we can remove the > behavior as we have to match rustc's behavior. The compiler has to ICE when > meeting this identifier. I suggest changing the message to rustc's one "It > looks like you're trying to break rust; would you like some ICE?" and > removing the "gcc" identifier check. Really this sounds like a bad idea to copy 100% of what rustc does. Instead we should follow the rust language specification (hopefully that actually exists). While you are at it, it would be useful to add a link to the rust langauge specification (like there is for almost all other languages [I see objective-C is not listed]) to https://gcc.gnu.org/readings.html .
[Bug testsuite/114642] new test case gcc.dg/debug/btf/btf-datasec-3.c from r14-6195-gb8cf266f4ca4ff fails for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642 Andrew Pinski changed: What|Removed |Added Target|powerpc64-linux-gnu |powerpc-linux-gnu mips*-*-* ||riscv*-*-* See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112849 Keywords||testsuite-fail Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-09 --- Comment #1 from Andrew Pinski --- Confirmed. This does seem like a testsuite issue. With `-G0` (which disables small data opt) the testcases passes. So I suspect this will also fail on mips*-*-* too. It also fails for riscv*-*-* (where the option to disable small data is -msmall-data-limit=0).
[Bug libgcc/65281] Lots of macros using non-reserved names in gthr headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65281 --- Comment #3 from Andrew Pinski --- Actually HIDE_EXPORTS has been handled as _GLIBCXX_HIDE_EXPORTS for a long time now. And UNUSED has also been handled as _GLIBCXX_UNUSED too for a long time (since 2001). This is all handled by the code in libstdc++/include/Makefile.in which does the renaming there. I don't see any references in libstdc++ usage where it places a macro in non-implementation space.
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added CC||punitb20 at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 109540 has been marked as a duplicate of this bug. ***
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #14 from Andrew Pinski --- Dup of bug 78017 for new enough glibc (which is all of ones that support time64_t IIRC). *** This bug has been marked as a duplicate of bug 78017 ***
[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 --- Comment #16 from Andrew Pinski --- (In reply to Andrew Pinski from comment #15) > (In reply to H.J. Lu from comment #14) > > This issue is about how libgcc is used by libgfortran, not libgcc itself. > > libgcc needs to be fixed too. NOT just libgfortran. > > If you are going to change libgfortran, you might as well fix libgcc since > libgfortran, libobjc and even ada libraries all need the same fix so why NOT > fix it in libgcc instead. All of the libraries that use gthr* need to be > fixed not just libgfortran. > > *** This bug has been marked as a duplicate of bug 87189 *** So will libphobos and libvtv. So fixing it once and for all in libgcc is much better than fixing all other libraries.
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #13 from Andrew Pinski --- *** Bug 114646 has been marked as a duplicate of this bug. ***
[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #15 from Andrew Pinski --- (In reply to H.J. Lu from comment #14) > This issue is about how libgcc is used by libgfortran, not libgcc itself. libgcc needs to be fixed too. NOT just libgfortran. If you are going to change libgfortran, you might as well fix libgcc since libgfortran, libobjc and even ada libraries all need the same fix so why NOT fix it in libgcc instead. All of the libraries that use gthr* need to be fixed not just libgfortran. *** This bug has been marked as a duplicate of bug 87189 ***
[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 H.J. Lu changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #14 from H.J. Lu --- This issue is about how libgcc is used by libgfortran, not libgcc itself.
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868 --- Comment #11 from Peter Bergner --- (In reply to Sam James from comment #10) > No problems reported yet and we have several people testing on ppc w/ gcc 14. Thanks for the testing! This is clearly a stage1 patch, so we'll wait until then before submitting it.
[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 --- Comment #13 from Andrew Pinski --- (In reply to Bruno Haible from comment #11) > (In reply to Andrew Pinski from comment #9) > > Dup. > > > > *** This bug has been marked as a duplicate of bug 87189 *** > > This makes no sense to me: > - I verified that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 is > fixed; therefore it ought to be marked as RESOLVED FIXED. > - Whereas H.J. is seeing this bug here with GCC 13 and glibc 2.38. > Therefore they cannot be duplicates of each other. It is all the same issue. Just half of it was fixed in glibc, which is why PR 87189 seems to have been fixed but the gcc side was not fixed.
[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Andrew Pinski --- (In reply to Bruno Haible from comment #11) > (In reply to Andrew Pinski from comment #9) > > Dup. > > > > *** This bug has been marked as a duplicate of bug 87189 *** > > This makes no sense to me: > - I verified that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 is > fixed; therefore it ought to be marked as RESOLVED FIXED. > - Whereas H.J. is seeing this bug here with GCC 13 and glibc 2.38. > Therefore they cannot be duplicates of each other. Yes it is all the same issue. *** This bug has been marked as a duplicate of bug 78017 ***
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 114646 has been marked as a duplicate of this bug. ***
[Bug libfortran/114646] libgfortran still doesn't define GTHREAD_USE_WEAK to 0 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 H.J. Lu changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW Ever confirmed|0 |1 Component|libgcc |libfortran Summary|libgcc's gthr.h still |libgfortran still doesn't |defines GTHREAD_USE_WEAK to |define GTHREAD_USE_WEAK to |1 for newer glibc |0 for newer glibc
[Bug tree-optimization/114647] missing DSE when looping over a VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114647
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-04-08
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
GCC also does not delete allocated memory when used in loop:
```
void foo(int n)
{
{
int *a = __builtin_malloc(n*sizeof(int));
for (int i=0;i
[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #11 from Bruno Haible --- (In reply to Andrew Pinski from comment #9) > Dup. > > *** This bug has been marked as a duplicate of bug 87189 *** This makes no sense to me: - I verified that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 is fixed; therefore it ought to be marked as RESOLVED FIXED. - Whereas H.J. is seeing this bug here with GCC 13 and glibc 2.38. Therefore they cannot be duplicates of each other.
[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 --- Comment #10 from H.J. Lu --- Created attachment 57906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57906=edit A patch I am testing this.
[Bug tree-optimization/114647] missing DSE when looping over a VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114647 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement Component|middle-end |tree-optimization Summary|missing DCE when looping|missing DSE when looping |over a VLA |over a VLA
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #7 from Andrew Pinski --- *** Bug 87189 has been marked as a duplicate of this bug. ***
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #12 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 78017 ***
[Bug middle-end/114647] New: missing DCE when looping over a VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114647
Bug ID: 114647
Summary: missing DCE when looping over a VLA
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: franckbehaghel_gcc at protonmail dot com
Target Milestone: ---
$cat foo.cpp
#include "stdint.h"
#include "stdio.h"
void foo(int n)
{
uint64_t a[n];
for (uint32_t i=0;i
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 Andrew Pinski changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 114646 has been marked as a duplicate of this bug. ***
[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 87189 ***
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #10 from Bruno Haible --- It is fixed in - glibc 2.35 + gcc 11.4 (verified on Ubuntu 22.04), - glibc 2.39 + gcc 13.2.1 (verified on Arch Linux 2024.04).
[Bug ipa/114643] [11/12/13/14 Regression] Call to a template function emitted but without the code for the template function itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67650, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80916 Known to fail||8.1.0 Summary|Call to a template function |[11/12/13/14 Regression] |emitted but without the |Call to a template function |code for the template |emitted but without the |function itself |code for the template ||function itself Target Milestone|--- |11.5 Known to work||7.5.0 Depends on|62051, 93115| --- Comment #4 from Andrew Pinski --- Actually it more closely related to PR 67650 (and PR 80916) but both of those were fixed. Looks like even though the function is not static, we are thinking we can still refer to it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 [Bug 62051] [11/12/13/14 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115 [Bug 93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
[Bug ipa/114643] Call to a template function emitted but without the code for the template function itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643 Andrew Pinski changed: What|Removed |Added Depends on||93115 --- Comment #3 from Andrew Pinski --- Maybe PR 93115 . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115 [Bug 93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
[Bug target/114615] spurious warning on mingw-w64: 'memcpy' reading 4 or more bytes from a region of size 2 with std::wstring{L""} and -flto -O1 [Wstringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615 --- Comment #4 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #3) > The dumb part is that __n here comes from wcslen(__s2), so the compiler is > able to track that __s2 is only two bytes, but not capable of tracking that > __n == 0. > > Specifically, __n is (__s2 + wcslen(__s2)) - __s2 which is just wcslen(L"") > which is 0. I dont think we fold/track wide_t builtins at all ...
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #7 from Hristo Venev --- I was actually trying to fix a bug in an existing application that I didn't write that is using std::chrono::current_zone() under the assumption that it returns some good approximation of what should be considered the "local" time zone. I guess I need to open a bug with the application. Still, as I said previously, the other time zone libraries I checked attempt to handle $TZ.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jonathan Wakely --- (In reply to Hristo Venev from comment #4) > Therefore current_zone() as currently implemented is worse than useless -- > it is a footgun. So don't use it then. > The people who wrote the standard probably did not consider how various > platforms handle default time zones this at all. That's a pretty bug assumption, and wrong. > I don't understand why you consider the ability to override the default time > zone using an environment variable to be a flaw. For one, the environment is mutable and not threadsafe. Anyway, this isn't going to change just because you don't like it.
[Bug c++/114638] Hang and Memory Consumption Increase during Compilation with many object creation of itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-08
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to fail||4.1.2
--- Comment #3 from Andrew Pinski ---
the problem seems related to tentative parsing. But I will note clang does give
an error quickly.
Reduced C++98 testcase:
```
struct Z
{
Z ();
Z (Z const &);
};
Z t = Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z ( Z
(Z (Z (Z ()));
```
GCC did get worse over time though. Add one more `Z(` and it fails. There is
definitely some O(n^2) issue going on. Most likely trying to figure out if this
is a function declaration vs a function call vs an object creation ...
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #5 from Jonathan Wakely --- The libc time zone doesn't necessarily correspond to anything in the IANA database anyway. If you use a POSIX time zone definition like TZ="abc4abd" then libc will use that to generate a custom time zone and use that for localtime, ctime etc. That's not compatible with the std::chrono model, which uses the IANA zones. So "the time zone libc would consider local" might not be a real time zone anyway. If you want to interpret $TZ then you can write code to do so, and convert that into a name that std::chrono::locale_zone understands. So if TZ is an IANA name, use it directly, otherwise extract the offset part and then use something like "Etc/GMT-8".
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #4 from Hristo Venev --- > What does "quite a bit completely useless" mean? current_zone() tells you > what /etc/localtime is set to. So it's as useless as /etc/localtime, no more > and no less. What I mean is that in its current state current_zone() is a partial (and incorrect) reimplementation of the logic used by various libcs to determine the local time zone. By not being an accurate enough implementation it is useless. Given that this partial implementation is correct in some but not all cases, it is possible that application bugs (e.g. considering that current_zone() is equivalent to libc local time) would go unnoticed, so any use of current_zone() is most likely a bug. In addition to glibc and musl, various other libraries for working with time zones in other languages honor $TZ, for example python's `dateutil` and rust's `chrono`. Therefore current_zone() as currently implemented is worse than useless -- it is a footgun. > Did you read the messages I linked to? Yes. Here are my answers to the points raised in the messages: > No, this is not a good idea. Libstdc++ cannot inspect the environment safely because another thread could be changing it concurrently, which would lead to undefined behaviour. The commented out code was an attempt to support on AIX which is unconventional and has no /etc/localtime symlink. These are just excuses. > In any case, the C++ standard requires that current_zone() refers to the computer's zone, not just the current process' TZ setting: > > "A pointer to the time zone which the computer has set as its local time zone." The people who wrote the standard probably did not consider how various platforms handle default time zones this at all. > is not . The chrono lib is not restricted to only working with a global time zone defined in the standard library, but instead everything works equally well with any chrono::time_zone object, whether that refers to the system zone or not. If you want to use a per-process zone specified by $TZ then you can easily do so, using something like: This is unrelated to the issue. Having current_zone() return the time zone the user actually wants to use wouldn't magically take away the ability to use other time zones. Having to reimplement libc logic in every application is not great. > In general, yes, but not here. That would be a glibc-specific feature, so not portable to other targets libstdc++ supports. And in any case, I don't think we want to depend on $TZ. That's not the intended design of the std::chrono API. Interesting point. Is that related to the C++ standard text mentioned in the other message? > Yes, and that's a flaw of , but not a problem with . I don't understand why you consider the ability to override the default time zone using an environment variable to be a flaw. > A C++ program can use **any number** of different time zones. Again, having sane default behavior from current_zone() wouldn't magically prevent other time zones from being used. > There is no > preference given in the API to any particular time zone, unlike the libc > which depends on global state for "the time zone" (singular). The > only time zone that has special treatment in the C++ API is UTC, which is > the default time zone used by std::chrono::zoned_time iff you don't > construct it with a pointer to a specific time zone. But even that can be > changed via chrono::zoned_traits. There **is** a special preference given to the time zone returned by current_zone() -- it is the time zone returned by current_zone(), and most applications using the C++20 time zone library would consider it to be the default "local" time zone.
[Bug analyzer/94365] false positive leak when using container_of-like constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94365 --- Comment #3 from David Malcolm --- (In reply to David Malcolm from comment #2) > Testing again with trunk (for GCC 12); the false leak of ‘a’ report still > occurs, but the -Wanalyzer-free-of-non-heap report is fixed. False leak still present with trunk (for GCC 14): https://godbolt.org/z/nzjaMG7c8
[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 Dan Raviv changed: What|Removed |Added CC||dan.raviv at gmail dot com --- Comment #8 from Dan Raviv --- +1, agreed too aggressive. Clang provides https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow-field-in-constructor
[Bug fortran/114626] Very long time for compilation the attached program, depends on value of a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114626 --- Comment #3 from anlauf at gcc dot gnu.org --- Another option is to not declare max_sum as parameter but as variable. With integer :: max_sum = 2 * max_ij ** 3 the code compiles almost instantly, but it has noticeable runtime. (But it performs much better here than with Intel... :)
[Bug c++/114638] Hang and Memory Consumption Increase during Compilation with many object creation of itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638 Andrew Pinski changed: What|Removed |Added Summary|Hang and Memory Consumption |Hang and Memory Consumption |Increase during Compilation |Increase during Compilation |with Recursive Template |with many object creation |Instantiation |of itself --- Comment #2 from Andrew Pinski --- This has nothing to do with template but rather
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #3 from Jonathan Wakely --- What does "quite a bit completely useless" mean? current_zone() tells you what /etc/localtime is set to. So it's as useless as /etc/localtime, no more and no less. Did you read the messages I linked to?
[Bug rtl-optimization/112560] [14 Regression] ICE in try_combine on pr112494.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560 --- Comment #7 from GCC Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:eaccdba315b86d374a4e72b9dd8fefb0fc3cc5ee commit r14-9847-geaccdba315b86d374a4e72b9dd8fefb0fc3cc5ee Author: Uros Bizjak Date: Mon Apr 8 20:54:30 2024 +0200 combine: Fix ICE in try_combine on pr112494.c [PR112560] The compiler, configured with --enable-checking=yes,rtl,extra ICEs with: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in try_combine, at combine.cc:3237 This is 3236 /* Just replace the CC reg with a new mode. */ 3237 SUBST (XEXP (*cc_use_loc, 0), newpat_dest); 3238 undobuf.other_insn = cc_use_insn; in combine.cc, where *cc_use_loc is (unspec:DI [ (reg:CC 17 flags) ] UNSPEC_PUSHFL) combine assumes CC must be used inside of a comparison and uses XEXP (..., 0) without checking on the RTX type of the argument. Replace cc_use_loc with the entire new RTX only in case cc_use_loc satisfies COMPARISON_P predicate. Otherwise scan the entire cc_use_loc RTX for CC reg to be updated with a new mode. PR rtl-optimization/112560 gcc/ChangeLog: * combine.cc (try_combine): Replace cc_use_loc with the entire new RTX only in case cc_use_loc satisfies COMPARISON_P predicate. Otherwise scan the entire cc_use_loc RTX for CC reg to be updated with a new mode. * config/i386/i386.md (@pushf2): Allow all CC modes for operand 1.
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #2 from Hristo Venev --- That makes current_zone() quite a bit completely useless and means that practically every use of current_zone() is most likely a bug. Is there some way to get the timezone libc would consider local?
[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 --- Comment #8 from Florian Weimer --- (In reply to Andrew Pinski from comment #6) > What was done for libstdc++ was only specific to libstdc++ even though it > uses the same headers, it was not changed for the generic libgcc code which > is used in other places including but not limited to the unwinder, and > libobjc. now the question comes to do we want to bring in pthread_ functions > always with the unwinder? I don't know ... For glibc, most of these functions are included in minimal static executables anyway. At least today, the difference is not going to be large, if it exists at all. In the future, minimal static executables may have a smaller footprint, but even then, these functions are pretty small. The concern is probably more in the opposite direction, that pthread_once pulls in the unwinder …
[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 --- Comment #7 from H.J. Lu --- r12-5108 commit 80fe172ba9820199c2bbce5d0611ffca27823049 Author: Jonathan Wakely Date: Tue Nov 9 23:45:36 2021 + libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133] Since Glibc 2.34 all pthreads symbols are defined directly in libc not libpthread, and since Glibc 2.32 we have used __libc_single_threaded to avoid unnecessary locking in single-threaded programs. This means there is no reason to avoid linking to libpthread now, and so no reason to use weak symbols defined in gthr-posix.h for all the pthread_xxx functions. libstdc++-v3/ChangeLog: PR libstdc++/100748 PR libstdc++/103133 * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK): Define for glibc 2.34 and later. fixed static C++ pthread programs. libgfortran neeeds a similar fix.
[Bug libgomp/39176] -static and -fopenmp and io causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176 --- Comment #13 from Andrew Pinski --- (In reply to H.J. Lu from comment #11) > fixed static C++ pthread programs. libgfortran neeeds a similar fix. libgcc needs the fix instead. Maybe libgomp, maybe libobjc. But this is tracked in the other bug.
[Bug libgomp/39176] -static and -fopenmp and io causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #12 from Andrew Pinski --- This version was invalid, see the other bug.
[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646 Andrew Pinski changed: What|Removed |Added Component|libfortran |libgcc --- Comment #6 from Andrew Pinski --- What was done for libstdc++ was only specific to libstdc++ even though it uses the same headers, it was not changed for the generic libgcc code which is used in other places including but not limited to the unwinder, and libobjc. now the question comes to do we want to bring in pthread_ functions always with the unwinder? I don't know ...
