https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113264
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
--- Comment #1 from Andrew Pinski ---
Created attachment 57004
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57004&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113264
Bug ID: 113264
Summary: ICE：tree check: expected tree that contains 'common'
structure, have 'integer_cst' in copy_list, at
tree.cc:1427
Product: gcc
Version: 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Bug ID: 113263
Summary: ICE for invalid code for compound literal and type
definition in return type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #16 from Andrew Pinski ---
Note multiple copies of the libstdc++ will not fix the issue here since
libtcmalloc provides a free which does not work with aligned_alloc. In fact it
would just fall over the same way. As I mentioned libtc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #7 from g.peterh...@t-online.de ---
Thank you. That was my question whether these two functions could be added.
At the moment I'm using boost.charconv https://github.com/cppalliance/charconv
https://develop.charconv.cpp.al (not offici
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Nicholas Miell changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262
Andrew Pinski changed:
What|Removed |Added
Known to fail||11.1.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #6 from Andrew Pinski ---
(In reply to g.peterhoff from comment #5)
> ??? I asked for std::from_chars/std::to_chars - which of course doesn't work:
> https://godbolt.org/z/n34dTajoc
std::from_chars/std::to_chars for extended floatin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #5 from g.peterh...@t-online.de ---
??? I asked for std::from_chars/std::to_chars - which of course doesn't work:
https://godbolt.org/z/n34dTajoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262
Bug ID: 113262
Summary: ICE when using [[gnu::copy("")]] attribute
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111480
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-01-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112751
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113261
--- Comment #1 from Hongtao Liu ---
For foo1,
_99 = .REDUC_PLUS (vect_patt_79.51_97);
_90 = .REDUC_PLUS (vect_patt_28.43_88);
_19 = _90 + _99;
can be optimized to
_tmp = vect_patt_79.51_97 + vect_patt_28.43_88;
_19 = .REDUC_PLUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113261
Bug ID: 113261
Summary: missing vectorization for dot_prod chain.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
--- Comment #2 from g.peterh...@t-online.de ---
I'm currently fiddling around with a library for/with boost. I don't need this
kind of incompatibility.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #4 from Andrew Pinski ---
_Float128 is supported in older c++ standards for gcc. That is it does not
error out for -std=gnu++11 even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #3 from g.peterh...@t-online.de ---
My problem is that I need from_chars/to_chars for __float128 also for older C++
standards that do not yet support _Float128/std::float128_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
--- Comment #1 from Andrew Pinski ---
There is support for _Float128 for from_chars/to_chars in GCC 14 already ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #12 from Nicholas Miell ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Nicholas Miell from comment #8)
> > What appears to actually be happening is that the libstdc++ operator
> > new(std::size_t size, std::align_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260
Bug ID: 113260
Summary: missing from_chars/to_chars for __float128
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259
Bug ID: 113259
Summary: quadmath::nanq not support payload
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #11 from Andrew Pinski ---
https://github.com/gperftools/gperftools/commit/d406f2285390c402e824dd28e6992f7f890dcdf9
was the commit which fixed tcmalloc .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110966
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #9 from Andrew Pinski ---
(In reply to Nicholas Miell from comment #8)
> What appears to actually be happening is that the libstdc++ operator
> new(std::size_t size, std::align_val_t alignment) is calling glibc's
> aligned_alloc, an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #8 from Nicholas Miell ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Nicholas Miell from comment #0)
> > This is typically the result of the libstdc++ version of operator
> > delete(void* ptr, std::align_val_t alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #7 from Jonathan Wakely ---
(In reply to Nicholas Miell from comment #0)
> This is typically the result of the libstdc++ version of operator
> delete(void* ptr, std::align_val_t alignment) calling the
> application-supplied version o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #6 from Andrew Pinski ---
(In reply to Nicholas Miell from comment #4)
> No, the problem is that a pre-C++17 application is using a post-C++17 GPU
> driver (well, the GPU driver is using a post-C++17 libLLVM), and the
> post-C++17 ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #5 from Andrew Pinski ---
(In reply to Nicholas Miell from comment #3)
> GCC has dealt with similar issues before, cf. bug 68210.
That was a defect to the C++11 standard unlike this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #4 from Nicholas Miell ---
(In reply to Andrew Pinski from comment #2)
> So the situtation here is you have a pre-C++17 application using a C++17
> library.
>
> If the application was C++17 and using a C++11 library, it would just w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #3 from Nicholas Miell ---
Windows and macOS (and Solaris) have sensible dynamic linker semantics where
the pre-C++17 code and the post-C++17 code uses two different C++ runtimes and
furthermore the application can use tcmalloc while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #2 from Andrew Pinski ---
So the situtation here is you have a pre-C++17 application using a C++17
library.
If the application was C++17 and using a C++11 library, it would just work.
So the ABI is broken in the C++17 library rathe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #1 from Andrew Pinski ---
This is a C++ standard issue I suspect which cannot be fixed just in libstdc++.
I suspect libc++ and MSVC's C++ library all have a similar issue too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Bug ID: 113258
Summary: Pre-C++17 code that supplies operator new/delete
crashes when mixed with post-C+17 code that uses the
align_val_t variants of new/delete
Product: gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-01-07
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245
--- Comment #1 from anlauf at gcc dot gnu.org ---
The following probably rather obvious patch fixes the issue:
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index d973c49380c..748cc74de89 100644
--- a/gcc/fortran/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #3 from Uroš Bizjak ---
_.dse1 pass is removing the store for some reason, -fno-dse "fixes" the
testcase.
Before _.dse1 pass, we have:
(insn 41 40 46 4 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -36 [0xf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:add995ec117d756e61d207041cd32f937c1a1cd9
commit r14-6986-gadd995ec117d756e61d207041cd32f937c1a1cd9
Author: Jerry DeLisle
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
--- Comment #5 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:0a8aba760f62e9d66cc5610ecc276c1f0befc651
commit r14-6985-g0a8aba760f62e9d66cc5610ecc276c1f0befc651
Author: Roger Sayle
Date: Sun J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
--- Comment #4 from Tamar Christina ---
Created attachment 57003
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57003&action=edit
perlbench.patch
submitted patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #1 from Sam James ---
FWIW, I did try a patch per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901#c4 as a quick hack in case
it's the same issue, but it didn't help:
```
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
Bug ID: 113257
Summary: -march=native or -mcpu=native are ineffective, but
-march=native -mcpu=native works on arm64 M2 Ultra
Product: gcc
Version: 14.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #24 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:1c765016557eb8d4c576bfe22c10abf0b398fbab
commit r14-6982-g1c765016557eb8d4c576bfe22c10abf0b398fbab
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693
--- Comment #11 from Piotr Siupa ---
Thanks! Now the generated assembly is one instruction shorter.
It works for:
bool foo(unsigned x)
{
[[assume(x != 0)]];
return std::has_single_bit(x);
}
and for:
bool foo(unsigned x)
{
if (x == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #23 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:7d60b1b78538c5606e8d35cdba8f565e7785d9c6
commit r14-6981-g7d60b1b78538c5606e8d35cdba8f565e7785d9c6
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #22 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:c2e66755b6b6336dd5d93da3f4effb81d236397e
commit r14-6980-gc2e66755b6b6336dd5d93da3f4effb81d236397e
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
--- Comment #2 from Pali Rohár ---
`section` is the best option. MS says about it:
https://learn.microsoft.com/en-us/cpp/cpp/code-seg-declspec
> The code_seg declaration attribute names an executable text segment in the
> .obj file in which t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111938
Thomas Koenig changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112899
--- Comment #2 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:a71c3977d24722ac8ee28d8844c4f96a151f75ab
commit r14-6979-ga71c3977d24722ac8ee28d8844c4f96a151f75ab
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679
--- Comment #4 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:63b531e6f8783e8624502d890dc422379de47a9a
commit r14-6978-g63b531e6f8783e8624502d890dc422379de47a9a
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110808
--- Comment #2 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:7f24446a3cf67d1346c78b4667fba74b73a23302
commit r14-6977-g7f24446a3cf67d1346c78b4667fba74b73a23302
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
62 matches
Mail list logo
