https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112741
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112742
Bug ID: 112742
Summary: missed vectorization with src[a*b+i] where a*b is not
int rather than same percission as size_type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112741
Bug ID: 112741
Summary: ICE: in gimplify_var_or_parm_decl, at gimplify.cc:3261
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #52 from post+gcc at ralfj dot de ---
For the point discussed earlier with the `restrict` in the musl memcpy, I had
another look at the definition of `restrict` and it's not entirely clear to me
any more that there is UB here. The rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #51 from post+gcc at ralfj dot de ---
Oh great, I love it when one part of the C standard just adds exceptions to
statements made elsewhere. It's almost as if the authors want this to be as
hard to understand as possible...
That then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112722
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112713
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740
Bug ID: 112740
Summary: [14 Regression] wrong code with vector compare on
riscv64 at -O0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112710
--- Comment #3 from Zdenek Sojka ---
(In reply to Ian Lance Taylor from comment #2)
> Also -fdump-go-spec isn't useful for C++ code.
>
> Why does this come up? What are you trying to do?
I am trying nothing else than to crash the compiler. Pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52252
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
Jose E. Marchesi changed:
What|Removed |Added
CC||david.faust at oracle dot com
--- Co
On Mon, Nov 27, 2023 at 8:24 PM Lew Robin via Gcc-bugs
wrote:
>
> This error happens when using macro and template.
> GCC Version: gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
> OS: ubuntu 22.04 (x64)
> Compile Command:
> g++-12 ./testmacro.cc --std=c++20
>
> In fact, this error exisits from
This error happens when using macro and template.
GCC Version: gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
OS: ubuntu 22.04 (x64)
Compile Command:
g++-12 ./testmacro.cc --std=c++20
In fact, this error exisits from g++11 to g++13. I also test it on clang and
msvc, but it cannot be reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #3 from Hongyu Wang ---
Created attachment 56703
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56703&action=edit
A patch
Hi Rainer, can you help verify if the change make these test pass on
solaris/FreeBSD?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #17 from Li Pan ---
(In reply to Robin Dapp from comment #15)
> Does the =m fix your issue? Or is the code gen different then and we're
> just lucky? For my problem it doesn't help because we still don't recognize
> an alias betwee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #2 from Hongyu Wang ---
The cfi scan fails was caused by -fno-omit-frame-pointer which force push the
frame pointer first and the cfi info become different. By default we have
-fomit-frame-pointer on linux, but not other targets. I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Lewis Hyatt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #7 from GCC Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:ce52f1f7074d96c4d9ce63b1169c11087757e926
commit r14-5898-gce52f1f7074d96c4d9ce63b1169c11087757e926
Author: Lewis Hyatt
Date: Mon N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #10 from Kewen Lin ---
(In reply to HaoChen Gui from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > Yeah, it tested for ISA 2.04 before. That was an attempt at including 476
> > probably?
> >
> > We really shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112713
--- Comment #1 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9c16ca93641ad460a576a9ed7daf2aadf596193c
commit r14-5897-g9c16ca93641ad460a576a9ed7daf2aadf596193c
Author: Juzhe-Zhong
Date: Mon Nov 27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112734
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #9 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #8)
> Yeah, it tested for ISA 2.04 before. That was an attempt at including 476
> probably?
>
> We really should have a TARGET_FCTID, on for TARGET_POWERPC64 or f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #10 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #9)
> var-tracking is very compile time intensive,
> so it would significantly slow down -O0 compilation.
Indeed, these are the timings of "time make" that I observe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Lewis Hyatt changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112710
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91225
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Keywords|diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91225
Andrew Pinski changed:
What|Removed |Added
CC||kxiang at umich dot edu
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112739
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97598
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112739
Yiming Xiang changed:
What|Removed |Added
Summary|variable 'a' is |Not emitting warning when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112739
Bug ID: 112739
Summary: variable 'a' is uninitialized when used within its own
initialization
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112738
--- Comment #2 from Andrew Pinski ---
This is what I will be testing:
```
/* (nop_outer_cast)-(inner_cast)var -> -(outer_cast)(var)
if var is smaller in precision.
This is always safe for both doing the negative in signed or unsigned
as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #50 from joseph at codesourcery dot com ---
Qualifiers on function parameter types do not affect type compatibility or
composite type (see 6.7.6.3#14). I think they're only actually of
significance in the definition; in a declarati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112738
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Summary|forwprop4 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668
--- Comment #9 from Krister Walfridsson ---
I opened PR 112738 for the issue mentioned in comment 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112738
Bug ID: 112738
Summary: forwprop4 introduces invalid wide signed Boolean
values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to GCC Commits from comment #2)
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/pr110279-1.c: New test.
>
> This testcase fails on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112454
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d29d27bde5df89e5357e0a33a71bb49125bd1655
commit r14-5893-gd29d27bde5df89e5357e0a33a71bb49125bd1655
Author: Andrew Pinski
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737
Bug ID: 112737
Summary: [14 Regression] g++.dg/modules/xtreme-header-2_b.C
-std=c++2b (test for excess errors)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:cd2519a6f857539262398f3ff63b53de173e2a88
commit r14-5892-gcd2519a6f857539262398f3ff63b53de173e2a88
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279
--- Comment #3 from Andrew Pinski ---
(In reply to GCC Commits from comment #2)
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr110279-1.c: New test.
This testcase fails on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736
Andrew Pinski changed:
What|Removed |Added
Summary|vectorizer is introducing |[14 Regression] vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736
Bug ID: 112736
Summary: vectorizer is introducing out of bounds memory access
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109077
--- Comment #2 from David Malcolm ---
PLUGIN_ANALYZER_INIT was added in r11-5583-g66dde7bc64b75d, so presumably this
affects GCC 11 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109077
David Malcolm changed:
What|Removed |Added
Blocks||107646
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111705
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=107939
--- Comment #12 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:c9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
commit r12-10017-gc9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269
--- Comment #15 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
commit r12-10016-g6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #11 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:c9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
commit r12-10017-gc9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #10 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
commit r12-10016-g6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
--- Comment #5 from Indu Bhagat ---
The reason for the noted difference in BTF for BPF vs non-BPF target is:
On non-BPF targets, BTF is emitted in early_finish. On BPF target however,
-mco-re is default, and hence, BTF is emitted in late finish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
Indu Bhagat changed:
What|Removed |Added
CC||ibhagat at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112735
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112735
--- Comment #1 from Andrew Pinski ---
Testing a fix. And this is a dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112735
Bug ID: 112735
Summary: [14 regression] gcc.dg/tree-prof/time-profiler-3.c
fails after r14-5666-g41aacdea55c5d7
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112712
--- Comment #2 from Mikael Pettersson ---
It appears the test case comes from https://github.com/dxx-rebirth/dxx-rebirth/
(a port of the old Descent game engine).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #51 from Sam James ---
manolis, did you have a chance to look at the remaining pass issue? You'll need
to revert Dave's commit locally which made the issue latent for building
Python.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #24 from Jakub Jelinek ---
As the pass seems to work on one basic block at the time (everything from
analysis to actual changes), I wonder if e.g. get_uses shouldn't punt if it
sees (non-DEBUG_INSN!) uses in other basic block but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #23 from Jakub Jelinek ---
Looking around, seems do_analysis properly finds out both uses of the %r10 +=
96 - the store of %r5 later in the same bb and store of %r9 earlier in the same
bb (at the start of it), and continues because b
es=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651
anlauf at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #22 from Jakub Jelinek ---
Full executable testcase:
struct tree_base
{
int code:16;
};
struct saved_scope
{
void *pad[14];
int x_processing_template_decl;
};
struct saved_scope *scope_chain;
struct z_candidate
{
tree_base *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
--- Comment #2 from Andrew Pinski ---
I linked PR 100499, not that it caused the issue here but talks about the
issues in multiple_of_p .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
--- Comment #1 from Andrew Pinski ---
multiple_of_p is one big source of bugs ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
ls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (gc9d691a7daa)
ra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #21 from Jakub Jelinek ---
Reduced testcase (though, just the function in question, not a runable
testcase):
struct tree_base
{
int code:16;
};
struct saved_scope
{
void *pad[14];
int x_processing_template_decl;
};
extern struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112725
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112731
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112731
Bug ID: 112731
Summary: [14 regression] Excess errors for
c-c++-common/builtin-classify-type-1.c after
r14-5615-g509b470dcee979
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711
--- Comment #6 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112721
--- Comment #2 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #5 from Andrew Pinski ---
(In reply to Lewis Hyatt from comment #4)
> Here is the fix. Not sure if it needs to wait for GCC 15 by now, but I can
> submit it with the testcase.
Bugs can be fixed during stage 3 (just no new __major__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599
Patrick O'Neill changed:
What|Removed |Added
Attachment #56662|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #15 from Jan Hubicka ---
Thanks a lot for working on this! I think it is quite importnat part of
the puzzle of making libstdc++ vector working reasonably well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638104.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
Patrick O'Neill changed:
What|Removed |Added
Attachment #56661|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
--- Comment #10 from Patrick O'Neill ---
See Andrew's comment on pr112583 - the new failures when comparing with the
previous report are already tracked and appear on other architectures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112727
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
Patrick O'Neill changed:
What|Removed |Added
Attachment #56660|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
Patrick O'Neill changed:
What|Removed |Added
Attachment #56659|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
--- Comment #12 from GCC Commits ---
The master branch has been updated by Prathamesh Kulkarni
:
https://gcc.gnu.org/g:2065438db4ac13af7e0de2f934959413647f74a7
commit r14-5890-g2065438db4ac13af7e0de2f934959413647f74a7
Author: Prathamesh Kulkar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #20 from Jakub Jelinek ---
Manolis/Jeff, how does the pass prove that it found and adjusted all the uses
of the register rather than just some (or the first one) as apparently happens
on this testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #19 from Jakub Jelinek ---
When using current trunk (r14-5889), I can see it even in x86_64-linux ->
powerpc64le-linux cross-compiler.
diff -U300 pr111601.s{1,2}
will show
std 9,0(10)
mr 10,9
+ addi 10,10,96
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #18 from Jakub Jelinek ---
Created attachment 56697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56697&action=edit
pr111601.ii.xz
Preprocessed source, compile with
./cc1plus -quiet -fpreprocessed -O2 -fprofile-generate -fno-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
Thomas Schwinge changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 214 matches
Mail list logo
