https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70233
--- Comment #6 from Jerry DeLisle ---
The failures I looked at were becasue the constructors were using strings of
different sizes. So my question was going to be what are the rules. Are the
strings suppose to get padded to the length of the cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70270
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70276
--- Comment #1 from Stefan Holdermans ---
A possible solution would be to make the accesses to `std::ios_base::_M_width`
from `std::ios_base::width()` and `std::ios_base::width(streamsize)` atomic.
Currently, these functions are defined by
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70309
Chengnian Sun changed:
What|Removed |Added
CC||chengniansun at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70310
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70223
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
Oleg Endo changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70205
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #5 from rguenther at suse dot de ---
On Thu, 17 Mar 2016, hongxu.jia at windriver dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
>
> --- Comment #3 from hongxu jia ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
--- Comment #7 from psturm at computervoice dot com ---
Created attachment 38007
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38007&action=edit
test suite summary
I built hjl/pr70150 branch and while the prior test suite failures are gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70121
Patrick Palka changed:
What|Removed |Added
Target Milestone|5.4 |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70223
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70205
--- Comment #9 from Paolo Carlini ---
I see...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70185
--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> stage1 approved (conditional on bootstrap/regtest):
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00980.html
bootstrapped and reg-tested, no issues found.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70277
Bug ID: 70277
Summary: Improve code generation for large initializer lists
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
--- Comment #6 from Ilya Enkovich ---
(In reply to rguent...@suse.de from comment #5)
> I think that would be an odd transform. But yes, The pattern is probably
> dead now and can as well be removed...
This test proves pattern is not dead and s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||marcus.appleby at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70162
--- Comment #5 from Oleg Endo ---
(In reply to Nick Clifton from comment #4)
> Yes - I would much prefer to patch the assembler so that it can cope with
> large
> values, even when compiled for a 32-bit host. That way the assembler will be
> ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70285
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70284
--- Comment #1 from Faraz Shahbazker ---
Created attachment 38006
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38006&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70285
--- Comment #3 from Jakub Jelinek ---
I think the bug is somewhere in build_conditional_expr_1. arg2 has signed char
type, and arg2_type = unlowered_expr_type (arg2); is int, which is what we
want, but for whatever reason we end up building a CO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70264
Marek Polacek changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70259
Bug ID: 70259
Summary: [6 Regression] -flifetime-dse=2 bug with empty bases
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #2 from Richard Biener ---
IMHO it doesn't make sense to prune system header paths here and having them
is desired.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70273
--- Comment #9 from Richard Henderson ---
Created attachment 38003
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38003&action=edit
proposed patch
Alternately, instead of setting local_decls early (and doing
other tri-state-ish things in c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70245
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70271
--- Comment #2 from Matthias Hochsteger ---
Looks like the following commit introduced this behavior:
commit b309adc8ef90cd7c7ecc46124707a51a53cfb205
Author: rguenth
Date: Fri Sep 18 12:59:32 2015 +
2015-09-18 Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #6 from Viktor Ostashevskyi ---
I'm not sure about bug prioritizing policies, but for me it looks like this
should get P1 or documentation/release notes for GCC5 and GCC6 should state
that -fno-ellide-constructor is broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #9 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #7)
> The bswap pass could learn to split this up into two loads and bswaps and
> combine the results with a single shift and or.
I'll add it to the bswap TODO l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70299
--- Comment #5 from Jonathan Wakely ---
Using the __builtin_powi* functions was done for PR11706, I believe because
they can be a lot more efficient than the general powl(double, double)
implementations. So it seems that for C++11 and later we pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70258
H.J. Lu changed:
What|Removed |Added
Summary|-fPIE isn't passed to lto |-fPIE isn't passed to lto
|b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
Rainer Orth changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70271
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70263
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70287
--- Comment #1 from Andrey Tarasevich ---
Created attachment 38012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38012&action=edit
correct test case
Wrong test case submitted. This is correct one. Sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
--- Comment #4 from hongxu jia ---
Created attachment 37995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37995&action=edit
Implement patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70261
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #23 from Richard Henderson ---
(In reply to Jiong Wang from comment #21)
> Please check the documentation at
> http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/
> Cortex_A57_Software_Optimization_Guide_external.pdf, page 14,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70280
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976
--- Comment #35 from Jonathan Wakely ---
I've backported the std::allocator_traits> partial
specialization to the gcc-4.9 and gcc-5 branches now. Please let me know if
this makes any difference for your use cases (and provide testcases to
reprodu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70188
--- Comment #9 from John David Anglin ---
Author: danglin
Date: Thu Mar 17 22:49:15 2016
New Revision: 234308
URL: https://gcc.gnu.org/viewcvs?rev=234308&root=gcc&view=rev
Log:
PR target/70188
* config/pa/constraints.md: Revert 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120
--- Comment #9 from Richard Henderson ---
Ah right, -ffunction-sections.
That requires a more extensive, though less hackish, fix.
Will post a new patch later this afternoon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70205
--- Comment #10 from Patrick Palka ---
Author: ppalka
Date: Fri Mar 18 01:26:50 2016
New Revision: 234317
URL: https://gcc.gnu.org/viewcvs?rev=234317&root=gcc&view=rev
Log:
Fix PR c++/70205 (ICE on valid call to qualified static member function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
--- Comment #5 from rguenther at suse dot de ---
On Wed, 16 Mar 2016, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
>
> --- Comment #4 from Marc Glisse ---
> (In reply to Ilya Enkovich from comment #2)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70183
vries at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
Component|pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70258
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70259
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Wed Mar 16 19:37:22 2016
New Revision: 234267
URL: https://gcc.gnu.org/viewcvs?rev=234267&root=gcc&view=rev
Log:
PR c++/70259
* decl.c (start_preparsed_function): Don't cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70278
--- Comment #2 from Bernd Schmidt ---
Author: bernds
Date: Fri Mar 18 19:09:08 2016
New Revision: 234342
URL: https://gcc.gnu.org/viewcvs?rev=234342&root=gcc&view=rev
Log:
Fix PR70278, a problem with the previous split_reg change
PR rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70224
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #10)
[...]
>> I just did, but it ICEed in stage2:
>>
>> +===G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70252
--- Comment #4 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Mar 18 09:36:32 2016
New Revision: 234323
URL: https://gcc.gnu.org/viewcvs?rev=234323&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/70252
* tree-vect-stmts.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70264
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70277
--- Comment #2 from Jonathan Wakely ---
It's allowed by Annex B in the standard (although I don't see specific mention
of a suggested minimum for the number of initializers in a braced-init-list):
Because computers are finite, C++ implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70273
Richard Henderson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70269
--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37994&action=edit
tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70304
Andrew Paprocki changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70309
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215
--- Comment #5 from Richard Henderson ---
Author: rth
Date: Wed Mar 16 23:53:01 2016
New Revision: 234271
URL: https://gcc.gnu.org/viewcvs?rev=234271&root=gcc&view=rev
Log:
Gimplify vec_cond_expr with condition inside
PR middle-end/70240
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70272
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70295
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70241
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114
Keith Marshall changed:
What|Removed |Added
CC||keith.marshall at mailinator
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #16 from Anthony Williams ---
Would it be worth ignoring pthread_once and using an implementation of
call_once based on Mike Burrows' algorithm?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2444.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70224
--- Comment #11 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)
> > --- Comment #9 from Jeffrey A. Law ---
> > So I realized that given the nature of this bug a simple bootstrap on sparc
> > wasn't going to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
--- Comment #2 from Ilya Enkovich ---
Here is a responsible match.pd pattern:
/* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C), since vector comparisons
return all-1 or all-0 results. */
/* ??? We could instead convert all instances of the vec_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70298
Bug ID: 70298
Summary: std::call_once hangs on second call if first threw an
exception
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70298
nsz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69710
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70260
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70271
Bug ID: 70271
Summary: internal compiler error: in dwarf2out_finish, at
dwarf2out.c:27346
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70162
Nick Clifton changed:
What|Removed |Added
Attachment #37974|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70276
--- Comment #2 from Stefan Holdermans ---
Note that the C++11 Standard (§27.4.1) prescribes that
"Concurrent access to a synchronized (§27.5.3.4) standard iostream object’s
formatted and unformatted input (§27.7.2.1) and output (§27.7.3.1) funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70258
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70298
--- Comment #3 from Jonathan Wakely ---
Or more accurately, non-(x86-*-gnu), since x86 with musl libc has the same
problem as non-x86 glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57006
Tom Tromey changed:
What|Removed |Added
Summary|extend DWARF to indicate|refer to
|types coming fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17239
Václav Haisman changed:
What|Removed |Added
Version|5.3.0 |4.0.0
--- Comment #3 from Václav Haisma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70199
Richard Henderson changed:
What|Removed |Added
Summary|[5/6 Regression] Crash at |[5 Regression] Crash at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70266
Bug ID: 70266
Summary: ICE on invalid code on x86_64-linux-gnu: unexpected
expression ‘foo’ of kind overload
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70311
Bug ID: 70311
Summary: libgfortran build dies on "implicit declaration of
function strncasecmp"
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
foo_delete (this)
type(foo), intent(inout) :: this
end subroutine
end module
program main
use foo_type
end program
Compiling with "gfortran -Wsurprising" gives:
gfortran-bug-20160319.f90:13:6:
use foo_type
1
Warning: Only array FINAL procedures declared for derived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70297
--- Comment #2 from Piotr Zierhoffer ---
Created attachment 38024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38024&action=edit
Test case with -save-temps
This file does NOT trigger the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
--- Comment #6 from rguenther at suse dot de ---
On Wed, 16 Mar 2016, mpolacek at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
>
> Marek Polacek changed:
>
>What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64713
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70262
--- Comment #3 from Andrew Pinski ---
(In reply to nickdu from comment #2)
> Why is this resolved as invalid? I realize I can increase my stack size.
> However, I believe I'm currently under the limit. In addition, alloca of
> the same size wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70272
--- Comment #1 from Jakub Jelinek ---
Created attachment 37997
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37997&action=edit
gcc6-pr70272.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70192
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69799
--- Comment #10 from dave.anglin at bell dot net ---
On 2016-03-16 12:26 PM, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69799
>
> --- Comment #9 from Dominique d'Humieres ---
>> New Revision: 234240
>>
>> Log:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70240
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70263
--- Comment #4 from Jeffrey A. Law ---
So the testcase has undefined behaviour, but obviously we shouldn't be
crashing.
The key insns are:
(insn 17 16 18 2 (set (mem:SI (plus:DI (mult:DI (reg:DI 98 [ c_lsm.5 ])
(const_int 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66200
Ramana Radhakrishnan changed:
What|Removed |Added
Target Milestone|--- |6.0
--- Comment #9 from Ramana Ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70105
--- Comment #6 from David Malcolm ---
Author: dmalcolm
Date: Thu Mar 17 18:27:47 2016
New Revision: 234303
URL: https://gcc.gnu.org/viewcvs?rev=234303&root=gcc&view=rev
Log:
PR c/70264: fix crash in compatible_locations_p with BUILTINS_LOCATION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70192
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69407
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70280
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70300
Bug ID: 70300
Summary: [6 Regression] ICE: in extract_constrain_insn, at
recog.c:2190 (insn does not satisfy its constraints)
with -mtune=amdfam10 -mavx512bw
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70313
Bug ID: 70313
Summary: libssp/ssp.c should include wincrypt.h for mingw32
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
--- Comment #9 from Marc Glisse ---
I don't find the current situation very consistent. We seem to consider that in
gimple, the output of a vector comparison can only be used directly in a
vec_cond_expr (possibly also {and,ior,xor,bit_not}_expr?)
101 - 200 of 376 matches
Mail list logo