https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867
--- Comment #2 from Janne Blomqvist ---
(In reply to Dominique d'Humieres from comment #1)
> This seems to be a regression between revisions r243624 (2016-12-13,
> compiles) and r243765 (2016-12-16, ICE with -m32 or -m64).
Thanks for quickly nar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745
--- Comment #3 from Frederic Marchal ---
One more truncated entry in gcc/config/aarch64/aarch64.opt at line 154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #16 from Peter Bergner ---
(In reply to Vladimir Makarov from comment #15)
> Sorry, I applied your changes manually and did a typo. The line
>
> SET_SRC (curr_insn_set) = new_reg;
>
> should be removed.
>
> I tested this patch wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #15 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #13)
> (In reply to Vladimir Makarov from comment #11)
> > Created attachment 40372 [details]
> > The proposed patch
>
> Agreed your additions to my change looks g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868
--- Comment #4 from Andrew Pinski ---
It is the call to printf and the order of evaluation of its arguments. That is
take:
F (g (), h ());
g or h could be called first. The same thing is true here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868
--- Comment #3 from Vlad Krasnov ---
I though that since va_arg is defined as a macro, it should be evaluated in
order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868
--- Comment #2 from Andrew Pinski ---
Note C++17 does specify this more now IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78868
Bug ID: 78868
Summary: When one variadic function calls another one, the
parameters are reversed, if va_arg is used directly in
function call.
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78866
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78683
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #14 from Peter Bergner ---
(In reply to Joseph S. Myers from comment #12)
> Created attachment 40373 [details]
> fnmatch.i preprocessed source
>
> With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE
> buildin
On 12/18/2016 12:15 PM, Eduardo Yÿffe1nez via gcc-bugs wrote:
>I wish to report a problem with g++ 4.x, g++ 5.x, g++ 6.x. I'm trying
>to implement a very classic Factory Method Pattern in C++, I can do it
>very easily in MS-Visual C++, but in Linux with g++ the code compiles
>but I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #13 from Peter Bergner ---
(In reply to Vladimir Makarov from comment #11)
> Created attachment 40372 [details]
> The proposed patch
Agreed your additions to my change looks good. However, I'm not so sure about
this last hunk:
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #12 from Joseph S. Myers ---
Created attachment 40373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40373&action=edit
fnmatch.i preprocessed source
With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #11 from Vladimir Makarov ---
Created attachment 40372
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40372&action=edit
The proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78867
Bug ID: 78867
Summary: GFortran function returning string ICE with -flto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #10 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #8)
> where "src" is the subreg:SI ..., so the new_reg mode will be SImode and we
> then replace the whole SET_SRC (curr_insn_set) which is the subreg:SI
> (reg:DF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505
--- Comment #8 from Damian Rouson ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047
Markus Trippelsdorf changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047
Markus Trippelsdorf changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047
Markus Trippelsdorf changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Markus Trippelsdorf changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #6 from Mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
--- Comment #5 from Casey Carter ---
I have verified that gcc-6-branch compiles the repro correctly, so yes, this is
a dup of PR78047.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505
--- Comment #7 from Andre Vehreschild ---
As you can see from the commit message in comment #3 it hit trunk on 9th of
Dezember.
Am 19. Dezember 2016 21:03:38 MEZ, schrieb damian at sourceryinstitute dot org
:
>https://gcc.gnu.org/bugzilla/show_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842
--- Comment #3 from Jakub Jelinek ---
(In reply to Nathan Sidwell from comment #2)
> Created attachment 40370 [details]
> trimmed testcase
Isn't this from PR78840 instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505
--- Comment #6 from Damian Rouson ---
Please let me know which day this hit (or will hit) the trunk. I'm currently
using a build dated 20161215.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78864
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659
Jerry DeLisle changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841
--- Comment #2 from Casey Carter ---
Created attachment 40371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40371&action=edit
compressed preprocessed repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659
--- Comment #12 from Jerry DeLisle ---
(In reply to janus from comment #8)
The case that ICEs needs to have an error check in io.c (gfc_resolve_dt). I
have found the location and now need to build the error check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78662
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78622
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
Pablo Halpern changed:
What|Removed |Added
CC||bugzilla@halpernwightsoftwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78840
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78866
--- Comment #1 from Gerhard Steinmetz
---
Older versions down to at least 5.4.1 give :
$ gfortran-7-20161023 -fopenmp -c z1.f90
z1.f90:4:0:
!$omp target
internal compiler error: Segmentation fault
0xc32b7f crash_signal
../../gcc/to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78866
Bug ID: 78866
Summary: ICE in gimplify_adjust_omp_clauses_1, at
gimplify.c:8721
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
Bug ID: 78865
Summary: ICE in create_tmp_var, at gimple-expr.c:473
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78864
--- Comment #1 from Gerhard Steinmetz
---
Older versions give :
$ gfortran-7-20160828 z1.f90
z1.f90:5:16:
namelist /nml/ x
1
Error: NAMELIST object 'x' in namelist 'nml' at (1) is polymorphic and requires
a defined input/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78864
Bug ID: 78864
Summary: ICE in dtio_procs_present, at fortran/resolve.c:13819
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751
--- Comment #2 from Segher Boessenkool ---
In this testcase ifcvt happens upon a branch like:
(jump_insn 28 27 65 2 (set (pc)
(if_then_else (eq (reg:CCEQ 183)
(const_int 0 [0]))
(label_ref:SI 65)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
--- Comment #6 from tprince at computer dot org ---
__sec_reduce_{min,max}_ind in Intel cilk(tm) plus don't give good performance,
so one may suspect they are using size_t.(In reply to Jakub Jelinek from
comment #5)
> While this started with my co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863
Bug ID: 78863
Summary: error on -fsanitize suggests invalid -fsanitize=all
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
--- Comment #5 from Jakub Jelinek ---
While this started with my commit, the actual bug is there from the start of
Cilk+ support.
The __sec_reduce_* builtins are declared with int return type, which doesn't
actual match what they return (it is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70186
--- Comment #2 from David Malcolm ---
Candidate patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01610.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
--- Comment #7 from Martin Sebor ---
While we work toward a resolution it should be possible to avoid the nonnull
warnings by using the -fno-sanitize-recover=undefined option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #7 from Jerry DeLisle ---
(In reply to janus from comment #2)
> I'm afraid I have too little knowledge of the I/O parts of libgfortran to
> fix, but I can at least give some pointers to where things appear to go
--- snip ---
> if (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
f2cfi.c:2572
0x64f64e create_cfi_notes
/home/bmg/src/gcc/gcc/dwarf2cfi.c:2611
0x64f64e execute_dwarf2_frame
/home/bmg/src/gcc/gcc/dwarf2cfi.c:2974
0x64f64e execute
/home/bmg/src/gcc/gcc/dwarf2cfi.c:3454
Version: gcc version 6.2.1 20161219 [gcc-6-branch revision 243794] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #6 from Vadim Zeitlin ---
> One might complain that it only does this transformation when the second
> argument is a constant, not for casts of integer variables to long double.
Yes, in the light of new information, this is what thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #5 from Marc Glisse ---
(In reply to Vadim Zeitlin from comment #4)
> Thanks for the explanation! I didn't realize the template function below was
> smart enough to select __builtin_powil() automatically,
The template selects __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78853
--- Comment #4 from Markus Trippelsdorf ---
See: http://refspecs.linuxfoundation.org/elf/x86-64-abi-0.99.pdf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
--- Comment #5 from Jakub Jelinek ---
(In reply to Martin Liška from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > (In reply to Martin Liška from comment #0)
> > > There are 2 (so far) errors reported:
> > >
> > > 1) gengtype.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78853
--- Comment #3 from Pedro Gonnet ---
OK, thanks for clarifying!
The declaration of __m256i only specifies the attributes vector_size and
may_alias
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/avxintrin.h;hb=HEAD#l56),
so I'm gues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78861
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
--- Comment #4 from Martin Liška ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Martin Liška from comment #0)
> > There are 2 (so far) errors reported:
> >
> > 1) gengtype.c:
> >
> > ../../gcc/gengtype.c: In function ‘const char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #5 from paul.richard.thomas at gmail dot com ---
Hi Janus,
Jerry is the expert here.
Cheers
Paul
On 19 December 2016 at 11:59, janus at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
>
> --- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78861
Bug ID: 78861
Summary: sequencer.cpp:603:53: error: cannot convert
'std::basic_istream::__istream_type {aka
std::basic_istream}' to 'bool' in assignment
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #4 from Vadim Zeitlin ---
Thanks for the explanation! I didn't realize the template function below was
smart enough to select __builtin_powil() automatically, this is quite
impressive (although it doesn't happen in my particular case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78860
niva at niisi dot msk.ru changed:
What|Removed |Added
Target||MIPS
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78860
Bug ID: 78860
Summary: ICE in compilation for MIPS with -mpaired-single
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
--- Comment #6 from Marc Mutz ---
Ah, I see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
--- Comment #5 from Marc Mutz ---
Created attachment 40368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40368&action=edit
Another TU that has an unfixable -Wnonnull warning
g++ -c -pipe -ffunction-sections -O2 -g -fPIC -std=c++1z -fno-ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |NEW
Target Milestone|---
/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20161219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
--- Comment #2 from Martin Liška ---
Created attachment 40367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40367&action=edit
133.pre dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
Senthil Kumar Selvaraj changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #22 from S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
--- Comment #2 from Marc Mutz ---
Created attachment 40366
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40366&action=edit
Preprocessed source
Command line used:
g++ -E -pipe -ffunction-sections -O2 -g -fPIC -std=c++1z -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
--- Comment #1 from Martin Liška ---
Created attachment 40365
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40365&action=edit
131.crited1 dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78859
Bug ID: 78859
Summary: profiledbootstrap failure caused by -Werror=nonnull
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
--- Comment #11 from Jakub Jelinek ---
The default arguments are evaluated in the caller even for non-inline
functions, for those we can hardly have any DW_AT_inline or
DW_TAG_inlined_subroutine just because of the arguments.
So, the question is,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71854
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78858
Bug ID: 78858
Summary: Bogus -Wnonnull warning involving strcmp.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78830
--- Comment #4 from Andrzej Krzemienski ---
Just to clarify, what I request for this "unconditional" check is not the
existence of all operators, but only the check for the iterator_tag (we expect
a bidirectional iterator).
That is, the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78567
Marc Mutz changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #4 from Marc Mutz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71854
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed|2016-07-13 00:00:00 |2016-12-19
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|diagnostic |
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
janus at gcc dot gnu.org changed:
What|Removed |Added
Attachment #40357|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #4 from janus at gcc dot gnu.org ---
Another starting point could be the fact that DTIO procedures appear to work
well on internal units, as long as no namelist output is involved. This case
seems to be handled by "formatted_transfer_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #2 from janus at gcc dot gnu.org ---
I'm afraid I have too little knowledge of the I/O parts of libgfortran to fix,
but I can at least give some pointers to where things appear to go wrong ...
In the function "nml_write_obj" at line 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Dec 19 10:26:04 2016
New Revision: 243794
URL: https://gcc.gnu.org/viewcvs?rev=243794&root=gcc&view=rev
Log:
2016-12-19 Janus Weil
PR fortran/78545
* int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78567
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78748
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78748
--- Comment #6 from Andreas Krebbel ---
Author: krebbel
Date: Mon Dec 19 09:53:56 2016
New Revision: 243793
URL: https://gcc.gnu.org/viewcvs?rev=243793&root=gcc&view=rev
Log:
PR target/78748: S/390: Fix ICE with ANDC splitter.
gcc/ChangeLog:
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78852
Markus Trippelsdorf changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
1 - 100 of 107 matches
Mail list logo
