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 at
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 thre
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=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 Kum
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
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #37 from Georg-Joha
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: norm
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&action=edit
main.ii
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 c
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=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=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=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,
IP
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 mallo
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 #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=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
> int_least128_t/uint_least128_t/int_fast128_t/uint_fast128_t,
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=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 coincidence
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=106783
Andrew Pinski changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
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=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=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=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=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=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: M
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: M
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
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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=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 follo
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=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=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=113866
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
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=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=113895
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Component|c
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=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 F
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=113760
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
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://lore.kernel.org/sparclinux/3ae4130c-c5aa-428e-b819-44cf2daf2...@mkarcher.dialup.fu-berlin.de
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 specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-12
Status|UNCONFIRM
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
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
Summary|Assigning array
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=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=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
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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 (no
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
[-Wextra-
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=110710
Amyspark changed:
What|Removed |Added
CC||amy at amyspark dot me
--- Comment #6 from A
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=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=113897
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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", x[NEED
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=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=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=113895
Zhendong Su changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Commen
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 built
101 - 169 of 169 matches
Mail list logo
