[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #4 from ian at airs dot com 2007-09-05 06:03 --- I haven't looked further at this since this message: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01166.html Testing DECL_EXTERNAL_LINKAGE_P does not make any difference: the compiler still crashes. The decl in question is var_decl 0xb7d3b0b8 c type integer_type 0xb7d378dc int readonly type_6 SI size integer_cst 0xb7c55620 constant invariant 32 unit size integer_cst 0xb7c5540c constant invariant 4 align 32 symtab 0 alias set -1 canonical type 0xb7d378dc precision 32 min integer_cst 0xb7c555cc -2147483648 max integer_cst 0xb7c555e8 2147483647 readonly used private static tree_1 tree_2 tree_3 nonlocal decl_3 decl_5 decl_6 SI file /home/iant/foo1.cc line 8 size integer_cst 0xb7c55620 32 unit size integer_cst 0xb7c5540c 4 align 32 context record_type 0xb7d37ca8 A initial integer_cst 0xb7c55bd0 0 template-info 0xb7d3c444 chain type_decl 0xb7d37d80 A -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug bootstrap/33309] gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualifiers from pointer target type
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-09-05 06:17 --- (In reply to comment #1) I think I'll let Kaveh fix this one... To what exactly do I owe this honor? :-) AFAICT, this is a -Wwrite-strings error caused by a patch by FX: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02280.html A quick fix might be to do ASTRDUP on the INIT_ENVIRONMENT string. It's okay to use stack space for putenv strings here because we're in main(). However I seem to recall a problem with alloca passed as a function argument in some ancient version of gcc. So it'll need an intermediate tmp variable, or use xstrdup to avoid alloca. Another option would be to constify xputenv and use CONST_CAST on the argument passed to putenv. A third option would be to constify xputenv and fixinclude putenv on those platforms where it isn't const. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
--- Comment #25 from giovannibajo at libero dot it 2007-09-05 06:47 --- Daniel, can we backport this patch to 4.2, please? It's a P1 regression! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
Kernel miscompile with -march=c3
I am trying to track down a problem with linux kernels which hang silently (within 5 minutes or a few hours of boot) if compiled with -march=c3. If I use -march=586mmx or 586 the kernels are stable for days. As there is nothing in the logs or on a serial console, it is difficult to know where to look for the root of the problem. I would be grateful for some suggestions to start to track this down. I imagine it is a compiler bug or a kernel bug exposed by the march setting. cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Ezra stepping: 10 cpu MHz : 399.000 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips: 800.58 clflush size: 32 .. so -march-c3 should be correct, if I understand correctly. An example of the complete command line the compile is using: gcc -m32 -Wp,-MD,drivers/net/.3c59x.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.1.3/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -pipe -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=c3 -falign-functions=0 -falign-jumps=0 -falign-loops=0 -mtune=generic -ffreestanding -maccumulate-outgoing-args -Iinclude/asm-i386/mach-default -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(3c59x) -DKBUILD_MODNAME=KBUILD_STR(3c59x) -c -o drivers/net/.tmp_3c59x.o drivers/net/3c59x.c I am out of my depth with lots of these, so I would be grateful for advice on whether they are sane! I am using: gcc (GCC) 4.1.3 20070812 (prerelease) (Debian 4.1.2-15) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU ld (GNU Binutils for Debian) 2.17.90.20070812 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Thanks for the help, Mark
[Bug middle-end/21032] [4.0 Regression] With -frounding-math, incorrectly reorders unary minus
--- Comment #21 from bagnara at cs dot unipr dot it 2007-09-05 08:22 --- It seems the bug has reappeared in GCC 4.1.2. Here is what I obtain: .file bug.c .text .p2align 4,,15 .globl assign2 .type assign2, @function assign2: pushl %ebp movl%esp, %ebp subl$20, %esp fldl12(%ebp) fstps -20(%ebp) movl8(%ebp), %eax flds-20(%ebp) fchs fstps -4(%ebp) flds-4(%ebp) fchs fstps (%eax) leave ret .size assign2, .-assign2 .ident GCC: (GNU) 4.1.2 20070626 (Red Hat 4.1.2-13) .section.note.GNU-stack,,@progbits -- bagnara at cs dot unipr dot it changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-09-05 08:29 --- Not really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug middle-end/21032] [4.0 Regression] With -frounding-math, incorrectly reorders unary minus
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-09-05 08:37 --- As this is still fixed at the tree level, can you file a new bugreport please? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
[Bug fortran/33308] gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-05 08:55 --- As Andrew wrote: It works with GCC gfortran 4.3.0; I can reproduce the failure with GCC gfortran 4.2.x and 4.1.x. The GCC policy is to fix only regressions in released GCC versions (i.e. 4.2.x and 4.1.x) and not backporting other fixes. (Which has the advantage that we can concentrate on fixing bugs in 4.3.0.) You could try the current GCC 4.3.0 gfortran; binaries are available from: http://gcc.gnu.org/wiki/GFortranBinaries Disclaimer: As these are the nightly builds of the developer version, they may not always work; however, in my experience they do work to 99.9% and especially gfortran contains many fixes (and enhancements). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.2 4.1.3 Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #21 from dominiq at lps dot ens dot fr 2007-09-05 09:19 --- Subject: Re: Missing last digit in some formatted output (on 32bit targets), per kind write_float If I am not mistaken, the test case did not go through. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug preprocessor/33305] We should warn about empty macro arguments
--- Comment #1 from manu at gcc dot gnu dot org 2007-09-05 09:24 --- There was talking about creating a -Wundefined flag that warns about undefined behaviour (PR30334). Would this fit in there? (-pedantic is not supposed to warn about undefined constructions as far as I know). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305
Re: [Bug preprocessor/33305] We should warn about empty macro arguments
On 5 Sep 2007 09:24:09 -, manu at gcc dot gnu dot org [EMAIL PROTECTED] wrote: There was talking about creating a -Wundefined flag that warns about undefined behaviour (PR30334). Would this fit in there? (-pedantic is not supposed to warn about undefined constructions as far as I know). There are two different undefined behaviors, one at runtime and one at compile time. This belongs to the latter which means we can diagnostic this if we want (and can do it with -pedantic in fact). -- Pinski
[Bug preprocessor/33305] We should warn about empty macro arguments
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-05 09:29 --- Subject: Re: We should warn about empty macro arguments On 5 Sep 2007 09:24:09 -, manu at gcc dot gnu dot org [EMAIL PROTECTED] wrote: There was talking about creating a -Wundefined flag that warns about undefined behaviour (PR30334). Would this fit in there? (-pedantic is not supposed to warn about undefined constructions as far as I know). There are two different undefined behaviors, one at runtime and one at compile time. This belongs to the latter which means we can diagnostic this if we want (and can do it with -pedantic in fact). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305
[Bug c++/29731] [4.0/4.1/4.2/4.3 regression] ICE with statement expression as template parameter
--- Comment #8 from paolo at gcc dot gnu dot org 2007-09-05 09:32 --- Subject: Bug 29731 Author: paolo Date: Wed Sep 5 09:31:54 2007 New Revision: 128124 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128124 Log: /cp 2007-09-05 Paolo Carlini [EMAIL PROTECTED] PR c++/29731 (again) * parser.c (cp_parser_primary_expression): Return error_mark_node when a statement-expression is found in a template-argument list. /testsuite 2007-09-05 Paolo Carlini [EMAIL PROTECTED] PR c++/29731 * g++.dg/parse/template24.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/template24.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29731
[Bug c++/29731] [4.0/4.1/4.2 regression] ICE with statement expression as template parameter
--- Comment #9 from pcarlini at suse dot de 2007-09-05 09:33 --- Fixed for 4.3.0. Frankly, I'm not interested in working on the other branches... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE |ICE with statement |with statement expression as |expression as template |template parameter |parameter | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29731
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #11 from jakub at gcc dot gnu dot org 2007-09-05 09:41 --- *** Bug 32855 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/32855] [4.3 Regression] g++.dg/tree-ssa/pr28003.C
--- Comment #5 from jakub at gcc dot gnu dot org 2007-09-05 09:41 --- *** This bug has been marked as a duplicate of 32552 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32855
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #12 from jakub at gcc dot gnu dot org 2007-09-05 09:44 --- I have bootstrapped/regtested the http://gcc.gnu.org/bugzilla/attachment.cgi?id=13831action=view patch on ia64-linux, fixed the FAIL: g++.dg/tree-ssa/pr28003.C execution test failure, no regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-09-05 09:47
---
(In reply to comment #9)
By the way, nint_2.f90 also fails at -O0 on AIX.
And it works on powerpc-apple-darwin. David, could you test my C program in
comment #4, and look into ${builddir}/${target_triplet}/libgfortran/config.h to
see what value have the HAVE_LROUND{F,,L} and HAVE_LLROUND{F,,L} macros?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu,
||powerpc-ibm-aix5.3.0.0
GCC host triplet|powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu,
||powerpc-ibm-aix5.3.0.0
GCC target triplet|powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu,
||powerpc-ibm-aix5.3.0.0
Version|4.3.0 |unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug bootstrap/33309] gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualifiers from pointer target type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-05 09:53
---
(In reply to comment #2)
Another option would be to constify xputenv and use CONST_CAST on the argument
passed to putenv.
Like this?
Index: gcc.c
===
--- gcc.c (revision 128046)
+++ gcc.c (working copy)
@@ -297,7 +297,7 @@ static void set_spec (const char *, cons
static struct compiler *lookup_compiler (const char *, size_t, const char *);
static char *build_search_list (const struct path_prefix *, const char *,
bool, bool);
-static void xputenv (char *);
+static void xputenv (const char *);
static void putenv_from_prefixes (const struct path_prefix *, const char *,
bool);
static int access_check (const char *, int);
@@ -2602,11 +2602,11 @@ add_to_obstack (char *path, void *data)
/* Add or change the value of an environment variable, outputting the
change to standard error if in verbose mode. */
static void
-xputenv (char *string)
+xputenv (const char *string)
{
if (verbose_flag)
notice (%s\n, string);
- putenv (string);
+ putenv (CONST_CAST (string));
}
/* Build a list of search directories from PATHS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug c++/33210] [4.1/4.2 Regression] Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl
--- Comment #7 from paolo at gcc dot gnu dot org 2007-09-05 10:40 --- Subject: Bug 33210 Author: paolo Date: Wed Sep 5 10:40:29 2007 New Revision: 128125 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128125 Log: /cp 2007-09-05 Paolo Carlini [EMAIL PROTECTED] PR c++/33210 * cxx-pretty-print.c (pp_cxx_unqualified_id): Deal with BOUND_TEMPLATE_TEMPLATE_PARM. /testsuite 2007-09-05 Paolo Carlini [EMAIL PROTECTED] PR c++/33210 * g++.dg/template/error30.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/error30.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cxx-pretty-print.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210
[Bug c++/33210] [4.1 Regression] Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl
--- Comment #8 from pcarlini at suse dot de 2007-09-05 10:41 --- Fixed in 4_2-branch too. -- pcarlini at suse dot de changed: What|Removed |Added Summary|[4.1/4.2 Regression] Broken |[4.1 Regression] Broken |diagnostics:|diagnostics: |'bound_template_template_par|'bound_template_template_par |m' not supported by |m' not supported by |pp_cxx_unqualified_id/dump_d|pp_cxx_unqualified_id/dump_d |ecl |ecl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210
[Bug fortran/33310] New: Bind(C): Accepts PARAMETER with BIND(C) attribute
I believe the following is invalid - combining PARAMETER with BIND(C), however, gfortran does not reject this; if one tries to use-associate the parameter in the main program, one gets an error. module m use iso_c_binding implicit none TYPE, bind(C) :: the_distribution INTEGER(c_int) :: parameters(1) END TYPE the_distribution TYPE (the_distribution), parameter, bind(C) :: the_beta = the_distribution((/0/)) end module m -- Summary: Bind(C): Accepts PARAMETER with BIND(C) attribute Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 32630 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33310
[Bug fortran/33310] Bind(C): Accepts PARAMETER with BIND(C) attribute
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-05 11:15 --- The BIND statement specifies the BIND attribute (5.1.2.4) for a list of variables and common blocks. and The BIND attribute for a variable or common block specifies that it is capable of interoperating with a C variable that has external linkage (15.3). I would argue that a symbol with a PARAMETER attribute is not a variable but a named constant and thus BIND(C) is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33310
[Bug tree-optimization/32586] [4.3 Regression] New VN misses FRE opportunities
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-05 11:26 --- *** Bug 32845 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32586
[Bug tree-optimization/32845] [4.3 Regression] : gcc.dg/builtins-61.c scan-tree-dump return 0.0
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-05 11:26 --- Confirmed, but a dup of 32586. *** This bug has been marked as a duplicate of 32586 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32845
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-05 11:33 --- While RTL dse eliminates the redundant store to this-D.2013.a, tree-level DSE does not do so. (RTL dse also fails with -O3 -fforce-addr -ftracer) bb 4: # VUSE tab_54, SMT.9_56 D.2089_34 = this_2(D)-D.2013.a; D.2090_35 = (unsigned int) D.2089_34; D.2091_36 = D.2090_35 + 2; D.2092_37 = (int) D.2091_36; # tab_62 = VDEF tab_54 # SMT.9_63 = VDEF SMT.9_56 this_2(D)-D.2013.a = D.2092_37; D.2095_40 = D.2091_36 + 2; D.2096_41 = (int) D.2095_40; # tab_64 = VDEF tab_62 # SMT.9_65 = VDEF SMT.9_63 this_2(D)-D.2013.a = D.2096_41; # VUSE tab_64, SMT.9_65 D.2087_42 = this_2(D)-addr; D.2097_43 = (long unsigned int) D.2087_42; D.2098_44 = D.2097_43 255; D.2099_45 = p_33 + D.2098_44; # VUSE tab_64, SMT.9_65 b_46 = *D.2099_45; goto bb 6; clearly there is no reason for DSE not to discard the store. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization, TREE Last reconfirmed|-00-00 00:00:00 |2007-09-05 11:33:31 date|| Summary|follow-up on bug 33291 |dead-store not eliminated |dead-store not eliminated | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #9 from ramana dot radhakrishnan at celunite dot com 2007-09-05 11:46 --- The above mentioned testcase works ok and generates auto-increments in Comment #8 . I'd still be interested in looking at why the volatile case cannot work. Adding Zdenek to the CC for this case. -- ramana dot radhakrishnan at celunite dot com changed: What|Removed |Added CC||rakdver at atrey dot karlin ||dot mff dot cuni dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-05 11:48 ---
DSE does a post-dominator walk starting from the exit block. But the exit
block
has no predecessors because the function does never exit ;)
void foo(int *p)
{
while (1)
{
*p = 0;
*p = 0;
}
}
after DSE:
foo (p)
{
bb 2:
bb 3:
*p_1(D) = 0;
*p_1(D) = 0;
goto bb 3;
}
I suppose more post-dom walk optimizations are affected by this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
Re: [Bug c/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite
On 28 Aug 2007 15:58:29 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-28 15:58 ---
if (a == 0) a = bar (); isn't necessary either.
salias has:
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# VUSE qD.2026_12(D), SMT.25D.2079_13(D) { qD.2026 SMT.25D.2079 }
D.2027_3 = foo ();
pD.2025_4 = (struct S *) D.2027_3;
if (pD.2025_4 == 0B)
goto bb 3;
else
goto bb 4;
# SUCC: 3 [7.3%] (true,exec) 4 [92.7%] (false,exec)
# BLOCK 3 freq:735
# PRED: 2 [7.3%] (true,exec)
# qD.2026_15 = VDEF qD.2026_12(D)
# SMT.25D.2079_16 = VDEF SMT.25D.2079_13(D)
# SMT.26D.2080_17 = VDEF SMT.26D.2080_14(D) { qD.2026 SMT.25D.2079
SMT.26D.2080 }
__builtin_memset (qD.2026, 0, 24);
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 4 freq:1
# PRED: 2 [92.7%] (false,exec) 3 [100.0%] (fallthru,exec)
# qD.2026_11 = PHI qD.2026_12(D)(2), qD.2026_15(3)
# pD.2025_1 = PHI pD.2025_4(2), qD.2026(3)
# qD.2026_18 = VDEF qD.2026_11 { qD.2026 }
pD.2025_1-s1D.2008 = aD.2021_6(D);
# qD.2026_19 = VDEF qD.2026_18 { qD.2026 }
pD.2025_1-s2D.2009 = bD.2022_7(D);
Shouldn't the VDEFs be a PHI of some SMT and qD?
For VDEF/VUSE, you will never have a PHI of anything other than
multiple versions of the same SMT/virtual variable.
The above looks right to me at a glance.
It is probably pruning the result using TBAA which is what p-s isn't
thought to access the SMT.
[Bug middle-end/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-09-05 11:50 ---
Subject: Re: [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of
code in SQLite
On 28 Aug 2007 15:58:29 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #6 from jakub at gcc dot gnu dot org 2007-08-28 15:58 ---
if (a == 0) a = bar (); isn't necessary either.
salias has:
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# VUSE qD.2026_12(D), SMT.25D.2079_13(D) { qD.2026 SMT.25D.2079 }
D.2027_3 = foo ();
pD.2025_4 = (struct S *) D.2027_3;
if (pD.2025_4 == 0B)
goto bb 3;
else
goto bb 4;
# SUCC: 3 [7.3%] (true,exec) 4 [92.7%] (false,exec)
# BLOCK 3 freq:735
# PRED: 2 [7.3%] (true,exec)
# qD.2026_15 = VDEF qD.2026_12(D)
# SMT.25D.2079_16 = VDEF SMT.25D.2079_13(D)
# SMT.26D.2080_17 = VDEF SMT.26D.2080_14(D) { qD.2026 SMT.25D.2079
SMT.26D.2080 }
__builtin_memset (qD.2026, 0, 24);
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 4 freq:1
# PRED: 2 [92.7%] (false,exec) 3 [100.0%] (fallthru,exec)
# qD.2026_11 = PHI qD.2026_12(D)(2), qD.2026_15(3)
# pD.2025_1 = PHI pD.2025_4(2), qD.2026(3)
# qD.2026_18 = VDEF qD.2026_11 { qD.2026 }
pD.2025_1-s1D.2008 = aD.2021_6(D);
# qD.2026_19 = VDEF qD.2026_18 { qD.2026 }
pD.2025_1-s2D.2009 = bD.2022_7(D);
Shouldn't the VDEFs be a PHI of some SMT and qD?
For VDEF/VUSE, you will never have a PHI of anything other than
multiple versions of the same SMT/virtual variable.
The above looks right to me at a glance.
It is probably pruning the result using TBAA which is what p-s isn't
thought to access the SMT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-09-05 11:51 --- Subject: Re: [4.2 Regression] -fstrict-aliasing causes skipped code On 5 Sep 2007 06:47:19 -, giovannibajo at libero dot it [EMAIL PROTECTED] wrote: --- Comment #25 from giovannibajo at libero dot it 2007-09-05 06:47 --- Daniel, can we backport this patch to 4.2, please? It's a P1 regression! Not really. We've tried before, and it causes other regressions in 4.2 due to missing infrastructure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #3 from DHConsultancy at skynet dot be 2007-09-05 11:51 --- Subject: Re: gfortran crt2.o not found under Vista fxcoudert at gcc dot gnu dot org wrote: --- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:40 --- (In reply to comment #0) I'm trying to run gfortran under Windows Vista. Do you compile yourself or use pre-made binaries (and which binaries)? I use the binaries for version 4.2.2, native Windows version, from http://gcc.gnu.org/wiki/GFortranBinaries What does the compiler say when you add the -v flag? (gfortran -v myfile.f90) What is the value of your PATH environment variable? the compilation works fine, the error occurs at the link phase: ld: crt2.o: No such file: No such file or directory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #3 from steven at gcc dot gnu dot org 2007-09-05 12:35 --- You can connect the exits by inserting fake edges. See add_noreturn_fake_exit_edges and connect_infinite_loops_to_exit. Not sure which one you would need in this case. Just be sure to call it before computing (post)dominator info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug libgcj/33311] New: gcj: libgcj.spec: No such file or directory
Hello everyone. I'm sorry when it is here the wrong place for this.. and for my bad english. For the better understanding.. I must make a exe file from java source on Longhorn and i try this with Eclipse GCJ Builder Plugin. When I try to make a .exe file this error comes: Build Started mkdir -p debug/resource gcj -O0 -g --classpath=./src/; -c src/hallo.java -o src/hallo.o gcj -O0 -g --main=hallo src/hallo.o -odebug/nativeapp -Ldebug gcj.exe: src/hallo.o: No such file or directory gcj.exe: no input files make: *** [main] Error 1 Than I find something interesting out. Maybe that isn't my fault that the GCJ Compiler don't work. I have the MingW on the D: Drive and Eclipse on F: Now when I run gcj on F: drive in the cmd then comes these one error message: gcj: libgcj.spec: No such file or directory But when I run gcj on D: drive in the cmd then looks okay: gcj: no input files Is that a bug? P.S. thanks for your help -- Summary: gcj: libgcj.spec: No such file or directory Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: freeboy1212 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33311
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-05 12:41 --- Ah, I only found add_noreturn_fake_exit_edges which obviously didn't help. connect_infinite_loops_to_exit does. Thx. -- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-05 11:33:31 |2007-09-05 12:41:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-09-05 12:51 --- (In reply to comment #4) Ah, I only found add_noreturn_fake_exit_edges which obviously didn't help. connect_infinite_loops_to_exit does. Thx. dominance.c contains code (probably buggy) that adds such edges implicitly, so this should not be needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug target/33312] New: -march=native detects k8 and not k8-sse3
I have an AMD Athlon(tm) 64 X2 Dual Core Processor 4800+, which supports pni alias SSE3. If I run gfortran -v -O3 -march=native, then -march=k8 and not -march=k8-sse3 is used. -- Summary: -march=native detects k8 and not k8-sse3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33312
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #4 from DHConsultancy at skynet dot be 2007-09-05 12:58 ---
Subject: Re: gfortran crt2.o not found under Vista
I was hoping to avoid having to do the build. If all else fails, I'll
try it.
Thnx for your help.
dannysmith at users dot sourceforge dot net wrote:
--- Comment #2 from dannysmith at users dot sourceforge dot net
2007-09-04 06:17 ---
The solution is to build gcc/gfortran wiith -D__USE_MINGW_ACCESS in CFLAGS;
From mingw/include/io.h
/* Some defines for _access nAccessMode (MS doesn't define them, but
* it doesn't seem to hurt to add them). */
#define F_OK0 /* Check for file existence */
/* Well maybe it does hurt. On newer versions of MSVCRT, an access mode
of 1 causes invalid parameter error. */
#define X_OK1 /* MS access() doesn't check for execute permission.
*/
#define W_OK2 /* Check for write permission */
#define R_OK4 /* Check for read permission */
and later:
#ifdef __USE_MINGW_ACCESS
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code. This will restore the
old behaviour */
static inline int __mingw_access (const char* __fname, int __mode)
{ return _access (__fname, __mode ~X_OK); }
#define access(__f,__m) __mingw_access (__f, __m)
#endif
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug libgcj/33313] New: gcj: libgcj.spec: No such file or directory
Hello everyone. I'm sorry when it is here the wrong place for this.. and for my bad english. For the better understanding.. I must make a exe file from java source on Longhorn and i try this with Eclipse GCJ Builder Plugin. When I try to make a .exe file this error comes: Build Started mkdir -p debug/resource gcj -O0 -g --classpath=./src/; -c src/hallo.java -o src/hallo.o gcj -O0 -g --main=hallo src/hallo.o -odebug/nativeapp -Ldebug gcj.exe: src/hallo.o: No such file or directory gcj.exe: no input files make: *** [main] Error 1 Than I find something interesting out. Maybe that isn't my fault that the GCJ Compiler don't work. I have the MingW on the D: Drive and Eclipse on F: Now when I run gcj on F: drive in the cmd then comes these one error message: gcj: libgcj.spec: No such file or directory But when I run gcj on D: drive in the cmd then looks okay: gcj: no input files Is that a bug? P.S. thanks for your help -- Summary: gcj: libgcj.spec: No such file or directory Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: freeboy1212 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33313
[Bug target/33312] -march=native detects k8 and not k8-sse3
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-05 13:05 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00324.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||09/msg00324.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33312
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-05 13:25 --- (In reply to comment #2) The solution is to build gcc/gfortran wiith -D__USE_MINGW_ACCESS in CFLAGS It might be worth putting into the tree. Danny, would you be OK with the following? Index: configure.ac === --- configure.ac(revision 127859) +++ configure.ac(working copy) @@ -974,8 +974,10 @@ host_makefile_frag=config/mh-cygwin ;; *-mingw32*) +host_makefile_frag=config/mh-mingw ;; *-mingw64*) +host_makefile_frag=config/mh-mingw ;; *-interix*) host_makefile_frag=config/mh-interix Index: config/mh-mingw === --- config/mh-mingw (revision 0) +++ config/mh-mingw (revision 0) @@ -0,0 +1,3 @@ +# Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows +# Vista (see PR33281 for details). +BOOT_CFLAGS += -D__USE_MINGW_ACCESS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #8 from pault at gcc dot gnu dot org 2007-09-05 13:34 --- Subject: Bug 31564 Author: pault Date: Wed Sep 5 13:34:25 2007 New Revision: 128130 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128130 Log: 2007-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/31564 * primary.c (gfc_match_rvalue): Make expressions that refer to derived type parameters that have array references into variable expressions. Remove references to use association from the symbol. PR fortran/33241 * decl.c (add_init_expr_to_sym): Provide assumed character length parameters with the length of the initialization expression, if a constant, or that of the first element of an array. 2007-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/31564 * gfortran.dg/derived_comp_array_ref_2.f90: New test. PR fortran/33241 * gfortran.dg/char_length_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_10.f90 trunk/gcc/testsuite/gfortran.dg/derived_comp_array_ref_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #6 from pault at gcc dot gnu dot org 2007-09-05 13:34 --- Subject: Bug 33241 Author: pault Date: Wed Sep 5 13:34:25 2007 New Revision: 128130 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128130 Log: 2007-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/31564 * primary.c (gfc_match_rvalue): Make expressions that refer to derived type parameters that have array references into variable expressions. Remove references to use association from the symbol. PR fortran/33241 * decl.c (add_init_expr_to_sym): Provide assumed character length parameters with the length of the initialization expression, if a constant, or that of the first element of an array. 2007-09-05 Paul Thomas [EMAIL PROTECTED] PR fortran/31564 * gfortran.dg/derived_comp_array_ref_2.f90: New test. PR fortran/33241 * gfortran.dg/char_length_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_10.f90 trunk/gcc/testsuite/gfortran.dg/derived_comp_array_ref_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #7 from pault at gcc dot gnu dot org 2007-09-05 13:37 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #9 from pault at gcc dot gnu dot org 2007-09-05 13:38 --- Fixed on trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug tree-optimization/33107] [4.3 regression] segfault in garbage collector
--- Comment #3 from jakub at gcc dot gnu dot org 2007-09-05 13:59 --- This testcase with ENABLE_GC_ALWAYS_COLLECT ICEs here in validate_free_objects in r127491, but is cured by the http://gcc.gnu.org/viewcvs?root=gccview=revrev=127946 fix, at which point it compiles just fine with always collect. Marcus, if you can still reproduce it with r127491 on the original non-preprocessed testcase, can you please apply the r127946 fix and retry? -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33107
[Bug tree-optimization/33107] [4.3 regression] segfault in garbage collector
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-05 14:03 --- Given the backtrace I believe it is the same issue, particularly that __builtin___strcpy_chk call was folded into __builtin_strcpy, set_rhs copied over the annotations from the former to the latter CALL_EXPR, but cgraph_edge still contained a pointer to the old CALL_EXPR. When clearing up annotations, delete_tree_cfg_annotations would ggc_free the annotation from latter CALL_EXPR and later on during ggc_collect when marking the cgraph_edge's call_stmt GC crashed, because we were trying to mark something that has been already ggc_freed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33107
[Bug fortran/33162] INTRINSIC functions as ACTUAL argument
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-05 14:14 --- Besides the argument kind checking of specific intrinsic procedures and besides using specific intrinsic as name in the PROCEDURE statement, the following fails as well. The error message is: Error: Type/rank mismatch in argument 'a' at (1) This program works with NAG f95, g95, ifort, openf95 ... module m implicit none contains subroutine sub(a) interface function a(x) real :: a, x intent(in) :: x end function a end interface optional :: a if(present(a)) print *, a(4.0) end subroutine sub end module m use m implicit none intrinsic cos call sub() call sub(cos) end -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||30871 nThis|| Keywords||rejects-valid Summary|Type checking absent for|INTRINSIC functions as |specific names of INTRINSIC |ACTUAL argument |functions | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #6 from rguenther at suse dot de 2007-09-05 14:17 ---
Subject: Re: dead-store not eliminated
On Wed, 5 Sep 2007, rakdver at gcc dot gnu dot org wrote:
(In reply to comment #4)
Ah, I only found add_noreturn_fake_exit_edges which obviously didn't help.
connect_infinite_loops_to_exit does. Thx.
dominance.c contains code (probably buggy) that adds such edges implicitly, so
this should not be needed.
Maybe, but then domwalk.c is buggy as walk_dominator_tree does
while (true)
{
/* Don't worry about unreachable blocks. */
if (EDGE_COUNT (bb-preds) 0 || bb == ENTRY_BLOCK_PTR)
{
and obviously in my case bb (the exit block) has no preds. Maybe
simply special-casing EXIT_BLOCK_PTR as well helps.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug c++/33314] New: Ill-formed program compiles without error. Ternary (expr.cond) operands, ambiguous conversion.
Steps:
g++ -Wall ternary-ambiguous-no-error.cpp
Expected behavior:
I believe that the program below is ill-formed, because both implicit
conversions MyString -- const char* are possible.
G++ should issue an error (or at least a warning).
From [5.16/3]:
Using this process, it is determined whether the second operand can be
converted to match the third operand, and whether the third operand can be
converted to match the second operand. If both can be converted, or one can be
converted but the conversion is ambiguous, the program is ill-formed.
Actual behavior:
G++ doesn't report that. It chooses one of two ambiguous conversions and
compiles cleanly.
Used version:
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
#include string
#include iostream
class MyString
{
public:
MyString(const char* s)
{
m_s = s;
}
operator const char*() const
{
return surprise;
}
std::ostream operator(std::ostream os)
{
return os m_s;
}
private:
std::string m_s;
};
int main(int argc, char* argv[])
{
bool isEmpty = false;
MyString s0(OK);
MyString s1 = (isEmpty) ? : s0; /* s1 is surprise; expected compile error
here, because both implicit conversions MyString -- const char* are possible.
*/
std::cout s1 std::endl;
return 0;
}
--
Summary: Ill-formed program compiles without error. Ternary
(expr.cond) operands, ambiguous conversion.
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: test dot 007 at seznam dot cz
GCC build triplet: i686-apple-darwin8
GCC host triplet: i686-apple-darwin8
GCC target triplet: i686-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33314
[Bug tree-optimization/33302] dead-store not eliminated
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-09-05
14:30 ---
Subject: Re: dead-store not eliminated
Ah, I only found add_noreturn_fake_exit_edges which obviously didn't help.
connect_infinite_loops_to_exit does. Thx.
dominance.c contains code (probably buggy) that adds such edges implicitly,
so
this should not be needed.
Maybe, but then domwalk.c is buggy as walk_dominator_tree does
while (true)
{
/* Don't worry about unreachable blocks. */
if (EDGE_COUNT (bb-preds) 0 || bb == ENTRY_BLOCK_PTR)
{
and obviously in my case bb (the exit block) has no preds. Maybe
simply special-casing EXIT_BLOCK_PTR as well helps.
Yes, that seems reasonable (I think domwalk was originally only used
for dominator tree walks, so it may contain this kind of bugs for
post-dominator walks)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug libgcj/33311] gcj: libgcj.spec: No such file or directory
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-05 14:36 --- *** Bug 33313 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33311
[Bug libgcj/33313] gcj: libgcj.spec: No such file or directory
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-05 14:36 --- *** This bug has been marked as a duplicate of 33311 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|gcj: libgcj.spec: No such |gcj: libgcj.spec: No such |file or directory |file or directory http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33313
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2007-09-05
14:39 ---
Not specific to tru64 and can be reproduced with an alpha-unknown-linux-gnu
cross compiler with --with-long-double-128. Worked at least with r127312.
Testcase:
typedef float TFtype __attribute__ ((mode (TF)));
int __powitf2 (TFtype x, int m)
{
unsigned int n = m 0 ? -m : m;
TFtype y = n % 2 ? x : 1;
return m 0 ? 1/y : y;
}
(small nitpick: please don't set or change bug's priority field: it is RM's
prerogative)
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
CC||belyshev at depni dot sinp
||dot msu dot ru
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|alpha-dec-osf5.1b |
GCC host triplet|alpha-dec-osf5.1b |
GCC target triplet|alpha-dec-osf5.1b |
Keywords||build, ice-on-valid-code
Priority|P2 |P3
Last reconfirmed|-00-00 00:00:00 |2007-09-05 14:39:39
date||
Summary|[4.3 regression] Bootstrap |[4.3 regression] Bootstrap
|failure on Tru64 UNIX V5.1B:|failure on alpha: ICE in
|ICE in convert_move, at |convert_move, at expr.c:369
|expr.c:369 |
Target Milestone|--- |4.3.0
Version|unknown |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2007-09-05 14:54 --- Subject: Re: [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369 belyshev at depni dot sinp dot msu dot ru writes: Not specific to tru64 and can be reproduced with an alpha-unknown-linux-gnu cross compiler with --with-long-double-128. Worked at least with r127312. makes sense: that's the primary difference between alpha-dec-osf4.0f (which works) and alpha-dec-osf5.1b (which does not). I'm currently running a reghunt to identify the culprit patch. (small nitpick: please don't set or change bug's priority field: it is RM's prerogative) It is set by the gccbug which I use to submit PRs. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug fortran/33308] gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
--- Comment #4 from t_nissie at yahoo dot co dot jp 2007-09-05 14:56 --- I did checkout the current trunk, compiled it, and use it for the attached reshapetest.f90 and my program. It works fine. I changed status to RESOLVED and resolution to FIXED. Is it OK? Thank you for your constant efforts at developing gfortran and gcc. I like gcc and gfortran very much, especially the new OpenMP feature. Takeshi -- t_nissie at yahoo dot co dot jp changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug bootstrap/33309] gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualifiers from pointer target type
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-05 15:08 --- Subject: Re: gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualifiers from pointer target type --- Comment #2 from ghazi at gcc dot gnu dot org 2007-09-05 06:17 --- (In reply to comment #1) I think I'll let Kaveh fix this one... To what exactly do I owe this honor? :-) Insufficient research on my part ;( Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug fortran/33308] gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-05 15:12 --- I changed status to RESOLVED and resolution to FIXED. Is it OK? This is OK. (Another possibility would have be wontfix in 4.2.x; I never know which alternative is better.) Thank you for your constant efforts at developing gfortran and gcc. Thanks you for taking the time do make a bug report; gfortran relies on the users finding and reporting bugs (including, e.g., accepting invalid Fortran, unclear documentation etc.). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug tree-optimization/33107] [4.3 regression] segfault in garbage collector
--- Comment #5 from marcus at jet dot franken dot de 2007-09-05 15:22 --- its was happening for various SVN revisions, and now no longer does. And there is a strcpy() in the function, so it might just be the same. I guess it is fixed :) -- marcus at jet dot franken dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33107
[Bug target/33138] [4.3 Regression] rejects valid? assembler, segfaults
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-05 15:42 --- Yeah, the asm is bogus for multiple reasons. But can be fixed easily, e.g. %3, %4 nor %5 aren't used anywhere, so just nuking the unneeded r (c), r (a), r (b), makes this to compile. Apparently e.g. gcc 4.1.x decided to give %0 the same register %3, %1 as %4 and so it happened to compile, still the constraints cause extreme register preassure. What is that 3 doing among clobbers? A fancy way to duplicate %rbx clobber? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33138
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-05 15:58 --- Daniel, Can you try the updated binaries at http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe ? They are built with the patch in comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug bootstrap/33309] gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualifiers from pointer target type
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-09-05 16:04 --- (In reply to comment #3) (In reply to comment #2) Another option would be to constify xputenv and use CONST_CAST on the argument passed to putenv. Like this? + putenv (CONST_CAST (string)); Almost, CONST_CAST takes a type argument now: CONST_CAST (char *, string) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug c++/15097] code generator problem with ::delete and multiple inheritance and virtual deconstructs
--- Comment #4 from jason at gcc dot gnu dot org 2007-09-05 16:08 --- The reduced testcase breaks in the same way with ICC 10.0.023 if I add a user-defined operator delete to B2. If I add it to D instead, ICC incorrectly calls the user-defined delete instead of the global delete in the calls to f2 and f3. This seems to be a standards and/or ABI problem. The standard clearly states that the global delete will be used if you say ::delete, but the C++ ABI doesn't provide any mechanism for that. EDG seem to be trying to split the difference by using the deleting destructor if the static type doesn't have an operator delete, but that's wrong if the dynamic type of the object does. It seems that the solution would be to return the true address as void* from a virtual destructor, or add another deleting destructor that uses the global operator delete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15097
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #11 from dje at watson dot ibm dot com 2007-09-05 17:13 ---
Subject: Re: nint_2.f90 abort compiled with -O0
fxcoudert at gcc dot gnu dot org writes:
FX look into ${builddir}/${target_triplet}/libgfortran/config.h to
FX see what value have the HAVE_LROUND{F,,L} and HAVE_LLROUND{F,,L} macros?
/* libm includes llround */
#define HAVE_LLROUND 1
/* libm includes llroundf */
#define HAVE_LLROUNDF 1
/* libm includes llroundl */
#define HAVE_LLROUNDL 1
/* libm includes lround */
#define HAVE_LROUND 1
/* libm includes lroundf */
#define HAVE_LROUNDF 1
/* libm includes lroundl */
#define HAVE_LROUNDL 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #12 from dje at watson dot ibm dot com 2007-09-05 17:19 --- Subject: Re: nint_2.f90 abort compiled with -O0 fxcoudert at gcc dot gnu dot org writes: FX David, could you test my C program in comment #4 $ ./xgcc -B./ -W -Wall -O1 fx.c fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type $ ./a.out 4 4 8 $ ./xgcc -B./ -W -Wall -O0 fx.c fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type ld: 0711-317 ERROR: Undefined symbol: .lround ld: 0711-317 ERROR: Undefined symbol: .lroundf ld: 0711-317 ERROR: Undefined symbol: .llround $ ./xgcc -B./ -W -Wall -O0 fx.c -lm fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type $ ./a.out 4 4 8 Abort 1 $ ./xgcc -B./ -maix64 -W -Wall -O1 fx.c $ ./a.out 4 8 8 $ ./xgcc -B./ -maix64 -W -Wall -O0 fx.c -lm $ ./a.out 4 8 8 Abort 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug preprocessor/33305] We should warn about empty macro arguments
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-09-05 17:29 --- Anyone know where in the preprocessor this should be done? I.e. which function in libcpp? If someone would let me know, I'll write a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #11 from daney at gcc dot gnu dot org 2007-09-05 17:34 ---
I am bootstrapping the 'Proposed patch' on mipsel-linux with this test case
added:
/* { dg-do compile } */
/* { dg-mips-options -O2 -EB -mabi=64 -msym32 -mno-abicalls -march=mips64 }
*/
extern unsigned long a[];
int b(int x);
int c()
{
return b(a[0]);
}
--
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33312] -march=native detects k8 and not k8-sse3
--- Comment #2 from ubizjak at gmail dot com 2007-09-05 17:46 --- Fixed by http://gcc.gnu.org/viewcvs?view=revrevision=128141 -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords|missed-optimization | Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33312
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2007-09-05 18:09 --- Subject: Re: [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369 A reghunt revealed that this patch 2007-08-31 Richard Sandiford [EMAIL PROTECTED] * optabs.c (shift_optab_p, commutative_optab_p): New functions, split out from expand_binop. (avoid_expensive_constant): New function. (expand_binop_directly): Remove commutative_op argument and call cummutative_optab_p instead. Do not change op0 or op1 when swapping xop0 and xop1. Apply avoid_expensive_constant to each argument after potential swapping. Enforce the canonical order of commutative operands. (expand_binop): Use shift_optab_p and commutative_optab_p. Update the calls to expand_binop_directly. Only force constants into registers when widening an operation. Only swap operands once a direct expansion has been rejected. (expand_twoval_binop): Only force constants into registers when using a direct expansion. is the culprit. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug c++/33207] [4.3 regression] ICE redeclaring namespace as struct
--- Comment #2 from simartin at gcc dot gnu dot org 2007-09-05 18:32 --- I'm testing a patch for this one. -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |simartin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-01 19:57:15 |2007-09-05 18:32:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33207
[Bug target/33138] [4.3 Regression] rejects valid? assembler, segfaults
--- Comment #5 from tbm at cyrius dot com 2007-09-05 18:38 --- (In reply to comment #4) Yeah, the asm is bogus for multiple reasons. ... What is that 3 doing among clobbers? A fancy way to duplicate %rbx clobber? I don't know. I made the testcase based on an application that I found in Debian. I'll forward your comments to the developer of that application to make them aware of the problems with their code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33138
[Bug middle-end/33315] New: If condition not getting eliminated
if ( x == 8 ) statement1 if ( x != 8 ) statement1 if ( x == 9 ) statement2 if ( x != 9 ) statement2 should be replaced by statement1 statement2 However this doesnt happen and compare and jumps do get generated. -- Summary: If condition not getting eliminated Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pranav dot bhandarkar at gmail dot com GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug libstdc++/33203] [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-05 19:00 --- A patch is at: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00310.html Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-05 19:00:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203
[Bug middle-end/33315] If condition not getting eliminated
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-09-05 19:03 --- Created an attachment (id=14158) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14158action=view) Sample Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug c++/30302] [4.0/4.1/4.2/4.3 regression] ICE with invalid member in anonymous struct
--- Comment #5 from paolo at gcc dot gnu dot org 2007-09-05 19:10 --- Subject: Bug 30302 Author: paolo Date: Wed Sep 5 19:10:48 2007 New Revision: 128145 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128145 Log: /cp 2007-09-03 Paolo Carlini [EMAIL PROTECTED] PR c++/30302 * semantics.c (finish_id_expression): Check that path != NULL_TREE before using TYPE_BINFO on it. * class.c (finish_struct_anon): Deal correctly with anonymous structs (vs unions, as GNU extension) in error messages. /testsuite 2007-09-03 Paolo Carlini [EMAIL PROTECTED] PR c++/30302 * g++.dg/ext/anon-struct5.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/anon-struct5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30302
[Bug c++/30302] [4.0/4.1/4.2 regression] ICE with invalid member in anonymous struct
--- Comment #6 from pcarlini at suse dot de 2007-09-05 19:12 --- Fixed in mainline. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE |ICE with invalid member in |with invalid member in |anonymous struct|anonymous struct http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30302
[Bug bootstrap/33306] [4.3 regression] Bootstrap failure on alpha: ICE in convert_move, at expr.c:369
--- Comment #4 from rsandifo at gcc dot gnu dot org 2007-09-05 19:19 --- Created an attachment (id=14159) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14159action=view) Proposed patch Sorry for the breakage. Could you try the attached patch? It seems to fix the problem on a cross compiler. I think it's the right fix because (a) the rest of expand_binop_directly is careful to pass unmodified operands when the expander does not specify a mode, and (b) that's what we'd do when not optimising. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug web/32965] missing documentation for -ftree-dse
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-05 19:48 --- Subject: Bug 32965 Author: rask Date: Wed Sep 5 19:47:56 2007 New Revision: 128146 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128146 Log: PR web/32965 PR tree-optimization/13756 * doc/invoke.texi (Options That Control Optimization): Document -ftree-dse. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
[Bug tree-optimization/13756] [tree-ssa] documentation missing
--- Comment #14 from rask at gcc dot gnu dot org 2007-09-05 19:48 --- Subject: Bug 13756 Author: rask Date: Wed Sep 5 19:47:56 2007 New Revision: 128146 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128146 Log: PR web/32965 PR tree-optimization/13756 * doc/invoke.texi (Options That Control Optimization): Document -ftree-dse. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13756
[Bug tree-optimization/21513] [4.0/4.1/4.2 Regression] __builtin_expect getting in the way of uninitialized warnings
--- Comment #8 from nemet at gcc dot gnu dot org 2007-09-05 19:54 --- Subject: Bug 21513 Author: nemet Date: Wed Sep 5 19:54:29 2007 New Revision: 128147 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128147 Log: PR tree-optimization/21513 * builtins.c (build_builtin_expect_predicate): New function. (fold_builtin_expect): Add argument for expected value. Distribute __builtin_expect over short-circuiting operations. Fold nested builtin_expects. (fold_builtin_2): Adjust call to fold_builtin_expect. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21513
[Bug web/32965] missing documentation for -ftree-dse
--- Comment #4 from rask at gcc dot gnu dot org 2007-09-05 19:56 --- Fixed with revision 128146. The online documentation will be updated automatically within 24 hours. -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
[Bug c/33316] New: [4.2.1 regression] ICE on valid variable-length automatic array in const struct
The following gives an ICE when compiled with -g. Removing -g, removing the
const or making data[] a constant size will allow it to be compiled.
int f(void *p, int length)
{
const struct {
int data[length];
} *array = p;
return array[0].data[0];
}
$ gcc -g -c t.c
t.c: In function f:
t.c:8: internal compiler error: Segmentation fault
$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c
Thread model: posix
gcc version 4.2.1
--
Summary: [4.2.1 regression] ICE on valid variable-length
automatic array in const struct
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: radford at blackbean dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33316
[Bug debug/33316] [4.2/4.3 regression] ICE on valid variable-length automatic array in const struct
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-05 20:20 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu|dwarf2 Keywords||ice-on-valid-code Known to fail||4.2.0 4.3.0 Known to work||4.1.1 Last reconfirmed|-00-00 00:00:00 |2007-09-05 20:20:59 date|| Summary|[4.2 regression] ICE on |[4.2/4.3 regression] ICE on |valid variable-length |valid variable-length |automatic array in const|automatic array in const |struct |struct Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33316
[Bug debug/33316] [4.2/4.3 regression] ICE on valid variable-length automatic array in const struct
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-05 20:24 --- This looks similar to PR29970. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33316
[Bug debug/33316] [4.2/4.3 regression] ICE on valid variable-length automatic array in const struct
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-05 20:26 --- (In reply to comment #2) This looks similar to PR29970. It is unrelated. There is no leak of a type here. The issue is we are looking at the type's name which does not exist or something like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33316
[Bug middle-end/33315] [4.3 Regression] If condition not getting eliminated
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-05 20:34 --- This is related to PR32306 and to the fact that we don't have a code hoisting pass. And related to PR30905 because cross-jumping fixes this up on the rtl-level for both gcc 4.1 and 4.2: test: pushl %ebp movl%esp, %ebp popl%ebp movl$0, a movl$0, a+4 movl$0, a+8 ret -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spark at gcc dot gnu dot org BugsThisDependsOn||30905 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-09-05 20:34:09 date|| Summary|If condition not getting|[4.3 Regression] If |eliminated |condition not getting ||eliminated Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-09-05 20:48 --- Created an attachment (id=14160) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14160action=view) 4.2 patch I've now regression-tested the original patch for mipsisa32r2-sde-elf. I've also regression-tested the attached patch for mips64-elf on 4.2 and 4.1. (The 4.2 version includes the testcase I used for all three runs. I've not forced -EB because that fails for -EL multilibs, and we want this test to work for both anyway.) I'll wait for David's results too and commit if all is well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #13 from ddaney at avtrex dot com 2007-09-05 20:57 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 rsandifo at gcc dot gnu dot org wrote: I've not forced -EB because that fails for -EL multilibs, and we want this test to work for both anyway.) Are you sure? On the trunk I tested on mipsel-linux with -EB and it seems to work. For a compile only test it should work on little-endian system. David Daney -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug fortran/33317] New: CSHIFT: Crash if variable passed to DIM= is not present
The following program should print twice T T T T as if DIM is not present, 1 is assumed. The standard does not forbid to pass a variable which has the OPTIONAL attribute to CSHIFT. NAG f95 and ifort print as expected twice T T T T. gfortran simply crashes. program test implicit none call sub(1) call sub() contains subroutine sub(d) integer, optional :: d print *, cshift([.true.,.true.,.true.,.true.],1,d) end subroutine end program test -- Summary: CSHIFT: Crash if variable passed to DIM= is not present Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug fortran/33317] CSHIFT/EOSHIFT: Crash if variable passed to DIM= is not present
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-05 21:04 --- Same for EOSHIFT, example (replace in above's program) print *, eoshift([.true.,.true.,.true.,.true.],1,dim=d) ifort and NAG f95 print twice T T T F. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|CSHIFT: Crash if variable |CSHIFT/EOSHIFT: Crash if |passed to DIM= is not |variable passed to DIM= is |present |not present http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #14 from richard at codesourcery dot com 2007-09-05 21:08
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
ddaney at avtrex dot com [EMAIL PROTECTED] writes:
I've not forced -EB because that fails for -EL
multilibs, and we want this test to work for both anyway.)
Are you sure? On the trunk I tested on mipsel-linux with -EB and it
seems to work. For a compile only test it should work on little-endian
system.
I mean that it fails if you explicitly test -EL multilibs. E.g. on
mipsisa64-elf, I normally test mips-sim{,-msoft-float}{-EB,-EL}, and
the compiler will complain at having both -EL and -EB on the command line.
We could make mips.exp skip the test when -EL is forced, but it seems
more useful to run it regardless. Or we could use target selectors to
select between two dg-mips-options lines depending on whether -EL has
been added to the multilib flags. However, it seems odd to test
big-endian (only) on little-endian systems when -EL is not explicitly
given, but test little-endian when -EL _is_ explicitly (and redundantly)
given.
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug fortran/33307] I/O read/positioning problem
--- Comment #3 from anlauf at gmx dot de 2007-09-05 21:09 --- Created an attachment (id=14161) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14161action=view) Alternative demo code This reduced variant shows that reading fails after the second rewind. With the same 3-line input file gfcbug69.nml I now get: inquire: after OPEN: position = ASIS nextrec = 0 k = 1 inquire: after REWIND: position = REWINDnextrec = 0 1: read: ! ***Remove this line*** 2: read: FOOfile='foo' / inquire: after read_lines (2): position = ASIS nextrec = 0 inquire: after BACKSPACE: position = ASIS nextrec = 0 1: read: FOOfile='foo' / 2: read: BARfile='bar' / inquire: after read_lines (many): position = APPENDnextrec = 0 inquire: after BACKSPACE: position = APPENDnextrec = 0 k = 2 inquire: after REWIND: position = REWINDnextrec = 0 inquire: after read_lines (2): position = REWINDnextrec = 0 inquire: after BACKSPACE: position = REWINDnextrec = 0 inquire: after read_lines (many): position = REWINDnextrec = 0 inquire: after BACKSPACE: position = REWINDnextrec = 0 During the second execution of the loop body no lines are read. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #15 from ddaney at avtrex dot com 2007-09-05 21:15 ---
Subject: Re: internal compiler error: in print_operand_reloc,
at config/mips/mips.c:5579
richard at codesourcery dot com wrote:
--- Comment #14 from richard at codesourcery dot com 2007-09-05 21:08
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
ddaney at avtrex dot com [EMAIL PROTECTED] writes:
I've not forced -EB because that fails for -EL
multilibs, and we want this test to work for both anyway.)
Are you sure? On the trunk I tested on mipsel-linux with -EB and it
seems to work. For a compile only test it should work on little-endian
system.
I mean that it fails if you explicitly test -EL multilibs. E.g. on
mipsisa64-elf, I normally test mips-sim{,-msoft-float}{-EB,-EL}, and
the compiler will complain at having both -EL and -EB on the command line.
We could make mips.exp skip the test when -EL is forced, but it seems
more useful to run it regardless. Or we could use target selectors to
select between two dg-mips-options lines depending on whether -EL has
been added to the multilib flags. However, it seems odd to test
big-endian (only) on little-endian systems when -EL is not explicitly
given, but test little-endian when -EL _is_ explicitly (and redundantly)
given.
My concern was that the bug only occurs for me with -EB, so running the
test case with -EL would be pointless. I understand that you do most of
your testing on the simulator, but for someone doing testing on little
endian hardware there is no coverage without the -EB.
David Daney
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug bootstrap/33318] New: fortran/expr.c:305: internal compiler error: internal consistency failure
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwr
ite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmi
ssing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG
_H -I. -Ifortran -I../../gcc/gcc -I../../gcc/gcc/fortran
-I../../gcc/gcc/../incl
ude -I../../gcc/gcc/../libcpp/include -I/opt/gnu64/gcc/gcc-4.3.0/include
-I../.
./gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc/gcc/fortran/expr.c -o fortran/expr.o
../../gcc/gcc/fortran/expr.c: In function 'copy_ref':
../../gcc/gcc/fortran/expr.c:305: error: invalid rtl sharing found in the insn
(jump_insn 25 100 101 5 ../../gcc/gcc/fortran/expr.c:283 (set (pc)
(if_then_else (eq (subreg/s/u:SI (reg:DI 71 [ D.8737 ]) 4)
(const_int 0 [0x0]))
(label_ref 29)
(pc))) 46 {*pa.md:1770} (expr_list:REG_BR_PROB (const_int 5000
[0x13
88])
(nil)))
../../gcc/gcc/fortran/expr.c:305: error: shared rtx
(subreg/s/u:SI (reg:DI 71 [ D.8737 ]) 4)
../../gcc/gcc/fortran/expr.c:305: internal compiler error: internal consistency
failure
--
Summary: fortran/expr.c:305: internal compiler error: internal
consistency failure
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa64-hp-hpux11.11
GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33318
[Bug fortran/33317] CSHIFT/EOSHIFT: Rejects optional dummy for DIM=
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-05 21:20 --- Correction: gfortran rejects this currently and does not accept it and crash; better than crashing but still wrong. (I modified check.c's dim_check and enabled it accidentally.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code |rejects-valid Summary|CSHIFT/EOSHIFT: Crash if|CSHIFT/EOSHIFT: Rejects |variable passed to DIM= is |optional dummy for DIM= |not present | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33317
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 ddaney at avtrex dot com [EMAIL PROTECTED] writes: My concern was that the bug only occurs for me with -EB, so running the test case with -EL would be pointless. I understand that you do most of your testing on the simulator, but for someone doing testing on little endian hardware there is no coverage without the -EB. OK. As I said before, I didn't think it would be pointless, because we do want to make sure this continues to work for -EL too. (There's generally very little coverage of -mabi=64 -msym32; the only user I know of is linux.) However, I'll yield and make mips.exp skip the test when running explicitly-EL multilibs. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #17 from ddaney at avtrex dot com 2007-09-05 21:36 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 richard at codesourcery dot com wrote: --- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22 --- Subject: Re: internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579 ddaney at avtrex dot com [EMAIL PROTECTED] writes: My concern was that the bug only occurs for me with -EB, so running the test case with -EL would be pointless. I understand that you do most of your testing on the simulator, but for someone doing testing on little endian hardware there is no coverage without the -EB. OK. As I said before, I didn't think it would be pointless, because we do want to make sure this continues to work for -EL too. The only time loading the low order bits of a word is done at an offset from the base of the word is in big endian. So I don't think it will ever fail on a little endian system, but I may be missing something. (There's generally very little coverage of -mabi=64 -msym32; the only user I know of is linux.) However, I'll yield and make mips.exp skip the test when running explicitly-EL multilibs. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #18 from richard at codesourcery dot com 2007-09-05 21:44
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
ddaney at avtrex dot com [EMAIL PROTECTED] writes:
richard at codesourcery dot com wrote:
--- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
ddaney at avtrex dot com [EMAIL PROTECTED] writes:
My concern was that the bug only occurs for me with -EB, so running the
test case with -EL would be pointless. I understand that you do most of
your testing on the simulator, but for someone doing testing on little
endian hardware there is no coverage without the -EB.
OK. As I said before, I didn't think it would be pointless, because
we do want to make sure this continues to work for -EL too.
The only time loading the low order bits of a word is done at an offset
from the base of the word is in big endian. So I don't think it will
ever fail on a little endian system, but I may be missing something.
Yes, I realise that, but I meant that you can't really assume very much
about -mabi=64 -msym32 -EL at all from a mips{64,}{,-el}-linux-gnu run.
At least allowing the test to be run in little-endian would have provided
some coverage, and people were still going to notice if the -EB case
regressed.
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug bootstrap/33318] fortran/expr.c:305: internal compiler error: internal consistency failure
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-09-05 22:30 --- Created an attachment (id=14162) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14162action=view) fix does the attached patch fix the bootstrap problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33318
[Bug middle-end/33318] [4.3 Regression] fortran/expr.c:305: internal compiler error: internal consistency failure
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33318
