https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93537
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88642
--- Comment #3 from Andrew Pinski ---
So this code is quiet old. There was an error back before
r0-5028-g790e949032a94b (1993, change by RMS) and mailing lists don't exist
that far back ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88642
--- Comment #2 from Andrew Pinski ---
We do warn:
: In function 'main':
:3:5: warning: braces around scalar initializer
3 | int x = { { 0 } } ;
| ^~~
Maybe this should be a pedantic warning instead ...
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86885
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.1.2
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86885
--- Comment #1 from Andrew Pinski ---
Created attachment 57908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57908=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87535
Andrew Pinski changed:
What|Removed |Added
Depends on||64236
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65007
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58806
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #7 from Li Pan ---
Looks this commit from bisect acc22d56e140220e7dc6c138918cb6754b6d1c0b, will
take a look into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956
Andrew Pinski changed:
What|Removed |Added
Keywords||build, documentation
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #4 from Andrew Pinski ---
Hmm, Does this matter that much since HLE has been disabled on all cores?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #13 from Kewen Lin ---
(In reply to Giuliano Belinassi from comment #12)
> With your patch we have:
>
> > .LPFE0:
> > ...
> Which seems what is expected.
Hi Giuliano, thanks for your time on testing it! Could you kindly help to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
--- Comment #4 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:18e94e04dae724c61cbc13ace85fa68f2deda900
commit r14-9852-g18e94e04dae724c61cbc13ace85fa68f2deda900
Author: H.J. Lu
Date: Mon Apr 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56009
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56009
--- Comment #3 from Andrew Pinski ---
This is IIRC the whole atexit vs __cxa_atexit issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > for try blocks, I do need the catch blocks so do it as the siblings.
> > For catch blocks, the child will be type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> for try blocks, I do need the catch blocks so do it as the siblings.
> For catch blocks, the child will be type that is being caught as a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614
--- Comment #2 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:9c97de682303b81c8886ac131fcfb3b122f2f1a6
commit r14-9851-g9c97de682303b81c8886ac131fcfb3b122f2f1a6
Author: Kewen Lin
Date: Mon Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
--- Comment #7 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:26eb5f8fd173e2425ae7505528fc426de4b7e34c
commit r14-9850-g26eb5f8fd173e2425ae7505528fc426de4b7e34c
Author: Kewen Lin
Date: Mon Apr 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642
--- Comment #3 from Andrew Pinski ---
(In reply to Kewen Lin from comment #2)
> David posted a fix (see URL).
Oh yes that should fix it for MIPS and RISCV too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436
--- Comment #5 from Andrew Pinski ---
for try blocks, I do need the catch blocks so do it as the siblings.
For catch blocks, the child will be type that is being caught as a
DW_TAG_formal_parameter/DW_TAG_unspecified_parameters .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642
Kewen Lin changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436
--- Comment #4 from Andrew Pinski ---
So for space, on LP64 (and LLP64) hosts, there is a free 32bits in the BLOCK
structure:
```
tree chain;
unsigned block_num;
location_t locus; // unsigned
location_t end_locus; // unsigned
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39436
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648
--- Comment #5 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:600bf396799a022e65938de572ad1a79a951b95a
commit r14-9849-g600bf396799a022e65938de572ad1a79a951b95a
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #6 from JuzheZhong ---
Definitely it is a regression:
https://compiler-explorer.com/z/e68x5sT9h
GCC 13.2 is ok, but GCC 14 ICE.
I think you should bisect first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45025
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #5 from Li Pan ---
(In reply to Kito Cheng from comment #4)
> Reduced case:
> ```c
> typedef long c;
> #pragma riscv intrinsic "vector"
> template struct d {};
> struct e {
> using f = d<0>;
> };
> struct g {
> using f = e::f;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648
--- Comment #4 from Gaius Mulley ---
Created attachment 57907
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57907=edit
Proposed fix
Trivial patch fix proposed with test code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39091
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #4 from Kito Cheng ---
Reduced case:
```c
typedef long c;
#pragma riscv intrinsic "vector"
template struct d {};
struct e {
using f = d<0>;
};
struct g {
using f = e::f;
};
template using h = g::f;
template long k(d);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #3 from Li Pan ---
Reproduced from my side too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96265
--- Comment #6 from Andrew Pinski ---
*** Bug 111937 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96265
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648
--- Comment #3 from Gaius Mulley ---
it will handle both, implemented in: gcc/m2/m2.flex:171
but the default was inverted during a recent bugfix.
The particular test code example which provoked the bug was:
# 2 "AdvParse.bnf"
IMPLEMENTATION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> While you are at it, it would be useful to add a link to the rust langauge
> specification (like there is for almost all other languages [I see
> objective-C is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114620
--- Comment #2 from Andrew Pinski ---
This also should be valid for C++17 +:
```
template struct T{};
struct A{char x;};
struct B:A{ };
struct C:A{ T y; };
```
Note the constexpr case is only valid for C++17 + too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114620
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114650
Bug ID: 114650
Summary: CodeView debug information format documentation should
be linked from https://gcc.gnu.org/readings.html
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114649
Bug ID: 114649
Summary: Would be useful to link to CTF and BTF debug
information specifications from
https://gcc.gnu.org/readings.html
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114648
Bug ID: 114648
Summary: compiler by default does not handle C pre-processor
file and line directives
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
--- Comment #5 from Andrew Pinski ---
(In reply to Pierre-Emmanuel Patry from comment #2)
> I can see the problem with the message, but I don't think we can remove the
> behavior as we have to match rustc's behavior. The compiler has to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642
Andrew Pinski changed:
What|Removed |Added
Target|powerpc64-linux-gnu |powerpc-linux-gnu mips*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65281
--- Comment #3 from Andrew Pinski ---
Actually HIDE_EXPORTS has been handled as _GLIBCXX_HIDE_EXPORTS for a long time
now.
And UNUSED has also been handled as _GLIBCXX_UNUSED too for a long time (since
2001).
This is all handled by the code in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Andrew Pinski changed:
What|Removed |Added
CC||punitb20 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
--- Comment #16 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #15)
> (In reply to H.J. Lu from comment #14)
> > This issue is about how libgcc is used by libgfortran, not libgcc itself.
>
> libgcc needs to be fixed too. NOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #13 from Andrew Pinski ---
*** Bug 114646 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
--- Comment #11 from Peter Bergner ---
(In reply to Sam James from comment #10)
> No problems reported yet and we have several people testing on ppc w/ gcc 14.
Thanks for the testing! This is clearly a stage1 patch, so we'll wait until
then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
--- Comment #13 from Andrew Pinski ---
(In reply to Bruno Haible from comment #11)
> (In reply to Andrew Pinski from comment #9)
> > Dup.
> >
> > *** This bug has been marked as a duplicate of bug 87189 ***
>
> This makes no sense to me:
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Andrew Pinski changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
H.J. Lu changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114647
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
--- Comment #10 from H.J. Lu ---
Created attachment 57906
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57906=edit
A patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114647
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Andrew Pinski changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114647
Bug ID: 114647
Summary: missing DCE when looping over a VLA
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
Andrew Pinski changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
--- Comment #10 from Bruno Haible ---
It is fixed in
- glibc 2.35 + gcc 11.4 (verified on Ubuntu 22.04),
- glibc 2.39 + gcc 13.2.1 (verified on Arch Linux 2024.04).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Andrew Pinski changed:
What|Removed |Added
Depends on||93115
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615
--- Comment #4 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #3)
> The dumb part is that __n here comes from wcslen(__s2), so the compiler is
> able to track that __s2 is only two bytes, but not capable of tracking that
> __n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #7 from Hristo Venev ---
I was actually trying to fix a bug in an existing application that I didn't
write that is using std::chrono::current_zone() under the assumption that it
returns some good approximation of what should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #5 from Jonathan Wakely ---
The libc time zone doesn't necessarily correspond to anything in the IANA
database anyway. If you use a POSIX time zone definition like TZ="abc4abd" then
libc will use that to generate a custom time zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #4 from Hristo Venev ---
> What does "quite a bit completely useless" mean? current_zone() tells you
> what /etc/localtime is set to. So it's as useless as /etc/localtime, no more
> and no less.
What I mean is that in its current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94365
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Testing again with trunk (for GCC 12); the false leak of ‘a’ report still
> occurs, but the -Wanalyzer-free-of-non-heap report is fixed.
False leak still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147
Dan Raviv changed:
What|Removed |Added
CC||dan.raviv at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114626
--- Comment #3 from anlauf at gcc dot gnu.org ---
Another option is to not declare max_sum as parameter but as variable.
With
integer :: max_sum = 2 * max_ij ** 3
the code compiles almost instantly, but it has noticeable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638
Andrew Pinski changed:
What|Removed |Added
Summary|Hang and Memory Consumption |Hang and Memory Consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #3 from Jonathan Wakely ---
What does "quite a bit completely useless" mean? current_zone() tells you what
/etc/localtime is set to. So it's as useless as /etc/localtime, no more and no
less.
Did you read the messages I linked to?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #7 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:eaccdba315b86d374a4e72b9dd8fefb0fc3cc5ee
commit r14-9847-geaccdba315b86d374a4e72b9dd8fefb0fc3cc5ee
Author: Uros Bizjak
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #2 from Hristo Venev ---
That makes current_zone() quite a bit completely useless and means that
practically every use of current_zone() is most likely a bug.
Is there some way to get the timezone libc would consider local?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
--- Comment #8 from Florian Weimer ---
(In reply to Andrew Pinski from comment #6)
> What was done for libstdc++ was only specific to libstdc++ even though it
> uses the same headers, it was not changed for the generic libgcc code which
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
--- Comment #7 from H.J. Lu ---
r12-5108
commit 80fe172ba9820199c2bbce5d0611ffca27823049
Author: Jonathan Wakely
Date: Tue Nov 9 23:45:36 2021 +
libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133]
Since Glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
--- Comment #13 from Andrew Pinski ---
(In reply to H.J. Lu from comment #11)
> fixed static C++ pthread programs. libgfortran neeeds a similar fix.
libgcc needs the fix instead. Maybe libgomp, maybe libobjc. But this is tracked
in the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646
Andrew Pinski changed:
What|Removed |Added
Component|libfortran |libgcc
--- Comment #6 from Andrew
1 - 100 of 224 matches
Mail list logo
