--- Comment #5 from hjl dot tools at gmail dot com 2008-01-20 07:53 ---
Revision 131671 is OK.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-01-20 07:01
---
Fixed:
Revision 131672 - (view) (download) - [select for diffs]
Modified Sun Jan 20 06:33:49 2008 UTC (26 minutes, 35 seconds ago) by jvdelisle
File length: 12184 byte(s)
Diff to previous 130805 (colored)
2008-0
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-20 06:49
---
Subject: Bug 34795
Author: jvdelisle
Date: Sun Jan 20 06:48:39 2008
New Revision: 131673
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131673
Log:
2008-01-20 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-01-20 06:49
---
Subject: Bug 34659
Author: jvdelisle
Date: Sun Jan 20 06:48:39 2008
New Revision: 131673
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131673
Log:
2008-01-20 Jerry DeLisle <[EMAIL PROTECTED]>
MYNAS:/home/src/trunk/rtorrent-0.7.9# gcc -v
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=pos
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-01-20 05:39 ---
Tomorrow after my extra checking build finishes, I will look into fixing this
bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 05:38 ---
(In reply to comment #2)
> 2.95 wrongly accepts this code, but doesn't ICE. So not a regression
> IMHO.
No it is a regression as anything (besides another ICE) to ICE is considered a
regression.I remember we pu
--- Comment #2 from ismail at pardus dot org dot tr 2008-01-20 04:57
---
--disable-padlock fixes the crash so the crashing part is the inline asm that
is under
#ifdef ENABLE_PADLOCK_SUPPORT .
--
ismail at pardus dot org dot tr changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-20 04:52 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The bootstrap fails at stage 3 for an up-to-date repo
The configure is:
../gcc/configure --prefix=/Users/ed/bin-4.3
--enable-languages=c,c++,objc,obj-c++,fortran,treelang
I do a search in the build directory and find:
MacOSX:~/obj-4.3 ed$ find . -name libgcc_s.10.4.\*
./powerpc-apple-darwin7.9.0/
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 04:19 ---
There is the issue, the testcase should be not run on your computer as it is
using SSE2. So this is a testsuite issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2008-01-20 04:17 ---
Subject: Re: fast-math-pr33299.f90 failure with illegal instruction due to
-ffast-math.
On Sun, Jan 20, 2008 at 04:09:19AM -, pinskia at gcc dot gnu dot org wrote:
>
> What instructions is ca
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 04:09 ---
What instructions is causing the crash?
Are you testing on a machine which has SSE2 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
gcc.c-torture/execute/float-floor.c depends on the target supporting an actual
64-bit double type.
Since the type "double" in the avr target is actually a 32-bit float, the test
always fails.
--
Summary: gcc.c-torture/execute/float-floor.c fails for targets
with n
--- Comment #4 from pmarques at grupopie dot com 2008-01-20 03:41 ---
gcc.c-torture/execute/ffs-1.c and gcc.c-torture/execute/ffs-2.c also fail with
this message. The test case gcc.c-torture/execute/builtin-bitops-1.c shows some
more similar errors:
builtin-bitops-1.c:(.text+0x6b4): un
The test case is gcc.c-torture/execute/built-in-setjmp.c.
The __builtin_setjmp stores Y+1 in the setjmp buffer. With -O0 the first
instruction after the jmp does a "sbiw r28, 1" that restores the
original value, but for some reason, with higher optimization levels,
this instruction is optimized aw
--- Comment #4 from hjl dot tools at gmail dot com 2008-01-20 03:06 ---
Revision 131671 passed the last failure point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-20 02:56
---
Here is a reduced case that illustrates the problem. Not specifying the
negative stride in either the read or write results in a failure. See the
commented lines.
program qi0011
character(9) bda(10)
--- Comment #4 from kargl at gcc dot gnu dot org 2008-01-20 02:20 ---
Just a quick note. The bug is not present on i386-*-freebsd, but is
present on x86_64-*-*freebsd. This is most likely a 32-bit versus
64-bit pointer issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
Bootstrap of revision 131654. Testsuite has one failure.
Executing on host: /home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran
-B/home/kargl/gcc/obj4x/
gcc/testsuite/gfortran/../../
/home/kargl/gcc/gcc4x/gcc/testsuite/gfortran.dg/vect/fast-math-pr33299.f9
0 -O2 -ftree-vectorize -fno-v
--- Comment #58 from zadeck at naturalbridge dot com 2008-01-20 02:13
---
The three patches that have been committed seem to have brought this under
control.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 01:49 ---
This is accepted for the same reason why the code you have is accepted:
std::cout << max(3u, -1) << std::endl;
If we write the second max as:
template T max( T a, T b, Args... args )
{
return a > max(b, a
--- Comment #59 from zadeck at gcc dot gnu dot org 2008-01-20 01:49 ---
Subject: Bug 26854
Author: zadeck
Date: Sun Jan 20 01:48:25 2008
New Revision: 131670
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131670
Log:
2008-01-19 Kenneth Zadeck <[EMAIL PROTECTED]>
PR rtl
--- Comment #57 from zadeck at gcc dot gnu dot org 2008-01-20 01:49 ---
Subject: Bug 34400
Author: zadeck
Date: Sun Jan 20 01:48:25 2008
New Revision: 131670
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131670
Log:
2008-01-19 Kenneth Zadeck <[EMAIL PROTECTED]>
PR rtl
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-20 01:47 ---
*** Bug 34874 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 01:47 ---
Sorry Kenny I forgot to say we already have a bug report about this, PR 34472.
*** This bug has been marked as a duplicate of 34472 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 01:46 ---
I think this is valid code as you specify max(b, args...) which means the
type for the first template argument will be unsigned so it will convert the
second argument to unsigned int.
Isn't that correct?
--
htt
--- Comment #2 from zadeck at naturalbridge dot com 2008-01-20 01:43
---
actually the commit for 34400 does not seem to effect this bug.
but the bug does have that nice heisenbug quality to it.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34874
consider template T max( T a, T b, Args... args
);
template T max( T a)
{
return a;
}
template T max( T a, T b, Args... args )
{
return a > max(b, args...) ? a : max(b, args...);
}
#include
int main()
{
std::cout << max(3u, 2u, -1) << std::endl;
}
Guess, what it prints: 4294967
--- Comment #4 from dick dot hendrickson at gmail dot com 2008-01-20 01:21
---
Subject: Re: ICE in function with entry (and result?)
Sorry, basically a typo on my part. This is part of a large test suite and I
cut it down to a small case. The "variable" NF3 has the value 3 and the
v
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 00:54 ---
How did you configure GCC? How exactly did you invoke make?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 00:54 ---
I built last night with revision 131650 with -j3 and it worked.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-01-20 00:49 ---
If confirmed, this is a serious regression.
Is the "make -j 4" command at toplevel in a newly configured clean build tree
(not a build tree previously built with an older version of the sources, for
example)?
--
--- Comment #14 from rsandifo at gcc dot gnu dot org 2008-01-20 00:08
---
Fixed.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #13 from rsandifo at gcc dot gnu dot org 2008-01-20 00:05
---
Subject: Bug 34831
Author: rsandifo
Date: Sun Jan 20 00:05:07 2008
New Revision: 131662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131662
Log:
gcc/
PR target/34831
* config/mips/mips.m
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-01-19 22:52 ---
Fixed. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-19 22:51 ---
Fixed. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-01-19 22:48 ---
Subject: Bug 34838
Author: tkoenig
Date: Sat Jan 19 22:47:47 2008
New Revision: 131660
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131660
Log:
2008-01-19 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-19 22:48 ---
Subject: Bug 34817
Author: tkoenig
Date: Sat Jan 19 22:47:47 2008
New Revision: 131660
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131660
Log:
2008-01-19 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from rbuergel at web dot de 2008-01-19 22:38 ---
another testcase:
template class Comp, typename... T> void f( T... Value)
{
static_assert( Comp::value > 0, "" );
}
template
struct Foo
{
static const int value=1;
};
int main()
{
f( 2 );
}
--
http
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-19 21:38 ---
>From FSFChangelog.10:
Mon Feb 12 20:42:11 1996 Randy Smith <[EMAIL PROTECTED]>
* i386/x-osfrose (XCFLAGS{,_NODEBUG}): Remove $(SHLIB).
(XCFLAGS): New variable.
(libdir, mandir, bindir): Dele
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-19 21:21
---
I will check into this one while I am at it as well
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-19 21:06
---
I will have a look.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
As
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
St
The following program prints READ FAILED. A similar program
with an unformatted, rather than direct access, file also fails.
Dick Hendrickson
Program qi0011
CHARACTER(9) BDA(10)
CHARACTER(9) BDA1(10)
INTEGER J_LEN
ISTAT = -314
INQUIRE(IOLENGTH = J_LEN) BDA1
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-19 20:49 ---
I can reproduce it on x86-64-linux. The first error valgrind shows is
==25404== Invalid read of size 8
==25404==at 0x44361B: gfc_match_common (match.c:2756)
==25404==by 0x4522B9: match_word (parse.c:64)
That
With compiler
4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)
vector valued reads into an array don't appear to read in values.
The test program prints out
kind of qda =4
vector valued read failed
1 -100.00 1.
2 -100.00 2.0
--- Comment #6 from pcarlini at suse dot de 2008-01-19 20:24 ---
This is not a bug, and already spuriously reported: yu *cannot* use
-D_GLIBCXX_FULLY_DYNAMIC_STRING, it's completely unsupported and not described
anywhere in the documentation. You can only completely rebuild the library w
--- Comment #1 from zadeck at naturalbridge dot com 2008-01-19 20:13
---
I am about to commit the last fix to p34400 and at least on my machine, this
patch will make this failure disappear from the test suite. however the bug is
still there if you look with valgrind.
pinskia, i am s
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)
valgrind --tool=memcheck --db-attach=yes --error-limit=no
/home/zadeck/gbB2/gcc/cc1 -fpreprocessed wo_prof_malloc_size_var.i -quiet
-dumpbase wo_prof_ma
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 19:47 ---
Further debug:
Breakpoint 2, resolve_common_blocks (common_root=0x40d02c50) at
../../gcc-4.3-work/gcc/fortran/resolve.c:692
692 {
(gdb) c
Continuing.
Breakpoint 3, resolve_common_vars (sym=0x40d06f50, named_comm
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 18:42 ---
Is really "SIZE(IDA2,NF3)" done on purpose? or is this a typo for
"SIZE(IDA2,3)"? It does not change the ICE AFAICT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-19
18:36 ---
Subject: Re: [4.3 regression] ICE with invalid variadic template functions
> I also see the ICE reported in comment #12 on hppa-unknown-linux-gnu.
Sorry, comment #7.
Dave
--
http://gcc.gnu.org/bugz
--- Comment #12 from danglin at gcc dot gnu dot org 2008-01-19 18:33
---
I also see the ICE reported in comment #12 on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-19 18:09 ---
It fails in array.c's
compare_bounds (gfc_expr *bound1, gfc_expr *bound2)
{
if (bound1 == NULL || bound2 == NULL
|| bound1->expr_type != EXPR_CONSTANT
|| bound2->expr_type != EXPR_CONSTANT
|| bound
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-19 18:06 ---
I'm closing because the original reporter could not reproduce.
If you think this is in error, post a note here and I will reopen this.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-19 18:04 ---
Why is a Fortran FE bug considered P2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34817
--- Comment #2 from tbptbp at gmail dot com 2008-01-19 17:56 ---
Gah. Seems that i've managed to hit another issue than what i was after with my
simplistic testcase then, because in the original code there's no array
anywhere - but static definitions - and i get calls to ldexpf (at runti
--- Comment #12 from jakub at gcc dot gnu dot org 2008-01-19 17:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
/usr/bin/gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc
-I/there.pentium4/toolchain_
--- Comment #11 from jakub at gcc dot gnu dot org 2008-01-19 17:50 ---
Subject: Bug 34610
Author: jakub
Date: Sat Jan 19 17:49:46 2008
New Revision: 131653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131653
Log:
PR gcov-profile/34610
* tree-cfg.c (make_edges):
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-01-19 17:48 ---
I'm 95% certain this was caused by my patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-19 17:47
---
On x86-64 linux using valgrind:
==2713== Invalid read of size 8
==2713==at 0x45C16C: resolve_common_vars (resolve.c:657)
and
==2713== Invalid read of size 1
==2713==at 0x45C230: resolve_common_vars (re
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:33
---
Reproduced on powerpc-apple-darwin9.1.0, both with -m32 and -m64. It happens
with stabs, but not with dwarf.
$ gfortran -gstabs test.f -g -m32
can't find atom for N_GSYM stabs nrange:G(0,5) in /var/tmp//cco3n4ye.
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:25
---
(In reply to comment #5)
> I do not have a strong feeling about it, and I would accept it if you
> propose to close this issue.
[...]
> A "-ffake-lack-of-integer-kind-1 option" would have made it easier to
> resol
--- Comment #6 from bkorb at gnu dot org 2008-01-19 17:23 ---
fixincludes has nothing to do with fixproto, other than both working
with fixing up headers and having names that start with "fix". So,
I know little about it and even less about canadian crosses. "fix-header"
also starts wi
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-19 17:21 ---
Some debuging (this as fas as I can go on my own):
note the line
5: csym->value = (struct gfc_expr *) warning: Got an error handling event:
"Cannot access memory at
for the case that does not crash.
(gdb) run 1234
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:20
---
Works for me with a more recent version (version 4.3.0 20071231), on my MacOS
10.4.11/Intel Core Duo, so I'm closing this as fixed.
Could you try to update your compiler (see
http://gcc.gnu.org/wiki/GFortranBinar
--- Comment #6 from jvdelisle at verizon dot net 2008-01-19 17:20 ---
Subject: Re: Formatted write of float broken (mingw32)
fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:12
> ---
> (In reply to comment #4)
>> Rep
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-19 17:13 ---
FIXED on the trunk (4.3.0).
Thanks for the bug report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:12
---
(In reply to comment #4)
> Reply to comment #2: I will update and see if that fixes it. Thanks Danny
I'm closing this: I have built new binaries and I still don't this it. Jerry,
if updating doesn't fix it, ple
21.3821.41
-mfpmath=387 20.73 20.6420.69
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU X6800 @ 2.93GHz
stepping: 5
cpu MHz : 2933.422
cache size : 4096 KB
gcc version 4.3.0
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-19 16:03 ---
Confirm. I think it is a fallout of Paul's typespec patch (PR 34429 et alia).
In resolve_branch (which prints the error message), label->defined ==
ST_LABEL_BAD_TARGET.
The problem is probably that ST_GET_FCN_CHARAC
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-19 15:41 ---
Subject: Bug 34760
Author: burnus
Date: Sat Jan 19 15:41:04 2008
New Revision: 131652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131652
Log:
2008-01-19 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
When I compile the function listed below using the January 18 snapshot of
gfortran, I get the following error:
t.f90:2.2:
10 CONTINUE
1
t.f90:3.7:
GOTO 10
2
Error: Statement at (1) is not a valid branch target statement for the branch
statement at (2)
I believe it applies to all platform
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-19 15:31
---
Not that this reference is always right, but Metcalf, Reid, and Cohen state:
direct=dir where dir "... are character variables that are assigned the value
YES, NO, or UNKNOWN, depending on whether the file may be
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-19 14:16 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00236.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-19 14:14 ---
Assuming build=i386-linux-*, host==target==sh4-linux-*, i.e. cross-compiling a
native compiler for SuperH:
-) sh*-* forces use_fixproto in config.gcc (why?)
See config.gcc: line 2308
-) stmp-install-fixproto: fixp
--- Comment #56 from zadeck at naturalbridge dot com 2008-01-19 13:09
---
Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions
Let me commit the patch first.
Sent from my iPod
On Jan 19, 2008, at 4:41 AM, "steven at gcc dot gnu dot org"
<[EMAIL PROTECTED]
>
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-19 12:47
---
OK, I understand, thank you.
Closing it then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-19 12:43 ---
Without -ff2c, gfortran uses (-fdump-tree-original):
complex(kind=8) __result_f;
__result_f = __complex__ (0.0, 0.0);
but for -ff2c it looks odd:
f (a)
{
complex(kind=8) __result_f;
*__result_f = 0.0;
ret
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-19 12:37 ---
Bruce,
Can you please have a look. How is that ment to work?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-19 12:11 ---
complex(kind=8) __result_f;
*__result_f = 0.0;
return __result_f;
:)
Well that is obviously wrong.
Also is there a reason why you are using -ff2c anyways? It does change the ABI
slightly.
--
pinskia a
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-19 12:08 ---
Well with x86_64, PIC addressing global variables is simpler as you have access
to the rip register. Try this on any other target, you will get a rejection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-19 12:07 ---
Oh, in C++, const_var is a constant integral expression after all so that is
why it is accepted with C++ front-end, I had forgot the exact rules for C++ for
a second there.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-19 12:04 ---
It is constant folded but not until after inlining.
A simplier example is:
static inline int f(int a)
{
return a+2;
}
int g(int a)
{
const int b[] = {f(1), f(2), f(3) };
return b[a];
}
int g1(int a)
{
const
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-19 12:03 ---
Does the regression on C2 duo show even without vectorizing? It looks like
generic SSE fpmath performance issue. There should be no reason why SSE math
in combination with SSE vectorization should result in regress
MODULE TESTS
dimension :: k(4)
CONTAINS
function k()
k = 35
end function k
END MODULE
is invalid (variable "k" vs. function "k"), but not detected.
Needs to be fixed in decl.c's get_proc_name; I have a patch, but it causes
regressions
--
Summary: Fl
--- Comment #1 from dragan at plusplus dot co dot yu 2008-01-19 11:39
---
Created an attachment (id=14974)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14974&action=view)
a simple test case (the same as in the bug description)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
This code should be legal:
template
struct Foo
{
template
friend void func(const Foo &) {}
};
void check(const Foo & x)
{
// Foo weird; // uncomment this line and all works
func(x);// <-- GCC issues an ERROR
}
After a brief discussion on [EMAIL PROTECTED], it has been con
1 - 100 of 114 matches
Mail list logo
