[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Patrick O'Neill changed: What|Removed |Added Attachment #57640|0 |1 is obsolete|| --- Comment #4 from Patrick O'Neill --- Created attachment 57642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57642=edit Raw testcase and headers Thanks for catching that, here's the zip file with actual files in it this time ;)
[Bug tree-optimization/114009] [11/12/13/14 Regression] Missed optimization: (!a) * a => 0 when a=(a/2)*2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:95b6ee96348041eaee9133f082b57f3e57ef0b11
commit r14-9350-g95b6ee96348041eaee9133f082b57f3e57ef0b11
Author: Jakub Jelinek
Date: Thu Mar 7 08:43:16 2024 +0100
match.pd: Optimize a * !a to 0 [PR114009]
The following patch attempts to fix an optimization regression through
adding a simple simplification. We already have the
/* (m1 CMP m2) * d -> (m1 CMP m2) ? d : 0 */
(if (!canonicalize_math_p ())
(for cmp (tcc_comparison)
(simplify
(mult:c (convert (cmp@0 @1 @2)) @3)
(if (INTEGRAL_TYPE_P (type)
&& INTEGRAL_TYPE_P (TREE_TYPE (@0)))
(cond @0 @3 { build_zero_cst (type); })))
optimization which otherwise triggers during the a * !a multiplication,
but that is done only late and we aren't able through range assumptions
optimize it yet anyway.
The patch adds a specific simplification for it.
If a is zero, then a * !a will be 0 * 1 (or for signed 1-bit 0 * -1)
and so 0.
If a is non-zero, then a * !a will be a * 0 and so again 0.
THe pattern is valid for scalar integers, complex integers and vector
types,
but I think will actually trigger only for the scalar integers. For
vector types I've added other two with VEC_COND_EXPR in it, for complex
there are different GENERIC trees to match and it is something that likely
would be never matched in GIMPLE, so I didn't handle that.
2024-03-07 Jakub Jelinek
PR tree-optimization/114009
* genmatch.cc (decision_tree::gen): Emit ARG_UNUSED for captures
argument even for GENERIC, not just for GIMPLE.
* match.pd (a * !a -> 0): New simplifications.
* gcc.dg/tree-ssa/pr114009.c: New test.
[Bug target/114252] Introducing bswapsi reduces code performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252 --- Comment #7 from Richard Biener --- Note I do understand what you are saying, just the middle-end in detecting and using __builtin_bswap32 does what it does everywhere else - it checks whether the target implements the operation. The middle-end doesn't try to actually compare costs (it has no idea of the bswapsi costs), and it most definitely doesn't see how AVR is special in having only QImode registers and thus the created SImode load (which the target supports!) will end up as four registers. To me a 'bswap' on AVR never makes sense since whatever is swapped will be _always_ available as a set of byte registers. That's why I question AVR exposing bswapsi to the middle-end rather than suggesting the middle-end should maybe see whether AVR has any regs of HImode or larger. Note that would break for targets that could eventually do a load-multiple byteswapped to a set of QImode regs (guess there's no such one in GCC at least), but it's the only heuristic that might work here. The only thing that maybe would make sense with AVR exposing bswapsi is users calling __builtin_bswap but since it always expands as a libcall even that makes no sense. So my preferred fix would be to remove bswapsi from avr.md? Does it benefit from recognizing bswap done with shifts on an int?
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 --- Comment #10 from rguenther at suse dot de --- On Wed, 6 Mar 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||rguenth at gcc dot gnu.org > > --- Comment #7 from Jakub Jelinek --- > The second UB is on > #2 ao_ref_init_from_vn_reference (ref=, set=1, base_set=1, > type=, ops=...) at ../../gcc/tree-ssa-sccvn.cc:1224 > 1224offset += op->off << LOG2_BITS_PER_UNIT; > where op->off is negative. > Isn't this just an unnecessary optimization? I mean can't we just do > offset += op->off * BITS_PER_UNIT; > BITS_PER_UNIT is a constant 8 on all targets we support... It's a habit from dealing with offset_int (but this is poly_int64) where the multiply is possibly a lot more costly than a shift. So yeah, a multiply is fine I guess.
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #3 from Alexander Monakov --- The first attachment is empty (perhaps you made a non-recursive archive when you meant to recursively zip a directory).
[Bug middle-end/111523] Unexpected performance regression with -ftrivial-auto-var-init=zero for e.g. systemctl unmask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #9 from Andrew Pinski --- Turns out systemd had a 1MB buffer in their serializer formating code (serialize_item_format) that would be executed a lot and -ftrivial-auto-var-init=zero would cause this buffer to be zero'd each time the function was called (a decent thing for this flag to do). It just happens serialize_item_format is called a lot when it came serialization. With arm memory systems being slower than most, it just exposed this issue. Anways systemd has now changed the buffer to 256 which is much much smaller and for most calls enough in size before needing to reallocate the buffer that it has now become fast. Anyways -ftrivial-auto-var-init=zero just exposed a performance (stack size) issue with already existing issue inside the systemd code. A good thing really. So closing as moved.
[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195 --- Comment #2 from Li Pan --- Trigger below assert in vectorizable_store, the loop_vinfo use_partial, fully_masked and fully_lens are all true here. /* Shouldn't go with length-based approach if fully masked. */ gcc_assert (!loop_lens || !loop_masks); Introduce by this commit https://github.com/gcc-mirror/gcc/commit/9fb832ce382d649b7687426e6bc4e5d3715cb78a#diff-97f675a4f401d6ec84d031e0d7259a0b6ba3b50eccc3fe483e9376becc9d9cf9
[Bug target/114200] [14] RISC-V fixed-length vector miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114200 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug ipa/114263] LTO generating incorrect code with -O2 -std=c++20 -fno-strict-aliasing flags in GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263 --- Comment #2 from Andrew Pinski --- the testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359#c15 makes it even more likely the same as this one.
[Bug ipa/114263] LTO generating incorrect code with -O2 -std=c++20 -fno-strict-aliasing flags in GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263
--- Comment #1 from Andrew Pinski ---
This sounds almost the same as what is mentioned in PR 113359 ("is changed by
SRA to only store 64 + 32 bits into the std::pair rather than 64 + 64 bits.").
[Bug lto/114263] New: LTO generating incorrect code with -O2 -std=c++20 -fno-strict-aliasing flags in GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263
Bug ID: 114263
Summary: LTO generating incorrect code with -O2 -std=c++20
-fno-strict-aliasing flags in GCC13
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: obaines at nvidia dot com
Target Milestone: ---
I have a minimized test case where LTO seems to be generating incorrect code.
### Sources ###
A.cpp
```
#include
#include
struct A {
A(uint64_t _x, uint8_t _y) : x(_x), y(_y) {}
uint64_t x;
uint8_t y;
};
void doA() {
std::vector v;
v.emplace_back(0xULL, 0x2);
v.emplace_back(0xULL, 0x4);
}
```
B.cpp
```
#include
#include
#include
struct B {
B(uint64_t _x, uint64_t _y) : x(_x), y(_y) {}
uint64_t x;
uint64_t y;
};
void doB() {
std::vector v;
v.emplace_back(0xULL, 0xULL);
v.emplace_back(0xULL, 0xULL);
std::cout << std::hex << "expected: " << 0xULL << " actual:
" << v[0].y << std::endl;
}
```
AB.cpp
```
void doA();
void doB();
int main() {
doA();
doB();
}
```
### Build Command ###
g++ -flto -g -O2 -std=c++20 -fno-strict-aliasing -Wall -Wextra -c *.cpp
g++ -flto -g -O2 -std=c++20 -fno-strict-aliasing -Wall -Wextra *.o
### Notes ###
The code doesn't generate any warnings during compilation.
The output of the program is usually `expected: actual:
`, but with these optimization flags the output is `expected:
actual: 66`. The bug won't reproduce if I specify C++ standard
before C++20, or if I don't disable strict-aliasing optimization.
Changing the size of A::y affects the number of bytes that are correctly copied
in the output. The bug reproduces in gcc 13.2.0 and from the latest
releases/gcc-13 branch (g++ (GCC) 13.2.1 20240306), but does not reproduce in
gcc-12.3.0 or with the latest trunk branch (g++ (GCC) 14.0.1 20240306
(experimental)).
So, as far as I can tell the bug is exclusive to GCC13.
[Bug tree-optimization/114238] [14 regression] Multiple 554.roms_r run-time regressions (4%-20%) since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238 Andrew Pinski changed: What|Removed |Added Summary|Multiple 554.roms_r |[14 regression] Multiple |run-time regressions|554.roms_r run-time |(4%-20%) since |regressions (4%-20%) since |r14-9193-ga0b1798042d033|r14-9193-ga0b1798042d033 Target Milestone|--- |14.0
[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96645 --- Comment #8 from Andrew Pinski --- Seems related to PR 96645 (and CWG2335).
[Bug libfortran/105456] Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 --- Comment #7 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:03932d3203bce244edd812b81921c2f16ea18d86 commit r14-9348-g03932d3203bce244edd812b81921c2f16ea18d86 Author: Jerry DeLisle Date: Wed Mar 6 19:46:04 2024 -0800 Fortran: Fix issue with using snprintf function. The previous patch used snprintf to set the message string. The message string is not a formatted string and the snprintf will interpret '%' related characters as format specifiers when there are no associated output variables. A segfault ensues. This change replaces snprintf with a fortran string copy function and null terminates the message string. PR libfortran/105456 libgfortran/ChangeLog: * io/list_read.c (list_formatted_read_scalar): Use fstrcpy from libgfortran/runtime/string.c to replace snprintf. (nml_read_obj): Likewise. * io/transfer.c (unformatted_read): Likewise. (unformatted_write): Likewise. (formatted_transfer_scalar_read): Likewise. (formatted_transfer_scalar_write): Likewise. * io/write.c (list_formatted_write_scalar): Likewise. (nml_write_obj): Likewise. gcc/testsuite/ChangeLog: * gfortran.dg/pr105456.f90: Revise using '%' characters in users error message.
[Bug tree-optimization/114246] [11/12/13 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246 Andrew Pinski changed: What|Removed |Added Keywords|ice-checking| --- Comment #6 from Andrew Pinski --- Note even without checking there is an ICE that happens during FRE with the invalid IR. (so removing the ice-checking marker).
[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 --- Comment #5 from Andrew Pinski --- (In reply to LIU Hao from comment #4) > The only difference between the C99 `extern inline` and C++ `extern inline` > is that the C++ external definition is COMDAT. Well not really. comdat changes heurstics here though. The reason being C++ inline functions are most likely smaller and should really be inlined. This is all heurstics of inlining and figuring out locally in the TU that it might not be called in another TU or not. Note GCC has not retuned its -Os heurstics for a long time because it has been decent enough for most folks and corner cases like this is almost never come up.
[Bug tree-optimization/114253] False positive maybe-uninitialized with std::optional and ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #5 from Andrew Pinski --- ``` [local count: 1073741824]: # pid_16 = PHI # pid$4_26 = PHI kill_pid (0); goto ; [100.00%] [count: 0]: : goto ; [100.00%] [local count: 1073741824]: _12 = VIEW_CONVERT_EXPR(pid$4_26); if (_12 != 0) goto ; [33.00%] else goto ; [67.00%] [local count: 354334800]: kill_pid (pid_16); goto ; [100.00%] ``` Funny if we turn off SRA we get: ``` [local count: 354334800]: _2 = MEM[(int &)]; kill_pid (_2); goto ; [100.00%] [count: 0]: : goto ; [100.00%] [local count: 536870912]: kill_pid (_2); [local count: 536870912]: goto ; [100.00%] ``` (note bb9/bb17 here looks to be landing pads for EH).
[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #4 from LIU Hao ---
(In reply to Andrew Pinski from comment #3)
> It looks like it has been this way since r0-37737-g4838c5ee553f06 (2001) (or
> rather that is when it was used by the tree inline; I don't want to dig
> further back to understand the RTL inliner). So looks like this is just
> missing documentation ...
It's not just about `gnu_inline`. If we switch to C++ inline we get the same
result:
(https://gcc.godbolt.org/z/ehbjqj5xh)
```
struct impl;
struct impl* get_impl(int key);
int get_value(struct impl* p);
extern inline
int get_value_by_key(int key)
{
struct impl* p = get_impl(key);
if(!p)
return -1;
return get_value(p);
}
int real_get_value_by_key(int key)
{
return get_value_by_key(key);
}
```
GCC outputs:
```
real_get_value_by_key(int):
pushrsi
callget_impl(int)
testrax, rax
je .L2
mov rdi, rax
pop rcx
jmp get_value(impl*)
.L2:
or eax, -1
pop rdx
ret
```
If we switched to C99 `extern inline` then it would produce desired result:
```
get_value_by_key:
pushrsi
callget_impl
testrax, rax
je .L2
mov rdi, rax
pop rcx
jmp get_value
.L2:
or eax, -1
pop rdx
ret
real_get_value_by_key:
jmp get_value_by_key
``
The only difference between the C99 `extern inline` and C++ `extern inline` is
that the C++ external definition is COMDAT.
[Bug tree-optimization/114253] False positive maybe-uninitialized with std::optional and ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253 --- Comment #4 from Andrew Pinski --- VIEW_CONVERT_EXPR(pid$4_26) Where I have seen this before ...
[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #3 from Andrew Pinski ---
The C++ front-end does:
/* Handle gnu_inline attribute. */
if (GNU_INLINE_P (decl1))
{
DECL_EXTERNAL (decl1) = 1;
DECL_NOT_REALLY_EXTERN (decl1) = 0;
DECL_INTERFACE_KNOWN (decl1) = 1;
DECL_DISREGARD_INLINE_LIMITS (decl1) = 1;
}
C front-end does:
/* For GNU C extern inline functions disregard inline limits. */
if (DECL_EXTERNAL (fndecl)
&& DECL_DECLARED_INLINE_P (fndecl)
&& (flag_gnu89_inline
|| lookup_attribute ("gnu_inline", DECL_ATTRIBUTES (fndecl
DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1;
This specifically from r0-82849-gc536a6a77a19a8 but it was done different
before that (using a language hook).
https://gcc.gnu.org/pipermail/gcc-patches/2007-July/221806.html
https://gcc.gnu.org/pipermail/gcc-patches/2007-August/223406.html
It looks like it has been this way since r0-37737-g4838c5ee553f06 (2001) (or
rather that is when it was used by the tree inline; I don't want to dig further
back to understand the RTL inliner). So looks like this is just missing
documentation ...
[Bug ipa/114262] Over-inlining when optimizing for size with gnu_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 --- Comment #2 from LIU Hao --- (In reply to Andrew Pinski from comment #1) > I thought it was documented that gnu_inline also causes always_inline if > optimization is turned on but I can't seem to find that ... Is that the case in GCC source? I think I would have to find a workaround for it.
[Bug tree-optimization/114262] Over-inlining when optimizing for size?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262 --- Comment #1 from Andrew Pinski --- I thought it was documented that gnu_inline also causes always_inline if optimization is turned on but I can't seem to find that ...
[Bug tree-optimization/114262] New: Over-inlining when optimizing for size?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
Bug ID: 114262
Summary: Over-inlining when optimizing for size?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
(https://gcc.godbolt.org/z/a4ox6oEfT)
```
struct impl;
struct impl* get_impl(int key);
int get_value(struct impl* p);
extern __inline__ __attribute__((__gnu_inline__))
int get_value_by_key(int key)
{
struct impl* p = get_impl(key);
if(!p)
return -1;
return get_value(p);
}
int real_get_value_by_key(int key)
{
return get_value_by_key(key);
}
```
This is actually two functions, one is `gnu_inline` and the other is a
non-inline one. It looks to me that if I mark a function `gnu_inline`, I assert
that 'somewhere I shall provide an external definition for you' so when
optimizing for size, GCC may generate a call instead of using the more complex
inline definition.
The `real_get_value_by_key` function is made a deliberate sibling call, so
ideally this should be
```
real_get_value_by_key:
jmp get_value_by_key
```
and not
```
real_get_value_by_key:
pushrsi
callget_impl
testrax, rax
je .L2
mov rdi, rax
pop rcx
jmp get_value
.L2:
or eax, -1
pop rdx
ret
```
It still gets inlined with `-finline-limit=0` and can only be disabled by
`-fno-inline`. I have no idea how it is controlled.
---
# Trivia
These are two `gnu_inline` functions from the same library. Most of the time
they should both be inlined in user code. However, external definitions are
required when optimization is not turned on, or when their addresses are taken,
so they must still exist. As they are unlikely to be used anyway, optimizing
for size makes much more sense.
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #2 from Patrick O'Neill --- Created attachment 57641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57641=edit unreduced preprocessed testcase
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3 CC||amonakov at gcc dot gnu.org, ||pinskia at gcc dot gnu.org
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #1 from Patrick O'Neill --- Created attachment 57640 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57640=edit Raw testcase and headers
[Bug rtl-optimization/114261] New: [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Bug ID: 114261 Summary: [13/14 Regression] Scheduling takes excessive time (97%) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: patrick at rivosinc dot com Target Milestone: --- I recently enabled timeout detection for the risc-v fuzzer so I'm not sure how interesting this is. Seems like something weird is going on in scheduling that should be short circuited/bailed out. tip-of-tree > ./bin/riscv64-unknown-linux-gnu-gcc red.c -O1 -fschedule-insns -w > -ftime-report Time variable usr sys wall GGC phase setup: 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 2779k ( 1%) phase parsing : 0.72 ( 0%) 0.54 ( 38%) 1.35 ( 0%) 36M ( 13%) phase opt and generate : 917.85 (100%) 0.89 ( 62%) 925.29 (100%) 241M ( 86%) phase last asm : 0.07 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 343k ( 0%) garbage collection : 0.31 ( 0%) 0.01 ( 1%) 0.37 ( 0%) 0 ( 0%) dump files : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) callgraph construction : 0.06 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 8997k ( 3%) callgraph optimization : 0.02 ( 0%) 0.01 ( 1%) 0.03 ( 0%) 10k ( 0%) callgraph functions expansion : 915.19 (100%) 0.76 ( 53%) 922.36 (100%) 198M ( 71%) callgraph ipa passes : 2.45 ( 0%) 0.10 ( 7%) 2.68 ( 0%) 19M ( 7%) ipa function summary : 0.20 ( 0%) 0.00 ( 0%) 0.21 ( 0%) 5358k ( 2%) ipa dead code removal : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa inlining heuristics: 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 192 ( 0%) ipa pure const : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1080 ( 0%) ipa modref : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 4336 ( 0%) cfg construction : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 28k ( 0%) cfg cleanup: 0.08 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 2496 ( 0%) CFG verifier : 1.27 ( 0%) 0.01 ( 1%) 1.26 ( 0%) 0 ( 0%) trivially dead code: 0.11 ( 0%) 0.00 ( 0%) 0.12 ( 0%) 0 ( 0%) df scan insns : 0.20 ( 0%) 0.04 ( 3%) 0.26 ( 0%) 528 ( 0%) df reaching defs : 1.03 ( 0%) 0.03 ( 2%) 1.07 ( 0%) 0 ( 0%) df live regs : 0.75 ( 0%) 0.00 ( 0%) 0.80 ( 0%) 0 ( 0%) df live regs : 0.22 ( 0%) 0.00 ( 0%) 0.22 ( 0%) 0 ( 0%) df use-def / def-use chains: 0.00 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 ( 0%) df reg dead/unused notes : 0.66 ( 0%) 0.00 ( 0%) 0.68 ( 0%) 7041k ( 2%) register information : 0.27 ( 0%) 0.00 ( 0%) 0.28 ( 0%) 0 ( 0%) alias analysis : 0.45 ( 0%) 0.01 ( 1%) 0.45 ( 0%) 14M ( 5%) alias stmt walking : 0.38 ( 0%) 0.03 ( 2%) 0.50 ( 0%) 3192 ( 0%) register scan : 0.03 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 586k ( 0%) rebuild jump labels: 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 0 ( 0%) preprocessing : 0.08 ( 0%) 0.09 ( 6%) 0.24 ( 0%) 1861k ( 1%) lexical analysis : 0.24 ( 0%) 0.16 ( 11%) 0.30 ( 0%) 0 ( 0%) parser (global): 0.18 ( 0%) 0.12 ( 8%) 0.35 ( 0%) 10103k ( 4%) parser function body : 0.19 ( 0%) 0.17 ( 12%) 0.40 ( 0%) 24M ( 9%) inline parameters : 0.10 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 128k ( 0%) tree gimplify : 0.04 ( 0%) 0.02 ( 1%) 0.05 ( 0%) 12M ( 5%) tree eh: 0.00 ( 0%) 0.01 ( 1%) 0.00 ( 0%) 10056 ( 0%) tree CFG construction : 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 8660k ( 3%) tree CFG cleanup : 0.03 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 20k ( 0%) tree copy propagation : 0.02 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 200 ( 0%) tree PTA : 0.36 ( 0%) 0.06 ( 4%) 0.44 ( 0%) 2128k ( 1%) tree SSA other : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) tree SSA rewrite : 0.03 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 2079k ( 1%) tree SSA incremental : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 196k ( 0%) tree operand
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #5 from Jonathan Wakely --- Yup, that's what I have in my local tree now.
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #4 from Howard Hinnant --- Not positive (because I don't know your code that well), but I think: __s = round<_Duration>(__fs); will do it.
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Yup, the seconds part "00.002" is parsed using std::numpunct (in order to
Oops, std::num_get obviously.
> handle the locale's decimal point) and then converted to milliseconds using
> duration_cast:
>
> auto& __ng = use_facet>(__loc);
> long double __val;
> ios_base::iostate __err2{};
> __ng.get(__buf, {}, __buf, __err2, __val);
> if (__is_failed(__err2)) [[unlikely]]
> __err |= __err2;
> else
> {
> duration __fs(__val);
> __s = duration_cast<_Duration>(__fs);
> }
As an unrelated optimization, when the locale is "C" we could use
std::from_chars or std::stod instead of std::num_get.
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > and another duration_cast in chrono::from_stream for durations. That one > could be used with either integral or floating-point reps. Ah, but we're converting from common_type_t to Duration, so either it's float-to-float or integer-to-integer, and duration_cast is OK if we're fine with truncating.
[Bug target/114200] [14] RISC-V fixed-length vector miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114200 Patrick O'Neill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick O'Neill --- Thanks for the fix! Once the other ICEs (pr114196, pr114195) get resolved I'll be able to turn on the yarpgen fuzzer without getting overwhelmed with duplicates. The failures from the existing csmith fuzzer are getting more rare :)
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
--- Comment #1 from Jonathan Wakely ---
Yup, the seconds part "00.002" is parsed using std::numpunct (in order to
handle the locale's decimal point) and then converted to milliseconds using
duration_cast:
auto& __ng = use_facet>(__loc);
long double __val;
ios_base::iostate __err2{};
__ng.get(__buf, {}, __buf, __err2, __val);
if (__is_failed(__err2)) [[unlikely]]
__err |= __err2;
else
{
duration __fs(__val);
__s = duration_cast<_Duration>(__fs);
}
We also use duration_cast when parsing %c and %X using std::time_get, but
that's an integer conversion there (but the duration_cast should have been
qualified to prevent ADL):
__h = hours(__tm.tm_hour);
__min = minutes(__tm.tm_min);
__s = duration_cast<_Duration>(seconds(__tm.tm_sec));
and another duration_cast in chrono::from_stream for durations. That one could
be used with either integral or floating-point reps.
Do we want to parse "00:00:31" as minutes(1)? I don't think we do, so only the
first case where converting long double to milliseconds should be rounded?
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 --- Comment #5 from Jonathan Wakely --- >using __format::_ChronoParts; >auto __need = _ChronoParts::_Year | _ChronoParts::_Month > - | _ChronoParts::_Day | _ChronoParts::_TimeOfDay; > + | _ChronoParts::_Day; > + if constexpr (ratio_less_v) > + __need |= _ChronoParts::_TimeOfDay; This condition's not right. If we have a period of days, but a floating-point rep, we probably do want to parse and use a time if one is present in the input. "2024-03-07 00:05" can be represented by sys_time> and is not the same time as "2024-03-07". And if we have a period like ratio then it's greater than days, but not using the time of day in the result will lose accuracy. I'm leaning towards Howard's approach of just assuming 00:00:00 if no time is present, rather than making it depend on the period in any way.
[Bug c++/106851] [modules] Name conflict for exported using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851 --- Comment #6 from Jonathan Wakely --- Excellent! Thanks for the fix.
[Bug c++/106851] [modules] Name conflict for exported using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851
--- Comment #5 from Nathaniel Shead ---
(In reply to Jonathan Wakely from comment #4)
> I tried doing it this way instead
>
> namespace std {
> export using std::vector;
> namespace pmr {
> export using std::vector;
> }
> }
>
> but that didn't work, nothing got exported. But maybe that will be fixed by
> Nathaniel's https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647088.html
Yup, looks to be this issue. This is merged into trunk now and with a quick
test appears to work: https://godbolt.org/z/T5zPfPGro
[Bug libstdc++/114260] New: std::formatter> formats as the previous day
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114260
Bug ID: 114260
Summary: std::formatter> formats as the previous day
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
We give surprising output for std::formatter>:
#include
#include
#include
using namespace std::chrono;
int main(){
auto sdays = std::chrono::sys_days(2024y/March/5);
auto udays = std::chrono::utc_clock::from_sys(sdays);
std::cout << udays << '\n';
std::cout << round(udays) << '\n';
}
This prints:
2024-03-05 00:00:00
2024-03-04 23:59:33
This happens because formatter> subtracts leap seconds
to get a sys_time (and checks to see whether we need to format the seconds as
"60") and then formats that result using formatter. The
result has a higher precision than utc_time and is no longer the
"correct" day.
I think we want to use chrono::round after subtracting leap seconds, to get
back to the original resolution. Otherwise we're formatting a sys_time that
differs from the supplied utc_time by less than that time's minimum tick.
So:
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -2067,7 +2067,7 @@ namespace __format
const auto __li = chrono::get_leap_second_info(__t);
sys_time<_CDur> __s{__t.time_since_epoch() - __li.elapsed};
if (!__li.is_leap_second) [[likely]]
- return _M_f._M_format(__s, __fc);
+ return _M_f._M_format(chrono::round<_Duration>(__s), __fc);
else
return _M_f._M_format(__utc_leap_second(__s), __fc);
}
Or maybe not even subtract leap seconds at all when the the sum of elapsed leap
seconds is less than Duration{1}? If the time being formatted can't represent
the number of elapsed leap seconds, is it meaningful to say the time falls
within a leap second? For the first ever leap second, yes it is:
clock_cast(sys_days{July/1/1972} - 500ms) + 500ms
-> 1972-06-30 23:59:60.000
round(clock_cast(sys_days{July/1/1972} - 500ms) + 500ms)
-> 1972-06-30 23:59:60
But for every leap second after that (and all future ones, unless the sum of
positive and negative leap seconds becomes a multiple of 60 again) rounding a
sys_time to utc_time cannot fall within a leap second and so doesn't
need to print "60" for the seconds:
clock_cast(sys_days{January/1/1973} - 500ms) + 500ms
-> 1972-12-31 23:59:60.000
round(clock_cast(sys_days{January/1/1973} - 500ms) + 500ms)
-> 1972-12-31 23:59:59 (with current GCC trunk, so not rounded to minutes)
-> 1973-01-01 00:00:00 (with the patch above to round to minutes)
The 23:59:59 result is not useful, it's neither a leap second like 23:59:60,
nor a round number of minutes like 00:00:00. I think we should format it as
00:00:00, which we could do by not subtracting the leap seconds at all.
Maybe we could do:
if (auto li = get_leap_second_info(ut); !li.is_leap_second && li.elapsed <
Duration{1})
_M_format(sys_time(ut.time_since_epoch()), fc);
else if (!li.is_leap_second)
_M_format(round(sys_time(ut.time_since_epoch()) -
li.elapsed), fc);
else
// ...
But I don't think that's necessary, just round should give the
desired result. Avoiding the subtraction doesn't seem like a useful
optimization (especially as we'd still have done the much slower
get_leap_second_info lookup anyway).
CC Howard to check I'm not talking nonsense.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #18 from Andrew Pinski --- Hmm, looking at what is done in combine, I wonder why forwprop didn't do the address add into the memory. That would definitely decrease the # of combines being done. Maybe it is because it is used more than once. But still seems like another pass should have done the a=b+c; d=e*[a] into a=b+c; d=e*[b+c] before hand. Maybe there is some address cost going wrong here that forwprop is causing issues. And it just happens combine does not take that into account due to rtl cost not taking address cost into account.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #17 from Segher Boessenkool --- Why does this happen so extremely often for s390x customers? It should from first principles happen way more often for e.g. powerpc, but we never see such big problems, let alone "all of the time"! So what is really happening? And, when did this start, anyway, because apparently at some point in time all was fine?
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #17 from Dimitry Andric --- With both attached patches, I can build gcc master (gcc-14-9347-g790e0b478ea) with --disable-bootstrap, against libc++ 18 on FreeBSD 15-CURRENT, using clang 18 as host compiler.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #16 from Dimitry Andric --- Created attachment 57639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57639=edit Fix identifier poisoning in libcc1plugin and libc1plugin Here is another patch that can be committed separately. It fixes the direct inclusion of in libcc1plugin.cc and libcp1plugin.cc, and replaces it with INCLUDE_VECTOR before system.h.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #16 from Segher Boessenkool --- (In reply to Andreas Krebbel from comment #14) > If my analysis from comment #1 is correct, combine does superfluous steps > here. Getting rid of this should not cause any harm, but should be > beneficial for other targets as well. I agree that the patch I've proposed > is kind of a hack. Do you think this could be turned into a proper fix? When some insns have changed (or might have changed, combine does not always know the details), combinations of the insn with later insns are tried again. Sometimes this finds new combination opportunities. Not retrying combinations after one of the insns has changed would be a regression.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 104956, which changed state. Bug 104956 Summary: ICE with -fmodules-ts unordered_set and map https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104956 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/104234] ICE with -fmodules-ts and std::map/_Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104234 Patrick Palka changed: What|Removed |Added CC||john2.718281828459045235360 ||287 at gmail dot com --- Comment #4 from Patrick Palka --- *** Bug 104956 has been marked as a duplicate of this bug. ***
[Bug c++/104956] ICE with -fmodules-ts unordered_set and map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104956 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- dup of the recently fixed PR104234 *** This bug has been marked as a duplicate of bug 104234 ***
[Bug target/114083] Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #7 from Maciej W. Rozycki --- (In reply to Roland Illig from comment #6) > There's a problem with the wording though. On a platform that doesn't > support conditional-move operations, it's not possible to _use_ > conditional-move operations. Period. It's only possible to _emulate_ the > behavior of these operations. There's just too much implementer's speak in the option description here. Sorry about this. What the option internally enables it is a set of named RTL machine description patterns that implement the respective conditional-move operations. So in terms of RTL the operations are indeed available unconditionally. But I guess the compiler's internal representation is less of an interest from the user's point of view. What do you think of Andreas's suggestion for the English wording?
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 104924, which changed state. Bug 104924 Summary: bad_variant_access When using iostream and variant as modules https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104924 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/104924] bad_variant_access When using iostream and variant as modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104924 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Target Milestone|--- |13.0 --- Comment #4 from Patrick Palka --- This seems fixed for GCC 13+.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 104523, which changed state. Bug 104523 Summary: G++ crash when compiling a simple module that includes pybind11/stl.h https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104523 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/104523] G++ crash when compiling a simple module that includes pybind11/stl.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104523 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 14 since r14-8963.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 104202, which changed state. Bug 104202 Summary: when defining a std::string in a module implementation file using -O2 g++ segfaults https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104202 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/104202] when defining a std::string in a module implementation file using -O2 g++ segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104202 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- This seems fixed for GCC 14 since the fix for PR112588 I suspect. *** This bug has been marked as a duplicate of bug 112588 ***
[Bug c++/112588] [modules] ICE in make_decl_rtl when returning str literal when string header imported in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112588 Patrick Palka changed: What|Removed |Added CC||f.b.brokken at rug dot nl --- Comment #7 from Patrick Palka --- *** Bug 104202 has been marked as a duplicate of this bug. ***
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 103844, which changed state. Bug 103844 Summary: [modules] ICE when exporting shared_ptr alias https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103844 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/105320] Use of shared_ptr within a type exported from a module results in spurious compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105320 Patrick Palka changed: What|Removed |Added CC||tim152 at tgf dot pw --- Comment #3 from Patrick Palka --- *** Bug 103844 has been marked as a duplicate of this bug. ***
[Bug c++/103844] [modules] ICE when exporting shared_ptr alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103844 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 105320 ***
[Bug c++/103468] [modules] ICE Segmentation fault during GIMPLE pass walloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103468 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- This seems fixed since GCC 13.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 103468, which changed state. Bug 103468 Summary: [modules] ICE Segmentation fault during GIMPLE pass walloca https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103468 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/105320] Use of shared_ptr within a type exported from a module results in spurious compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105320 --- Comment #2 from Patrick Palka --- (In reply to Patrick Palka from comment #1) > GCC doesn't ICE, but it rejects with: GCC _trunk_ doesn't ICE rather..
[Bug c++/105320] Use of shared_ptr within a type exported from a module results in spurious compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105320
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-03-06
Ever confirmed|0 |1
Keywords||rejects-valid
CC||ppalka at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Patrick Palka ---
GCC doesn't ICE, but it rejects with:
error: conflicting declaration of template ‘template class std::__shared_ptr’
note: previous declaration ‘template class std::__shared_ptr@test_support’
error: conflicting declaration of template ‘template class std::__weak_ptr’
note: previous declaration ‘template class std::__weak_ptr@test_support’
Reduced:
$ cat 105320_a.C
module;
template struct _Sp_atomic;
template struct shared_ptr {
template friend struct _Sp_atomic;
using atomic_type = _Sp_atomic;
};
export module test_support;
export
template struct A {
shared_ptr data;
};
$ cat 105320_b.C
import test_support;
A a;
$ g++ -fmodules-ts 105320_{a,b}.C
105320_a.C:2:1: warning: global module fragment contents must be from
preprocessor inclusion [-Wglobal-module]
2 | template struct _Sp_atomic;
| ^~~~
In module test_support, imported at 105320_b.C:1:
105320_a.C: In instantiation of ‘struct shared_ptr@test_support’:
105320_a.C:11:18: required from ‘struct A@test_support’
11 |shared_ptr data;
| ^~~~
105320_b.C:3:8: required from here
3 | A a;
|^
105320_a.C:4:33: error: conflicting declaration of template ‘template
struct _Sp_atomic’
4 | template friend struct _Sp_atomic;
| ^~
105320_a.C:2:24: note: previous declaration ‘template struct
_Sp_atomic@test_support’
2 | template struct _Sp_atomic;
|^~
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 111785, which changed state. Bug 111785 Summary: [modules] ICE when compiling fmt lib as module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111785 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108080 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=111785| CC||mends-sputter.0z at icloud dot com --- Comment #10 from Patrick Palka --- *** Bug 111785 has been marked as a duplicate of this bug. ***
[Bug c++/111785] [modules] ICE when compiling fmt lib as module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111785 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=108080| Status|UNCONFIRMED |RESOLVED --- Comment #6 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 108080 ***
[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108080 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Last reconfirmed||2024-03-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #9 from Patrick Palka --- We don't implement OPTIMIZATION_NODE and TARGET_OPTION_NODE streaming: case OPTIMIZATION_NODE: case TARGET_OPTION_NODE: // FIXME: Our representation for these two nodes is a cache of // the resulting set of options. Not a record of the options // that got changed by a particular attribute or pragma. Should // we record that, or should we record the diff from the command // line options? The latter seems the right behaviour, but is // (a) harder, and I guess could introduce strangeness if the // importer has set some incompatible set of optimization flags? gcc_unreachable (); break;
[Bug fortran/103707] Stray "Array operands are incommensurate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #8 from anlauf at gcc dot gnu.org --- The "Array operands are incommensurate" error is gone. With -frange-check (the default) we are left with "Division by zero", which I think is intended. Use -fno-range-check if you want to compile the code.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 107083, which changed state. Bug 107083 Summary: [modules] internal compiler error: in core_vals, at cp/module.cc:6127 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107083 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108080 Patrick Palka changed: What|Removed |Added CC||karl.weber99 at gmx dot net --- Comment #8 from Patrick Palka --- *** Bug 107083 has been marked as a duplicate of this bug. ***
[Bug c++/107083] [modules] internal compiler error: in core_vals, at cp/module.cc:6127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107083 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 108080 ***
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 --- Comment #4 from Jonathan Wakely --- This has revealed another bug in some of the from_stream overloads, due to Clock::from_sys / Clock::from_utc sometimes returning a higher precision value than the input argument (due to using the common_type with seconds).
[Bug c++/105512] compilation with -fmodules-ts and std=c++20 leads to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105512 Patrick Palka changed: What|Removed |Added Keywords||wrong-code Ever confirmed|0 |1 Last reconfirmed||2024-03-06 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110730 Status|UNCONFIRMED |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- (In reply to David Truby from comment #1) > Interestingly the issue also goes away if -D_GLIBCXX_USE_CXX11_ABI=0 is > passed to both TUs so I suspect there's an issue with the module file not > exporting the correct ABI for `std::string` Good catch, so this is the same underlying issue as in PR110730.
[Bug fortran/105658] Passing array component to unlimited polymorphic routine passes wrong slice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Priority|P3 |P4 Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #3 from anlauf at gcc dot gnu.org --- Backporting to 13-branch appears to depend on a backport of Paul's commit r14-870-g6c95fe9bc05537, or part of it, plus maybe more. Might be risky. Setting target milestone to 14 and closing. Thanks to Peter for the patch!
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.3 Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing.
[Bug fortran/114012] overloaded unary operator called twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114012 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.3 Status|ASSIGNED|RESOLVED Priority|P3 |P4 Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing. Thanks for the report!
[Bug fortran/114012] overloaded unary operator called twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114012 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1f5787e4b803a4294eeb80e048f56ccdb99c1b3b commit r13-8407-g1f5787e4b803a4294eeb80e048f56ccdb99c1b3b Author: Harald Anlauf Date: Sun Feb 25 21:18:23 2024 +0100 Fortran: do not evaluate polymorphic functions twice in assignment [PR114012] PR fortran/114012 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): Evaluate non-trivial arguments just once before assigning to an unlimited polymorphic dummy variable. gcc/testsuite/ChangeLog: * gfortran.dg/pr114012.f90: New test. (cherry picked from commit 2f71e801ad0bb1f620334aadbd7c99cc4efe6309)
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:77cf842869ddda8cfcdbb7db6e65ecfb9ac432fc commit r13-8406-g77cf842869ddda8cfcdbb7db6e65ecfb9ac432fc Author: Steve Kargl Date: Fri Feb 23 22:05:04 2024 +0100 Fortran: ALLOCATE statement, SOURCE/MOLD expressions with subrefs [PR114024] PR fortran/114024 gcc/fortran/ChangeLog: * trans-stmt.cc (gfc_trans_allocate): When a source expression has substring references, part-refs, or %re/%im inquiries, wrap the entity in parentheses to force evaluation of the expression. gcc/testsuite/ChangeLog: * gfortran.dg/allocate_with_source_27.f90: New test. * gfortran.dg/allocate_with_source_28.f90: New test. Co-Authored-By: Harald Anlauf (cherry picked from commit 80d126ba99f4b9bc64d4861b3c4bae666497f2d4)
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 100433, which changed state. Bug 100433 Summary: [modules] segfault with optimization greater than -O0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100433 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/100433] [modules] segfault with optimization greater than -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100433 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112588 Resolution|--- |FIXED Target Milestone|--- |14.0 CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Fixed for GCC 14 by r14-8196 for PR112588.
[Bug c++/99999] segmentation fault when declaring concept in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112588 Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick Palka --- Fixed for GCC 14 by r14-8196 for PR112588.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 9, which changed state. Bug 9 Summary: segmentation fault when declaring concept in module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99377 Patrick Palka changed: What|Removed |Added Last reconfirmed|2021-03-04 00:00:00 |2024-3-6 --- Comment #16 from Patrick Palka --- The comment #15 testcase still fails on trunk.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113121, which changed state. Bug 113121 Summary: failed to load pendings for ‘std::__format::__do_vformat_to’ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113121 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug c++/113121] failed to load pendings for ‘std::__format::__do_vformat_to’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113121 Patrick Palka changed: What|Removed |Added Resolution|--- |WORKSFORME CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick Palka --- Works for me too.
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 --- Comment #1 from Iain Sandoe --- note Darwin's linker does not, by default permit symbols to be undefined. If the test case requires allowing undefined symbols to complete, then either we need to specify them thus: -Wl,-U,_XXX (for each symbol) or if they are unknown at build time, but required dynamically at runtime... -Wl,-undefined,dynamic_lookup ( I am not sure if this is a requirement of the test, or some artefact of the test case reduction ).
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 99749, which changed state. Bug 99749 Summary: Error when using std::string in a module (versions 11.0.1 20210307, 11.0.1 20210314, and 11.0.1 20210321) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99749 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/99749] Error when using std::string in a module (versions 11.0.1 20210307, 11.0.1 20210314, and 11.0.1 20210321)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99749 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #1 from Patrick Palka --- This seems long fixed, even GCC 11 is happy.
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Iain Sandoe --- (In reply to Marek Polacek from comment #6) > Should we close this as fixed then? Yes, it is fixed as per my recent testing.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 110805, which changed state. Bug 110805 Summary: g++ crash on modules with exported class providing string constant with obscure content https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110805 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/110805] g++ crash on modules with exported class providing string constant with obscure content
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110805 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.0 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- GCC trunk accepts the testcase and indeed this seems to be pretty much a dup of the recently fixed PR112899. If the string fits in the SSO buffer we can statically initialize it, otherwise we need dynamic initialization which crashed until r14-6979. *** This bug has been marked as a duplicate of bug 112899 ***
[Bug c++/112899] odr-using constexpr static data member of class exported from module results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112899 Patrick Palka changed: What|Removed |Added CC||jo.hiller+gcc at gmail dot com --- Comment #5 from Patrick Palka --- *** Bug 110805 has been marked as a duplicate of this bug. ***
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Should we close this as fixed then?
[Bug middle-end/113738] [14 Regression] ICE: in df_reg_chain_verify_unmarked, at df-scan.cc:4001 with -O2 -march=rv64gcv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113738 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- This was fixed on the trunk by Juzhe a while back: commit d29136ad3282905145e24d7ec10b6efe4ab5d2f1 Author: Juzhe-Zhong Date: Tue Feb 6 07:12:24 2024 +0800 RISC-V: Fix infinite compilation of VSETVL PASS This patch fixes issue reported by Jeff. Testing is running. Ok for trunk if I passed the testing with no regression ? gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): Fix inifinite compilation. (pre_vsetvl::remove_vsetvl_pre_insns): Ditto.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #15 from Iain Sandoe --- (In reply to Dimitry Andric from comment #14) > (In reply to Iain Sandoe from comment #13) > > (In reply to Francois-Xavier Coudert from comment #11) > > > Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking > > > bootstrap on x86_64-apple-darwin23 > > > > confirmed the bootstrap fail and that the proposed patch fixes it (on > > x86_64-darwin23). Now testing more widely on other Darwin versions. > > > > For Darwin, this is a regression (caused by changes in the system SDK > > headers) - what is the situation with freeBSD? > > The situation is that the FreeBSD port maintainer disabled the option to > build the gcc ports without bootstrap, to work around the problem. :-) > > I built the ports locally, but there are seem to have been some recent > introductions of poisoned identifiers in plugins, which also have be fixed > by adding #define INCLUDE_xxx statements at the top of the sources, before > including system.h. > > I will update the patches to build with gcc master, and re-attach/send them. FAOD, in the Darwin case this is a failure in the regular bootstrap at stage-1 (not an attempt to build --disable-bootstrap or a cross).
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 100135, which changed state. Bug 100135 Summary: [modules] ICE when using constants in a module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100135 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/100135] [modules] ICE when using constants in a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100135 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99232 CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Patrick Palka --- GCC 14 accepts this since the fix for PR99232.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 Dimitry Andric changed: What|Removed |Added CC||dimitry@unified-streaming.c ||om --- Comment #14 from Dimitry Andric --- (In reply to Iain Sandoe from comment #13) > (In reply to Francois-Xavier Coudert from comment #11) > > Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking > > bootstrap on x86_64-apple-darwin23 > > confirmed the bootstrap fail and that the proposed patch fixes it (on > x86_64-darwin23). Now testing more widely on other Darwin versions. > > For Darwin, this is a regression (caused by changes in the system SDK > headers) - what is the situation with freeBSD? The situation is that the FreeBSD port maintainer disabled the option to build the gcc ports without bootstrap, to work around the problem. :-) I built the ports locally, but there are seem to have been some recent introductions of poisoned identifiers in plugins, which also have be fixed by adding #define INCLUDE_xxx statements at the top of the sources, before including system.h. I will update the patches to build with gcc master, and re-attach/send them.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 112621, which changed state. Bug 112621 Summary: g++ error: "references internal linkage entity" when compiling a module interface https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112621 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/112621] g++ error: "references internal linkage entity" when compiling a module interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112621 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |14.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99232 CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Patrick Palka --- GCC 14 accepts this since the fix for PR99232.
[Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target||i686 --- Comment #29 from Uroš Bizjak --- Fixed.
[Bug c++/99569] segfault when running a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99569 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=112580|a/show_bug.cgi?id=112588 --- Comment #4 from Patrick Palka --- (In reply to Patrick Palka from comment #3) > Actually it seems fixed on trunk ever since the fix for PR112580. Whoops, I meant PR112588.
[Bug c++/110730] STL internal allocation/deallocation might lead to core dump in the use of header units of the modules feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110730 --- Comment #2 from Patrick Palka --- Without modules we end up calling _ZNSt10filesystem12current_pathB5cxx11Ev i.e. std::filesystem::current_path[abi:cxx11]() and with modules we call _ZNSt10filesystem12current_pathEv i.e. the non-abi-tagged version. The abi tag is getting lost because we don't stream the abi_tag attribute attached to an inline namespace.
