--- Comment #16 from rguenther at suse dot de 2007-11-27 09:10 ---
Subject: Re: Empty macro definitions not considered
equal
On Mon, 26 Nov 2007, manu at gcc dot gnu dot org wrote:
--- Comment #15 from manu at gcc dot gnu dot org 2007-11-26 17:47 ---
(In reply to comment
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-11-27 09:40
---
For the testcase in comment #13 we now generate two(!) temporaries:
void barc() ()
{
struct Foo D.2027;
struct Foo D.2028;
D.2027 = {};
D.2028 = {};
bar (D.2028);
}
via gimplification of
;; Function
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43
---
This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64
parameter as volatile to work around this issue. I expect upstream to adopt
a workaround as well. Note that some targets in the kernel
Build gcc version 4.3.0 20070711 (experimental) with fortran faild. The massage
is,
checking whether the GNU Fortran compiler is working... no
configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
--- Comment #13 from burnus at gcc dot gnu dot org 2007-11-27 09:48 ---
For testsub.f, g95 creates (for EXTERNAL BDTEST):
static void * U0 = bdtest_;
which shows up as:
U bdtest_
same for ifort. While sunf95 and openf95 have bdtest_ in the dump.
And for the BLOCK
--- Comment #7 from burnus at gcc dot gnu dot org 2007-11-27 09:55 ---
I think this is fixed by the patch for PR 22244.
Patches:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00888.html
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00903.html
--
--- Comment #12 from burnus at gcc dot gnu dot org 2007-11-27 09:56 ---
I think the patch also fixes PR 17905.
Current patch links:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00888.html
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00903.html
--
--- Comment #5 from aph at gcc dot gnu dot org 2007-11-27 10:24 ---
Should be fixed now on EABI.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ramana dot radhakrishnan at celunite dot com
2007-11-27 11:00 ---
(In reply to comment #13)
This patch sometimes confuses loop2_doloop. On ia64 this prevents use of
countable loop branch machine idiom (br.cloop). On the example used in this
thread loop2_doloop
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
int* GetParent(void);
int* FindCommonAncestor(int *aNode1, int *aNode2)
{
if (aNode1 aNode2) {
int offset = 0;
int *anc1 = aNode1;
for (;;) {
++offset;
int * parent = GetParent();
if (!parent)
break;
anc1 = parent;
}
int *anc2 = aNode2;
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-27 11:30 ---
Runtime testcase:
int __attribute__((noinline)) GetParent(void)
{
static int count = 0;
count++;
switch (count)
{
case 1:
case 3:
case 4:
return 1;
default:
return 0;
}
Builtins for all the other floating-point classification macros are already
implemented and it would be nice to complete the set with __builtin_fpclassify
(could be certainly exploited in libstdc++, also)
--
Summary: Missing __builtin_fpclassify
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-27 11:55 ---
You attached the incorrect config.log. Configure specificied the correct one
to attach, please do that.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
From
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01452.html
FAIL: gfortran.dg/bind_c_usage_16.f03 -O0 execution test
FAIL: gfortran.dg/bind_c_usage_16.f03 -O1 execution test
FAIL: gfortran.dg/bind_c_usage_16.f03 -O2 execution test
FAIL: gfortran.dg/bind_c_usage_16.f03 -O3
--- Comment #2 from fgccbz1 at greynode dot net 2007-11-27 12:08 ---
Sorry - it looks like compiling as c++ is required. I thought I'd eliminated
that issue in my original analysis, but evidently I was wrong.
I see the weird behavior just when compiling with
g++ cast.c -o cast
but not
--- Comment #3 from fgccbz1 at greynode dot net 2007-11-27 12:09 ---
Created an attachment (id=14646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14646action=view)
code to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34235
From
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01452.html
FAIL: libgomp.fortran/character1.f90 -O0 (internal compiler error)
FAIL: libgomp.fortran/character1.f90 -O0 (test for excess errors)
WARNING: libgomp.fortran/character1.f90 -O0 compilation failed to produce
executable
...
--- Comment #4 from fgccbz1 at greynode dot net 2007-11-27 12:12 ---
Oh - and thanks for looking at my bug!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34235
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-27 12:19 ---
Works on x86-64 with -m64, but fails with -m32.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
I tried to find without success a simular bug with CHARACTER(*) function :
Files test5.f90 :
FUNCTION ctbgt() RESULT(ctab)
CHARACTER(*) :: ctab
END
[EMAIL PROTECTED]:~/test$ gfortran -c test5.f90
test5.f90: In function 'ctbgt':
test5.f90:2: internal compiler error: Segmentation fault
Please
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-27 12:31 ---
Testcase in C:
/* PR tree-optimization/34016 */
/* { dg-do compile } */
/* { dg-options -O2 -ftree-loop-linear } */
extern void bar (double *);
void foo (void)
{
double gr[36];
int i, j;
for (i = 0; i = 5;
I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c
-O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE
-fno-show-column -lm -o
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-27 12:38 ---
Valgrind finds:
==26293== Use of uninitialised value of size 4
==26293==at 0x80485D5: returnA (bind_c_usage_16.f03:14)
==26293== Bad permissions for mapped region at address 0x8048B10
==26293==at 0x80485C1:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-27 12:49 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from hjl at lucon dot org 2007-11-27 12:49 ---
This testcase doesn't work on Linux/x86-64.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-27 12:50 ---
Fixed with r130465:
./cc1plus -quiet /tmp/t.ii
t.C: In function 'int isnan(T) [with T = std::basic_stringchar,
std::char_traitschar, std::allocatorchar ]':
t.C:11: instantiated from here
t.C:6: error:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-27 13:00 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-27 13:01 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-11-27 13:01 ---
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34240
--- Comment #16 from michael dot a dot richmond at nasa dot gov 2007-11-27
13:08 ---
I am running the i386 version of FreeBSD 6.2. I compiled gcc myself. The only
reference to lgammaf in libgfortran/config.h is:
490:/* libm includes lgammaf */
libgfortran/config.log contains the
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-27 13:12 ---
I have a patch. The expected result is to optimize
bb 2:
a.1_1 = (struct A *) a;
change_dynamic_type (struct A *) a.1_1)
D.1744_2 = a.1_1;
iftmp.0_3 = (struct A *) D.1744_2;
if (iftmp.0_3 != 0B)
goto
--- Comment #1 from hjl at lucon dot org 2007-11-27 13:20 ---
Revision 130371:
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00566.html
is the cause.
--
hjl at lucon dot org changed:
What|Removed |Added
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rask at gcc dot gnu dot org
|dot org
--- Comment #1 from pault at gcc dot gnu dot org 2007-11-27 13:48 ---
Confirmed.
gcc-4.2.0 20061221 (prerelease) gives
FUNCTION ctbgt() RESULT(ctab)
1
Warning: CHARACTER(*) function 'ctbgt' at (1) is obsolescent in fortran 95
pr34248.f90: In function 'ctbgt':
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org
|dot org
--- Comment #3 from rguenther at suse dot de 2007-11-27 14:04 ---
Subject: Re: [4.3 Regression] VRP/SCEV miscompiles
Firefox
On Tue, 27 Nov 2007, rakdver at gcc dot gnu dot org wrote:
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-11-27 13:57
---
I will have a
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-27 14:06 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-11-27 13:57 ---
I will have a look. What target is this on, and what flags are used for
compilation?
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from manu at gcc dot gnu dot org 2007-11-27 13:57 ---
Can someone suggest a better comment for this?
/* Since this diagnostic is mandated by the standard, with -pedantic we
diagnose
different parameters spellings even if the macro expansion has no tokens.
*/
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2007-11-27
14:22 ---
Does anyone have access to other platforms to see if blocktest_data breaks when
compiled with gfortran on anything other than Darwin and Cywin?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
--- Comment #2 from tom_francen at midtechcorp dot com 2007-11-27 14:30
---
thanks ... i'm using sunfreeware.com's latest version of GMP (4.2.1) and MPFR's
2.3.0 (plus the latest downloaded patches) ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34207
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-27 14:17 ---
I've changed that
+ if (gimplify_ctxp-allow_rhs_cond_expr
+!TREE_SIDE_EFFECTS (*expr_p)
+expression_without_side_effects_p (*expr_p))
+ return gimplify_pure_cond_expr (expr_p,
--- Comment #17 from kargl at gcc dot gnu dot org 2007-11-27 15:00 ---
(In reply to comment #16)
I am running the i386 version of FreeBSD 6.2. I compiled gcc myself. The only
reference to lgammaf in libgfortran/config.h is:
490:/* libm includes lgammaf */
libgfortran/config.log
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-27 15:01 ---
Subject: Bug 34241
Author: rguenth
Date: Tue Nov 27 15:00:37 2007
New Revision: 130468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130468
Log:
2007-11-27 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-27 15:01 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
15:04 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-27 14:17 ---
I've changed that
+ if
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-27 15:28 ---
Subject: Bug 34225
Author: jakub
Date: Tue Nov 27 15:28:07 2007
New Revision: 130470
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130470
Log:
PR target/34225
* config/rs6000/rs6000.c
--- Comment #18 from michael dot a dot richmond at nasa dot gov 2007-11-27
15:28 ---
I retrieve my source with the following commands:
wget --timestamping
ftp://ftp.mirrorservice.org/sites/sources.redhat.com/pub/gcc/snapshots/4.3-20071123/gcc-core-4.3-20071123.tar.bz2
wget
--- Comment #2 from joseph at codesourcery dot com 2007-11-27 15:34 ---
Subject: Re: New: Missing __builtin_fpclassify
As previously discussed, this builtin would either need to be used in the
form
#define fpclassify(x) __builtin_fpclassify(FP_INFINITE, FP_NAN, FP_NORMAL,
--- Comment #4 from schneecrash+gcc-help at gmail dot com 2007-11-27 15:19
---
hi,
not just in 4.3, apparently ...
i'm seeing this same (?) issue on gcc 4.2.1 on osx 10.4.11 when building LIBSDL
... (fwiw, on OSX 10.5.11, all's OK)
i've
uname -a
Darwin
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-27 15:52 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at redhat dot com 2007-11-27 15:59 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
I think the problems only appeared if allow_rhs_cond_expr was enabled
for the gimplification pass (when called from the loop optimizer,
--- Comment #3 from pcarlini at suse dot de 2007-11-27 16:00 ---
(In reply to comment #2)
As previously discussed,
Didn't know about that. If you have a pointer, I would like to read the thread.
this builtin would either need to be used in the
form
--- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
16:03 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
I think the problems only appeared if allow_rhs_cond_expr was enabled
for the gimplification pass (when called from
--- Comment #4 from joseph at codesourcery dot com 2007-11-27 16:20 ---
Subject: Re: Missing __builtin_fpclassify
On Tue, 27 Nov 2007, pcarlini at suse dot de wrote:
As previously discussed,
Didn't know about that. If you have a pointer, I would like to read the
thread.
--- Comment #4 from pmendez at orga-systems dot com 2007-11-27 16:34
---
Right, -mptr64 should *never* be used. Just use -m64 as documented.
1.-where is this stated in the documentation?
2.-If it is a non supported option it should issue something like this
gcc: unrecognized
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-27 16:37 ---
I see. Though you probably shouldn't care about side effects in the first
argument of COND_EXPR, that's going to be evaluated in any case.
And for 2nd and 3rd argument wouldn't it for loop and vectorizer be
--- Comment #11 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
16:44 ---
Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME
object)
And for 2nd and 3rd argument wouldn't it for loop and vectorizer be sufficient
to just test is_gimple_val? I.e.
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-11-27 16:48 ---
as it may be zero, in case offset_46 is = 0.
Sebastian, Zdenek - any idea what goes wrong here?
# of iteration analysis records an assumption that offset_46 = 0. However,
this is simplified to true, as the
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-11-27 16:49
---
1.-where is this stated in the documentation?
-mptr64 is simply not documented.
2.-If it is a non supported option it should issue something like this
gcc: unrecognized option '-mptr64'
and not a wrong
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-11-27 17:00 ---
# of iteration analysis records an assumption that offset_46 = 0. However,
this is simplified to true, as the value range of offset_46 is set to [0,0] by
vrp (which seems to be wrong); so the problem is probably
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-27 17:24 ---
The problem is that repo_emit_p decides something needs to be emitted as if
-fno-repo was used, but import_export_decl then can just ignore it and not emit
it anyway (set import_p = true). When repo_emit_p said it
--- Comment #15 from burnus at gcc dot gnu dot org 2007-11-27 17:36 ---
(In reply to comment #13)
For testsub.f, g95 creates (for EXTERNAL BDTEST):
static void * U0 = bdtest_;
which shows up as:
U bdtest_
same for ifort. While sunf95 and openf95 have bdtest_ in
--- Comment #7 from rwgk at yahoo dot com 2007-11-27 17:43 ---
(In reply to comment #6)
Fixed.
Confirmed (yesterday with svn revision 130447).
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34233
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-27 18:04 ---
Created an attachment (id=14647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14647action=view)
Patch to enhance cse.c
The attached patch can optimize this testcase:
void foo (int);
int bar2 (int a, int b)
{
This was triggered by a patch of ours on the SLES10 compiler, which is 4.1.2
based. But it can be seen without any patches, for 4.1.x and trunk at least.
I'm sure the other compilers in between have the same problem, as the code
in the s390 backend is designed to error in these cases. Anyway, do
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-27 18:28 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01449.html
so you don't read the patches list.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-27 18:44 ---
Additionally, repo_emit_p should IMHO use DECL_INTEGRAL_CONSTANT_VAR_P
rather than DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P check - if a static
data member isn't const, then it really doesn't matter if it is
--- Comment #30 from mark at codesourcery dot com 2007-11-27 18:58 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
rguenth at gcc dot gnu dot org wrote:
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43
---
This is IMHO at
--- Comment #2 from matz at gcc dot gnu dot org 2007-11-27 19:05 ---
For reference, the internal one is at
https://bugzilla.novell.com/show_bug.cgi?id=344299
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
--- Comment #1 from matz at gcc dot gnu dot org 2007-11-27 19:02 ---
Created an attachment (id=14648)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14648action=view)
fix for this
A potential fix for this problem, iterating over possibly multiple constant
refs. Shouldn't have much
--- Comment #31 from bunk at stusta dot de 2007-11-27 19:16 ---
(In reply to comment #29)
This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64
parameter as volatile to work around this issue. I expect upstream to adopt
a workaround as well. Note that some
--- Comment #4 from pault at gcc dot gnu dot org 2007-11-27 19:22 ---
Subject: Bug 34231
Author: pault
Date: Tue Nov 27 19:21:52 2007
New Revision: 130471
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130471
Log:
2007-11-27 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #13 from pault at gcc dot gnu dot org 2007-11-27 19:22 ---
Subject: Bug 33541
Author: pault
Date: Tue Nov 27 19:21:52 2007
New Revision: 130471
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130471
Log:
2007-11-27 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from drow at gcc dot gnu dot org 2007-11-27 19:27 ---
Probably. Why are you using the iwmmxt ABI? Don't. Just trust the AAPCS, it
knows what's good for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
--- Comment #32 from bunk at stusta dot de 2007-11-27 19:31 ---
(In reply to comment #30)
...
I am not a kernel developer, but my feeling as a GCC developer is that
you must provide the entry points in libgcc whenever you are linking
code compiled with GCC. In other words, that GCC
--- Comment #33 from rakdver at kam dot mff dot cuni dot cz 2007-11-27
19:42 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43
---
This is IMHO at most a QOI issue - at
--- Comment #19 from kargl at gcc dot gnu dot org 2007-11-27 19:42 ---
Michael,
I found a part of the problem. First, I grabbed the tarballs
you specified and built gcc/gfortran in a directory as you
stated. The reason I did not see a problem previously is
because I always add
--- Comment #34 from jakub at gcc dot gnu dot org 2007-11-27 19:43 ---
I certainly agree with Mark here, we can talk whether on a particular arch
with particular options this transformation is a win or not, but when the
kernel
people decide to implement libgcc on their own and
--- Comment #35 from mark at codesourcery dot com 2007-11-27 19:45 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
bunk at stusta dot de wrote:
Even if this specific issue in the kernel would turn out as a misoptimization,
the general problem would
--- Comment #6 from aldot at gcc dot gnu dot org 2007-11-27 19:48 ---
I ment to build with arch=tune=abi for iwmmxt
As you say, arm.c suggests that iwmmxt defaults to -fshort-enums here, fwiw:
/* AAPCS based ABIs use short enums by default. */
static bool
arm_default_short_enums
--- Comment #7 from aldot at gcc dot gnu dot org 2007-11-27 20:15 ---
s/int//. The enumerated type is implementation defined but shall be capable to
represent the values of all members.
I'd read this as -fshort-enum violating that :16?
--
--- Comment #4 from simartin at gcc dot gnu dot org 2007-11-27 20:26
---
Patch submitted here: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01404.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
--- Comment #20 from kargl at gcc dot gnu dot org 2007-11-27 20:28 ---
OK, I've found the problem. tgammaf has not been added to
gfortran.map. I suspect that there may be other symbols
missing from gfortran.map. Unfortunately, I don't know
enough about symbol versioning to determine
--- Comment #3 from pault at gcc dot gnu dot org 2007-11-27 20:48 ---
Subject: Bug 33850
Author: pault
Date: Tue Nov 27 20:47:55 2007
New Revision: 130472
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130472
Log:
2007-11-27 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pault at gcc dot gnu dot org 2007-11-27 20:48 ---
Subject: Bug 29389
Author: pault
Date: Tue Nov 27 20:47:55 2007
New Revision: 130472
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130472
Log:
2007-11-27 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from dominiq at lps dot ens dot fr 2007-11-27 20:49 ---
Works for me on Intel Darwin9, but fails with default (-m32) on ppc Darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
--- Comment #14 from pault at gcc dot gnu dot org 2007-11-27 20:50 ---
Fixed on trunk I hope!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2007-11-27 20:51 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pault at gcc dot gnu dot org 2007-11-27 20:52 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-27 20:53 ---
I think your proposed fix sounds ok.
I don't have a copy of the C++ standard handy.
Does this bug apply to both C and C++, or only C?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
--- Comment #4 from pault at gcc dot gnu dot org 2007-11-27 20:54 ---
Fixed on trunk.
Paul
PS Note the need to get the kind right for the index vector in order to
eliminate the temporary.
--
pault at gcc dot gnu dot org changed:
What|Removed
Hello,
I have following output from the compiler for attached testcase:
gcc -c items.adb -gnat05
items.adb:11:21: expected type
System.Finalization_Implementation.Limited_Record_Controller
items.adb:11:21: found type
System.Finalization_Implementation.Record_Controller
This strange diagnosis
--- Comment #1 from vgodunko at rostel dot ru 2007-11-27 21:08 ---
Created an attachment (id=14649)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14649action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34251
--- Comment #4 from dominiq at lps dot ens dot fr 2007-11-27 21:39 ---
Works for me on Intel Darwin9, but fails with default (-m32) on ppc Darwin9.
More precisely, works with both -m32 and -m64 on Intel Darwin9, but fails with
both on ppc Darwin9.
--
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-27 21:50 ---
Subject: Bug 34181
Author: jakub
Date: Tue Nov 27 21:50:20 2007
New Revision: 130474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130474
Log:
PR tree-optimization/34181
* method.c (use_thunk):
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-11-27 21:51
---
(In reply to comment #20)
OK, I've found the problem. tgammaf has not been added to
gfortran.map.
Yuck. I should have remembered that :(
I don't know
enough about symbol versioning to determine if
--- Comment #2 from terry at chem dot gu dot se 2007-11-27 21:57 ---
(In reply to comment #1)
There is no bug here. You have explicitly disabled
range checking. This means that you no longer have
a limitation on range in constant folding. It may
be help to look at
1 - 100 of 164 matches
Mail list logo
