https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110068
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #30 from Eric Gallager ---
(In reply to matoro from comment #26)
> We also had somebody report on IRC that they observed this on powerpc (not
> sure what tuple), again with -j1. It does not seem to show up with -j2, so
> likely -j1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685
--- Comment #4 from Eric Gallager ---
(In reply to Eric Gallager from comment #3)
> (In reply to Eric Gallager from comment #2)
> > I just got a similar error on gcc13 on the compile farm; config.guess there
> > reports:
> >
> > $ ../config.gues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
Eric Gallager changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111341
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-09-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
--- Comment #1 from Andrew Pinski ---
The front-end does:
hi = instantiate_non_dependent_expr (hi, complain);
hi = cxx_constant_value (hi, complain);
int len = valid_constant_size_p (hi) ? tree_to_shwi (hi) : -1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357
Bug ID: 111357
Summary: __integer_pack fails to work with values of dependent
type convertible to integers
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #5 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:0d50facd937bda26e3083046dc5dec8fca47e1e6
commit r14-3825-g0d50facd937bda26e3083046dc5dec8fca47e1e6
Author: Juzhe-Zhong
Date: Sun Sep 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb
Also: thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #4 from Hans-Peter Nilsson ---
(In reply to Jonathan Wakely from comment #2)
> The FAIL should be gone after r14-3812-gb96b554592c5cb
Confirmed
> but the underlying
> g++ problem is latent.
So, keeping this PR open is TRT?
Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #11 from John Platts ---
Created attachment 55869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55869&action=edit
Test program to reproduce GCC 12 compilation bug
Here is the expected output of the ppc9_test_sat_add_090923.cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #7 from Jonathan Wakely ---
And there are a number of proposals related to increasing how much of the
standard library is available for freestanding, which might eventually meet
your needs. But it would help if you stop publicly insu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #6 from Jonathan Wakely ---
Defect reports to WG21 do not go to GCC's bugzilla though.
And it's not a defect, it's the intended design, working as intended and
approved by the committee. Just because you don't like it, doesn't make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #8 from John Soo ---
> Also, it is typically Windows that suffers from this limitation of command
> line length.
Ok that may be true but I am effected by this on linux as are quite a few
others in this issue https://github.com/NixOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #3 from Jonathan Wakely ---
Possibly relevant, compiling anything including with
-Wsystem-headers -Wabi gives these warnings:
/home/jwakely/gcc/13/include/c++/13.2.1/stacktrace: At global scope:
/home/jwakely/gcc/13/include/c++/13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #5 from cqwrteur ---
It's evident that there's a flaw in the standard, making it impossible to
allocate uninitialized memory for freestanding environments. That's precisely
why I reported it as a potential issue for future proposals.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
--- Comment #2 from Andrew Pinski ---
Works for me on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #10 from John Platts ---
Created attachment 55868
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55868&action=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The ppc9_test_sat_widen_pairwise_add_090923_2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #9 from John Platts ---
Created attachment 55867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55867&action=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The attached ppc9_test_sat_widen_pairwise_add_0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
--- Comment #1 from comer352l at googlemail dot com ---
Created attachment 55866
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55866&action=edit
cpp file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111356
Bug ID: 111356
Summary: Segmentation fault when compiling large static data
structure
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
--- Comment #7 from Costas Argyris ---
(In reply to John Soo from comment #6)
> This is not a Windows-only bug, so I don't think it is fixed.
Althought it is not mentioned explicitly in the title of this PR, the original
reporter did describe it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Benjamin Priour :
https://gcc.gnu.org/g:50b5199cff690891726877e1c00ac53dfb7cc1c8
commit r14-3823-g50b5199cff690891726877e1c00ac53dfb7cc1c8
Author: benjamin priour
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030
John Soo changed:
What|Removed |Added
CC||john.soo+gcc-bugzilla@arist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111355
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Andrew Pinski changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111355
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300
--- Comment #2 from Jonathan Wakely ---
The FAIL should be gone after r14-3812-gb96b554592c5cb but the underlying g++
problem is latent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #3 from cqwrteur ---
what i am talking about is uninitialized memory for later initialization like
implementing containers for example
From: redi at gcc dot gnu.org
Sent: Saturday, September 9, 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
--- Comment #2 from Jonathan Wakely ---
This is not a proper bug report. What are you reporting, that you get an error
for some code (what code? where is the testcase? where is the `gcc -v` output?)
or that you want a new feature to support some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330
--- Comment #6 from Gaius Mulley ---
Created attachment 55864
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55864&action=edit
Proposed fix
Here is a proposed interim patch. In the meantime I'll hunt down the missing
case clause (and fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-09-09
Ever confirmed|0
/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230909 (experimental) (GCC)
[520] %
[520] % gcctk -O1 -w small.c
during GIMPLE pass: ccp
small.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #13 from Paul Thomas ---
(In reply to anlauf from comment #12)
> Fixed on mainline for gcc-14.
>
> Shall we close it? Or does it deserve backporting?
Hi Harald,
I was considering a backport of a composite finalization patch to bri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #19 from Xi Ruoyao ---
(In reply to chenglulu from comment #18)
> This problem has been fixed on LA664．
> I don't quite understand why this operation is still needed in !TARGET_64BIT?
It's not needed with !TARGET_64BIT. I just mea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to Francois-Xavier Coudert from comment #3)
> > > Clang: 14.0.0 build 1400
> > > CLT: 14.2.0.0.1.1668646533
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #18 from chenglulu ---
(In reply to Xi Ruoyao from comment #17)
> I think the proper description should be:
>
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index 75f641b38ee..000d17b0ba6 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #17 from Xi Ruoyao ---
I think the proper description should be:
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..000d17b0ba6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #16 from chenglulu ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to chenglulu from comment #13)
> > (In reply to Xi Ruoyao from comment #12)
> > > (In reply to chenglulu from comment #11)
> > > > (In reply to Xi Ruoyao fro
45 matches
Mail list logo
