https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #5 from Kirill Yukhin ---
(In reply to ktkachov from comment #3)
> CC'ing Kirill for AVX512 opinion
I suppose that there's something wrong w/ MD patterns.
E.g. for example provided pattern is:
;; /export/users/kyukhin/gcc/git/gcc/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69684
Bug ID: 69684
Summary: Useless -Wparentheses for A || !A && B
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685
Bug ID: 69685
Summary: GCC cross compiler build failed
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
Bug ID: 69686
Summary: Useless -Wparentheses for A && B || !A && C
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #11 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #9)
> Another problem. STV is disabled even when stack is aligned:
See the other PR, that has been discussed as one of the possible approaches,
but as TARGET_STV does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685
Richard Biener changed:
What|Removed |Added
Target||avr
--- Comment #1 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69684
--- Comment #1 from Richard Biener ---
See other PR, this is about coding-style. One could say even a || !a && b
doesn't make sense as the !a in the !a && b conditon will always be true
and thus this is a || b.
So a diagnostic is warranted - ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Severity|major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #14 from Richard Biener ---
*** Bug 69682 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685
--- Comment #2 from Pieter Cardoen ---
How do you mean: appending -v? The only command I execute is:
../gcc-4.9.3/configure --prefix=/usr/local/gcc-4.9.3-avr-unknown-elf \
--target=avr-unknown-elf --build=i686-pc-$(ENV) \
--enable-languages=c,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #6 from Kirill Yukhin ---
This bug seems to be mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #12 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 5 09:23:03 2016
New Revision: 233167
URL: https://gcc.gnu.org/viewcvs?rev=233167&root=gcc&view=rev
Log:
PR bootstrap/69677
* config/i386/i386.c (convert_scalars_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
Kirill Yukhin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625
--- Comment #2 from Andreas Krebbel ---
Author: krebbel
Date: Fri Feb 5 10:08:17 2016
New Revision: 233168
URL: https://gcc.gnu.org/viewcvs?rev=233168&root=gcc&view=rev
Log:
S/390: Fix r6 vararg handling.
This patch fixes a problem introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
--- Comment #2 from Jonathan Wakely ---
(In reply to wipedout from comment #0)
> So here there's only once reasonable way to put parentheses and the warning
> is useless.
But how long does it take most readers of the code to do that analysis and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #8 from Kirill Yukhin ---
(In reply to Jakub Jelinek from comment #7)
> So do you want to use reg_or_0_operand? I don't think we usually tie output
> with input already in the predicates, except when match_dup is used.
That is the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69684
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #10 from Kirill Yukhin ---
(In reply to Jakub Jelinek from comment #9)
> But something like that might remove the flexibility from the register
> allocator.
>
> Wonder why the RA in this case doesn't see that the value loaded into th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
--- Comment #4 from Jonathan Wakely ---
*** Bug 69684 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
Bug ID: 69687
Summary: Buffer Overflow in libiberty
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #14 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #6)
> STV turns:
>
> insn 21 19 23 4 (parallel [
> (set (reg:DI 102 [ val ])
> (and:DI (reg/v:DI 97 [ val ])
> (mem/u:DI (pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #1 from Marcel Böhme ---
Created attachment 37593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37593&action=edit
Test Case #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #15 from Ilya Enkovich ---
(In reply to Jakub Jelinek from comment #13)
> Fixed.
I think you just hide LRA issue disabling STV and LRA still may generate
incorrect register fill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #11 from Jakub Jelinek ---
void bar (void);
void
foo (int p2, int p3)
{
unsigned long a = p2;
unsigned long b = (~(unsigned long) ((unsigned int) p3 + -1U)) + a;
unsigned long c = (a - (unsigned long) ((unsigned int) p3 + -1U))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #12 from Richard Biener ---
(In reply to Jakub Jelinek from comment #11)
> void bar (void);
>
> void
> foo (int p2, int p3)
> {
> unsigned long a = p2;
> unsigned long b = (~(unsigned long) ((unsigned int) p3 + -1U)) + a;
> uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38812
--- Comment #8 from Peter Keller ---
(In reply to Eric Gallager from comment #7)
> (In reply to Eric Gallager from comment #6)
> > There's also some places where environ is used as an extern variable in
> > libiberty that would need similar fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69688
Bug ID: 69688
Summary: -Wsign-compare causes bogus error: size of array
‘uc_code’ is not an integral constant-expression
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #3 from Marcel Böhme ---
Hi Markus,
Indeed, it depends on the use case. I find it quite unsettling to know that
common digital forensics tools, such as gdb and objdump, are vulnerable to
execute arbitrary code.
How much credibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69688
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #16 from Uroš Bizjak ---
(In reply to Ilya Enkovich from comment #15)
> (In reply to Jakub Jelinek from comment #13)
> > Fixed.
>
> I think you just hide LRA issue disabling STV and LRA still may generate
> incorrect register fill
Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683
--- Comment #2 from Juan Rada-Vilela ---
Indeed, it is unfortunate, especially because I compile my software with
`-Werror`, so now I have to choose between ignoring warnings or using raw
strings. Is there anything I can do to avoid triggering a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683
--- Comment #3 from Jonathan Wakely ---
(In reply to Juan Rada-Vilela from comment #0)
> BUT it is expected from the compiler to ignore everything within the
> `#ifdef` because `X` was not defined.
The compiler still has to do tokenization to de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683
--- Comment #4 from Jonathan Wakely ---
(In reply to Juan Rada-Vilela from comment #2)
> Is there anything I can do to avoid triggering a warning and yet
> use a raw string?
You can use R""(this)"" or R"xxx"(this)"xxx" as the raw string, so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683
--- Comment #5 from Juan Rada-Vilela ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Juan Rada-Vilela from comment #2)
> > Is there anything I can do to avoid triggering a warning and yet
> > use a raw string?
>
> You can use R"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #5 from Yuri Rumyantsev ---
Jacub,
I'd like to clarify one your remark:
5) IMHO you should give up also for !is_gimple_assign, say trying to move an
elemental function call into the conditional is just wrong
What's wrong in call mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #6 from Jakub Jelinek ---
Well, MASK_STORE you don't want to handle in that loop, that is a store.
MASK_LOAD is an exception, so IMHO you should just check for is_gimple_assign
|| MASK_LOAD. Allowing move of arbitrary other stmts loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689
Bug ID: 69689
Summary: gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #16 from Richard Biener ---
Testing of the tree-ssanames.c change went ok on x86_64, can somebody see
whether this fixes the testcase on mips?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #27 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #7 from rguenther at suse dot de ---
On Fri, 5 Feb 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
>
> --- Comment #6 from Jakub Jelinek ---
> Well, MASK_STORE you don't want to handle in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69690
Bug ID: 69690
Summary: -pg -fomit-frame-pointer fails with error even if -pg
does not depend on frame pointers
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #28 from rguenther at suse dot de ---
On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> alalaw01 at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689
--- Comment #1 from Richard Biener ---
It's actually because ax dies in the ... instruction. So no easy fix here.
Maybe postreload reload_combine needs to be "integrated" into LRA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #29 from Wilco ---
(In reply to rguent...@suse.de from comment #28)
> On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote:
> > Should I raise a new bug for this, as both this and 53068 are CLOSED?
>
> I think this has been discuss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
vries at gcc dot gnu.org changed:
What|Removed |Added
Attachment #37585|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #30 from Jakub Jelinek ---
(In reply to Wilco from comment #29)
> (In reply to rguent...@suse.de from comment #28)
> > On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote:
>
> > > Should I raise a new bug for this, as both this and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Bug ID: 69691
Summary: [6 Regression] wrong code at -O2 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |6.0
--- Comment #1 from Marek Polacek -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #31 from rguenther at suse dot de ---
On Fri, 5 Feb 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> --- Comment #30 from Jakub Jelinek ---
> (In reply to Wilco from comment #29)
> > (I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #11 from Richard Biener ---
Alternate fix not causing PR69689 (but also not getting the extra speedup
observed with the original fix):
Index: gcc/ira.c
===
--- gcc/ira.c
mm a,8,8
.ident "GCC: (GNU) 6.0.0 20160205 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-1 pr69677]$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59474
Johannes S. Mueller-Roemer changed:
What|Removed |Added
CC||j.s.mueller-roemer at gmx do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69688
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #25 from Alexander Fomin ---
Good new, thank you!
Sent to ML.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
Bug ID: 69693
Summary: Wrong mode is used to load spilled register
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #17 from Ilya Enkovich ---
(In reply to Uroš Bizjak from comment #16)
> That doesn't mean that incorrect register fill RA bug should't be fixed
> during stage-4. Do we have a small testcase that exposes it?
I submitted PR69693 for RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
--- Comment #1 from Ilya Enkovich ---
We should be able to revert r233167 if this issue is fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #12 from Richard Biener ---
Key assembly difference seems to be extra reg-reg copies around a loop. But
maybe
perf lies to me (the description cites fsettle as the real offender but perf
points me to inl1130). As I can reproduce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #13 from Richard Biener ---
It would be interesting to see whether FDO also shows the regression (I only
have a non-march=native FDO tester and the non-march=native tester doesn't show
the regression already). Because it might be tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
--- Comment #10 from Patrick Palka ---
Author: ppalka
Date: Fri Feb 5 14:36:44 2016
New Revision: 233176
URL: https://gcc.gnu.org/viewcvs?rev=233176&root=gcc&view=rev
Log:
Fix PR c++/68948 (wrong code generation due to invalid constructor call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to vries from comment #11)
> Created attachment 37594 [details]
> Updated tentative patch
>
> This patch builds, and runs target-libgomp with -flto -flto-partition=1to1
> -fno-toplevel-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69694
Bug ID: 69694
Summary: type incomplete depending if constructing function is
templated
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #11 from Jakub Jelinek ---
BTW, can you see if the cse.c one-liner has significant effect on say SPEC2k6
with -mavx512* options? If yes, then either we need some help from the RA to
deal with this, or perhaps the one-liner should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648
--- Comment #11 from Bernd Schmidt ---
FWIW that passes bootstrap & regtest on x86_64-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648
--- Comment #12 from Bernd Schmidt ---
err, with -fPIC in the CFLAGS was what I was going to say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
--- Comment #6 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Feb 5 14:41:00 2016
New Revision: 233177
URL: https://gcc.gnu.org/viewcvs?rev=233177&root=gcc&view=rev
Log:
gcc/
2016-02-05 Ilya Enkovich
PR target/69369
Rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66999
sshannin at gmail dot com changed:
What|Removed |Added
CC||sshannin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
--- Comment #12 from Patrick Palka ---
Created attachment 37596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37596&action=edit
better fix for gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #11 from Patrick Pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
--- Comment #5 from wipedout at yandex dot ru ---
Here the compiler just enforces people to add parentheses so that they
accidentally put them wrong and then the compiler is happy and the code is
buggy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
--- Comment #4 from Jakub Jelinek ---
I think the bug is in move_plus_up, as that function transforms:
(subreg:SI (plus:DI (reg/f:DI 20 frame)
(const_int 16 [0x10])) 0)
into:
(plus:SI (plus:SI (subreg:SI (reg/f:DI 20 frame) 0)
(co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69251
Bug 69251 depends on bug 69277, which changed state.
Bug 69277 Summary: [6 Regression] ICE mangling a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
--- Comment #6 from Jonathan Wakely ---
(In reply to wipedout from comment #5)
> Here the compiler just enforces people to add parentheses so that they
> accidentally put them wrong and then the compiler is happy and the code is
> buggy.
Yes, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #17 from Jeffrey A. Law ---
I've got enough state on this BZ and remember just enough MIPS that I can
verify behaviour with a cross.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #4 from Marcel Böhme ---
Here is my preliminary analysis:
The function demangle_args (cplus-dem.c:4424) parses the (crafted) mangled
function args from the binary. In line 4452, r is read from mangled. In line
4491, we enter a loop wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #13 from vries at gcc dot gnu.org ---
(In reply to vries from comment #11)
> Created attachment 37594 [details]
> Updated tentative patch
>
> This patch builds, and runs target-libgomp with -flto -flto-partition=1to1
> -fno-toplevel-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #18 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Feb 5 16:24:06 2016
New Revision: 233180
URL: https://gcc.gnu.org/viewcvs?rev=233180&root=gcc&view=rev
Log:
Add a testcase for PR target/69677
PR target/69677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #18 from Jeffrey A. Law ---
Richi,
The patch fixes both the original testcase as well as the reduced testcase.
The difficultly I see is building a reliable test for the regression suite.
Parsing RTL dumps looking for the right as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695
Bug ID: 69695
Summary: slice of an array retains pointer attribute
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fastjar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #32 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #31)
>
> Thus a "fix" for the case where treating a[i] as a[0] is the issue
> would be
>
> Index: gcc/tree-dfa.c
> ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #14 from Jim Wilson ---
Andrew Pinksi wrote the patch to fix the ICE. I was expecting him to submit
it.
He also pointed out that the code with the patch is inefficient, and can be
optimized by adding some patterns to the aarch64 and
1 - 100 of 166 matches
Mail list logo
