https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
--- Comment #17 from Paul Thomas ---
Author: pault
Date: Wed Aug 31 05:36:22 2016
New Revision: 239880
URL: https://gcc.gnu.org/viewcvs?rev=239880&root=gcc&view=rev
Log:
2016-08-31 Paul Thomas
Jerry DeLisle
PR fortran/48298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
--- Comment #6 from Peter Bergner ---
Another similar test case, but thi sone I'm able to make fail on a 64-bit LE
compile.
bergner@genoa:~/gcc/BUGS/PR77289$ cat q.i
void dummy (long *);
long bar (long);
void
foo (long a, long b)
{
long array[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #24 from Bill Schmidt ---
This seems to work as a short-term solution (c,c++,ada bootstrap succeeds).
Need to do a full regstrap with all the languages.
Index: gcc/config/rs6000/rs6000.c
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416
Bug ID: 77416
Summary: LRA rematerializing use of CA reg across function call
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #23 from Bill Schmidt ---
Bleah, that doesn't work because offsetreg needs to contain something that's a
valid address in order to use replace_equiv_address. So something more
involved is needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #22 from Michael Meissner ---
Note, if the index register is R0 and the base register is SP, you might not be
able to use the other register (well you can use it, but you likely will get a
segmentation fault or just access the wrong m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #21 from Bill Schmidt ---
I think for the purposes of this bug we should be able to work around it by
forcing the offset register to be modified instead of the base register. Going
to try testing this:
Index: gcc/config/rs6000/rs600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #20 from Michael Meissner ---
Yeah, it sounds like you don't want to adjust any of the stack related
registers.
However, in looking at this $#!%, we probably need to rewrite it so it doesn't
do clever tricks like this. Which probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #19 from Bill Schmidt ---
I'm suspicious of rs6000_split_multireg_move in rs6000.c, which appears to be
the code that gets called to split a TImode move involving a GPR pair.
In particular, this code:
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77415
--- Comment #1 from Gerhard Steinmetz
---
With official releases (configured with --enable-checking=release),
down to at least 4.8 :
$ gfortran-6 z1.f90
z1.f90:1:0:
integer function f()
internal compiler error: in make_decl_rtl, at varasm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77415
Bug ID: 77415
Summary: ICE: tree check: expected function_type or
method_type, have pointer_type in
create_function_arglist, at fortran/trans-decl.c:2263
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395
--- Comment #6 from Ville Voutilainen ---
Fixed on trunk, backporting to the gcc-6 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395
--- Comment #5 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Aug 30 18:46:11 2016
New Revision: 239870
URL: https://gcc.gnu.org/viewcvs?rev=239870&root=gcc&view=rev
Log:
PR libstdc++/77395
* include/std/type_traits (is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #18 from Bill Schmidt ---
The frame pointer adjustments are introduced in 263r.split2. I haven't yet run
down the offending split, but the pattern being split is a *vsx_movti_64bit. I
know we've had changes in the back end fairly re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77414
--- Comment #1 from Gerhard Steinmetz
---
Backup tests, more variants :
$ cat z2.f90
subroutine s(x)
real :: x
contains
subroutine s(x)
character(*) :: x
end
end
$ cat z3.f90
subroutine s(x)
real :: x
contains
subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77414
Bug ID: 77414
Summary: ICE in create_function_arglist, at
fortran/trans-decl.c:2410
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
--- Comment #12 from Gerhard Steinmetz
---
Slightly modified variant :
$ cat z7.f90
subroutine s(x)
contains
subroutine s(x)
end
end
$ gfortran-7-20160828 z7.f90
z7.f90:3:0:
subroutine s(x)
internal compiler error: in gfc_generat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22041
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2013-03-17 12:00:00 |2016-8-30
--- Comment #9 from Thomas Koe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #17 from Eric Botcazou ---
> Is this kind of frame pointer adjustment a common occurrence with Ada code
> gen, or do you think this is related to POWER code gen somehow? I've never
> seen this sort of thing before.
No, that's really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #16 from Bill Schmidt ---
Looks like the back end must be inserting the frame pointer adjustments, as
they aren't there at expand time. From the 218.vregs dump:
(call_insn 141 140 3128 2 (parallel [
(set (reg:TI 3 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #10 from Jeff Hammond ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Jeff Hammond from comment #8)
> > So GCC refuses to compile any code that potentially includes undefined
> > behavior?
>
> Semantics not being defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #9 from Andrew Pinski ---
(In reply to Jeff Hammond from comment #8)
> So GCC refuses to compile any code that potentially includes undefined
> behavior?
Semantics not being defined is different than undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20432
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2008-12-11 21:22:46 |2016-8-30
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #8 from Jeff Hammond ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jeff Hammond from comment #3)
> > Do you seriously pick this one time to prevent the user from even trying to
> > write incorrect code, while allowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #7 from Jeff Hammond ---
The fact that the parser doesn't handle a particle case where something might
go wrong is no reason to have the compiler refuse to compile code that includes
stdatomic.h with -fopenmp. Look at my example and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #15 from Bill Schmidt ---
Created attachment 39520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39520&action=edit
Dumps before and after dse2
Here are the full dumps before and after dse2 in tarball form.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #6 from Andrew Pinski ---
(In reply to Jeff Hammond from comment #3)
> Do you seriously pick this one time to prevent the user from even trying to
> write incorrect code, while allowing an uncountable number of others?
This is differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #5 from Andrew Pinski ---
From the original discussions on why this is disabled:
_Atomic support is currently disabled for Objective-C and OpenMP. For
both (but mainly OpenMP), the relevant parser code needs checking to
determine whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #14 from Bill Schmidt ---
Confirmed that the frame pointer dance is where the issue is. Prior to dse2:
(insn 3854 144 4133 2 (set (reg:DI 9 9 [1674])
(const_int 1208 [0x4b8]))
/home/wschmidt/gcc/gcc-mainline-base/gcc/ada/\
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #4 from Jeff Hammond ---
Apparently, the GCC team wants to make it impossible for anyone to build
software where independent components that share CFLAGS in the build system
cannot use both the C11 atomics header and the OpenMP flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151
--- Comment #21 from Senthil Kumar Selvaraj ---
It occurs with "7.0.0 20160824 (experimental) (GCC)". Besides, the errors go
away if I remove --relax, so I think it's a linker issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
--- Comment #5 from Denis Vlasenko ---
Patches v3 posted to the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02073.html
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02074.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71913
--- Comment #11 from Renlin Li ---
(In reply to Christophe Lyon from comment #10)
> I've noticed that something similar to what Renlin suggested was committed
> to trunk as r238728.
>
> Could this testcase fix be backported to the release branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71917
--- Comment #11 from Eric Botcazou ---
> I'm getting my head around this now! The conversion functions will need to
> perform the 32-bit to 64-bit sign extension but do nothing for the reverse.
> I think this means that only the raw-to-rvalue nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #13 from Eric Botcazou ---
> Yes, it does! The tools appear to be building normally with this option.
> Without it the build of gnattools fails almost immediately.
>
> I'll work on getting some dumps to see what is happening in DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #3 from Jeff Hammond ---
This is awful. How do I disable this horrible thing?
I am using OpenMP to create a thread pool, because C11 threads are still not
implemented in glibc, and all of my access to C11 _Atomic variables use C11
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77374
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336
--- Comment #10 from Yves Vandriessche ---
A similar internal compile error is triggered in find_rank when dealing with
two-dimensional array arguments, for both g++-5.2 and g++-6.1.1.
>void test(double Arr[][16]) {
> double A[16]= {0};
> for(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336
--- Comment #9 from Yves Vandriessche ---
Created attachment 39518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39518&action=edit
2D-array cilk array notation ICE test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #12 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #10)
> > So the double-word load before the call to SS_Release should be from a
> Mark_Id object obtained from a preceding call to SS_Mark. It indeed looks
> like the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #11 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #8)
> > I'm afraid I don't know anything about Ada and how its runtime works; it
> > looks like system.secondary_stack.ss_release is called automatically somehow
> > as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71917
--- Comment #10 from Matthew Fortune ---
(In reply to Eric Botcazou from comment #9)
> > I'll certainly check on this but I did run the fix on both big and little
> > endian MIPS which seems to suggest there isn't a double adjustment overall.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #43 from Szőts Ákos ---
Yes, I can agree with this reasoning. However, when you remove either the
"while" or the "if" statements, the warning disappears. I don't think they
should have any influence on the array_size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69270
mwahab at gcc dot gnu.org changed:
What|Removed |Added
CC||mwahab at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77413
--- Comment #2 from Jonathan Wakely ---
i.e. it's caused by r239777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77413
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #42 from Patrick Palka ---
(In reply to Szőts Ákos from comment #41)
> A newer example:
>
> int main() {
> bool exists = true;
> int i = 0;
> int sum = 0;
>
> volatile int array_size = 7;
> volatile int array[7];
>
> wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71917
--- Comment #9 from Eric Botcazou ---
> I'll certainly check on this but I did run the fix on both big and little
> endian MIPS which seems to suggest there isn't a double adjustment overall.
So this was broken in 64-bit big-endian too before yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77374
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77413
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77413
Bug ID: 77413
Summary: [7 regression] experimental/numeric/gcd.cc etc. FAIL
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77382
--- Comment #4 from Jakub Jelinek ---
If this is invalid Fortran, it should be diagnosed somewhere during resolve.c
and not make it the translation phase. There for the "s" symbol which is a
subroutine is first given a FUNCTION_DECL as backend_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77382
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
Szőts Ákos changed:
What|Removed |Added
CC||szotsaki at gmail dot com
--- Comment #41 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71917
--- Comment #8 from Matthew Fortune ---
(In reply to Eric Botcazou from comment #7)
> > 2016-07-13 Matthew Fortune
> >
> > * interpret-run.cc: Use ffi_arg for FFI integer return types.
>
> so we now have a double adjustment on 64-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69047
--- Comment #10 from rguenther at suse dot de ---
On Tue, 30 Aug 2016, mwahab at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69047
>
> mwahab at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
mwahab at gcc dot gnu.org changed:
What|Removed |Added
CC||mwahab at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77412
--- Comment #1 from Daan van Vugt ---
Some more info: changing 1.0 to 1d0 does not prevent the crash. Adding a type
constructor and changing 1.0 to 1d0 does work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69047
mwahab at gcc dot gnu.org changed:
What|Removed |Added
CC||mwahab at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77396
--- Comment #1 from Jakub Jelinek ---
Created attachment 39517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39517&action=edit
gcc7-pr77396.patch
Untested partial fix for the compiler side. It should fix the common case when
this happens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77412
Bug ID: 77412
Summary: constructor of an extended type with an allocatable
component in the base type crashes gfortran
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77396
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #9 from rguenther at suse dot de ---
On Tue, 30 Aug 2016, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
>
> --- Comment #8 from Alexander Monakov ---
> > The extension is closely modeled af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #8 from Alexander Monakov ---
> The extension is closely modeled after openCL
Hm, that doesn't sound right: gcc had vector types long before OpenCL was even
a thing; I believe it's modeled after Altivec actually: the discrepancy betw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #7 from Richard Biener ---
(In reply to Alexander Monakov from comment #6)
> Thanks. Any comment on having gimple lowering emit cleaner code in the first
> place?
well, I'm not sure if it is worth the trouble. FEs emit
return <<<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #6 from Alexander Monakov ---
Thanks. Any comment on having gimple lowering emit cleaner code in the first
place?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77407
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77393
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77395
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77397
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #5 from Richard Biener ---
OTOH sth like tree-complex.c for vectors would be nice as well (well, really
re-writing tree-vect-generic.c to sth better).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #4 from Richard Biener ---
Note that this is a patten matching issue that could be quite easily fixed in
tree-ssa-forwprop.c:simplify_vector_constructor (which currently recognizes
a VEC_PERM but it should be easy to handle intermedia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69047
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Tue Aug 30 09:22:17 2016
New Revision: 239857
URL: https://gcc.gnu.org/viewcvs?rev=239857&root=gcc&view=rev
Log:
2016-08-30 Richard Biener
PR tree-optimization/69047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77411
--- Comment #1 from Tom de Vries ---
Analysis at https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01985.html :
...
The problem here is that the functions f2 and f3 access a stack-
based object out of bounds and that is inlined in main and
therefore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77411
Bug ID: 77411
Summary: object-size-9.c -fpic -m32 failure
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72866
Jakub Jelinek changed:
What|Removed |Added
Summary|[7 Regression] Compile time |Compile time hog w/ -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #10 from Eric Botcazou ---
> It does look possible that this is an LRA issue. Here's the code right
> before failure:
>
> 100dae08: f8 95 22 39 addir9,r2,-27144
> 100dae0c: 01 00 40 39 li r10,1
> 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77363
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77363
Jiří Engelthaler changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
Alexander Monakov changed:
What|Removed |Added
Summary|SLP does not handle |Poor code generation for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup dot
org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #8 from Eric Botcazou ---
> I'm afraid I don't know anything about Ada and how its runtime works; it
> looks like system.secondary_stack.ss_release is called automatically somehow
> as part of entering make.Initialize, but I have no i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77405
--- Comment #9 from Eric Botcazou ---
> if that attempt doesn't let you reproduce it, and if it still happens when I
> remove that flag, I can start bisecting and see if I can get it to a
> specific day or even commit that caused it. That will o
87 matches
Mail list logo
