[Bug middle-end/110660] conditional length reduction optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110660 --- Comment #1 from Richard Biener --- The vectorizer itself could do the merging which means it could also more accurately cost things. Otherwise think about whether/how such a situation might arise from people using RVV intrinsics - how are those exposed to GIMPLE / RTL and at which level could that be optimized? Is it possible to write an intrinsic testcase with such opportunity?
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 Richard Biener changed: What|Removed |Added Target||x86_64-linux-gnu --- Comment #8 from Richard Biener --- yes
[Bug c/110662] Segmentation fault with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110662 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55540 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55540=edit The compiler output
[Bug c/110662] New: Segmentation fault with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110662 Bug ID: 110662 Summary: Segmentation fault with '-O3' Product: gcc Version: 11.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: --- Created attachment 55539 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55539=edit The preprocessed file *** OS and Platform: CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux *** gcc version: gcc -v Using built-in specs. COLLECT_GCC=/home/new-gcc/gcc-11-0706/bin/gcc COLLECT_LTO_WRAPPER=/home/new-gcc/gcc-11-0706/libexec/gcc/x86_64-pc-linux-gnu/11.4.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/new-gcc/gcc-11-0706/ --disable-multilib --enable-language=c,c++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.4.1 20230706 (GCC) *** Command Lines: # /home/new-gcc/gcc-11-0706/bin/gcc -I /home/csmith/include/csmith-2.3.0/ -O3 -fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-allocation-dce -fno-asynchronous-unwind-tables -fno-auto-inc-dec -fno-bit-tests -fno-branch-count-reg -fno-caller-saves -fno-code-hoisting -fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fno-crossjumping -fno-cse-follow-jumps -fno-dce -fno-defer-pop -fno-delete-null-pointer-checks -fno-devirtualize -fno-devirtualize-speculatively -fno-dse -fno-early-inlining -fno-expensive-optimizations -fno-forward-propagate -fno-fp-int-builtin-inexact -fno-function-cse -fno-gcse -fno-gcse-after-reload -fno-gcse-lm -fno-guess-branch-probability -fno-hoist-adjacent-loads -fno-if-conversion -fno-if-conversion2 -fno-indirect-inlining -fno-inline -fno-inline-atomics -fno-inline-functions -fno-inline-functions-called-once -fno-inline-small-functions -fno-ipa-bit-cp -fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf -fno-ipa-icf-functions -fno-ipa-icf-variables -fno-ipa-modref -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-ra -fno-ipa-reference -fno-ipa-reference-addressable -fno-ipa-sra -fno-ipa-stack-alignment -fno-ipa-vrp -fno-ira-hoist-pressure -fno-ira-share-save-slots -fno-ira-share-spill-slots -fno-isolate-erroneous-paths-dereference -fno-ivopts -fno-jump-tables -fno-lifetime-dse -fno-loop-interchange -fno-loop-unroll-and-jam -fno-lra-remat -fno-math-errno -fno-move-loop-invariants -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-optimize-strlen -fno-partial-inlining -fno-peel-loops -fno-peephole -fno-peephole2 -fno-plt -fno-predictive-commoning -fno-prefetch-loop-arrays -fno-printf-return-value -fno-ree -fno-reg-struct-return -fno-rename-registers -fno-reorder-blocks -fno-reorder-blocks-and-partition -fno-reorder-functions -fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock -fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec -fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep -fno-schedule-fusion -fno-schedule-insns2 -fno-short-enums -fno-shrink-wrap -fno-shrink-wrap-separate -fno-signed-zeros -fno-split-ivs-in-unroller -fno-split-loops -fno-split-paths -fno-split-wide-types -fno-ssa-backprop -fno-ssa-phiopt -fno-stdarg-opt -fno-store-merging -fno-strict-aliasing -fno-strict-volatile-bitfields -fno-thread-jumps -fno-toplevel-reorder -fno-trapping-math -fno-tree-bit-ccp -fno-tree-builtin-call-dce -fno-tree-ccp -fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-cselim -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-forwprop -fno-tree-fre -fno-tree-loop-distribute-patterns -fno-tree-loop-distribution -fno-tree-loop-if-convert -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-loop-vectorize -fno-tree-partial-pre -fno-tree-phiprop -fno-tree-pre -fno-tree-pta -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize -fno-tree-slsr -fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge -fno-tree-ter -fno-tree-vrp -fno-unroll-completely-grow-size -fno-unswitch-loops -fno-unwind-tables -fno-var-tracking -fno-var-tracking-assignments -fno-version-loops-for-strides -fno-web -fno-allow-store-data-races -fno-associative-math -fno-branch-probabilities -fno-conserve-stack -fno-cx-fortran-rules -fno-cx-limited-range -fno-delayed-branch -fno-delete-dead-exceptions -fno-exceptions -fno-finite-loops -fno-finite-math-only -fno-float-store -fno-gcse-las -fno-gcse-sm -fno-graphite -fno-graphite-identity -fno-ipa-pta -fno-ira-loop-pressure -fno-isolate-erroneous-paths-attribute
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652
--- Comment #4 from Kewen Lin ---
I can't reproduce this on ppc64le with both the default bootstrapping checking
option --enable-checking=yes,extra and the reported --enable-checking=release.
I'm going to test it on cfarm x86 machine.
If the error message lineno is correct, it complains on line 10962:
/* Collect vector loads and later create their permutation in
vect_transform_grouped_load (). */
if (!costing_p && (grouped_load || slp_perm))
dr_chain.quick_push (new_temp); // line 10962
It's guarded with !costing_p and we have:
/* One common place to cost the above vect load for different
alignment support schemes. */
if (costing_p)
{
...
}
else
{
vec_dest = vect_create_destination_var (scalar_dest,
vectype);
...
new_temp = make_ssa_name (vec_dest, new_stmt); // line 10911
...
}
at line 10911, new_temp is always initialized for !costing_p. It looks like a
false positive.
Anyway, I'll reproduce it first on x86.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #7 from Rich Townsend --- (In reply to Andrew Pinski from comment #6) > GCC 13 won't build with anything older than GCC 4.8.x as documented at > https://gcc.gnu.org/install/prerequisites.html (which is right now for the > trunk but that requirement has not changed yet). The plot thickens -- I misidentified the compiler, here's the correct id: [user@0ec987449fdf gcc-build]$ x86_64-pc-linux-gnu-g++ -v Using built-in specs. COLLECT_GCC=x86_64-pc-linux-gnu-g++ COLLECT_LTO_WRAPPER=/opt/bootstrap/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/user/sdk2-tmp/build/gcc/configure CC= CXX= --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk --with-mpfr=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer --enable-clocale=generic Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.1.0 (GCC) So, 12.1.0 should be perfectly capable of building 13.1, right?
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Oleg Endo --- Fixed on master, GCC 13, GCC 12, GCC 11. Should also be applied to older release branches that are maintained elsewhere.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #14 from CVS Commits --- The releases/gcc-13 branch has been updated by Oleg Endo : https://gcc.gnu.org/g:ef4b6d29d9801c970bee1b3e8675b19ef5f61d2a commit r13-7563-gef4b6d29d9801c970bee1b3e8675b19ef5f61d2a Author: Oleg Endo Date: Fri Jul 14 09:54:20 2023 +0900 SH: Fix PR101469 peephole bug gcc/ChangeLog: PR target/101469 * config/sh/sh.md (peephole2): Handle case where eliminated reg is also used by the address of the following memory operand.
[Bug c++/110661] New: Weird handing for deleting a void* pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110661
Bug ID: 110661
Summary: Weird handing for deleting a void* pointer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
GCC accepts the following code snipped and says that " warning: deleting
'void*' is undefined". Godbolt link: https://godbolt.org/z/xKWTGrfPc
```
constexpr int test_delete_pvoid()
{
delete static_cast(new int);
return 0;
}
constexpr int n = test_delete_pvoid();
```
It's contradictory that GCC considers this undefined but accepts it in constant
evaluation.
Moreover, https://eel.is/c++draft/expr.delete#1 seemingly states that deleting
a void* pointer is ill-formed.
[Bug c/110660] New: conditional length reduction optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110660
Bug ID: 110660
Summary: conditional length reduction optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
Consider this following test:
#include
int __attribute__((noipa))
add_loop (int32_t * __restrict x, int32_t n, int res, int * __restrict cond)
{
for (int i = 0; i < n; ++i)
if (cond[i])
res += x[i];
return res;
}
Current GCC can do vectorize reduction for RVV:
[local count: 630715945]:
...
_59 = .SELECT_VL (ivtmp_57, POLY_INT_CST [4, 4]);
ivtmp_40 = _59 * 4;
vect__4.10_43 = .LEN_MASK_LOAD (vectp_cond.8_41, 32B, _59, 0, { -1, ... });
mask__18.11_45 = vect__4.10_43 != { 0, ... };
vect__7.14_49 = .LEN_MASK_LOAD (vectp_x.12_47, 32B, _59, 0, mask__18.11_45);
vect__ifc__33.15_51 = .VCOND_MASK (mask__18.11_45, vect__7.14_49, { 0, ...
});
vect__34.16_52 = .COND_LEN_ADD ({ -1, ... }, vect_res_19.7_38,
vect__ifc__33.15_51, vect_res_19.7_38, _59, 0);
...
[local count: 105119324]:
_54 = .REDUC_PLUS (vect__34.16_52);
_55 = res_11(D) + _54;
Actually, we can optmize "VCOND_MASK + COND_LEN_ADD" into single "COND_LEN_ADD"
with replacing the argument of "COND_LEN_ADD".
Consider this following pattern:
dummy_mask = { -1, ... }
dummy_else_value = { 0, ... } ;; This is dummy for PLUS, since a + 0 = a
op1_2 = .VCOND_MASK (control_mask, op1_1, dummy_else_value);
result = .COND_LEN_ADD (dummy_mask, op0, op1_2, op2, loop_len, bias)
Since it is using dummy_mask and dummy_else_value, we can simplify this
operation into:
result = .COND_LEN_ADD (control_mask, op0, op1_1, op2, loop_len, bias)
To do this optimization, we can either do this optimization either in
middle-end
"match.pd" or in backend "combine pass" to handle this.
Which approach is better?
Thanks.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Oleg Endo : https://gcc.gnu.org/g:5f20f736c1144dd9f2ae2f99099b7f7b21a3ab4e commit r12-9772-g5f20f736c1144dd9f2ae2f99099b7f7b21a3ab4e Author: Oleg Endo Date: Fri Jul 14 09:54:20 2023 +0900 SH: Fix PR101469 peephole bug gcc/ChangeLog: PR target/101469 * config/sh/sh.md (peephole2): Handle case where eliminated reg is also used by the address of the following memory operand.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Oleg Endo : https://gcc.gnu.org/g:75b8353e4b61566f7e8ac627204e2bcd6bfe60a6 commit r11-10909-g75b8353e4b61566f7e8ac627204e2bcd6bfe60a6 Author: Oleg Endo Date: Fri Jul 14 09:54:20 2023 +0900 SH: Fix PR101469 peephole bug gcc/ChangeLog: PR target/101469 * config/sh/sh.md (peephole2): Handle case where eliminated reg is also used by the address of the following memory operand.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #11 from CVS Commits --- The master branch has been updated by Oleg Endo : https://gcc.gnu.org/g:4dbb3af1efe55174a714d15c2994cf2842ef8c28 commit r14-2511-g4dbb3af1efe55174a714d15c2994cf2842ef8c28 Author: Oleg Endo Date: Fri Jul 14 09:54:20 2023 +0900 SH: Fix PR101496 peephole bug gcc/ChangeLog: PR target/101469 * config/sh/sh.md (peephole2): Handle case where eliminated reg is also used by the address of the following memory operand.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #8 from dave.anglin at bell dot net ---
On 2023-07-13 2:16 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #7 from dave.anglin at bell dot net ---
> On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote:
>> ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36:
>> error:
>> 'strtold' is not a member of 'std'; did you mean 'strtoll'?
> That's a problem with stdlib.h header.
I thought this was because we lack _NAMESPACE_STD_START and _NAMESPACE_STD_END
statements
around the strtold declaration in stdlib.h, but this didn't help. Maybe we lack
a define for _NAMESPACE_STD
/* ANSI C++ namespace std support */
#ifdef _NAMESPACE_STD
#define _NAMESPACE_STD_START namespace std {
#define _NAMESPACE_STD_END }
or maybe "using::strtold" additions are needed to various cstdlib files in gcc.
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 Kewen Lin changed: What|Removed |Added Last reconfirmed||2023-07-14 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Kewen Lin --- Thanks for reporting and I'll have a look.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #101 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #100)
> Created attachment 55513 [details]
> Arithmetic right shift late expanding
>
> (In reply to Oleg Endo from comment #99)
> > Meanwhile, here's my iteration on your patch.
>
> Thank you! I did all checks I did before, added testcases, and edited to fit
> the code style.
Looks OK. Just 3 things:
> +++ gcc-13.1.0/gcc/testsuite/gcc.target/sh/pr54089-11.c 2023-07-07
> 08:56:41.212345982 +0300
> @@ -0,0 +1,37 @@
> +/* Check that 'tst #64,r0' genrated. */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
Please rename this test to pr49263... to have all tst #imm,r0 related tests in
one place.
Also:
- 'genrated' -> 'generated'
- space before opening paren of function args
- 2 spaces indention
- similarly, check code style of other added tests
> --- gcc-13.1.0.orig/gcc/testsuite/gcc.target/sh/pr54089-12.c 1970-01-01
> 03:00:00.0 +0300
Can you try out Segher's suggestion in #c88 to make the regex look less
cluttered?
[Bug tree-optimization/94094] [meta-bug] store-merging and/or bswap load/store-merging missed optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-07-13 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- .
[Bug middle-end/97968] [11/12/13/14 Regression] Unnecessary mov instruction with comparison and cmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||13.1.0 --- Comment #7 from Andrew Pinski --- In GCC 13+ we produce: f: xorl%eax, %eax cmpl%esi, %edi cmovg %edi, %eax ret
[Bug rtl-optimization/97756] [11/12/13/14 Regression] Inefficient handling of 128-bit arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756 Andrew Pinski changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #11 from Andrew Pinski --- This seems to be improved on trunk ...
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 --- Comment #4 from Jose E. Marchesi --- Looks like `combine' is generating paradoxical subregs of mems, which seem to confuse LRA and these weird incorrect reloads end up being generated. The easiest fix for this is to make the backend to use the instruction scheduler, which makes `combine' to not generate such subregs.
[Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
--- Comment #7 from Jason Merrill ---
In an email thread Jakub wrote:
Only the simplest assumptions in [[assume(cond)]] where there clearly aren't
any
side-effects no risks of them are lowered to if (!cond) __builtin_unreachable
();
in the IL, anything else goes into the condition being outlined in a
separate artificial function and an internal function recording the
assumption in the IL.
The optimizers then can optimize both the artificial function and the
caller.
The missed optimization thing is that currently only the value range
propagation is able to take advantage of the assumptions, and VRP
is only able to deal with scalars.
We have interprocedural optimizations like IPA scalar replacement of
aggregates etc., where we can optimize passing aggregates at function
boundaries to passing just some scalars from them if the rest isn't needed
etc., but because the assumptions aren't normal calls they'd need tweaks to
be able to optimize the assumptions too so that VRP could take advantage of
those.
Why don't the existing optimizations work on the artificial function the same
as any other function? i.e. like
struct S { bool x; };
void do_something();
inline void assumption_1 (const S& s) noexcept {
if (s.x) __builtin_unreachable ();
}
void fn(S s) {
assumption_1 (s);
if (s.x) do_something();
}
which is also optimized as expected.
[Bug target/96050] PDP-11: 32-bit MOV from offset(Rn) overrides Rn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96050 --- Comment #1 from pkoning at gcc dot gnu.org --- There certainly are some missing earlyclobbers in the MD file. Someone else reported bad code from this and a patch to add the missing "&" fixed those. Curious that it doesn't for your test case; it suggests that there is an additional issue that needs to be understood.
[Bug c++/103806] internal compiler error: in vague_linkage_p, at cp/decl2.c:2192 for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103806 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #3 from pkoning at gcc dot gnu.org --- At the moment there is no support for other than C. It would be nice for that to change; it's not particularly practical without first doing ELF. That has been prototyped but that work is not available, but it can probably be redone with a reasonable amount of effort.
[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug tree-optimization/105834] [13/14 Regression] Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105834 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||14.0 --- Comment #4 from Andrew Pinski --- Looks to be fixed on the trunk. We also now get from evrp: Global Exported: c_5 = [irange] int [0, 0][3, 3]
[Bug tree-optimization/96945] unused std::vector is not always optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96945
Andrew Pinski changed:
What|Removed |Added
Component|c++ |tree-optimization
Last reconfirmed||2023-07-13
Status|UNCONFIRMED |NEW
Summary|optimizations regression|unused std::vector is not
|when defaulting copy|always optimized away
|constructor |
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Andrew Pinski ---
Confirmed.
In the case of having a move constructor, there is a loop generated for the
constructor (and since this is an empty struct, the loop is empty).
In the case of not having a move constructo, we get:
MEM [(char * {ref-all})_30] = MEM
[(char * {ref-all})];
In the end DSE does not remove that store even though it is dead right before
the operator delete.
_30 = operator new (3);
MEM [(char * {ref-all})_30] = MEM
[(char * {ref-all})];
D.26026 ={v} {CLOBBER(eol)};
operator delete (_30, 3); [tail call]
Also if we add an field and initialize it to 0, we get a memcpy:
__builtin_memcpy (_40, , 12);
Which is also not DSEd:
_40 = operator new (12);
__builtin_memcpy (_40, , 12);
D.26033 ={v} {CLOBBER(eol)};
operator delete (_40, 12); [tail call]
Maybe the clobber is getting in the way here
[Bug libstdc++/103801] Link tests are not allowed after GCC_NO_EXECUTABLES. for pdp11-aout target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103801 pkoning at gcc dot gnu.org changed: What|Removed |Added CC||pkoning at gcc dot gnu.org --- Comment #5 from pkoning at gcc dot gnu.org --- There is no pdp11 support in newlib (and never was as far as I know; it's not a matter of it having been "removed"). I've played with creating one, but not enough to submit the result. But that doesn't make the pdp11 target meaningless or say it needs to be removed. The only consequence of the lack of an off the shelf library package is that you can't run the execution testsuite. But you can, for example, run the compile part of the testsuite.
[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841 pkoning at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from pkoning at gcc dot gnu.org --- Fixed by the patch from Mikael Petterson.
[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841 --- Comment #3 from CVS Commits --- The master branch has been updated by Paul Koning : https://gcc.gnu.org/g:8f1a26ee259f72e42405b9c5f2b161042ec4014b commit r14-2509-g8f1a26ee259f72e42405b9c5f2b161042ec4014b Author: Mikael Pettersson Date: Thu Jul 13 16:06:39 2023 -0400 pdp11: Fix epilogue generation [PR107841] gcc/ PR target/107841 * config/pdp11/pdp11.cc (pdp11_expand_epilogue): Also deallocate alloca-only frame. gcc/testsuite/ PR target/107841 * gcc.target/pdp11/pr107841.c: New test.
[Bug c++/96533] ICE with three-way comparison when error occurs in templated operator< overload and -Wunused-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96533 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #11 from Patrick Palka --- Thus fixed. Adding a testcase for this issue doesn't seem super worthwhile.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #6 from Andrew Pinski --- GCC 13 won't build with anything older than GCC 4.8.x as documented at https://gcc.gnu.org/install/prerequisites.html (which is right now for the trunk but that requirement has not changed yet).
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #18 from Mikael Morin --- Followup patches submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059580.html https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624081.html
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #5 from Rich Townsend --- (In reply to Andrew Pinski from comment #2) > What compiler did you start with? > That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ? [user@60947d0cbd04 ~]$ x86_64-pc-linux-gnu-g++ -v bash: x86_64-pc-linux-gnu-g++: command not found [user@60947d0cbd04 ~]$ g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)
[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 Mikael Morin changed: What|Removed |Added Last reconfirmed||2023-07-13 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin --- Patches submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059596.html https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624384.html
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #4 from Rich Townsend --- Someone else seems to have the same problem: https://stackoverflow.com/questions/76375244/how-can-i-resolve-a-ld-eh-frame-hdr-refers-to-overlapping-fdes-error-during ...although there is no fix suggested.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-07-13 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- To build an GCC 13, you might need to bootstrap GCC 10 (which is just c++98 code rather than C++11) and then bootstrap GCC 13.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #2 from Andrew Pinski --- What compiler did you start with? That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ?
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #1 from Rich Townsend --- I should add that this is on CentOS 5.11, running inside a Docker container. This ships with a very old binutils, so before trying to compile gcc I installed binutils 2.40 (built from source with --disable-gprofng).
[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050 --- Comment #8 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:616a101848bfd5b61ffdd87ae9b1153139d916ca commit r14-2507-g616a101848bfd5b61ffdd87ae9b1153139d916ca Author: Mikael Morin Date: Thu Jul 13 21:23:44 2023 +0200 fortran: Release symbols in reversed order [PR106050] Release symbols in reversed order wrt the order they were allocated. This fixes an error recovery ICE in the case of a misplaced derived type declaration. Such a declaration creates nested symbols, one for the derived type and one for each type parameter, which should be immediately released as the declaration is rejected. This breaks if the derived type is released first. As the type parameter symbols are in the namespace of the derived type, releasing the derived type releases the type parameters, so one can't access them after that, even to release them. Hence, the type parameters should be released first. PR fortran/106050 gcc/fortran/ChangeLog: * symbol.cc (gfc_restore_last_undo_checkpoint): Release symbols in reverse order. gcc/testsuite/ChangeLog: * gfortran.dg/pdt_33.f90: New test.
[Bug bootstrap/110659] New: Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 Bug ID: 110659 Summary: Error from linker: .eh_frame_hdr refers to overlapping FDEs Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- I'm running into the following problem during a build of the 13.1.0 release: x86_64-pc-linux-gnu-g++ -std=c++11 -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genenums \ build/genenums.o build/read-md.o build/errors.o ../build-x86_64-pc-linux-gnu/libiberty/libiberty.a /home/user/sdk2-tmp/mesasdk/bin/ld: .eh_frame_hdr refers to overlapping FDEs /home/user/sdk2-tmp/mesasdk/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status This is on Linux with binutils-2.40. Configure as follows: /home/user/sdk2-tmp/build/gcc/configure CC= CXX= --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk --with-mpfr=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer --enable-clocale=generic Wondering whether any of these config flags are what's causing the problem...
[Bug target/110624] Xcode 15 ld warns about -macosx_version_min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #8 from Iain Sandoe --- so fixed by using the platform_version change. If anyone runs into a problem because they have makefiles/etc that build stand-alone ld lines, I guess they will have to fix them anyway (nothing GCC can do about that).
[Bug target/110624] Xcode 15 ld warns about -macosx_version_min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 --- Comment #7 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:032b5da1fc781bd3c23d9caa72fb09439e7f6f3a commit r14-2506-g032b5da1fc781bd3c23d9caa72fb09439e7f6f3a Author: Iain Sandoe Date: Thu Jul 13 07:36:51 2023 +0100 Darwin: Use -platform_version when available [PR110624]. Later versions of the static linker support a more flexible flag to describe the OS, OS version and SDK used to build the code. This replaces the functionality of '-mmacosx_version_min' (which is now deprecated, leading to the diagnostic described in the PR). We now use the platform_version flag when available which avoids the diagnostic. Signed-off-by: Iain Sandoe PR target/110624 gcc/ChangeLog: * config/darwin.h (DARWIN_PLATFORM_ID): New. (LINK_COMMAND_A): Use DARWIN_PLATFORM_ID to pass OS, OS version and SDK data to the static linker.
[Bug c++/96533] ICE with three-way comparison when error occurs in templated operator< overload and -Wunused-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96533 Patrick Palka changed: What|Removed |Added Known to work||12.1.0, 13.1.0 Known to fail||10.5.0, 11.4.0 CC||ppalka at gcc dot gnu.org --- Comment #10 from Patrick Palka --- This seems fixed for GCC 12+ by r12-6022-gbb2a7f80a98de3.
[Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110619 Patrick Palka changed: What|Removed |Added CC||natattak at gmail dot com, ||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- IIUC Nathaniel's patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623377.html will fix this.
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 Sergei Trofimovich changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #2 from Sergei Trofimovich --- If it helps bisect landed on r14-2493-g5f03844b32f452 commit 5f03844b32f45224c33dcea08a20b5a2089082f7 Author: Kewen Lin Date: Wed Jul 12 21:23:22 2023 -0500 vect: Adjust vectorizable_load costing on VMAT_CONTIGUOUS_REVERSE
[Bug target/93719] Unable to find a register to spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93719 --- Comment #1 from pkoning at gcc dot gnu.org --- This works with -mlra, so given the deprecation of old reload the right answer seems to be to close this as fixed.
[Bug tree-optimization/106379] DCE depends on order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107880 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > _1 = ~c_5(D); > _2 = _1 & s_4(D); > > Mine. > That is `c < s`. So the same as PR 106380 . Or PR 107880 .
[Bug tree-optimization/106570] [12/13/14 Regression] DCE sometimes fails with depending if statements since r12-2305-g398572c1544d8b75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107880 --- Comment #7 from Andrew Pinski --- I suspect if we optimize: _1 = ~c_6(D); _2 = _1 & s_7(D); to: c < s; VRP will just work now. (that would be PR 107880 ).
[Bug tree-optimization/101240] [missed optimization] Transitivity of less-than and less-or-equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101240
--- Comment #5 from Andrew Pinski ---
here is a better testcase:
```
int test_array(unsigned ()[3]) {
int t = (a[0]+a[1]+a[2]);
ALWAYS_TRUE(a[0] < a[1] && a[1] < a[2]);
return (a[0] < a[2])+t;
}
```
(just to make sure VRP is only dealing with SSA names).
We should be able to optimize the above to just
return a[0]+a[1]+a[2]+1;
[Bug fortran/110658] New: MINVAL/MAXVAL and deferred-length character arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110658 Bug ID: 110658 Summary: MINVAL/MAXVAL and deferred-length character arrays Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- Spin-off from pr110288: program p character(len=2), allocatable :: fixed(:) character(len=:), allocatable :: array(:) fixed = ["bb", "aa"] array = ["bb", "aa"] print *, minval (fixed) ! OK print *, maxval (array) ! runtime error end While the MINVAL for the fixed-length character array works fine, the MAXVAL for the deferred-length character array gives at runtime: a.out: ../../../gcc-trunk/libgfortran/generated/maxval0_s1.c:68: maxval0_s1: Assertion `xlen == len' failed. All versions since gcc-8 (when MINVAL/MAXVAL of character was implemented) fail.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #7 from dave.anglin at bell dot net --- On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote: > ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error: > 'strtold' is not a member of 'std'; did you mean 'strtoll'? That's a problem with stdlib.h header.
[Bug c++/108953] inefficient codegen for trivial equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953 Andrew Pinski changed: What|Removed |Added CC||jengelh at inai dot de --- Comment #5 from Andrew Pinski --- *** Bug 103733 has been marked as a duplicate of this bug. ***
[Bug c++/103733] Defaulted operator== for arrays of integral types could be done using memcmp instead of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103733 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 108953. Even though PR 108953 is newer, it contains more details on how to fix this and contains a few different/better testcases and such. *** This bug has been marked as a duplicate of bug 108953 ***
[Bug target/59172] pdp11-aout makes a wrong code at the epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from pkoning at gcc dot gnu.org --- It works properly in the current release.
[Bug target/59178] Stack corruption on register save/restore when using frame pointer on pdp-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59178 pkoning at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from pkoning at gcc dot gnu.org --- It works properly in the current version -- I see stack push in the prologue and matching stack pop operations in the epilogue.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55530|0 |1 is obsolete|| --- Comment #79 from Jakub Jelinek --- Created attachment 55538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55538=edit gcc14-bitint-wip.patch double -> large/huge signed/unsigned _BitInt support. Works on 8 conversions, will need to add larger testcase coverage and when happy with double, add it for float, long double and __float128 as well. And then large/huge signed/unsigned _BitInt support -> floating point.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #6 from dave.anglin at bell dot net ---
On 2023-07-13 1:09 p.m., redi at gcc dot gnu.org wrote:
> I'm testing this, which should define std::stof and std::stold for hpux11.11:
>
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -4148,12 +4148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> stod(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
>
> -#if _GLIBCXX_USE_C99_STDLIB
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOF
> // NB: strtof vs strtod.
> inline float
> stof(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
> +#endif
>
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx);
> }
> @@ -4161,7 +4163,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return std::stod(__str, __idx); }
> -#endif // _GLIBCXX_USE_C99_STDLIB
> +#endif
We get this error with the above:
bash-5.1$ gcc/xg++ -Bgcc/ -o xxx xxx.cc
-I./hppa64-hp-hpux11.11/libstdc++-v3/include
-I./hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-Lhppa64-hp-hpux11.11/libstdc++-v3/src/.libs -O2
In file included from ./hppa64-hp-hpux11.11/libstdc++-v3/include/string:54,
from xxx.cc:1:
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function
'long double std::__cxx11::stold(const std::string&, std::size_t*)':
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error:
'strtold' is not a member of 'std'; did you mean 'strtoll'?
4161 | { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(),
__idx); }
| ^~~
| strtoll
[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841 pkoning at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-07-13 Status|UNCONFIRMED |ASSIGNED CC||pkoning at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110206 --- Comment #15 from Uroš Bizjak --- Created attachment 55537 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55537=edit Proposed patch. v2 patch in testing. This version prevents emission of invalid REG_EQUAL note in cprop.cc/try_replace_reg when original, non-simplified RTX contains SUBREG. The patch is in effect an one-liner: @@ -795,7 +796,8 @@ try_replace_reg (rtx from, rtx to, rtx_insn *insn) /* If we've failed perform the replacement, have a single SET to a REG destination and don't yet have a note, add a REG_EQUAL note to not lose information. */ - if (!success && note == 0 && set != 0 && REG_P (SET_DEST (set))) + if (!success && note == 0 && set != 0 && REG_P (SET_DEST (set)) + && !contains_paradoxical_subreg_p (SET_SRC (set))) note = set_unique_reg_note (insn, REG_EQUAL, copy_rtx (src)); } but we have to move contains_paradoxical_subreg_p to rtlanal.cc.
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 --- Comment #7 from anlauf at gcc dot gnu.org --- The fix for FINDLOC also fixes the same regression for MINLOC, MAXLOC. There is another issue for MINVAL and MAXVAL that exists already in 10-branch, thus not a regression. I get at runtime: a.out: ../../../gcc-10/libgfortran/generated/maxval0_s1.c:68: maxval0_s1: Assertion `xlen == len' failed. Thus should be tracked separately.
[Bug libstdc++/78710] suggest better exception text for stoi, stol, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78710 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #5 from Jonathan Wakely ---
(In reply to dave.anglin from comment #3)
> On 2023-07-13 9:46 a.m., redi at gcc dot gnu.org wrote:
> > Dave, does this patch work for hppa64-hp-hpux11.11 ?
> Yes.
Great - pushed to trunk.
> On hpux, double and long double have different representations (they are
> same on linux). hpux11.11 has both
> strtod and strtold. strtold is checked for:
>
> /* Define to 1 if you have the `strtof' function. */
> /* #undef HAVE_STRTOF */
>
> /* Define to 1 if you have the `strtold' function. */
> #define HAVE_STRTOLD 1
Ah yes. That comes from libstdc++-v3/linkage.m4 which I think I've never even
looked at before!
> There doesn't seem to be a configure check for strtod.
That's from C89 and we already assume that's available unconditionally e.g. for
this code in :
using ::strtod;
using ::strtol;
using ::strtoul;
I'm testing this, which should define std::stof and std::stold for hpux11.11:
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4148,12 +4148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
stod(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
-#if _GLIBCXX_USE_C99_STDLIB
+#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOF
// NB: strtof vs strtod.
inline float
stof(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
+#endif
+#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
inline long double
stold(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx); }
@@ -4161,7 +4163,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
inline long double
stold(const string& __str, size_t* __idx = 0)
{ return std::stod(__str, __idx); }
-#endif // _GLIBCXX_USE_C99_STDLIB
+#endif
// DR 1261. Insufficent overloads for to_string / to_wstring
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a1d12752f8d45df5d7962cef6e2a87585002e982 commit r14-2504-ga1d12752f8d45df5d7962cef6e2a87585002e982 Author: Jonathan Wakely Date: Thu Jul 13 10:44:57 2023 +0100 libstdc++: std::stoi etc. do not need C99 support [PR110653] std::stoi, std::stol, std::stoul, and std::stod only depend on C89 functions, so don't need to be guarded by _GLIBCXX_USE_C99_STDLIB std::stoll and std::stoull don't need C99 strtoll and strtoull if sizeof(long) == sizeof(long long). std::stold doesn't need C99 strtold if DBL_MANT_DIG == LDBL_MANT_DIG. This only applies to the narrow character overloads, the wchar_t overloads depend on a separate _GLIBCXX_USE_C99_WCHAR macro and none of them can be implemented in C89 easily. libstdc++-v3/ChangeLog: PR libstdc++/110653 * include/bits/basic_string.h (stoi, stol, stoul, stod): Do not depend on _GLIBCXX_USE_C99_STDLIB. [__LONG_WIDTH__ == __LONG_LONG_WIDTH__] (stoll, stoull): Define in terms of stol and stoul respectively. [__DBL_MANT_DIG__ == __LDBL_MANT_DIG__] (stold): Define in terms of stod.
[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Uroš Bizjak --- Thanks for helping with tests! Fixed for gcc-12.4+
[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966 --- Comment #16 from CVS Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:4520e2dbc73262028ad556f732871565101ef615 commit r12-9770-g4520e2dbc73262028ad556f732871565101ef615 Author: Uros Bizjak Date: Thu Jul 13 18:32:15 2023 +0200 alpha: Fix computation mode in alpha_emit_set_long_cost [PR106966] PR target/106966 gcc/ChangeLog: * config/alpha/alpha.cc (alpha_emit_set_long_const): Always use DImode when constructing long const. gcc/testsuite/ChangeLog: * gcc.target/alpha/pr106966.c: New test. (cherry picked from commit 337649c1660211db733c1ba34ae260b8c66a3578)
[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966 --- Comment #15 from CVS Commits --- The releases/gcc-13 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:27e421319efcf47280339fbc17c263f36c92eee6 commit r13-7561-g27e421319efcf47280339fbc17c263f36c92eee6 Author: Uros Bizjak Date: Thu Jul 13 18:32:15 2023 +0200 alpha: Fix computation mode in alpha_emit_set_long_cost [PR106966] PR target/106966 gcc/ChangeLog: * config/alpha/alpha.cc (alpha_emit_set_long_const): Always use DImode when constructing long const. gcc/testsuite/ChangeLog: * gcc.target/alpha/pr106966.c: New test. (cherry picked from commit 337649c1660211db733c1ba34ae260b8c66a3578)
[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966 --- Comment #14 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:337649c1660211db733c1ba34ae260b8c66a3578 commit r14-2503-g337649c1660211db733c1ba34ae260b8c66a3578 Author: Uros Bizjak Date: Thu Jul 13 18:32:15 2023 +0200 alpha: Fix computation mode in alpha_emit_set_long_cost [PR106966] PR target/106966 gcc/ChangeLog: * config/alpha/alpha.cc (alpha_emit_set_long_const): Always use DImode when constructing long const. gcc/testsuite/ChangeLog: * gcc.target/alpha/pr106966.c: New test.
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 Jose E. Marchesi changed: What|Removed |Added Last reconfirmed||2023-07-13 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Jose E. Marchesi --- Thanks. Confirmed with master bpf-unknown-gcc: stxb[%fp+-20],%r7 ldxw%r7,[%fp+-20]
[Bug preprocessor/110655] incorrect position of indicator in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110655 Andrew Pinski changed: What|Removed |Added Component|c++ |preprocessor --- Comment #1 from Andrew Pinski --- It points to the start of the identifier rather than the position of the character
[Bug c/110654] inconsistent error message in presence of unexpected encoded characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654
--- Comment #1 from Andrew Pinski ---
libccp has:
/* In C++, this is an error for invalid character in an identifier
because logically, the UTF-8 was converted to a UCN during
translation phase 1 (even though we don't physically do it that
way). In C, this byte rather becomes grammatically a separate
token. */
if (CPP_OPTION (pfile, cplusplus))
cpp_error (pfile, CPP_DL_ERROR,
"extended character %.*s is not valid in an identifier",
(int) (*pstr - base), base);
else
{
*pstr = base;
return false;
}
So this is due to differences in the languages themselves rather than due to C
vs C++ front-end ...
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 --- Comment #2 from Kris Van Hees --- Created attachment 55536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55536=edit Pre-processed source file
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 Jose E. Marchesi changed: What|Removed |Added CC||jemarch at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jemarch at gcc dot gnu.org --- Comment #1 from Jose E. Marchesi --- Can you please provide a pre-processed version of the reproducer? Thanks.
[Bug target/110657] New: BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 Bug ID: 110657 Summary: BPF verifier rejects generated code due to invalid stack access Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kris.van.hees at oracle dot com Target Milestone: --- Created attachment 55535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55535=edit C source code file for BPF function The attached BPF program compiles into code that the BPF kernel verifier rejects because of invalid stack access. Code is compiled with: bpf-gcc -gbtf -D__amd64 -Ilibdtrace -Iinclude -I/scratch/dtrace-bpf-user/build/include -O2 -Wall -Wno-unknown-pragmas -MP -MMD -MF /scratch/dtrace-bpf-user/build/bpf--inet_ntoa6.o.deps -MT /scratch/dtrace-bpf-user/build/bpf--inet_ntoa6.o -c -o /scratch/dtrace-bpf-user/build/bpf--inet_ntoa6.o bpf/inet_ntoa6.c The bpf/inet_ntoa6.c code is attached (incomplete implementation of the function but exhibiting the issue). The function gets included in a larger program so instruction numbers are much higher than in e.g. objdump output. Function entry point is at instruction 2432. The BPF verifier output is: BPF: 2432: (7b) *(u64 *)(r10 -32) = r1 ; frame2: R1_w=map_value(off=0,ks=4,vs=528,umin=8,umax=263,var_off=(0x0; 0x1ff),s32_min=0,s32_max=511,u32_max=511) R10=fp0 fp-32_w=map_value BPF: 2433: (bf) r6 = r2; frame2: R2_w=map_value(off=2208,ks=4,vs=3529,imm=0) R6_w=map_value(off=2208,ks=4,vs=3529,imm=0) BPF: 2434: (bf) r3 = r1; frame2: R1_w=map_value(off=0,ks=4,vs=528,umin=8,umax=263,var_off=(0x0; 0x1ff),s32_min=0,s32_max=511,u32_max=511) R3_w=map_value(off=0,ks=4,vs=528,umin=8,umax=263,var_off=(0x0; 0x1ff),s32_min=0,s32_max=511,u32_max=511) BPF: 2435: (b7) r2 = 16; frame2: R2_w=P16 BPF: 2436: (bf) r1 = r10 ; frame2: R1_w=fp0 R10=fp0 BPF: 2437: (07) r1 += -16 ; frame2: R1_w=fp-16 BPF: 2438: (85) call bpf_probe_read#4 ; frame2: R0=Pscalar() fp-8= fp-16= BPF: 2439: (71) r0 = *(u8 *)(r10 -14) ; frame2: R0_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2440: (67) r0 <<= 8 ; frame2: R0_w=Pscalar(umax=65280,var_off=(0x0; 0xff00)) BPF: 2441: (71) r1 = *(u8 *)(r10 -13) ; frame2: R1_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2442: (4f) r0 |= r1 ; frame2: R0_w=Pscalar() R1_w=Pscalar(umax=255,var_off=(0x0; 0xff)) BPF: 2443: (71) r8 = *(u8 *)(r10 -12) ; frame2: R8_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2444: (67) r8 <<= 8 ; frame2: R8_w=Pscalar(umax=65280,var_off=(0x0; 0xff00)) BPF: 2445: (71) r2 = *(u8 *)(r10 -11) ; frame2: R2_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2446: (4f) r8 |= r2 ; frame2: R2_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R8_w=Pscalar() BPF: 2447: (71) r7 = *(u8 *)(r10 -10) ; frame2: R7_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2448: (67) r7 <<= 8 ; frame2: R7_w=Pscalar(umax=65280,var_off=(0x0; 0xff00)) BPF: 2449: (71) r3 = *(u8 *)(r10 -9) ; frame2: R3_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2450: (4f) r7 |= r3 ; frame2: R3_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R7_w=Pscalar() BPF: 2451: (7b) *(u64 *)(r10 -40) = r7 ; frame2: R7_w=Pscalar() R10=fp0 fp-40_w= BPF: 2452: (71) r1 = *(u8 *)(r10 -8) ; frame2: R1_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2453: (67) r1 <<= 8 ; frame2: R1_w=Pscalar(umax=65280,var_off=(0x0; 0xff00)) BPF: 2454: (71) r4 = *(u8 *)(r10 -7) ; frame2: R4_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2455: (4f) r1 |= r4 ; frame2: R1_w=Pscalar() R4_w=Pscalar(umax=255,var_off=(0x0; 0xff)) BPF: 2456: (71) r3 = *(u8 *)(r10 -6) ; frame2: R3_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2457: (67) r3 <<= 8 ; frame2: R3_w=Pscalar(umax=65280,var_off=(0x0; 0xff00)) BPF: 2458: (71) r5 = *(u8 *)(r10 -5) ; frame2: R5_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2459: (4f) r3 |= r5 ; frame2: R3_w=Pscalar() R5_w=Pscalar(umax=255,var_off=(0x0; 0xff)) BPF: 2460: (71) r4 = *(u8 *)(r10 -4) ; frame2: R4_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2461: (67) r4 <<= 8 ; frame2: R4_w=Pscalar(umax=65280,var_off=(0x0; 0xff00)) BPF: 2462: (71) r2 = *(u8 *)(r10 -3) ; frame2: R2_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2463: (4f) r4 |= r2 ; frame2: R2_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R4_w=Pscalar() BPF: 2464: (71) r5 = *(u8 *)(r10 -2) ; frame2: R5_w=Pscalar(umax=255,var_off=(0x0; 0xff)) R10=fp0 BPF: 2465: (67) r5 <<= 8 ; frame2:
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 --- Comment #1 from Andrew Pinski --- new_temp does look like it is initialized on the !costing_p path too ..
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #3 from dave.anglin at bell dot net ---
On 2023-07-13 9:46 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #2 from Jonathan Wakely ---
> Created attachment 55534
>--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55534=edit
> libstdc++: std::stoi etc. do not need C99 support
>
> Dave, does this patch work for hppa64-hp-hpux11.11 ?
Yes.
>
> It should allow you to compile + run the code below:
>
> #include
> int main()
> {
>std::string z = "0";
>return std::stoi(z) + std::stol(z) + std::stoul(z) + std::stoll(z)
> + std::stoull(z) + std::stod(z);
> }
The above code compiles and runs successfully on hppa64-hp-hpux11.11 with the
patch.
>
> I'm not sure if double and long double are the same representation on this
> target, but if they are then std::stold("0.0") should work too.
Adding std::stold("0.0") to test, we get:
bash-5.1$ gcc/xg++ -Bgcc/ -o xxx xxx.cc
-I./hppa64-hp-hpux11.11/libstdc++-v3/include
-I./hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-Lhppa64-hp-hpux11.11/libstdc++-v3/src/.libs -O2
xxx.cc: In function 'int main()':
xxx.cc:6:48: error: 'stold' is not a member of 'std'
6 | + std::stoull(z) + std::stod(z) + std::stold("0.0");
| ^
xxx.cc:2:1: note: 'std::stold' is defined in header ''; this is
probably fixable by adding '#include '
1 | #include
+++ |+#include
2 | int main()
On hpux, double and long double have different representations (they are same
on linux). hpux11.11 has both
strtod and strtold. strtold is checked for:
/* Define to 1 if you have the `strtof' function. */
/* #undef HAVE_STRTOF */
/* Define to 1 if you have the `strtold' function. */
#define HAVE_STRTOLD 1
There doesn't seem to be a configure check for strtod.
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||build, diagnostic
[Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- CCing Martin, I don't have sufficient experience with IPA SRA nor IPA CP to be able to handle this.
[Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Last reconfirmed||2023-07-13
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Jason Merrill ---
Note that the __builtin_unreachable variant is optimized as expected:
struct S { bool x; };
void do_something();
void fn(S s) {
if (s.x) __builtin_unreachable ();
if (s.x) do_something();
}
It's unfortunate that [[assume (x)]] is currently so much less useful than if
(!x) __builtin_unreachable(), which expresses almost the same thing.
[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293 --- Comment #7 from Andrew Pinski --- Half of this is fixed now.
[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:285c9d042e90a7425b37697edc9ec93a1b03b486 commit r14-2501-g285c9d042e90a7425b37697edc9ec93a1b03b486 Author: Andrew Pinski Date: Wed Jul 12 00:33:14 2023 -0700 Fix part of PR 110293: `A NEEQ (A NEEQ CST)` part This fixes part of PR 110293, for the outer comparison case being `!=` or `==`. In turn PR 110539 is able to be optimized again as the if statement for `(a&1) == ((a & 1) != 0)` gets optimized to `false` early enough to allow FRE/DOM to do a CSE for memory store/load. OK? Bootstrapped and tested on x86_64-linux with no regressions. gcc/ChangeLog: PR tree-optimization/110293 PR tree-optimization/110539 * match.pd: Expand the `x != (typeof x)(x == 0)` pattern to handle where the inner and outer comparsions are either `!=` or `==` and handle other constants than 0. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr110293-1.c: New test. * gcc.dg/tree-ssa/pr110539-1.c: New test. * gcc.dg/tree-ssa/pr110539-2.c: New test. * gcc.dg/tree-ssa/pr110539-3.c: New test. * gcc.dg/tree-ssa/pr110539-4.c: New test.
[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:285c9d042e90a7425b37697edc9ec93a1b03b486 commit r14-2501-g285c9d042e90a7425b37697edc9ec93a1b03b486 Author: Andrew Pinski Date: Wed Jul 12 00:33:14 2023 -0700 Fix part of PR 110293: `A NEEQ (A NEEQ CST)` part This fixes part of PR 110293, for the outer comparison case being `!=` or `==`. In turn PR 110539 is able to be optimized again as the if statement for `(a&1) == ((a & 1) != 0)` gets optimized to `false` early enough to allow FRE/DOM to do a CSE for memory store/load. OK? Bootstrapped and tested on x86_64-linux with no regressions. gcc/ChangeLog: PR tree-optimization/110293 PR tree-optimization/110539 * match.pd: Expand the `x != (typeof x)(x == 0)` pattern to handle where the inner and outer comparsions are either `!=` or `==` and handle other constants than 0. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr110293-1.c: New test. * gcc.dg/tree-ssa/pr110539-1.c: New test. * gcc.dg/tree-ssa/pr110539-2.c: New test. * gcc.dg/tree-ssa/pr110539-3.c: New test. * gcc.dg/tree-ssa/pr110539-4.c: New test.
[Bug middle-end/109520] compiler never terminates with an inline-asm goto and an output with high register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109520 --- Comment #5 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:b175b4887f928118af997f6d4d75097a64dcec5d commit r14-2500-gb175b4887f928118af997f6d4d75097a64dcec5d Author: Vladimir N. Makarov Date: Thu Jul 13 10:42:17 2023 -0400 [RA][PR109520]: Catch error when there are no enough registers for asm insn Asm insn unlike other insns can have so many operands whose constraints can not be satisfied. It results in LRA cycling for such test case. The following patch catches such situation and reports the problem. PR middle-end/109520 gcc/ChangeLog: * lra-int.h (lra_insn_recog_data): Add member asm_reloads_num. (lra_asm_insn_error): New prototype. * lra.cc: Include rtl_error.h. (lra_set_insn_recog_data): Initialize asm_reloads_num. (lra_asm_insn_error): New func whose code is taken from ... * lra-assigns.cc (lra_split_hard_reg_for): ... here. Use lra_asm_insn_error. * lra-constraints.cc (curr_insn_transform): Check reloads nummber for asm. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109520.c: New test.
[Bug c/110656] Floating point to char/short or bitfield conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110656 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=27682 --- Comment #1 from Andrew Pinski --- See pr 27682 for the non trapping question.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #2 from Jonathan Wakely ---
Created attachment 55534
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55534=edit
libstdc++: std::stoi etc. do not need C99 support
Dave, does this patch work for hppa64-hp-hpux11.11 ?
It should allow you to compile + run the code below:
#include
int main()
{
std::string z = "0";
return std::stoi(z) + std::stol(z) + std::stoul(z) + std::stoll(z)
+ std::stoull(z) + std::stod(z);
}
I'm not sure if double and long double are the same representation on this
target, but if they are then std::stold("0.0") should work too.
[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966 --- Comment #13 from Matthias Klose --- search for "test-summary" https://buildd.debian.org/status/logs.php?pkg=gcc-12=alpha 12.3.0-5 is gcc-12 branch 20230630 12.3.0-6 is gcc-12 branch 20230707 with the proposed patch applied comparing gcc summary (-5 to -6): === gcc Summary === # of expected passes136199 # of unexpected failures657 # of unexpected successes 16 # of expected failures 1112 # of unresolved testcases 8 # of unsupported tests 2539 /<>/build/gcc/xgcc version 12.3.0 (Debian 12.3.0-5) === gcc Summary === # of expected passes136261 # of unexpected failures652 # of unexpected successes 16 # of expected failures 1112 # of unresolved testcases 8 # of unsupported tests 2539 /<>/build/gcc/xgcc version 12.3.0 (Debian 12.3.0-6)
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #3 from Jan Hubicka --- > -fdump-tree-all-blocks-details produced more than 100 dump files. Which > one(s) > do you want? Can you just zip them an attach all? Thank you! Honza
[Bug c/110656] New: Floating point to char/short or bitfield conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110656
Bug ID: 110656
Summary: Floating point to char/short or bitfield conversions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
While implementing floating point to _BitInt convertions, I'm wondering if it
is correct that we implement say float -> signed char conversion effectively as
float -> int -> signed char.
signed char foo (float x) { return x; }
with foo (512.0f).
ISO C17 has in F.4 says
"or if the integral part of the floating value
exceeds the range of the integer type, then the “invalid” floating-point
exception is raised and the resulting value is unspecified."
but we even with -ftrapping-math trigger invalid say for 8589934592.0f (when it
doesn't fit into int), but the above just does
cvttss2sil %xmm0, %eax
movsbl %al, %eax
on x86_64.
In the scope of _BitInt, I wonder if I should care, i.e. whether I should call
say a library routine for floating point to _BitInt(N)/unsigned _BitInt(N)
conversions when
N is smaller than bit width of __int128 (if it exists, long long otherwise) and
is not equal to width of int, long or long long, or if I can implement those
like it is implemented for char/short and bitfields.
I guess for now I'll try to implement the library side so that it handles
correctly all valid Ns and we can decide on the compiler side later.
[Bug c++/110655] New: incorrect position of indicator in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110655
Bug ID: 110655
Summary: incorrect position of indicator in error message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take this source and run it through a trunk version or earlier of the C++
frontend.
#include
int main() {
puts(“hello world”);
return 0;
}
This is the same code as in BZ 110654 but shows a different, frontend-specific
problem.
The output is:
u.c:3:8: error: extended character “ is not valid in an identifier
3 | puts(“hello world”);
|^
u.c:3:15: error: extended character ” is not valid in an identifier
3 | puts(“hello world”);
| ^
u.c: In function ‘int main()’:
u.c:3:8: error: ‘“hello’ was not declared in this scope
3 | puts(“hello world”);
|^~
The problem is the second error message. It should report the U201d character
at what would be the end of the string but it column indicator points to the
second word in the string.
If you want to go further down the rathole of this example, the first error
message says that U201c is not valid in an identifer which is of course
correct. But then gcc neverthess adds it in front of the supposed identifier
which extends to the end of the first word of the string. See the last error
message which says that “hello is not a valid identifier. This is
inconsistent.
[Bug c/110654] New: inconsistent error message in presence of unexpected encoded characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654
Bug ID: 110654
Summary: inconsistent error message in presence of unexpected
encoded characters
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drepper.fsp+rhbz at gmail dot com
Target Milestone: ---
Take this code which in a similar form was taken from a text document where the
smart quote handling used the U201c and U201d characters instead of simple
ASCII double quotes. Note, this text should be encoded in UTF-8 and the
environment of the compiler must use UTF-8 as well.
#include
int main() {
puts(“hello world”);
return 0;
}
Compiling this with a recent gcc 13 or older versions leads to these error
messages:
u.c: In function ‘main’:
u.c:3:8: error: stray ‘\342’ in program
3 | puts(hello world);
|^~~~
u.c:3:9: error: ‘hello’ undeclared (first use in this function); did you mean
‘ftello’?
3 | puts(“hello world”);
| ^
| ftello
u.c:3:9: note: each undeclared identifier is reported only once for each
function it appears in
u.c:3:14: error: expected ‘)’ before ‘world’
3 | puts(“hello world”);
| ~ ^~
| )
u.c:3:20: error: stray ‘\342’ in program
3 | puts(hello world);
| ^~~~
The problem is the initial message about "stray ‘\342’" and the notation used
in the context line. In the later the byte is correctly recognized as being
part on an UTF-8 character.
Note that this is in contrast to the C++ frontend which handles this correctly.
It shows:
u.c:3:8: error: extended character “ is not valid in an identifier
3 | puts(“hello world”);
|^
The C frontend should adopt the same code as the C++ frontend.
[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > I'll split out the checks needed for std::stoi etc. See Bug 110653 for the library improvements.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-07-13 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- std::stoi, std::stol and stoul only depend on strtol and strtoul which are in C89, so don't need to be guarded by _GLIBCXX_USE_C99_STDLIB std::stoll and std::stoull can be implemented without C99 strtoll and strtoull if sizeof(long) == sizeof(long long). std::stod only depends on strtod which is in C89. std::stold can be implemented without C99 strtold if DBL_MANT_DIG == LDBL_MANT_DIG.
[Bug libstdc++/110653] New: Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 Bug ID: 110653 Summary: Support std::stoi etc. without C99 APIs 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 CC: danglin at gcc dot gnu.org, redi at gcc dot gnu.org, unassigned at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 +++ This bug was initially created as a clone of Bug #110646 +++ g++ -std=c++11 -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwi nd-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmiss ing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include \ -o build/gensupport.o ../../gcc/gcc/gensupport.cc ../../gcc/gcc/gensupport.cc: In constructor 'conlist::conlist(const char*, unsigned int, bool)': ../../gcc/gcc/gensupport.cc:643:18: error: 'stoi' is not a member of 'std'; did you mean 'atoi'? 643 | idx = std::stoi (name); | ^~~~ | atoi Build gcc is: gcc version 12.2.1 20230420 [remotes/origin/releases/gcc-12 r12-9449-g3907147aa9 b] (GCC) libstdc++ provides std::stoi in basic_string.h when _GLIBCXX_USE_C99_STDLIB is 1. However, hpux11.11 lacks all the routines needed when _GLIBCXX_USE_C99_STDLIB is 1. But it does have strtol, atol, atoi, strtoul, strtod and atof. strtoll and strtoull are not needed on hppa64 as long long and long are equivalent. So it seems the string conversion routines could be provided in basic_string.h for this target.
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Sandoe --- > (In reply to Rainer Orth from comment #0) >> When bootstrapping current trunk on macOS 14.0 beta 3 with Xcode 15 beta 4, >> every single fortran link test FAILs like > >> * Get rid of %(libgcc) in libgfortran.spec.in. >> >> * Include it conditionally depending on a configure test. > > Hmm .. I thought we already had configure tests to customise the spec for > Darwin? > FX? We do: @LIBM@ is handled that way. >> * Disable ld warnings with -w in the spec, probably using some >> @TARGET_LDFLAGS@. >> >> * Disable ld warnings globally in the Darwin driver code. That may be >> undisable since it would disable possibly benign warnings, too. > > I think we need to fix the specs not work around with disabled warnings. Agreed: for me modifying the spec was a quick hack to avoid half the failures in the testsuite run.
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 --- Comment #1 from Iain Sandoe --- (In reply to Rainer Orth from comment #0) > When bootstrapping current trunk on macOS 14.0 beta 3 with Xcode 15 beta 4, > every single fortran link test FAILs like > * Get rid of %(libgcc) in libgfortran.spec.in. > > * Include it conditionally depending on a configure test. Hmm .. I thought we already had configure tests to customise the spec for Darwin? FX? > * Disable ld warnings with -w in the spec, probably using some > @TARGET_LDFLAGS@. > > * Disable ld warnings globally in the Darwin driver code. That may be > undisable since it would disable possibly benign warnings, too. I think we need to fix the specs not work around with disabled warnings.
[Bug tree-optimization/110652] New: [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 Bug ID: 110652 Summary: [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Noticed build failure today when built r14-2495-g43ed05a08963a5 as: $ ~/dev/git/gcc/configure --disable-multilib --enable-checking=release $ make ... /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o tree-vect-stmts.o -MT tree-vect-stmts.o -MMD -MP -MF ./.deps/tree-vect-stmts.TPo /home/slyfox/dev/git/gcc/gcc/tree-vect-stmts.cc In file included from /home/slyfox/dev/git/gcc/gcc/hash-table.h:248, from /home/slyfox/dev/git/gcc/gcc/coretypes.h:486, from /home/slyfox/dev/git/gcc/gcc/tree-vect-stmts.cc:24: In member function 'T* vec::quick_push(const T&) [with T = tree_node*; A = va_heap]', inlined from 'T* vec::quick_push(const T&) [with T = tree_node*]' at /home/slyfox/dev/git/gcc/gcc/vec.h:1987:28, inlined from 'bool vectorizable_load(vec_info*, stmt_vec_info, gimple_stmt_iterator*, gimple**, slp_tree, stmt_vector_for_cost*)' at /home/slyfox/dev/git/gcc/gcc/tree-vect-stmts.cc:10962:23: /home/slyfox/dev/git/gcc/gcc/vec.h:1023:9: error: 'new_temp' may be used uninitialized [-Werror=maybe-uninitialized] 1023 | *slot = obj; | ~~^ $ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v Reading specs from /tmp/gb/./prev-gcc/specs COLLECT_GCC=/tmp/gb/./prev-gcc/xg++ COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230713 (experimental) (GCC)
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libfortran/110651] New: libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
Bug ID: 110651
Summary: libgfortran.spec links twice with libgcc spec
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, fxcoudert at gcc dot gnu.org,
iains at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-apple-darwin23.0.0
Target: x86_64-apple-darwin23.0.0
Build: x86_64-apple-darwin23.0.0
When bootstrapping current trunk on macOS 14.0 beta 3 with Xcode 15 beta 4,
every single fortran link test FAILs like
FAIL: gfortran.dg/c-interop/allocatable-dummy.f90 -O0 (test for excess
errors)
Excess errors:
ld: warning: ignoring duplicate library '-lemutls_w'
ld: warning: ignoring duplicate library '-lgcc'
The link line ends in
-lgfortran -lemutls_w -lgcc -lquadmath -lemutls_w -lgcc -lSystem
-no_compact_unwind -idsym -dsym
I could trace this to libgfortran.spec, which has
%rename lib liborig
*lib: %{static-libquadmath:libquadmath.a%s;:-lquadmath} %(libgcc) %(liborig)
The libgcc spec is included twice, once explicitly here and another time in
%(liborig). I have no idea why this is done this way: this already was in
the original patch that introduced libgfortran.spec.in:
commit 1ec601bf9fb0fbc39b3a6cb90450500f857adae8
Author: Francois-Xavier Coudert
Date: Tue Nov 16 21:23:19 2010 +
re PR fortran/32049 (Support on x86_64 also kind=16)
I see quite a number of possible solutions:
* Get rid of %(libgcc) in libgfortran.spec.in.
* Include it conditionally depending on a configure test.
* Disable ld warnings with -w in the spec, probably using some
@TARGET_LDFLAGS@.
* Disable ld warnings globally in the Darwin driver code. That may be
undisable since it would disable possibly benign warnings, too.
[Bug target/110624] Xcode 15 ld warns about -macosx_version_min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Iain Sandoe --- > Here, I will test on some earlier Darwin versions - but would welcome > confirmation that it fixes the XC15 issue. I've done that now and could successfully bootstrap on macOS 14.0 beta 3 with Xcode 15 beta 4. Thanks for the patch, especially since my patch series to consistently prune the ld warning provded to be a can of worms. I needed one patch to link m2/boot-bin/mklink with -static-libstdc++ (to be submitted shortly). However, there's an enormous number of issues compared to macOS 14.0 beta 2/Xcode 15 beta 2, in particular all (?) EH-related execution tests failing, and all gfortran tests failing due to ld warnings about duplicate libraries (will submit a PR for that).
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #9 from Mathieu Malaterre --- (In reply to Richard Biener from comment #8) > I wonder if you can try a recent GCC 13 snapshot or the head of the branch > and also confirm with GCC 14 trunk? Could you suggest a docker image I could use ? $ docker run -it
