https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66766
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #5 from Tamar Christina ---
And yes the same semantics apply to 'i', but if I read it right the patch in
r12-2523 is tracking variables that are read but never written to. So 'i'
escaped the same issue because it's written to somewh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101769
--- Comment #2 from Richard Biener ---
free_all2_r loses it during CDDCE1 which elides the original while loop. Then
tail-recursion discovers a new loop from the following IL
void free_all2_r (struct Node * n_)
{
struct Node * t;
struct No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
--- Comment #7 from Andrew Pinski ---
GCC, ICC, clang and MSVC all fail the same way. Are we sure this is valid?
Even this fails:
void(Derived:: *t)() = &Derived::bar;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #6 from rguenther at suse dot de ---
On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
>
> --- Comment #5 from Tamar Christina ---
> And yes the same semantics apply to 'i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59931
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-04
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
Yujie Yang changed:
What|Removed |Added
CC||yangyujie at alumni dot
sjtu.edu.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86703
Andrew Pinski changed:
What|Removed |Added
Known to work||9.1.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86558
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749
Martin Liška changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40664
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61936
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39328
Andrew Pinski changed:
What|Removed |Added
CC||modysk at hotmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Bug ID: 101772
Summary: [12 regression] ICE in ix86_expand_epilogue, at
config/i386/i386.c:9267
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #11 from Haoxin Tu ---
Hi all.
I hope you all are doing well.
I am sorry to bother you again. May I ask a quick question about how do you
treat the bug-revealing test case which may include the valid syntax but
contain the UB? (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101769
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4d562591018a51f155a2e5d8b9f3e5860111a327
commit r12-2721-g4d562591018a51f155a2e5d8b9f3e5860111a327
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765
--- Comment #1 from Iain Sandoe ---
I am not sure that a VLA can be used in a coroutine (neither can alloca, if I
remember correctly) [so not sure that this is ICE on valid, it could be ICE on
invalid]
Either way, we should not ICE from it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101769
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-02-11 00:00:00 |2021-8-4
--- Comment #6 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #7 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #5 from Tamar Christ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #12 from Martin Liška ---
>
> (1)From my understanding, compilers should compile well (no crashing or
> performance issue) with those test programs although they contain UB.
Yes, a compiler should produce a valid error message and e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #13 from Haoxin Tu ---
(In reply to Martin Liška from comment #12)
Ok, got you. Thanks for your speedy reply~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90085
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-04-16 00:00:00 |2021-8-4
--- Comment #1 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749
--- Comment #7 from Jakub Jelinek ---
(In reply to Martin Liška from comment #6)
> (In reply to Xi Ruoyao from comment #1)
> > I guess it's fixed in trunk by something in
> > 90e46074e6b3561ae7d8ebd205127f286cc0c6b6:
>
> Does it really fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #2 from Andrew Pinski ---
This seems fixed in GCC 11+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> This seems fixed in GCC 11+.
And in GCC 10.4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > This seems fixed in GCC 11+.
>
> And in GCC 10.4.
I meant 10.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101763
--- Comment #3 from Aldy Hernandez ---
evrp is on the chopping block for this release, and if everything goes
according to plan, so will VRP.
If VRP survives this release, we can go back and fix things like this.
However, if you feel inclined,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101763
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64615
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85251
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-08-04
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101756
--- Comment #4 from Richard Biener ---
So we have
of_14 = of.3[iter.9_16];
ea_13 = ea.2[iter.9_16];
kk_3 = kk.4[iter.9_16];
_32 = kk_3 != 0;
_33 = ea_13 != -1;
_43 = ea_13 != -2;
_36 = MAX_EXPR <_33, _43>;
_41 = _32 < _36;
_31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101743
--- Comment #2 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:9f26640f7b89c771b0ebffd7e7f5019d0709a955
commit r12-2724-g9f26640f7b89c771b0ebffd7e7f5019d0709a955
Author: liuhongt
Date: Wed Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101759
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:af31cab04770f7a1a1da069415ab62ca2ef54fc4
commit r12-2726-gaf31cab04770f7a1a1da069415ab62ca2ef54fc4
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 91094, which changed state.
Bug 91094 Summary: BB vectorization is too quick to disable itself because of
possible unrolling needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 91094, which changed state.
Bug 91094 Summary: BB vectorization is too quick to disable itself because of
possible unrolling needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
Bug ID: 101773
Summary: errors when writing to .gcda file are not checked
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #9 from Richard Biener ---
The full satd_8x4 looks like the following, the 2nd loop isn't to be
disregarded
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
#define HADAMARD4(d0, d1, d2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101756
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:87a0b607e40f8122c7fc45d496ef48799fe11550
commit r12-2727-g87a0b607e40f8122c7fc45d496ef48799fe11550
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101756
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #1 from Richard Biener ---
The question is what to do, exit() or alternatively simply stop attempting to
write to the file? (or even remove it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #5 from Jonathan Wakely ---
Fixed by r11-1571: c++: Refinements to "more constrained".
And the backport r10-8343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181
--- Comment #7 from Jonathan Wakely ---
GCC 7 accepts it in C++17 mode because of r241137
Implement P0386R2 - C++17 inline variables
That's because an out-of-class definition is not needed in C++17, the compiler
will generate one from the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Bug ID: 101774
Summary: using-declaration and typedef alter name for linkage
purposes of unnamed struct
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101775
Bug ID: 101775
Summary: G++ drops namespace prefix of argument in the
referenced function symbol
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101775
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Jonathan Wakely changed:
What|Removed |Added
CC||mytbk920423 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
--- Comment #2 from Jonathan Wakely ---
Not a regression as far as I can tell, GCC 4.1 did the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #14 from Richard Biener ---
(In reply to Martin Liška from comment #12)
> > I am asking the question because I am thinking whether the effort is
> > worthing or not if I devise a tool that can produce diverse syntactic valid
> > but m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #2 from Vincent Lefèvre ---
An immediate exit() might yield other files, the terminal, etc. in a bad state.
IMHO, the best thing to do is to stop attempting to write to the file (possibly
attempt to remove it, but this might fail), a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Jonathan Wakely changed:
What|Removed |Added
CC||cgd at google dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002
Bug 59002 depends on bug 48078, which changed state.
Bug 48078 Summary: accepts-invalid: taking address of private member function
from template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
Bug 101603 depends on bug 48078, which changed state.
Bug 48078 Summary: accepts-invalid: taking address of private member function
from template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96193
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010
Jonathan Wakely changed:
What|Removed |Added
CC||johelegp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #15 from Jakub Jelinek ---
(In reply to Richard Biener from comment #14)
> I disagree - syntactically valid input should not crash the compiler or make
> it slow. Yes, fixing cases with obvious non-sensical input might be low
> prior
Hi,
Eli Zaretskii via Gcc-bugs writes:
> The version of rust-demangle.c included with Binutils 2.37 doesn't
> compile with MinGW:
>
> mingw32-gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -I.
> -I../../binutils-2.37/libiberty/../include -W -Wall -Wwrite-strings
> -Wc++-compat -Wstrict-pr
> From: Richard Sandiford
> Cc: Eli Zaretskii
> Date: Wed, 04 Aug 2021 13:04:24 +0100
>
> Eli Zaretskii via Gcc-bugs writes:
> > The version of rust-demangle.c included with Binutils 2.37 doesn't
> > compile with MinGW:
> >
> > mingw32-gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -I.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #16 from Martin Liška ---
Oh, you are right, I moved syntactically valid inputs (with a potential UBSAN)
into the same bag with syntactically invalid input.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #4 from Vincent Lefèvre ---
GCOV_EXIT_AT_ERROR is not documented in the man page.
Anyway, it doesn't seem to work:
$ export GCOV_EXIT_AT_ERROR=1
$ printenv GCOV_EXIT_AT_ERROR
1
$ gcc-test -O -fprofile-generate=dir tst.c
$ ./a.out
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
--- Comment #4 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #3)
> x86 also get 2 new failures
> ```
> FAIL: c-c++-common/hwasan/alloca-gets-different-tag.c -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects execution test
> FA
In GCC's bugzilla. You could also report it to the sourceware.org
bugzilla for binutils, but I think GCC is the upstream for libiberty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101638
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-08-04
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #17 from Haoxin Tu ---
Thank you all for the detailed clarification! I have got the answer now. Let's
try together to make compilers a better place:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
H.J. Lu changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101742
--- Comment #2 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:f2e5d2717d9e249edc5e0d45e49e4f9ef81fc694
commit r12-2732-gf2e5d2717d9e249edc5e0d45e49e4f9ef81fc694
Author: H.J. Lu
Date: Tue Aug 3 06:
On Aug 04 2021, Eli Zaretskii via Gcc-bugs wrote:
> I'd love to, but please tell me where. I couldn't find any
> information about reporting libiberty bugs, sorry if I missed
> something obvious.
The libiberty README says to report bugs to gcc-bugs@gcc.gnu.org.
Andreas.
--
Andreas Schwab, sch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #8 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:9fcb8ec60302f5f110f94a885b618993c28d18d3
commit r12-2734-g9fcb8ec60302f5f110f94a885b618993c28d18d3
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
> Date: Wed, 4 Aug 2021 14:03:21 +0100
> From: Jonathan Wakely
> Cc: gcc-bugs@gcc.gnu.org
>
> In GCC's bugzilla.
That's what I tried originally, but there's no libiberty there among
the various "components". So I decided the GCC Bugzilla was not the
right place. If it is the right place, pleas
> From: Andreas Schwab
> Cc: Richard Sandiford , Eli Zaretskii
>
> Date: Wed, 04 Aug 2021 15:35:04 +0200
>
> On Aug 04 2021, Eli Zaretskii via Gcc-bugs wrote:
>
> > I'd love to, but please tell me where. I couldn't find any
> > information about reporting libiberty bugs, sorry if I missed
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from H.J. Lu ---
> A patch is posted at:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576697.html
I gave it a quick try by restarting a previously failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977
--- Comment #2 from Jakub Jelinek ---
Created attachment 51258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51258&action=edit
gcc12-pr100977-1.patch
I think I found a bug in the makeucnid.c program, sometimes the ranges are
split
even w
est -O -fprofile-generate=dir tst.c
> $ ./a.out
> $ echo $?
> 0
> $ ls -l dir/*.gcda
> -rw-r--r-- 1 vlefevre vlefevre 0 2021-08-04 14:48:01
> dir/#home#vlefevre#a-tst.gcda
It works for me:
$ gcc --version
gcc (GCC) 12.0.0 20210804 (experimental)
$ df -h /tmp/ramdisk
Filesys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
--- Comment #5 from Martin Liška ---
> > ```
> Just want to clarify that it's our developping lam version which is at
> https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master
What can you see for a vanilla GCC compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101575
--- Comment #14 from CVS Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:96c82a16b2076891a9974d0f0e96a0b85fbc2df4
commit r12-2735-g96c82a16b2076891a9974d0f0e96a0b85fbc2df4
Author: Bernd Edlinger
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598
--- Comment #8 from Bernd Edlinger ---
patch was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576027.html
review here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576520.html
and here:
https://gcc.gnu.org/pipermail/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #6 from Vincent Lefèvre ---
Created attachment 51259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51259&action=edit
added missing error check on fclose in gcc/gcov-io.c
Well, not all errors are detected. There is a missing t
> The libiberty README says to report bugs to gcc-bugs@gcc.gnu.org.
Well that needs to be fixed. It should point to
https://gcc.gnu.org/bugs/ instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Martin Liška --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #8 from Vincent Lefèvre ---
(In reply to Martin Liška from comment #7)
> May I please install the patch on your behalf?
Yes. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:929f2cf4105ccf12d0684c6d5838f58f0ee5e7c7
commit r12-2736-g929f2cf4105ccf12d0684c6d5838f58f0ee5e7c7
Author: Vincent Lefèvre
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749
--- Comment #8 from Martin Liška ---
> It should. Before that change there is a block scope variable that needs
> initialization and so that it is initialized just once (by the first thread
> calling that function and other threads waiting unti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749
--- Comment #9 from Jakub Jelinek ---
(In reply to Martin Liška from comment #8)
> Thanks for the full explanation.
> So it seems it's fine on master, should I backport the fix to release
> branches?
Yes, please.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101776
Bug ID: 101776
Summary: [12 Regression] Boootstrap broken on s390x
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101776
--- Comment #1 from Martin Liška ---
There's missing '-Wl,' before the option. On x86_64 it's fine:
[12038s] libtool: link:
/home/abuild/rpmbuild/BUILD/gcc-12.0.0+git187113/obj-x86_64-suse-linux/./gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-12.0
1 - 100 of 299 matches
Mail list logo
