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
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=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=78373
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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 #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 #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=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=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=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=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 #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=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=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=78351
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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
--- 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=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 #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=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=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=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=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=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=78294
Markus Trippelsdorf changed:
What|Removed |Added
Status|REOPENED|NEW
CC|
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=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=59406
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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=77673
Thomas Preud'homme changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2016-09
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=68377
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
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=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=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
Gerhard Steinmetz changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
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=78341
--- Comment #3 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #2)
> Shall we just remove the assertion?
Sounds good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78362
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356
--- Comment #7 from vehre at gcc dot gnu.org ---
Fix at:
https://gcc.gnu.org/ml/fortran/2016-11/msg00140.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70965
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Tue Nov 15 16:32:38 2016
New Revision: 242432
URL: https://gcc.gnu.org/viewcvs?rev=242432&root=gcc&view=rev
Log:
PR c++/78358 - tuple decomposition decltype
* semantics.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> The following patch fixes it:
... but unfortunately causes a failure of extends_type_of_3.f90 in the
testsuite, which means either:
* one of the tests in exten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78367
Bug ID: 78367
Summary: Out-of-line definitions fail to match in-line
declarations with decltype and template arguments
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356
--- Comment #6 from Andrew Benson ---
(In reply to janus from comment #3)
> (In reply to janus from comment #2)
> > I suspect it may be caused by Andre's r241885 ...
>
> I may be wrong, though: It seems like reverting those changes does not solv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78313
--- Comment #3 from David Malcolm ---
(In reply to Jakub Jelinek from comment #0)
> +++ This bug was initially created as a clone of Bug #72774 +++
>
> // PR c++/72774
> // { dg-do compile }
>
> void baz ();
> namespace A { void foo (); }
> voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78326
--- Comment #6 from Jonathan Wakely ---
See Bug 59002, this is one of the ones it depends on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78361
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #9 from Chung-Lin Tang ---
(In reply to Sebastian Huber from comment #8)
> (In reply to Chung-Lin Tang from comment #7)
> > (In reply to Sebastian Huber from comment #6)
> > > (In reply to Chung-Lin Tang from comment #5)
> > > > > I c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78349
--- Comment #1 from Jonathan Wakely ---
I think this is a known issue and intentionally not fixed on the GCC 5 branch
(but it is fixed for GCC 6).
N.B. GNU nm has a -C option to demangle so you don't need c++filt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78364
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366
Bug ID: 78366
Summary: target_clones does not generate resovler function
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365
--- Comment #1 from David Binderman ---
Created attachment 40049
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40049&action=edit
reduced C source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71988
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Nov 15 15:21:49 2016
New Revision: 242426
URL: https://gcc.gnu.org/viewcvs?rev=242426&root=gcc&view=rev
Log:
PR c++/71988
* g++.dg/cpp0x/constexpr-71988.C: New test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78364
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70601
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71988
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363
Richard Biener changed:
What|Removed |Added
Keywords||openmp, wrong-debug
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78358
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
iled by gcc trunk dated 20161115,
revision 242408, and with compiler flag -O2, does this:
mklev.c:80:1: internal compiler error: in determine_value_range, at
tree-ssa-loo
p-niter.c:413
0xda4cb1 determine_value_range
../../trunk/gcc/tree-ssa-loop-niter.c:413
0xda61f0 bound_dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77673
--- Comment #3 from Jakub Jelinek ---
Regressed with r211778 aka PR61517.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #6 from amker at gcc dot gnu.org ---
> > But for tests:
> > FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f -O scan-tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78333
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78292
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78341
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #8 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #7)
> (In reply to Sebastian Huber from comment #6)
> > (In reply to Chung-Lin Tang from comment #5)
> > > > I checked the code generation on some targets for the te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78364
Bug ID: 78364
Summary: [ARM] Error: bit-field extends past end of register --
ubfx
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #7 from Chung-Lin Tang ---
(In reply to Sebastian Huber from comment #6)
> (In reply to Chung-Lin Tang from comment #5)
> > > I checked the code generation on some targets for the test case above. The
> > > arm, bfin, epiphany, i386,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #6 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #5)
> > I checked the code generation on some targets for the test case above. The
> > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets
> > gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #5 from Chung-Lin Tang ---
> I checked the code generation on some targets for the test case above. The
> arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets
> generated all __atomic_* functions.
> Only on Nios II i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78362
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78295
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Nov 15 13:57:59 2016
New Revision: 242413
URL: https://gcc.gnu.org/viewcvs?rev=242413&root=gcc&view=rev
Log:
PR middle-end/78295
* gcc.dg/uninit-pr78295.c: Add -Wno-ps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881
Michael Matz changed:
What|Removed |Added
Summary|[5/6/7 Regression] |[5/6 Regression]
|Non-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77881
--- Comment #6 from Michael Matz ---
Author: matz
Date: Tue Nov 15 14:02:28 2016
New Revision: 242414
URL: https://gcc.gnu.org/viewcvs?rev=242414&root=gcc&view=rev
Log:
PR missed-optimization/77881
* combine.c (simplify_compariso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78319
--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I think this seems to be an issue with uninit pass.
The same behavior can be observed for following test-case on
x86_64-unknown-linux-gnu regardless of r241915.
(test-case is a slight m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78359
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60853
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #4 from Sebastian Huber ---
(In reply to Chung-Lin Tang from comment #3)
> (In reply to Sebastian Huber from comment #2)
> > (In reply to Chung-Lin Tang from comment #1)
> > > Sebastian, I'm not sure what your problem is. The atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #3 from Chung-Lin Tang ---
(In reply to Sebastian Huber from comment #2)
> (In reply to Chung-Lin Tang from comment #1)
> > Sebastian, I'm not sure what your problem is. The atomics in nios2 are
> > implemented by __sync_* functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
--- Comment #5 from Yuri Rumyantsev ---
Yes, I think so.
2016-11-15 14:49 GMT+03:00 rguenth at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348
>
> Richard Biener changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363
Andrey Guskov changed:
What|Removed |Added
Component|c++ |debug
--- Comment #1 from Andrey Guskov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346
--- Comment #6 from Arseny Solokha ---
(In reply to Aldy Hernandez from comment #5)
> -fPIC -fno-stack protector
Did you copy your session verbatim in #c5? If so, -f(no-)stack-protector
apparently has nothing to do w/ the issue. Your cross-co
end=isl --enable-languages=c,c++,fortran,jit,lto
Thread model: posix
gcc version 7.0.0 20161115 (experimental) (GCC)
$ build_ext/bin/g++ fail.cpp -fopenmp –g
fail.cpp: In lambda function:
fail.cpp:6:34: internal compiler error: in force_type_die, at dwarf2out.c:24864
for (int i = [](){ retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60853
--- Comment #3 from janus at gcc dot gnu.org ---
This patch makes gfortran accept the code:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (Revision 242412)
+++ g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848
--- Comment #21 from Bill Schmidt ---
Great, thanks. Just realized I need to add a test case yet -- should have this
on the list later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78360
--- Comment #1 from Markus Trippelsdorf ---
This points to a defect in the P0012R1 implementation:
markus@x4 tmp % cat facet.ii
struct locale;
template bool has_facet(const locale &) throw();
extern template bool has_facet(const locale &);
mar
1 - 100 of 144 matches
Mail list logo
