--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-23 08:21 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-01-23 08:21
---
Created an attachment (id=15005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15005&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34934
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-01-23 08:23
---
valgrind output (gcc (GCC) 4.3.0 20080122 (experimental)):
send_tiny.i: In function sendto_realops_lev:
send_tiny.i:77: warning: implicit declaration of function strlen
send_tiny.i:77: warning: incompatible
--- Comment #8 from jakub at gcc dot gnu dot org 2008-01-23 08:34 ---
Subject: Bug 34829
Author: jakub
Date: Wed Jan 23 08:33:22 2008
New Revision: 131756
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131756
Log:
PR c++/34829
* g++.dg/ext/pr34829.C (operator new
--- Comment #48 from steven at gcc dot gnu dot org 2008-01-23 08:52 ---
The priority of this bug is too high. If it wasn't just for recording that
this behavior exists in VRP and CPROP, I would propose to just close this bug
as WONTFIX. The test case is just too obscure, no man or mach
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-23 08:54 ---
Having slept on it, I know where the problem is - old_locus in decode_statement
points to the whitespace after a statement label. In consequence, if the label
is deleted, it is not parsed again.
A fix is regtesting.
--- Comment #36 from steven at gcc dot gnu dot org 2008-01-23 08:54 ---
What is the relation between the LIM patch and the alias oracle patch that was
floated some time ago?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
--- Comment #49 from rguenth at gcc dot gnu dot org 2008-01-23 09:06
---
I think it is reasonable to build in limits into passes that do work not
linear (or at least quadratic) in the number of statements, BBs or edges.
The testcase is probably just extracting the core problem from a r
--- Comment #10 from rguenther at suse dot de 2008-01-23 09:21 ---
Subject: Re: [4.3 Regression] ICE with some
constant vectors
On Tue, 22 Jan 2008, dominiq at lps dot ens dot fr wrote:
> --- Comment #8 from dominiq at lps dot ens dot fr 2008-01-22 23:50
> ---
> On i686-app
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-23 09:28 ---
> The tree-cfg.c hunk was supposed to fix this.
Additional info: on i686-apple-darwin9 the failures disappear with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
--- Comment #37 from rguenth at gcc dot gnu dot org 2008-01-23 09:12
---
The lim patch applies alias-oracle techniques to the loop invariant and store
motion parts of tree-ssa-loop-im.c. I have a forward-port of Zdeneks patch to
current trunk.
Note that the alias-oracle patch for SCCV
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-23 10:34 ---
Of course I tested the backport on x86_64-unknown-linux-gnu, where it worked
for me. And it should via
fold_builtin_classify
...
case BUILT_IN_FINITE:
if (!HONOR_NANS (TYPE_MODE (TREE_TYPE (arg)))
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-23 10:38 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from myway dot cn at gmail dot com 2008-01-23 10:40 ---
Created an attachment (id=15006)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15006&action=view)
source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34882
--- Comment #5 from debian-gcc at lists dot debian dot org 2008-01-23
10:40 ---
2005-01-15> I'm working on it.
Michael, any progress ;-?
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14759
--- Comment #3 from myway dot cn at gmail dot com 2008-01-23 10:41 ---
(In reply to comment #1)
> >g++: Internal error: Killed (program cc1plus)
> How much memory do you have? How much swap space do you have?
> Can you attach command_download.ii?
32M RAM of NSLU2
200MB swap space
--
--- Comment #6 from konqueror at gmx dot de 2008-01-23 10:43 ---
Give back.
--
konqueror at gmx dot de changed:
What|Removed |Added
AssignedTo|konqueror at gmx do
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-23 10:43 ---
I've "fixed" superH locally via
\\ gcc PR33200
Index: gcc-4.3.0/gcc/config.gcc
===
--- gcc-4.3.0/gcc/config.gcc(revision 131628)
+++ gcc-4.3.0/g
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-23 10:46 ---
Confirmed. They should not have the same canonical type.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-23 10:47 ---
Works for me on the trunk, even with
Index: tree-stdarg.c
===
--- tree-stdarg.c (revision 131756)
+++ tree-stdarg.c (working copy)
@@ -98,7
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-23 10:50 ---
This is not a regression. From write_builtin_type:
case REAL_TYPE:
if (type == float_type_node
|| type == java_float_type_node)
write_char ('f');
else if (type == double_type_node
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-23 10:56 ---
Confirmed. We mangle the function type and come along the CONST_DECL for b
which refers to the CONST_DECL of a. Some recursion is missing somewhere
here.
But we should not mangle for this non-instantiated template
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-23 10:56
---
*** Bug 34933 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-23 10:56
---
We chose not to implement it (I remember discussing it with Jerry and someone
else on IRC, and I think I asked for opinions on the mailing-list before
closing the bugreport as WONTFIX), because of the potential pr
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-23 10:57 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-23 10:58 ---
Confirmed. Related to PR34937.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Bu
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-23 10:59 ---
This is actually a big can of worms.
may_alias causes a distinct type code to be created.
For mangling I've tried:
--- mangle.c.jj128 2007-10-08 10:44:57.0 +0200
+++ mangle.c2008-01-23 11:11:12.000
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-23 11:01 ---
It is unclear whether this can be considered a regression or not.
In GCC 3.2 and earlier the may_alias attribute was ignored, so while it meant
something else, we weren't ICEing on it.
--
jakub at gcc dot gnu dot o
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #4 from debian-gcc at lists dot debian dot org 2008-01-23
11:07 ---
this patch is applied on the current trunk; the bug should be closed.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-23 11:27 ---
It is not always a win. A function called once on a cold path should not be
inlined for e.g. icache reasons.
For your test case however, CS1 should have been inlined.
--
steven at gcc dot gnu dot org changed:
contained subroutines called only once are not inlined, despite the fact that
it is always a win (independent of the size of the contained subroutine). It
'only requires' counting the number of calls to cs1 in the routine s1, if it is
1, it should be inlined, as there can not be other callers.
exa
--- Comment #8 from tbm at cyrius dot com 2008-01-23 12:11 ---
Rask, can you please submit the patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #9 from nickc at redhat dot com 2008-01-23 13:13 ---
Created an attachment (id=15007)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15007&action=view)
Improve --help= output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
--- Comment #10 from nickc at redhat dot com 2008-01-23 13:13 ---
Subject: Re: [4.3 Regression] gcc -v --help returns no options
for C, C++
Hi Manuel,
> % gcc -v --help=c
>
> returns the following for me
>
> The following options are language-independent:
> --help
--- Comment #8 from debian-gcc at lists dot debian dot org 2008-01-23
13:34 ---
please mark it as closed, if it is not a candidate for a backport.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-23 13:54 ---
It's considered too big and it's not static.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-23 13:55 ---
Considering cs1 with 52 insns
to be inlined into s1
Estimated growth after inlined into all callees is -13 insns.
Estimated badness is 86, frequency 1.00.
Not inlining into s1:--param large-stack-frame-growth lim
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-23 14:20
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-23 14:20
---
Subject: Bug 31529
Author: rguenth
Date: Wed Jan 23 14:20:07 2008
New Revision: 131758
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131758
Log:
2008-01-23 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #32 from rguenth at gcc dot gnu dot org 2008-01-23 14:24
---
Patches pending for review:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00862.html
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00951.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--- Comment #19 from debian-gcc at lists dot debian dot org 2008-01-23
14:38 ---
$ gcc-4.3 --version
gcc-4.3 (Debian 4.3-20080116-1) 4.3.0 20080116 (experimental) [trunk revision
131577]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying
--- Comment #7 from aldot at gcc dot gnu dot org 2008-01-23 14:41 ---
Created an attachment (id=15008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15008&action=view)
libgcc patch #2
Updated patch
--
aldot at gcc dot gnu dot org changed:
What|Removed
[forwarded from http://bugs.debian.org/425623]
This code:
#include
int main(int argc, char *argv[])
{
void *a, *b;
printf("%d\n", a - b);
return 0;
}
will generate this warning on a 64-bit platform:
temp.c:5: warning: format %d expects type int, but argument 2 has t
--- Comment #61 from lucier at math dot purdue dot edu 2008-01-23 15:03
---
Subject: Re: Inordinate compile times on large routines
Kenny:
Even after you backed out this latest patch the CPU usage was down
(to 203 seconds from 280 seconds on my machine) and the maximum
memory usa
--- Comment #60 from joel at gcc dot gnu dot org 2008-01-23 15:12 ---
I did a build of powerpc-rtems4.9 on the trunk and it built much more quickly.
I haven't had a chance to run the ACATS yet to check run-time behavior. Thanks
for all the effort for this one.
--
http://gcc.gnu.or
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
|
--- Comment #4 from tgall dot foo at gmail dot com 2008-01-23 15:28 ---
Hi Ben,
Yesterday I picked this up again using the 0118 snapshot. Same failure.
Yes this is being built inside of portage. No patches are being applied. (I've
disabled that)
Following the direction of Peter Bergn
--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-23 15:45 ---
(In reply to comment #2)
> It's considered too big and it's not static.
>
not sure if my C is good enough to reply, but CS1 is visible only from within
the subroutine S1. That's somewhat similar to (or stricter than) '
--- Comment #6 from hjl dot tools at gmail dot com 2008-01-23 15:47 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01062.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-23 15:59 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
[forwarded from http://bugs.debian.org/426809]
seen with trunk 20080123
another possibility might be to unset the locale, or set it to C
Matthias
The g++ -frepo option only works with C locale, not with es_UY for example.
A possible test case is:
template class C
{
public:
C
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-23 16:20 ---
CCing the canonical type expert.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-23 16:30 ---
What would be the semantics of "weak" on a template member? That is, how would
the weak reference be overridden?
What I'm looking for is an example of what GCC did with this declaration when
it was still accepted.
--- Comment #21 from burnus at gcc dot gnu dot org 2008-01-23 16:36 ---
Another test case
module m
public :: volatile
contains
subroutine foo
volatile :: bar
end subroutine foo
subroutine volatile
end subroutine volatile
end module
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #9 from tromey at gcc dot gnu dot org 2008-01-23 16:43 ---
Reopened while I look at the new problem
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from matz at gcc dot gnu dot org 2008-01-23 16:45 ---
Subject: Bug 34895
Author: matz
Date: Wed Jan 23 16:44:27 2008
New Revision: 131761
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131761
Log:
PR debug/34895
* dwarf2out.c (force_type_die): Use
Consider this C test case:
const char *
f(long v)
{
if (v < 0)
v = - v;
if (v > 0x7fff)
return "negative";
else
return "positive";
}
When this is compiled with -O2, it always returns "positive". This is fine
because when v == LONG_MIN, negating it is undefined signed overfl
--- Comment #1 from ian at airs dot com 2008-01-23 16:46 ---
Created an attachment (id=15009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15009&action=view)
Proposed patch
I believe that this is the correct patch for this bug. This should be tested
and committed for gcc 4.4.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-23 16:48 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-01-23 16:49
---
(In reply to comment #9)
> Reopened while I look at the new problem
>
Jakub fixed it last night with:
Author: jakub
Date: Wed Jan 23 08:33:22 2008
New Revision: 131756
URL: http://gcc.gnu.org/viewcvs?root=gcc&v
--- Comment #6 from matz at gcc dot gnu dot org 2008-01-23 16:54 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2008-01-23 17:12
---
With the patch I get this:
xgcc -m32 -O1 -c send_tiny.i
send_tiny.i: In function sendto_realops_lev:
send_tiny.i:77: warning: incompatible implicit declaration of built-in function
strlen
send_tiny.i:25: in
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-23 17:22 ---
just a note, ifort does inline the function cs1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
On both Linux/x86-64 and Linux/ppc I get an tree check error bootstrapping
current GCC 4.2 SVN:
/abuild/aj/gcc/powerpc64-suse-linux-gnu/libstdc++-v3/include/bits/cpp_type_traits.h:3
71: internal compiler error: tree check: expected class type, have
declaration (n
amespace_decl) in complete_typ
With compiler
gcc version 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)
I get the following error message
>gfortran vf0009.f
vf0009.f: In function 'vf0009':
vf0009.f:11: error: size of variable 'test_array' is too large
If I replace the second line in the declaration of test_array
--- Comment #8 from manu at gcc dot gnu dot org 2008-01-23 17:57 ---
(In reply to comment #7)
> This is bison 2.0.
> The latest version is 2.3. If haven't found anything in the ChangeLog which
> sounds like there was a bug fix in this area.
>
You should really try bison 2.3 just in cas
--- Comment #1 from aj at gcc dot gnu dot org 2008-01-23 17:30 ---
configure line is:
# /cvs/gcc-svn/branches/gcc-4_2-branch/configure --prefix=/opt/gcc/4.2-devel
--enable-checking=yes,rtl --enable-threads=posix --enable-clocale=gnu
--enable-ssp --disable-libssp --enable-libstdcxx-allo
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-23 17:59 ---
Fix checked in a while ago.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2008-01-23 18:00 ---
I don't think this will be fixed before GCC 4.3 is released, which is a shame.
But if anyone has a suggestion on how to fix this, I will try to submit a patch
ASAP.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34
--- Comment #5 from manu at gcc dot gnu dot org 2008-01-23 18:13 ---
I think this is a regression since it used to work in GCC 4.0.0 and 4.1.0.
>From the duplicated report:
gcc_release is supposed to generate html files in HTML/ from
gcc/doc/install.texi for release candidates and fina
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
--- Comment #8 from dick dot hendrickson at gmail dot com 2008-01-23 18:31
---
Subject: Re: [4.2/4.3 Regression] implicit character(s) hides type of
selected_int_kind intrinsic
I have another example of what might be the same problem, although the
symptoms are
a little different. the
--- Comment #4 from manu at gcc dot gnu dot org 2008-01-23 18:34 ---
Regressions should have a target milestone
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-01-23 18:35 ---
Regressions should have a target milestone
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-01-23 18:36 ---
Regressions should have a target milestone.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from manu at gcc dot gnu dot org 2008-01-23 18:37 ---
Regressions should have a target milestone
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #145 from jv244 at cam dot ac dot uk 2008-01-23 19:02 ---
current gfortran trunk seems to fail on CVS sources of CP2K with:
/data03/vondele/clean/cp2k/src/../src/realspace_grid_types.F: In function
rs_grid_create:
/data03/vondele/clean/cp2k/src/../src/realspace_grid_types.
GNU Fortran (GCC) 4.3.0 20080121 (experimental) [trunk revision 131689] yields
> gfortran -ffree-form bug.F
bug.F: In function rs_grid_create:
bug.F:147: internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:592
Please submit a full bug report,
with preprocessed sourc
--- Comment #1 from jv244 at cam dot ac dot uk 2008-01-23 19:25 ---
Created an attachment (id=15010)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15010&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34946
--- Comment #146 from jv244 at cam dot ac dot uk 2008-01-23 19:30 ---
(In reply to comment #145)
> current gfortran trunk seems to fail on CVS sources of CP2K with:
PR34946
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
This problem is about functions that push some float registers at the
beginning, but forget to pop them at the end. The stack pointer is not adjusted
as expected, so the function return to an invalid address.
It appears when the following is true:
- the file is compiled with -m68020-60 -O1 -fomit-
--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-23 20:26 ---
*** This bug has been marked as a duplicate of 34824 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from jakub at gcc dot gnu dot org 2008-01-23 20:26 ---
*** Bug 28475 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from aj at gcc dot gnu dot org 2008-01-23 20:43 ---
Note: This appears with *both* x86_64-unknown-linux-gnu and
powerpc64-suse-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34944
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916
--- Comment #14 from pluto at agmk dot net 2008-01-23 21:01 ---
> :-( I cannot compile this testcase
please try the latest testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
The problem is shown by the following code: basically, when using the +=
operator on a pointer which is the member of a class as in a line like below:
a.myptr += a.SideEffect();
if the a.myptr pointer is modified by the a.SideEffect() call, the += still
takes into account only the old po
--- Comment #8 from peter dot waller at gmail dot com 2008-01-23 21:15
---
Still no sign of 4.2 fix?
--
peter dot waller at gmail dot com changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2008-01-23 21:24 ---
Subject: Bug 34944
Author: jason
Date: Wed Jan 23 21:23:32 2008
New Revision: 131765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131765
Log:
PR bootstrap/34944
Modified:
branches/gcc-4_2-branch
--- Comment #4 from jason at gcc dot gnu dot org 2008-01-23 21:24 ---
That's bizarre, I'm not sure how I managed to check in a different version of
that patch on 4.2 than the one I tested. Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tgall dot foo at gmail dot com 2008-01-23 21:31 ---
so the call path involved here is from gcc/c-cppbuiltin.c
builtin_define_with_hex_fp_value
which is calling real_to_decimal and its in that function we're running into
problems.
The string rep of the real is : 0x0
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-23 21:35
---
Not fixed on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-23 21:44 ---
I checked both a 32bit compiler and x86_64 with -m32 (with the reduced
testcase).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34934
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-23 21:46 ---
Fortran is not release-critical.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-23 21:49 ---
There's no sequence point, the order of evaluation is undefined.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from terry at chem dot gu dot se 2008-01-23 21:54 ---
Rather than open a new bug, I'll tack onto this one as it's pretty much the
same bug in a different context.
The latest gfortran does indeed give a sensible error for the test case above.
However, if we put something
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-23 22:21
---
Run is fine, invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 138 matches
Mail list logo
