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
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
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?
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=edit
Test program to reproduce GCC 12 compilation bug
Here is the expected output of the ppc9_test_sat_add_090923.cpp test
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
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://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:
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
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=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The ppc9_test_sat_widen_pairwise_add_090923_2b.cpp
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=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The attached
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Andrew Pinski changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
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,
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
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=edit
Proposed fix
Here is a proposed interim patch. In the meantime I'll hunt down the missing
case clause (and fix the
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
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
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
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
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
+++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111354
--- Comment #3 from d_vampile ---
(In reply to Andrew Pinski from comment #1)
> First off the performance is difference is die to micro-arch issues with
> unaligned stores of 256 bits.
>
> Also iirc rte_mov128blocks is tuned at copying blocks
42 matches
Mail list logo
