https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68285
Bug ID: 68285
Summary: Assembler error on x86_64-linux-gnu: invalid
instruction suffix for `movabs'
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
--- Comment #6 from Dominik Vogt ---
> My internal customer has confirmed that this patch fixes his problem with
> Ethereum.
(He had verified the patch I sent, not yet the patch that was committed.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68072
--- Comment #5 from Dominik Vogt ---
Any opinions on the patch in comment 3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
--- Comment #5 from Dominik Vogt ---
Great, thanks! My internal customer has confirmed that this patch fixes his
problem with Ethereum.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68284
Bug ID: 68284
Summary: -Wlong-long causes dialect options to be ignored
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68268
--- Comment #3 from isearcher at 126 dot com ---
Sorry, the configure command is like this (fortran is added):
./configure --prefix=/wk5/WJ/gcc -enable-threads=posix -disable-checking
-disable-multilib -enable-languages=c,fortran --with-gmp=/wk5/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68268
--- Comment #2 from isearcher at 126 dot com ---
i download GCC installation file and tar it at /wk5/WJ/tmp. And i configure
GCC at /wk5/WJ/gcc.
./configure --prefix=/wk5/WJ/gcc -enable-threads=posix -disable-checking
-disable-multilib -enable-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68283
Bug ID: 68283
Summary: ice: gfc_variable_attr(): Bad array reference
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67498
--- Comment #2 from Vittorio Zecca ---
Sorry, I am traveling now, I'll look at it when I am back home, end of
March 2016?
Maybe you better close it, I think at that time gcc 6 will be available.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
--- Comment #2 from Vittorio Zecca ---
I am traveling now, I cannot check the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #23 from Alexander Cherepanov ---
On 2015-11-11 03:53, msebor at gcc dot gnu.org wrote:
> Another way is that the standard requires
> sizeof(excessively-large-vla-type) to overflow/wrap. That's how the
> implementations I've tested b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281
Josh Stone changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
--- Comment #13 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Nov 11 01:11:20 2015
New Revision: 230144
URL: https://gcc.gnu.org/viewcvs?rev=230144&root=gcc&view=rev
Log:
[ARM] PR63870 Remove error for invalid lane numbers
2015-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
--- Comment #12 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Nov 11 01:08:43 2015
New Revision: 230143
URL: https://gcc.gnu.org/viewcvs?rev=230143&root=gcc&view=rev
Log:
[ARM] PR63870 Mark lane indices of vldN/vstN with appropria
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870
--- Comment #11 from cbaylis at gcc dot gnu.org ---
Author: cbaylis
Date: Wed Nov 11 01:05:16 2015
New Revision: 230142
URL: https://gcc.gnu.org/viewcvs?rev=230142&root=gcc&view=rev
Log:
[ARM] PR63870 Add qualifiers for NEON builtins
2015-11-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281
--- Comment #4 from Jonathan Wakely ---
See C++14 8.5 [dcl.init] p12:
If an indeterminate value is produced by an evaluation, the behavior is
undefined except in the following cases:
[... various cases involving unsigned char ...]
so you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #22 from Martin Sebor ---
(In reply to jos...@codesourcery.com from comment #20)
> where the C
> standard fails to recognize limits in such areas but all implementations
> in practice have such limits, that's a defect in the C stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281
--- Comment #3 from Jonathan Wakely ---
(In reply to Josh Stone from comment #2)
> This may also be significant:
>
> bool
> base_query::get_number_param(literal_map_t const & params,
>interned_string k, long & v)
> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #21 from Daniel Micay ---
(In reply to jos...@codesourcery.com from comment #20)
> Undefined behavior when the type is created (not when an object of that
> type is declared or when sizeof is used) seems entirely in accordance with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281
--- Comment #2 from Josh Stone ---
This may also be significant:
bool
base_query::get_number_param(literal_map_t const & params,
interned_string k, long & v)
{
int64_t value;
bool present = derived_probe_builder:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279
Sebastian Pop changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #20 from joseph at codesourcery dot com ---
Undefined behavior when the type is created (not when an object of that
type is declared or when sizeof is used) seems entirely in accordance with
normal C practice in areas such as stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68278
--- Comment #2 from Paul Keir ---
Agreed. I've just tested on 6.0.0 20151110 and there is no ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68282
Bug ID: 68282
Summary: Optimization fails to remove unnecessary sign
extension instruction
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281
--- Comment #1 from Josh Stone ---
I suspect this may actually be acceptable, NOTABUG, because I can't think of
any uninitialized data that would make the effective behavior different than if
it had been checked in the proper order. Both conditi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281
Bug ID: 68281
Summary: '&&' is checked in reverse and reads an uninitialized
value
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
--- Comment #4 from Alan Modra ---
I meant by my testcase comment that gcc/testsuite/gcc.target/powerpc/pr60158.c
is a poor test because it does not seem to emit addresses to .data.rel.ro.local
or any other non-got section, on gcc-4.9, gcc-5 or m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67826
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from Domin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111
Dominique d'Humieres changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111
Bug 49111 depends on bug 64861, which changed state.
Bug 64861 Summary: Possible wrong code with BIND(C) and PRIVATE + slightly
bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64861
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68266
--- Comment #2 from Martin Sebor ---
Yes, it does fix it, thanks.
See also bug 68280 for a related problem, though in a different area. (I'm not
suggesting the two should be fixed as part of the same patch, just pointing to
a similar problem for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68280
Bug ID: 68280
Summary: dependent arrays of excessive size not diagnosed
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244
Dominique d'Humieres changed:
What|Removed |Added
Component|fortran |target
--- Comment #12 from Domin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47266
--- Comment #5 from Dominique d'Humieres ---
Assuming that the test gfortran.dg/module_private_2.f90 at
http://gcc.gnu.org/ml/fortran/2011-01/msg00094.html is intended to cover the
issue at hand and considering that adding the test to the gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67493
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67498
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68278
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
Known t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #18 from Daniel Micay ---
Also, it's possible to use segmented stacks to avoid stack overflow and this
probably breaks in that context too. That's a very niche use case compared to
-fstack-check though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #17 from Daniel Micay ---
It's well-defined C code though. It shouldn't be possible to for anything to go
wrong here when using -fstack-check, i.e. it should be guaranteed to trigger a
stack overflow which is caught. The size wrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
with gcc version 6.0.0 20151110 (experimental) [trunk revision 230080] (GCC)
> gfortran -c -O2 -floop-nest-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
Ian Lance Taylor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Nov 10 20:31:11 2015
New Revision: 230120
URL: https://gcc.gnu.org/viewcvs?rev=230120&root=gcc&view=rev
Log:
PR go/68255
cmd/go: always use --whole-archive for gccg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68278
Bug ID: 68278
Summary: internal compiler error with C++14 polymorphic lambda
and type alias
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #13 from Jonathan Wakely ---
N.B. we could also get rid of the _S_ios_xxx_end enumerators, but that would
break any code which (foolishly) refers to them, e.g. to suppress Clang's
-Wswitch warnings.
My suggestion assumes that __INT_M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158
--- Comment #12 from Jonathan Wakely ---
Richard's patch changes the values returned by operator~ which is not
desirable.
To fix the underlying type to int in C++03 (so that all values of int will be
valid values of the enumeration type) we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
--- Comment #12 from Jonathan Wakely ---
Author: redi
Date: Tue Nov 10 18:08:50 2015
New Revision: 230118
URL: https://gcc.gnu.org/viewcvs?rev=230118&root=gcc&view=rev
Log:
Fix return type of heterogeneous find for sets
PR libstdc++/681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
--- Comment #1 from joseph at codesourcery dot com ---
This is not a standards conformance bug, on multiple grounds:
* The C standard does not permit you to define your own copies of standard
library functions (that is, functions in the standar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265
--- Comment #2 from Zack Weinberg ---
This problem apparently goes back at least as far as 4.8. Stack Overflow
people found a number of variations, please consult
https://stackoverflow.com/questions/23033043/is-it-a-new-c11-style-of-comments
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
--- Comment #2 from Matt Godbolt ---
Thanks for updating the bug. As a corollary, moving the unreachability above
the returns yields the same code as the non-unreachable: https://goo.gl/MdULOs
--
int test_with_unreach_First(Side side, const Foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454
--- Comment #4 from Paul Martin ---
For information :
The Silverfrost FTN95 compiler , version 7.20 compiles with no errors the
program submitted in Comment 0 (though I had to delete two '::' separators).
It gives the same results as the ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277
Bug ID: 68277
Summary: [5] [SH]: error: insn does not satisfy its constraints
when compiling erlang
Product: gcc
Version: 5.2.1
URL: https://buildd.debian.org/status/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601
--- Comment #15 from David Edelsohn ---
GCC development trunk and it will be in GCC 5.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
--- Comment #11 from Jakub Jelinek ---
(In reply to Richard Henderson from comment #10)
> I believe the tokens didn't stay around in C at the time.
> But I might be wrong... it was 9 years ago...
>
> If we can remove it, it does seem like a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
--- Comment #10 from Richard Henderson ---
I believe the tokens didn't stay around in C at the time.
But I might be wrong... it was 9 years ago...
If we can remove it, it does seem like a good idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601
--- Comment #14 from Hugo Koblmueller
---
David, which version does/will include these recent additions?
I recently encountered a crash on program exit in AIX 6.1, in a setup where I
used a static C++ objects inside functions within a shared li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276
Bug ID: 68276
Summary: ios_base::_M_grow_words should use new (std::nothrow)
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
Jason Merrill changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275
--- Comment #1 from Christophe Lyon ---
Created attachment 36678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36678&action=edit
slp1 log, little-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68197
--- Comment #1 from Jonathan Wakely ---
I would argue that your program has undefined behaviour, there is no array
element at a negative index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275
--- Comment #3 from Christophe Lyon ---
Created attachment 36680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36680&action=edit
slp2 log, little-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275
--- Comment #2 from Christophe Lyon ---
Created attachment 36679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36679&action=edit
slp2 log, big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275
Bug ID: 68275
Summary: bb-slp-38 FAILs on armeb
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190
--- Comment #11 from Jonathan Wakely ---
Author: redi
Date: Tue Nov 10 15:12:24 2015
New Revision: 230113
URL: https://gcc.gnu.org/viewcvs?rev=230113&root=gcc&view=rev
Log:
Fix return type of heterogeneous find for sets
PR libstdc++/681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68266
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601
--- Comment #13 from David Edelsohn ---
The recent additions to GCC cxa atexit support on AIX may fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
--- Comment #8 from cesar at gcc dot gnu.org ---
I'm not sure it will make much of a difference, but Thomas is planning on
adding two openacc clauses bind and nohost. Is there anything I can do to help
here, or is this already being taken care of?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68185
--- Comment #2 from Thomas Preud'homme ---
Here's a quick update. What I found so far is that after split2, we have:
(insn 148 61 304 16 (set (reg:CCNO 17 flags)
(compare:CCNO (reg:HI 44 r15 [orig:91 pretmp_9 ] [91])
(const_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
Bug ID: 68274
Summary: __builtin_unreachable pessimizes code
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
Bug ID: 68273
Summary: Wrong code on mips/mipsel with -fno-ipa-sra
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68238
James Greenhalgh changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68238
--- Comment #3 from James Greenhalgh ---
Author: jgreenhalgh
Date: Tue Nov 10 14:40:43 2015
New Revision: 230110
URL: https://gcc.gnu.org/viewcvs?rev=230110&root=gcc&view=rev
Log:
[Patch GCC 4.9/Vect] Partial backport of r228751 (pr68238)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158
--- Comment #3 from joakim.tjernlund at transmode dot se ---
(In reply to Alan Modra from comment #2)
> Fixed on master with git commit 8e2a42caa / svn rev 223209.
> Fixed for gcc-4.9 with git commit 110222ca0 / svn rev 223714.
> Fixed for gcc-4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68145
--- Comment #5 from Julian Taylor ---
thanks, the full application now compiles successfully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255
--- Comment #1 from Dominik Vogt ---
Created attachment 36675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36675&action=edit
Experimental fix.
The attached patch fixes the problem in the "go" tool by forcing the
--whole-archive linker op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68222
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68223
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68208
--- Comment #2 from Jonathan Wakely ---
I thought I remembered dealing with this case as part of my patch for PR2972
but it doesn't look like it. PR19808 is also relevant here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68208
--- Comment #1 from Jonathan Wakely ---
I'm pretty sure this is a dup of a very old bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209
--- Comment #5 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #4)
> Yes it is QoI, but we could still do better.
Yes, I agree that if we accept it with only a warning then it should behave
correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68261
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45715
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68186
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68200
--- Comment #3 from Jonathan Wakely ---
I would like to deprecate mt_allocator, I don't recommend using it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68202
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68263
--- Comment #6 from H.J. Lu ---
(In reply to Yulia Koval from comment #4)
> Why should TARGET_IAMCU support SSE?
It is about using SSE instructions with IAMCU psABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68263
--- Comment #5 from H.J. Lu ---
Created attachment 36674
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36674&action=edit
A patch
1 - 100 of 144 matches
Mail list logo
