--- 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=gccview=revrev=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
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=17206action=view)
The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled
--
--- 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=17207action=view)
The (gtk-doc-tools generated) gsf-scan.c file which gets miscompiled,
preprocessed.
--
--- Comment #14 from rguenther at suse dot de 2009-01-29 09:19 ---
Subject: Re: [4.4 regression] Unexplained 'anonymous' 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
--- 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 the
--
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=gccview=revrev=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=gccview=revrev=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.
--
--- 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.
--
--- 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=17208action=view)
gcc44-pr39002.patch
As MS_ABI sseregs save area isn't counted into frame.allocate anymore, IMHO
--- 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=17208action=view) [edit]
gcc44-pr39002.patch
As MS_ABI sseregs save area isn't counted
--- 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=gccview=revrev=143753
Log:
2009-01-29 Andrey Belevantsev a...@ispras.ru
--- 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
--- 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=17208action=view) [edit]
gcc44-pr39002.patch
As MS_ABI
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
--- 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=17209action=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
--- 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=17210action=view)
Alternative patch suggested
This is the patch I test at the moment.
--
--- 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=17210action=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 dave.ang...@nrc-cnrc.gc.ca
*
--- 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
The following code fails to compile under g++ 4.3.2:
class Bar {};
templateint N
class Foo {
double val[N];
};
templateint N
void fun(FooN* ptr) {
}
typedef void (*T)(Bar*);
T funptr = (T) fun2;
The error message is:
$ g++ -c a.cc
a.cc:14: error: address of overloaded function with no
--- 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
--- 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=gccview=revrev=143756
Log:
2009-01-29 Kenneth Zadeck zad...@naturalbridge.com
PR
--- 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 (see
--- 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
zad...@naturalbridge.com wrote:
rguenth at gcc dot gnu
--- 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;
}
which
--- 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=17211action=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 explained
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
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
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
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
--- 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
--- 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=gccview=revrev=143762
Log:
2009-01-29 H.J. Lu hongjiu...@intel.com
Backport from
--- 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=gccview=revrev=143762
Log:
2009-01-29 H.J. Lu hongjiu...@intel.com
Backport from
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
--- 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=gccview=revrev=143765
Log:
2009-01-29 H.J. Lu hongjiu...@intel.com
2009-01-28
--- 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=gccview=revrev=143765
Log:
2009-01-29 H.J. Lu hongjiu...@intel.com
2009-01-28 Richard
--- 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=gccview=revrev=143765
Log:
2009-01-29 H.J. Lu hongjiu...@intel.com
2009-01-28 Richard
Sent from my iPhone
On Jan 29, 2009, at 2:01 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.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
--- 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
--- 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
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #3 from rguenth at gcc
--- 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=gccview=revrev=143767
Log:
gcc/
PR tree-optimization/39007
*
--- 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
--
+++ 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
--- 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]$
--- 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 -S
If
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 'l'
The fix for bug 32121 C
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 without
--- 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.c:1:
--
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
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 springl-...@bfw-online.de:
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
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
--- 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.
--
--- 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 accepts
--- 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
--- 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
--- 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
--- 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 changed
--
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.
--
--- 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
1 - 100 of 137 matches
Mail list logo
