The following program - which uses a very common extension - is rejected by
gfortran. It is accepted by ifort, NAG f95 (!), sunf95, openf95, pgi, absoft.
As it is a very common extension, I marked it as reject-valid though the tab
makes it non-standard.
It is essential that at least for the second
--- Comment #18 from bonzini at gnu dot org 2008-01-21 08:04 ---
I agree with Steven. The trimming could be adjusted to not trim register that
are mentioned by REG_EQ* notes, but I'm not sure it would be a good idea,
either.
--
bonzini at gnu dot org changed:
What|Re
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-21 08:45 ---
Real-world test case:
http://www.chara.gsu.edu/~gudehus/fits_library_package.html
Untested:
Index: scanner.c
===
--- scanner.c (revision 131688)
+++
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-21 09:20
---
Err, did I really close this bug?! I wanted to assign it to myself ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-21 09:22 ---
This is an unhandled expression. A gcc_unreachable() is hit in a switch block.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #5 from olga at gcc dot gnu dot org 2008-01-21 09:07 ---
Subject: Bug 34701
Author: olga
Date: Mon Jan 21 09:07:12 2008
New Revision: 131689
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131689
Log:
2008-01-21 Alon Dayan <[EMAIL PROTECTED]>
Olga Golova
Hello,
I am experiencing the error below while building gcc 4.2.2 for the mips64vr-elf
target. I have confirmed the same happens with gcc-4.2-20080116.
Versioning:
binutils 2.18
newlib-1.16.0
GCC configured this way:
$ CFLAGS=-O2 $DEPACK_DIR/gcc-4.2.2/configure --target=mips64vrel-elf \
--pre
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-21 09:35 ---
Subject: Bug 34850
Author: rguenth
Date: Mon Jan 21 09:34:19 2008
New Revision: 131690
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131690
Log:
2008-01-21 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #12 from hubicka at ucw dot cz 2008-01-21 09:54 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
and haydn tester using -O3 -funroll-loops -fpeel-loops -ffast-math
-march=native -mtune=native -mfpmath=sse has also started failing at
17th, so th
--- Comment #11 from hubicka at ucw dot cz 2008-01-21 09:48 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
Hi,
also one extra data point, britten tester that uses -O3
-fomit-frame-pointer -ftree-loop-linear -funroll-all-loops
-fprefetch-loop-arrays -march=k8
--- Comment #10 from hubicka at ucw dot cz 2008-01-21 09:44 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
>
>
> --- 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
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-21 09:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from hubicka at ucw dot cz 2008-01-21 09:43 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
>
>
> --- Comment #7 from hjl dot tools at gmail dot com 2008-01-20 16:43
> ---
> Oops. This one
Yes, it does make sense. I must've missed
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-21 10:15 ---
On trunk, ICEs with plain -g.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyw
gfortran correctly complains about mismatched types in the code below. However,
adding the kinds of the data types would make the message even more informative
(see below).
$> cat real-real.f90
REAL(4) :: x
print *, f(x)
CONTAINS
FUNCTION f(a)
REAL(8) :: a, f
a = 3.1415
END FUNCTION
E
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-21 10:36 ---
Err...
# VUSE { D.2180 }
from_8 = (struct sockaddr *) D.2180
this is not valid gimple.
Reduced testcase:
typedef union {
__const struct sockaddr *__restrict __sockaddr__;
} __CONST_SOCKADDR_ARG __attribute__ (
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-21 10:44 ---
That we don't catch this mismatch during gimplifcation and disable inlining
for this function is because the C FE doesn't provide DECL_ARGUMENTS for
this function! So we fall back to the function types TYPE_ARG_TYPE
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-21 10:55 ---
Actually, this does not work as in scanner.c's "load_line" the '\t' is changed
into 6 spaces. And of cause, if one changes this, e.g., "\tPARAMETER" is no
longer recognized ...
+ if (c < 1 || c > 9)
And t
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-21 11:02 ---
Index: interface.c
===
--- interface.c (revision 131688)
+++ interface.c (working copy)
@@ -1475,6 +1475,12 @@ compare_parameter (gfc_symbol *formal, g
--- Comment #3 from tammer at tammer dot net 2008-01-21 11:14 ---
Hello,
any news ?
Do you need further information / tests ?
Bye
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34794
For the attached C/C++ source, illegal code is produced when -O3 is used.
One source statement is omitted. This statement is marked by
/** ERROR: no code will be generated for the following statement **/
in the source code.
The issue can be seen on different platforms, so it seems to be in the RTL
--- Comment #1 from dominik dot strasser at onespin-solutions dot com
2008-01-21 11:17 ---
Created an attachment (id=14986)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14986&action=view)
tar file with illustrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
--- Comment #1 from jakub at gcc dot gnu dot org 2008-01-21 11:20 ---
Apparently caused by my PR33025 fix, will look into this.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-21 11:52 ---
I thought inlining is disabled for mismatching function prototype/definition?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
--- Comment #6 from rguenther at suse dot de 2008-01-21 12:03 ---
Subject: Re: [4.3 Regression] ICE in copy_reference_ops_from_ref,
at tree-ssa-sccvn.c:574
On Mon, 21 Jan 2008, steven at gcc dot gnu dot org wrote:
> --- Comment #5 from steven at gcc dot gnu dot org 2008-01-21 11
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-21 12:12 ---
Could you try to compile it by adding -Wstrict-overflow=5 as the last warning
flag (after -Wall)?
Independently, could you try to compile it by adding the -fwrapv flag?
--
manu at gcc dot gnu dot org changed:
--- Comment #3 from dominik dot strasser at onespin-solutions dot com
2008-01-21 12:17 ---
-Wstrict-overflow=5 doesn't seem to be available in 4.1.2
-fwrapv didn't make a difference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-01-21 12:22
---
*** Bug 34834 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-01-21 12:22
---
*** This bug has been marked as a duplicate of 24314 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from tbm at cyrius dot com 2008-01-21 12:31 ---
(In reply to comment #11)
> Created an attachment (id=14907)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14907&action=view) [edit]
> Lightly tested fix.
>
> I'll give it a whirl on IA-64 but it would be nice to test
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-21 12:44 ---
Does -fno-strict-aliasing? Does adding that option with -O3 does that fix the
issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-21 12:45 ---
Actually, only the diagnostics is a regression introduced by PR33025 fix.
Before that (but after PR29286 fix) at -O1 and higher cc1plus ICEd in
gimplify_expr and at -O0 it silently miscompiled e.g.:
typedef __SIZE_TYPE
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-21 12:58 ---
So, either the source is invalid and the C FE should diagnose it, or we can
'work around' this (and similarly bogus) issues by using VIEW_CONVERT_EXPR
to make the IL valid again.
Ha, and we do. With -pedantic-error
--- Comment #19 from zadeck at naturalbridge dot com 2008-01-21 13:02
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
bonzini at gnu dot org wrote:
> --- Comment #18 from bonzini at gnu dot org 2008-01-21 08:04 ---
> I agree with Steven. The trimming co
--- Comment #5 from dominik dot strasser at onespin-solutions dot com
2008-01-21 13:07 ---
Bingo -fno-strict-aliasing does the trick. But what shall I do ? This is a
generated Bison parser.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #20 from bonzini at gnu dot org 2008-01-21 13:21 ---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
> I am testing a patch that add eq_notes to the lr problem if you specify
> DF_EQ_NOTES.
> If you and steven still want me to abandon this, i will, but in
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-21 13:22 ---
If I remember correctly this was a bug with bison itself. What version of
bison are you using? I suggest to simply use -fno-strict-aliasing for this
generated file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #21 from zadeck at naturalbridge dot com 2008-01-21 13:25
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
bonzini at gnu dot org wrote:
> --- Comment #20 from bonzini at gnu dot org 2008-01-21 13:21 ---
> Subject: Re: [4.3 Regression] gfortr
--- Comment #39 from olga at gcc dot gnu dot org 2008-01-21 13:33 ---
(In reply to comment #38)
> 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 execut
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-21 13:42 ---
Confirmed. In the latter case we const-propped the initializer into the
V_C_E:
VIEW_CONVERT_EXPR({(unsigned int) &g[16]})
which is of course neither CONSTANT_CLASS_P nor a gimple lvalue (but it is
is_gimple_min_in
--- Comment #7 from dominik dot strasser at onespin-solutions dot com
2008-01-21 13:45 ---
This is bison 2.0.
The latest version is 2.3. If haven't found anything in the ChangeLog which
sounds like there was a bug fix in this area.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=349
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-21 13:54 ---
And for_each_index does not handle CONSTRUCTOR. Then, we ICE in
copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
because that obviously also does not handle CONSTRUCTOR either.
_Then_, at -O2, we ICE in simpli
--- Comment #40 from dominiq at lps dot ens dot fr 2008-01-21 14:09 ---
> Why are you running wo_prof_mult_field_peeling.c with profiling?
My best guess is because I have reused some previous command line(s) with it
(from gcc.dg/struct/w_prof_global_array.c for instance) without thinkin
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-21 14:15 ---
To answer my question, new16.C fails if the build_new_1 setting of
placement_expr and both calls to avoid_placement_new_aliasing are commented
out. I believe PR33407 is meant to handle this, unfortunately there is not
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-01-21 14:25
---
> Eric, was your testing successful?
Yes, everything is clean on the IA-64.
> I'll give it a go on ARM now.
Thanks in advance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-21 14:26 ---
Subject: Bug 34885
Author: rguenth
Date: Mon Jan 21 14:25:46 2008
New Revision: 131694
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131694
Log:
2008-01-21 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-21 14:26 ---
"Fixed."
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-21 14:38 ---
> The similar
> condition for reaching definitions is not liveness, but absence of
> uses. To trim reaching definitions, one should really be looking at
> the last reachable use of a definition, and trim from there.
--- Comment #24 from dominiq at lps dot ens dot fr 2008-01-21 14:39 ---
Side note for the record: the polyhedron test mdbx.f90 also fails in 32 bit
mode with rev. 131689 on i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-21 14:40
---
Can we revert the offending patch and revisit this issue during stage1 please?
Thanks.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #3 from rvovsd at mail dot ru 2008-01-21 14:43 ---
This case is similar to the bug 31047
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047).
There Andrew Pinski wrote (comment 4):
>14.6.4.2/1 says this is invalid code.
>For a function call that depends on a template paramet
--- Comment #26 from bonzini at gnu dot org 2008-01-21 14:54 ---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
Agreed. I think we'd better revert the patch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #41 from dominiq at lps dot ens dot fr 2008-01-21 14:54 ---
Sorry I missed the second question:
> The other question is whether the failing tests that should run *with*
> profiling, like w_prof_gloval_var.c and w_prof_local_var.c, fail after
> compilation with -fprofile-gene
--- Comment #22 from stevenb dot gcc at gmail dot com 2008-01-21 14:29
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
On 21 Jan 2008 13:25:23 -, zadeck at naturalbridge dot com I understand that, that is why if the pass does not specify DF_EQ_NOTES,
> the l
--- Comment #3 from singler at gcc dot gnu dot org 2008-01-21 15:14 ---
So is this a bug in the library or in the definition/implementation of
namespace association? The documentation on namespace association even mentions
"argument-dependent lookup".
http://gcc.gnu.org/onlinedocs/gcc/N
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-21 15:14 ---
Reproducible even with x86_64-linux -> i686-darwin9 cross, at -Os as well as
-O2 -mno-accumulate-outgoing-args. The difference between i686-linux and
i686-darwin9 that matters here is that darwin defines STACK_BOUNDAR
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-21 15:14
---
I tried -mpc64. It also works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-01-21 15:17 ---
> In reply to comment #1:
Bootstrapped and regression tested on i686-pc-linux-gnu. No additional
regressions besides shown in [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00966.html
--
http://gcc.
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-21 15:22 ---
Shorter testcase:
void foo (int, ...);
__attribute__ ((vector_size (16))) int v;
void
bar (void)
{
foo (1, v);
}
with -O2 -mno-accumulate-outgoing-args -m32 or -Os -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.
I can't build the embedded application (U-Boot firmware) using the GCC 4.2.2
powerpc-linux cross because resultant code doesn't fit into the reserved space
anymore. GCC 4.0.0 powerpc cross build it OK.
Investigation showed that the code size generated by the GCC 4.2.2 is about 6%
bigger as produced
--- Comment #1 from sposelenov at emcraft dot com 2008-01-21 15:36 ---
Created an attachment (id=14987)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14987&action=view)
Preprocessed output, GCC 4.2.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
--- Comment #27 from zadeck at naturalbridge dot com 2008-01-21 15:36
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
bonzini at gnu dot org wrote:
> --- Comment #26 from bonzini at gnu dot org 2008-01-21 14:54 ---
> Subject: Re: [4.3 Regression] gfortr
--- Comment #2 from sposelenov at emcraft dot com 2008-01-21 15:37 ---
Created an attachment (id=14988)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14988&action=view)
Resulted assembler,GCC 4.2.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-21 15:38 ---
And varargs aren't even needed:
typedef __attribute__ ((vector_size (16))) int V;
void foo (int, V, V, V, V);
V v;
void
bar (void)
{
foo (1, v, v, v, v);
}
The regression has been caused by
http://gcc.gnu.org/viewc
--- Comment #3 from sposelenov at emcraft dot com 2008-01-21 15:41 ---
Created an attachment (id=14989)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14989&action=view)
preprocessed output, GCC 4.0.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
--- Comment #4 from sposelenov at emcraft dot com 2008-01-21 15:42 ---
Created an attachment (id=14990)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14990&action=view)
resulted assmbelr, GCC 4.0.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
bash-3.2$ /usr/gcc-4.3/bin/gcc -m32 -c y.i z.i -march=core2 -mfpmath=sse
bash-3.2$ /usr/gcc-4.3/bin/gcc -m32 -c y.i z.i -march=native -mfpmath=sse
z.i:1: warning: SSE instruction set disabled, using 387 arithmetics
The problem is gcc driver never passed the proper -march=xxx to
COLLECT_GCC_OPT
--- Comment #14 from hjl dot tools at gmail dot com 2008-01-21 15:51
---
(In reply to comment #12)
> Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
>
> and haydn tester using -O3 -funroll-loops -fpeel-loops -ffast-math
> -march=native -mtune=native -mfpmath
--- Comment #5 from dje at gcc dot gnu dot org 2008-01-21 15:54 ---
The "regression" is due to a wrong-code bug fix. To reduce the code size, the
prologue and epilogue need to emit lwm/stwm for two ranges of registers, which
does not correspond to a standard PowerPC ABI.
--
dje at g
--- Comment #15 from manu at gcc dot gnu dot org 2008-01-21 16:01 ---
This is CCP related. (See "Problem 2: CCP assumes a value for uninitialized
variables" in http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings)
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from sposelenov at emcraft dot com 2008-01-21 16:08 ---
(In reply to comment #5)
> The "regression" is due to a wrong-code bug fix. To reduce the code size, the
> prologue and epilogue need to emit lwm/stwm for two ranges of registers, which
> does not correspond to a sta
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-21 16:22 ---
Subject: Bug 34856
Author: rguenth
Date: Mon Jan 21 16:21:45 2008
New Revision: 131696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131696
Log:
2008-01-21 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-21 16:24 ---
tree parts fixed. Eric, can you look into the RTL parts?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-01-21 16:30 ---
Bugs waiting for the committee should not be release-critical; we can restore
this to P3 and reconsider the priority when unsuspending.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from jsm28 at gcc dot gnu dot org 2008-01-21 16:32 ---
Bugs waiting for the committee should not be release-critical; we can restore
this to P3 and reconsider the priority when unsuspending.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34846
--- Comment #15 from hubicka at ucw dot cz 2008-01-21 16:42 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
> I tried -mpc64. It also works.
I would declare this a proof that it is extra preccision issue and
simply update testers to use -mpc64. It is what mos
--- Comment #6 from geoffk at gcc dot gnu dot org 2008-01-21 16:43 ---
I suspect that the patch changed bad code generation into a crash, which is not
a regression...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
--- Comment #5 from rakdver at gcc dot gnu dot org 2008-01-21 16:43 ---
I cannot reproduce this with the current mainline (rev 131696), neither with
the original testcase nor the reduced one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
FAIL: g++.dg/conversion/simd1.C (test for excess errors)
Excess errors:
==18116== Conditional jump or move depends on uninitialised value(s)
==18116==at 0x80CFD96: comptypes (typeck.c:1107)
==18116==by 0x8122A01: vector_types_convertible_p (c-common.c:1196)
==18116==by 0x80DA8BA: conver
FAIL: g++.dg/ext/asm3.C (test for excess errors)
Excess errors:
==25921== Conditional jump or move depends on uninitialised value(s)
==25921==at 0x8292529: gimplify_asm_expr (gimplify.c:4285)
==25921==by 0x82952A7: gimplify_expr (gimplify.c:5904)
==25921==by 0x8292FD7: gimplify_stmt (gi
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P2
--- Comment #7 from dje at gcc dot gnu dot org 2008-01-21 16:37 ---
First, please stop changing the categorization of this bug.
The patch which changed this behavior is
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00276.html
--
dje at gcc dot gnu dot org changed:
What
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-21 17:10 ---
It's been half a year since anyone said anything about this bug...
Ian, pinski asked you a question. Thoughts?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-21 17:11
---
Used svn revision 131650.
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
GCC ta
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-21 17:13
---
Used svn revision 131650.
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
GCC ta
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-21 17:19 ---
Me neither, but it now ICEs with
./cc1 -quiet -O3 -ftree-parallelize-loops=4 decompress.i
decompress.c: In function 'BZ2_decompress':
decompress.c:107: internal compiler error: in get_smt_for, at
tree-ssa-alias.c:3
--- Comment #7 from rakdver at gcc dot gnu dot org 2008-01-21 17:25 ---
I get that ICE as well; but that is a dup of 34330 (and seems to be different
from the problem described in this PR).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
--- Comment #10 from danglin at gcc dot gnu dot org 2008-01-21 17:25
---
Subject: Bug 26253
Author: danglin
Date: Mon Jan 21 17:24:30 2008
New Revision: 131698
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131698
Log:
PR libfortran/34699
Backport:
2007-
--- Comment #6 from danglin at gcc dot gnu dot org 2008-01-21 17:25 ---
Subject: Bug 34699
Author: danglin
Date: Mon Jan 21 17:24:30 2008
New Revision: 131698
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131698
Log:
PR libfortran/34699
Backport:
2007-09
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-21 17:32 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00253.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rakdver at gcc dot gnu dot org 2008-01-21 17:35 ---
(In reply to comment #3)
> > This is a vectorizer vs not being able to run may_alias after it
>
> can you please remind me why we can't run may_alias after the vectorizer? (and
> what do you think can be done about
--- Comment #3 from kargl at gcc dot gnu dot org 2008-01-21 17:40 ---
(In reply to comment #0)
> The following program - which uses a very common extension - is rejected by
> gfortran. It is accepted by ifort, NAG f95 (!), sunf95, openf95, pgi, absoft.
> As it is a very common extension,
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
1 - 100 of 212 matches
Mail list logo
