https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #17 from __vic ---
Created attachment 38319
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38319&action=edit
Dirty patch for GCC 5/6
This dirty patch created for GCC5 solves the problem for GCC6 as well.
(out_of_range will not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70748
Bug ID: 70748
Summary: GCC6 Regression: ICE with debug in
gfc_trans_block_construct
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #16 from Jan Hubicka ---
Author: hubicka
Date: Thu Apr 21 09:05:07 2016
New Revision: 235318
URL: https://gcc.gnu.org/viewcvs?rev=235318&root=gcc&view=rev
Log:
PR ipa/70018
* cgraph.c (cgraph_set_nothrow_flag_1): Ren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70746
Alexander Cherepanov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70725
--- Comment #11 from Richard Biener ---
I think that's a separate issue. if-conversion is confused about
.MEM_198 = PHI <.MEM_191(43)>
which it should simply ignore.
Index: tree-if-conv.c
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #10 from Richard Biener ---
(In reply to Richard Biener from comment #9)
> Oh, and I believe to make nests with only outer safelen > 0 work correctly we
> need to move the check elsewhere:
>
> Index: gcc/tree-ssa-loop-im.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70725
--- Comment #12 from Richard Biener ---
Testing that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70747
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60796
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70744
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #7 from Richard Biener ---
The compiler would need to provide div_t as a builtin-type. Or the standard
specifies it enough so that layout issues are no worry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70740
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70749
Bug ID: 70749
Summary: [4.9/5 Regression] error: storage size of ‘a’ isn’t
known goes away with -Os
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Keywords: ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #8 from Marc Glisse ---
"The div, ldiv, and lldiv functions return a structure of type div_t, ldiv_t,
and lldiv_t, respectively, comprising both the quotient and the remainder. The
structures shall contain (in either order) the member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70749
Richard Biener changed:
What|Removed |Added
Summary|[4.9/5 Regression] error: |error: storage size of ‘a’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70749
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Trunk errors with or without optimisation.
GCC 5 and earlier don't error with optimisation.
If this behaviour is expected (and the bug is in the kernel sources) feel free
to close the report. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60796
--- Comment #4 from Daniel Vollmer ---
The relevant clang issue seems to be
https://llvm.org/bugs/show_bug.cgi?id=22763
In my case, I have the "extern template" declaration in the header for the
corresponding template, thus preventing any implic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70748
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
Bug ID: 70750
Summary: [6/7 Regression] Load and call no longer combined for
indirect calls on x86
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
Richard Biener changed:
What|Removed |Added
Component|rtl-optimization|target
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #30 from rguenther at suse dot de ---
On Wed, 20 Apr 2016, jamborm at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
>
> --- Comment #29 from Martin Jambor ---
> Created attachment 38316
> --> https:/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #31 from Martin Jambor ---
(In reply to rguent...@suse.de from comment #30)
>
> Any reason it's not unsigned HOST_WIDE_INT size?
The only reason is to use the same type in which
get_ref_base_and_extent returns size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70715
--- Comment #1 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Apr 21 11:28:58 2016
New Revision: 235333
URL: https://gcc.gnu.org/viewcvs?rev=235333&root=gcc&view=rev
Log:
PR tree-optimization/70715
* tree-ssa-loop-niter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751
Bug ID: 70751
Summary: FAIL: gcc.target/arm/eliminate.c scan-assembler-times
r0,[\\t ]*sp 3 since r235184
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70715
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, ra
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674
--- Comment #5 from Andreas Krebbel ---
Author: krebbel
Date: Thu Apr 21 11:50:22 2016
New Revision: 235334
URL: https://gcc.gnu.org/viewcvs?rev=235334&root=gcc&view=rev
Log:
PR70674: S/390: Add memory barrier to stack pointer restore
from fpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70747
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Thu Apr 21 11:52:50 2016
New Revision: 235335
URL: https://gcc.gnu.org/viewcvs?rev=235335&root=gcc&view=rev
Log:
2016-04-21 Richard Biener
PR middle-end/70747
* fol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70747
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Thu Apr 21 11:57:28 2016
New Revision: 235336
URL: https://gcc.gnu.org/viewcvs?rev=235336&root=gcc&view=rev
Log:
2016-04-21 Richard Biener
PR middle-end/70747
* fol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70747
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #30 from Jakub Jelinek ---
Created attachment 38320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38320&action=edit
2.5.37 -> 2.6
So, can you please verify that the RC1 tarball bootstraps if you apply the
attached patch (which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70752
Bug ID: 70752
Summary: Incorrect LEN for ALLOCATABLE CHARACTER
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70728
--- Comment #2 from Kirill Yukhin ---
This is a 5/6 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624
--- Comment #10 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Apr 21 12:12:53 2016
New Revision: 235337
URL: https://gcc.gnu.org/viewcvs?rev=235337&root=gcc&view=rev
Log:
Cherry-pick r266868 from upstream.
PR sanitizer/70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624
--- Comment #11 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Apr 21 12:19:54 2016
New Revision: 235338
URL: https://gcc.gnu.org/viewcvs?rev=235338&root=gcc&view=rev
Log:
Cherry-pick r266868 from upstream.
PR sanitizer/70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #31 from David Edelsohn ---
I will test, but Flex and gengtype-lex.c does not appear to be the issue. If
the change works, it will be coincidental.
I have built the RC with gengtype-lex.c removed so that it is regenerated with
the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #32 from Jakub Jelinek ---
But if gengtype-lex.c is not it, what it is then? I can't see how the
generated man pages or *.html files or *.gmo or *.info files could affect it,
so is the pathname? If you check out r235040 into the sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #33 from David Edelsohn ---
I'm completely confused as well. The bits seem to be identical. The only
other obvious difference is ordering of timestamps of the source files that
would cause Make to build files in a different order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #34 from David Edelsohn ---
The tarball contains LAST_UPDATED, although different contents.
I previously copied gcc/REVISION from svn checkout to the RC (which is
referenced by Makefile). That showed no difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70752
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70725
--- Comment #13 from Richard Biener ---
Author: rguenth
Date: Thu Apr 21 14:09:33 2016
New Revision: 235341
URL: https://gcc.gnu.org/viewcvs?rev=235341&root=gcc&view=rev
Log:
2016-04-21 Richard Biener
PR tree-optimization/70725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #35 from David Edelsohn ---
Flex 2.6.0 works with --enable-checking=yes, but may not work with
--enable-checking=release. I believe that Flex may be the culprit. If the
current bootstrap confirms that, I am going to bootstrap with g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70753
Bug ID: 70753
Summary: missing diagnostic in C11 mode: sizeof, _Alignof of
function type
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #7 from Andreas Schwab ---
The second commit triggers this ICE on ia64:
$ gcc/xgcc -Bgcc/ ../../gcc/gcc/testsuite/gcc.dg/pr70725.c -O3 -S
../../gcc/gcc/testsuite/gcc.dg/pr70725.c: In function ‘fn1’:
../../gcc/gcc/testsuite/gcc.dg/pr7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #9 from rguenther at suse dot de ---
On Thu, 21 Apr 2016, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
>
> --- Comment #7 from Andreas Schwab ---
> The second commit triggers this ICE on ia64:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70753
--- Comment #2 from Florian Weimer ---
(In reply to Marek Polacek from comment #1)
> Why would it have to be error? If you want errors instead of warnings, use
> -pedantic-errors.
I did not know about -pedantic-errors. It is extremely surprisi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70753
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70753
--- Comment #3 from Marek Polacek ---
But you get the warning with -Wpedantic, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #8 from Andreas Schwab ---
The same ICE also occurs on m68k and aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #7)
> The second commit triggers this ICE on ia64:
>
> $ gcc/xgcc -Bgcc/ ../../gcc/gcc/testsuite/gcc.dg/pr70725.c -O3 -S
> ../../gcc/gcc/testsuite/gcc.dg/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #36 from David Edelsohn ---
It definitely is Flex. gcc-6-branch r235040 and r235340 fail when built with
Flex 2.6.0. gcc-6.0.1-RC-20160415 fails using the supplied gengtype-lex.c
created with Flex 2.5.37.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #11 from Andreas Schwab ---
> Isn't that what was reported in PR70725 for its fix? Does r235341 fix it?
Yes and yes, but r235252 didn't trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70522
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70744
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70728
--- Comment #3 from Kirill Yukhin ---
Author: kyukhin
Date: Thu Apr 21 15:29:29 2016
New Revision: 235344
URL: https://gcc.gnu.org/viewcvs?rev=235344&root=gcc&view=rev
Log:
AVX-512. PR target/70728. Use separate constraint for AVX-512BW
PR tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #12 from Julian Taylor ---
the testcase in this ticket is not yet vectorized with gcc 20160421 (r235341)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70754
Bug ID: 70754
Summary: ICE during predictive commoning
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70754
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #13 from amker at gcc dot gnu.org ---
(In reply to Julian Taylor from comment #12)
> the testcase in this ticket is not yet vectorized with gcc 20160421 (r235341)
Hi Julian, may I ask which target? It can be vectorized on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #10 from Jerry DeLisle ---
(In reply to Ray Donnelly from comment #9)
> Should the other two places - next_char_default () and next_char_internal ()
> -that also do:
>
> dtp->u.p.at_eol = (c == '\n' || c == EOF);
>
> not check for '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70755
Bug ID: 70755
Summary: [ARM] excessive struct alignment for globals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
--- Comment #14 from Julian Taylor ---
I am on x86_64. It actually does vectorize with -mavx but not with -msse2.
The other variant of the loop I posted does vectorize with sse2.
$ gcc --version
gcc (GCC) 7.0.0 20160421 (experimental
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70744
--- Comment #3 from Marek Polacek ---
So build_conditional_expr_1 has
4626 /* As a G++ extension, the second argument to the conditional can be
4627 omitted. (So that `a ? : c' is roughly equivalent to `a ? a :
4628 c'.) If the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70513
--- Comment #6 from Marek Polacek ---
Author: mpolacek
Date: Thu Apr 21 16:52:51 2016
New Revision: 235347
URL: https://gcc.gnu.org/viewcvs?rev=235347&root=gcc&view=rev
Log:
PR c++/70513
* parser.c (cp_parser_enum_specifier): Che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70513
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70756
Bug ID: 70756
Summary: Wrong column number shown for "error: invalid use of
flexible array member"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70757
Bug ID: 70757
Summary: Add plugin callbacks that run early enough to check
for declarations using "bad" names
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
--- Comment #3 from H.J. Lu ---
r231923 has
(define_special_predicate "call_insn_operand"
(ior (match_test "constant_call_address_operand
(op, mode == VOIDmode ? mode : Pmode)")
(match_operand 0 "call_register_no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #11 from Ray Donnelly ---
I wonder if opening the files in text mode on Windows would be
possible? I don't know a lot about fortran at present, but doing that
would cause Windows to dump the \r's for you.
On Thu, Apr 21, 2016 at 5:30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70758
Bug ID: 70758
Summary: unique_ptr of aligned T calls invalid free
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
--- Comment #4 from H.J. Lu ---
Created attachment 38322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38322&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70744
--- Comment #4 from Marek Polacek ---
A possible fix seems to be
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -4255,6 +4255,12 @@ stabilize_reference (tree ref)
volatiles. */
return stabilize_reference_1 (ref);
+case POSTDECREMENT_EXPR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70756
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #12 from Andy May ---
I don't know that it's necessary or desired to support both '\n' and '\r' as
eol, but instead the native eol just needs to be used consistently everywhere,
for example something like the following pseudo code:
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70758
--- Comment #1 from H.J. Lu ---
I think this is a dup of PR 36159.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70744
--- Comment #5 from Donald Chai ---
For what it's worth, post-increments behave as I would expect:
$ cat test.c
int main() {
int x = 1;
x++ ?: 0xbeef;
return x;
}
$ gcc-5 -x c test.c; ./a.out; echo $?
2
$ gcc-5 -x c++ test.c; ./a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #13 from Jerry DeLisle ---
(In reply to Andy May from comment #12)
> I don't know that it's necessary or desired to support both '\n' and '\r' as
> eol, but instead the native eol just needs to be used consistently
> everywhere, for e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70758
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #9 from Daniel Gutson
---
Created attachment 38323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38323&action=edit
sample script to be called from the build system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #10 from Daniel Gutson ---
(In reply to Marc Glisse from comment #8)
> "The div, ldiv, and lldiv functions return a structure of type div_t,
> ldiv_t, and lldiv_t, respectively, comprising both the quotient and the
> remainder. The st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #11 from Marcos Diaz ---
(In reply to Daniel Gutson from comment #10)
> (In reply to Marc Glisse from comment #8)
> > "The div, ldiv, and lldiv functions return a structure of type div_t,
> > ldiv_t, and lldiv_t, respectively, compris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70540
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Apr 21 19:42:34 2016
New Revision: 235348
URL: https://gcc.gnu.org/viewcvs?rev=235348&root=gcc&view=rev
Log:
/cp
2016-04-21 Paolo Carlini
PR c++/70540
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70540
Paolo Carlini changed:
What|Removed |Added
Summary|[4.9/5/6/7 Regression] ICE |[4.9/5/6 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66067
--- Comment #15 from Jason Merrill ---
(In reply to Victoria from comment #14)
> issue not seen in GCC 5.x branch, is possible to backport the patch?
I don't understand. If the issue is not seen, why backport?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70759
Bug ID: 70759
Summary: Ada rts fails to build with -mabi=ilp32
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
David Abdurachmanov changed:
What|Removed |Added
CC||david.abdurachmanov at gmail
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
--- Comment #11 from David Abdurachmanov
---
"Good" code, annotated by me. Now notice from my previous message that the fix
for this PR, caused
49 89 1c 24 mov%rbx,(%r12)
to be removed. We lost one instruction which stored the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to David Abdurachmanov from comment #10)
> I have been reg-testing GCC 6 for the last few weeks and I hit an issue with
> compile code straggly segfaulting.
>
> Compiler with GCC 5.3.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70750
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Apr 21 22:01:34 2016
New Revision: 235353
URL: https://gcc.gnu.org/viewcvs?rev=235353&root=gcc&view=rev
Log:
X86: Fix a typo in call_insn_operand
r231923 has
;; Test for a v
92 matches
Mail list logo
