https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #4 from Jens Gustedt ---
(In reply to Joseph S. Myers from comment #2)
This is not about the question if the C library supports these types
as `uint128_t`. This is primarily to provide `printf` etc *interface*
support for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
Zhendong Su changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822
--- Comment #2 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645448.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:6caec7d9ec37e60e718a12934c85bac9c12757ac
commit r14-8947-g6caec7d9ec37e60e718a12934c85bac9c12757ac
Author: Steve Kargl
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #24 from Tamar Christina ---
The case I thought would go wrong with the above fix is:
#include
#include
#include
#define N 306
#define NEEDLE 135
__attribute__ ((noipa, noinline))
int use(int x[N])
{
printf("res=%d\n",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #38 from H.J. Lu ---
The new glibc patch set covers both i386 and x86-64:
https://patchwork.sourceware.org/project/glibc/list/?series=30854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107538
--- Comment #6 from Orion Poplawski ---
Any progress on determining whether or not this is a valid assertion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897
Bug ID: 113897
Summary: Consecutive tab edits in format are not processed
correctly.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #13 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jerry DeLisle
:
https://gcc.gnu.org/g:d85a658402d5433ff223ce8f4e70174ed8a20428
commit r13-8322-gd85a658402d5433ff223ce8f4e70174ed8a20428
Author: Jerry DeLisle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
Amyspark changed:
What|Removed |Added
CC||amy at amyspark dot me
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #14 from Marek Polacek ---
My current patch appears to handle that correctly:
$ ./cc1plus -quiet q.C -pedantic-errors -std=c++98 -Wno-error=extra-semi
q.C:3:3: warning: extra ‘;’ outside of a function only allowed in C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #13 from Harald van Dijk ---
(In reply to Marek Polacek from comment #12)
> Thank for your comment. In the end I went with
>
> -std=c++03 -pedantic-errors -Wextra-semi -> warnings
> -std=c++03 -pedantic -Wextra-semi -> warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 111022, which changed state.
Bug 111022 Summary: ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #37 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jerry DeLisle
:
https://gcc.gnu.org/g:fbe5e908de76aa240bbcd2f144c156eccc863604
commit r13-8321-gfbe5e908de76aa240bbcd2f144c156eccc863604
Author: Jerry DeLisle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Andrew Pinski changed:
What|Removed |Added
Summary|[12 Regression] Assigning |[12 Regression] Assigning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
Summary|Assigning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Bug ID: 113896
Summary: Assigning array elements in the wrong order after
floating point optimization
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #12 from Marek Polacek ---
Thank for your comment. In the end I went with
-std=c++03 -pedantic-errors -Wextra-semi -> warnings
-std=c++03 -pedantic -Wextra-semi -> warnings (not pedwarn)
based on the principle that a more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #14 from John Paul Adrian Glaubitz ---
The posix_spawn() issue on sparc64 is explained in more detail, including a
reproducer, here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:153ce7a78edbe339fa0b1cd314dea0554f59faf0
commit r14-8944-g153ce7a78edbe339fa0b1cd314dea0554f59faf0
Author: Jerry DeLisle
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294
--- Comment #3 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:065dddc6e07a917c57c7955db13b1fe77abbcabc
commit r14-8943-g065dddc6e07a917c57c7955db13b1fe77abbcabc
Author: Paul Keir
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
Andrew Pinski changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
Bug ID: 113895
Summary: ice in in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1144
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #10 from Marek Polacek ---
And we should also warn in C++98 with -Wc++11-extensions for an extra ';'
outside of a function I suppose...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113894
Bug ID: 113894
Summary: `(x ^ (-CMP)) + CMP` -> `CMP ? -x : x`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893
Bug ID: 113893
Summary: Finalization exception issue with anonymous access
object.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #36 from Jerry DeLisle ---
I was looking for my damnit doll until I got to your last post. Is this one
worthy of backport?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #11 from Jerry DeLisle ---
I am going to submit the attached patch to close this PR and open a new PR for
the lingering multiple tab edits in a row. The problem there is we have a
special case if we have different T, TL, and TR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:39d989022dd0eacf1a7b95b7b20621acbe717d70
commit r14-8942-g39d989022dd0eacf1a7b95b7b20621acbe717d70
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113849
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113849
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9511b91c56f08b319b4a407608f85c96029ce7ce
commit r14-8941-g9511b91c56f08b319b4a407608f85c96029ce7ce
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b42e978f29b33071addff6d7bb8bcdb11d176606
commit r14-8940-gb42e978f29b33071addff6d7bb8bcdb11d176606
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113892
Bug ID: 113892
Summary: Missing temporary in assignment for array-valued
function referencing host-associated array
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #20 from Martin Jambor ---
I have access to the benchmark and building it with -fprofile-generate
it fails for me (with an ICE in add_symbol_to_partition_1) only when I
use -fno-use-linker-plugin and either -std=c++11 or -std=c++03.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #37 from Andreas Schwab ---
No, it uses whatever __rtld_malloc points at, which will be the normal malloc
after bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106783
Andrew Pinski changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #36 from H.J. Lu ---
(In reply to Andreas Schwab from comment #35)
> ld.so use its internal malloc only during bootstrapping.
___tls_get_addr always uses the internal malloc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #19 from Andrew Pinski ---
(In reply to Martin Jambor from comment #18)
> (In reply to Filip Kastl from comment #17)
> > I've bisected this (using the test from Andrew Pinski) to
> > r10-3311-gff6686d2e5f797
>
> That's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #35 from Andreas Schwab ---
ld.so use its internal malloc only during bootstrapping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #3 from Jens Gustedt ---
(In reply to Jakub Jelinek from comment #1)
> AFAIK glibc doesn't support %w128d etc., it would require full
> int128_t/uint128_t support, likely
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #34 from H.J. Lu ---
(In reply to H.J. Lu from comment #33)
> (In reply to H.J. Lu from comment #32)
> > (In reply to Michael Matz from comment #31)
> > > (In reply to H.J. Lu from comment #30)
> > > > (In reply to Michael Matz from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891
--- Comment #3 from Andrew Pinski ---
I suspect this is due to the use of weak for pthread functions.
Most likely you need to force include all of libthr archive file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #33 from H.J. Lu ---
(In reply to H.J. Lu from comment #32)
> (In reply to Michael Matz from comment #31)
> > (In reply to H.J. Lu from comment #30)
> > > (In reply to Michael Matz from comment #29)
> > > > It not only can call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
--- Comment #18 from Martin Jambor ---
(In reply to Filip Kastl from comment #17)
> I've bisected this (using the test from Andrew Pinski) to
> r10-3311-gff6686d2e5f797
That's a coincidence, with -fno-ipa-sra the testcase fails even earlier,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #32 from H.J. Lu ---
(In reply to Michael Matz from comment #31)
> (In reply to H.J. Lu from comment #30)
> > (In reply to Michael Matz from comment #29)
> > > It not only can call malloc. As the backtrace of H.J. shows, it quite
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #30 from Alex Coplan ---
Backport for GCC 12 submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645415.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891
--- Comment #2 from Steffen ---
The program was compiled with g++13 -pthread -static main.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #31 from Michael Matz ---
(In reply to H.J. Lu from comment #30)
> (In reply to Michael Matz from comment #29)
> > It not only can call malloc. As the backtrace of H.J. shows, it quite
> > clearly _does_ so :-)
>
> ld.so can only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891
--- Comment #1 from Steffen ---
Created attachment 57401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57401=edit
main.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891
Bug ID: 113891
Summary: On FreeBSD, a statically linked program which runs a
std::thread aborts
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #37 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #30 from H.J. Lu ---
(In reply to Michael Matz from comment #29)
> It not only can call malloc. As the backtrace of H.J. shows, it quite
> clearly _does_ so :-)
>
ld.so can only call the malloc implementation internal to ld.so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #36 from GCC Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:83e9075ed22c0c5f27328b4be7d8eb9df5c8778b
commit r13-8319-g83e9075ed22c0c5f27328b4be7d8eb9df5c8778b
Author: Senthil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #29 from Michael Matz ---
It not only can call malloc. As the backtrace of H.J. shows, it quite clearly
_does_ so :-)
That's why there is talk earlier in this report about potentially not using
malloc as one-time allocator for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #28 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #27)
> (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
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
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
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
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=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 () =
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
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=113667
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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
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=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
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
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=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=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
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
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=113890
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever
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=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:
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
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=113847
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
---
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
---
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=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
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
1 - 100 of 169 matches
Mail list logo
