--- 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 libra
--- 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'
--- 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.
--- 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
--- 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 accordin
--- 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?
--- 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
--- 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
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_n
--- 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:
Wha
--- 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 h
--- 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
--- 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 (
--- 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
--- 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
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
--- 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/bug
--- 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_TYP
--- 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
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 pos
--- 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
--- 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_clon
--- 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
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
--- 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|UNCONFIRM
--- 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.
--- 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
--- 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
--- 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/
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 t
--- 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_d
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 t
--- 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
--- 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
--- 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
--
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
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 fi
--
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|
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: UNCONFIRME
--- 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
40 matches
Mail list logo
