https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #4 from Tobias Burnus ---
(In reply to Steve Kargl from comment #2)
> It seems that bugzilla does not recognize the email address
> that Tobias's uses in ChangeLong. Try to cc him here to see
> if he gets added to the audit trail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #21 from Jakub Jelinek ---
If so, then I don't understand why does t-cygwin-w64 exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #20 from jon_y <10walls at gmail dot com> ---
No, Cygwin does not use fat objects/archives. As far as I know, Cygwin never
shipped multilib capable gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #4 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #3 from Jerry DeLisle ---
(In reply to Steve Kargl from comment #2)
> On Wed, Feb 01, 2023 at 06:13:33PM +, kargl at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
> >
> > This appears to be relat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108632
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #4 from Sam James ---
Patch sent to kernel:
https://lore.kernel.org/linux-hardening/20230201230009.2252783-1-...@gentoo.org/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #3 from Andrew Pinski ---
Not a GCC bug.
plugins need to compiled with the same C++ settings as what GCC was compiled
with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #1 from Arsen Arsenović ---
The kernel's using wrong C(XX)FLAGS to compile the plugin. IMO, the best
solution would be to dump $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) into a makefile
that gets installed, so that plugins can use that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108613
--- Comment #7 from Jonathan Wakely ---
OK, thanks for confirming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
Bug ID: 108634
Summary: [13 regression] 'undefined symbol: tree_code_type'
when building kernel GCC plugins since
r13-5431-gb0241ce6e37031
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108613
--- Comment #6 from Serdar Sanli ---
> Where did you get this from? The header uses signed __int128
> here, not signed __int128_t.
Just checked and __GLIBCXX_TYPE_INT_N_0 is also __int128 for me. int128_t seem
to come from somewhere else, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #9 from Marek Polacek ---
But even that won't work for Wdangling-reference6.C where the argtype is int
but the rettype is std::pair.
Really, all I could do is to warn only when all the arguments to the function
returning a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #13 from H.J. Lu ---
Created attachment 54389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54389&action=edit
A patch for GCC 12 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077
--- Comment #6 from Sergei Trofimovich ---
Not actively working on it. A bit of discussion from #gcc:
21:41:59 < pinskia> note your patch is incorrect
21:42:10 < trofi_> yup
21:42:13 < pinskia> it should just not add t-linux64 for musl
21:42:31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104883
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Which causes errors when we rely on that being present, e.g. for AVR:
>
> /home/jwakely/src/gcc/build-avr/avr/libstdc++-v3/include/charconv: In
> function ‘
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104883
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2d2e163d12f64a5e68f9e0381751ed9d5d6d3617
commit r13-5638-g2d2e163d12f64a5e68f9e0381751ed9d5d6d3617
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108632
--- Comment #2 from Jonathan Wakely ---
(In reply to Hans-Peter Nilsson from comment #0)
> The test appears to assert that the footprint of hh_mm_ss is
> minimal, but for that, S0 misses a trailing empty member for
> hh_mm_ss , which for most ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
Jonathan Wakely changed:
What|Removed |Added
Keywords||build, lto
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #8 from Marek Polacek ---
(For std::any et al I guess we also have to look for void*.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69836
--- Comment #5 from Jason Merrill ---
(In reply to Jason Merrill from comment #4)
> Here, the
> problem looks to be that we're re-calculating the type of w_counter inside
> the function definition (where the current function is in the overload se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69836
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:88a2a09dd4529107e7ef7a6e7ce43acf96457173
commit r13-5636-g88a2a09dd4529107e7ef7a6e7ce43acf96457173
Author: Harald Anlauf
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
Bug ID: 108633
Summary: -Wanalyzer-fd-type-mismatch erroneously emitted on
missing error-checking in qemu's
tests/qtest/libqtest.c
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108613
--- Comment #5 from Jonathan Wakely ---
(In reply to Serdar Sanli from comment #0)
> https://godbolt.org/z/M1o34e6cx
>
> Below code crashes GCC versions starting with GCC 12. It is only stuff from
> std library headers, I've copied bits from pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #19 from Jakub Jelinek ---
I don't know either. Maybe objdump would print something.
Anyway, looking at config-ml.in, it seems like the empty directory name would
basically
disable that multilib:
multidirs=
for i in `${CC-gcc} --pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #16 from Jakub Jelinek ---
__extension__
template
using __is_signed_integer = __is_one_of<__remove_cv_t<_Tp>,
signed char, signed short, signed int, signed long,
signed long long
#if defined(__GLIBCXX_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #18 from James McKelvey ---
I don't know. How do I tell? I'm pretty sure they are just 64-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #15 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #14)>
> Those are all correct. They don't use the __int128_t typedef, only the
> keyword.
Then I wonder how someone got the reduced testcase from PR 108613 which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #17 from Jakub Jelinek ---
And those are libraries containing 64-bit objects, 32-bit objects, mixture of
that (FAT objects)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #3 from Jakub Jelinek ---
Strictly speaking, in this case I think it isn't invalid, puts is a standard
function and implementation could treat it as a builtin with known behavior
(that it doesn't care about pointer equality of what i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #8 from joseph at codesourcery dot com ---
See also bug 102989 (C2x _BitInt) regarding another case for which growing
TYPE_PRECISION would be useful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103869
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #16 from James McKelvey ---
$ find /usr/local/lib/gcc -name libgcc_s\*.dll -o -name libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/11.3.1/libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/12.1.1/libgcc.a
/usr/local/lib/gcc/x86_64-pc-cygwin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #15 from Jakub Jelinek ---
(In reply to James McKelvey from comment #14)
> Okay I installed gcc-12, built about 10/29/2022:
>
> $ g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #14 from James McKelvey ---
Okay I installed gcc-12, built about 10/29/2022:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/12.2.1/lto-wrapper.exe
Target: x86_64-pc-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609
--- Comment #2 from seurer at gcc dot gnu.org ---
I tried the patch and it seems to work fine.
make -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/pr108527.f90"
# of expected passes3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #7 from Marek Polacek ---
Sure, I could (lookup_member?). It's still just guessing but maybe it would be
worth it. Let me try...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #2 from Marat Radchenko ---
Thanks for the pointer to -fmerge-all-constants, that helped me to google out
why such transformation is invalid: https://stackoverflow.com/a/70328102
Should I close this issue as INVALID (and probably op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #2 from Steve Kargl ---
On Wed, Feb 01, 2023 at 06:13:33PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
>
> This appears to be related to Sandra and Tobias's work on CFI. In particula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-02-01
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> Aldy/Andrew, any ideas about this?
patch already in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #5 from Marek Polacek ---
Sorry, I'm not sure if the false positive in comment 0 can be fixed. I can't
simply compare the type of the temporary argument and the return type, because
we may be returning a subobject of the temporary a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:8495d80f44488b2566afc84b3f5704dd7c999e21
commit r12-9096-g8495d80f44488b2566afc84b3f5704dd7c999e21
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
--- Comment #13 from Jakub Jelinek ---
I have tried a cross with the genmultilib exit 1 commented out, and the
difference between the previous state of just MULTILIB_DIRNAMES = 64 and 64 32
is
--- multilib.h 2023-02-01 18:41:31.013661359 +0100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #7 from Michael Meissner ---
Created attachment 54387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54387&action=edit
Proposed patch combining Richard's patch and an assertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2023-02-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103994
--- Comment #2 from Melven.Roehrig-Zoellner at DLR dot de ---
Can confirm this with current trunk (see https://godbolt.org/z/16K1jhrsW).
I stumbled upon this while trying to include the C++ library Eigen in the
global module fragment (same stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #5 from Segher Boessenkool ---
The failure was not detected, only things down the road broke up, can we add
something for that? Just a strategically placed assert should do fine.
Less important if we grow the field all the way to 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #7 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:9fadd8dec79876d3c393daccc62959f6f4853cc5
commit r13-5634-g9fadd8dec79876d3c393daccc62959f6f4853cc5
Author: Gaius Mulley
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551
--- Comment #11 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:9fadd8dec79876d3c393daccc62959f6f4853cc5
commit r13-5634-g9fadd8dec79876d3c393daccc62959f6f4853cc5
Author: Gaius Mulley
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108632
--- Comment #1 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:a939dd835798efd40b78f7c0070177616e3f36d3
commit r13-5633-ga939dd835798efd40b78f7c0070177616e3f36d3
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #4 from Michael Meissner ---
I must have missed the spare bits. I think it is better to use the full 16
bits for precision. I also think your other changes to realign bit fields
greater than 1 bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
Jakub Jelinek changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jakub Jelinek changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #1 from Andrew Pinski ---
I think what clang did is an invalid transformation.
You can use -fmerge-all-constants to get this same transformation in gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #20 from Tamar Christina ---
> > I don't think so for addhn, because it wouldn't truncate the top bits, it
> > truncates the bottom bits.
> >
> > The instruction does
> > element1 = Elem[operand1, e, 2*esize];
> > element2 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #13 from dhekir at gmail dot com ---
Thank you very much for the work.
Running the attached file with `-O -finline-small-functions` does compile in
under 30 seconds on my computer.
However, when trying to compile the original progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #12 from dhekir at gmail dot com ---
Created attachment 54386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54386&action=edit
another test case, this time with 1M calls and structs as arguments
A more complex test case, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107017
--- Comment #1 from David Malcolm ---
Should probably also handle scanf-style functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #6 from Gaius Mulley ---
Will do - I'm currently seeing problems on a bootstrap build and regression
tests
(after a rebase). Once this clears I'll commit / push the changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #10 from Kyle Shores ---
Ah, wait I lied. I must not have recompiled or something because everything
works now. Thank you again for addressing this and sorry for submitting a false
positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #5 from Andrew Macleod ---
I do not seem to be able to reproduce this... is it still valid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559
--- Comment #6 from Marek Polacek ---
*** Bug 108627 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108627
Marek Polacek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #5 from Martin Liška ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54383 [details]
> Proposed fix v2
>
> Here is version 2 of the proposed fix which should also help resolve
> PR modula2/108551.
>
> Note a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #11 from Andrew Macleod ---
To be clear, the reason it is unlikely to be ported to GCC12 is because this
depends on relation support in GORI to recognize the LHS and operand 1 are
equivalent. That support was first added in GCC13, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Barnabás Pőcze changed:
What|Removed |Added
CC||pobrn at protonmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108632
Bug ID: 108632
Summary: [13 Regression] libstdc++ std/time/hh_mm_ss/1.cc on
"packed" platforms
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
Martin Liška changed:
What|Removed |Added
CC||Mayshao-oc at zhaoxin dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #6 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:881bf8de9b07fb501d61ade8f521f1cc9dbe712e
commit r13-5630-g881bf8de9b07fb501d61ade8f521f1cc9dbe712e
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
--- Comment #4 from Jakub Jelinek ---
I think the problem is that normally when gimplifying
OMP_CLAUSE_LASTPRIVATE_STMT we force a BIND_EXPR around it:
push_gimplify_context ();
if (TREE_CODE (OMP_CLAUSE_LASTPRIVATE_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #11 from ValdikSS ---
Well, the function is called __builtin_cpu_supports, for which one might expect
that it just checks CPUID and returns reliable results, while in reality it
operates using the build-in CPU support list. The funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:78589691ee158e689fa9bb7dec1165da475ea634
commit r13-5629-g78589691ee158e689fa9bb7dec1165da475ea634
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108628
Martin Liška changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #10 from Martin Liška ---
(In reply to ValdikSS from comment #9)
> May I ask why was is closed as WONTFIX?
Because we're not planning to support such legacy hardware.
> It fails on VIA Eden Eshter.
Is it critical that the feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
--- Comment #6 from David Malcolm ---
Another example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598#c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598
--- Comment #3 from David Malcolm ---
Yeah, it would be good if -fanalyzer detected such issues within loops, and
identified the iteration at which the access goes out-of-bounds. Handling that
is bug 108432 (which I'm treating as an RFE).
Than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Summary|[10/11/12/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:fb2d50f72caf3b84b315bc760368670680999749
commit r12-9095-gfb2d50f72caf3b84b315bc760368670680999749
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:5ce8961b46f050a96e8c542b34b1cf024ba95f1b
commit r13-5627-g5ce8961b46f050a96e8c542b34b1cf024ba95f1b
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #2 from Andre Heider ---
Additionally, LDFLAGS_FOR_TARGET isn't part of the configure help:
./configure --help|grep FOR_TARGET
LD_FOR_TARGET is, attempting to shove LTO in there yields other problems (or I
am be doing it wrong).
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108135
Martin Liška changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108481
--- Comment #6 from Jakub Jelinek ---
I'd say the implementation intends to warn about UB that still remains in the
code after optimizations, if a result of some UB invoking operation isn't used
(the DCE case) or as in this case the UB happens o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:1d77bfdf11fb9d7f9fcce7ed8817fc2877b3ded2
commit r13-5626-g1d77bfdf11fb9d7f9fcce7ed8817fc2877b3ded2
Author: Martin Liska
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108481
Jakub Jelinek changed:
What|Removed |Added
Known to work|12.2.0 |
Summary|[13 Regression] UBs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #1 from Andre Heider ---
Forgot to mention:
CXXFLAGS_FOR_TARGET="$CFLAGS_FOR_TARGET"
Obviously :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631
--- Comment #1 from Martin Liška ---
Created attachment 54384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54384&action=edit
Patch candidate
Please check what you get with -fmem-report with the suggested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631
Bug ID: 108631
Summary: gcc/rust/backend/rust-constexpr.cc:2099:33: error: too
few arguments to function ‘tree_node*
Rust::Compile::unshare_constructor(tree, const char*,
1 - 100 of 133 matches
Mail list logo
