--- Comment #7 from dominiq at lps dot ens dot fr 2007-11-13 08:01 ---
Created an attachment (id=14539)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14539&action=view)
"Good" assembly code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
--- Comment #9 from dominiq at lps dot ens dot fr 2007-11-13 08:10 ---
> and the from the debugger which field of the array caused the abort and maybe
> even good
> and bad char_cshift_2.*.fwprop* dumps? Can you hit breakpoint on
> _gfortran_cshift1_4_char
> and _gfortran_cshift1_8_
--- Comment #8 from dominiq at lps dot ens dot fr 2007-11-13 08:02 ---
Created an attachment (id=14540)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14540&action=view)
"Bad" assembly code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
--- Comment #10 from bonzini at gnu dot org 2007-11-13 08:16 ---
Anyway, it looks like a latent bug somewhere else.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #11 from bonzini at gnu dot org 2007-11-13 08:21 ---
Since you are at it, could you test on *exactly* the involved revisions, i.e.
130042 and 130043?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
--- Comment #6 from tbm at cyrius dot com 2007-11-13 08:27 ---
So I guess this can be closed?
--
tbm at cyrius dot com changed:
What|Removed |Added
CC|
--- Comment #8 from tbm at cyrius dot com 2007-11-13 08:29 ---
Would be great if some IA64 people could comment on the patch.
--
tbm at cyrius dot com changed:
What|Removed |Added
Using STDCALL, not the callee but the called procedure pops the arguments from
the stack. The problem is that gfortran currently also for BIND(C) passes the
string lengths as arguments.
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/19d77dfc75f8be58
--
--- Comment #12 from dominiq at lps dot ens dot fr 2007-11-13 08:42 ---
Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3
-funroll-loops fails on Intel Darwin
> Since you are at it, could you test on *exactly* the involved revisions, i.e.
> 130042 and 130043?
--- Comment #3 from dominiq at lps dot ens dot fr 2007-11-13 08:52 ---
The patch works as advertised without regression on both PPC and Intel Darwin8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34008
I have code that was previously working with gfortran and now is broken. The
problem has to do with the 'transfer' intrinsic. If I transfer a character
string into an array of a different type, and then transfer the array back to a
string, the result is not the original string, but apparently rando
gcc -v
Using built-in specs.
Target: s390x-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java
--enable-checking=release
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-13 10:00 ---
Created an attachment (id=14541)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14541&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34081
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-13 10:19 ---
I think ix86_expand_movemem should not call emit_cmp_and_jump_insns with
constant
tests.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from dominiq at lps dot ens dot fr 2007-11-13 10:40 ---
Created an attachment (id=14542)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14542&action=view)
Comparison between revisions 130042 and 130043 with -O2 -funroll-loops and with
-O1+all the others
bzip2 tar ar
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 10:26 ---
Either we should use correct order of arguments in chrec_evaluate (that
function
is swapping CHREC_LEFT based expression with CHREC_RIGHT based expression
for pointer_plus addition) - testing patch for that - or chrec_
--- Comment #14 from dominiq at lps dot ens dot fr 2007-11-13 10:41 ---
Could you try to "compile" the assembly code in r43_O2 and see if you get the
abort?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 11:38 ---
Mine.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-11-13
11:43 ---
Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90
fails with -O3 -funroll-loops fails on Intel Darwin
> bzip2 tar archive with four directories r42_O1, r42_O2, r43_O1, and r43_O2
> containin
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 12:12 ---
The set_packs_to_error stuff is very problematic in this case, because
trees are shared and the C++ FE certainly doesn't expect error_mark_nodes
to appear at random places.
In this case T* type is shared (as the pointe
--- Comment #12 from victork at gcc dot gnu dot org 2007-11-13 12:26
---
> Still fails on 4.2 branch.
I've just tried with 4.2 on PPC from svn and it did not ICE:
./gcc/cc1plus -O3 -ftree-vectorize -maltivec ~/42/build/pr27549.C
Can we close this PR?
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-13 12:28
---
(In reply to comment #4)
> __builtin_copysign has got SFmode(*)(SFmode, SFmode) prototype and is invoked
> on DFmode arguments.
copysign takes doubles and returns a double. Does the SH double have SF mode in
the
--- Comment #10 from pault at gcc dot gnu dot org 2007-11-13 12:46 ---
(In reply to comment #9)
> > This patch is OK.
> Yes indeed, I have applied it a long time ago.
As I found out minutes after I posted this note - thanks!
> I have only pointed to the last bug on transfer I know of.
--- Comment #16 from dominiq at lps dot ens dot fr 2007-11-13 13:18 ---
> Also, please check if the bug appears disappears with
> -O2 -fno-forward-propagate -funroll-loops
It disappears with -fno-forward-propagate (rev 130043).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34067
--- Comment #13 from victork at gcc dot gnu dot org 2007-11-13 13:26
---
I've just tested it with 4.2 on x86 on it worked OK as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
--- Comment #7 from dorit at gcc dot gnu dot org 2007-11-13 13:29 ---
fixed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from p dot vestjens at gmail dot com 2007-11-13 13:38
---
Okay. First of all the code causing the problems isn't actually my own code. It
is used in the Connexis middleware layer of IBM's Rational Rose Real-Time
application. The reproduce.cpp file was created by IBM's sup
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 13:43 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 13:44 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 13:44 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-13 13:44 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #17 from dominiq at lps dot ens dot fr 2007-11-13 13:46 ---
Created an attachment (id=14543)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14543&action=view)
outputs with -fdump-rtl-all
outputs with -fdump-rtl-all with -O2 -funroll-loops for revisions 130042 and
130043
--- Comment #36 from victork at gcc dot gnu dot org 2007-11-13 13:53
---
Subject: Bug 32582
Author: victork
Date: Tue Nov 13 13:53:33 2007
New Revision: 130138
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130138
Log:
2007-11-13 Victor Kaplansky <[EMAIL PROTECTED]>
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-13 13:55
---
Confirmed on x86_64-linux.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
someinfo
--
Summary: someinfo
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: libf2c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim3 at iq17 dot co
--- Comment #1 from jim3 at iq17 dot com 2007-11-13 14:32 ---
aa
--
jim3 at iq17 dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESO
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-13 14:39 ---
Example:
interface
subroutine subiso(x) bind(c)
use iso_c_binding
character(kind=c_char,len=1), dimension(*) :: x
end subroutine subiso
subroutine subiso2(x) bind(c) ! { dg-warning "may not be C interop
--- Comment #2 from dominiq at lps dot ens dot fr 2007-11-13 15:08 ---
Reduced test case:
module TransferBug
type ByteType
character(len=1) :: singleByte
end type
contains
subroutine BytesToString(bytes, string)
type (ByteType), i
While looking at pr34080, I produced the following invalid code
module TransferBug
type ByteType
character(len=1) :: singleByte
end type
end module
program main
use TransferBug
type (ByteType) :: bytes(4)
pr
--- Comment #23 from dnovillo at gcc dot gnu dot org 2007-11-13 15:20
---
Subject: Bug 33870
Author: dnovillo
Date: Tue Nov 13 15:20:40 2007
New Revision: 130141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130141
Log:
pr 33870
* tree.h (strcut tree_memory_ta
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-13 15:44 ---
Confirmed. NAG f95 reports:
Error: aa.f90, line 13: Array value for scalar component SINGLEBYTE of type
BYTETYPE
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from dnovillo at gcc dot gnu dot org 2007-11-13 15:47
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00719.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-13 15:51 ---
I did not do proper regression tests, but it works using
4.3.0 20071016 (experimental) [trunk revision 129378] (SUSE Linux)
which has presumably no Fortran patches applied.
--
burnus at gcc dot gnu dot org chang
--- Comment #18 from jakub at gcc dot gnu dot org 2007-11-13 15:57 ---
Is this still reproduceable with current trunk?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
--- Comment #18 from dominiq at lps dot ens dot fr 2007-11-13 15:58 ---
At revision 130137 the minimal flags are:
[ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fschedule-insns -fregmove
-fexpensive-optimizations -fforward-propagate
char_cshift_2_red_1.f90[ibook-dhum] f90/bug% a.out
tes
.18 for
bootstrapping and configured the stuff as follows:
env CC=gcc CFLAGS=-O2 CXXFLAGS='-O2 -g' GCJFLAGS='-O2 -g' LDFLAGS=-s
/bin/sh ../gcc-20071113/configure --host=$config --target=$config
--build=$config
--srcdir=../gcc-20071113 --prefix=/opt/gnu --with-gnu-as --w
The following error occurs in the November 9 snapshot version of gfortran. It
applies to all platforms. I compile the following program:
INCLUDE 'anything'
PROGRAM test_cg
END PROGRAM test_cg
The INCLUDE file can contain anything. I get the message:
f951: internal compiler error: in end_source_f
--- Comment #19 from paolo dot bonzini at lu dot unisi dot ch 2007-11-13
16:46 ---
Subject: Re: [4.3 regression] gfortran.dg/char_cshift_2.f90
fails with -O3 -funroll-loops fails on Intel Darwin
> [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fschedule-insns -fregmove
> -fexpensive-
--
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
--- Comment #20 from dominiq at lps dot ens dot fr 2007-11-13 16:59 ---
Created an attachment (id=14544)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14544&action=view)
outputs of -fdump-rtl-all for two set of options at -O1
The folder r137_O1_insns corresponds to -fschedule-insn
--- Comment #5 from jsjodin at gcc dot gnu dot org 2007-11-13 17:07 ---
(In reply to comment #4)
> Related to PR 33790 (and most likely fixed by it). There is another issue
> with
> that bug relating to not deleting the extra store.
>
Indeed the extra load disappeared when with the p
--- Comment #1 from janis at gcc dot gnu dot org 2007-11-13 17:23 ---
The change on mainline from silently accepting the code to an ICE is due to
this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=117360
r117360 | mmitchel | 2006-10-02 04:12:30 + (Mon, 02 Oct 2006)
--
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-11-13 17:34 ---
(In reply to comment #3)
> Either we should use correct order of arguments in chrec_evaluate (that
> function
> is swapping CHREC_LEFT based expression with CHREC_RIGHT based expression
> for pointer_plus addition) -
--- Comment #29 from alexandre dot nunes at gmail dot com 2007-11-13 17:35
---
(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #25)
> [cut]
>
> Mark does not actually read the full list of messages when changing the target
> milestone. I think this should
--- Comment #30 from manu at gcc dot gnu dot org 2007-11-13 17:55 ---
(In reply to comment #29)
>
> It would be nice if this bug would get somehow documented on gcc manual or the
> main site before gcc 4.2.3 release.
I agree. But I am not sure how this is typically done (I am too newbi
When compiling the testacse attached with -O3 -fprofile-use
-freorder-blocks-and-partition flags, I get the following error: (I use the
profiling information given by first compiling with -fprofile-generate and than
running the executable)
tmp.c: In function âmainâ:
tmp.c:36: error: insn 186 outsi
--- Comment #1 from eres at il dot ibm dot com 2007-11-13 18:21 ---
Created an attachment (id=14545)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14545&action=view)
The testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-13 18:23 ---
Subject: Bug 34063
Author: jakub
Date: Tue Nov 13 18:23:03 2007
New Revision: 130151
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130151
Log:
PR tree-optimization/34063
* tree-chrec.c (chrec_
--- Comment #2 from steven at gcc dot gnu dot org 2007-11-13 18:24 ---
Can you please also attach your profile information and give the exact compiler
revision ID that you used to create that information? That way, people without
access to POWER can still help debug this problem.
--
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 ---
Subject: Bug 34057
Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 ---
Subject: Bug 34054
Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 ---
Subject: Bug 34058
Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-13 18:27 ---
Subject: Bug 34060
Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:27 ---
Subject: Bug 34056
Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:28 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-13 18:28 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:30 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:30 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from eres at il dot ibm dot com 2007-11-13 18:30 ---
Created an attachment (id=14546)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14546&action=view)
the testcase (please ignore the previous testcase it has been uploaded by
mistake)
--
http://gcc.gnu.org/bugzil
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-13 18:30 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-13 18:31 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from eres at il dot ibm dot com 2007-11-13 18:34 ---
(In reply to comment #2)
> Can you please also attach your profile information and give the exact
> compiler
> revision ID that you used to create that information? That way, people
> without
> access to POWER can sti
--- Comment #7 from gcc-bugzilla at contacts dot eelis dot net 2007-11-13
18:42 ---
(In reply to comment #6)
> The bug is that the C++ front end implicitly #defines _GNU_SOURCE.
> [..]
> Could some libstdc++ guru explain why this define is actually needed?
I am no libstdc++ guru, but
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-13
19:27 ---
Subject: Re: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related
verify_ssa failure
> Is this still reproduceable with current trunk?
As of last night, this still occurs on hppa2.0w-hp-hpux1
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-13 19:51 ---
I can reproduce this (if the included file is not empty).
FX, can you have a look? I would not be surprised if one of your debug patches
caused the regression:
anything:1: internal compiler error: in end_source_file
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-13 20:02 ---
Note: The patch above works, one only needs to check whether there is a memory
leak or something else which affects the generated tree.
Index: gcc/testsuite/gfortran.dg/bind_c_vars_2.f03
=
--- Comment #4 from pault at gcc dot gnu dot org 2007-11-13 20:07 ---
The regression occurred at r129505. Allowance was not made in the correction
to gfc_resolve_transfer for assumed size dummy arguments. This fixes it:
Index: /svn/trunk/gcc/fortran/iresolve.c
The following code crashes g++ 4.1.3 :
*START OF FILE**
#include
using namespace std;
double arctan(double x)
{
int i=1,n=20;
double c=1.0,arct=0.0,paf=1.0,eps=0.1,hab;
hab=(x/(1+x*x));
do
{
arct+=paf;
c+=2i/(2i+1);
pa
--- Comment #1 from nmaquet at gmail dot com 2007-11-13 20:13 ---
Created an attachment (id=14547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14547&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34086
--- Comment #2 from nmaquet at gmail dot com 2007-11-13 20:16 ---
I reported this on Launchpad a few weeks ago but it doesn't get much attention
:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.1/+bug/155259
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34086
--- Comment #5 from pault at gcc dot gnu dot org 2007-11-13 20:19 ---
Drew,
By the way - thanks!
The regression test is just coming to an end, so it'll be fixed very soon.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34080
--- Comment #6 from drewmccormack at mac dot com 2007-11-13 20:27 ---
Subject: Re: [4.3 regression] Transfer was working, now broken
Thanks for fixing it so quick, Paul.
Drew
On 13/11/2007, at 9:19 PM, pault at gcc dot gnu dot org wrote:
>
>
> --- Comment #5 from pault at gcc d
--- Comment #7 from pault at gcc dot gnu dot org 2007-11-13 20:33 ---
Subject: Bug 34080
Author: pault
Date: Tue Nov 13 20:33:21 2007
New Revision: 130158
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130158
Log:
2007-11-13 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from michael dot meissner at amd dot com 2007-11-13 20:48
---
Created an attachment (id=14548)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14548&action=view)
Patch to fix PR34077
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34077
The following attatchment from the cpu20006 benchmark leslie3d ICEs in the
following manner. The problem appears to be a latent bug that has come and gone
a couple times (I saw it earlier on the gamess benchmark too). Recent
mainlines compile it fine, but revision 128829 exhibits the problem. Ope
--- Comment #1 from pthaugen at gcc dot gnu dot org 2007-11-13 21:08
---
Created an attachment (id=14549)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14549&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34087
--- Comment #3 from fang at csl dot cornell dot edu 2007-11-13 21:12
---
4.0.1 (apple) ICEs:
pr34086.cc: In function 'double arctan(double)':
pr34086.cc:12: internal compiler error: in const_binop, at fold-const.c:1610
4.2.2 gives me:
pr34086.cc: In function 'double arctan(double)':
pr
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-13 21:18
---
(In reply to comment #1)
> FX, can you have a look? I would not be surprised if one of your debug patches
> caused the regression
Me neither. A simple workaround is to simply add a blank line before the
INCLUDE s
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-13 21:57 ---
This is not the first time something like this has shown up before.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The following valid code snippet triggers an ICE on mainline
when compiled with "gcc -O -Wall -Werror" on i686-pc-linux-gnu.
=
int F0 (int);
int F1 (int t) { return F0(t); }
int F2 (int t) { return F0(t); }
extern int X[];
static inline int foo(
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet||i686-pc-linux-gnu
GCC host triplet||i6
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-13 22:38 ---
Confirmed.
#1 0x084a545e in const_binop (code=TRUNC_DIV_EXPR, arg1=0xb7cec528,
arg2=0xb7cec720, notrunc=0)
at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:1640
1640default:
(gdb) l
1635
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-13 22:41 ---
I think this showed up when may_alias became a TODO.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-13 22:54 ---
(In reply to comment #3)
> So? Is the warning warranted?
Yes because va_list is not a first class type and never was and is very ABI
dependent.
> Can be worked-around?
Well no, because va_list's type is ABI depende
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-13 23:20 ---
Stephan, please, try with
my_func( "format string: %s", (char *)__FILE__ )
Otherwise, you can use -Wno-write-strings to avoid the warning or
-Wno-error=write-strings to get the warning as a warning even when using
-W
Attempting to compile the following file
template void foo() { };
template struct foo { };
results in
bug.c++:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GN
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-11-14 00:59
---
Subject: Bug 33162
Author: jvdelisle
Date: Wed Nov 14 00:59:09 2007
New Revision: 130168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130168
Log:
2007-11-11 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from janis at gcc dot gnu dot org 2007-11-14 01:02 ---
The ICE also occurs on powerpc-linux, where a regression hunt identified this
patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=120373
r120373 | hubicka | 2007-01-03 01:12:56 + (Wed, 03 Jan 2007)
--
htt
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2007-11-14 01:06
---
Subject: Bug 33162
Author: jvdelisle
Date: Wed Nov 14 01:06:13 2007
New Revision: 130169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130169
Log:
2007-11-13 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2007-11-14 01:17
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
1 - 100 of 120 matches
Mail list logo
