https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> I'm currently not sure which one it is, but I'll investigate.
I think it's both ;)
extends_type_of_3.f90 is definitely wrong, because it contains the exact c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69183
Gerhard Steinmetz changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77927
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68377
Markus Trippelsdorf changed:
What|Removed |Added
CC||jeff.mirwaisi at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69183
--- Comment #4 from Gerhard Steinmetz
---
Related (modified example from testsuite) :
$ cat z3.f90
subroutine gang (a)
!$acc routine gang
integer, intent(inout) :: a(n)
integer, allocatable :: i
!$acc loop
do i = 1, 2
a(i) = a(i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78368
Bug ID: 78368
Summary: ICE in lookup_decl, at omp-low.c:1071
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68377
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
Markus Trippelsdorf changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77673
Thomas Preud'homme changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2016-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78369
Bug ID: 78369
Summary: default parameter ICEs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70965
--- Comment #6 from Jakub Jelinek ---
Reduced testcase:
struct A {};
struct B {};
struct C { using p = int *; template using ra = A; };
struct J : C { template struct K { typedef C::ra o; }; };
template struct D
{
struct H : J::K::o { H (J:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #12 from Markus Trippelsdorf ---
Created attachment 40050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40050&action=edit
unreduced testcase
Indeed it look like gcc simply ignores the attribute:
g++ -fPIC -O2 -g -c tsan_rtl.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78193
Eric Botcazou changed:
What|Removed |Added
Severity|normal |major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Tue Nov 15 20:17:39 2016
New Revision: 242454
URL: https://gcc.gnu.org/viewcvs?rev=242454&root=gcc&view=rev
Log:
PR 59406 note that FNV hash functions are incorrect
PR libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
Markus Trippelsdorf changed:
What|Removed |Added
Status|REOPENED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346
--- Comment #7 from Aldy Hernandez ---
(In reply to Arseny Solokha from comment #6)
> Did you copy your session verbatim in #c5? If so, -f(no-)stack-protector
> apparently has nothing to do w/ the issue. Your cross-compilers most likely
> defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365
--- Comment #4 from kugan at gcc dot gnu.org ---
bug320.c also has the same issue:
static void finddpos (coord *,int,int,int,int);
bug320.c +10093 has:
static void
finddpos(cc, xl,yl,xh,yh)
coord *cc;
xchar xl,yl,xh,yh;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #5 from Dr. Kevin B. Beard ---
I've always understood that a comma will terminate a FORTRAN field - for
example:
https://docs.oracle.com/cd/E19957-01/805-4939/z4000743a36d/index.html
Am I misunderstanding the F77 standard? Also, "-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
--- Comment #42 from Jerry DeLisle ---
Author: jvdelisle
Date: Tue Nov 15 23:03:00 2016
New Revision: 242462
URL: https://gcc.gnu.org/viewcvs?rev=242462&root=gcc&view=rev
Log:
2016-11-15 Jerry DeLisle
Thomas Koenig
PR l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78370
Bug ID: 78370
Summary: Missing uninitialzed warning
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #6 from Jerry DeLisle ---
(In reply to Dr. Kevin B. Beard from comment #5)
> I've always understood that a comma will terminate a FORTRAN field - for
> example:
>
> https://docs.oracle.com/cd/E19957-01/805-4939/z4000743a36d/index.htm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67461
--- Comment #4 from Peter Cordes ---
(In reply to Andrew Pinski from comment #1)
> Hmm, I think there needs to be a barrier between each store as each store
> needs to be observed by the other threads.
As we agreed earlier, a full barrier is onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #7 from Steve Kargl ---
On Tue, Nov 15, 2016 at 10:51:41PM +, kevin.b.beard at nasa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
>
> --- Comment #5 from Dr. Kevin B. Beard ---
> I've always understood that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #8 from Steve Kargl ---
On Tue, Nov 15, 2016 at 11:21:05PM +, jvdelisle at gcc dot gnu.org wrote:
>
> I just finished fixing another issue and am now looking at this one. Generally
> speaking if code worked before under g77, we d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78329
--- Comment #1 from chihin ko ---
The bug only happen in member functions,
I tried multiple classes with deducted return type for multiple member
functions, they all point to the same DW_TAG_unspecified_type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78371
Bug ID: 78371
Summary: list::sort doesn't work with non-default-constructible
allocators
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #10 from Dominique d'Humieres ---
> We are getting a segfault right after the error and the backtrace
> is landing in the middle of read_block_direct, so the error recovery
> is broken. Segfault is never acceptable so I will fix that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
--- Comment #22 from Bill Schmidt ---
Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01541.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #11 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #10)
> > We are getting a segfault right after the error and the backtrace
> > is landing in the middle of read_block_direct, so the error recovery
> > is broke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78370
--- Comment #1 from Andrew Pinski ---
In this case, GCC does not know that a escapes only at func2 so it assumes
func1 touches a. I think there is a bug which says the same thing already but
I am too lazy to look for it right now. PR 24639 migh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78372
Bug ID: 78372
Summary: gdb/demangler crashes
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #14 from Markus Trippelsdorf ---
Here is a small testcase:
markus@x4 tsan % cat tsan_rtl.ii
__attribute__((tls_model("initial-exec"))) extern __thread char b[];
__thread char b[1];
int c;
void fn1() { c = *b; }
markus@x4 tsan % clan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #15 from Markus Trippelsdorf ---
Easiest fix:
diff --git a/libsanitizer/tsan/tsan_rtl.cc b/libsanitizer/tsan/tsan_rtl.cc
index 07fa165e939c..0a40e3c9a2e1 100644
--- a/libsanitizer/tsan/tsan_rtl.cc
+++ b/libsanitizer/tsan/tsan_rtl.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #16 from Dmitry Vyukov ---
So is it a bug in gcc or in tsan runtime?
I thought that an attribute attached to a definition must affect declaration as
well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #17 from Markus Trippelsdorf ---
(In reply to Dmitry Vyukov from comment #16)
> So is it a bug in gcc or in tsan runtime?
> I thought that an attribute attached to a definition must affect declaration
> as well.
Yes, I would say it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68468
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 16 07:01:56 2016
New Revision: 242468
URL: https://gcc.gnu.org/viewcvs?rev=242468&root=gcc&view=rev
Log:
PR libgcc/68468
* unwind-dw2-fde-dip.c: Fix build on FDPI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78373
Bug ID: 78373
Summary: [7 Regression] error: constant not recomputed when
ADDR_EXPR changed
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78373
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #18 from Jakub Jelinek ---
Well, GCC has always required that the tls_model attribute is specified on all
the declarations/definitions (since the introduction of the extension) rather
than just one of them, and matches in between them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
--- Comment #19 from Jakub Jelinek ---
As for the ld.bfd optimization that makes linking with ld.bfd work, that is an
optimization if there are any IE relocations then other GD/LD relocations are
turned into them too, because once you have any IE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78124
--- Comment #2 from lucdanton at free dot fr ---
I ran into a different program that regressed starting at r241187 (again, only
for -std=c++1z), this time not involving explicit constructors:
//--
struct aggr {
int x;
};
struct base
101 - 144 of 144 matches
Mail list logo
