--- Comment #14 from ubizjak at gmail dot com 2009-01-29 08:05 ---
Cc the author of the patch:
Author: hubicka
Date: Tue Jan 6 15:08:44 2009
New Revision: 143119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143119
Log:
* i386.h (CONDITIONAL_CALL_USAGE): SSE regs are
--- Comment #15 from ubizjak at gmail dot com 2009-01-29 08:06 ---
4.4 regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Summary|codegen bug
>From running the testsuite and for the testcase 20021204-1.c
/home/ramana/cos/build-try/gcc/cc1 -fpreprocessed 20021204-1.i -quiet -dumpbase
20021204-1.c -mtune=generic -auxbase-strip 20021204-1.o -O1 -w -version -flto
-o 20021204-1.s
#0 fancy_abort (file=0xa888740 "P\207\210\nP\207\210\n\t",
--- Comment #1 from jdassen at debian dot org 2009-01-29 09:10 ---
Created an attachment (id=17206)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17206&action=view)
The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from jdassen at debian dot org 2009-01-29 09:11 ---
Created an attachment (id=17207)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17207&action=view)
The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled,
preprocessed.
--
http://gcc.gnu.org/bugzil
--- Comment #14 from rguenther at suse dot de 2009-01-29 09:19 ---
Subject: Re: [4.4 regression] Unexplained "'' is
used uninitialized in this function" warning in cc1plus -m64
On Wed, 28 Jan 2009, mmitchel at gcc dot gnu dot org wrote:
> --- Comment #13 from mmitchel at gcc dot
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-29 09:56
---
No compiler with -fpie support manages to do this "correct". Not a regression.
IMHO this is invalid. 6.7.4/6
"... If a function is declared with an inline function specifier, then it
shall also be defined in th
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- 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.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from uros at gcc dot gnu dot org 2009-01-29 10:05 ---
Subject: Bug 38969
Author: uros
Date: Thu Jan 29 10:05:17 2009
New Revision: 143752
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143752
Log:
Backport from mainline:
2009-01-28 Uros Bizjak
--- Comment #11 from uros at gcc dot gnu dot org 2009-01-29 10:05 ---
Subject: Bug 38988
Author: uros
Date: Thu Jan 29 10:05:17 2009
New Revision: 143752
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143752
Log:
Backport from mainline:
2009-01-28 Uros Bizjak
--- Comment #12 from ubizjak at gmail dot com 2009-01-29 10:09 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from ubizjak at gmail dot com 2009-01-29 10:10 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from doko at ubuntu dot com 2009-01-29 10:14 ---
when Ray wrote he tested with a snapshot build, I assume this was 20090107
without the patch applied, so the status on the trunk is not known yet. will
test with current trunk later.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #5 from jdassen at debian dot org 2009-01-29 10:24 ---
(In reply to comment #4)
> when Ray wrote he tested with a snapshot build, I assume this was 20090107
> without the patch applied,
Yes, I was using sid's gcc-snapshot 20090107-1.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-29 10:31 ---
Created an attachment (id=17208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208&action=view)
gcc44-pr39002.patch
As MS_ABI sseregs save area isn't counted into frame.allocate anymore, IMHO
ix86_can_use_ret
--- Comment #12 from gzp at gmx dot net 2009-01-29 10:43 ---
Anyone knows how 'i686-pc-linux-gnu/libmudflap/libtool' file generated?
Thats the problem, and still is with released 4.3.3.
--
gzp at gmx dot net changed:
What|Removed |Added
---
--- Comment #17 from r dot emrich at de dot tecosim dot com 2009-01-29
10:47 ---
(In reply to comment #16)
> Created an attachment (id=17208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208&action=view) [edit]
> gcc44-pr39002.patch
>
> As MS_ABI sseregs save area isn't counte
--- Comment #9 from amonakov at gcc dot gnu dot org 2009-01-29 10:53
---
Subject: Bug 38857
Author: amonakov
Date: Thu Jan 29 10:53:15 2009
New Revision: 143753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143753
Log:
2009-01-29 Andrey Belevantsev
Alexander Mon
--- Comment #10 from amonakov at gcc dot gnu dot org 2009-01-29 10:55
---
Fixed with above commit.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from l dot jirkovsky at gmail dot com 2009-01-29 11:19
---
First, I'd like to thank you for doing this hard work and for finding out which
patch causes this problem.
Anyway I've done more investigation to the problematic code.
The problem actually begins in
CachedFileI
--- Comment #5 from paolo dot carlini at oracle dot com 2009-01-29 11:23
---
Are we really sure this is invalid? For one, EDG doesn't agree...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #18 from r dot emrich at de dot tecosim dot com 2009-01-29
11:34 ---
(In reply to comment #17)
> (In reply to comment #16)
> > Created an attachment (id=17208)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17208&action=view) [edit]
> > gcc44-pr39002.patch
> >
> > As M
I just tried to compile the Suse Linux package
kde4-k3b-4.1.4.svn907132-1.5 with the g++ compiler version 4.4 snapshot
20090123. The compiler said
/usr/src/packages/BUILD/k3b/libk3b/tools/k3blibdvdcss.cpp:109: internal
compiler error: in find_or_generate_expression, at tree-ssa-pre.c:2769
Please s
--- Comment #1 from dcb314 at hotmail dot com 2009-01-29 11:53 ---
Created an attachment (id=17209)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17209&action=view)
C++source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39017
--- Comment #19 from jakub at gcc dot gnu dot org 2009-01-29 12:03 ---
Anyone else could test it, please?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from ktietz at gcc dot gnu dot org 2009-01-29 12:21 ---
(In reply to comment #19)
> Anyone else could test it, please?
I am currently on to test it for w64. We noticed a regression reasoned by this
for this target, too (sadly we found it pretty late).
This patch seems f
--- Comment #21 from ktietz at gcc dot gnu dot org 2009-01-29 12:27 ---
Created an attachment (id=17210)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17210&action=view)
Alternative patch suggested
This is the patch I test at the moment.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #14 from rob1weld at aol dot com 2009-01-29 12:32 ---
(In reply to comment #5)
> ! Test XFAILed on these platforms because the system's printf() lacks
> ! proper support for denormalized long doubles. See PR24685
> Looks like this testcase should be xfailed on solaris also.
--- Comment #22 from ktietz at gcc dot gnu dot org 2009-01-29 12:52 ---
(In reply to comment #21)
> Created an attachment (id=17210)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17210&action=view) [edit]
> Alternative patch suggested
> This is the patch I test at the moment.
The
--- Comment #20 from danglin at gcc dot gnu dot org 2009-01-29 13:05
---
hppa just uses the generic code for delayed branch optimization.
The target problems that led to this PR were fixed in this series of
changes:
2009-01-05 John David Anglin
* pa.c (output_call): Reloca
--- Comment #23 from jakub at gcc dot gnu dot org 2009-01-29 13:23 ---
I don't see why ix86_expand_epilogue should be changed. Do you have some
testcase which shows where your change improves generated code?
I can certainly test on Linux, but as frame.nsseregs is always 0 there, it
sho
The following code fails to compile under g++ 4.3.2:
class Bar {};
template
class Foo {
double val[N];
};
template
void fun(Foo* ptr) {
}
typedef void (*T)(Bar*);
T funptr = (T) &fun<2>;
The error message is:
$ g++ -c a.cc
a.cc:14: error: address of overloaded function with no contextual t
--- Comment #24 from ktietz at gcc dot gnu dot org 2009-01-29 13:45 ---
(In reply to comment #23)
> I don't see why ix86_expand_epilogue should be changed. Do you have some
> testcase which shows where your change improves generated code?
> I can certainly test on Linux, but as frame.ns
--- Comment #25 from jakub at gcc dot gnu dot org 2009-01-29 13:54 ---
Can't reproduce that with a cross compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- Comment #26 from ktietz at gcc dot gnu dot org 2009-01-29 14:04 ---
(In reply to comment #25)
> Can't reproduce that with a cross compiler.
You are right, I changed something else, too. Sorry.
But this patch to expand_epilogue is proper IIUC
Comment tells
"If we're only restoring
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
--- 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
--- 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 #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 #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
--
--
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 #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
--- 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 #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 #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 #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 #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
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
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
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
--- 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|
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
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 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
--- 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
--- 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 #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-
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 #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
--
--
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 #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
--- 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 #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
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 #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
--- 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 #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 #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 #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.
+++ 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 #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
--- 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 #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 #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
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 #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
---
--
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 #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 -
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
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
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
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
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
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
>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
--- 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
--- 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 #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 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 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 #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 #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 #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 #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
--
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 #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
--- 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 #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.
1 - 100 of 137 matches
Mail list logo
