https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61629
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346
Andrew Pinski changed:
What|Removed |Added
CC||myriachan at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61816
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
.
||com
--- Comment #1 from Daniel Krügler ---
The problem also exists in gcc trunk version 4.10.0 20140715 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
--- Comment #4 from Yury Gribov ---
> It should be possible to detect fp layout on the frame basis -
> there is a slot (don't know which one off the top of my head)
> that is FP in one compiler and return address in the other.
> Comparing its con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61809
--- Comment #5 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.
Oh, for r212549 and r212
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
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=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=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=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=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=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 #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=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=59513
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #2
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=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=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=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=50961
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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=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=61807
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
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=56218
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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=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=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=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=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=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
--- 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=61792
Thomas Koenig changed:
What|Removed |Added
Severity|normal |blocker
--- Comment #5 from Thomas Koeni
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=61815
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=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 #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=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 #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=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=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
Dominique d'Humieres changed:
What|Removed |Added
Keywords||ice-on-valid-code
Vers
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=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=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=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 #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=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=61812
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=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=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=61803
Tom Tromey changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Tom Tromey
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=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=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=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=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=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=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=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=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 #3 from Jan Hubicka ---
how those tests fail?
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=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=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=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=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=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=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=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=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=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=25992
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|anton.kirill
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=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=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=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=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=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=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=61801
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, ra
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=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=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=61801
--- Comment #1 from Richard Biener ---
Auto-reduring (matching the bogus assembler pattern).
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=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=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=61802
Richard Biener changed:
What|Removed |Added
Keywords||lto, wrong-code
Priority|P3
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
1 - 100 of 106 matches
Mail list logo
