https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #31 from LIU Hao ---
(In reply to Gabriel Ivăncescu from comment #30)
> Why would it not be safe? For MinGW specifically, what's not safe about it?
> The entire Windows stack assumes only 4-byte alignment for i386, because
> that's w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #11 from Sam James ---
Created attachment 61249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61249&action=edit
small.c
This cvise-mangled one (tidied up a fair bit after) seems to do it, but it's
weird, e.g. swapping g/h mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #15 from GCC Commits ---
The releases/gcc-14 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:e363940e1cef7f6face970414ffaa565daf413bd
commit r14-11701-ge363940e1cef7f6face970414ffaa565daf413bd
Author: Vineet Gupta
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #19 from GCC Commits ---
The releases/gcc-14 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:ae6ce4cd33d00b8acc9503b0d4883fa92c1a696d
commit r14-11700-gae6ce4cd33d00b8acc9503b0d4883fa92c1a696d
Author: Robin Dapp
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #10 from Sam James ---
It's definitely related to the x* functions. Using __builtin_XXX() instead
makes it work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #9 from Sam James ---
I need to do other things for tonight so won't be reducing it further for now.
Feel free to take over.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #8 from Sam James ---
Created attachment 61248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61248&action=edit
fsck.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #7 from Sam James ---
Created attachment 61247
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61247&action=edit
fsck.i.xz
Reduced (but could do with more) testcase attached.
$ gcc fsck.c -o fsck -save-temps -O2 -fsigned-char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
--- Comment #5 from kargls at comcast dot net ---
On 4/29/25 17:01, neil.n.carlson at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
>
> --- Comment #4 from Neil Carlson ---
> (In reply to kargls from comment #3)
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62244
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120015
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
--- Comment #4 from Neil Carlson ---
(In reply to kargls from comment #3)
> Also note, that the above generates the expected temporary arrays.
A tangential question: Why is this expected? I would have naively thought that
a dope
vector with a s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
Sam James changed:
What|Removed |Added
Known to fail||15.1.0, 16.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #6 from Sam James ---
(In reply to Avraham Hollander from comment #5)
> So it could be code from either of those files. How would you narrow that
> down further?
What I usually do is:
* Build it manually (git clone ... && cd ... &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #5 from Avraham Hollander ---
(In reply to Sam James from comment #4)
> I can have a look at reducing if nobody else can, just it may be a few days.
> But
> are you sure fsck.c is actually the miscompiled file (verified that)?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #4 from Sam James ---
I can have a look at reducing if nobody else can, just it may be a few days.
But
are you sure fsck.c is actually the miscompiled file (verified that)?
>
> I diffed the new preprocessed file with the old one a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #3 from Avraham Hollander ---
(In reply to Andrew Pinski from comment #2)
> Can you try the backporting the commit in PR 119973 and seeing if that fixes
> this one too? If so please close this as a dup of bug 119973.
It did not fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
--- Comment #6 from Amber Ehrlich ---
Ahh I can't edit, well, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120014 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120016 are crash 2 and 3
respectively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
Sam James changed:
What|Removed |Added
Summary|[15/16 Regression] |[15/16 Regression]
|Impos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120016
Bug ID: 120016
Summary: SIGSEGV ICE with modules related to instantiation of
templates across partition units (case 3)
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120015
Bug ID: 120015
Summary: internal compiler error: in unify, at cp/pt.cc:25969
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120014
Bug ID: 120014
Summary: SIGSEGV ICE with modules related to instantiation of
templates across partition units (case 2)
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
--- Comment #5 from Amber Ehrlich ---
Ehh he's not sure so I'll do it anyways. Removing the other 2 cases from this
post
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
--- Comment #5 from H. Peter Anvin ---
(I'm asking because of our is far enough back then we can convert the kernel
code immediately.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
--- Comment #4 from Sam James ---
If one of the GCC modules folks are on the Discord and said that, then that's
fine. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
--- Comment #3 from Amber Ehrlich ---
I was told by a maintainer on modules that the 3 issues seem to be the same
one; I'll ask again & create 3 separate issues if not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
--- Comment #2 from Amber Ehrlich ---
Created attachment 61244
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61244&action=edit
Crash 1 project files + preprocessed source
Output:
/usr/local/bin/g++ -std=c++20 -freport-bug -Wall -Wextr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
--- Comment #4 from H. Peter Anvin ---
Since when has i386 supported %a (outputting just the symbol)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
Bug ID: 120013
Summary: SIGSEGV ICE with modules related to instantiation of
templates across partition units
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119983
--- Comment #4 from gap mman ---
(In reply to Nathaniel Shead from comment #2)
> Thanks for the report! As Andrew noted, the ICE is fixed for 14.3 by
> r14-10825-g01d3a974fe3474c37cd52b595c29dddafad954dc.
>
> The code is ill-formed, however:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120005
--- Comment #4 from Nathaniel Shead ---
But as Andrew says, you can workaround the issue by declaring it 'inline' to
prevent it from having internal linkage. This will also avoid any issues with
accidental ODR usages from later maintenance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120005
Nathaniel Shead changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #11 from Andrew Pinski ---
(In reply to Stefan Kneifel from comment #9)
> Hongtao Liu's patch mentioned in Comment 1 does NOT retract the regression.
That is because I thought you were testing against the final release of GCC
15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #10 from Sam James ---
Bisecting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #9 from Stefan Kneifel ---
Hongtao Liu's patch mentioned in Comment 1 does NOT retract the regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012
Bug ID: 120012
Summary: [12/13/14/15/16 Regression] P1008R1 causes tail
padding reuse in C++20 mode
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #8 from Stefan Kneifel ---
It was the version shipped with Fedora 42 Release:
https://dl.fedoraproject.org/pub/fedora/linux/releases/42/Everything/source/tree/Packages/g/gcc-15.0.1-0.11.fc42.src.rpm
Regards, Stefan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.2
Summary|[15 Regression] Imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
Andrew Pinski changed:
What|Removed |Added
Known to fail||15.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #4 from Stefan Kneifel ---
Oh I see that the error occurs only if one of the size optimization options
(-Os,-Oz) is active:
[64 bit environment]
gcc -Os -pipe -c addtf3.c works
gcc -Os -pipe -c addtf3.c -mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103044
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
--- Comment #3 from Uroš Bizjak ---
(In reply to Sam James from comment #2)
> It's r15-2213-g062e46a8137996, so let's set the milestone.
Actually, %a always did this on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103044
--- Comment #3 from GCC Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:692b6470706090a09e30232d7eab74151a509243
commit r16-289-g692b6470706090a09e30232d7eab74151a509243
Author: Iain Buclaw
Date: Tue Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119855
--- Comment #11 from Jonathan Wakely ---
Specifically, WG14 N2829 changed assert for C23 and WG21 P2264R7 changed it for
C++26, and the latter includes a solution for the scoped enum problem described
in the glibc bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119855
--- Comment #10 from Jonathan Wakely ---
The C23 change and the C++26 change were proposed concurrently and were
originally part of the same proposal, and the glibc bug about scoped enums is
related to that same proposal.
However, glibc really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #2 from Stefan Kneifel ---
Created attachment 61243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61243&action=edit
creduced addtf3.c from libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/cgit/gcc/commit/?h=releases/gcc-15&id=972a03737284b8611ec4e6315f6ca04d56ec05bf
is the only x86 change on the 15 branch. There are no other changes on the
branch which would have touched i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011
Bug ID: 120011
Summary: [15 Regression] Impossible asm constraints in 32 bit
libgcc when compiling with -march=x86-64-v4
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120010
--- Comment #3 from H. Peter Anvin ---
THat should of course have been __attribute__((unused)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120010
--- Comment #2 from H. Peter Anvin ---
Having to omit the name puts us right back into macro hell... having to
macroize every function definition.
It also violates the principle of least surprise, since __attribute__((used))
works if attached t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120004
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Another option which I am thinking about is just expanding
> __builtin_unreachable as the same as a trap. So at -O0, an explict
> __builtin_unreachable will turn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916
--- Comment #18 from Jason Merrill ---
(In reply to Iain Sandoe from comment #17)
> > > In the meantime, perhaps it would be enough to revert the "fix" for
> > > PR115908
> > > (and presumably mark that as INVALID?) - or do you have other thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120010
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Common-Type-Attributes.html#index-unused-type-attribute
"This is often the case with lock or thread classes, which are usually defined
and then not referenced, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
--- Comment #4 from H. Peter Anvin ---
Well, I did both.
See also bug 120010; I don't believe this is at all consistent.
Having to omit the variable name defeats the whole purpose here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120010
Bug ID: 120010
Summary: __attribute__((unused)) does not work for function
arguments
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
--- Comment #3 from Andrew Pinski ---
>I will file a bug for __attribute__((unused)).
There is no bug on the unused case, you are marking the typedef decl as unused
not the type being unused. GNU C (and C23) also handles omitting the paramater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
--- Comment #2 from H. Peter Anvin ---
Very interesting indeed... I just tried it as such:
struct empty_t { } __attribute__((unused));
typedef struct empty_t empty_t __attribute__((unused));
int foo(empty_t a, int b, int c, empty_t d, int e,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120004
--- Comment #3 from Andrew Pinski ---
Another option which I am thinking about is just expanding
__builtin_unreachable as the same as a trap. So at -O0, an explict
__builtin_unreachable will turn into a trap. And the RTL optimizations don't
take
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
--- Comment #5 from Andrew Pinski ---
Or the problem is in general_operand (recorg.cc) which accepts this subreg too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
--- Comment #5 from anlauf at gcc dot gnu.org ---
The thread on the J3 ML starts here:
https://mailman.j3-fortran.org/pipermail/j3/2025-April/015230.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
--- Comment #4 from Neil Carlson ---
(In reply to kargls from comment #3)
> Note, Neil has asked on the J3 mailing list for clarification as there
> seems to be a conflict on the requirements of a restricted expression.
I think the list given i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
--- Comment #2 from Sam James ---
It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266
H. Peter Anvin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
--- Comment #4 from Andrew Pinski ---
validate_subreg allows the paradoxical subreg even in the case of hard
register:
```
/* Paradoxical subregs must have offset zero. */
if (maybe_gt (osize, isize))
return known_eq (offset, 0U);
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009
Bug ID: 120009
Summary: RFE: idea: void (dummy) objects (really...)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117783
Jakub Jelinek changed:
What|Removed |Added
Attachment #61223|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120004
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
Martin Jambor changed:
What|Removed |Added
Summary|[12/13/14 regression] Wrong |[12 regression] Wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
--- Comment #3 from Dimitar Dimitrov ---
Created attachment 61240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61240&action=edit
Reduced test reproducing the issue
Attached a reduced preprocessed test case:
$ ./xgcc -O2 test-pr119966.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
Bug ID: 120008
Summary: RFE: x86: explicit compiler support for SMAP stac/clac
(possibly via __attribute__((user))) or similar
Product: gcc
Version: unknown
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #30 from Gabriel Ivăncescu ---
(In reply to LIU Hao from comment #28)
> Created attachment 61236 [details]
> proposed patch #2
>
> It might not be safe to decrease the preferred stack boundary, so let's keep
> it as 16, but initiali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120007
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-04-29
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111657
--- Comment #14 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:69669180d29cc420b1b1ac86530a4f9573748d81
commit r16-285-g69669180d29cc420b1b1ac86530a4f9573748d81
Author: Uros Bizjak
Date: Tue A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119855
--- Comment #9 from Joseph S. Myers ---
I don't think a glibc bug "assert should not allow C++ scoped enums" has
anything to do with the issue of making assert a variadic macro to allow an
argument with a comma in it. As far as I know that C23 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120007
Bug ID: 120007
Summary: AArch64 incorrectly handles 16-bit HFAs
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ABI, wrong-code
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003
--- Comment #4 from Andrew Macleod ---
This seems to be the issue?
[local count: 350791453]:
_1 = g (i_3);
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 175395727]:
[local count: 1063004408]:
# iftmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003
Andrew Macleod changed:
What|Removed |Added
CC||aldy at quesejoda dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Target Mile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116440
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117265
--- Comment #17 from H. Peter Anvin ---
So I am still confused by this.
It would seem that this really ought to be a very simple request, and that
adding compiler support for all these cases would impose a really large burden
on the gcc team (y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119807
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
--- Comment #22 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #21)
> > +FAIL: gcc.dg/pr46309-2.c scan-tree-dump-times reassoc1 "Optimizing range
> > tests a_[0-9]*.D. -.1, 1. and -.2, 2. and -.3, 3. and -.4, 4. and -.5, 5.
> > a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
H. Peter Anvin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
Andrew Pinski changed:
What|Removed |Added
Blocks||68331
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006
--- Comment #1 from Avraham Hollander ---
Created attachment 61239
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61239&action=edit
util-linux build log from portage. Contains all the compiler output.
1 - 100 of 206 matches
Mail list logo
