https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69616
Bug ID: 69616
Summary: optimization of 8 movb
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69616
Markus Trippelsdorf changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
--- Comment #7 from rsandifo at gcc dot gnu.org
---
(In reply to Uroš Bizjak from comment #6)
> IMO, we should revert r215450, and fix a couple of cases using narrowing
> conversions with gen_lowpart that were introduced after r215450.
Please g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69616
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69532
--- Comment #4 from david.sherwood at arm dot com ---
(In reply to vries from comment #3)
> Also for the non-vect version:
> ...
> FAIL: gcc.target/arm/fmaxmin.c execution test
> ...
Hi, if you are not already fixing this, I can take a look if yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69615
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69606
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69615
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
rx 3,0,9
add 5,3,6
andc 10,3,7
and 5,5,7
or 10,10,5
stwcx. 10,0,9
bne- 0,.L6
isync
srw 3,3,8
rlwinm 3,3,0,0x
blr
.size inc_ushort, .-inc_ushort
.ident "GCC: (GNU) 6.0.0 20160202 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69616
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69532
--- Comment #5 from vries at gcc dot gnu.org ---
(In reply to david.sherwood from comment #4)
> (In reply to vries from comment #3)
> > Also for the non-vect version:
> > ...
> > FAIL: gcc.target/arm/fmaxmin.c execution test
> > ...
>
> Hi, if yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69597
--- Comment #2 from Richard Biener ---
OACC uses IPA PTA unconditionally, right?
.type acquire, @function
acquire:
lwsync
blr
.size acquire, .-acquire
.ident "GCC: (GNU) 6.0.0 20160202 (experimental)
See also e6500 Core Reference Manual, 5.5.5.2.1 (Simplified memory barrier
recommendations) and EREF: A Programmer’s Reference M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69597
--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> OACC uses IPA PTA unconditionally, right?
It uses it by default. I think -fno-ipa-pta should work as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69606
--- Comment #3 from Richard Biener ---
So before VRP2 we have
:
load_dst_16 = b;
# RANGE [2, 65535] NONZERO 65535
_12 = (int) load_dst_16;
# RANGE [0, 255]
_9 = (unsigned char) load_dst_16;
e = _9;
# RANGE [0, 255] NONZERO 255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68542
--- Comment #8 from Ilya Enkovich ---
Author: ienkovich
Date: Tue Feb 2 09:46:26 2016
New Revision: 233068
URL: https://gcc.gnu.org/viewcvs?rev=233068&root=gcc&view=rev
Log:
gcc/
2016-02-02 Yuri Rumyantsev
PR middle-end/68542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69606
--- Comment #4 from Richard Biener ---
Testing
Index: gcc/tree-ssa-math-opts.c
===
*** gcc/tree-ssa-math-opts.c(revision 233067)
--- gcc/tree-ssa-math-opts.c(working copy)
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
Bug ID: 69619
Summary: [6 Regression] compilation doesn't terminate during
CCMP expansion
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: compile-time-h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||wdijkstr at arm dot com
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69620
Bug ID: 69620
Summary: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times
optimized fails for powerpc64-linux-gnu
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69615
--- Comment #3 from Peter Cordes ---
@Richard and Jakub:
That's just addressing the first part of my report, the problem with x <=
(INT_MAX-1), right?
You may have missed the second part of the problem, since I probably buried it
under too muc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69615
--- Comment #4 from Jakub Jelinek ---
I suppose even that is doable in the reassoc framework, or it could be done in
match.pd just using the recorded value ranges, like richi has handled PR69595,
or both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
--- Comment #1 from ktkachov at gcc dot gnu.org ---
Just increasing the size of 'e' avoids undefined behaviour.
The following doesn't give a warning and still shows the bug:
int a, b, c, d;
int e[100];
void
fn1 ()
{
int *f = &d;
c = 6;
for (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69621
Bug ID: 69621
Summary: extern std::string used as reference template-argument
does not have [abi:cxx11] tag applied
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #8 from Bernd Schmidt ---
Looks like it can be slightly reduced, removing not executed paths.
template constexpr inline const T &
min (const T &a, const T &b)
{
if (b < a)
return b;
return a;
}
template < typename T > const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69622
Bug ID: 69622
Summary: compiler reordering of non-temporal (write-combining)
stores produces significant performance hit
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68715
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2016-01-07 00:00:00 |2016-2-2
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
--- Comment #2 from Wilco ---
Changing to c = 3 generates code after a short time. The issue is recursive
calls to expand_ccmp_expr during the 2 possible options tried to determine
costs. That makes the algorithm exponential.
A fix would be to e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623
Bug ID: 69623
Summary: CWG 1388; Invalid deduction of non-trailing template
parameter pack
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #5)
> Even if we look through macros, I'd actually think we should warn here.
I think we should NOT look through macros. The purpose of the warning is to
catch m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Eric Blake from comment #0)
> However, as shown by the sample code below, gcc 6.0's new warning is
> over-ambitious, and is likely to _cause_ rather than cure user bugs, when
> uninformed u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69606
Richard Biener changed:
What|Removed |Added
Known to work||6.0
Summary|[5/6 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69606
Richard Biener changed:
What|Removed |Added
Known to work||6.0
Summary|[5/6 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #8 from Jakub Jelinek ---
(In reply to Manuel López-Ibáñez from comment #7)
> (In reply to Eric Blake from comment #0)
> > However, as shown by the sample code below, gcc 6.0's new warning is
> > over-ambitious, and is likely to _caus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69307
--- Comment #6 from Andrey Belevantsev ---
Created attachment 37551
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37551&action=edit
proposed patch
Here before reload we're trying to rename a hard register. At the very final
point of choo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69622
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032
Uroš Bizjak changed:
What|Removed |Added
Keywords|ra |
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Bisection showed this started with r228302.
But I'm not sure if that's the cause or just exposes a latent bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
--- Comment #3 from Wilco ---
A simple workaround is to calculate cost1 early and only try the 2nd option if
the cost is low (ie. it's not a huge expression that may evaluate into lots of
ccmps). A slightly more advanced way would be to walk prep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #3 from ktkachov at gcc dot gnu.org ---
Note that -mtpcs-leaf-frame was deprecated in GCC 5 due to a number of bugs
with it: https://gcc.gnu.org/gcc-5/changes.html
There are a number of known issues with these options relating to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
Bug ID: 69624
Summary: sanitize-coverage=trace-pc miscompiles kernel
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69613
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #1 from Jiri Slaby ---
Created attachment 37552
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37552&action=edit
__sw_hweight32 assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #2 from Jiri Slaby ---
Created attachment 37553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37553&action=edit
__sanitizer_cov_trace_pc implementation
This guys actually changes rdx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #3 from Jiri Slaby ---
Preprocessed code:
http://www.fi.muni.cz/~xslaby/sklad/af_netlink.i
This one results in the code from initial description. I.e. rdx is loaded
before a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69621
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625
Bug ID: 69625
Summary: deadlock in libgomp.c/doacross-1.c test
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69626
Bug ID: 69626
Summary: [6 Regression] std::strtoll no longer defined in c++98
mode
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69627
Bug ID: 69627
Summary: [6 Regression] Conditional jump or move depends on
uninitialised value(s) in (anonymous
namespace)::layout::get_state_at_point
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69628
Bug ID: 69628
Summary: [6 Regression] Conditional jump or move depends on
uninitialised value(s)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #5 from Jiri Slaby ---
(In reply to Jakub Jelinek from comment #4)
> What gcc options are you using on the preprocessed source to trigger this?
By default this:
gcc-6 -nostdinc -fno-strict-aliasing -fno-common -std=gnu89 -mno-sse -mn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #6 from Dmitry Vyukov ---
Also what gcc version?
I've tried:
gcc version 6.0.0 20160105 (experimental) (GCC)
$ gcc /tmp/af_netlink.c -c -O2 -fsanitize-coverage=trace-pc
-fsanitize=kernel-address --param asan-stack=1 --param asan-glo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #7 from Jiri Slaby ---
(In reply to Dmitry Vyukov from comment #6)
> Also what gcc version?
$ gcc-6 --version
gcc-6 (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]
> I've tried:
> gcc version 6.0.0 20160105 (exper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #8 from Dmitry Vyukov ---
First of all, are you sure that r12 is not 0 before the call?
Deference of 0xdc00 is how KASAN reacts on NULL deref, it does
shadow check before the memory accesses. If original address is NULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #9 from Jiri Slaby ---
(In reply to Dmitry Vyukov from comment #8)
> First of all, are you sure that r12 is not 0 before the call?
Yes.
> Deference of 0xdc00 is how KASAN reacts on NULL deref, it does
> shadow check befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69628
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69627
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69626
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #10 from Jakub Jelinek ---
If you are calling a function (__sw_hweight32) without letting gcc know you do
that, are you sure that function call does not modify any registers other than
"flags" and "rax"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69577
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #11 from Jiri Slaby ---
(In reply to Jakub Jelinek from comment #10)
> If you are calling a function (__sw_hweight32) without letting gcc know you
> do that, are you sure that function call does not modify any registers other
> than "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #12 from Jiri Slaby ---
(In reply to Jiri Slaby from comment #11)
> __sw_hweight32 changes only retval (rax) and parameter (rdi).
... and rdi is stored to and restored from stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #13 from Jakub Jelinek ---
Seems hweight.c is compiled with
-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx
-fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11
but that of course expects that all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #14 from Dmitry Vyukov ---
Wait, I already disabled instrumentation of hweight.c for because of this:
+# Kernel does not boot if we instrument this file as it uses custom calling
+# convention (see CONFIG_ARCH_HWEIGHT_CFLAGS).
+KCOV_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #10 from Jakub Jelinek ---
(In reply to Bernd Schmidt from comment #9)
> Ah, of course.
>
> 804856f: df ec fucomip %st(4),%st
>
> pc 0x804856f 0x804856f
> st00.5019607843137254902
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #15 from Jiri Slaby ---
(In reply to Dmitry Vyukov from comment #14)
> If you apply the latest kcov patch "[PATCH v6] kernel: add kcov code
> coverage", it should work.
Could you please push that to the syzkaller tree [1] then?
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #16 from Dmitry Vyukov ---
> Could you please push that to the syzkaller tree [1] then?
Sorry, syzkaller page referred to outdated patch. I was hoping that Andrew will
take it soon, so that I can update the link to a more respected l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69624
--- Comment #17 from Dmitry Vyukov ---
Jakub, I guess you can close this.
Sorry again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69595
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Tue Feb 2 15:19:32 2016
New Revision: 233076
URL: https://gcc.gnu.org/viewcvs?rev=233076&root=gcc&view=rev
Log:
2016-02-02 Richard Biener
PR tree-optimization/69595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69613
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Bisection shows this started with r226901, the big copyrename dropping patch.
I didn't investigate whether it's actually the cause of the bug or just exposes
another latent one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69599
vries at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69595
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #11 from Tom Hughes ---
This is C++ so -fexcess-precision=standard is no help as that is C only.
Likewise -ffloat-store is, as I understand it, not much help in real world code
because you need to make sure that you force stores in o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630
Bug ID: 69630
Summary: [6 Regression] LTO ICE in types_same_for_odr at
ipa-devirt.c:402
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630
--- Comment #1 from Tobias Burnus ---
Created attachment 37557
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37557&action=edit
test.ii test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69626
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032
--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Feb 2 16:07:24 2016
New Revision: 233079
URL: https://gcc.gnu.org/viewcvs?rev=233079&root=gcc&view=rev
Log:
PR target/67032
* config/i386/i386.c (geode_cost)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032
--- Comment #15 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Feb 2 16:08:56 2016
New Revision: 233080
URL: https://gcc.gnu.org/viewcvs?rev=233080&root=gcc&view=rev
Log:
PR target/67032
* config/i386/i386.c (geode_cost)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032
--- Comment #16 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Feb 2 16:10:04 2016
New Revision: 233081
URL: https://gcc.gnu.org/viewcvs?rev=233081&root=gcc&view=rev
Log:
PR target/67032
* config/i386/i386.c (geode_cost)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69631
Bug ID: 69631
Summary: Bogus overflow in constant expression error
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
-system-zlib --disable-bootstrap --disable-libvtv
--disable-libcilkrts --disable-libitm --disable-libgomp --disable-libcc1
--disable-libstdcxx-pch --disable-libssp --enable-isl
Thread model: posix
gcc version 5.3.1 20160202 (GCC)
But not anymore with 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #12 from Bernd Schmidt ---
Or lose the equality tests on the max values, instead use something like
if (b > r && b >= g)
I suppose that could still have problems if b and g are equal and one of them
is spilled. Someone who knows tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69632
Bug ID: 69632
Summary: No error issued for declaring a parameter having a
late-specified return type without the 'auto' type
specifier
Product: gcc
Version: 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277
--- Comment #6 from Martin Sebor ---
In response to another patch for a related problem Jason asked me to change the
representation of flexible array members in C++. The alternate representation
has an impact on how this bug is dealt with so it'
ticed that for
attached simple test-case extracted from real benchmark one more redundant move
instruction is generated (till 20160202 compiler build):
before fix (postreload dump)
86: NOTE_INSN_BASIC_BLOCK 4
40: dx:QI=[si:SI]
41: ax:QI=[si:SI+0x1]
42: {si:SI=si:SI+0x3;clobber flags:CC;}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69632
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633
--- Comment #1 from Yuri Rumyantsev ---
Created attachment 37559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37559&action=edit
test-case to reproduce
Need to be compiled with -O2 -m32 -pie -fPIE.
Assume that -march=slm is not needed.
1 - 100 of 169 matches
Mail list logo