[Bug testsuite/40565] [4.5 Regression] Extra failures

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-06-27 09:49 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40565

[Bug c++/40566] New: rejects promoted throw

[rguenth at gcc dot gnu dot org]

void f(int x) { char c = x ? 23 : throw "bla"; }

error: aggregate value used where an integer was expected


because we call convert_to_integer on the throw_expression.


-- 
   Summary: rejects promoted throw
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40566

[Bug c++/40566] [4.3/4.4/4.5 Regression] rejects promoted throw

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||3.3.6 4.0.0 4.4.1 4.5.0
  Known to work||2.95.3
Summary|rejects promoted throw  |[4.3/4.4/4.5 Regression]
   ||rejects promoted throw
   Target Milestone|--- |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40566

[Bug testsuite/40567] New: [4.5 regression] Revision 149002 caused many failures

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 149002:

http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00987.html

caused:

FAIL: gcc.dg/vect/O3-pr36098.c (test for excess errors)
FAIL: gcc.dg/vect/O3-pr39675-2.c (test for excess errors)
FAIL: gcc.dg/vect/O3-pr39675-2.c scan-tree-dump-times vect "vectorized 1 loops"
1: dump file does not exist
FAIL: gcc.dg/vect/O3-pr39675-2.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1: dump file does not exist
FAIL: gcc.dg/vect/O3-vect-pr32243.c (test for excess errors)
FAIL: gcc.dg/vect/O3-vect-pr34223.c (test for excess errors)
FAIL: gcc.dg/vect/O3-vect-pr34223.c scan-tree-dump-times vect "vectorized 1
loops" 1: dump file does not exist


-- 
   Summary: [4.5 regression] Revision 149002 caused many failures
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40567

[Bug testsuite/40567] [4.5 regression] Revision 149002 caused many failures

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40567

[Bug testsuite/40567] [4.5 regression] Revision 149002 caused many failures

[bonzini at gcc dot gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-06-27 14:40 ---
Subject: Bug 40567

Author: bonzini
Date: Sat Jun 27 14:40:29 2009
New Revision: 149006

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149006
Log:
2009-06-27  Paolo Bonzini  

PR testsuite/40567
* gcc.dg/vect/vect.exp: Fix lappend syntax.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect.exp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40567

[Bug tree-optimization/26854] [4.3/4.4/4.5 Regression] Inordinate compile times on large routines

[bonzini at gcc dot gnu dot org]

--- Comment #109 from bonzini at gnu dot org  2009-06-27 14:48 ---
Subject: Bug 26854

Author: bonzini
Date: Sat Jun 27 14:48:34 2009
New Revision: 149010

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149010
Log:
2009-06-07  Paolo Bonzini  

PR rtl-optimization/26854
* timevar.def: Remove TV_DF_RU, add TV_DF_MD.
* df-problems.c (df_rd_add_problem): Fix comment.
(df_md_set_bb_info, df_md_free_bb_info, df_md_alloc,
df_md_simulate_artificial_defs_at_top,
df_md_simulate_one_insn, df_md_bb_local_compute_process_def,
df_md_bb_local_compute, df_md_local_compute, df_md_reset,
df_md_transfer_function, df_md_init, df_md_confluence_0,
df_md_confluence_n, df_md_free, df_md_top_dump, df_md_bottom_dump,
problem_MD, df_md_add_problem): New.
* df.h (DF_MD, DF_MD_BB_INFO, struct df_md_bb_info, df_md,
df_md_get_bb_info): New.
DF_LAST_PROBLEM_PLUS1): Adjust.

* Makefile.in (fwprop.o): Include domwalk.h.
* fwprop.c: Include domwalk.h.
(reg_defs, reg_defs_stack): New.
(bitmap_only_bit_between): Remove.
(process_defs): New.
(process_uses): Use reg_defs and local_md instead of
bitmap_only_bit_between and local_rd.
(single_def_use_enter_block): New, from build_single_def_use_links.
(single_def_use_leave_block): New.
(build_single_def_use_links): Remove code moved to
single_def_use_enter_block, invoke domwalk.
(use_killed_between): Adjust comment.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/df-problems.c
trunk/gcc/df.h
trunk/gcc/fwprop.c
trunk/gcc/timevar.def


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854

[Bug middle-end/40550] Segmentation fault caused by alignment error in sse code

[CaptainSifff at gmx dot de]

--- Comment #8 from CaptainSifff at gmx dot de  2009-06-27 15:44 ---
This also happens in gcc-4.2.1 on i686.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550

[Bug fortran/40568] New: F2008: C_SIZEOF is in the wrong scope

[burnus at gcc dot gnu dot org]

C_SIZEOF should be a function in ISO_C_BINDING, however, in gfortran it is a
normal intrinsic.

Expected:
- The USE statement works
- Using C_SIZEOF should give an error

use iso_c_binding, only: so => c_sizeof
implicit none
print *, c_sizeof(1)
end


-- 
   Summary: F2008: C_SIZEOF is in the wrong scope
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568

[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.

[ktietz at gcc dot gnu dot org]

--- Comment #4 from ktietz at gcc dot gnu dot org  2009-06-27 16:05 ---
I noticed for version 4.4 (x86_64-*-mingw* and i686-*-mingw*) this issue still
exist. On 4.5 branch it is fixed. I would like that it the patch is getting
applied on the 4.4.1 branch, too. It fixed a crash in emutls_destroy, we get
for 4.4 branch.

Any chance?

Kai


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024

[Bug fortran/40569] New: F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()

[burnus at gcc dot gnu dot org]

Fortran 2008 adds the two inquiry subroutines, which return a string.

In GCC the version string is in "version.h":
  extern const char version_string[];

The options string has to constructed manually; the question is whether one
wants to skip certain options. Optimally, one would record exactly those
options passed to "gfortran" and not all those options passed to "f951". The
middle end has -frecord-gcc-switches and -fverbose-asm; cf. toplev.c's
print_switch_values.


-- 
   Summary: F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569

[Bug target/40489] gcc.dg/builtin-unreachable-3.c doesn't work on ia64

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2009-06-27 16:43 ---
Subject: Bug 40489

Author: hjl
Date: Sat Jun 27 16:43:28 2009
New Revision: 149014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149014
Log:
2009-06-27  H.J. Lu  

PR target/40489
* config/ia64/ia64.c (ia64_reorg): Check NULL insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40489

[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.

[ktietz at gcc dot gnu dot org]

--- Comment #5 from ktietz at gcc dot gnu dot org  2009-06-27 17:50 ---
Subject: Bug 40024

Author: ktietz
Date: Sat Jun 27 17:50:20 2009
New Revision: 149015

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149015
Log:
2009-06-27  Kai Tietz  

Merged from trunk rev/148061
2009-06-01  Jakub Jelinek  
PR other/40024
* emutls.c (__emutls_get_address): Change arr->size to mean number
of allocated arr->data entries instead of # of slots + 1.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/emutls.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024

[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.

[ktietz at gcc dot gnu dot org]

--- Comment #6 from ktietz at gcc dot gnu dot org  2009-06-27 17:52 ---
Subject: Bug 40024

Author: ktietz
Date: Sat Jun 27 17:52:29 2009
New Revision: 149016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149016
Log:
2009-06-27  Kai Tietz  

Merged from trunk rev/148061
2009-06-01  Jakub Jelinek  
PR other/40024
* emutls.c (__emutls_get_address): Change arr->size to mean number
of allocated arr->data entries instead of # of slots + 1.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/emutls.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024

[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.

[ktietz at gcc dot gnu dot org]

--- Comment #7 from ktietz at gcc dot gnu dot org  2009-06-27 17:56 ---
I did regression test for 4.3 and 4.4 branches and it was successful.
I committed the patch for PR other/40024 to both branches.
Committed revision 149015 for 4.3 branch and committed revision 149016 for 4.4
branch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024

[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-06-27 17:56 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.3.3 4.4.0
  Known to work||4.3.4 4.4.1 4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024

[Bug c/40570] New: ice in get_constraint_for_ptr_offset with -O3

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package qemacs-0.3.1-381.2
with the G++ compiler version 4.5 snapshot 20090625.
The compiler said

css.c:819:24: warning: cast from pointer to integer of different size
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See  for instructions.

Preprocessed source attached. Flag -O3 required.

Here is valgrind helping out with a stack backtrace.

==19864== Invalid read of size 4
==19864==at 0x8897FE: get_constraint_for_ptr_offset
(tree-ssa-structalias.c:2877)
==19864==by 0x1006F: ???
==19864==by 0x7FFF: ???
==19864==by 0x87: ???
==19864==by 0x645537F: ???
==19864==by 0x7FEFFF92F: ???
==19864==by 0x5F2C57F: ???
==19864==  Address 0x623b23c is 12 bytes inside a block of size 72 free'd
==19864==at 0x4C257E1: realloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==19864==by 0xC231CC: xrealloc (xmalloc.c:179)
==19864==by 0x9076D6: vec_heap_o_reserve_1 (vec.c:320)
==19864==by 0x889823: get_constraint_for_ptr_offset
(tree-ssa-structalias.c:379)
==19864==by 0x1006F: ???
==19864==by 0x7FFF: ???
==19864==by 0x87: ???
==19864==by 0x645537F: ???
==19864==by 0x7FEFFF92F: ???
==19864==by 0x5F2C57F: ???


-- 
   Summary: ice in get_constraint_for_ptr_offset with -O3
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570

[Bug c/40570] ice in get_constraint_for_ptr_offset with -O3

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-06-27 18:08 ---
Created an attachment (id=18079)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18079&action=view)
C source code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570

[Bug tree-optimization/40570] [4.5 Regression] ice in get_constraint_for_ptr_offset with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-06-27 18:38 ---
Hm, for me it endlessly recurses

#49 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78db340, duplicate=0 '\0', 
update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261
261   cgraph_clone_inlined_nodes (e, duplicate, update_original);
(gdb) 
#50 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78e2980, duplicate=0 '\0', 
update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261
261   cgraph_clone_inlined_nodes (e, duplicate, update_original);
(gdb) 
#51 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78db340, duplicate=0 '\0', 
update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261
261   cgraph_clone_inlined_nodes (e, duplicate, update_original);
(gdb) 
#52 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78e2980, duplicate=0 '\0', 
update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261
261   cgraph_clone_inlined_nodes (e, duplicate, update_original);

-O2 -fipa-cp-clone is enough to cause that.

If you can reproduce the ICE in tree-ssa-structalias.c can you try to
reduce it and/or debug it?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mjambor at suse dot cz
  Component|c   |tree-optimization
Summary|ice in  |[4.5 Regression] ice in
   |get_constraint_for_ptr_offse|get_constraint_for_ptr_offse
   |t with -O3  |t with -O3
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570

[Bug tree-optimization/40570] [4.5 Regression] ice in get_constraint_for_ptr_offset with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-27 19:06 ---
Created an attachment (id=18080)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18080&action=view)
reduced testcase

slightly reduced testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570

[Bug fortran/40571] New: F2008: ISO_FORTRAN_ENV: Missing constants

[burnus at gcc dot gnu dot org]

For the missing inquiry function, see PR 40569.

Do not forget to update intrinsic.texi!

Missing are the following integer arrays/scalars:


CHARACTER_KINDS
  [ 1, 4 ]

INTEGER_KINDS
  [ 1, 2, 4 ...]

LOGICAL_KINDS
  [ 1, 2, 4, ...]

REAL_KINDS
  [ 4, 8, ... ]


IO_INQUIRE_INTERNAL_UNIT
  some positive number which cannot appear for any
  other error as value for IOSTAT=

STAT_STOPPED_IMAGE
  positive, /= IO_INQUIRE_INTERNAL_UNIT
  Different from other STAT= values which appear for
  STAT= in ALLOCATE/DEALLOCATE and in
  SYNC ALL/IMAGES/MEMORY.


-- 
   Summary: F2008: ISO_FORTRAN_ENV: Missing constants
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571

[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-06-27 19:44 ---
Do not forget to update intrinsic.texi!

For the missing constants in ISO_FORTRAN_ENV, see PR 40571


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569

[Bug middle-end/40502] [4.5 Regression] crash in cp_diagnostic_starter

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2009-06-27 20:07 
---
Reduced testcase:

===
struct A
{
  char x[12], y[35];
};

struct B
{
  char z[50];
};

inline void foo(char* dest, const char* __restrict src, __SIZE_TYPE__ n)
{
   __builtin___strncpy_chk (dest, src, n, 0);
}

void bar(const char*, int);

inline void baz(int i)
{
  char s[128], t[32];
  bar(s, 0);
  bar(t, i);
  A a;
  B b;
  foo(a.y, b.z, 36);
}

void quus()
{
  baz(0);
}
===


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40502

[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables

[ebotcazou at gcc dot gnu dot org]

--- Comment #13 from ebotcazou at gcc dot gnu dot org  2009-06-27 20:18 
---
> This appears to still be broken in 32-bit mode.

Yes, I've seen similar problems with 4.4.0 and 4.5.0 on x86.  Probably the
stack realignment stuff.  I'd suggest opening a new PR.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012

[Bug bootstrap/40572] New: gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

I've tried my hardest to build gcc without resorting to the use of
LD_LIBRARY_PATH. I simply can't understand why if LD_FLAGS is set to the path
of the mpfr library, the compiler can't use them. 

My compile bombs out with the well known error:

error: cannot compute suffix of object files: cannot compile

after trying to build it for a couple of hours. 

A read of $BUILD_DIRECOTRYsparc-sun-solaris2.10/libgcc/config.log

shows the real reason is that the compiler can't find the mpfr library. 

ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory

But I've specified in three ways where to look for this library.

1) Use of -L
2) Use of -R
3) Use of the configure flag --with-mpfr=

I've seen others report the same failure (cannot compute suffix of object
files) - see for example 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693

but it gets closed as 'invalid'. Given gcc finds the library during the initial
configure stage, spends two hours compiling (making two copies of xgcc), then
to bomb out since it can't find the library seems crazy. 

So I decided to set LD_LIBRARY_PATH (against my better judgement), but the
build would not proceed. However, I expect it will if I set it first, then
rebuild. 

Personally I think there are three things wrong here, that should be fixed, but
do doubt the bug will be closed as invalid. 

1) Don't expect people to use LD_LIBRARY_PATH
2) Check the location of the libraries in the configure script, so people don't
waste two hours building, only to find the library is not found. 
3) Respect the option --with-mpfr=
4) Respect LD_FLAGS

I expect this will be closed as invalid, so you will still get people
(especially on Solaris) finding this odd error. Clearly the configure script
found the libraries in a way specified by the options - perhaps the compiler
should not forget them a couple of hours later. 

I note a note by Brian Dessent on bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693 (reported against 4.3), that
the top level configure script should pick this up earlier, not when it comes
to run state 1 xgcc for the first time. 

I can't actually understand why it wont even 

I will both config.log and sparc-sun-solaris2.10/libgcc/config.log in the hope
someone might actually fix this bug, rather than dismiss it.


-- 
   Summary: gcc insistance on using LD_LIBRARY_PATH and ignoring
LD_FLAGS
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
 GCC build triplet: Sun T5240 Solaris 10 update 4
  GCC host triplet: Sun T5240 Solaris 10 update 4
GCC target triplet: Sun T5240 Solaris 10 update 4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

--- Comment #1 from david dot kirkby at onetel dot net  2009-06-27 20:25 
---
Created an attachment (id=18081)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18081&action=view)
Top level config.log


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

--- Comment #2 from david dot kirkby at onetel dot net  2009-06-27 20:29 
---
Created an attachment (id=18082)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18082&action=view)
sparc-sun-solaris2.10/libgcc/config.log

This is the file, which shows it can't find the library, a couple of hours
after the configure script finds it. 

VERY annoying. 

PLEASE PLEASE fix this. It hits a lot of people - I'm far from the only one. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-27 20:35 ---
What is the LDFLAGS supposed to do?  Is it supposed to adjust the run-path of
the built executables to find the mpfr/gmp libraries to not need
LD_LIBRARY_PATH
set?

Note that setting LDFLAGS maybe not what you want (it affects stage1 only
AFAIK), you likely want to set BOOT_LDFLAGS.

  $ ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc
--prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32
--with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld
--without-gnu-ld --enable-languages=c,c++,fortran
--with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32
--with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/
--with-libiconv-prefix=/usr/lib/iconv LDFLAGS=-R
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
-L
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

--- Comment #4 from david dot kirkby at onetel dot net  2009-06-27 20:57 
---
(In reply to comment #3)
> What is the LDFLAGS supposed to do?  Is it supposed to adjust the run-path of
> the built executables to find the mpfr/gmp libraries to not need
> LD_LIBRARY_PATH
> set?
> 
> Note that setting LDFLAGS maybe not what you want (it affects stage1 only
> AFAIK), you likely want to set BOOT_LDFLAGS.
> 
>   $ ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc
> --prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32
> --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld
> --without-gnu-ld --enable-languages=c,c++,fortran
> --with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32
> --with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/
> --with-libiconv-prefix=/usr/lib/iconv LDFLAGS=-R
> /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
> -L
> /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
> 

LD_LIBRARY_PATH should be used as a last resort - not the first resort. 

But it is surely crazy for the configure script to look for the libraries and
header files, then two hours later the build fails since the location of a
library, which was previously check for, is now forgotten. 

Does that not seem a bit illogical? 

If I've specified the location of the library in a way the configure script
accepts, AND specified -L option to the linker, why can't the linker find it? 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

--- Comment #5 from david dot kirkby at onetel dot net  2009-06-27 21:00 
---
(In reply to comment #3)

> Note that setting LDFLAGS maybe not what you want (it affects stage1 only
> AFAIK), you likely want to set BOOT_LDFLAGS.


Sorry, forget to comment on that. 

I'll try that. I would have thought if one set a standard option to the linker
like -R, it would have propagated, but I'll try that. 

It stills seems a bug to me though. This probably should be detected much
earlier. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-06-27 21:46 ---
LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are
running programs which use shared libraries stored in a "non standard" place.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug debug/40573] New: [4.4/4.5 Regression] DWARF for inlined subroutines refers to the outlined copy

[drow at gcc dot gnu dot org]

In the attached testcase (which will be added to the GDB testsuite), func1 is
both emitted as a function and inlined into main and func2.  The generated
DWARF output looks like this with mainline:

 <1><1bf>: Abbrev Number: 2 (DW_TAG_subprogram)
<1c0>   DW_AT_external: 1
<1c1>   DW_AT_name: (indirect string, offset: 0x11b): func1
<1c5>   DW_AT_decl_file   : 1
<1c6>   DW_AT_decl_line   : 22
<1c7>   DW_AT_prototyped  : 1
<1c8>   DW_AT_type: <0x1e8>
<1cc>   DW_AT_inline  : 3   (declared as inline and inlined)
<1cd>   DW_AT_sibling : <0x1e8>
 <2><1d1>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<1d2>   DW_AT_name: (indirect string, offset: 0x10c): arg1
<1d6>   DW_AT_decl_file   : 1
<1d7>   DW_AT_decl_line   : 22
<1d8>   DW_AT_type: <0x1e8>

 <1><202>: Abbrev Number: 9 (DW_TAG_subprogram)
<203>   DW_AT_abstract_origin: <0x1bf>
<207>   DW_AT_low_pc  : 0x4004a0
<20f>   DW_AT_high_pc : 0x4004e8
<217>   DW_AT_frame_base  : 0x0 (location list)
<21b>   DW_AT_sibling : <0x230>
 <2><21f>: Abbrev Number: 10 (DW_TAG_formal_parameter)
<220>   DW_AT_abstract_origin: <0x1d1>
<224>   DW_AT_location: 1 byte block: 53(DW_OP_reg3)

 <2><272>: Abbrev Number: 12 (DW_TAG_inlined_subroutine)
<273>   DW_AT_abstract_origin: <0x1bf>
<277>   DW_AT_entry_pc: 0x4004fa
<27f>   DW_AT_ranges  : 0x50
<283>   DW_AT_call_file   : 1
<284>   DW_AT_call_line   : 34
 <3><285>: Abbrev Number: 13 (DW_TAG_formal_parameter)
<286>   DW_AT_abstract_origin: <0x21f>

The problem is that the abstract origin of arg1 in the inlined copy (DIE at
0x285) refers to the outlined copy.  But this is not in the abstract subtree
referred to by the DIE at 0x272.

Two things go wrong in consequence.  GDB concludes that nothing in this subtree
refers to the DIE at 0x1d1 and stitches that DIE into the tree, resulting in a
second copy of arg1 (with no DW_AT_location).  This could be worked around in
GDB to compensate for the DWARF, but I'm convinced from the DWARF spec that the
nesting is invalid.  The other thing that goes wrong is even with the
workaround, we try to use the DW_AT_location from the outlined copy.  It works
by chance in 4.5; in 4.4 a location list was used instead of a register, so of
course the PC values in the location list do not apply.

Honza, Richi suggested on IRC that this might be related to your changes in
inline variable tracking.  Any idea?


-- 
   Summary: [4.4/4.5 Regression] DWARF for inlined subroutines
refers to the outlined copy
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573

[Bug debug/40573] [4.4/4.5 Regression] DWARF for inlined subroutines refers to the outlined copy

[drow at gcc dot gnu dot org]

--- Comment #1 from drow at gcc dot gnu dot org  2009-06-27 22:12 ---
Created an attachment (id=18083)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18083&action=view)
Test case

Compile with -O2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

--- Comment #7 from david dot kirkby at onetel dot net  2009-06-27 22:31 
---
(In reply to comment #6)
> LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are
> running programs which use shared libraries stored in a "non standard" place.
> 

So is any user who uses the compiler going to need to set  LD_LIBRARY_PATH ?
That would seem crazy if that is true. I don't need to set LD_LIBRARY_PATH on
my Sun to use the gcc from Blastwave, which resides in /opt/csw/bin/gcc or the
one which Sun ship which resides in /usr/sfw/bin. 

It is impossible for me to create a gcc-4.4.0 which links to libraries in
locations I chose, without users having to set LD_LIBRARY_PATH? It is not
possible to specify the locations of the libraries? I thought options like:

--with-mpfr-lib=PATHspecify directory for the installed MPFR library

were supposed to override the default /usr/local/lib. 

In some ways, an option like --ignore-usr-local would be nice on LOTS of
programs. The trouble with the 'standard' /usr/local is that it tends to
accumulate a lot of rubbish. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

--- Comment #8 from david dot kirkby at onetel dot net  2009-06-27 22:57 
---
It looks as though we will have to agree to differ about the LD_LIBRARY_PATH
being the right way to do things. 


But do you not agree that this probably should be found at an earlier stage in
the build process? If so, could you at least fix that, so other people don't
want so much time over this problem. If you Google for it, you will find there
are thousands of references to this. 


-- 

david dot kirkby at onetel dot net changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2009-06-27 23:39 ---
This is just like building any other program and running the result if you link
with a library stored somewhere else.  /usr/local/lib not being standard is up
to your distro really, it is a standard location according to GCC and should be
according to everything else, if it is not then it is a bug with your distro or
the runtime loader/linker.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-06-27 23:39 
---
It is semi hard to figure out early on really.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006

[jamborm at gcc dot gnu dot org]

--- Comment #3 from jamborm at gcc dot gnu dot org  2009-06-27 23:41 ---
I believe the  following (but yet untested) patch  fixes this issue.
I will bootstrap  and test it once I have a  testcase that is simple
enough to be  put into the testsuite.   I hope to do all  of this on
Monday.


Index: mine/gcc/tree-sra.c
===
--- mine.orig/gcc/tree-sra.c2009-06-28 00:58:23.0 +0200
+++ mine/gcc/tree-sra.c 2009-06-28 01:00:34.0 +0200
@@ -1908,7 +1908,8 @@ sra_modify_expr (tree *expr, gimple_stmt
  && host_integerp (TREE_OPERAND (bfr, 2), 1))
{
  chunk_size = tree_low_cst (TREE_OPERAND (bfr, 1), 1);
- start_offset = tree_low_cst (TREE_OPERAND (bfr, 2), 1);
+ start_offset = access->offset
+   + tree_low_cst (TREE_OPERAND (bfr, 2), 1);
}
   else
start_offset = chunk_size = 0;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[david dot kirkby at onetel dot net]

--- Comment #11 from david dot kirkby at onetel dot net  2009-06-28 03:51 
---
(In reply to comment #3) 
> Note that setting LDFLAGS maybe not what you want (it affects stage1 only
> AFAIK), you likely want to set BOOT_LDFLAGS.

FWIW, BOOT_LDFLAGS. that did not solve it either. I think I'll have a go with
'sed' and change /usr/local to somewhere else in the gcc-4.4.0.tar file.
Hopefully that will avoid the need for setting LD library path. 

It would be good if the /usr/local thing could be overridden, but sed might
come to my rescuse!

../gcc-4.4.0/configure 'CC=/usr/sfw/bin/gcc' \
--prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 \
--without-gnu-as \
--without-gnu-ld \
--with-as=/usr/ccs/bin/as  \
--with-ld=/usr/ccs/bin/ld \
--enable-languages=c,c++,fortran \
--with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 \
--with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32 \
--with-libiconv-prefix=/usr/lib/iconv \
BOOT_LDFLAGS='-R
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
-L
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib'
\
LDFLAGS='-R
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
-L
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib'




It later failed with 

  -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4.0/gcc -I../../gcc-4.4.0/gcc/.
-I../../gcc-4.4.0/gcc/../include -I./../intl
-I../../gcc-4.4.0/gcc/../libcpp/include
-I/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/include
-I/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/include
-I../../gcc-4.4.0/gcc/../libdecnumber -I../../gcc-4.4.0/gcc/../libdecnumber/dpd
-I../libdecnumber\
  -DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"4.4.0\"
-DDEFAULT_TARGET_MACHINE=\"sparc-sun-solaris2.10\"
-DSTANDARD_BINDIR_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/bin/\"
-DTOOLDIR_BASE_PREFIX=\"../../../../\"  `test "X${SHLIB_LINK}" = "X" || test
"yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` \
  -c ../../gcc-4.4.0/gcc/gcc.c -o gcc.o)
In file included from ../../gcc-4.4.0/gcc/gcc.c:73:
./multilib.h:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before
':' token
gmake[3]: *** [gcc.o] Error 1
gmake[3]: Leaving directory
`/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32'
gmake: *** [all] Error 2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572

[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2009-06-28 06:22 
---
> FWIW, BOOT_LDFLAGS. that did not solve it either. I think I'll have a go with
> 'sed' and change /usr/local to somewhere else in the gcc-4.4.0.tar file.
> Hopefully that will avoid the need for setting LD library path. 

Don't build the shared version of the libraries if you cannot manage them.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572