https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66174
Bug ID: 66174
Summary: [6 Regression] ICE: in extract_insn, at recog.c:2341
(unrecognizable insns) with -ftree-vectorize
-mavx512ifma
Product: gcc
Version: 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48025
Thomas Koenig changed:
What|Removed |Added
Blocks||48997
--- Comment #1 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66173
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172
--- Comment #4 from Andrew Pinski ---
*** Bug 66173 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220
Thomas Koenig changed:
What|Removed |Added
Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172
--- Comment #3 from Marc Singer ---
I've come to the same conclusion. My hope was that I could eliminate the guard
and force the compiler to initialize block scoped statics at the start of
execution. It looks like the standard stands in the way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55839
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674
--- Comment #12 from Thomas Koenig ---
Is there interesting in further backporting?
If not, I would close this as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165
Mikhail Maltsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66173
--- Comment #1 from Marc Singer ---
I neglected to include information about the version of the compiler. This is
a 64 bit compiler on amd64.
# g++ --version
g++ (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66172
Bug ID: 66172
Summary: -fno-threadsafe-statics suppresses guard functions but
not guard variables
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66173
Bug ID: 66173
Summary: -fno-threadsafe-statics suppresses guard functions but
not guard variables
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66168
Mikhail Maltsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
--- Comment #2 from Peter Boyle ---
p.s. in case anyone is wondering this recursive construct is
a simplification of a construct I'm using in an expression
template framework, so this is not simply a convoluted test case.
Rather, I distilled th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #23 from Lawrence Velázquez ---
(In reply to Francois-Xavier Coudert from comment #21)
> - version_as_legacy_macro(): same issue. Why do we need to handle major <=
> 9? You have rejected this possibility in macosx_version_as_macro()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66171
Bug ID: 66171
Summary: [6 Regression]: gcc.target/cris/biap.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66170
Bug ID: 66170
Summary: Bogus warning with -Wsign-conversion when using
static_cast on an int
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66164
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66004
--- Comment #3 from Hans-Peter Nilsson ---
Something supposedly very good happened recently, because:
r223225 18369501023
I'll just have to find out what caused that 50% cut! The test-case is
unchanged.
If the cause is related to inlining heuri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66166
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66166
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
Kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
--- Comment #21 from Francois-Xavier Coudert ---
(In reply to Lawrence Velázquez from comment #20)
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01377.html
Quick review of the patch:
- version_as_modern_macro(): you implement a specific beha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66166
--- Comment #1 from H.J. Lu ---
GCC 4.0 also aborts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66169
--- Comment #1 from Ying-Po Liao ---
The following example shows a Concept applied to the constructor of class A.
The compiler (r223061) will generate internal compiler error if A's subclass C
implements default behaviors of copy/move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66164
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66169
Bug ID: 66169
Summary: [c++-concepts] constraints on constructor are jammed
with inherited copy/move constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66167
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66167
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #5 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #4)
> Thanks, Martin. So maybe something like this:
This happens on almost all non-x86 machines. I tested it on aarch64 and we had
the same failure as powerpc.
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150515 (experimental) [trunk revision 223211] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-5.1 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:15:1: internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66167
Bug ID: 66167
Summary: Scalar Storage Order attribute has no effect on 2
dimensional arrays
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150515 (experimental) [trunk revision 223211] (GCC)
$
$ gcc-trunk -O0 small.c; ./a.out
$
$ gcc-trunk -O1 small.c
$ ./a.out
Aborted (core dumped)
$
---
int a, b, e, c = 1;
const int d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #8 from Jonathan Wakely ---
I already said that it works fine with C++ code *you* write, in any standard
mode. But don't expect everyone else's C++ code (including standard library
headers) to follow the old pre-1998 rules.
If you us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165
Bug ID: 66165
Summary: vect_transform_slp_perm_load: vec out of range ?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66164
Bug ID: 66164
Summary: Strange behaviour calling functions with float as
parameter
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
--- Comment #6 from AK ---
Your patch did fix the problem. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #7 from Luca Stoppa ---
Well, even if my production code is 20 years old, the example I have attached
isn't. It is valid c++11/14 code.
Would you call something like this "old c++ code"?
#include
int main()
{
std::vector v{1,2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956
Mikhail Maltsev changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Mikhail Maltsev from comment #12)
Great! Please do not forget to close the bug (using your @gcc.gnu.org account).
I leave the honor to you. Perhaps even worth it to add this to
https://gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #14 from Marc Glisse ---
(In reply to Andrew Pinski from comment #13)
> It might also be useful if the range is [0,10] for x%5 to be simplified down
> to just "t = x-5; x>=5?t:x;"
(I assume you meant [0,9])
I agree, but the profitabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #13 from Andrew Pinski ---
(In reply to Marc Glisse from comment #12)
> One last thing that would have been nice: in VRP, if the range of X is
> included in [10,14], X%5 can be simplified to X-10. But it is probably not
> worth the tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956
--- Comment #12 from miyuki at gcc dot gnu.org ---
Author: miyuki
Date: Fri May 15 18:02:50 2015
New Revision: 223223
URL: https://gcc.gnu.org/viewcvs?rev=223223&root=gcc&view=rev
Log:
PR c/48956
gcc/c-family/
* c-common.c (int_safely_convertibl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #3 from Martin Sebor ---
On Power, both glibc and AIX pthread_once behave the same way: i.e., they fail
to clear the once flag on exception. The test case below mimics glibc's
pthread_once and demonstrates the root cause of the probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|paolo.carlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #11 from Marc Glisse ---
Author: glisse
Date: Fri May 15 17:34:15 2015
New Revision: 223221
URL: https://gcc.gnu.org/viewcvs?rev=223221&root=gcc&view=rev
Log:
2015-05-15 Marc Glisse
PR tree-optimization/64454
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Paolo Carlini from comment #9)
> But the error message is about l->*ptr, not about ptr per se.
Yes, but the location should already point to l->*ptr. I'm thinking in cases
such as:
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #2 from Martin Liška ---
(In reply to Andrew Pinski from comment #1)
> This really sounds like a bug in Firefox. This argument is not valid to be
> null. Hmm, I suspect there should be an undefined sanitizer that should be
> added to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #1 from Andrew Pinski ---
This really sounds like a bug in Firefox. This argument is not valid to be
null. Hmm, I suspect there should be an undefined sanitizer that should be
added to catch this case if not already there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Bug ID: 66163
Summary: [6 Regression] Not working Firefox built with LTO
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903
--- Comment #5 from Jerry DeLisle ---
(In reply to Laurent Chardon from comment #4)
> Thanks for the fix. If I may suggest a modification of the testcase in order
> to check also when there are no blanks between the & and !. I know in
> Fortran i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66162
Bug ID: 66162
Summary: Bug box compiling Ada.Finalization with -gnatc
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
--- Comment #6 from vekumar at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #5)
> (In reply to vekumar from comment #4)
> > (In reply to ktkachov from comment #3)
> > > Venkat, are you planning to submit this patch to gcc-pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13981
Jonathan Wakely changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66161
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #9 from Paolo Carlini ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Paolo Carlini from comment #7)
> > First blush I'm wondering if in this specific case we couldn't forward from
> > dump_decl to dump_expr and j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #2 from Andrey V ---
Replacing throw/try/catch with longjmp/setjmp for non-returning function exit,
like so:
#include
#include
#include
pthread_once_t flag_ = PTHREAD_ONCE_INIT;
int call_count = 0;
jmp_buf catch_;
void func_()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
Eric Fiselier changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #5 from Luca Stoppa ---
I think you can close this "bug".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #4 from Luca Stoppa ---
It is a very very very... old application written like 20 years ago.
Anyway, we'll try to remove that option from our build process.
Thanks for your answer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #3 from Jonathan Wakely ---
The option works exactly as documented, and can be used freely with your own
code if you need to compile old code. Obviously if you include any code you
didn't write (such as standard library headers) then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64783
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65225
--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #1)
> Presumably yours ?
Yes, and I think it's fixed. At least all the important aarch64 patches are in
with.
https://gcc.gnu.org/ml/gcc-patches/20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835
Bug 64835 depends on bug 66015, which changed state.
Bug 66015 Summary: align directives not propagated after __attribute__
((__optimize__ ("O2")))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65225
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65068
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||missed-optimization
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66161
Bug ID: 66161
Summary: gcc silent about type incompleteness in error message
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
Jonathan Wakely changed:
What|Removed |Added
Severity|major |minor
--- Comment #1 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #2 from Luca Stoppa ---
I'm sorry, what do you mean with "don't do that"?
Can you please tell me whether c++11/14 with -fno-for-scope is supported?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
Frédéric Buclin changed:
What|Removed |Added
Attachment #35409|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #42 from Frédéric Buclin ---
(In reply to Uroš Bizjak from comment #41)
> The GCC bugzilla favicon now shows generic Bugzilla favicon. Previously, it
> was a GCC favicon.
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
--- Comment #3 from Ed Maste ---
> the posix standard does not seem to disallow \n in the replacement string so
> i think freebsd sed should be fixed (or report the bug to the austingroup).
I can't find language that specifies sed must interpre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
--- Comment #2 from Szabolcs Nagy ---
the posix standard does not seem to disallow \n in the replacement string so i
think freebsd sed should be fixed (or report the bug to the austingroup).
meanwhile i will prepare a fix for this in gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66160
Bug ID: 66160
Summary: gcc-5.1.0 fails with "lambda-expression in unevaluated
context" where gcc-4.9.2 succeeds
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221
Arjen Markus changed:
What|Removed |Added
CC||arjen.markus895 at gmail dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
Bug ID: 66159
Summary: bogus warning for alias-declaration using
elaborated-type-specifier
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
--- Comment #3 from dhowells at redhat dot com ---
The compiler works now, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968
--- Comment #41 from Uroš Bizjak ---
The GCC bugzilla favicon now shows generic Bugzilla favicon. Previously, it was
a GCC favicon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Paolo Carlini from comment #7)
> First blush I'm wondering if in this specific case we couldn't forward from
> dump_decl to dump_expr and just print ‘l->*ptr’. AFAICS, wouldn't be a
> regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66158
Bug ID: 66158
Summary: Use DO loop constraints for optimizing bounds checking
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
--- Comment #1 from Peter Boyle ---
Created attachment 35547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35547&action=edit
unprocessed source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #8 from Douglas Mencken ---
Created attachment 35546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35546&action=edit
linker output for genmatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66134
--- Comment #1 from Ilya Enkovich ---
Author: ienkovich
Date: Fri May 15 09:38:44 2015
New Revision: 223215
URL: https://gcc.gnu.org/viewcvs?rev=223215&root=gcc&view=rev
Log:
gcc/
PR middle-end/66134
* tree-chkp.c (chkp_get_orgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
Bug ID: 66157
Summary: bits/random.tcc compiler error when using
-fno-for-scope
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: major
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #7 from Paolo Carlini ---
First blush I'm wondering if in this specific case we couldn't forward from
dump_decl to dump_expr and just print ‘l->*ptr’. AFAICS, wouldn't be a
regression and would allow us to adopt immediately Manuel' pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156
Bug ID: 66156
Summary: [msp430] wrong code generated with -O2 -mlarge (zero
extension HI -> SI)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
1 - 100 of 104 matches
Mail list logo
