https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71167
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71167
--- Comment #1 from Andrew Pinski ---
Most likely a dup of bug 17693.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71164
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71741
--- Comment #2 from Alex ---
At attachment There is no all sources of my program, you can find it here:
https://github.com/mediev/inclined_well/tree/gcc_bug
But, instead of my program, I ask you to try reproduce the simple example of
code here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70938
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71154
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
--- Comment #6 from Paul Eggert ---
> this is because it thinks skip_space() may return NULL:
That sounds like a bug, then, as skip_spaces immediately dereferences its
argument, so it cannot possibly return NULL.
Also, skip_spaces is never pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905
--- Comment #9 from David Binderman ---
I tried a build of the gcc fortran compiler and I found this warning:
../../../src/trunk/libgfortran/intrinsics/date_and_time.c:173:33: warning:
‘%+03d’ directive output truncated while writing ‘9’ bytes i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70934
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905
--- Comment #10 from Jakub Jelinek ---
(In reply to David Binderman from comment #9)
> I tried a build of the gcc fortran compiler and I found this warning:
>
> ../../../src/trunk/libgfortran/intrinsics/date_and_time.c:173:33: warning:
> ‘%+03d’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66334
Andrew Pinski changed:
What|Removed |Added
Target Milestone|6.2 |6.0
--- Comment #14 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71748
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71747
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71749
Bug ID: 71749
Summary: Define _REENTRANT on ARC when -pthread is passed
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71750
Bug ID: 71750
Summary: Define _REENTRANT on Blackfin when -pthread is passed
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71106
--- Comment #3 from Andrew Pinski ---
Doing a movmisalign for mips is actually very easy:
;; Unaligned load/store (movmisalign)
(define_expand "movmisalign"
[(set (match_operand:GPR 0 "nonimmediate_operand")
(match_operand:GPR 1 "move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71739
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71721
Andrew Pinski changed:
What|Removed |Added
Severity|minor |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71738
Jakub Jelinek changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71737
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
--- Comment #3 from Ramana Radhakrishnan ---
Author: ramana
Date: Mon Jul 4 09:06:02 2016
New Revision: 237957
URL: https://gcc.gnu.org/viewcvs?rev=237957&root=gcc&view=rev
Log:
[AArch64] Fix PR target/63874
In this PR we have a situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71751
Bug ID: 71751
Summary: [7 Regression] Segmentation fault in ssa_default_def
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71751
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Known to work||6.1.0
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71739
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71752
Bug ID: 71752
Summary: [7 Regression] ICE in compute_live_loop_exits, at
tree-ssa-loop-manip.c:229 w/ -O1 -ftree-vectorize
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71753
Bug ID: 71753
Summary: Clamp function does not work with O3 optimization
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71190
--- Comment #4 from Markus Trippelsdorf ---
In my case it only happens with "-flto=60 --param lto-partitions=60",
-flto=60 alone works fine.
So perhaps flto-partition=max will help reducing. (Will give it another try
later
today myself.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71670
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Mon Jul 4 09:52:38 2016
New Revision: 237958
URL: https://gcc.gnu.org/viewcvs?rev=237958&root=gcc&view=rev
Log:
rs6000: Fix split of ashdi3_extswsli_dot for memory (PR71670)
The s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71670
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71753
--- Comment #1 from Andrew Pinski ---
Comment on attachment 38830
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38830
Code that reproduces the issue
value + 0x7F00
Will overflow most of the time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71753
--- Comment #2 from Marc Glisse ---
-fsanitize=undefined
a.c:11:21: runtime error: signed integer overflow: 260 + 2147483392 cannot be
represented in type 'int'
You need to use an unsigned type for this type of computation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71753
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71357
--- Comment #2 from Arseny Solokha ---
gcc-7.0.0-alpha20160703 snapshot ICEs w/ -O1 -floop-nest-optimize only, not w/
-O2 and above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691
--- Comment #3 from Jakub Jelinek ---
The testcase looks invalid to me.
In the second iteration of the outermost loop, l = 1, g = 0, so it compares
uninitialized h with 7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71753
--- Comment #4 from Łukasz Spintzyk ---
Yes, this code is utilizing overflow, but it is there for a reason to optimize
the code and get rid of branches as they can slow down program execution.
You can refer to http://locklessinc.com/articles/sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905
--- Comment #11 from David Binderman ---
(In reply to Jakub Jelinek from comment #10)
> I think the warning code should compute both
> minimum and maximum,
I'd be happy for the code to compute minimum only and have maximum
postponed for the fut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691
--- Comment #4 from Jakub Jelinek ---
That said,
char b;
short f;
unsigned e;
int g = 20;
void
foo ()
{
int l, h;
for (l = 0; l <= 7; l++)
{
int j = 38;
if (g)
h = 0;
for (; h <= 7; h++)
{
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71753
--- Comment #5 from Marc Glisse ---
(In reply to Łukasz Spintzyk from comment #4)
> Looking from this point of view is this really invalid?
There is a perfectly valid way to write such code:
"You need to use an unsigned type for this type of co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #13 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #12)
> (In reply to Goswin von Brederlow from comment #11)
> > I think the design is fundamentally lacking in the following points:
> >
> > 1. interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71752
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
--- Comment #12 from rguenther at suse dot de ---
On Sat, 2 Jul 2016, hiraditya at msn dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
>
> AK changed:
>
>What|Removed |Added
> --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691
--- Comment #5 from Jakub Jelinek ---
I bet this is related to the uninitialized i.
We have in bb3:
# RANGE [0, 1] NONZERO 1
# i_57 = PHI
and in bb5:
# RANGE [0, 1] NONZERO 1
# i_48 = PHI
and in bb6:
if (i_48 != 0)
and in basic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71751
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71010
--- Comment #5 from Jonathan Wakely ---
(In reply to Ubikovich from comment #3)
> But since C++14 cbegin invoke std::begin:
>
> // http://en.cppreference.com/w/cpp/iterator/begin
> template< class C >
> constexpr auto cbegin( const C& c ) -> dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71719
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667
--- Comment #5 from alahay01 at gcc dot gnu.org ---
Qirun:
That looks like a separate issue.
My fix for 71667 (under review) is specific to debug statements.
Could you please raise your test case as a new bug and assign it to me. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313
--- Comment #2 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jul 4 12:52:49 2016
New Revision: 237978
URL: https://gcc.gnu.org/viewcvs?rev=237978&root=gcc&view=rev
Log:
PR libstdc++/71313
* src/filesystem/ops.cc (remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313
--- Comment #3 from Ville Voutilainen ---
Fixed on trunk so far, backporting to gcc-6 and gcc-5 shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313
--- Comment #4 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jul 4 13:15:10 2016
New Revision: 237980
URL: https://gcc.gnu.org/viewcvs?rev=237980&root=gcc&view=rev
Log:
PR libstdc++/71313
* src/filesystem/ops.cc (remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71754
Bug ID: 71754
Summary: gcc prints internal error on ARM NEON code with buffer
overflow
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905
--- Comment #12 from David Binderman ---
(In reply to David Binderman from comment #11)
> So it looks to me like format %Lx isn't handled.
Also, %lf seems to cause a crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71754
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||arm*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #29 from Jakub Jelinek ---
The #c27 r237844 change looks bogus to me.
First of all, IMNSHO you can argue this way only if ref is a reference seen in
loop LOOP, which is the case of e.g. *.omp_data_i_23(D).a ref in simd3.f90 -O2
-fopen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71734
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313
--- Comment #5 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jul 4 13:52:21 2016
New Revision: 237981
URL: https://gcc.gnu.org/viewcvs?rev=237981&root=gcc&view=rev
Log:
Backport from mainline
2016-07-04 Ville Voutila
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71190
--- Comment #5 from Markus Trippelsdorf ---
I'm down to 16 *.ii files. It will probably take a few days to creduce them
all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71715
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71707
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71753
--- Comment #6 from Łukasz Spintzyk ---
I confirm changing the code to use unsigned int fixed the problem.
Also there is no signed overflow errors.
Thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #30 from Jakub Jelinek ---
Another thing to think of, e.g.
void
baz (int *p, int *q)
{
#pragma omp simd safelen(2)
for (int i = 0; i < 1024; i++)
p[4 * i] += q[0];
}
for aliasing p[4 * 1022] I think still applies that if (&q[0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #31 from Jakub Jelinek ---
A question is if #pragma GCC ivdep has similar guarantees/restrictions; the
documentation only disallows certain loop-carried dependencies, in particular
those that would prevent vectorization, so I think it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #32 from Jakub Jelinek ---
Also, the testcase has weird dg- directives:
// { dg-do compile }
// { dg-require-effective-target vect_simd_clones }
// { dg-additional-options "-Ofast" }
// { dg-additional-options "-mavx2 -fopenmp-simd" {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28810
Vadim Zeitlin changed:
What|Removed |Added
CC||vz-gcc at zeitlins dot org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #33 from Jakub Jelinek ---
In any case, loop->safelen > 0 test looks also wrong, if there are guarantees
about single iteration only (safelen(1)), then there is nothing useful at all.
So it must be loop->safelen >= 2.
For foo in #c29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71755
Bug ID: 71755
Summary: friend function may not be defined inside a class
using a qualified name but GCC allows that
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71756
Bug ID: 71756
Summary: internal compiler error: in ~saved_token_sentinel, at
cp/parser.c:1228
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #14 from H.J. Lu ---
(In reply to Goswin von Brederlow from comment #13)
> > >
> > > In a kernel there will always be some exception that simply prints a
> > > register dump and stack backtrace. So again how do you access the origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
Bug ID: 71757
Summary: libgcj: unknown symbol
__cxa_throw_bad_array_new_length
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #34 from Yuri Rumyantsev ---
Thanks a lot Jakub for your detail comments.
I have simple fix which cures failures from 71734. The fix is simple
enough and simply check that the ref in problem belongs to simd loop:
diff --git a/gcc/tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #35 from Jakub Jelinek ---
Doesn't it still miscompile the #c33 testcase?
Say with __attribute__((noinline, noclone)) on baz and
int v[2048];
int
main ()
{
v[1023] = 5;
baz (v, v + 1023, v + 1024, v + 1023);
int i;
for (i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #36 from Yuri Rumyantsev ---
#c33 testcase was not tested since I have some doubts about it. Note
that original problem was
#pragma omp simd
for (int i=0; i:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
>
> --- Comment #35 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
--- Comment #1 from Andrew Pinski ---
What target is this on? I get all passes in the java testsuite with GCC 6.1 on
aarch-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
--- Comment #2 from Timo Teräs ---
(In reply to Andrew Pinski from comment #1)
> What target is this on? I get all passes in the java testsuite with GCC 6.1
> on aarch-linux-gnu.
Happens on x86_64-alpine-linux-musl for me. PIE enabled by defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
--- Comment #3 from Timo Teräs ---
(In reply to Timo Teräs from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > What target is this on? I get all passes in the java testsuite with GCC 6.1
> > on aarch-linux-gnu.
>
> Happens on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #37 from Yuri Rumyantsev ---
Jakub,
I assume that yoour #C33 test-case is not correct, i.e. it can not be
marked with pragma omp simd. For example, even if we turn off lim
phase it will be aborted:
my_g++ -O3 -m64 t33.cpp -o t33.exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
--- Comment #4 from Andrew Pinski ---
(In reply to Timo Teräs from comment #3)
> (In reply to Timo Teräs from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > What target is this on? I get all passes in the java testsuite with G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
Andrew Pinski changed:
What|Removed |Added
Keywords||build
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
--- Comment #6 from Andrew Pinski ---
Are you sure __cxa_throw_bad_array_new_length is being exported from
libstdc++v3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905
--- Comment #13 from Martin Sebor ---
(In reply to David Binderman from comment #9)
> I tried a build of the gcc fortran compiler and I found this warning:
>
> ../../../src/trunk/libgfortran/intrinsics/date_and_time.c:173:33: warning:
> ‘%+03d’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71757
--- Comment #7 from Timo Teräs ---
(In reply to Andrew Pinski from comment #6)
> Are you sure __cxa_throw_bad_array_new_length is being exported from
> libstdc++v3?
$ nm -D
./stage1-x86_64-alpine-linux-musl/libstdc++-v3/src/.libs/libstdc++.so|g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71227
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905
--- Comment #14 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #13)
> (In reply to David Binderman from comment #9)
> > I tried a build of the gcc fortran compiler and I found this warning:
> >
> > ../../../src/trunk/libgfortran/i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #38 from Jakub Jelinek ---
Sorry, make that
__attribute__((noinline, noclone)) void
baz (int *p, int *q, int *r, int *s)
{
#pragma omp simd
for (int i = 0; i < 1024; i++)
{
p[i] += q[0] * 6;
r[i] += s[0] * 9;
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66244
--- Comment #4 from Gerhard Steinmetz
---
Compiling slightly modified example from comment 0 :
$ cat z4.f90
program p
integer, target :: a(3)[*]
integer, pointer :: z => a(3)
z = 0
print *, z
end
$ gfortran-7-20160703 -fcoarray=s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71069
--- Comment #2 from Andrew Pinski ---
-fsantize=undefined will catch this at runtime. What is undefined is passing a
NULL to setData.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49905
--- Comment #15 from Martin Sebor ---
(In reply to David Binderman from comment #11)
> BTW, I tried a Linux kernel build and got this
>
> drivers/char/ipmi/ipmi_msghandler.c: In function ‘guid_show’:
> drivers/char/ipmi/ipmi_msghandler.c:2365:9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71058
--- Comment #2 from Andrew Pinski ---
Why would someone even try to use stabs debugging info. It provides almost no
debug information anyways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883
--- Comment #2 from Gerhard Steinmetz
---
Another group of examples.
First case is working in a sufficient manner.
Concatenating two empty hulls (zero len and size, respectivly)
gives an empty hull as result again.
$ cat zz1.f90
program p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883
--- Comment #3 from Gerhard Steinmetz
---
For the following cases, every line produces an ICE :
$ cat zz5.f90
program p
character(*), parameter :: x1(*) = [character(*) ::] // [character(0) ::]
character(*), parameter :: x2(*) = [charac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65173
Gerhard Steinmetz changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71739
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Jul 4 17:31:38 2016
New Revision: 237991
URL: https://gcc.gnu.org/viewcvs?rev=237991&root=gcc&view=rev
Log:
PR c++/71739
* tree.c (attribute_value_equal): Use get_att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47425
Gerhard Steinmetz changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71739
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Mon Jul 4 17:33:50 2016
New Revision: 237992
URL: https://gcc.gnu.org/viewcvs?rev=237992&root=gcc&view=rev
Log:
PR c++/71739
* tree.c (attribute_value_equal): Use get_att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47425
--- Comment #4 from Gerhard Steinmetz
---
Some simplifications :
$ cat z1.f90
program p
character(3) :: x
integer :: n = 3
print *, [character(len(x(1:n))) :: 'a']
end
$ gfortran-7-20160703 z1.f90
z1.f90:4:0:
print *, [characte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71758
Bug ID: 71758
Summary: ICE in verify_gimple_in_cfg, at tree-cfg.c:5212
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: for
1 - 100 of 128 matches
Mail list logo
