https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555
--- Comment #11 from Dominik Vogt ---
Successfully bootstrapped and regression tested on s390x biarch.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659
--- Comment #22 from Dominik Vogt ---
Successfully bootstrapped and regression tested on s390x biarch.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69987
--- Comment #7 from Dominik Vogt ---
Fixed on s390x.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #11 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70059
Bug ID: 70059
Summary: Invalid codegen on AVX-512 when using
_mm512_inserti64x4(x, y, 0)
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936
--- Comment #14 from Richard Biener ---
Author: rguenth
Date: Thu Mar 3 09:12:53 2016
New Revision: 233928
URL: https://gcc.gnu.org/viewcvs?rev=233928&root=gcc&view=rev
Log:
2016-03-03 Richard Biener
PR tree-optimization/55936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70023
Uroš Bizjak changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70059
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69904
--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #5)
> I'll propose a patch to disallow copying of load-exclusive insns
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00211.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70046
--- Comment #3 from Richard Biener ---
I've confirmed the regression to be caused by r230647
Estimated Estimated
Base Base BasePeak Peak Peak
Ben
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70043
--- Comment #1 from Martin Liška ---
Author: marxin
Date: Thu Mar 3 10:08:09 2016
New Revision: 233934
URL: https://gcc.gnu.org/viewcvs?rev=233934&root=gcc&view=rev
Log:
Skip properly debug stmt in optimize_mask_stores (PR
PR tree-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70059
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70046
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60632
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70050
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Thu Mar 3 11:42:19 2016
New Revision: 233937
URL: https://gcc.gnu.org/viewcvs?rev=233937&root=gcc&view=rev
Log:
PR middle-end/70050
* match.pd (X % -Y): Add INTEGRAL_T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70050
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
Bug ID: 70060
Summary: array initialization adds to executable size
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
--- Comment #9 from Leon Winter ---
> If you declare it outside the loop body, gcc generates exactly the same code
> for a 'for' and a 'do-while'.
You are right. When I did the testing, I mistakenly left out "-O1" or such so I
did not see the wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70049
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70061
Bug ID: 70061
Summary: [6 Regression] ICE: SIGSEGV in delete_insn_chain()
with -mstringop-strategy=libcall
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70054
--- Comment #1 from Richard Biener ---
GCC 6 re-introduces type-based alias analysis for pointer objects and thus
if you do sth like
*(int *)&x = A;
... = *(long *)&x;
then the compiler will now remove the store (because 'int *' does not
ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Leon Winter from comment #9)
> > If you declare it outside the loop body, gcc generates exactly the same code
> > for a 'for' and a 'do-while'.
>
> You are right. When I did the testing,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70062
Bug ID: 70062
Summary: ICE: in decide_alg, at config/i386/i386.c:26173 with
-mmemcpy-strategy=libcall
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70063
Bug ID: 70063
Summary: msp430 stack corruption for naked functions
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70043
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044
--- Comment #2 from rguenther at suse dot de ---
On Thu, 3 Mar 2016, ktkachov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044
>
> ktkachov at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70061
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70064
Bug ID: 70064
Summary: wrong code with custom flags and quite big testcase @
i686
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70063
--- Comment #1 from Andrew Wygle ---
A quick correction - as my example above accidentally shows, compiling with
optimizations isn't a guarantee of avoiding this problem, it just sometimes
helps if the arguments are unused, as the optimizer will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #84 from alalaw01 at gcc dot gnu.org ---
Bah. Do you normally use -fno-aggressive-loop-optimizations? With
-funknown-commons, did you try with/out aggressive loop opts?
Powerpc{,64}{be,le} ?
The unknown-commons testcase I included in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70064
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
--- Comment #2 from Stas Sergeev ---
The question is not what happens now, but rather
can't it be done differently?
Is there any reason why gcc can't but it into .bss
anyway, and initialize from the startup code?
I realize this is not a bug but a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69979
--- Comment #1 from Andre Vieira ---
I believe expand_function_start is responsible for this code. When it calls
assign_parms it will generate RTL to copy the incoming struct parameter onto
the stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
--- Comment #11 from Leon Winter ---
Created attachment 37855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37855&action=edit
Current test case
gcc version 4.9.3
$ gcc -std=gnu99 -O1 -Wall -Wextra -o foo main.c
$ gcc -std=gnu99 -O2 -Wal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70063
Andre Vieira changed:
What|Removed |Added
CC||andre.simoesdiasvieira@arm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69824
--- Comment #5 from Bernd Schmidt ---
I've been playing with that for a while. If the continue is replaced with
gcc_unreachable, we find parm-impl-decl-[13].c testcases that trigger it. I
think your patch is probably fine, but I'm not 100% sure a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
--- Comment #12 from Leon Winter ---
> Are you saying that GCC 4.9 does not warn? That would be surprising and a
> regression. If you could find the revision that started warning, that would
> be helpful.
Funny you would ask, it turns out that o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065
Bug ID: 70065
Summary: Add a new option to suppress a warnings about
operators priority
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065
--- Comment #1 from Marc Glisse ---
Patches should be sent to gcc-patc...@gcc.gnu.org for review. Please avoid
unrelated whitespace changes in your patch. The test "if (warn_precedence)"
seems redundant with the use of OPT_Wprecedence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065
--- Comment #2 from Marek Polacek ---
Wait, so what is wrong with this?
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
You can use -Wno-parentheses to disable that warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065
--- Comment #3 from Serge Roussak ---
(In reply to Marc Glisse from comment #1)
> The test "if (warn_precedence)"
> seems redundant with the use of OPT_Wprecedence.
I see all except this mentioned: what do you mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065
--- Comment #4 from Serge Roussak ---
(In reply to Marek Polacek from comment #2)
> Wait, so what is wrong with this?
> warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
> You can use -Wno-parentheses to disable that warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70065
--- Comment #5 from Serge Roussak ---
(In reply to Marek Polacek from comment #2)
> Wait, so what is wrong with this?
> warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
> You can use -Wno-parentheses to disable that warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68530
Jason Merrill changed:
What|Removed |Added
Keywords|ice-on-valid-code, |ice-on-invalid-code
|r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
--- Comment #12 from Alan Modra ---
Created attachment 37857
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37857&action=edit
workaround patch
Given the problems identified with notes (and of course the notes are what
drives reg_equiv_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68802
--- Comment #3 from Philip Deegan ---
Anything I can do to help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69798
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68206
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 3 14:32:15 2016
New Revision: 233940
URL: https://gcc.gnu.org/viewcvs?rev=233940&root=gcc&view=rev
Log:
PR target/70021
* tree-vect-stmts.c (vect_mark_relevant):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64696
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69059
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68074
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68187
--- Comment #6 from David Malcolm ---
Candidate patches posted:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00260.html
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00261.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70032
--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Note the very first "cleanup" would be to rip out all value numbering use
> from
> the current implementation and make the pass properly separate. Now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #85 from Bill Seurer ---
I just grabbed a fresh copy of the gcc source, applied the patch, built it,
fixed up the options for 416.gamess, and when I ran it it worked! I should
have done that yesterday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #2 from Wilc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70062
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
--- Comment #3 from Jakub Jelinek ---
If some arch in glibc implements memcpy.S and does not implement mempcpy.S,
then obviously the right fix is to add mempcpy.S for that arch, usually it is
just a matter of #include memcpy.S with some define US
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
--- Comment #4 from Jakub Jelinek ---
Note the choice of this in a header file is obviously wrong, if you at some
point fix this up, then apps will still call memcpy rather than mempcpy, even
when the latter is more efficient (because it doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70061
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70061
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70062
--- Comment #2 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> This ICEs since the -mmemcpy-strategy option has been added in r201645, so
> technically not a regression.
IMO, it looks like the fix for PR 69888 has to be refine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70062
--- Comment #3 from Jakub Jelinek ---
I'll look at it then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #86 from Bill Seurer ---
I also tried it on a power8 BE machine and it worked fine there, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
--- Comment #4 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #3)
> If you want it to be initialized at runtime, do that yourself.
> The compiler can't do that, you could e.g. access bigarr from another
> compilation unit before th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70062
--- Comment #4 from Jakub Jelinek ---
Created attachment 37858
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37858&action=edit
gcc6-pr70062.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69904
--- Comment #7 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Mar 3 17:25:43 2016
New Revision: 233941
URL: https://gcc.gnu.org/viewcvs?rev=233941&root=gcc&view=rev
Log:
[ARM] PR rtl-optimization/69904: Disallow copying/duplicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69904
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066
Bug ID: 70066
Summary: alignas imposes the wrong limit on data members
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066
Martin Sebor changed:
What|Removed |Added
Known to fail||4.9.3, 5.3.0, 6.0
--- Comment #1 from Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Bernd Schmidt changed:
What|Removed |Added
Target Milestone|4.9.4 |7.0
--- Comment #14 from Bernd Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066
--- Comment #2 from Andrew Pinski ---
> The BIGGEST_FIELD_ALIGNMENT macro is defined in config/i386/i386.h with the
> following comment:
...
> #ifdef IN_TARGET_LIBS
This definition version is only ever used in libobjc and libgcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066
--- Comment #3 from Andrew Pinski ---
This is the definition which matters:
/* Minimum size in bits of the largest boundary to which any
and all fundamental data types supported by the hardware
might need to be aligned. No data type wants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #87 from alalaw01 at gcc dot gnu.org ---
Great, many thanks for the tests, I was worried if we had hit another distinct
issue. (Of course this would be better on gcc-patches!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
--- Comment #5 from Wilco ---
(In reply to Jakub Jelinek from comment #3)
> If some arch in glibc implements memcpy.S and does not implement mempcpy.S,
> then obviously the right fix is to add mempcpy.S for that arch, usually it
> is just a matte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
--- Comment #6 from Wilco ---
(In reply to Jakub Jelinek from comment #4)
> Note the choice of this in a header file is obviously wrong, if you at some
> point fix this up, then apps will still call memcpy rather than mempcpy,
> even when the lat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #4 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
--- Comment #7 from Jakub Jelinek ---
(In reply to Wilco from comment #6)
> (In reply to Jakub Jelinek from comment #4)
> > Note the choice of this in a header file is obviously wrong, if you at some
> > point fix this up, then apps will still ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #13 from Jakub Jelinek ---
So, does anybody plan to change CONSTANT_ALIGNMENT for rs6000? If not, I think
we should close this bug, because changing the generic code back is
undesirable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65061
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65061
--- Comment #9 from Jason Merrill ---
Author: jason
Date: Thu Mar 3 18:43:01 2016
New Revision: 233942
URL: https://gcc.gnu.org/viewcvs?rev=233942&root=gcc&view=rev
Log:
PR c++/65061
* parser.c (cp_parser_template_name): Call st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67257
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69257
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
David Edelsohn changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066
Martin Sebor changed:
What|Removed |Added
Blocks||58601
--- Comment #5 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
--- Comment #8 from H.J. Lu ---
Inlining mempcpy uses a callee-saved register:
hjl@gnu-6 tmp]$ cat m.c
extern char *src, *dst;
char *
foo (unsigned long i)
{
return __builtin_mempcpy (dst, src, i);
}
char *
bar (unsigned long i)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70067
Bug ID: 70067
Summary: internal compiler error: in strip_typedefs, at
cp/tree.c:1466
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: major
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058
--- Comment #2 from Jerry DeLisle ---
Paul, could you please post the terminal output that gives the error message
please.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068
Bug ID: 70068
Summary: ICE: out of memory on involving empty substring
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068
--- Comment #1 from Gerhard Steinmetz
---
Similar :
$ cat z7.f90
program p
integer :: i
character(3), parameter :: x(3) = ['abc', 'ijk', 'xyz']
character(3), parameter :: y(2) = [(x(i)(i:1), i=2,3)]
end
$ gfortran-6 z7.f90
*** Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069
Bug ID: 70069
Summary: Uninitialized value default to zero, plus warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070
Bug ID: 70070
Summary: ICE on initializing character data beyond min/max
bound
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority
1 - 100 of 150 matches
Mail list logo
