https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
--- Comment #11 from Richard Sandiford ---
Yeah, like I mentioned in the commit message, I'm in the process of rolling
this fix out to more places. Was just testing the waters with the minimal fix
for comment 4.
But yeah, maybe more of it will
ed with: ../configure --prefix=/home/user/gcc-pref
--enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240613 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114789
Sam James changed:
What|Removed |Added
Summary|False positive |[12/13/14 regression] False
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
--- Comment #3 from Gang Peng ---
Dear Sir,
When I build cpp with gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-g++
I meet this error, and the following compilation options are required：
CFLAGS += -fPIE
CFLAGS += -msingle-pic-base
CFLAGS +=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
--- Comment #2 from Gang Peng ---
Created attachment 58423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58423&action=edit
build_code.tar.7z.002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
--- Comment #1 from Gang Peng ---
Created attachment 58422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58422&action=edit
Minimal reproducible example of the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484
Richard Biener changed:
What|Removed |Added
Summary|AVX vectorization is|if-to-switch prevents AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115483
--- Comment #2 from Richard Biener ---
it's again the interaction of store motion, re-assoc and then invariant motion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485
Bug ID: 115485
Summary: CASEServer.cpp:203:1: internal compiler error: in
require_pic_register, at config/arm/arm.c:7855
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484
Bug ID: 115484
Summary: AVX vectorization is limited to 3 comparisons
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113212
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113212
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d8a6de9e2b850b71712e89e8e6026e4ae6284766
commit r15-1305-gd8a6de9e2b850b71712e89e8e6026e4ae6284766
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362
--- Comment #20 from Jon Daniel ---
float s = storage::dot(a.pinr(i), b.pinr(i), c.pinr(i));
float t = storage::dot(a.pinr(j), b.pinr(j), c.pinr(j));
return s-t;
g++ interchanges the operands s-t with t-s: -575-142=-717 != 142-(-575)=717
causi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113212
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115483
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115483
Bug ID: 115483
Summary: Missed optimization for loop invariant code
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Ok, thanks.
2024年6月14日(金) 7:51 Andrew Pinski :
> On Thu, Jun 13, 2024 at 3:43 PM naoki ueda via Gcc-bugs
> wrote:
> >
> > Although "rename" is not a reserved word, there would be a name conflict
> if
> > you used it as a function name.
>
> The rename function is defined as part of the ISO C 90 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115469
--- Comment #3 from Marek Polacek ---
*** Bug 115472 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115472
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115469
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
--- Comment #10 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:9b8c3e622c7cd4ea393f59b873c3107767e1ba88
commit r15-1301-g9b8c3e622c7cd4ea393f59b873c3107767e1ba88
Author: Alexandre Oliva
Date
Although "remove" is not a reserved word, there would be a name conflict if
you used it as a function name.
On Thu, Jun 13, 2024 at 3:43 PM naoki ueda via Gcc-bugs
wrote:
>
> Although "rename" is not a reserved word, there would be a name conflict if
> you used it as a function name.
The rename function is defined as part of the ISO C 90 standard.
Therefore it is considered reserved.
Also this mailing
Although "rename" is not a reserved word, there would be a name conflict if
you used it as a function name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #15 from m.cencora at gmail dot com ---
Thanks!
Unfortunately it seems that your changes broke reexporting of types declared in
other module. It works fine on gcc-14.
$ cat base.cpp
module;
#include
export module base;
export
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115480
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Note the change for GCC 12.3.0 that fix it was r12-8799-gaeba3e009b0abf .
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602548.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
--- Comment #5 from Segher Boessenkool ---
The GCC documentation says
> Note that the 'vec_ld' and 'vec_st' built-in functions always generate
> the AltiVec 'LVX' and 'STVX' instructions even if the VSX instruction
> set is available.
(which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #5 from Jonathan Wakely ---
For output, the requirement to set failbit was present since C++98, not added
by a DR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
--- Comment #10 from Tamar Christina ---
Thanks for the fix, but I don't think it's sufficient.
what I meant with the earlier comment was that the subregs are broken in
general, so not just the one generated by the undef fast path.
i.e.
#incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
--- Comment #3 from Roger Sayle ---
Hi Jeff, many thanks for looking into this/assigning the PR to yourself.
I'd suggest that the fix is to add a define_code_iterator to aarch64.md
called any_or_plus matching the definition in i386.md.
(define_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115482
Bug ID: 115482
Summary: print.cc fails with avrlibc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115481
--- Comment #1 from Andrew Pinski ---
Patch should be sent to gcc-patches@ (and in this case also to libstdc++@)
after reading https://gcc.gnu.org/contribute.html too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
--- Comment #7 from Mital Ashok ---
I think the issue is the same as it was in Clang
The preconditions for `has_unique_object_representations` is
https://eel.is/c++draft/type.traits#tab:meta.unary.prop-row-47-column-3-sentence-1
> T shall be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115481
Bug ID: 115481
Summary: HAVE_* for long double math functions wrong for
avrlibc (target AVR)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115480
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115480
Bug ID: 115480
Summary: Difference between trivial copyability of std::pair
under Clang in C++23
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
--- Comment #6 from Carl Love ---
comment 5, Segher
Yes, I have some PVIPR changes that we have talked about previously. I will
create a patch to also make the changes discussed here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115479
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114004
--- Comment #3 from Segher Boessenkool ---
We have very many similar PRs reported over the years, but more for when the
argument is *signed*, actually! There, we end up with unneeded sign-extension
insns often (which are easier to spot than ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The requirement to set failbit came from
> https://cplusplus.github.io/LWG/issue211 and certainly seems consistent with
> other input operations, which set fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115480
--- Comment #4 from Andrew Pinski ---
Note the change for GCC 12.3.0 that fix it was r12-8799-gaeba3e009b0abf .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115477
--- Comment #2 from Andrew Pinski ---
Note with -fsanitize=address we get errors as one would expect:
=
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7dc0b850003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
--- Comment #4 from Mital Ashok ---
cppreference is wrong
https://eel.is/c++draft/type.traits#tab:meta.unary.prop-row-47-column-2-sentence-1
> For an array type `T`, the same result as
> `has_unique_object_representations_v>`, otherwise see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115480
--- Comment #2 from Andrew Pinski ---
#include
#include
struct trivially_copyable_no_assignment {
int arr[4];
trivially_copyable_no_assignment& operator=(const
trivially_copyable_no_assignment&) = delete;
};
static_assert(std::is_trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115480
--- Comment #1 from Andrew Pinski ---
template
struct is_trivially_copyable
: public integral_constant
Well it is clang front-end issue though it looks like GCC had a similar issue
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453
--- Comment #10 from Andrew Pinski ---
(In reply to Arthur Cohen from comment #9)
> Ah, sorry Andrew, I thought the component was referring to the origin of the
> issue. Just wanted to be able to find it in the list of Rust-related issues.
> Sor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453
--- Comment #9 from Arthur Cohen ---
(In reply to Andrew Pinski from comment #8)
> Toplevel makefile is consider bootstrap component rather than rust ...
Ah, sorry Andrew, I thought the component was referring to the origin of the
issue. Just w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114710
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #7 from Jonathan Wakely ---
I think we can just do this in __ostream_insert:
--- a/libstdc++-v3/include/bits/ostream_insert.h
+++ b/libstdc++-v3/include/bits/ostream_insert.h
@@ -103,6 +103,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-06-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115477
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
--- Comment #6 from Jonathan Wakely ---
It looks like we've been setting badbit in ostream::_M_write(const charT*,
streamsize) since it was added in r0-47606-g8d0a564bba54f7
That function was used to replace the similar code in basic_ostream::wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
--- Comment #6 from Marek Polacek ---
Aha, so
static_assert(__has_unique_object_representations(Foo<0>[]));
is valid and should be treated just like
static_assert(__has_unique_object_representations(Foo<0>));
but
class Foo;
stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69621
Andrew Pinski changed:
What|Removed |Added
CC||awright at tradebot dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
--- Comment #13 from Jakub Jelinek ---
Created attachment 58418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58418&action=edit
gcc15-pr105863-wip.patch
WIP patch, which already does something. Started now working on the testsuite.
I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115479
--- Comment #1 from Andrew Pinski ---
Can you provide a non godbolt version of this using a shell script invoking gcc
directly>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115479
Bug ID: 115479
Summary: undefined reference to [abi:cxx11] with variadic
template of constexpr template structs
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
Bug ID: 115478
Summary: [15 Regression] gcc.target/aarch64/bitint-args.c fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 115194, which changed state.
Bug 115194 Summary: [modules] "reference to is ambiguous" when
multiple paths to same symbol exist through module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115194
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #3 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115461
--- Comment #6 from Ilya Leoshkevich ---
Forgot to add: since the runtime is shared, this observation applies to both
GCC and LLVM.
$ gcc k.c -fsanitize=leak; ./a.out
0x5080
$ LSAN_OPTIONS=use_stacks=0 ./a.out
0x5080
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
--- Comment #5 from Mital Ashok ---
Sorry, I misread the cppreference quote. Though it should be ill-formed instead
of UB I think.
GCC also crashes on this invalid code:
class Foo;
static_assert(__has_unique_object_representations(Foo[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:609764a42f0cd3f6358562cab98fc220d3d2d9fd
commit r15-1297-g609764a42f0cd3f6358562cab98fc220d3d2d9fd
Author: Jason Merrill
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Component|rust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
--- Comment #3 from Marek Polacek ---
In check_trait_type, we do
if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
return true; // Array of unknown bound. Don't care about completeness.
and then end up crashing in r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
Andrew Pinski changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115478
--- Comment #1 from Andrew Pinski ---
r15-1120-g2277f987979445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115477
Bug ID: 115477
Summary: compiling with gcc flips the sign of a float return
value
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
--- Comment #4 from Carl Love ---
comment 1
Yes, I can confirm if I add the alignment statement to the declarations it
works fine.
I originally tried to use the built-in as part of a re-write of a function in
the Milvus AI source code. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
--- Comment #6 from Jonathan Wakely ---
MSVC and libc++ both behave the same as libstdc++, calling rdbuf()->sgetn():
https://github.com/microsoft/STL/blob/e36ee6c2b9bc6f5b1f70776c18cf5d3a93a69798/stl/inc/istream#L522
https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13823
--- Comment #14 from Jonathan Wakely ---
(In reply to Dan Evison from comment #0)
> This seems to a problem with the default allocator, since running the
> program
> with GLIBCPP_FORCE_NEW set, removes the problem, and dramatically speeds up
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115194
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jason at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
Bug ID: 115476
Summary: __has_unique_object_representation ICE with array of
uninstantiated type of unknown bound
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115194
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:8878fecc251762bc32c24e659695557797e03fd9
commit r15-1296-g8878fecc251762bc32c24e659695557797e03fd9
Author: Jason Merrill
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115370
Hongyu Wang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678
--- Comment #4 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:d387ecb2b2f44f33fd6a7c5ec7eadaf6dd70efc9
commit r15-1294-gd387ecb2b2f44f33fd6a7c5ec7eadaf6dd70efc9
Author: Patrick Palka
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115461
--- Comment #5 from Ilya Leoshkevich ---
The LLVM testsuite still passes.
Looking a bit deeper:
$ LSAN_OPTIONS=verbosity=1,log_pointers=1 ./a.out
[...]
0x5080
==1522380==LeakSanitizer: checking for leaks
[...]
==1522381==Scanning STACK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115474
--- Comment #2 from Andrew Pinski ---
Here is a few more:
```
int func(bool a, bool b) {
bool t = b < a;
return t | a; // a
}
int func1(bool a, bool b) {
bool t = b < a;
bool t1 = t < a;
return t | t1; // a
}
int func2(bool a, bool b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021
--- Comment #5 from Hongtao Liu ---
It's fixed by r15-1100-gec985bc97a0157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115463
--- Comment #2 from GCC Commits ---
The master branch has been updated by Hongyu Wang :
https://gcc.gnu.org/g:83a765768510d1f329887116757d6818d7846717
commit r15-1293-g83a765768510d1f329887116757d6818d7846717
Author: Hongyu Wang
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115474
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115463
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115463
Bug 115463 depends on bug 115370, which changed state.
Bug 115370 Summary: [15 regression] gcc.target/i386/pr77881.c FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115370
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115463
--- Comment #3 from Hongyu Wang ---
Should be fixed, but will wait for the confirm of SPEC result on znver/skylake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
--- Comment #8 from Andrew Pinski ---
(In reply to Andi Kleen from comment #7)
> I'm not sure how it would speed up the linker if gcc did it. The linker
> would still need to do it because there might be matches between different
> .o files. Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115370
--- Comment #4 from GCC Commits ---
The master branch has been updated by Hongyu Wang :
https://gcc.gnu.org/g:83a765768510d1f329887116757d6818d7846717
commit r15-1293-g83a765768510d1f329887116757d6818d7846717
Author: Hongyu Wang
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115239
--- Comment #5 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7fed7e9bbc57d502e141e079a6be2706bdbd4560
commit r15-1292-g7fed7e9bbc57d502e141e079a6be2706bdbd4560
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
--- Comment #7 from Andi Kleen ---
I'm not sure how it would speed up the linker if gcc did it. The linker would
still need to do it because there might be matches between different .o files.
Also linker wouldn't know if the compiler supported th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106393
--- Comment #4 from David Malcolm ---
(In reply to Eric Gallager from comment #3)
> (In reply to Marek Polacek from comment #2)
> > The rest may have to be implemented in the analyzer.
>
> Hm, let's ask David?
Please open it as a fresh bug aga
1 - 100 of 149 matches
Mail list logo
