https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #10 from Jordi Mallach ---
OK, to avoid the .gch includes, build with PRECOMPILE=0 REGENIE=1. I'm
attaching the result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #12 from Jordi Mallach ---
Created attachment 39748
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39748&action=edit
s file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #11 from Jordi Mallach ---
Created attachment 39747
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39747&action=edit
ii file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77841
Bug ID: 77841
Summary: a new expression of a char array cannot be initialized
by a string literal
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77798
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
Richard Biener changed:
What|Removed |Added
CC||gmc at synopsys dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77832
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77833
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||assemble-failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821
--- Comment #3 from Richard Biener ---
If you force (not sure what's the default on your target) -fno-fat-lto-objects
then you'll notice if LTO is used at link time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77828
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
Tamar Christina changed:
What|Removed |Added
CC||tamar.christina at arm dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77828
--- Comment #3 from vehre at gcc dot gnu.org ---
That's what library version numbering was made, wasn't it? I.e., this is the
way to go IMO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839
--- Comment #4 from Richard Biener ---
SCC consists of: .MEM_16 .MEM_15 .MEM_35 .MEM_26 ez_12 .MEM_14 wo_37 _5 _6
hy.3_7 _8 .MEM_32 hy.0_1 ez_28 _3 wo_40
Value numbering wo_37 stmt = wo_37 = PHI <0(4), wo_40(5)>
Setting value number of wo_37 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77833
--- Comment #3 from Richard Biener ---
#1 0x00a5937e in plus_constant (mode=SImode, x=0x76a35fa0, c=-1,
inplace=false) at /space/rguenther/src/svn/trunk/gcc/explow.c:87
87gcc_assert (GET_MODE (x) == VOIDmode || GET_MODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70808
Jaak Ristioja changed:
What|Removed |Added
CC||jaak at ristioja dot ee
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821
--- Comment #4 from PeteVine ---
Just tried your suggestion and during the final link, /tmp is full of ltrans
objects so LTO seems to be working fine (GCC5 + -fno-fat-lto-objects) but the
stripped size ended up even larger (2.5M).
Anyway, here's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821
--- Comment #5 from PeteVine ---
Missed the configure step, just before make:
$ ./configure --enable-release --disable-sdl2 --enable-only-ufo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
--- Comment #3 from Richard Biener ---
Ideally we'd do operand_equal_p's job in the pattern but there is no reliable
way to get at the type of the (convert? @0) operand. So I'm thinking of
amending operand_equal_p () with a types_match () check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
--- Comment #4 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> --- gcc/genmatch.c (revision 240739)
> +++ gcc/genmatch.c (working copy)
> @@ -2593,8 +2601,10 @@ dt_operand::gen_match_op (FILE *f, int i
> {
>ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
--- Comment #5 from rguenther at suse dot de ---
On Tue, 4 Oct 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
>
> --- Comment #4 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77842
Bug ID: 77842
Summary: genmatch segfault on a missing brace
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77407
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Tue Oct 4 13:18:18 2016
New Revision: 240742
URL: https://gcc.gnu.org/viewcvs?rev=240742&root=gcc&view=rev
Log:
2016-10-04 Richard Biener
PR middle-end/77407
* mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821
--- Comment #6 from PeteVine ---
Aha! 4.9.4 and additional LDFLAGS=$CFLAGS reproduces the larger size.
(-fno-fat-lto-objects on its own still works as expected)
Probably thee clue to solving this mystery :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77843
Bug ID: 77843
Summary: ICE for gcc.dg/tree-ssa/forwprop-35.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77833
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Tue Oct 4 13:39:22 2016
New Revision: 240743
URL: https://gcc.gnu.org/viewcvs?rev=240743&root=gcc&view=rev
Log:
2016-10-04 Richard Biener
PR middle-end/77833
* exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #15 from Richard Biener ---
Author: rguenth
Date: Tue Oct 4 13:40:54 2016
New Revision: 240744
URL: https://gcc.gnu.org/viewcvs?rev=240744&root=gcc&view=rev
Log:
2016-10-04 Richard Biener
PR tree-optimization/77399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77826
--- Comment #6 from Richard Biener ---
Fallout in GENERIC folding from doing that:
FAIL: c-c++-common/fold-divmul-1.c -std=gnu++11 scan-tree-dump-not original
"/
[ex]"
FAIL: g++.dg/cpp1y/constexpr-array4.C -std=c++14 (test for excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77833
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77840
--- Comment #1 from Jonathan Wakely ---
(In reply to Wolfgang Roehrl from comment #0)
> Hi,
> I would like to post a bug report for the GNU C/C++ compiler 6.1.1.
> We use the compiler to generate code for a PowerPC processor.
> Invokation line fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77841
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77843
--- Comment #1 from Segher Boessenkool ---
It is trying to do a signed conversion from TImode to float here, to be
stored in BLKmode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773
--- Comment #7 from PeteVine ---
Even though it's probably a dfifferent issue (affecting GCC6/7), profiling
makes the solver about 2-3% slower on aarch64:
profiled/non-profiled
gcc5.4 799/875
gcc6.2 790/773
gcc7.0 752/730
But guess what, if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773
--- Comment #8 from PeteVine ---
Created attachment 39749
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39749&action=edit
aarch64 assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77756
--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Oct 4 14:44:16 2016
New Revision: 240747
URL: https://gcc.gnu.org/viewcvs?rev=240747&root=gcc&view=rev
Log:
Backport from mainline
2016-09-29 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77756
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844
Bug ID: 77844
Summary: Compilation of simple C++ example exhaust memory
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844
--- Comment #1 from Andrew Pinski ---
This might have been fixed already. Can you try out gcc 5.4.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77808
--- Comment #1 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Tue Oct 4 15:28:23 2016
New Revision: 240749
URL: https://gcc.gnu.org/viewcvs?rev=240749&root=gcc&view=rev
Log:
Fix PR tree-optimization/77808
gcc/
PR tree-optimization/77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844
--- Comment #2 from graeser at mi dot fu-berlin.de ---
With gcc 5.4.0 on Ubuntu this issue seems to be essentially fixed. However,
compilation still takes about 14s and eats up about 1gb which looks huge
compared to 0.1s and 31mb if the indirectio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65239
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77791
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Oct 4 15:34:16 2016
New Revision: 240751
URL: https://gcc.gnu.org/viewcvs?rev=240751&root=gcc&view=rev
Log:
PR c++/77791
* parser.c (cp_parser_lambda_declarator_opt):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77824
--- Comment #1 from Bill Schmidt ---
Eric, thanks for the report! I'll have a look. Much obliged. This used to
work several years ago...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #8 from andysem at mail dot ru ---
Created attachment 39751
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39751&action=edit
A new testcase which produces invalid code with gcc 5.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593
--- Comment #12 from n8tm at aol dot com ---
On 9/25/2016 3:03 PM, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593
>
> --- Comment #9 from Jerry DeLisle ---
> (In reply to tprince from comment #8)
>> I sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77804
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Tue Oct 4 17:34:00 2016
New Revision: 240754
URL: https://gcc.gnu.org/viewcvs?rev=240754&root=gcc&view=rev
Log:
PR c++/77804 - Internal compiler error on incorrect initialization of new-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #12 from Andrew Pinski ---
(In reply to andysem from comment #10)
> (In reply to Andrew Pinski from comment #9)
> >
> > I think this testcase is violating C++ ODR. In that
> > INSTRUCTION_SET::my_simd_func_impl is the same between t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77845
Bug ID: 77845
Summary: LTO accumulates CPU requirements from all input
objects (reopen)
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #13 from andysem at mail dot ru ---
Ok. For the record, opened bug 77845.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77835
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77804
--- Comment #4 from Martin Sebor ---
Author: msebor
Date: Tue Oct 4 17:55:43 2016
New Revision: 240755
URL: https://gcc.gnu.org/viewcvs?rev=240755&root=gcc&view=rev
Log:
PR c++/77804 - Internal compiler error on incorrect initialization of new-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77804
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77846
Bug ID: 77846
Summary: Wrong error recovery with switch, goto and
initialization skipped
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77846
--- Comment #1 from denis.campredon at gmail dot com ---
I'm pretty sure it is linked the following code, compiled with '-fpermissive'
only prints A instead of AB
--
enum E{ A, B };
class C {public:C(){};};
static inline
void f(E e)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77847
Bug ID: 77847
Summary: PowerPC big endian power7/power8 do not bootstrap due
to fall through error
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
Bug ID: 77848
Summary: Gimple if-conversion results in redundant comparisons
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
Bill Schmidt changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
--- Comment #5 from Jeffrey A. Law ---
So digging a bit deeper. When we leave threading we've exposed a new natural
loop. However, there is still an irreducible loop in the CFG. The CFG and the
cached loop information are conservatively correc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77849
Bug ID: 77849
Summary: [regression/4.9] Warning about deprecated enum even
when "-Wdeprecated-declarations" is off
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77850
Bug ID: 77850
Summary: FAIL: gcc.dg/compat/scalar-by-value-4
c_compat_x_tst.o-c_compat_y_tst.o execute
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
--- Comment #6 from Jeffrey A. Law ---
As noted in my last comment, removal of a forwarder block may turn an
irreducible loop into a natural loop. The loop header for any such exposed
natural loop will not be recognized as a loop header by tree_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Tue Oct 4 21:14:18 2016
New Revision: 240757
URL: https://gcc.gnu.org/viewcvs?rev=240757&root=gcc&view=rev
Log:
PR c++/5 - misoptimization of PMF comparison
* conste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72858
--- Comment #4 from Martin Sebor ---
I came across one subtle case that I think might be better handled differently
than the others.
The type of the expected argument to a %lc directive is wint_t, which is
commonly int, but on some targets long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77824
--- Comment #2 from Bill Schmidt ---
Ah, the passes have moved around some since I last looked at this. This used
to follow a dom pass, so the code for copies didn't kick in any more at that
point. So it's understandable that the copy propagati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77824
--- Comment #3 from Bill Schmidt ---
Eric, can you please provide a test case where you are seeing the unpropagated
copies? Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72858
--- Comment #5 from Martin Sebor ---
Here's a slightly different but arguably even more compelling test case from
x86_64-linux with ILP32 where wchar_t is a typedef for long for some strange
reason yet wint_t is a typedef for int. Passing a wcha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25398
Andrew John Hughes changed:
What|Removed |Added
CC||gnu_andrew at member dot
fsf.org
-
, -16(%rsp)
movss -4(%rsp), %xmm0
movss %xmm0, -12(%rsp)
movq-16(%rsp), %xmm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 7.0.0 20161004 (experimental)"
.section.note.GNU-stack,"",@progbits
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77852
Bug ID: 77852
Summary: ICE when deducing class template arguments for pair or
tuple
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77824
--- Comment #4 from Eric Botcazou ---
> Eric, can you please provide a test case where you are seeing the
> unpropagated copies? Thanks!
I only have an Ada testcase but I think that it would be fairly easy to see
unpropagated copies: replace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77853
Bug ID: 77853
Summary: -Wimplicit-fallthrough: Fall through comment made
ineffective by following comment
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77663
--- Comment #4 from David Binderman ---
(In reply to vehre from comment #1)
> what SW did you use to find this?
cppcheck, a static analyser for C/C++, available from sourceforge.
I run it sometimes over the compiler source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77854
Bug ID: 77854
Summary: std::deque doesn't use allocator's size_type and
difference_type
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77852
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77852
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Wed Oct 5 01:24:38 2016
New Revision: 240765
URL: https://gcc.gnu.org/viewcvs?rev=240765&root=gcc&view=rev
Log:
PR c++/77852 - class deduction from list-init
* pt.c (do_
/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161004 (experimental) [trunk revision 240755
-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161004 (experimental) [trunk revision 240755] (GCC)
$
$ gcc-6.2 -m32 -O2 small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77857
Bug ID: 77857
Summary: gccgo: vendoring doesn't work in gcc 6/7
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77858
Bug ID: 77858
Summary: std::polar throws an exception if rho is negative
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77512
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #10 from Eric Botcaz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77851
--- Comment #1 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #0)
> It should be simply "ret".
Probably we need to introduce SCmode moves (and maybe also SCmode arithmetic
ops) to handle SCmode that gets passed in a single XMM register.
93 matches
Mail list logo
