https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
Bug ID: 113049
Summary: Compiles to strlen even with -fno-builtin-strlen
-fno-optimize-strlen
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #1 from Georg-Johann Lay ---
-fno-builtin works, but that seems too much. -fno-builtin-strlen should switch
it off IMO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #2 from Mikael Pettersson ---
Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
disabling similar loop-to-call transformations people have been objecting to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113050
Bug ID: 113050
Summary: -Wincompatible-pointer-types emitted as a warning, not
an error, for __atomic_load
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113050
--- Comment #1 from Florian Weimer ---
The warning should be -Wdiscared-qualifiers, which is not an error for C.
What confused me is that the volatile qualifier is already accepted for the
first argument. I believe it's valid for the second arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113050
--- Comment #2 from Sam James ---
Yeah, for every attempt I had to reconstruct it manually, I just got the
expected -Wdiscarded-qualifiers, and then realised it was atomic-specific.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113050
--- Comment #3 from Florian Weimer ---
(In reply to Florian Weimer from comment #1)
> The warning should be -Wdiscared-qualifiers, which is not an error for C.
>
> What confused me is that the volatile qualifier is already accepted for the
> fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52889
--- Comment #3 from MathiasPuetz at gmx dot de ---
Hi Andrew,
I only vaguely remember this after 11 (!) years.
The generated code looks ok on first sight.
However the reference doc (e.g.
https://www.cs.ucr.edu/~csong/cs153/refs/amd64-vol4-media.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
--- Comment #3 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:50b3f596bd943ec6110c1987f14e5497ce39622f
commit r14-6642-g50b3f596bd943ec6110c1987f14e5497ce39622f
Author: Xi Ruoyao
Date: Sat Dec 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113051
Bug ID: 113051
Summary: -Wformat-signedness wrongly triggers for values from
template arguments
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113046
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107367
--- Comment #4 from Jonathan Wakely ---
*** Bug 113046 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107367
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-12-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110731
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9e30ca09c01124333dc97e8c2cb704b74d3c7b60
commit r11-11148-g9e30ca09c01124333dc97e8c2cb704b74d3c7b60
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408
--- Comment #9 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1fdae54453d115d73d5a4bfa0257e88000ab18b8
commit r11-11150-g1fdae54453d115d73d5a4bfa0257e88000ab18b8
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112795
--- Comment #12 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:67762f3d76d42b2d9a436b6279fd111082f47c2b
commit r11-11151-g67762f3d76d42b2d9a436b6279fd111082f47c2b
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816
--- Comment #14 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:531d80228d85624c0e2eac40cd525dc75686ba95
commit r11-11152-g531d80228d85624c0e2eac40cd525dc75686ba95
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112837
--- Comment #8 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:05e3cff4e8b3b544afb1bbefddc342de42641cc1
commit r11-11153-g05e3cff4e8b3b544afb1bbefddc342de42641cc1
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112845
--- Comment #8 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:6156cbb74dabb98899f8f481bda4ae969ac22d53
commit r11-11154-g6156cbb74dabb98899f8f481bda4ae969ac22d53
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
--- Comment #18 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:124a2110a1f5bbfe7274251b25b3944910296887
commit r11-11155-g124a2110a1f5bbfe7274251b25b3944910296887
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112727
--- Comment #12 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:97d6683f6aeda4916a89889bde4c051e55aac984
commit r11-11156-g97d6683f6aeda4916a89889bde4c051e55aac984
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #3 from Georg-Johann Lay ---
(In reply to Mikael Pettersson from comment #2)
> Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
> disabling similar loop-to-call transformations people have been objecting to.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #4 from Andreas Schwab ---
-fno-builtin-strlen has a different purpose.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113034
Xi Ruoyao changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #5 from Georg-Johann Lay ---
(In reply to Andreas Schwab from comment #4)
> -fno-builtin-strlen has a different purpose.
So then -fno-builtin should also not work? GCC documentation of -fno-builtin is
the same like for -fno-builtin-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113050
Florian Weimer changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ever conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112899
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #6 from Andreas Schwab ---
That's what -fno-tree-loop-distribute-patterns is for.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
--- Comment #7 from Georg-Johann Lay ---
(In reply to Andreas Schwab from comment #6)
> That's what -fno-tree-loop-distribute-patterns is for.
So you know the GCC sources and can draw that conclusion.
The documentation of -ftree-loop-distribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592
--- Comment #8 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5060825aa78b3da036df6437390fd42d094d8f15
commit r14-6644-g5060825aa78b3da036df6437390fd42d094d8f15
Author: Harald Anlauf
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
David Binderman changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #4)
> Created attachment 56484 [details]
> Fix for this PR
>
> Somehow this missed being a blocker for the ASSOCIATE meta-bug.
>
> The patch is so unbelievab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113043
Uroš Bizjak changed:
What|Removed |Added
Component|target |sanitizer
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
Andrew Pinski changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113052
Bug ID: 113052
Summary: Templated conversion operator of templated class is
not considered in argument to equality operator
Product: gcc
Version: 13.2.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #3 from Jonathan Wakely ---
I don't recognise that code, are you sure I wrote it? d4ba3b369c did not touch
that code.
Do you have a shallow clone, which happens to have my d4ba3b369c as the oldest
commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #4 from Jonathan Wakely ---
That's what the ^ on the commit suggests is happening.
You can fix your history with:
git fetch --unshallow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #5 from David Binderman ---
(In reply to Jonathan Wakely from comment #3)
> I don't recognise that code, are you sure I wrote it? d4ba3b369c did not
> touch that code.
No idea. git blame is known to lie from time to time. I am no
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #6 from David Binderman ---
(In reply to Jonathan Wakely from comment #4)
> That's what the ^ on the commit suggests is happening.
Righto.
> You can fix your history with:
> git fetch --unshallow
trunk.year $ git fetch --unshallow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112840
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558
uecker at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939
uecker at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #7 from David Binderman ---
I tried:
$ git fetch --shallow-since=1/1/2021
and the blame still has ^ on the front of it.
^abca670596 libcpp/lex.c (Ian Lance Taylor 2020-12-31 11:23:30 -0800 869)
/* Align the source pointer. *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
--- Comment #12 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> You need -fno-tree-loop-distribution -fno-tree-loop-distribute-patterns to
> turn it off. There is another older bug about this for memcpy.
This is also a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #8 from Andrew Pinski ---
e75b54a2d932 libcpp/lex.c (Richard Earnshaw 2012-03-22 17:54:55 +
869) /* Align the source pointer. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56676
--- Comment #6 from Andrew Pinski ---
GCC 11 produces:
```
_Z3fooPiS_:
.LFB0:
.cfi_startproc
vmovdqu (%rdi), %ymm2
vmovdqu 32(%rdi), %ymm3
vpmulld (%rsi), %ymm2, %ymm1
vpmulld 32(%rsi), %ymm3, %ymm0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56676
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
Andrew Pinski changed:
What|Removed |Added
CC||cookevillain at yahoo dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #10 from Jonathan Wakely ---
(In reply to David Binderman from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > I don't recognise that code, are you sure I wrote it? d4ba3b369c did not
> > touch that code.
>
> No ide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112973
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96580
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=96580
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid, wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #11 from Jonathan Wakely ---
(In reply to David Binderman from comment #5)
> I have the last 18 months or so history and that's a whopping
> 3.8 Gig on it's own.
I have a full clone with all history and it's only 3.3g, I'm not sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #12 from Jonathan Wakely ---
Because otherwise I'm going to get blamed for every bug older than 2022-11-01!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111270#c1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110141
Andrew Pinski changed:
What|Removed |Added
Summary|Wrong code at -O2 on|[12/13/14 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113053
Bug ID: 113053
Summary: local variable misaligned with AddressSanitizer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113053
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
Andrew Pinski changed:
What|Removed |Added
CC||pobrn at protonmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113053
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113053
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Andrew Pinski changed:
What|Removed |Added
CC||pobrn at protonmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-18
Known to fail|
-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/gimple-ssa-sccopy.cc:121:
note: a field with different name is defined in another translation unit
121 | bool active; /* scc_discovery::compute_sccs () only considers a
subgraph of
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113054
--- Comment #1 from Andrew Pinski ---
My suggestion is to wrap most of the code in gimple-ssa-sccopy.cc inside an
anonymous namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113055
Bug ID: 113055
Summary: possibly-const-range missing constraints
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #5 from YunQiang Su ---
It's my fault.
I misunderstanding `reconcat`:
if `optr` is NULL, it cannot work as the `s1` at the sametime.
If so, the return string will be empty.
So, let's define and initial ret like this:
char *ret = c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #6 from YunQiang Su ---
ohh, it should be concat(" ", NULL);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
See Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113054
--- Comment #2 from Andrew Pinski ---
Note I also don't like how dead_stmts is a static variable either but that
would be for another change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113054
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113054
--- Comment #4 from Andrew Pinski ---
Created attachment 56896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56896&action=edit
Patch which I am testing
h
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #1 from Sam James ---
Created attachment 56897
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56897&action=edit
config.log (libgrust)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #2 from Sam James ---
Created attachment 56898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56898&action=edit
build.log.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #3 from Andrew Pinski ---
Well this is not right:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc: not
32 should not be there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #4 from Andrew Pinski ---
Looks like multilib support in libgrust is just broken. I suspect it would be
worse on other targets where there are many more multilibs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #42 from Kewen Lin ---
(In reply to Richard Biener from comment #41)
> What's the "other" testcase? Do we know that doesn't suffer from the same
> uninitialized issue?
For "other" test cases, I guessed he referred to my comment #c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #43 from Kewen Lin ---
Created attachment 56899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56899&action=edit
Previously reduced case for comment 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #5 from Sam James ---
ftr (given I only gave a packaged build log) repro'd with ./configure
--prefix=/tmp/gcc --enable-languages=c,c++,rust --enable-multilib
--with-multilib-list=m32,m64 --with-checking=yes,extra,rtl --disable-analyz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Hi Harald,
I had forgotten about this PR because the fix became incorporated in the
patch for PR89645. In consequence, pr87448.f90 disappeared from the pr87477
failures :-)
One of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
--- Comment #5 from rguenther at suse dot de ---
On Fri, 15 Dec 2023, avieira at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
>
> --- Comment #4 from avieira at gcc dot gnu.org ---
> Drive by comments as it's be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88737
--- Comment #9 from Richard Biener ---
We do now have the analyzer and -Wuse-after-free. I don't think a rust-like
borrow checking feature will ever work or is sensible to implement in C. Use
rust if you need such a feature.
I'm also not sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113057
Bug ID: 113057
Summary: Segmentation fault in dwarf2out.cc:941 with -O
-fno-dwarf2-cfi-asm
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88737
--- Comment #10 from uecker at gcc dot gnu.org ---
I would say it is rather likely that C will get something like this at some
point.
BTW: Any use of the pointer value after free as in comment #2 is UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #6 from Andrew Pinski ---
I just did:
```
mkdir objdir
cd objdir
../configure --enable-languages=rust
make -j24
```
And it work ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #8 from Sam James ---
for the pkg build (original report): no
for the quick test I did earlier: yes because I was rushing, oops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113056
--- Comment #9 from Andrew Pinski ---
I am testing out using an absolute path for configure right now. Seeing if that
changes things ...
98 matches
Mail list logo
