https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #15 from Andrew Pinski ---
(In reply to Joshua Kinard from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > What is the kernel version? There has been some recent (this year) fixes
> > inside the kernel for futex.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #33 from rguenther at suse dot de ---
On Mon, 14 Jul 2014, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
>
> --- Comment #32 from Jeffrey A. Law ---
> No, we don't have that information available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
Richard Biener changed:
What|Removed |Added
Known to work||4.10.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61805
Bug ID: 61805
Summary: Demangler crash (GDB PR 17157)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #15 from Dominique d'Humieres ---
> Its sort of like Steve said earlier. The coder is choosing to ignore an
> error condition so anything gfortran does is valid. In this case the
> output got writen to buffer before the error occurr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806
Bug ID: 61806
Summary: [C++11] Expression sfinae w/o access gives hard error
in partial template specializations
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #3 from Richard Biener ---
Like
@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
Richard Biener changed:
What|Removed |Added
Keywords||lto, wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
--- Comment #1 from ktkachov at gcc dot gnu.org ---
There's actually quite a lot of -flto failures (all of them?) besides the ones
posted here all over the gcc testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #10 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #7)
> (In reply to dhowe...@redhat.com from comment #0)
> > I'm also very intrigued by that last line - I can reproduce it quite easily.
>
> This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61671
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #1 from Richard Biener ---
Auto-reduring (matching the bogus assembler pattern).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #11 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #3)
> > libgcc is built with:
> > make -C cris-linux-gnu tooldir=/usr all-target-libgcc
>
> I'd expect "make all-target-libgcc" to Just Work.
So wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #12 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #6)
> Created attachment 33121 [details]
> Patch to config.gcc
>
> Correct patch to config.gcc required to actually build the compiler proper.
Okay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #2 from Richard Biener ---
Created attachment 33122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33122&action=edit
autoreduced testcase
Autoreduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #5 from Vittorio Zecca ---
I just applied your fix and now gcc compiles succesfully with -Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #6 from rguenther at suse dot de ---
On Tue, 15 Jul 2014, zeccav at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
>
> --- Comment #5 from Vittorio Zecca ---
> I just applied your fix and now gcc compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #4 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> Like
>
> @item always_inline
> @cindex @code{always_inline} function attribute
> Generally, functions are not inlined unless optimization is specified.
> For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61807
Bug ID: 61807
Summary: genautomata.c fails to compile
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #4 from Richard Biener ---
Created attachment 33123
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33123&action=edit
more reduced
On trunk reproduces with the following slightly more manual reduced testcase
and -O2 -m32 -g (so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61808
Bug ID: 61808
Summary: Linking error with explicit template instantiation and
default template param
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
Richard Biener changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25992
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|anton.kirill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809
Bug ID: 61809
Summary: [4.10 regression] fold-const.c:14865:47: error:
'DECL_ARGUMENT' was not declared in this scope
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target|aarch64-none-elf|aarch64-none-elf, arm*
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810
Bug ID: 61810
Summary: init-regs.c papers over issues elsewhere
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: missed-optimization, wrong-code
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809
Dmitry G. Dyachenko changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809
--- Comment #2 from Dominique d'Humieres ---
Are you sure that r212549 fails? I'ld rather suspect a typo in r212550, i.e.,
DECL_ARGUMENT instead of DECL_ARGUMENT_FLD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090
--- Comment #12 from Jonathan Wakely ---
r212555 addresses this issue for certain std::lib types, but not for the
general case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61772
--- Comment #2 from Michael Matz ---
Author: matz
Date: Tue Jul 15 14:11:06 2014
New Revision: 212563
URL: https://gcc.gnu.org/viewcvs?rev=212563&root=gcc&view=rev
Log:
PR rtl-optimization/61772
* ifcvt.c (dead_or_predicable): Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809
--- Comment #3 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809
>
> --- Comment #2 from Dominique d'Humieres ---
> Are you sure that r212549 fails? I'ld rather suspect a typo in r212550, i.e.,
> DECL_ARGUMENT instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
--- Comment #5 from Richard Biener ---
;; --- Region Dependences --- b 12 bb 0
;; insn codebb dep prio cost reservation
;; -- --- ---
...
;; 2399012 1 5 1
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
--- Comment #3 from Jan Hubicka ---
how those tests fail?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #13 from Hans-Peter Nilsson ---
(In reply to dhowe...@redhat.com from comment #12)
> (In reply to Hans-Peter Nilsson from comment #6)
> > Created attachment 33121 [details]
> > Patch to config.gcc
> >
> > Correct patch to config.gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #3)
> how those tests fail?
They seem to hit abort ();
signal 6 in the emulator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61811
Bug ID: 61811
Summary: [4.10 Regression] Firefox LTO build error due to
undefined symbols
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #14 from Hans-Peter Nilsson ---
(In reply to dhowe...@redhat.com from comment #10)
> (In reply to Hans-Peter Nilsson from comment #7)
> > (In reply to dhowe...@redhat.com from comment #0)
> > > I'm also very intrigued by that last lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #16 from Dominique d'Humieres ---
> This:
>
> +fmt->format_string_len = strrchr (f->source, ')') - f->source + 1;
>
>Is taking the difference between two string pointers, ie memory addresses
>
> This:
>
> printf("pos 0 =%x, pos )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
Bug ID: 61812
Summary: gcc ICE says "The bug is not reproducible, so it is
likely a hardware or OS problem."
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #1 from dhowells at redhat dot com ---
For an example ICE, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
This is easily reproducible, so the line is incorrect. It might be better
stated conditionally:
"If the bug is n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #15 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #14)
> Could you please consider open a separate PR for the "is not reproducible"
> misdisagnosis?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #17 from Steve Kargl ---
On Tue, Jul 15, 2014 at 09:08:44AM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
>
> --- Comment #15 from Dominique d'Humieres ---
> > Its sort of like Steve sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803
Tom Tromey changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Tom Tromey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #7 from Vittorio Zecca ---
I forgot to mention that my code fragment comes from
#include
void
f(void)
{
for (;;)
_SDT_PROBE(0, 0, 1,(0));
}
Maybe you can find intelligent ways to exercise this code and find
more -Og bugs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
--- Comment #1 from Richard Earnshaw ---
The ABI does not document a model for stack chains, so any use of a frame
pointer is, by definition, purely private to that function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #18 from Dominique d'Humieres ---
> I did not say that iostat had to be used. However, one can find
> things like:
>
> 9.10.1 Error conditions and the ERR= specifier
>
> If an error condition occurs during execution of an input/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
Jason Merrill changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61813
Bug ID: 61813
Summary: __attribute__((__packed__)) does not pack struct
containing uint16_t with uint32_t
Product: gcc
Version: unknown
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25992
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|paolo.carlini at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814
Bug ID: 61814
Summary: [c++1y] cannot use decltype on captured arg-pack
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
--- Comment #2 from Maxim Ostapenko ---
So looks like fast unwinding in libsanitizer is not portable to GCC for ARM
Linux target because of incompatible frame pointer value. But how is
libsanitizer going to identify functions/object files compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
--- Comment #10 from Dominique d'Humieres ---
(In reply to Dominique d'Humieres from comment #4)
> > After providing all the missing 'USE' items:
>
> Where did you get them?
Adding the following at the beginning of the original test allows to g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
--- Comment #3 from Evgeniy Stepanov ---
Yes, FP on ARM is non-standard and differs in GCC and Clang implementations.
Disabling fast unwind is not really an option, as you are looking at 10x, maybe
100x slowdown (depending of the app, of course).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Tom Tromey from comment #2)
> > In this case yes, but this is not always the case: See PR5252.
>
> I think that's the wrong PR number but I couldn't easily find the
> correct one.
Sorry,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803
Tom Tromey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #15 from Tom Tromey ---
*** Bug 61803 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
Dominique d'Humieres changed:
What|Removed |Added
Keywords||ice-on-valid-code
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #16 from Tom Tromey ---
I've tripped across this enough that I've actually filed dups twice now.
I think it would be best to change the ordering here.
That is, the initial error ought to generally be the
location of the outermost exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
--- Comment #12 from Dominique d'Humieres ---
Created attachment 33126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33126&action=edit
Session showing erratic behavior of gfortran
gfortran-fsf-4.5 is 4.5.4,
gfortran-fsf-4.6 is 4.6.4,
gfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #3 from dhowells at redhat dot com ---
Hmmm... It appears you're right. The 'upstream tarball' in the Fedora gcc SRPM
seems already to be altered from what's upstream - even before the spec file
applies any patches to it. I wonder w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #21 from Dominique d'Humieres ---
(In reply to Jerry DeLisle from comment #20)
> Based on this I believe the resolution of this bug is 'INVALID'. ...
I fully agree. If there is no objection before next Wednesday (July 23, 21014),
I'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #4 from Andrew Pinski ---
Also even though it might be a true gcc issue, it does not say it is a hardware
issue, the message says likely. This could also mean a gc or a memory issue
inside gcc. Except detecting that vs a memory issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
--- Comment #2 from David ---
Sent July 9, 2014: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00604.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #5 from dhowells at redhat dot com ---
(In reply to Andrew Pinski from comment #4)
> Also even though it might be a true gcc issue, it does not say it is a
> hardware issue, the message says likely. This could also mean a gc or a
> me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #6 from Jakub Jelinek ---
This is with the original version of the
http://gcc.gnu.org/ml/gcc-patches/2014-07/msg00819.html
As discussed on IRC, the issue is that the RTL includes host address in the
stderr output, which due to stack r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #13 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815
Bug ID: 61815
Summary: precedence of operators is not being followed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
Thomas Koenig changed:
What|Removed |Added
Severity|normal |blocker
--- Comment #5 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815
--- Comment #2 from saisusheelsunkara at hotmail dot com ---
its from left to right order?
(In reply to Andrew Pinski from comment #1)
> The precedence of operators is being followed but what the C standard does
> not say which side of the * is ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815
--- Comment #3 from saisusheelsunkara at hotmail dot com ---
if it is following the precedence then output must have been 216?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61815
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60848
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Tue Jul 15 19:16:29 2014
New Revision: 212574
URL: https://gcc.gnu.org/viewcvs?rev=212574&root=gcc&view=rev
Log:
PR c++/60848
PR c++/61723
* call.c (is_std_init_list): Don't c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Tue Jul 15 19:16:29 2014
New Revision: 212574
URL: https://gcc.gnu.org/viewcvs?rev=212574&root=gcc&view=rev
Log:
PR c++/60848
PR c++/61723
* call.c (is_std_init_list): Don't c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56218
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
--- Comment #6 from Daniel Santos ---
(In reply to Richard Biener from comment #3)
> Note that if such function is called indirectly the compiler may
> or may not inline it dependent on optimization level and a failure
> to inline an indirect cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61807
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
Ed Smith-Rowland <3dw4rd at verizon dot net> changed:
What|Removed |Added
CC||3dw4rd at v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #5 from Paul Pluzhnikov ---
(In reply to Paolo Carlini from comment #1)
> I find this testcase rather weird
It's the result of creduce over a preprocessed original.
> std::initializer_list isn't a random user type
In the non-reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #6 from Manfred Schwarb ---
There is ./configure --disable-isl-version-check,
but I doubt that it will help. The thing is, isl-0.13 needs
cloog-0.18.2 (or rather, cloog-0.18.1 needs isl-0.12.2 and does
not build with isl-0.13), which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #6 from Paul Pluzhnikov ---
It turns out that the original unreduced test case does not error on trunk
@r212277;
it only ICEs on gcc-4.8 and gcc-4.9 branches.
But once I creduced it using 4.9, the reduced test also ICEd on trunk.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
--- Comment #7 from Jason Merrill ---
(In reply to Paul Pluzhnikov from comment #6)
> This appears to be a different ICE.
> Should I reduce it?
Please. And open a new PR for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61811
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Tue Jul 15 21:38:48 2014
New Revision: 212576
URL: https://gcc.gnu.org/viewcvs?rev=212576&root=gcc&view=rev
Log:
PR c++/61811
* decl2.c (maybe_emit_vtables): Return true for -fuse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #23 from Dominique d'Humieres ---
> Jerry, concerning your cited standard:
> "If the file contains an endfile record" suggests that there is some
> special marker in the file to be read/written.
>From the standard:
> NOTE 9.2
> An e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #7 from Dominique d'Humieres ---
For the record, I have done a clean bootstrap of r212523 on
x86_64-apple-darwin13 with cloog-0.18.1 and isl-0.12.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #8 from Manfred Schwarb ---
The graphite-isl-ast-to-gimple.c code reads
#ifdef HAVE_cloog
#include
#include
#include
#include
#if defined(__cplusplus)
extern "C" {
#endif
#include
#if defined(__cplusplus)
}
#endif
#endif
and v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #9 from Dominique d'Humieres ---
> and val_gmp.h only exists in isl-0.13.
I have val_gmp.h for isl-0.12.1 and isl-0.12.2:
[Book15] f90/bug% find /opt/libs -name val_gmp.h
/opt/libs/cloog-0.18.1/isl/include/isl/val_gmp.h
/opt/libs/is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61816
Bug ID: 61816
Summary: Member functions of a template class can access
private classes without permission
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #24 from Jerry DeLisle ---
(In reply to Manfred Schwarb from comment #22)
--- snip ---
> Jerry, concerning your cited standard:
> "If the file contains an endfile record" suggests that there is some
> special marker in the file to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
--- Comment #19 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #15)
> > Its sort of like Steve said earlier. The coder is choosing to ignore an
> > error condition so anything gfortran does is valid. In this case the
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61015
Melissa changed:
What|Removed |Added
CC||myriachan at gmail dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809
--- Comment #4 from Dmitry G. Dyachenko ---
(In reply to Dominique d'Humieres from comment #2)
> Are you sure that r212549 fails? I'ld rather suspect a typo in r212550,
> i.e., DECL_ARGUMENT instead of DECL_ARGUMENT_FLD.
Sorry, err in err.messag
1 - 100 of 106 matches
Mail list logo
