--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-30 07:23 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-30 07:21 ---
*** This bug has been marked as a duplicate of 39038 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-30 07:21 ---
*** Bug 39040 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39038
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-30 07:19 ---
*** Bug 39036 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-30 07:19 ---
STDC FENV_ACCESS is not implemented.
*** This bug has been marked as a duplicate of 20785 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-30 07:17 ---
isn't this a dup of the previous bug?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-30 07:14 ---
Invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #6 from rguenther at suse dot de 2009-01-30 06:52 ---
Subject: Re: Gcc accepts invalid code
On Fri, 30 Jan 2009, hjl dot tools at gmail dot com wrote:
> --- Comment #5 from hjl dot tools at gmail dot com 2009-01-30 01:17
> ---
> (In reply to comment #4)
> >
> >
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-30 05:35 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01498.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
Hello,
I found a strange behavior of the following code.
void fn(int x, int y){
if(int temp = ( x > y ? (x /y) : (x % y))){
cout << temp;
}
else{
double temp = x / y; // ill-formed, redeclaration of temp
cout << temp;
}
}
int main(int argc, char **argv){
fn(2, 3);
}
According to $6.4
The following program segfaults when compiled with "-O1 -ftree-vectorize
-msse2". Compiler is gfortran trunk revision 143693 (4.4.0 20090127).
Also fails with higher levels of optimization but requires both
-ftree-vectorize and -msse2.
program common
real (kind=8) b(5)
common /com1/b
b
Hello,
I found a strange behavior of the following code.
void fn(int x, int y){
if(int temp = ( x > y ? (x /y) : (x % y))){
cout << temp;
}
else{
double temp = x / y; // ill-formed, redeclaration of temp
cout << temp;
}
}
int main(int argc, char **argv){
fn(2, 3);
}
According to $6.4
--- Comment #3 from rob1weld at aol dot com 2009-01-30 04:31 ---
The building of Language Java is broken on (at least) two platforms.
Checking http://gcc.gnu.org/ml/gcc-testresults/2009-01/ it seems to
work on some other platforms. I'll investigate if it is my ./configure .
Rob
--
--- Comment #15 from rob1weld at aol dot com 2009-01-30 03:24 ---
(In reply to comment #9)
> Subject: Re: [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
> failing tests that worked previously
>
> I think adding a printf() clone to libiberty is WAY overkill just to
> silence
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-30 03:22
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedT
--- Comment #1 from pinskia at gmail dot com 2009-01-30 02:41 ---
Subject: Re: New: Decimal floating-point exception flags done wrong
Sent from my iPhone
On Jan 29, 2009, at 6:00 PM, "tydeman at tybor dot com"
wrote:
> Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Cor
Sent from my iPhone
On Jan 29, 2009, at 6:00 PM, "tydeman at tybor dot com" > wrote:
Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Core 10 and
-std=gnu99
There were some dfp fixes on the trunk relating to fp exceptions so
you should try the trunk before reporting any more bug
Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Core 10 with
-std=gnu99
/* DFP TR 24732 == WG14 / N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#pragma STDC FLOAT_CONST_DECIMAL64 ON /* unsuffixed => Decimal (not Binary) */
_Decimal64 d10 = 1.0DD
Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Core 10 and
-std=gnu99
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#pragma STDC FENV_ACCESS ON /* will be testing FP exception flags */
#include /* prin
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 01:43
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedT
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-30 01:41 ---
I am testing this patch:
Index: gcc/langhooks.c
===
--- gcc/langhooks.c (revision 143777)
+++ gcc/langhooks.c (working copy)
@@ -612,6 +612,7 @@
Using gcc 4.3.2-7 on Intel Pentium 4 running Fedora Core 10 and -std=gnu99 of
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include /* printf() */
int main(void){
if( 0.0DF ){
printf("0.0DF should be zero\n");
Using gcc 4.3.2-7 on Intel Pentium 4 running Fedora Core 10 with -std=gnu99 of
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include /* printf() */
int main(void){
double d2 = (double)((28./3.-9.) - (31./3.-1
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-30 01:17 ---
(In reply to comment #4)
>
> I think the frontend should, in C89 mode and if just issueing a warning,
> set DECL_EXTERNAL properly on the decl.
>
Do we want to make such a change, especially for 4.3 branch?
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-30 01:13 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00944.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-30 01:12 ---
/* The floating-point expression evaluation method.
-1 indeterminate
0 evaluate all operations and constants just to the range and
precision of the type
1 evaluate operations
Using gcc 4.3.2-7 on Intel Pentium running Linux Fedora Core 10
with -std=gnu99 of
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include /* DEC_EVAL_METHOD */
#ifndef DEC_EVAL_METHOD
#error Missing DEC_EVAL_METHOD
#
--- Comment #2 from janis at gcc dot gnu dot org 2009-01-30 00:31 ---
Please don't file a bug report against GLIBC for missing decimal float support
unless you enjoy being yelled at.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39032
--- Comment #2 from janis at gcc dot gnu dot org 2009-01-30 00:25 ---
Andrew is correct, math.h is not provided by GCC.
TR 24732 is not supported by GLIBC and probably won't be until it is
incorporated into a C standard. Meanwhile it is in a branch of the EGLIBC
project, but I understa
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-01-30 00:21
---
*** Bug 39018 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-30 00:21 ---
Yes this is a known bug, please see PR 11407.
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-30 00:19 ---
math.h is not controlled by the GCC project, so please file it with glibc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39032
gcc 4.3.2-7 with command line option -std=gnu99 of
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include/* DEC_INFINITY */
_Decimal32 d32 = DEC_INFINITY;
gets:
test2.c:5: warning: ISO C does not support decimal
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-30 00:05 ---
IIRC math.h is controlled by the glibc project and really this is a bug in
glibc and not GCC. GCC officially only implements the freestanding C library.
It is better to report it to the glibc project about this pro
The Decimal Floating Point (DFP) Technical Report (TR) added DFP versions
of HUGE_VAL to . They are missing in (at least) gcc 4.3.2-7.
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__/* Tell implementation that we want Decimal FP
*/
#include/* HUGE_VAL_D*
--- Comment #44 from rob1weld at aol dot com 2009-01-29 23:12 ---
(In reply to comment #43)
> Rob, your various assertions do not show that there is a bug here. ...
...
> I built GCC from 20090106, broke a couple of thing affecting cc1, float.h, and
> libgcc.a, and installed it. Then I
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-29 22:52 ---
I think the problem is LTO uses mmap to read in LTO sections. But all
LTO sections have alignment of 0. They have have alignment of void *
instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38995
--- Comment #27 from sezeroz at gmail dot com 2009-01-29 22:48 ---
I can confirm that after applying pr_w64.diff of Kai Tietz to svn rev 143768,
my similar problem which I reported at mingw-w64 site (which is also related
to the 143119 commit) is fixed. Thanks to all who wonked on this.
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-01-29 22:41
---
(In reply to comment #9)
> Assuming there is a way to trigger this, I wonder if the program is legal. In
> particular I was looking at the initialization of GbArgTable which has a lot
> of
> holes in it.
Those
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-29 22:39
---
I don't see anything in gsf-scan.c which would have been changed by that patch.
All the arrays are already marked as static. The only ones that changed by
that patch are auto arrays.
--
http://gcc.gnu.org/bu
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #10 from doko at ubuntu dot com 2009-01-29 22:36 ---
I'm able to reproduce it with trunk 20090129. The gsf-scan executable links
against the just built libgsf.so, so I assume we have to look for a miscompiled
file in libgsf.
--
doko at ubuntu dot com ch
--- Comment #43 from janis at gcc dot gnu dot org 2009-01-29 22:36 ---
Rob, your various assertions do not show that there is a bug here. The failure
of gcc.target/i386/funcspec-3.c described in comment #41 does not prove that
the compiler under test is using GCC files from the install
--- Comment #4 from billingd at gcc dot gnu dot org 2009-01-29 22:14
---
Tests gfortran.dg/chmod_2.f90 and gfortran.dg/chmod_3.f90 also fail.
There is also some discussion at
http://gcc.gnu.org/ml/fortran/2009-01/msg00353.html
In each case, the failure is due to the test
i = chmod
--- Comment #3 from billingd at gcc dot gnu dot org 2009-01-29 22:09
---
I asked about this on the cygwin list.
http://cygwin.com/ml/cygwin/2009-01/msg00718.html
On Jan 24 18:40, David Billinghurst wrote:
> I am having a problem with the access() function in cygwin-1.7.
>
> Under cygw
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-29 22:03 ---
patch http://gcc.gnu.org/ml/fortran/2009-01/msg00348.html
The failure for ik=8 is not fixed by this patch.
I thought it was ok because of the kind conversion function call.
But it seems it's not.
It is impacting f
--- Comment #4 from janis at gcc dot gnu dot org 2009-01-29 21:57 ---
We missed that. This is indeed a bug.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tydeman at tybor dot com 2009-01-29 21:52 ---
The Decimal Floating-Point Technical Report (WG14/N1176 and later) added
the suffixes 'd' and 'D' to indicate (binary) double, and 'dd' and 'DD' to
indicate decimal double (_Decimal64). The suffixes 'd' and 'D'
are in ad
--- Comment #4 from rguenther at suse dot de 2009-01-29 21:24 ---
Subject: Re: Gcc accepts invalid code
On Thu, 29 Jan 2009, joseph at codesourcery dot com wrote:
>
>
> --- Comment #2 from joseph at codesourcery dot com 2009-01-29 20:02
> ---
> Subject: Re: New: Gcc acce
--- Comment #2 from janis at gcc dot gnu dot org 2009-01-29 21:20 ---
In the C99 standard, floating constants are defined in section 6.4.4.2. A
floating constant of type double is unsuffixed; there is no 'd' or 'D' suffix.
Unless I'm missing something the test case is invalid.
--
j
>From http://gcc.gnu.org/ml/fortran/2009-01/msg00332.html:
The C99 patch (for GCC 4.5),
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html, fixes the excess
precision problem of the infamous PR 323 (yes, that old). For C99 there exists
a new option -fexcess-precision={standard,fast} which nee
2009/1/29 Stephan Springl :
> Hi,
>
> I just wanted to upload the attached files to gcc bugzilla entry #39028, but
> I always hit a bugzilla bug. Could you please attach these files to the bug
> for me?
Well first patches go to gcc-patches@ list with a changelog. And then
you don't need to uploa
When precompiling, #pragma once directives are handled correctly, but once we
try to use the pch, these directives are lost and the compiler will #include
again every real header file, even if it's already contained in the pch file.
The "easy" workaround is to fallback to include guards instead of
Hi,
I just wanted to upload the attached files to gcc bugzilla entry #39028,
but I always hit a bugzilla bug. Could you please attach these files to
the bug for me?
Thank you.
Regards
Stephancommit a9f24d7b25568b3fde13ae406deb1aeeacf45e23
Author: Stephan Springl
Date: Thu Jan 29 20:00:31
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-29 20:09 ---
(In reply to comment #2)
> If you use -std=c99 -pedantic-errors you get an error, as expected.
> You're compiling in gnu89 mode.
>
> If you use -std=c99 without -pedantic-errors you get a duplicate warning:
>
> t
On Thu, 29 Jan 2009, hjl dot tools at gmail dot com wrote:
> inline void foo ();
>
> int
> main ()
> {
> foo ();
> return 0;
> }
> [...@gnu-6 gcc]$ gcc /tmp/i.i -S
If you use -std=c99 -pedantic-errors you get an error, as expected.
You're compiling in gnu89 mode.
If you use -std=c99 wit
label.C
with g++ versions 4.4.0 20090129 (experimental) and 4.3.3 gives:
label.C: In function 'void c()':
label.C:2: error: '__label__' not at the beginning of a block
label.C:3: error: '__label__' not at the beginning of a block
label.C:3: error: duplicate label
--- Comment #2 from joseph at codesourcery dot com 2009-01-29 20:02 ---
Subject: Re: New: Gcc accepts invalid code
On Thu, 29 Jan 2009, hjl dot tools at gmail dot com wrote:
> inline void foo ();
>
> int
> main ()
> {
> foo ();
> return 0;
> }
> [...@gnu-6 gcc]$ gcc /tmp/i.i -
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-29 19:38 ---
I think you need to configure GCC with DFP support.
Defining __STDC_WANT_DEC_FP__ is not enough.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
With C command line option -std=gnu99
double floating-point constants with either 'd' or 'D' suffix
are not accepted by gcc 4.3.2-7 running on Intel x86/x87 Pentium 4
running Fedora Core 10 Linux
Part of gcc -v is:
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
#define __STDC_WANT_DEC_FP__ /*
--- Comment #9 from sje at cup dot hp dot com 2009-01-29 18:57 ---
So far I have been unable to reproduce this problem. When compiling gsf-scan.i
I do not even reach the code that I changed in PR 38615 and I get the same code
with or without my change included.
Assuming there is a way
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-29 18:34 ---
Icc 11.0 gave:
[...@gnu-6 tmp]$ /opt/intel/cce/11.0/bin/icc -S i.i-Wall
i.i(1): remark #1419: external declaration in primary source file
inline void foo ();
^
[...@gnu-6 tmp]$ /opt/intel/cce/11
--- Comment #42 from janis at gcc dot gnu dot org 2009-01-29 18:32 ---
I'm looking into this. It's all very messy and confusing, so I'm trying to
step back and understand the big picture.
Is there a reason that GCC_EXEC_PREFIX is set to $(libdir)/gcc/ for the
compiler tests but not for
--- Comment #4 from kazu at gcc dot gnu dot org 2009-01-29 18:31 ---
Fixed.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
+++ This bug was initially created as a clone of Bug #39013 +++
[...@gnu-6 gcc]$ cat /tmp/i.i
inline void foo ();
int
main ()
{
foo ();
return 0;
}
[...@gnu-6 gcc]$ gcc /tmp/i.i -S
Is this valid C code? From
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013#c10
--
IMHO this is invalid.
--- Comment #15 from zorry at ume dot nu 2009-01-29 18:23 ---
We have this in the shared library that is compile with -fPIC
inline u_int32_t
libnet_getgre_length(u_int16_t fv)
{
code
}
And the app have
code
len = libnet_getgre_length(gre_flags);
size += len;
code
--
http://gcc.
--- Comment #3 from kazu at gcc dot gnu dot org 2009-01-29 18:23 ---
Subject: Bug 39007
Author: kazu
Date: Thu Jan 29 18:23:21 2009
New Revision: 143767
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143767
Log:
gcc/
PR tree-optimization/39007
* tree-loop-distrib
--- Comment #33 from hjl dot tools at gmail dot com 2009-01-29 17:57
---
Reopen since revision 143757 isn't supposed to fix it.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from pinskia at gmail dot com 2009-01-29 17:53 ---
Subject: Re: [4.3 regression] wrong code building libgsf
Sent from my iPhone
On Jan 29, 2009, at 2:01 AM, "rguenth at gcc dot gnu dot org"
wrote:
>
>
> --- Comment #3 from rguenth at gcc dot gnu dot org 2009-01
--- Comment #7 from jdassen at debian dot org 2009-01-29 17:53 ---
(In reply to comment #3)
> The best option would be to revert that patch on the branch.
Matthias did that in the 4.3.3-3 packages and with them, the problem has
indeed gone away.
(In reply to comment #6)
> What GCC opti
Sent from my iPhone
On Jan 29, 2009, at 2:01 AM, "rguenth at gcc dot gnu dot org" > wrote:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-29
10:01 ---
The best option would be to revert that patch on the branch.
Except it alone could not cause wrong code. Some ot
--- Comment #6 from hjl at gcc dot gnu dot org 2009-01-29 17:43 ---
Subject: Bug 38887
Author: hjl
Date: Thu Jan 29 17:43:14 2009
New Revision: 143765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143765
Log:
2009-01-29 H.J. Lu
2009-01-28 Richard Guenther
--- Comment #9 from hjl at gcc dot gnu dot org 2009-01-29 17:43 ---
Subject: Bug 38883
Author: hjl
Date: Thu Jan 29 17:43:14 2009
New Revision: 143765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143765
Log:
2009-01-29 H.J. Lu
2009-01-28 Richard Guenther
--- Comment #15 from hjl at gcc dot gnu dot org 2009-01-29 17:43 ---
Subject: Bug 38908
Author: hjl
Date: Thu Jan 29 17:43:14 2009
New Revision: 143765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143765
Log:
2009-01-29 H.J. Lu
2009-01-28 Richard Guenther
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
--- Comment #32 from hjl dot tools at gmail dot com 2009-01-29 17:13
---
This has been fixed by revision 143757:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01410.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
The configure step of libgcc aborts with
checking for suffix of object files... configure: error: in
`/vol/gccsrc/obj/gcc-lto-20090127/11-gcc/sparc-sun-solaris2.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
config.log reveal
--- Comment #11 from hjl at gcc dot gnu dot org 2009-01-29 17:06 ---
Subject: Bug 38857
Author: hjl
Date: Thu Jan 29 17:06:01 2009
New Revision: 143762
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143762
Log:
2009-01-29 H.J. Lu
Backport from mainline:
2009-
--- Comment #10 from hjl at gcc dot gnu dot org 2009-01-29 17:06 ---
Subject: Bug 38926
Author: hjl
Date: Thu Jan 29 17:06:01 2009
New Revision: 143762
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143762
Log:
2009-01-29 H.J. Lu
Backport from mainline:
2009-
--- Comment #6 from sje at cup dot hp dot com 2009-01-29 17:00 ---
What GCC options was gsf-scan.i compiled with? I am trying to see what
variables are getting/not getting promoted during the compilation and I am not
seeing it affect any variables if I just compile gsf-scan.i with -O[01
I had built the prerequisite libelf 0.8.10 for lto statically to avoid RPATH
issues, but noticed that by default liblto_plugin.so.0 failed to link since
libelf.a contained non-PIC code. Building with -fPIC fixed this, but the
requirement better be documented.
--
Summary: static libel
lto-plugin.c uses mkdtemp unconditionally, which breaks Solaris 10/x86
bootstrap
where this function is missing (while it was introduced for Solaris 11). There
should be a replacement, but the fix for PR bootstrap/39022 would avoid this
since gold currently cannot be used on non-GNU/Linux configur
I just noticed that lto-plugin is only used with gold, but is built
unconditionally. This may unnecessarily break builds and should be avoided.
--
Summary: lto-plugin is built unconditionally
Product: gcc
Version: lto
Status: UNCONFIRMED
Se
--- Comment #2 from kazu at gcc dot gnu dot org 2009-01-29 16:11 ---
Patch posted.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
URL|
At least gcc/lto/common.c makes unconditional use of __attribute__ ((visibility
("hidden"))), which means you are forced to use GCC as a bootstrap compiler.
If
building lto and the lto-plugin were moved to stage2, this wouldn't be a
problem.
--
Summary: lto requires GCC as bootstrap
The lto plugin currently requires a bootstrap compiler with visibility support:
/vol/gcc/src/gcc-lto/lto-plugin/../gcc/lto/common.c:25: warning: visibility
attribute not supported in this configuration; ignored
Since it is built with -Werror, this causes a bootstrap failure if that support
is mis
Despite they seem to have the same interface, the libelf bundled with Solaris
(at
least as far back as Solaris 8) cause trouble:
* The Solaris libelf.h isn't largefile aware:
#if defined(_ILP32) && (_FILE_OFFSET_BITS != 32)
#error "large files are not supported by libelf"
#endif
This is explai
--- Comment #14 from hjl dot tools at gmail dot com 2009-01-29 15:53
---
Created an attachment (id=17211)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17211&action=view)
A patch
This patch only checks
--- gcc/varasm.c.pie2008-11-30 08:49:54.0 -0800
+++ gcc/varasm.c
--- Comment #13 from hjl dot tools at gmail dot com 2009-01-29 15:52
---
(In reply to comment #12)
> My testcase is
>
> > cat t2.c
> void foo() {}
The problem happens when t2.c is in a shared library.
> > cat t.c
> inline void foo ();
> int main ()
> {
> foo ();
> return 0;
> }
>
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-29 15:20
---
My testcase is
> cat t2.c
void foo() {}
> cat t.c
inline void foo ();
int main ()
{
foo ();
return 0;
}
which works perfectly fine even with 4.3 and 4.4 if I build both t2.c and t.c
with -fpie and fails with
--- Comment #11 from zorry at ume dot nu 2009-01-29 15:03 ---
I don't get the link error with gcc 4.2.4 on the code in comment #7
--
zorry at ume dot nu changed:
What|Removed |Added
--
--- Comment #41 from rob1weld at aol dot com 2009-01-29 15:01 ---
(In reply to comment #35)
> In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the
> compiler being tested in the build directory is invoked with -B.
> GCC_EXEC_PREFIX will only be used to find files
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-29 14:50 ---
This is likely a dup of PR38926 which was fixed Jan 28th.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39017
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.4 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35854
--- Comment #8 from zadeck at naturalbridge dot com 2009-01-29 14:42
---
patch committed.
closed for 4.4.
richi said not to backport to 4.3 on irc.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--
--- Comment #7 from zadeck at naturalbridge dot com 2009-01-29 14:38
---
Subject: Re: [4.3/4.4 Regression] life passes dump
option still documented
Richard Guenther wrote:
> On Wed, Jan 28, 2009 at 5:03 PM, Kenneth Zadeck
> wrote:
>
>> rguenth at gcc dot gnu dot org wrote:
>>
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-01-29 14:37
---
> RTEMS has fixed size task stacks. This test is blowing a stack that is ~100K
> large. How large does it need to be? Is is a bug to use this much stack?
It's a QOI issue, the stack usage is already capped (se
--- Comment #6 from zadeck at gcc dot gnu dot org 2009-01-29 14:35 ---
Subject: Bug 35854
Author: zadeck
Date: Thu Jan 29 14:34:55 2009
New Revision: 143756
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143756
Log:
2009-01-29 Kenneth Zadeck
PR middle-end/35854
1 - 100 of 137 matches
Mail list logo
