[Bug fortran/58771] [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58771 --- Comment #6 from Paul Thomas --- Author: pault Date: Sun Nov 17 08:11:33 2013 New Revision: 204913 URL: http://gcc.gnu.org/viewcvs?rev=204913&root=gcc&view=rev Log: 2013-11-17 Paul Thomas PR fortran/58771 * trans-io.c (transfer_expr): If the backend_decl for a derived type is missing, build it with gfc_typenode_for_spec. 2013-11-17 Paul Thomas PR fortran/58771 * gfortran.dg/derived_external_function_1.f90 : New test Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/derived_external_function_1.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/trans-io.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/58771] [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58771 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- Fixed on 4,7,4,8 and 4.9. Thanks for the report. Paul
[Bug c++/59123] [c++11] can't forward-declare an object later defined constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59123 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-17 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Yes.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #27 from Alexey Samsonov --- (In reply to Jakub Jelinek from comment #26) > libbacktrace doesn't use malloc (unless mmap isn't supported), handles > inline frames just fine and Ian has posted today a patch to support also > data symbol lookups. I think I'll post a > sanitizer_symbolizer_posix_libcdep.cc alternative > on Monday that will use libbacktrace, then users can at least choose what > they prefer, say at configure time. Awesome if you want to give it a try :) Note that support for in-process symbolization is already there. You may simply link in the library with functions __sanitizer_symbolize_code and __sanitizer_symbolize_data, and these functions will be picked up by ASan runtime and used instead of forking llvm-symbolizer. See InternalSymbolizer class in sanitizer_symbolizer_posix_libcdep.cc. We use this behavior in our private setup (i.e. we link with hermetic library version of llvm-symbolizer tool, built by a huge and ugly script).
[Bug c/59159] New: Need opaque pass-through as optimization barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
Bug ID: 59159
Summary: Need opaque pass-through as optimization barrier
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
(category:c because I am asking for a built-in, but this is more about
middle/back-end)
Since gcc doesn't support FENV, I often need to insert optimization barriers in
my code that hide things from gcc optimizers, so it doesn't perform constant
propagation, or replace x*-y with -x*y, or move operations across fesetround,
etc. Note that speed is still very important, doing a store/read on a volatile
variable (the most portable optimization barrier) can make the whole
application 15% slower.
One common way to do that is to use an inline asm like:
asm volatile ("", "+g"(x));
(4.9 is the first version where this doesn't ICE all over the place on x86, use
"+m" earlier)
so no code is emitted but the value of x is hidden from the compiler. However,
the "g" constraint doesn't include FP registers. Depending if the code is
compiled for power, sparc, itanium, arm or x86_64, I need to add either "d",
"e", "f", "w", or "x" (yeah, there aren't 2 using the same letter). It looks
like there isn't even a letter for x87 (PR 59157). Using the more general "+X"
is tempting but ICEs (PR 59155).
There is at least one case this inline asm approach can never handle optimally:
constants. We need the variable as asm output or it won't have any effect. But
the constants are in a read-only location that is not suitable for an output
operand, so with "+m" gcc copies the constant to another memory location.
Ideally, there would be a __builtin_opaque built-in that does the right thing
and I wouldn't have to think about it...
[Bug testsuite/59160] New: The test c-c++-common/cilk-plus/PS/reduction-3.c fails on x86_64-apple-darwin1(0|3)*.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160 Bug ID: 59160 Summary: The test c-c++-common/cilk-plus/PS/reduction-3.c fails on x86_64-apple-darwin1(0|3)*. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: aldyh at gcc dot gnu.org, iains at gcc dot gnu.org Host: x86_64-apple-darwin1(0|3)* Target: x86_64-apple-darwin1(0|3)* Build: x86_64-apple-darwin1(0|3)* The test c-c++-common/cilk-plus/PS/reduction-3.c (r204863) fails on x86_64-apple-darwin1(0|3)* with the error: /opt/gcc/_clean/gcc/testsuite/c-c++-common/cilk-plus/PS/reduction-3.c:10:20: fatal error: malloc.h: No such file or directory It succeeds with the following patch --- ../_clean/gcc/testsuite/c-c++-common/cilk-plus/PS/reduction-3.c 2013-11-15 23:09:51.0 +0100 +++ gcc/testsuite/c-c++-common/cilk-plus/PS/reduction-3.c2013-11-17 12:29:18.0 +0100 @@ -7,7 +7,8 @@ #if HAVE_IO #include #endif -#include +/* #include */ +#include int reduction_simd (int *a) Is the line /* FIXME: This test has been xfailed until reductions are fixed. */ still relevant? I don't see any xfail in the source.
[Bug fortran/58471] [4.8/4.9 Regression] ICE on invalid with missing type constructor and -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471
--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Nov 17 12:00:15 2013
New Revision: 204915
URL: http://gcc.gnu.org/viewcvs?rev=204915&root=gcc&view=rev
Log:
2013-11-17 Janus Weil
Backport from mainline
2013-11-07 Janus Weil
PR fortran/58471
* primary.c (gfc_expr_attr): Check for result symbol.
2013-11-17 Janus Weil
Backport from mainline
2013-11-07 Janus Weil
PR fortran/58471
* gfortran.dg/constructor_9.f90: New.
Added:
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/constructor_9.f90
- copied unchanged from r204547,
trunk/gcc/testsuite/gfortran.dg/constructor_9.f90
Modified:
branches/gcc-4_8-branch/ (props changed)
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/primary.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
Propchange: branches/gcc-4_8-branch/
('svn:mergeinfo' modified)
[Bug fortran/58471] [4.8/4.9 Regression] ICE on invalid with missing type constructor and -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from janus at gcc dot gnu.org --- Fixed on trunk and 4.8. Closing. Thanks for the report!
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099 --- Comment #24 from janus at gcc dot gnu.org --- The original regression has been fixed on trunk and 4.8 with r202766 and r204908, respectively. Still to do: Fix the test case of comment 14, cf. also comment 17 - 20 as well as comment 22.
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Richard Biener from comment #8) > -floop-parallelize-all ends up using GRAPHITE dependence analysis which is > what never finishes (is stuck in ISL). I'd say avoid it at all cost (as > the rest of GRAPHITE). If you're saying this is a case of WONTFIX and -floop-parallelize-all should not be used at all, maybe one should document the flag in the manual as 'experimental' (or 'broken' or whatever) ... ?
[Bug libstdc++/59161] New: GDB pretty printers: iterator->reference not printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
Bug ID: 59161
Summary: GDB pretty printers: iterator->reference not printed
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: pmuldoon at redhat dot com
Target: x86_64-unknown-linux-gnu
gdb a.out -ex 'b 11' -ex r -ex 'p it'
(gdb) p it
$3 = {ref = }
= bug
(gdb) p *it
$2 = (C &) @0x603010: {ref = @0x7fffd928}
(gdb) whatis it
type = __gnu_cxx::__normal_iterator > >
#include
class C {
public:
int &ref;
C(int &ref_):ref(ref_) {}
};
int main() {
int d(1);
std::vector vec({d});
for (auto it=vec.begin();it!=vec.end();++it) {
++it->ref; // line 11
__attribute__((unused)) C *gdb_stub(&*it);
}
}
[Bug libstdc++/59161] GDB pretty printers: iterator->reference not printed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #1 from Jan Kratochvil --- Tested with: GNU gdb (GDB) 7.6.50.20131109-cvs libstdcxx/v6/printers.py from GCC r201888 (=with PR libstdc++/53477 fix)
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-11-17
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres ---
Backtrace
Program received signal SIGSEGV, Segmentation fault.
0x00010003da12 in gfc_search_interface (intr=0x141d08f00, sub_flag=0,
ap=0x141d1e0a0) at ../../work/gcc/fortran/interface.c:3407
3407if (a->expr && a->expr->expr_type == EXPR_NULL
(gdb) bt
#0 0x00010003da12 in gfc_search_interface (intr=0x141d08f00, sub_flag=0,
ap=0x141d1e0a0) at ../../work/gcc/fortran/interface.c:3407
#1 0x000100085611 in gfc_resolve_expr (e=0x141d08f00) at
../../work/gcc/fortran/resolve.c:2477
#2 0x00010008a2f0 in resolve_code (code=, ns=) at ../../work/gcc/fortran/resolve.c:9772
#3 0x00010008cac4 in resolve_codes (ns=0x141d08f00) at
../../work/gcc/fortran/resolve.c:14624
#4 0x00010008c9c8 in resolve_codes (ns=0x141d08f00) at
../../work/gcc/fortran/resolve.c:14610
#5 0x00010008cbbd in gfc_resolve (ns=) at
../../work/gcc/fortran/resolve.c:14652
#6 0x0001000786e1 in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4672
#7 0x0001000b9d96 in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:188
#8 0x00010082f774 in compile_file () at ../../work/gcc/toplev.c:545
#9 0x00010083190a in toplev_main (argc=1, argv=0x7fff5fbff550) at
../../work/gcc/toplev.c:1891
(gdb) p *intr
$1 = {sym = 0x141d1d210, where = {nextc = 0x141d0d3c0, lb = 0x141d0d380}, next
= 0x0warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
}
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099
--- Comment #25 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #22)
> (In reply to janus from comment #19)
> > (In reply to janus from comment #18)
> > That version still yields a good number of testsuite failures, but it seems
> > like most of them are due to invalid code that was not detected previously:
>
> Well, sizeof_proc.f90 looks like a bug in the checking code:
>
> procedure(real), pointer :: pp
> pp => sin
> ! Error: Explicit interface required for '' at (1): elemental procedure
There might be a bug here, but I don't quite follow your argument (see below).
> The quote in comment 2 has: "If proc-pointer-object has an explicit
> interface…" which is not fulfilled as "pp" has an implicit interface.
Agreed. The quote continues "... its characteristics shall be the same as
proc-target except ...". The error is not about the characteristics being
different, but about the target being elemental at all. Everything is fine so
far.
> There is in addition the following constraint, but sin is an intrinsic:
> "C730 (R740) The proc-target shall not be a nonintrinsic elemental
> procedure."
Yes. As you say, this is not applicable here (and is again not what the error
is about). Still everything fine.
The relevant quote for the above error message is F08:12.4.2.2, which says:
" A procedure other than a statement function shall have an explicit interface
if it is referenced and ... (4) the procedure is elemental, or ..."
In our case it applies to the proc-pointer 'pp', which itself is not elemental,
but (validly) points to the elemental intrinsic 'sin'.
Therefore I would say the logic in gfc_check_pointer_assign is wrong after all:
if (s1->attr.if_source == IFSRC_UNKNOWN
&& gfc_explicit_interface_required (s2, err, sizeof(err)))
{
gfc_error ("Explicit interface required for '%s' at %L: %s",
name1, &lvalue->where, err);
I guess we should not require an explicit interface for the pointer, if the
target is elemental. Right?
[Bug fortran/59146] Segfault when ommiting '&' in 'bind (C) ' procedure call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59146 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Likely fixed by one of the revisions 199118 to 199120. I don't think there is any plan to backport the fix to 4.8.
[Bug fortran/59107] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-17 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed with 4.7, 4.8 and trunk. Apparently the symbol gets a ts.type of BT_INTEGER somewhere (indepedent of the type of 'nargs'). It also happens for the following variant: implicit none Intrinsic :: command_argument_count print *, command_argument_count() End Doing the same thing with a different intrinsic like 'cos' does not give the warning: Intrinsic :: cos print *, cos(0.) End
[Bug fortran/59146] Segfault when ommiting '&' in 'bind (C) ' procedure call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59146 --- Comment #3 from Jean-Charles Papin --- Ok, thanks a lot for these information :) I've just try gcc-4.9 and, as you mentioned, this has been fixed.
[Bug fortran/59107] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) > Doing the same thing with a different intrinsic like 'cos' does not give the > warning: > > Intrinsic :: cos > print *, cos(0.) > End However, it *does* so with GETGID, for example: intrinsic :: getgid print *, getgid() end GETGID is a GNU extension, in contrast to COMMAND_ARGUMENT_COUNT (which is standard F03), but both are integer-valued functions without arguments. The warning only appears with the INTRINSIC statement.
[Bug c/59159] Need opaque pass-through as optimization barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159 --- Comment #1 from joseph at codesourcery dot com --- On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote: > propagation, or replace x*-y with -x*y, or move operations across fesetround, Do you mean -(x*y)? I don't see the problem with replacing x*-y with -x*y (which is (-x)*y), in any rounding mode.
[Bug fortran/59107] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 --- Comment #3 from janus at gcc dot gnu.org --- The warning also occurs with 4.5 and 4.6. Further, it not only occurs for integer functions, but also for character-valued ones, like FDATE (which, like the previous two, has no arguments).
[Bug fortran/59107] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 --- Comment #4 from janus at gcc dot gnu.org --- In fact the warning seems to happen for all intrinsics which are introduced by 'add_sym_0' in intrinsic.c (all those are functions without arguments), except those from ISO_FORTRAN_ENV, since they are imported by a USE statement instead of INTRINSIC. For the intrinsics with arguments it does not seem to happen.
[Bug fortran/59107] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) > For the intrinsics with arguments it does not seem to happen. This is simply due to the fact that 'gfc_resolve_intrinsic' apparently is called more than once (potentially for all intrinsics?). However, for the ones with arguments, the check for 'sym->formal' exits the function early on the second call. For the ones without arguments this does not happen. They receive a type on the first call, which then triggers the warning on the second call. To fix this bug, we just have to make sure that 'gfc_resolve_intrinsic' is not called more than once!
[Bug fortran/59107] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 --- Comment #6 from janus at gcc dot gnu.org --- The warning does not occur with 4.4, i.e. it is a regression in 4.5 and upward.
[Bug c/59159] Need opaque pass-through as optimization barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159 --- Comment #2 from Marc Glisse --- (In reply to jos...@codesourcery.com from comment #1) > On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote: > > > propagation, or replace x*-y with -x*y, or move operations across > > fesetround, > > Do you mean -(x*y)? I don't see the problem with replacing x*-y with > -x*y (which is (-x)*y), in any rounding mode. Yes, sorry, I meant -(x*y).
[Bug fortran/59107] [4.7/4.8/4.9 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Spurious "Type specified|[4.7/4.8/4.9 Regression] |for intrinsic function |Spurious "Type specified |'command_argument_count' at |for intrinsic function |(1) is ignored" under |'command_argument_count' at |-Wsurprising. |(1) is ignored" under ||-Wsurprising. --- Comment #7 from janus at gcc dot gnu.org --- I suspect the culrprit here is myself. The regression is proabably due to this revision: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=150716
[Bug libffi/34311] libffi.call/nested_struct5.c execution tests fail under darwin9 on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34311
--- Comment #4 from Iain Sandoe ---
(In reply to Anthony Green from comment #3)
> (In reply to Iain Sandoe from comment #2)
> > However, there is no guarantee in the Darwin m32 ABI that the stacked
> > version of the structs will be appropriately aligned. So, either the
> > testcase is wrong code - or the process for passing structures in the
> > closure needs to be refined (significant re-write, since the structs are
> > currently passed in-place).
>
> Iain - could you please explain this a little more? Which are the stacked
> structs that aren't aligned, and where do they come from?
I hope I've reloaded/remembered state correctly, this was debugging done a
while ago while I was doing the m64 port, and everything was fresh in my head
;)
==
Darwin uses IBM-style long doubles (two double concatenated)
The psABI alignment of a long double is 16bytes.
The psABI alignment of a structure with a long double as the first element is
also 16bytes.
However, in this code, for example:
typedef struct A {
long double a;
unsigned char b;
} A;
extern struct A foo (struct A y);
struct A bar (void)
{
struct A a = {1.5,'a'};
return foo(a);
}
in the call to foo()
r3 = pointer to struct return
r4 .. r10 are used to pass a.
In a standard stack frame, the offset of r4 is not necessarily aligned to even
8bytes, much less 16.
But, when we build the closure - since, we don't have any other memory to play
with - we point at the saved registers containing the structure (now,
effectively/potentially, unaligned).
If the values are picked up by a floating load or memcopied to a suitable
place, the worst that happens is we suffer a performance hit for the unaligned
access.
But .. in this specific case [nested_struct5.c] codegen decides to optimize the
structure move using vector insns (which is normally OK, since the structure is
supposed to be 16byte aligned):
static void
B_gn(ffi_cif* cif __UNUSED__, void* resp, void** args,
void* userdata __UNUSED__)
{
struct A b0;
struct B b1;
b0 = *(struct A*)(args[0]); << line 44.
b1 = *(struct B*)(args[1]);
*(B*)resp = B_fn(b0, b1);
}
;
/src/host-libs/libffi-3.0.13/testsuite/libffi.call/nested_struct5.c:44
LM8:
lwz r2,0(r5); *args_2(D), *args_2(D)
lvx v1,0,r2 ; MEM[(struct A *)_3], MEM[(struct A *)_3]
li r9,16; tmp128,
lvx v0,r2,r9; MEM[(struct A *)_3], MEM[(struct A *)_3]
li r2,128 ; tmp146,
stvx v1,r1,r2 ; MEM[(struct A *)_3], b0
li r2,144 ; tmp147,
stvx v0,r1,r2 ; MEM[(struct A *)_3], b0
;
/src/host-libs/libffi-3.0.13/testsuite/libffi.call/nested_struct5.c:45
and we're then hosed, since those insns just silently ignore the lsbits of the
address.
The code works fine if we memcopy the structs from their source (i.e. the
libffi process is getting the correct stuff in the place expected) - it's just
incorrectly aligned.
The psABI will, presumably, never change (since the platform is EOL).
Perhaps codegen should not make the assumption that *(struct A*) of a void * is
correctly aligned, not sure if that's a c-standard question or ...
Perhaps there's a way of getting at some scratch memory when building the FFI
structures, but ISTR this was not going to be easy.
there are higher darwin priorities than fixing this issue - however, if I've
missed some obvious workaround (quite plausible), it would be nice to have it
working and would welcome suggestions.
thanks for looking into this, Iain.
[Bug fortran/59107] [4.7/4.8/4.9 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #8 from janus at gcc dot gnu.org --- The following patch fixes it (and regtests cleanly): Index: gcc/fortran/gfortran.h === --- gcc/fortran/gfortran.h(revision 204922) +++ gcc/fortran/gfortran.h(working copy) @@ -1250,7 +1250,7 @@ typedef struct gfc_symbol /* Set if this variable is used as an index name in a FORALL. */ unsigned forall_index:1; /* Used to avoid multiple resolutions of a single symbol. */ - unsigned resolved:1; + unsigned resolved:2; int refs; struct gfc_namespace *ns;/* namespace containing this symbol */ Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 204922) +++ gcc/fortran/resolve.c(working copy) @@ -1619,8 +1619,9 @@ gfc_resolve_intrinsic (gfc_symbol *sym, locus *loc gfc_intrinsic_sym* isym = NULL; const char* symstd; - if (sym->formal) + if (sym->resolved>=2) return true; + sym->resolved = 2; /* Already resolved. */ if (sym->from_intmod && sym->ts.type != BT_UNKNOWN) @@ -12699,7 +12700,7 @@ resolve_symbol (gfc_symbol *sym) gfc_array_spec *as; bool saved_specification_expr; - if (sym->resolved) + if (sym->resolved>=1) return; sym->resolved = 1;
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-17 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I can not reproduce the ICE, but I see the corrupted error message and several valgrind errors. Reduced test case: MODULE atomic_kind_types PUBLIC :: atomic_kind_type CONTAINS INTEGER FUNCTION is_hydrogen(atomic_kind) TYPE(atomic_kind_type), pointer :: atomic_kind END FUNCTION END MODULE
[Bug c/59129] assert fail for tree.c:4150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59129 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Binderman --- (In reply to Richard Biener from comment #1) > I think this is a already fixed. Agreed. I tried 20131117 and it seems fixed to me.
[Bug c++/59123] [c++11] can't forward-declare an object later defined constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59123 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Nov 17 19:22:43 2013 New Revision: 204923 URL: http://gcc.gnu.org/viewcvs?rev=204923&root=gcc&view=rev Log: /cp 2013-11-17 Paolo Carlini PR c++/59123 * decl.c (validate_constexpr_redeclaration): Redeclarations of variables can differ in constexpr. /testsuite 2013-11-17 Paolo Carlini PR c++/59123 * g++.dg/cpp0x/constexpr-redeclaration1.C: New. * g++.dg/cpp0x/constexpr-decl.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-redeclaration1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-decl.C
[Bug c++/59123] [c++11] can't forward-declare an object later defined constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59123 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #3 from Paolo Carlini --- Fixed for 4.9.0.
[Bug tree-optimization/59162] New: wrong code (hangs) at -Os and above on x86_64-linux-gnu (affecting 4.7.3 and earlier versions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59162
Bug ID: 59162
Summary: wrong code (hangs) at -Os and above on
x86_64-linux-gnu (affecting 4.7.3 and earlier
versions)
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
GCC 4.7.3 and earlier versions miscompile the following code on x86_64-linux at
-Os and above in both 32-bit and 64-bit modes. But I did not check the latest
4.7 branch.
It affects neither the current trunk nor 4.8.x.
$ gcc-4.7.3 -O1 small.c; a.out
1
$ gcc-4.7.3 -Os small.c; a.out
^C
$ gcc-4.6.4 -Os small.c; a.out
^C
$ gcc-4.8.2 -Os small.c; a.out
1
$ gcc-trunk -Os small.c; a.out
1
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131117 (experimental) [trunk revision 204920] (GCC)
$
-
int printf (const char *, ...);
int a, *b = &a;
int
main ()
{
short c = 0;
lbl:
++c;
*b |= 1;
if (c)
goto lbl;
printf ("%d\n", a);
return 0;
}
[Bug tree-optimization/59162] wrong code (hangs) at -Os and above on x86_64-linux-gnu (affecting 4.7.3 and earlier versions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59162 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 35634. *** This bug has been marked as a duplicate of bug 35634 ***
[Bug c/35634] [4.7 Regression] operand of pre-/postin-/decrement not promoted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634 Andrew Pinski changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #40 from Andrew Pinski --- *** Bug 59162 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/59162] wrong code (hangs) at -Os and above on x86_64-linux-gnu (affecting 4.7.3 and earlier versions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59162 --- Comment #2 from Zhendong Su --- (In reply to Andrew Pinski from comment #1) > Dup of bug 35634. > > *** This bug has been marked as a duplicate of bug 35634 *** Sorry for the dup; didn't know about this earlier report.
[Bug c++/59163] New: program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163
Bug ID: 59163
Summary: program compiled with g++ -O3 segfaults
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: donnyjward at gmail dot com
Created attachment 31232
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31232&action=edit
Stripped preprocessed C++ source.
The attached test case crashes (segmentation fault) when run. It is a
preprocessed file where I stripped just about everything from
except std::for_each.
gcc -v:
~/src $ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/app/gcc/4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./gcc-4.8.2/configure --prefix=/app/gcc/4.8.2
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.8.2 (GCC)
~/src $
The complete command line that triggers the bug:
g++ -O3 -std=c++11 -Wall -Wextra bug2.ii
...then run the output program to see the segmentation fault
I tried building with:
g++ -O3 -std=c++11 -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -Wall -Wextra bug2.ii
...and the same crash occurs.
The compiler outputs no messages (no warnings errors etc).
The program runs without crashing if compiled with -O0, -O1, -O2, or -Os.
I compiled with the latest version of clang++ bundled with Mac's XCode, trying
each optimization level and the program runs fine. Same with the latest version
of MSVC (Visual Studio 2013).
The gdb segfault and backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x004007a7 in Quaternion::slerp(Quaternion const&, Quaternion const&)
() at bug2.ii:82
82{
(gdb) bt
#0 0x004007a7 in Quaternion::slerp(Quaternion const&, Quaternion
const&) () at bug2.ii:82
#1 0x00400475 in main () at bug2.ii:97
(gdb)
Extra observations:
If I comment out "int parent" in the struct definition so that the struct
becomes
struct Joint
{
//int parent;
Quaternion orient;
};
the program no longer segfaults when compiled/run.
[Bug target/59153] ICE: in memory_address_length, at config/i386/i386.c:24617 with -O -flive-range-shrinkage -mdispatch-scheduler -march=bdver1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59153 --- Comment #1 from uros at gcc dot gnu.org --- Author: uros Date: Sun Nov 17 23:10:10 2013 New Revision: 204925 URL: http://gcc.gnu.org/viewcvs?rev=204925&root=gcc&view=rev Log: PR target/59153 * config/i386/i386.c (ix86_address_subreg_operand): Do not reject non-integer subregs. (ix86_decompose_address): Do not reject invalid CONST_INT RTXes. Move check for invalid x32 constant addresses ... (ix86_legitimate_address_p): ... here. testsuite/ChangeLog: PR target/59153 * gcc.target/i386/pr59153.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr59153.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/59153] ICE: in memory_address_length, at config/i386/i386.c:24617 with -O -flive-range-shrinkage -mdispatch-scheduler -march=bdver1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59153 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-11/msg01977.htm ||l Last reconfirmed||2013-11-17 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #2 from Uroš Bizjak --- Fixed in mainline sofar.
[Bug c/59164] New: ice: tree check: expected tree that contains ‘decl minimal’ structure, have ‘integer_cst’ in get_var_info, at tree-into-ssa.c:380
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59164
Bug ID: 59164
Summary: ice: tree check: expected tree that contains ‘decl
minimal’ structure, have ‘integer_cst’ in
get_var_info, at tree-into-ssa.c:380
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: regehr at cs dot utah.edu
CC: chenyang at cs dot utah.edu
regehr@regehr-M51AC:~/z/reduce/r104$ gcc -O3 small.c -c
small.c: In function ‘fn2’:
small.c:9:6: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘integer_cst’ in get_var_info, at
tree-into-ssa.c:380
void fn2(void) {
^
0xbec8e4 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/regehr/z/compiler-source/gcc/gcc/tree.c:9340
0x54ddf7 contains_struct_check
/home/regehr/z/compiler-source/gcc/gcc/tree.h:2820
0x54ddf7 get_var_info
/home/regehr/z/compiler-source/gcc/gcc/tree-into-ssa.c:380
0xa4761e get_var_info
/home/regehr/z/compiler-source/gcc/gcc/hash-table.h:825
0xa4761e get_common_info
/home/regehr/z/compiler-source/gcc/gcc/tree-into-ssa.c:413
0xa4761e get_current_def(tree_node*)
/home/regehr/z/compiler-source/gcc/gcc/tree-into-ssa.c:422
0xbbea64 slpeel_update_phi_nodes_for_guard1
/home/regehr/z/compiler-source/gcc/gcc/tree-vect-loop-manip.c:474
0xbbea64 slpeel_tree_peel_loop_to_edge
/home/regehr/z/compiler-source/gcc/gcc/tree-vect-loop-manip.c:1307
0xbc09ed vect_do_peeling_for_loop_bound(_loop_vec_info*, tree_node**, unsigned
int, bool)
/home/regehr/z/compiler-source/gcc/gcc/tree-vect-loop-manip.c:1798
0xbb0437 vect_transform_loop(_loop_vec_info*)
/home/regehr/z/compiler-source/gcc/gcc/tree-vect-loop.c:5662
0xbcd2cf vectorize_loops()
/home/regehr/z/compiler-source/gcc/gcc/tree-vectorizer.c:375
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
regehr@regehr-M51AC:~/z/reduce/r104$ cat small.c
int a, d, e;
long b[10];
int c[10][8];
int fn1(p1) {
return 1 >> p1;
}
void fn2(void) {
int f;
for (a=1; a <= 4; a++) {
f = fn1(0 < c[a][0]);
if (f || d)
e = b[a] = 1;
}
}
regehr@regehr-M51AC:~/z/reduce/r104$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r204924-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r204924-install
--enable-languages=c,c++ --enable-multilib
Thread model: posix
gcc version 4.9.0 20131117 (experimental) (GCC)
[Bug c++/58907] [c++11] ICE in gimplify_var_or_parm_decl, at gimplify.c:NNNN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58907 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-18 Ever confirmed|0 |1
[Bug c++/59165] New: gcc looks up begin(), end() for for-range loops for ints in namespace std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
Bug ID: 59165
Summary: gcc looks up begin(), end() for for-range loops for
ints in namespace std
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thakis at chromium dot org
This compiles, but shouldn't:
$ cat gcc4.8bug.cc
// builds with gcc4.8, but shouldn't
namespace std {
int* begin(int i) { return (int*)0; }
int* end(int i) { return (int*)0; }
}
int main() {
for (int a : 10) { }
}
$ gcc-4.8.1 -c gcc4.8bug.cc -std=c++11
# works
The standard says that begin() and end() for foreach loops should be looked up
in the associated namespace of the type of the expression (6.5.4p1)
"""otherwise, begin-expr and end-expr are begin(__range) and end(__range),
respectively, where begin and end are looked up in the associated namespaces
(3.4.2). [ Note: Ordinary unqualified lookup (3.4.1) is not performed. — end
note ]"""
10 has type int, which is a fundamental type, and hence doesn't have an
associated namespace. So this shouldn't compile. (It doesn't compile in clang.)
$ gcc-4.8.1 --version
gcc-4.8.1 (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #6 from Dongsheng Song --- After revert r192062, I can build gcc smoothly. $ svn log -r 192062 r192062 | uros | 2012-10-04 13:53:22 +0800 (Thu, 04 Oct 2012) | 4 lines * configure.ac (noexception_flags): Add -fasynchronous-unwind-tables. * configure: Regenerate. 2012-10-04 Uros Bizjak * configure.ac (noexception_flags): Add -fasynchronous-unwind-tables. * configure: Regenerate.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #14 from Yury Gribov --- Sent to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01990.html As for libubsan, it does not seem to support static link anyway: /home/ygribov/install/gcc-master/bin/gcc -g repro.i -fsanitize=undefined -static-libubsan ... /sanitizer_linux_libcdep.cc:71: undefined reference to `pthread_getattr_np' /sanitizer_linux_libcdep.cc:74: undefined reference to `pthread_attr_getstack' /sanitizer_linux_libcdep.cc:85: undefined reference to `dlsym' ... Once it does, we can go with the same per-file flags hack that we do e.g. in libstdc++-v3/src/Makefile.am.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #15 from Kostya Serebryany --- (In reply to Yury Gribov from comment #14) > Sent to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01990.html > > As for libubsan, it does not seem to support static link anyway: you need -ldl -lpthread (asan has it already) > > /home/ygribov/install/gcc-master/bin/gcc -g repro.i -fsanitize=undefined > -static-libubsan > ... > /sanitizer_linux_libcdep.cc:71: undefined reference to `pthread_getattr_np' > /sanitizer_linux_libcdep.cc:74: undefined reference to > `pthread_attr_getstack' > /sanitizer_linux_libcdep.cc:85: undefined reference to `dlsym' > ... > > Once it does, we can go with the same per-file flags hack that we do e.g. in > libstdc++-v3/src/Makefile.am.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #16 from Jakub Jelinek --- See my http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01874.html, that should fix that -ldl -lpthread already.
[Bug rtl-optimization/59166] New: ICE in simplify_subreg, at simplify-rtx.c:5901 on valid code (at -O1 and above with -g enabled)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59166
Bug ID: 59166
Summary: ICE in simplify_subreg, at simplify-rtx.c:5901 on
valid code (at -O1 and above with -g enabled)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above with -g enabled (except -Os in 64-bit mode) on x86_64-linux-gnu.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131117 (experimental) [trunk revision 204923] (GCC)
$
$ gcc-trunk -O0 -g small.c; a.out
$ gcc-trunk -O1 small.c; a.out
$ gcc-4.8.2 -O1 -g small.c; a.out
$
$ gcc-trunk -O1 -g small.c
small.c: In function ‘fn1’:
small.c:26:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5901
}
^
0x98caf6 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
../../gcc-trunk/gcc/simplify-rtx.c:5900
0x98cc1d simplify_gen_subreg
../../gcc-trunk/gcc/simplify-rtx.c:6121
0xbf2fba vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8328
0x6a5575 cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1649
0x6a698e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1531
0xbf0837 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8223
0xbf32fa vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8385
0x6a565b cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1684
0x6a698e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def*
(*)(rtx_def*, bitmap_head_def*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1531
0xbf0837 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8223
0xbf152f vt_expand_1pvar
../../gcc-trunk/gcc/var-tracking.c:8498
0xbf152f emit_note_insn_var_location(variable_def**, emit_note_data_def*)
../../gcc-trunk/gcc/var-tracking.c:8552
0xbfc35e traverse_noresize
../../gcc-trunk/gcc/hash-table.h:928
0xbfc35e traverse
../../gcc-trunk/gcc/hash-table.h:950
0xbfc35e emit_notes_for_changes
../../gcc-trunk/gcc/var-tracking.c:8914
0xbfd09e emit_notes_in_bb
../../gcc-trunk/gcc/var-tracking.c:9345
0xbfd09e vt_emit_notes
../../gcc-trunk/gcc/var-tracking.c:9408
0xbfda4f variable_tracking_main_1
../../gcc-trunk/gcc/var-tracking.c:10206
0xbfda4f variable_tracking_main()
../../gcc-trunk/gcc/var-tracking.c:10220
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
int a, b, c, f, g;
void
fn2 ()
{
for (; b; b++)
for (; f; f = g)
for (; a;)
;
}
static int
fn1 (int p)
{
short d;
if (c)
{
for (; f; f = g);
fn2 ();
d = p;
char e = d;
if (p)
return 1;
}
return p;
}
int
main ()
{
fn1 (0);
fn1 (g);
return 0;
}
[Bug bootstrap/55915] fails to build lto-compress.c, zlib.h not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55915 Yves Caniou changed: What|Removed |Added CC||yves.can...@ens-lyon.fr --- Comment #3 from Yves Caniou --- I have the same problem when compiling gcc-4.8.2 with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) on Xeon(R) CPU W3670 @ 3.20GHz Note that with the exact same process, I have been able to compile gcc-4.8.2 with gcc 4.7.2 (debian). I use gmp-5.1.3, mpfr-3.1.2, mpc-1.0.1. They are not intree. Once compiled, their respective prefix/lib are added to LD_LIBRARY_PATH. Gcc source is copied local disk, so no NFS or such. I call: /tmp/YC/gcc/src-4.8.2/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/home/ycaniou/bin/amd64/4.6.3/gcc --disable-altivec --disable-fixed-point --without-cloog --without-ppl --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-gmp=/home/ycaniou/bin/amd64/4.6.3/gmp --with-mpfr=/home/ycaniou/bin/amd64/4.6.3/mpfr --with-mpc=/home/ycaniou/bin/amd64/4.6.3/mpc Calling "make -j 12" ends with: [...] x86_64-linux-gnu-g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/tmp/YC/gcc/src-4.8.2/gcc -I/tmp/YC/gcc/src-4.8.2/gcc/. -I/tmp/YC/gcc/src-4.8.2/gcc/../include -I/tmp/YC/gcc/src-4.8.2/gcc/../libcpp/include -I/home/ycaniou/bin/amd64/4.6.3/gmp/include -I/home/ycaniou/bin/amd64/4.6.3/mpfr/include -I/home/ycaniou/bin/amd64/4.6.3/mpc/include -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libbacktrace /tmp/YC/gcc/src-4.8.2/gcc/lto-compress.c -o lto-compress.o /tmp/YC/gcc/src-4.8.2/gcc/lto-compress.c:28:18: fatal error: zlib.h: No such file or directory compilation terminated. x86_64-linux-gnu-g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/tmp/YC/gcc/src-4.8.2/gcc -I/tmp/YC/gcc/src-4.8.2/gcc/. -I/tmp/YC/gcc/src-4.8.2/gcc/../include -I/tmp/YC/gcc/src-4.8.2/gcc/../libcpp/include -I/home/ycaniou/bin/amd64/4.6.3/gmp/include -I/home/ycaniou/bin/amd64/4.6.3/mpfr/include -I/home/ycaniou/bin/amd64/4.6.3/mpc/include -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libbacktrace/tmp/YC/gcc/src-4.8.2/gcc/mcf.c -o mcf.o x86_64-linux-gnu-g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/tmp/YC/gcc/src-4.8.2/gcc -I/tmp/YC/gcc/src-4.8.2/gcc/. -I/tmp/YC/gcc/src-4.8.2/gcc/../include -I/tmp/YC/gcc/src-4.8.2/gcc/../libcpp/include -I/home/ycaniou/bin/amd64/4.6.3/gmp/include -I/home/ycaniou/bin/amd64/4.6.3/mpfr/include -I/home/ycaniou/bin/amd64/4.6.3/mpc/include -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/YC/gcc/src-4.8.2/gcc/../libbacktrace /tmp/YC/gcc/src-4.8.2/gcc/mode-switching.c -o mode-switching.o make[3]: *** [lto-compress.o] Error 1
