https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107505
Bug ID: 107505
Summary: [13 Regression] ICE: verify_flow_info failed (error:
returns_twice call is not first in basic block 2)
Product: gcc
Version: 13.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107506
Bug ID: 107506
Summary: [regression]
cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023: stack
smashing detected during RTL pass: expand in function
__absvdi2 (gen_mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #15 from CVS Commits ---
The master branch has been updated by HaoChen Gui :
https://gcc.gnu.org/g:eaba55ffef961c28f6a15d845a4d6b77b8a8bab1
commit r13-3603-geaba55ffef961c28f6a15d845a4d6b77b8a8bab1
Author: Xionghu Luo
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106811
Nuno Lopes changed:
What|Removed |Added
CC||nunoplopes at sapo dot pt
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107506
jcmvbkbc at gcc dot gnu.org changed:
What|Removed |Added
CC||jcmvbkbc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107506
Triffid Hunter changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104872
--- Comment #4 from Benjamin Buch ---
Can you please increase the priority? P3 seems too low for the wrong code. With
ICE I could understand that, but here the code seems to be compiled
successfully and then crashes when running the program. Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104872
--- Comment #5 from Jonathan Wakely ---
P2 is used to mark regressions that already exist on released versions, P1 is
for regressions that are new on trunk and not in any release yet. Everything
else is P3.
Changing it would serve no real purpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107239
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-11-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102217
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102217
--- Comment #5 from Jonathan Wakely ---
I also see the ICE on trunk (but not the release branches) so I suspect it's
related to --enable-checking
cocrash.cxx: In function 'Co::Task FooC(bool)':
cocrash.cxx:171:1: internal compiler error: in fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104872
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504
--- Comment #3 from Jonathan Wakely ---
I'm also seeing similar jumps back and forth in the debugger for the bodies of
lambda expressions, where the debugger keeps jumping back to the capture list
of the lambda:
$ cat lambda.cc
int main(int a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |c++
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107507
Bug ID: 107507
Summary: Conversion function templates are not sometimes not
considered if the return type is type dependent
Product: gcc
Version: 12.2.1
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #3 from Jonathan Wakely ---
N.B. making the dtor constexpr doesn't change anything. Unsurprising, since
that just says it's usable in constant expressions, it doesn't mean the
destructor is trivial and can be elided. Worth a try thou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #4 from R. Diez ---
The 'constant_init' wrapper with the 'union' inside is a contrived hack, isn't
it? We may as well use a different hack then.
How about a combination of '__attribute__ constructor' and 'placement new' like
this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107492
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cf35818a390e7cb4b1a4fa70c243ede59d6cbbac
commit r13-3607-gcf35818a390e7cb4b1a4fa70c243ede59d6cbbac
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #5 from R. Diez ---
I know very little about GCC, but it is a very smart compiler, so I am having a
hard time understanding how GCC could miss so many optimisations. After all,
even when compiling with little optimisation, GCC seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #6 from Jonathan Wakely ---
You can't use placement new in a constexpr constructor, so it can't be
constinit, which means it is susceptible to the static initialization order
fiasco. init priority attributes are also a hack, and less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #7 from Jonathan Wakely ---
(In reply to R. Diez from comment #5)
> First of all, GCC seems unable to generate an empty routine or destructor,
> or at least flag it as being effectively empty. The caller should then
> realise that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107508
Bug ID: 107508
Summary: Invalid bounds due to bogus reallocation on assignment
with KIND=4 characters
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #4 from Jakub Kulik ---
Thanks for the confirmation.
-fsplit-stack on Solaris would be nice, but it's as simple as designating a TLS
accessible slot, right? We have our own linker on Solaris and don't use gold,
and I am not how feas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107509
Bug ID: 107509
Summary: wrong ambiguous overloaded function error if argument
class is undefined
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #8 from R. Diez ---
Why does this 'eh_globals' object have to use a constexpr constructor?
How does the current code avoid the "static initialization order fiasco"? If
the user defines his/her own static C++ objects, how is it guara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #9 from R. Diez ---
> [...]
> not just "turn on -Os and all the code gets removed".
I am sure that the solution is not as trivial as "turn on -Os". But, as an
outsider, it is hard to believe that it "takes non-trivial analysis of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504
--- Comment #4 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #3)
> I'm also seeing similar jumps back and forth in the debugger for the bodies
> of lambda expressions, where the debugger keeps jumping back to the capture
> lis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #16 from Jonathan Wakely ---
For the record, r12-8589-gade3197134cc9e was needed to fix something in the
commits above, and was also backported to gcc-12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #10 from Jonathan Wakely ---
(In reply to R. Diez from comment #8)
> Why does this 'eh_globals' object have to use a constexpr constructor?
So it can be constinit.
> How does the current code avoid the "static initialization order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471
Jonathan Wakely changed:
What|Removed |Added
Summary|Instruction reordering |Debugger jumps back to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #11 from Jonathan Wakely ---
Reduced:
extern "C" int puts(const char*);
struct A
{
constexpr A() { }
~A() { puts("bye"); }
};
namespace
{
struct constant_init
{
union {
A obj;
};
constexpr constant_init(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #17 from Jeffrey A. Law ---
Vineet: I don't know your priorities and such, but I've got a junior engineer
starting in a bit under two weeks and this would actually be a good issue for
them to tackle as part of learning about GCC. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107486
David Malcolm changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[13 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
Andrew Pinski changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2006-02-05 21:10:26 |2022-11-2
--- Comment #12 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93371
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:abaa32c7384edef065c79741764bc112dd18f32d
commit r13-3611-gabaa32c7384edef065c79741764bc112dd18f32d
Author: Rasmus Villemoes
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
R. Diez changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #13 from R. Diez ---
>From
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532
--- Comment #4 from Andrew Pinski ---
Created attachment 53820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53820&action=edit
Patch which is under test
This is patch 1 of 2. The 2nd patch adds the assert to catch this earlier on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107505
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
> The bug is either in tree_nonzero_bits and should not be doing:
> return wi::shwi (-1, TYPE_PRECISION (TREE_TYPE (t)));
Just FYI, TYPE_PRECISION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #5 from Ian Lance Taylor ---
Good point, I did forget about using gold or lld. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #18 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #17)
> Vineet: I don't know your priorities and such, but I've got a junior
> engineer starting in a bit under two weeks and this would actually be a good
> issue for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #19 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #13)
> Trying 7, 8, 9 -> 10:
> 7: r140:DI=0x1
> 8: r141:DI=r140:DI<<0x26
> REG_DEAD r140:DI
> REG_EQUAL 0x40
> 9: r139:DI=r141:DI-0x40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #14 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105483
Andrew Pinski changed:
What|Removed |Added
Known to work||7.1.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #20 from Jeffrey A. Law ---
Yea, I think so (3 shifts). Two for masking, one to put the bits in the right
position. Then we just have to figure out how to combine the initial shift
with the 3 for the masking and ultimately result w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
--- Comment #13 from Jonathan Wakely ---
*** Bug 107500 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #15 from Jonathan Wakely ---
(In reply to R. Diez from comment #13)
> From your comments about "constexpr constructor" and "constinit", I gather
> that the "eh_globals" singleton is guaranteed then to be initialised very
> early, ear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104118
Andrew Pinski changed:
What|Removed |Added
Target Milestone|11.4|11.3
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105382
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107505
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107510
Bug ID: 107510
Summary: gcc/config/gcn/gcn.cc:4930:9: style: Same expression
on both sides of '||'. [duplicateExpression]
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107510
Andrew Pinski changed:
What|Removed |Added
Target|gcn |amdgcn-*-*
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #3 from Andrew Pinski ---
Created attachment 53821
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53821&action=edit
testcase -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106643
--- Comment #2 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:da8e0e1191c5512244a752b30dea0eba83e3d10c
commit r13-3616-gda8e0e1191c5512244a752b30dea0eba83e3d10c
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106643
--- Comment #3 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:f6ce1e77bbf5d3a096f52e674bfd7354c6537d10
commit r13-3617-gf6ce1e77bbf5d3a096f52e674bfd7354c6537d10
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668
--- Comment #9 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:f6ce1e77bbf5d3a096f52e674bfd7354c6537d10
commit r13-3617-gf6ce1e77bbf5d3a096f52e674bfd7354c6537d10
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
Andrew Pinski changed:
What|Removed |Added
Target|powerpc64le-linux |powerpc64*-linux-*
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107511
Bug ID: 107511
Summary: [13 Regression] gcc-13-20221030 failure to build on
Cygwin due to lack of secure_getenv
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105344
--- Comment #1 from Andrew Pinski ---
(In reply to Jan Polasek from comment #0)
> https://godbolt.org/z/ozf1MbG3n shows this code works fine under MSVC.
You don't try to use foo afterwards.
Once you do, MSVC will have an ICE.
try:
```
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107511
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107511
--- Comment #1 from Andrew Pinski ---
I suspect adding:
#ifndef _GNU_SOURCE
// Cygwin needs this for secure_getenv
# define _GNU_SOURCE 1
#endif
at the beginging of eh_alloc.cc fixes the issue; just like what was done for
src/c++17/fs_ops.cc, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107511
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-11-02
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107511
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107512
Bug ID: 107512
Summary: Defaulted virtual destructor not considered in
constexpr context
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107512
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
Andrew Pinski changed:
What|Removed |Added
CC||kacper.slominski72 at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107513
Bug ID: 107513
Summary: [Feature Request] Implement
__attribute__((__nodebug__))
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107513
--- Comment #1 from Andrew Pinski ---
GCC's artificial attribute should be similar for functions:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#index-artificial-function-attribute
Which was added in GCC 4.3.0 by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107513
--- Comment #2 from Roy Jacobson ---
I might be using it wrong? But it doesn't seem to do anything:
https://godbolt.org/z/9bdKhz4E7
It would be nice to at least avoid having the function's name in the binary,
clang does it with nodebug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106643
Thomas Schwinge changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107513
--- Comment #3 from Andrew Pinski ---
(In reply to Roy Jacobson from comment #2)
> I might be using it wrong? But it doesn't seem to do anything:
> https://godbolt.org/z/9bdKhz4E7
>
> It would be nice to at least avoid having the function's nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532
--- Comment #6 from Andrew Pinski ---
Patch submitted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604914.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107513
--- Comment #4 from Jonathan Wakely ---
But what does DW_AT_artificial do? Does gdb just ignore it? I've never noticed
it helping at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105328
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #9 from Rama Malladi ---
(In reply to Rama Malladi from comment #8)
> (In reply to Wilco from comment #7)
> > The revert results in about 0.5% loss on Neoverse N1, so it looks like the
> > reassociation pass is still splitting FMAs i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106829
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f755e367117ca43c96235ef47d4915c3746a3483
commit r12-8883-gf755e367117ca43c96235ef47d4915c3746a3483
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981
--- Comment #11 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a46f71c1a5c286b8cc4802fffe235909016cd34f
commit r12-8884-ga46f71c1a5c286b8cc4802fffe235909016cd34f
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:31f25cf4ef9a0a0ccc0b0f9158773c5a71e74cc5
commit r12-8889-g31f25cf4ef9a0a0ccc0b0f9158773c5a71e74cc5
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107001
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:c8dc6b06daf910b758bb964116ada2c5070de764
commit r12-8885-gc8dc6b06daf910b758bb964116ada2c5070de764
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107121
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7d5e6cd2d3f00d463705a5046b2920680a0ab7a9
commit r12-8886-g7d5e6cd2d3f00d463705a5046b2920680a0ab7a9
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:20ef7d7c578dab0585d70fbea571a74e8e8d4b47
commit r12--g20ef7d7c578dab0585d70fbea571a74e8e8d4b47
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300
--- Comment #3 from Andrew Pinski ---
Something like:
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 7c5f90b5127..185e0ac53f7 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -11203,6 +11203,13 @@ finish_static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305
--- Comment #2 from Andrew Pinski ---
>The code to explicitly exclude "obvious" directories is here
That code has been there since before 1993. So I wonder if all other ld's
always included /usr and /usr/lib by default. It is only the newer one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #21 from Vineet Gupta ---
I've been experimenting with
(define_predicate "consecutive_bits_operand"
(match_code "const_int")
{
unsigned HOST_WIDE_INT val = UINTVAL (op);
if (exact_log2 ((val >> ctz_hwi (val)) + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305
--- Comment #3 from Rui Ueyama ---
By other ld's, what linkers did you have in your mind? If lld, mold and gold
don't hard code /usr and /usr/lib, then the only remaining linker is GNU ld.
It doesn't seem like POSIX says about the default libra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106806
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:20d5dca80b82df9b1295359edb44eb08c45c4334
commit r13-3621-g20d5dca80b82df9b1295359edb44eb08c45c4334
Author: Kewen Lin
Date: Thu Nov 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106806
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
95 matches
Mail list logo
