https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850
Matteo Italia changed:
What|Removed |Added
Attachment #57372|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Richard Biener changed:
What|Removed |Added
Target|x86_64 |x86_64-*-* i?86-*-*
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885
Bug ID: 113885
Summary: ice in gimplify_expr, at gimplify.cc:18658
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113886
Bug ID: 113886
Summary: new C23 length specifier with confusing diagnostic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878
--- Comment #9 from Richard Biener ---
I'd very much appreciate getting rid of TYPE_OVERFLOW_SANITIZED checks by doing
instrumentation in the frontends.
Note we do
#define TYPE_OVERFLOW_UNDEFINED(TYPE) \
(POINTER_TY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113879
Richard Biener changed:
What|Removed |Added
Blocks||85316
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113882
Richard Biener changed:
What|Removed |Added
Blocks||53947
--- Comment #1 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #15 from Tamar Christina ---
(In reply to Sam James from comment #14)
> Created attachment 57390 [details]
> test.c
>
> I'll try reducing it preprocessed now (couldn't do it before as checking w/
> clang as well in the reduction scr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
Bug ID: 113887
Summary: no support for %w128 length modifiers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
Aldy Hernandez changed:
What|Removed |Added
CC|aldyh at redhat dot com|
--- Comment #3 from Aldy Herna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
Sam James changed:
What|Removed |Added
Attachment #57390|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #17 from Tamar Christina ---
(In reply to Sam James from comment #16)
> Created attachment 57393 [details]
> test.c
>
> OK, all done now (I figured I'd let cvise finish). No more :)
>
> By the way, this fails on arm64 too (at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64064
--- Comment #3 from Jonathan Wakely ---
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fseek-fseeki64?view=msvc-170#remarks
The only way to use _fseeki64 for text mode files is with __off=0 (and any
value of __way) or __way=be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113888
Bug ID: 113888
Summary: libm2pim/target.c doesn't assemble on 32-bit
Linux/sparc64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113888
Rainer Orth changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
--- Comment #8 from Andrew Stubbs ---
(In reply to seurer from comment #7)
> On the BE machine:
>
> seurer@nilram:~/gcc/git/build/gcc-test$ ulimit -a
> real-time non-blocking time (microseconds, -R) unlimited
> ...
> max locked memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
--- Comment #5 from Jakub Jelinek ---
That said, the math at least in the reduced testcase is weird.
%d output is at most 11 bytes - strlen ("-2147483648"), + 9 other chars, so
that
is 42, not 32. But even using + 42 in there instead of 32 does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #18 from Tamar Christina ---
Loop that gets miscompiled is the initialization loop:
while (parse_tables_n-- && i < 306)
table[i++] = 0;
and indeed, the compiler seems to also be ignori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #11 from Florian Weimer ---
(In reply to Richard Biener from comment #10)
> I think a glibc fix would be very much preferred.
It's a bit of a maintenance nightmare because we have to update the code
slightly each time new registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1e3f78dbb328a2f2db8def241372cb947d9cb7eb
commit r14-8925-g1e3f78dbb328a2f2db8def241372cb947d9cb7eb
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #13 from Jakub Jelinek ---
BTW, isn't _mcount similar in this regard?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #12 from Jakub Jelinek ---
(In reply to Florian Weimer from comment #11)
> (In reply to Richard Biener from comment #10)
> > I think a glibc fix would be very much preferred.
>
> It's a bit of a maintenance nightmare because we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #15 from Jakub Jelinek ---
Because right now it also means it needs to save/restore the APX registers
because malloc could be -mapxf compiled even when glibc isn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
--- Comment #4 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:525cfe1e9554858366e7811aa9e437357c0f272e
commit r14-8926-g525cfe1e9554858366e7811aa9e437357c0f272e
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #16 from Richard Biener ---
I do wonder why __tls_get_addr would have to call the overloaded malloc, can
we just not force-bind it to the glibc local malloc (and make sure that's
compiled with -mgeneral-regs-only)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #17 from Richard Biener ---
(In reply to Richard Biener from comment #16)
> I do wonder why __tls_get_addr would have to call the overloaded malloc, can
> we just not force-bind it to the glibc local malloc (and make sure that's
> co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #19 from Tamar Christina ---
Ok, removing all the noise shows that this is the same issue as I saw before.
The code out of the vectorizer is correct, but cunroll does a dodgee unrolling.
-fdisable-tree-cunroll confirms it's the unr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #18 from Florian Weimer ---
(In reply to Richard Biener from comment #16)
> I do wonder why __tls_get_addr would have to call the overloaded malloc, can
> we just not force-bind it to the glibc local malloc (and make sure that's
> co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65424
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #19 from H.J. Lu ---
(In reply to Florian Weimer from comment #9)
> (In reply to H.J. Lu from comment #7)
> > > The __tls_get_addr call with the default approach potentially needs to
> > > solve
> > > the same problem, doesn't it?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113889
Bug ID: 113889
Summary: Incorrect constant string value if declared in a
definition module
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92387
--- Comment #3 from Sam James ---
With trunk, I get:
```
Breakpoint 1, main () at /tmp/foo.c:11
11 c ();
$1 =
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113889
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
Tobias Burnus changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113888
Rainer Orth changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #20 from Florian Weimer ---
(In reply to H.J. Lu from comment #19)
> (In reply to Florian Weimer from comment #9)
> > (In reply to H.J. Lu from comment #7)
> > > > The __tls_get_addr call with the default approach potentially needs t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
Gaius Mulley changed:
What|Removed |Added
Attachment #57388|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #21 from H.J. Lu ---
(In reply to Florian Weimer from comment #20)
> (In reply to H.J. Lu from comment #19)
> > (In reply to Florian Weimer from comment #9)
> > > (In reply to H.J. Lu from comment #7)
> > > > > The __tls_get_addr cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #16 from Christopher Fore ---
I tried to build older snapshots as well (back to 20231119) and it seems this
assembler error still occurs back to there so I was wrong about this being a
new thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've found what's going on: as described in Solaris makecontext(3C), the
function changed starting with Solaris 10:
NOTES
The semantics of the uc_stack member of the ucontext_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
--- Comment #2 from Rainer Orth ---
Created attachment 57396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57396&action=edit
Preliminary patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
--- Comment #4 from Martin Jambor ---
Created attachment 57397
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57397&action=edit
-fopt-info-vec before/after comparison
(In reply to Richard Biener from comment #3)
> A compare before/after t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #3 from Tobias Burnus ---
Created attachment 57398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57398&action=edit
Patch - handling the libgomp issue
Possible patch - lightly tested. This fixes the issue in libgomp.
While al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113888
--- Comment #2 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:0437cbdccb91da6a8c25b2c29e9f19a9585309fc
commit r14-8928-g0437cbdccb91da6a8c25b2c29e9f19a9585309fc
Author: Rainer Orth
Date: Mon F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113888
Rainer Orth changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|gaius at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #20 from Tamar Christina ---
[local count: 21718864]:
...
_54 = (short unsigned int) bits_106;
_26 = _54 >> 9;
_88 = _139 + 7;
_89 = _88 & 7;
_111 = _26 + 10;
[local count: 181308616]:
# i_66 = PHI
# parse_table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
--- Comment #3 from Richard Biener ---
I can't confirm a regression (testing r14-8925-g1e3f78dbb328a2 with the
offending rev reverted vs bare).
462.libquantum 20720 61.9335 S 20720 62.6331 *
462.libquantum 20720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #21 from Richard Biener ---
loop->nb_iterations_upper_bound exactly is an upper bound on the number of
latch executions, so maybe I'm missing the point here. When we update it it as
well has to reflect an upper bound on that, whethe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #22 from Tamar Christina ---
(In reply to Richard Biener from comment #21)
> loop->nb_iterations_upper_bound exactly is an upper bound on the number of
> latch executions, so maybe I'm missing the point here. When we update it it
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
--- Comment #6 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:938a419182f8c43bd1212ffb98f8aa6077cf8326
commit r14-8929-g938a419182f8c43bd1212ffb98f8aa6077cf8326
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108355
--- Comment #7 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:938a419182f8c43bd1212ffb98f8aa6077cf8326
commit r14-8929-g938a419182f8c43bd1212ffb98f8aa6077cf8326
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Summary|[11/12/13/14 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113448
--- Comment #5 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:1e94648ab7b370c5867e146c7f59603e2e6ba2e6
commit r14-8930-g1e94648ab7b370c5867e146c7f59603e2e6ba2e6
Author: Rainer Orth
Date: Mon F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
--- Comment #7 from Gaius Mulley ---
Patch posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113448
Rainer Orth changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
--- Comment #6 from H.J. Lu ---
I can reproduce it with r14-8930-g1e94648ab7b370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113849
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #22 from Jakub Jelinek ---
BTW, does aarch64 dl-tlsdesc.S save SVE/SME register state (I only see fixed
offsets in there), or are those call-saved?
What about floating point registers in x86_64/dl-tlsdesc.S?
And i386/dl-tlsdesc.S nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113805
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #23 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #22)
> BTW, does aarch64 dl-tlsdesc.S save SVE/SME register state (I only see fixed
> offsets in there), or are those call-saved?
> What about floating point registers in x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
H.J. Lu changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #25 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #23)
> > And i386/dl-tlsdesc.S needs to save/restore 387 and SSE regs?
>
> i386 doesn't preserve them in _dl_runtime_resolve nor _dl_tlsdesc_dynamic.
That is different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #4 from Patrick Palka ---
r13-6421 just makes us use mce_true and mce_uknown during trial constant
evaluation of x's initialization, so my guess is before that commit the
evaluation was quickly aborted as soon as it saw a std::is_con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #6 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:5e39897ee2c73938fa940c4792d987608aeeebcd
commit r14-8931-g5e39897ee2c73938fa940c4792d987608aeeebcd
Author: Iain Sandoe
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890
Bug ID: 113890
Summary: -fdump-tree-modref ICE with _BitInt
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #5 from Patrick Palka ---
Relatedly, if we actually make x constexpr
#include
const std::size_t N = 1'000'000;
constexpr std::vector x(N);
int main() {}
we end up evaluating its expensive initialization (and hitting the constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
--- Comment #6 from Martin Jambor ---
(In reply to Richard Biener from comment #5)
> CCing also Martin who should know how/why IPA SRA doesn't reconstruct the
> component ref chain here
I have not had a look at this specific case (yet), but IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #6 from Jakub Jelinek ---
Should we really be reaching the limits for cases like this?
I mean, all the default ctors produce the same value here and we could figure
out that
they are in no way dependent on the exact position of the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113879
--- Comment #2 from Andrew Macleod ---
Not so much a cycle issue as a backward propagation issue.
:
goto ; [INV]
:
_1 = (long unsigned int) j_10;
<..>
if (j_10 >= -1)
goto ; [INV]
else
goto ; [INV]
:
__builtin_trap (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #23 from Tamar Christina ---
small standalone reducer:
#include
#include
#include
#define N 306
#define NEEDLE 136
__attribute__ ((noipa, noinline))
int use(int x[N])
{
printf("res=%d\n", x[NEEDLE]);
return x[NEEDLE];
}
__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113758
--- Comment #1 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:3c57b1c12a8e34d50bdf6aaf44146760db6d1b33
commit r14-8933-g3c57b1c12a8e34d50bdf6aaf44146760db6d1b33
Author: Iain Buclaw
Date: Sun F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113667
--- Comment #1 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:160f3f31fe106741b7c95b3663e6794e6abc7fd8
commit r14-8936-g160f3f31fe106741b7c95b3663e6794e6abc7fd8
Author: Iain Buclaw
Date: Mon F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #15 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:2dde675ff48600188d3e892d191a2345bad2e6ae
commit r14-8934-g2dde675ff48600188d3e892d191a2345bad2e6ae
Author: Iain Buclaw
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113125
--- Comment #1 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:b0efb1c35724e3332ee5993976efb98200c1a154
commit r14-8935-gb0efb1c35724e3332ee5993976efb98200c1a154
Author: Iain Buclaw
Date: Mon F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113667
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113852
--- Comment #7 from Zachary L ---
(In reply to Richard Biener from comment #6)
> Well, given athat a1 * a2 is carried out in 'int' you are invoking undefined
> behavior if it overflows. GCC assumes that doesn't happen so it's correct
> to elide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #8 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #7)
> g++ emits 4 errors on
> struct S
> {
> void foo () {}
> void bar () {};
> void baz () = delete;
> void qux () = delete;
> ;
> void corge () = delete;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #9 from Marek Polacek ---
And:
-pedantic-errors -> errors only in C++03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #2 from Joseph S. Myers ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643237.html has my notes
on things that need supporting, in , and by implication
in printf and scanf, to support __int128 as an extended integer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #26 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #25)
> (In reply to H.J. Lu from comment #23)
> > > And i386/dl-tlsdesc.S needs to save/restore 387 and SSE regs?
> >
> > i386 doesn't preserve them in _dl_runtime_resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #27 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #26)
> Even if I compile ia32 glibc with -march=skylake, the _dl_tlsdesc_dynamic
> slow
> path doesn't touch XMM registers at all.
I thought Florian said it can call mallo
1 - 100 of 169 matches
Mail list logo
