--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-21 07:41 ---
> Then the resultant C source is
>VOID f_(doublecomplex * ret_val, doublereal *a)
Indeed this is f2c (and g77 -ff2c) syntax.
> So it seems to me that the current functionality of the gfortran is different
> from
--- Comment #1 from oliver dot kellogg at eads dot com 2008-01-21 07:30
---
Created an attachment (id=14985)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14985&action=view)
source code for producing the bug
I tried this with gcc-4.1, 4.2, and 4.3.
If I remove the aggregate assi
For reference, here's a compile with gcc-3.3.5:
$ gcc -c -v pkg001u.adb
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-langu
--- Comment #24 from manu at gcc dot gnu dot org 2008-01-21 06:55 ---
(In reply to comment #23)
> It's too bad the bug is closed just as a duplicate of another bug.
I am sorry that you feel disappointed. I believed that the rationale behind
closing this was fairly clear. I tried to answ
>From the old version of gfortran.dg/mapping_2.f90
function my_string(x)
integer i
real, intent(in) :: x(:)
character(0) h4(1:minval([(1,i=1,0)],1)) ! If range is 1,0 bombs out.
character(0) sv1(size(x,1):size(h4))
character(0) sv2(2*lbound(sv1,1)
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-21 05:40 ---
Confirmed
This is the reduced version
! { dg-do run }
module reduction5
intrinsic min, max
end module reduction5
program reduction_5_regression
call test2
contains
subroutine test2
use reduction5, min =>
--- Comment #23 from sergstesh at yahoo dot com 2008-01-21 05:07 ---
It's too bad the bug is closed just as a duplicate of another bug.
The main points of this bug are:
1) the code triggering the bug uses undefined in "C" standards language
features - behavior in case of integer overfl
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-21 04:26 ---
Revision 131678 seems OK:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00926.html
It looks like revision 131679
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00925.html
is the cause.
--
http://gcc.gnu.org
On Linux/Intel64 and Linux/ia32, revision 131679 gives
FAIL: libgomp.fortran/reduction5.f90 -O0 execution test
FAIL: libgomp.fortran/reduction5.f90 -O1 execution test
FAIL: libgomp.fortran/reduction5.f90 -O2 execution test
FAIL: libgomp.fortran/reduction5.f90 -O3 -fomit-frame-pointer execu
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2008-01-21 03:15 ---
Created an attachment (id=14984)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14984&action=view)
The code that triggers the ICE
Just compile with -g -O2 to see the problem.
--
http:
The (soon to be attached) code ICEs when compiled with options -g -O2.
This is still true as of gcc version 4.3.0 20080118 (x86_64-unknown-linux-gnu),
it used to pass but I do not know if this was due to the use of a previous
version of the compiler (3.4) or the use of a i386 target (this is most
p
--- Comment #8 from hjl dot tools at gmail dot com 2008-01-21 03:09 ---
Add -ffloat-store seems to fix the problem. I will verify it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
--- Comment #4 from yamagen at coral dot t dot u-tokyo dot ac dot jp
2008-01-21 02:57 ---
Thank you very much for your comments.
First I answer to you why I would like to use -ff2c option.
The reason is that I would like to use "-framework vecLib".
In the URL
http://developer.apple
--- Comment #2 from pcarlini at suse dot de 2008-01-21 02:31 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at s
--- Comment #1 from paolo at gcc dot gnu dot org 2008-01-21 02:31 ---
Subject: Bug 34891
Author: paolo
Date: Mon Jan 21 02:30:31 2008
New Revision: 131687
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131687
Log:
/cp
2008-01-20 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from pmarques at grupopie dot com 2008-01-21 02:23 ---
Created an attachment (id=14983)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14983&action=view)
patch with possible fix
This patch fixes the test cases, by #ifndef'ing the relevant code when
NO_TRAMPOLINES is
When trying to run the testsuite for the avr target I get these failures from
gcc.c-torture/compile:
gcc.c-torture/compile/20010226-1.c:6: internal compiler error: trampolines not
supported
gcc.c-torture/compile/20050122-2.c:7: internal compiler error: trampolines not
supported
gcc.c-torture/compi
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #7 from mmitchel at gcc dot gnu dot org 2008-01-21 02:03
---
I agree that this should be a P2. I had misunderstood Andrew's earlier comment
to mean that we always got a valid error message before the ICE.
--
mmitchel at gcc dot gnu dot org changed:
What|
--- Comment #19 from mmitchel at gcc dot gnu dot org 2008-01-21 02:00
---
Lawrence, thanks for looking into this.
Was there any consensus on whether or not these are static_casts in this
context?
I'm guessing that the eventual resolution is going to be something like saying
that a c
--- Comment #4 from pcarlini at suse dot de 2008-01-21 01:52 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at s
--- Comment #5 from pcarlini at suse dot de 2008-01-21 01:52 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at s
--- Comment #4 from paolo at gcc dot gnu dot org 2008-01-21 01:50 ---
Subject: Bug 34486
Author: paolo
Date: Mon Jan 21 01:49:29 2008
New Revision: 131686
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131686
Log:
/cp
2008-01-20 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #3 from paolo at gcc dot gnu dot org 2008-01-21 01:50 ---
Subject: Bug 34776
Author: paolo
Date: Mon Jan 21 01:49:29 2008
New Revision: 131686
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131686
Log:
/cp
2008-01-20 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #22 from manu at gcc dot gnu dot org 2008-01-21 01:10 ---
"make check" failing is expected since there is undefined behaviour in the
program and we warn about it with -Wstrict-overflow=5 (I guess that we warn
with lower values as well, probably simply with -Wstrict-overflow).
--- Comment #9 from manu at gcc dot gnu dot org 2008-01-21 01:10 ---
*** Bug 34841 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-21
00:27 ---
Subject: Re: ICE: output_operand: invalid expression
as operand on hppa
> (gdb) p debug_rtx (insn)
> (code_label/s 1897 4221 1898 13722 ("*.LJpc=819954") [0 uses])
We are losing usage counts in re
--- Comment #10 from kkojima at gcc dot gnu dot org 2008-01-21 00:12
---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from kkojima at gcc dot gnu dot org 2008-01-21 00:05 ---
Subject: Bug 34808
Author: kkojima
Date: Mon Jan 21 00:04:23 2008
New Revision: 131680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131680
Log:
PR rtl-optimization/34808
* emit-rtl.c (try_s
--- Comment #4 from debian-gcc at lists dot debian dot org 2008-01-20
23:57 ---
seen as well with a sparc-linux-gnu compiler with -m64 (patched for a biarch
build ) with trunk 20080116
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33034
--- Comment #17 from zadeck at naturalbridge dot com 2008-01-20 23:27
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
steven at gcc dot gnu dot org wrote:
> --- Comment #16 from steven at gcc dot gnu dot org 2008-01-20 23:22
> ---
> I favor blowing away
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-20 23:22 ---
I favor blowing away the RD patch.
Having the LR problem (and probably the LIVE problem too?) always propagate the
REG_EQ* notes as if they were real uses sounds like a terrible idea to me.
They are not real uses a
--- Comment #15 from zadeck at naturalbridge dot com 2008-01-20 23:15
---
There appears to be an design inconsistency in the way that we have specified
the various dataflow problems with respect to the eq notes.
I hate eq notes.
In the rd patch that just went in where we trim the so
--- Comment #21 from sergstesh at yahoo dot com 2008-01-20 22:30 ---
Now that the flags are in this order: -Wall -Wstrict-overflow=5 :
a) the warnings during compilation:
"
[EMAIL
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep warn make.log
lpc.c:220:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 22:30 ---
*** This bug has been marked as a duplicate of 34886 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 22:30 ---
*** Bug 34893 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34886
--- Comment #5 from ed at catmur dot co dot uk 2008-01-20 22:28 ---
Created an attachment (id=14981)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14981&action=view)
gcc-cpp-Werror-message.patch
--
ed at catmur dot co dot uk changed:
What|Removed
--- Comment #4 from ed at catmur dot co dot uk 2008-01-20 22:20 ---
Created an attachment (id=14980)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14980&action=view)
gcc-cpp-Werror-message.patch
Also when preprocessing-only.
--
ed at catmur dot co dot uk changed:
W
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-20 22:19 ---
> - next_record (dtp, 0);
> + next_record (dtp, 1);
This causes a regression in x_slash_1.f . I'll dig around
some more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34887
On compiling that code:
--- begin code ---
class Y {};
void f(Y*) { } // line 3. If comment - all ok
template < typename T>
void sel(T* a) { f(a); } //line 6
void f(void*) {}
int main(int argc, char **argv)
{
sel((void*)0); //line 12
}
--- end code ---
Àppears error:
../main.cpp: In f
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|fortran |middle-end
Target Milestone|--- |4.3.0
ht
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 21:55 ---
GCC is correct here. Well partly. It should reject it no matter what.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34886
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-20 21:40 ---
(currently regtesting)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34887
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34892
The following invalid testcase triggers an ICE on mainline:
==
template struct A {};
A<0> a;
==
bug.cc:1: error: expected primary-expression before '...' token
bug.cc:3: internal compiler erro
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-20 21:39 ---
What about this one-character patch?
Index: transfer.c
===
--- transfer.c (revision 131679)
+++ transfer.c (working copy)
@@ -1308,7 +1308,7 @@ forma
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34891
A broken diagnostic ('view_convert_expr' not supported by dump_expr)
is issued for the following testcase since GCC 4.0.2:
==
typedef float v4f __attribute__((vector_size(8)));
typedef int v4i __attribute__((vector_size(8)));
void foo()
{
v4
--- Comment #2 from tbm at gcc dot gnu dot org 2008-01-20 21:21 ---
Fixed in SVN by Richard.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from tbm at cyrius dot com 2008-01-20 21:20 ---
This was fixed in SVN today, see
http://gcc.gnu.org/ml/gcc/2008-01/msg00308.html
--
tbm at cyrius dot com changed:
What|Removed |Added
--
--- Comment #38 from dominiq at lps dot ens dot fr 2008-01-20 20:47 ---
With patch form comments #11 and #31, the executable for
gcc.dg/struct/wo_prof_mult_field_peeling.c segfault with -m64. I have used the
32 bit mode for -fprofile-generate, run the executable, and use -m64 for
-fprofi
When I attempt to compile the 01/18/08 snapshot under Debian Linux 4.0 for mips
I get the following message:
/home/mrichmon/gcc-4.3-20080118/g95/./prev-gcc/xgcc
-B/home/mrichmon/gcc-4.3-20080118/g95/./prev-gcc/
-B/home/mrichmon/irun/mips-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W
-Wall -Wwri
--- Comment #6 from mark at codesourcery dot com 2008-01-20 20:28 ---
Subject: Re: [4.2/4.3 Regression] bit-fields, references and
overloads
aoliva at gcc dot gnu dot org wrote:
> --- Comment #5 from aoliva at gcc dot gnu dot org 2008-01-17 18:01
> ---
> Created an attachmen
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-20 20:18 ---
Reduced test case:
$ cat bug-4.f
program main
write (*,'(3X A, T1, A,/)') 'aa', 'bb'
end
$ gfortran bug-4.f && ./a.out
bb
$ g77 bug-4.f && ./a.out
bb aa
--
tkoenig at gcc dot gnu dot org chang
--- Comment #5 from mmitchel at gcc dot gnu dot org 2008-01-20 20:13
---
This is a known bug in the Itanium C++ ABI. ARM noticed this; there variant of
the C++ ABI has the additional is_reference parameter precisely to correctly
handle this case.
I looked at this in some detail at one
--- Comment #1 from pmarques at grupopie dot com 2008-01-20 19:39 ---
Created an attachment (id=14979)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14979&action=view)
the attached patch implements the proposed change
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34889
gcc.c-torture/execute/builtins/pr23484-chk.c has on line 44:
if (snprintf (buf, l1 ? sizeof (buf) : 4, "%d", l1 + 65536) != 5
|| memcmp (buf, "655\0", 8))
but on a 16 bit platform like the avr, the "l1 + 65536" overflows and gives the
wrong result. Changing that to:
if (snprintf (b
--- Comment #6 from wvangulik at xs4all dot nl 2008-01-20 19:30 ---
Bug is still present in 4.2.2.
Some more info:
I rewrote the example to (atleast for me) little more clear example.
struct fseqp_void
{
void (*p) (void);
char *e;
};
struct fseqp_void c;
void bar (void){}
i
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-20 19:26 ---
It fails even with gcc 4.1.2 and the same CFLAGS, and the problem is just buggy
inline assembly.
Following patch cures this for me:
--- hwfeatures.c.xx 2007-12-05 12:03:33.0 +0100
+++ hwfeatures.c20
There are several instruction patterns related to stack pointer operations.
These are not quite right:
1) popqi and poph1 patterns use post_inc codes - when in fact there are pre_inc
- this could fail if gcc ever used them outside prolog/epilog
2) Stack moves such as push/pop should be placed be
--- Comment #14 from zadeck at naturalbridge dot com 2008-01-20 18:30
---
confirmed on my machine,
i will have my best people work on it.
kenny
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-20 18:10
---
In the failing case, we have no stride:
Breakpoint 1, gfc_walk_subexpr (ss=0xfc2de0, expr=0x106f6b0)
at ../../gcc43/gcc/fortran/trans-array.c:5609
(gdb) p *expr->ref
snip
> stride = {0x0, 0x0, 0x0,
--- Comment #37 from dominiq at lps dot ens dot fr 2008-01-20 18:09 ---
(In reply to comment #36)
> ... And, if I understand correctly the comment #32, with 64 bits mode it does
> fails with wo_prof_mult_fields_peeling.c. Please fix me if I am wrong.
Yes, you are right. I did not look c
We are computing the correct result for test 8 of FM903.f, but one of the
"Correct" answers is truncated. Both are truncated in 4.2 and my last patch
gives this.
With FM903.f
gfortran:
COMPUTED=
12.34506.78 120.34 506.78 123.40 567.80
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-20 17:07 ---
Fixed on trunk - thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-20 17:07 ---
Fixed on trunk - thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #36 from olga at gcc dot gnu dot org 2008-01-20 17:03 ---
(In reply to comment #35)
> Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and
> 64 bit modes on i686-apple-darwin9, so I am not sure that what follows will
> help.
Sorry, I meant compiling
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34872
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34858
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
--- Comment #7 from pault at gcc dot gnu dot org 2008-01-20 16:59 ---
Subject: Bug 34784
Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131679
Log:
2008-01-20 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-20 16:59 ---
Subject: Bug 34854
Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131679
Log:
2008-01-20 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-20 16:59 ---
Subject: Bug 34861
Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131679
Log:
2008-01-20 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from hjl dot tools at gmail dot com 2008-01-20 16:43 ---
Oops. This one
--- regmove.c.freq 2008-01-17 07:31:56.0 -0800
+++ regmove.c 2008-01-20 08:42:42.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
rtx p;
rtx post_inc
--- Comment #6 from hjl dot tools at gmail dot com 2008-01-20 16:42 ---
Does this patch make any senses?
--- regmove.c.freq 2008-01-17 07:31:56.0 -0800
+++ regmove.c 2008-01-20 08:40:34.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
rtx
--- Comment #5 from hjl dot tools at gmail dot com 2008-01-20 16:34 ---
Should we also update REG_FREQ_CALLS_CROSSED whenever REG_N_CALLS_CROSSED
is updated? In regmove.c, there are
delete_insn (q);
INC_REG_N_SETS (REGNO (src), -1);
REG_N_CALLS_
--- Comment #11 from zadeck at naturalbridge dot com 2008-01-20 16:34
---
Subject: Re: [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c
doesn't work
olga at gcc dot gnu dot org wrote:
> --- Comment #10 from olga at gcc dot gnu dot org 2008-01-20 16:28 ---
> (In reply
On compiling that code:
--- begin code ---
class Y {};
void f(Y*) { } // line 3. If comment - all ok
template < typename T>
void sel(T* a) { f(a); } //line 6
void f(void*) {}
int main(int argc, char **argv)
{
sel((void*)0); //line 12
}
--- end code ---
Àppears error:
../main.cpp: In f
--- Comment #10 from olga at gcc dot gnu dot org 2008-01-20 16:28 ---
(In reply to comment #9)
> olga,
> even if the test case does not normally ice on your system, you be able to see
> the bug if you run the test with valgrind.
Kenny,
Thank you a lot for information. I was not aware
--- Comment #8 from manu at gcc dot gnu dot org 2008-01-20 16:06 ---
(In reply to comment #7)
> (In reply to comment #6)
>
> > Sorry, I don't have any of those trees left. But if I ever come to
> > revisit those two bugs I'll make sure it fixes this bogus warning.
>
> If you can give
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-20 15:57
---
It happens for me on Linux/Intel64 with -m32:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00907.html
My configuration is
configure flags: --enable-clocale=gnu --with-system-zlib
--enable-decimal-float=bid -
--- Comment #12 from zadeck at naturalbridge dot com 2008-01-20 15:52
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
> --- Comment #11 from dominiq at lps dot ens dot fr 2008-01-20 15:47
> ---
> I have put the resul
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-20 15:47 ---
I have put the results of the compilation with -da with the patch at
http://www.lps.ens.fr/~dominiq/gcc/tmp_fresh.tar.bz2
All the files will be in a directory tmp_fresh. Do you still need the same
without the patc
--- Comment #10 from zadeck at naturalbridge dot com 2008-01-20 15:39
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
> --- Comment #9 from dominiq at lps dot ens dot fr 2008-01-20 15:30
> ---
>
>> you are buildin
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-20 15:36 ---
Created an attachment (id=14978)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14978&action=view)
First draft of the patch
The patch works for the test case, but it fails for auto_char_dummy_array_1.f90
(ICE) a
--- Comment #4 from ubizjak at gmail dot com 2008-01-20 15:34 ---
(In reply to comment #3)
> Double checking patch, I don't see obvious mistakes. Since the patch should
> only affect register allocation decisions, either we see a latent bug, or
> another example of x86 extra precision c
--- Comment #4 from ubizjak at gmail dot com 2008-01-20 15:34 ---
(In reply to comment #3)
> There is the issue, the testcase should be not run on your computer as it is
> using SSE2. So this is a testsuite issue.
Please look at gcc.dg/vect/ how this should be done. There is a check_ve
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-20 15:30 ---
> you are building on a mac "darwin" box
Yes indeed, but the bug is also present for i686-pc-linux-gnu, see for
instance:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00914.html
--
http://gcc.gnu.org/bugzil
--- Comment #9 from zadeck at naturalbridge dot com 2008-01-20 15:29
---
olga,
even if the test case does not normally ice on your system, you be able to see
the bug if you run the test with valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
--- Comment #8 from zadeck at naturalbridge dot com 2008-01-20 15:24
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
> --- Comment #7 from dominiq at lps dot ens dot fr 2008-01-20 14:39
> ---
>
>> I need a more in
--- Comment #8 from ubizjak at gmail dot com 2008-01-20 15:21 ---
(In reply to comment #6)
> Confirmed on x86_64-unknown-linux-gnu.
It fails only with --enable-checkgin=assert, as is the case in
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00695.html
--
http://gcc.gnu.org/bugzi
--- Comment #7 from j at uriah dot heep dot sax dot de 2008-01-20 15:21
---
(In reply to comment #6)
> Sorry, I don't have any of those trees left. But if I ever come to
> revisit those two bugs I'll make sure it fixes this bogus warning.
If you can give me some hints about where to
--- Comment #35 from dominiq at lps dot ens dot fr 2008-01-20 15:16 ---
Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and
64 bit modes on i686-apple-darwin9, so I am not sure that what follows will
help.
For the code in comment #34 the assembly code is:
[ibo
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-20 14:56 ---
I am trying to proceed backward. I have reached the following point:
Breakpoint 8, gfc_parse_file () at ../../gcc-4.3-work/gcc/fortran/parse.c:3460
3460{
(gdb) s
gfc_parse_file () at ../../gcc-4.3-work/gcc/fortr
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-20 14:39 ---
> I need a more info to reproduce this bug.
I have tried to give all the info I have been able to gather on my own. My
config is:
Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
--mandir=/opt/gc
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-20 14:34 ---
I have a patch. Actually, I do not understand why it worked before.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from zadeck at naturalbridge dot com 2008-01-20 13:53
---
I need a more info to reproduce this bug. I bootstrapped and regression tested
on x86_64-unknown-linux-gnu with suse 10.3 and using
--enable-languages=c,c++,fortran --disable-multilib before committing the
patch
--- Comment #4 from krefson at googlemail dot com 2008-01-20 13:53 ---
(In reply to comment #3)
> (In reply to comment #2)
> > It's a regression - and I might be guilty of it with my Bind(C) patches...
>
> Well, if it's a regression, there's a bigger chance for it to
> be fixed before 4
--- Comment #8 from manu at gcc dot gnu dot org 2008-01-20 13:38 ---
(In reply to comment #2)
> I think that having -Wall clobber -Wstrict-overflow in this way is confusing.
> This isn't reversing the setting of the option, it's changing its level.
>
Ian, should the above testcase act
--- Comment #34 from olga at gcc dot gnu dot org 2008-01-20 13:28 ---
Dave, Dominique,
As I have no such execution failures on any one of machines, would you please
help me debugging the execution failures?
I am actually need the place where it fails and assembly files. The most
conven
1 - 100 of 125 matches
Mail list logo
