[Bug target/32389] [4.1/4.2 Regression] ICE in extract_constrain_insn_cached when using -msse
--- Comment #4 from uros at gcc dot gnu dot org 2007-06-21 07:06 --- Subject: Bug 32389 Author: uros Date: Thu Jun 21 07:06:29 2007 New Revision: 125911 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125911 Log: PR target/32389 * config/i386/i386.h (enum ix86_stack_slot): Add SLOT_VIRTUAL. * config/i386/i386.c (assign_386_stack_local): Assert that SLOT_VIRTUAL is valid only before virtual regs are instantiated. (ix86_expand_builtin) [IX86_BUILTIN_LDMXCSR, IX86_BUILTIN_STMXCSR]: Use SLOT_VIRTUAL stack slot instead of SLOT_TEMP. * config/i386/i386.md (truncdfsf2, truncxfsf2, truncxfdf2): Ditto. testsuite/ChangeLog: PR target/32389 * gcc.target/i386/pr32389.c New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr32389.c - copied unchanged from r125830, trunk/gcc/testsuite/gcc.target/i386/pr32389.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.c branches/gcc-4_2-branch/gcc/config/i386/i386.h branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32389
[Bug target/32389] [4.1/4.2 Regression] ICE in extract_constrain_insn_cached when using -msse
--- Comment #5 from uros at gcc dot gnu dot org 2007-06-21 07:13 --- Subject: Bug 32389 Author: uros Date: Thu Jun 21 07:13:16 2007 New Revision: 125912 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125912 Log: PR target/32389 * config/i386/i386.h (enum ix86_stack_slot): Add SLOT_VIRTUAL. * config/i386/i386.c (assign_386_stack_local): Assert that SLOT_VIRTUAL is valid only before virtual regs are instantiated. (ix86_expand_builtin) [IX86_BUILTIN_LDMXCSR, IX86_BUILTIN_STMXCSR]: Use SLOT_VIRTUAL stack slot instead of SLOT_TEMP. * config/i386/i386.md (truncdfsf2, truncxfsf2, truncxfdf2): Ditto. testsuite/ChangeLog: PR target/32389 * gcc.target/i386/pr32389.c New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr32389.c - copied unchanged from r125830, trunk/gcc/testsuite/gcc.target/i386/pr32389.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/config/i386/i386.h branches/gcc-4_1-branch/gcc/config/i386/i386.md branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32389
[Bug target/32389] [4.1/4.2 Regression] ICE in extract_constrain_insn_cached when using -msse
--- Comment #6 from ubizjak at gmail dot com 2007-06-21 07:14 --- Fixed on branches. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32389
[Bug c/32449] New: declaring �strcmp()� as an extern function with inclusion of �string.h� is causing compilation error
Hi,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problems while compiling the following testcase-
--
TESTCASE
#include
#include
extern int strcmp(const char *,const char *);
int main()
{
char s1[3];
char s2[3];
strcpy(s1,"12");
strcpy(s2,"2");
printf("\n\t %d",strcmp(s1,s2));
return 0;
}
-
PROBLEM
The above testcase gets compiled with '-O0' optimization successfully
Â
/sh4-linux-gcc testcase.c Âo a.out ÂO0
but on compilation with '-O2' optimization option--
Â
/sh4-linux-gcc testcase.c Âo a.out ÂO2
it gives the following
error:-
testcase.c:4: error: expected identifier or Â(Â before Â__extension__Â
testcase.c:4: error: expected identifier or Â(Â before Â)Â token
OBSERVATIONS
1. In the above testcase, declaring Âstrcmp()Â as an extern function with
inclusion of Âstring.h is causing the above mentioned compilation error. But
on the other hand, if either of the two scenarios is used i.e. either
Âstring.h is included or Âstrcmp() is declared as an extern function only,
then it compiles successfully with ÂO2 option.
2. This problem has been observed with
sh-linux toolchain (gcc-4.2)
i686-pc-linux toolchain (gcc-4.1.1, Fedora Core 6)
i686-pc-linux toolchain (gcc-4.2.0)
Any help on this will be appreciated.
Regards,
Suma Sharma
KPIT Cummins Infosystems Ltd,
Pune (INDIA)
~~
Free download of GNU based SH-Linux toolchains for Renesas' SH Series.
The following site also offers free technical support to its users.
Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU SH-Linux tools were released on April 5, 2007.
~
--
Summary: declaring Âstrcmp()Â as an extern function with
inclusion of Âstring.h is causing compilation error
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suma dot sharma at kpitcummins dot com
GCC build triplet: i686-pc-linux
GCC host triplet: sh4-unknown-linux
GCC target triplet: sh4-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32449
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #20 from rguenther at suse dot de 2007-06-21 07:59 ---
Subject: Re: ICE: fold check: original tree changed
by fold with --enable-checking=fold
On Thu, 20 Jun 2007, spop at gcc dot gnu dot org wrote:
>
>
> --- Comment #17 from spop at gcc dot gnu dot org 2007-06-20 22:58 ---
> Subject: Re: ICE: fold check: original tree changed by fold with
> --enable-checking=fold
>
> Hi,
>
> The following patch fixes a part of the reported testsuite fails.
> With this patch we avoid folding the TREE_CHAIN of an SSA_NAME, that
> corresponds to its SSA_NAME_DEF_STMT.
>
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c(revision 125883)
> +++ gcc/fold-const.c(working copy)
> @@ -12775,7 +12775,8 @@ recursive_label:
>fold_checksum_tree (TREE_TYPE (expr), ctx, ht);
>if (TREE_CODE_CLASS (code) != tcc_type
>&& TREE_CODE_CLASS (code) != tcc_declaration
> - && code != TREE_LIST)
> + && code != TREE_LIST
> + && code != SSA_NAME)
> fold_checksum_tree (TREE_CHAIN (expr), ctx, ht);
>switch (TREE_CODE_CLASS (code))
> {
>
> The only fails that remain when compiling with default languages and
> --enable-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree
> on i686-linux are:
>
> gcc.c-torture/compile/20021108-1.c
> gcc.c-torture/compile/920501-7.c
> gcc.c-torture/compile/labels-1.c
> gcc.c-torture/compile/labels-2.c
> gcc.c-torture/compile/labels-3.c
> gcc.c-torture/execute/comp-goto-1.c
> gcc.dg/20021029-1.c
> gcc.dg/pr16973.c
>
> Okay for trunk?
Yes, this is ok.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #21 from rguenther at suse dot de 2007-06-21 08:01 --- Subject: Re: ICE: fold check: original tree changed by fold with --enable-checking=fold On Thu, 20 Jun 2007, spop at gcc dot gnu dot org wrote: > > > --- Comment #18 from spop at gcc dot gnu dot org 2007-06-20 23:31 --- > Subject: Re: ICE: fold check: original tree changed by fold with > --enable-checking=fold > > Hi, here is the final fix for the remaining cases, closing this PR. > Okay for trunk after bootntest on i686-linux with default languages > and --enable-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree ? This doesn't look right - let me investigate. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug c/32447] without-decimal-float needed
--- Comment #1 from malitzke at metronets dot com 2007-06-21 08:08 --- Disclosure: I am not an IBM hater and never was. My first significant program ran on an IBM 1410 with a Tape Operating System (TOS) on the day President Kennedy was assassinated. I then used an IBM 1620 II extensively.; migrated to an IBM 1800 and to an IBM 1130. All worked well for these early systems, but, I had to open the door fairly often late at night for an IBM customer service man. At another firm I worked with the then largest and newest IBM 360's. Overall, I had twice teams come from the Almaden Labs to resolve issues with DASD's and the FORTRAN H compiler (early seventies). On the other hand I really got to hate PL/I, as I could interpret ABEND dumps and colleagues came to my office with 1-2 feet high dumps that mostly by the PL/I compiler going off on a tangent. This interfered with my work and I turned to satellite telecommunications. I only returned to programming as a hobby and as a retirement activity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #22 from richard dot guenther at gmail dot com 2007-06-21 08:16 --- Subject: Re: ICE: fold check: original tree changed by fold with --enable-checking=fold On 6/21/07, Sebastian Pop <[EMAIL PROTECTED]> wrote: > Hi, here is the final fix for the remaining cases, closing this PR. > Okay for trunk after bootntest on i686-linux with default languages > and --enable-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree ? The fold_binary change looks unnecessary. The rest is ok. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #23 from spop at gcc dot gnu dot org 2007-06-21 08:21 ---
Subject: Re: ICE: fold check: original tree changed by fold with
--enable-checking=fold
On 6/21/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> The fold_binary change looks unnecessary.
ok.
> The rest is ok.
>
There was something wrong in the rest, so I'm proposing this fix instead,
as we were not using the modified base anymore for building the result 't'.
@@ -14191,14 +14220,15 @@ build_fold_addr_expr_with_type (tree t,
}
else
{
- tree base = t;
+ tree copy_t = copy_node (t);
+ tree base = copy_t;
while (handled_component_p (base))
base = TREE_OPERAND (base, 0);
if (DECL_P (base))
TREE_ADDRESSABLE (base) = 1;
- t = build1 (ADDR_EXPR, ptrtype, t);
+ t = build1 (ADDR_EXPR, ptrtype, copy_t);
}
return t;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug c/32449] declaring �strcmp()� as an extern function with inclusion of �string.h� is causing compilation error
--- Comment #1 from schwab at suse dot de 2007-06-21 08:45 --- may define strcmp as a macro. This has nothing to do with the compiler. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32449
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #24 from rguenther at suse dot de 2007-06-21 08:48 ---
Subject: Re: ICE: fold check: original tree changed
by fold with --enable-checking=fold
On Thu, 21 Jun 2007, spop at gcc dot gnu dot org wrote:
>
>
> --- Comment #23 from spop at gcc dot gnu dot org 2007-06-21 08:21 ---
> Subject: Re: ICE: fold check: original tree changed by fold with
> --enable-checking=fold
>
> On 6/21/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >
> > The fold_binary change looks unnecessary.
>
> ok.
>
> > The rest is ok.
> >
>
> There was something wrong in the rest, so I'm proposing this fix instead,
> as we were not using the modified base anymore for building the result 't'.
>
> @@ -14191,14 +14220,15 @@ build_fold_addr_expr_with_type (tree t,
> }
>else
> {
> - tree base = t;
> + tree copy_t = copy_node (t);
> + tree base = copy_t;
>
>while (handled_component_p (base))
> base = TREE_OPERAND (base, 0);
>if (DECL_P (base))
> TREE_ADDRESSABLE (base) = 1;
>
> - t = build1 (ADDR_EXPR, ptrtype, t);
> + t = build1 (ADDR_EXPR, ptrtype, copy_t);
> }
>
>return t;
Oh, indeed. The above is ok. (The fold_binary change still looks
unnecessary)
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #3 from rob1weld at aol dot com 2007-06-21 08:49 --- GCC printed no warning about disliking a conversion. I hacked the program in accordance with your suggestion and now it prints: n= 4 QUESTION1=+0.123 QUESTION2=+0.123 Q(n)=+0.000 n= 5 QUESTION1=+0.099 QUESTION3=+0.099 Q(n)=-0.000 n= 5 QUESTION1=+0.099 QUESTION2=+0.099 Q(n)=-0.000 n= 6 QUESTION1=+0.083 QUESTION3=+0.083 Q(n)=-0.000 n= 6 QUESTION1=+0.083 QUESTION2=+0.083 Q(n)=-0.000 n= 7 QUESTION1=+0.071 QUESTION3=+0.071 Q(n)=+0.000 n= 7 QUESTION1=+0.071 QUESTION2=+0.071 Q(n)=+0.000 n= 8 QUESTION1=+0.062 QUESTION3=+0.062 Q(n)=-0.000 Sometimes the answer is _positive_ zero and sometimes the answer is _negative_ zero. -- rob1weld at aol dot com changed: What|Removed |Added Severity|major |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #20 from tbm at cyrius dot com 2007-06-21 08:53 --- It's interesting that you mention problems with va_list and prologues because I have such problems on IA64 too since the df merge. I've no idea if they're related but maybe you want to check them out: Error: .prologue within prologue: PR32338 Segfault after rejecting bogus assembler / va_list: PR32370 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug target/32441] ICE in expand_expr_real_1, at expr.c:7109
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-21 08:58 ---
Patch which fixes this bug:
Index: builtins.c
===
--- builtins.c (revision 125776)
+++ builtins.c (working copy)
@@ -4649,7 +4649,18 @@
std_expand_builtin_va_start (tree valist, rtx nextarg)
{
tree t;
- t = make_tree (sizetype, nextarg);
+ /* Use the correct type/mode for make_tree, can't use a pointer type as
+ PLUS_EXPR is not appliable to pointers. type_for_mode might return
+ a type with a different mode (SI vs PSI) so we might need to convert
+ to the different mode. */
+ tree type = lang_hooks.types.type_for_mode (TYPE_MODE (ptr_type_node),
true);
+ if (TYPE_MODE (type) != GET_MODE (nextarg))
+{
+ rtx reg = gen_reg_rtx (TYPE_MODE (type));
+ convert_move (reg, nextarg, false);
+ nextarg = reg;
+}
+ t = make_tree (type, nextarg);
t = fold_convert (ptr_type_node, t);
t = build2 (MODIFY_EXPR, TREE_TYPE (valist), valist, t);
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-21 08:58:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
[Bug debug/32444] missing debug information for structure components with optimized code
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-21 09:01 --- First temp is SRA'd so the debugging info should be correct unless tracking is wrong. Second iv-opts is messing up the debuging info for i by creating a new variable. I think this is a feature we would like to support but is not something we need to support that well. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Summary|missing debug information |missing debug information |for structure components|for structure components ||with optimized code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32444
[Bug middle-end/32450] New: -pg seemingly causes miscompilation
CP2K (see PR 29975) compiles fine with current trunk using '-O3 -ffast-math -ftree-vectorize -march=native -funroll-loops' but the code stops with a bogus error message using '-O3 -ffast-math -ftree-vectorize -march=native -funroll-loops -pg' to reproduce see comment 112 in PR 29975 to obtain the code and the example inputs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975#c112 I've tested this using: Target: x86_64-unknown-linux-gnu Configured with: /data/vondele/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_trunk/build --enable-languages=c,fortran --with-mpfr=/data/programs/mpfr/ Thread model: posix gcc version 4.3.0 20070620 (experimental) -- Summary: -pg seemingly causes miscompilation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug debug/32444] missing debug information for structure components with optimized code
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-21 09:03 --- Actually SRA should be ok, because we do keep tracking them on the tree level. Daniel Berlin added this code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32444
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #115 from jv244 at cam dot ac dot uk 2007-06-21 09:05 --- trying to investigate the culprit of the slowdown mentioned in comment 112 I found out that adding -pg to the compile flags leads to a miscompiled code. I've filed PR 32450 to track the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-21 09:06 --- abs converts the float/double to an integer type so this is not a bug. If you use 4.3, you can use -Wconversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-21 09:07 --- Most likely -pg is changing the alignment of the stack which is incorrect. Oh -pg code is emitted by the target specific code so this is a target issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target GCC target triplet||x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug middle-end/32447] without-decimal-float needed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-21 09:11 --- You are misrepresenting the problem again. So the issue is that the size of cc1/cc1plus is increased with the decimal float back-end support. Now Disabling this support in general is a hard problem. I would dare you to do #ifdef SUPPORT_DFP around all the uses and see if that works. I doubt it because the DFP is now embedded inside GCC sources. This is true of vector support. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu
--- Comment #22 from sunjoong at gmail dot com 2007-06-21 09:14 --- I checked VOLATILE statement passing in gfortran 4.3 . Unfortunately I had failed to buid gfortran (and gcc) 4.3 in my i686, I only checked that passing with ia64 binary on another ia64 machine. (There is no gfortran 4.3 binary on i686.) However, I think and hope it would work after my success of building on i686. (In reply to comment #21) > (In reply to comment #20) > > $ gfortran -O1 -o TMalign TMalign.f > > In file TMalign.f:2005 > > > > VOLATILE D > > 1 > > Error: Unclassifiable statement at (1) > > Sigh. Try it with gfortran 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
[Bug target/30599] long double declaration rounds to double instead
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-21 09:15 --- But again, even if sqrtl is not part of the library, this is not a GCC issue. We provide builtins for faster usage and not to get around libc not including the function. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30599
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #1 from daney at gcc dot gnu dot org 2007-06-21 09:15 --- Created an attachment (id=13754) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13754&action=view) Proposed patch. This is a problem with __builtin_eh_return(). At -O0 the new return address is being stored in the $ra save slot on the stack. At -O1 it is not. The patch allows cleanup-9.c to succeed. I will refomat the code to fit in 80 columns and bootstrap it. -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug target/32437] [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-06-21 09:30 --- Does the pattern get deleted, or moved somewhere inappropriate? If the former, does that mean that (unspec)s aren't allowed in top-level patterns any more? Other backends besides MIPS seem to use this construct. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
[Bug tree-optimization/32451] New: [4.3 Regression] ICE in verify_flow_info after DOM2
./cc1plus -quiet -O3 1.2.ii -fdump-tree-all-details 1.2.ii: In function 'void test1()': 1.2.ii:104: error: true/false edge after a non-COND_EXPR in bb 15 1.2.ii:104: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.3 Regression] ICE in verify_flow_info after DOM2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-21 09:48 --- Created an attachment (id=13755) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13755&action=view) testcase testcase reduced from libstdc++-v3/testsuite/25_algorithms/equal/1.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #25 from richard dot guenther at gmail dot com 2007-06-21
10:07 ---
Subject: Re: ICE: fold check: original tree changed by fold with
--enable-checking=fold
On 6/21/07, Sebastian Pop <[EMAIL PROTECTED]> wrote
> On 6/21/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >
> > The fold_binary change looks unnecessary.
>
> ok.
>
> > The rest is ok.
> >
>
> There was something wrong in the rest, so I'm proposing this fix instead,
> as we were not using the modified base anymore for building the result 't'.
>
> @@ -14191,14 +14220,15 @@ build_fold_addr_expr_with_type (tree t,
> }
>else
> {
> - tree base = t;
> + tree copy_t = copy_node (t);
> + tree base = copy_t;
>
>while (handled_component_p (base))
> base = TREE_OPERAND (base, 0);
>if (DECL_P (base))
> TREE_ADDRESSABLE (base) = 1;
>
> - t = build1 (ADDR_EXPR, ptrtype, t);
> + t = build1 (ADDR_EXPR, ptrtype, copy_t);
> }
As you noted copying trees here is wrong, too. We can either try to get rid
of setting the TREE_ADDRESSABLE flag here or fix fold checking code to
ignore this particular change. Note the above code is this way since the
tree-ssa merge.
Another thing would be to note where we call this helper from fold() routines
and not set the flag only for those callers which should be safe. We'd need
another flag argument to the function or another wrapper.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #43 from ebotcazou at gcc dot gnu dot org 2007-06-21 10:11 --- Subject: Bug 25737 Author: ebotcazou Date: Thu Jun 21 10:11:19 2007 New Revision: 125915 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125915 Log: PR tree-optimization/25737 * misc.c (gnat_post_options): Do not force flag_tree_salias to 0. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/misc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #44 from ebotcazou at gcc dot gnu dot org 2007-06-21 10:13 --- Works on mainline. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg01533.html Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-21 10:16 --- (In reply to comment #1) > Most likely -pg is changing the alignment of the stack which is incorrect. Oh > -pg code is emitted by the target specific code so this is a target issue. > Is there an easy way for me to check this ? Meanwhile, I find that '-O1 -march=native -pg' compiles/executes OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-21 10:19 --- Can be triggered with -O2 as well, with --param max-aliased-vops=1000 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-21 10:26 --- Zdenek, I suppose this is caused by your loop-preserving for DOM. Note this may be jump threading related: Threaded jump 9 --> 15 to 27 (gdb) call debug_bb_n (15) ;; basic block 15, loop depth 1, count 0 ;; prev block 26, next block 16 ;; pred: 26 [100.0%] (fallthru,dfs_back) ;; succ: 16 [59.4%] (false,exec) : Invalid sum of outgoing probabilities 59.4% # __first2$ptr_107 = PHI <__first2$ptr_83(26)> so we simply forget to remove the false flag from the edge? #0 internal_error (gmsgid=0x104edd0 "verify_flow_info failed") at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:600 #1 0x007697c3 in verify_flow_info () at /space/rguenther/src/svn/trunk/gcc/cfghooks.c:247 #2 0x00f2c094 in loop_optimizer_finalize () at /space/rguenther/src/svn/trunk/gcc/loop-init.c:122 #3 0x00b5f57e in tree_ssa_dominator_optimize () at /space/rguenther/src/svn/trunk/gcc/tree-ssa-dom.c:348 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-21 10:38 --- The problem is introduced by tree-ssa-threadupdate.c:thread_single_edge where we have the single_pred_p case but fail to clear the edge flags as we do for example in DOMs propagate_rhs_into_lhs. So the following seems to work but I'm not sure if this is enough: Index: tree-ssa-threadupdate.c === --- tree-ssa-threadupdate.c (revision 125884) +++ tree-ssa-threadupdate.c (working copy) @@ -636,6 +636,9 @@ thread_single_edge (edge e) /* If BB has just a single predecessor, we should only remove the control statements at its end, and successors except for ETO. */ remove_ctrl_stmt_and_useless_edges (bb, eto->dest); + eto->flags &= ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE); + eto->flags &= ~EDGE_ABNORMAL; + eto->flags |= EDGE_FALLTHRU; return bb; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-21 10:42 --- Looks like so, the other caller in tree-ssa-threadupdate.c does so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-21 10:44 --- Mine. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-21 10:44:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug tree-optimization/32435] ICE in build2_stat for -O2 -ftree-vectorize -maltivec
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-21 10:57 --- I bet this is the same as PR32421. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||32421 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32435
[Bug fortran/32439] f951: out of memory with '-O1 -fbounds-check'
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-21 10:58 --- Can you run the compile inside gdb and check periodically where it wastes its time? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug target/32441] ICE in expand_expr_real_1, at expr.c:7109
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-21 11:00 --- You shouldn't introduce calls to langhooks. Why not use mode_for_size? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
[Bug ada/32452] New: Incorrect type debugging information for variables in other compilation units
(Debian bug #429934, forwarding upstream) Package: gnat-4.1 Version: 4.1.1-22 Severity: normal Tags: confirmed, upstream In the test case below, GCC emits correct type information for Debugging.A but the type information for External.B is incorrect. package External is type External_Type is array (1 .. 4) of Float; B : External_Type; end External; with External; procedure Debugging is A : External.External_Type; begin A := (1.0, 2.0, 3.0, 4.0); External.B := A; end Debugging; How to reproduce: $ gnatmake -g debugging.adb gcc-4.1 -c -g debugging.adb gnatbind -x debugging.ali gnatlink debugging.ali -g $ gnatgdb debugging Current directory is /home/lbrenta/src/tmp/ GNU gdb 6.4 for GNAT Pro 2006 (20060522) Copyright 2005 Free Software Foundation, Inc. Ada Core Technologies version of GDB for GNAT Professional [...] (gdb) break debugging Breakpoint 1 at 0x400d30: file debugging.adb, line 5. (gdb) run [...] Breakpoint 1, debugging () at debugging.adb:5 (gdb) ptype a type = array (1 .. 4) of <4-byte float>(correct) (gdb) ptype external.b type = <4-byte integer>(wrong) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnat-4.1 depends on: ii gcc-4.1 4.1.1-21 The GNU C compiler ii gnat-4.1-base 4.1.1-22 The GNU Compiler Collection (gnat ii libc6 2.5-9GNU C Library: Shared libraries ii libc6-dev 2.5-9GNU C Library: Development Librari ii libgcc1 1:4.2-20070528-1 GCC support library ii libgnat-4.1 4.1.1-22 Runtime library for GNU Ada applic ii libgnatprj4.1 4.1.1-22 GNU Ada Project Manager ii libgnatvsn4.1 4.1.1-22 GNU Ada compiler version library gnat-4.1 recommends no packages. -- no debconf information -- Summary: Incorrect type debugging information for variables in other compilation units Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32452
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-21 11:19 --- Ping? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug ada/32452] [4.0/4.1 Regression] Incorrect type debugging information for variables in other compilation units
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-06-21 11:24 --- Forgot to add the output of gcc -v: $ gcc-4.1 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) $ gnatmake -v 2>&1 | head -n 3 GNATMAKE 4.1.220061115prerelease (Debian 4.1.1-22) Copyright 1995-2004 Free Software Foundation, Inc. Also the OP says this is a regression since GCC 3.4. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Known to fail||4.2.0 Summary|Incorrect type debugging|[4.0/4.1 Regression] |information for variables in|Incorrect type debugging |other compilation units |information for variables in ||other compilation units http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32452
[Bug tree-optimization/32453] New: [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
#0 fancy_abort (file=0xe96e48 "/space/rguenther/src/svn/trunk/gcc/tree.c", line=3074, function=0xe9825f "build2_stat") at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:656 #1 0x00a3bb1a in build2_stat (code=PLUS_EXPR, tt=0x2ad09f6def00, arg0=0x2ad09fb625c0, arg1=0x2ad09fb1ca50) at /space/rguenther/src/svn/trunk/gcc/tree.c:3074 #2 0x006c2be1 in fold_build2_stat (code=PLUS_EXPR, type=0x2ad09f6def00, op0=0x2ad09fb625c0, op1=0x2ad09fb1ca50) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12945 #3 0x00a0466e in extract_range_from_assert (vr_p=0x7fff0be24420, expr=0x2ad09f6b3e00) at /space/rguenther/src/svn/trunk/gcc/tree-vrp.c:1477 #4 0x00a0ac2b in extract_range_from_expr (vr=0x7fff0be24420, expr=0x2ad09f6b3e00) at /space/rguenther/src/svn/trunk/gcc/tree-vrp.c:2582 #5 0x00a17e17 in vrp_visit_assignment (stmt=0x2ad09fe3ae10, output_p=0x7fff0be24710) at /space/rguenther/src/svn/trunk/gcc/tree-vrp.c:4668 (gdb) call debug_generic_expr (stmt) inptr_549 = ASSERT_EXPR so we have an anti-range for inptr of pointer-type. So the following 1477min = fold_build2 (PLUS_EXPR, TREE_TYPE (var_vr->min), 1478 anti_max, 1479 build_int_cst (TREE_TYPE (var_vr->min), 1)); isn't going to make us happy. -- Summary: [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-21 11:26 --- Created an attachment (id=13756) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13756&action=view) testcase testcase from glibc, build with -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
-- rguenth 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=32453
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #5 from ubizjak at gmail dot com 2007-06-21 11:27 --- (In reply to comment #3) > GCC printed no warning about disliking a conversion. It just happens that gcc is not like microwave oven that has to include warnings about not drying animals in it. > Sometimes the answer is _positive_ zero and sometimes the answer is _negative_ > zero. http://en.wikipedia.org/wiki/Floating-point -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug c/32448] [3.3 / 3.4 / 4.1 / 4.2 / 4.3 Regression] abs / printf bug
--- Comment #6 from rob1weld at aol dot com 2007-06-21 11:30 --- Thanks for everyones input. The only issues related to this 'bug' are: 1): printf _sometimes_ prints "-0.000" and sometimes prints "+0.000" - the reason it is even showing the "+" or "-" is because I enabled them using "%+f", this I understand. My 2 cents is that the correct answer is "+0.000" and never "-0.000" - UNLESS, that is related to _accuracy_ and nothing to do with "printf"; in which cause that is a different bug. 2): Using a "sprintf()" to print the answer to a char string (which itself is never even used!) "fixes" the bug. This suggests to me that something is upsetting the folding. It can't be an optimization issue since this occurs at any optimization level (even -O0, none) so unless it is the parsing it may be the folding. Sometimes GCC goes "crazy" (see 6, 8, and 9). If indeed GCC is operating "correctly" it should do the SAME thing everytime - Correct ? If GCC want to convert it to an INT, fine. the correct answer is ZERO and not: a): -16522743262502092537856.000 b): +60316137357217275485696900081464849817...(many more digits)... c): -25531721305534761946185249871767754587...(many more digits)... Cygwin gives the same (ridiculous) answer _everytime_ which is better though it ought to be ZERO. If GCC thinks it is doing the correct thing (there is NO BUG) then why doesn't it do the SAME thing - it is saying that the previous time it was wrong and wants to give a different answer, when it ought to give the same answer. 3): If this belongs on http://gcc.gnu.org/bugs.html#nonbugs then this is a documentation bug. Thanks for considering this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-21 11:38 --- I have a patch. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-21 11:38:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-06-21 12:00 --- Subject: Bug 32451 Author: rguenth Date: Thu Jun 21 12:00:47 2007 New Revision: 125916 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125916 Log: 2007-06-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32451 * tree-ssa-threadupdate.c (thread_single_edge): Fixup edge flags. * g++.dg/torture/20070621-1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/20070621-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug middle-end/32362] ICE: in lookup_decl_in_outer_ctx, at omp-low.c:1508
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-21 12:11 --- Subject: Bug 32362 Author: jakub Date: Thu Jun 21 12:11:00 2007 New Revision: 125917 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125917 Log: PR middle-end/32362 * omp-low.c (lookup_decl_in_outer_ctx): Don't ICE if t is NULL, but decl is a global var, instead return decl. * gimplify.c (gimplify_adjust_omp_clauses_1): Add shared clauses even for is_global_var decls, if they are private in some outer context. * testsuite/libgomp.c/pr32362-1.c: New test. * testsuite/libgomp.c/pr32362-2.c: New test. * testsuite/libgomp.c/pr32362-3.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr32362-1.c trunk/libgomp/testsuite/libgomp.c/pr32362-2.c trunk/libgomp/testsuite/libgomp.c/pr32362-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/omp-low.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32362
[Bug middle-end/32362] ICE: in lookup_decl_in_outer_ctx, at omp-low.c:1508
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-21 12:16 --- Subject: Bug 32362 Author: jakub Date: Thu Jun 21 12:15:53 2007 New Revision: 125918 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125918 Log: PR middle-end/32362 * omp-low.c (lookup_decl_in_outer_ctx): Don't ICE if t is NULL, but decl is a global var, instead return decl. * gimplify.c (gimplify_adjust_omp_clauses_1): Add shared clauses even for is_global_var decls, if they are private in some outer context. * testsuite/libgomp.c/pr32362-1.c: New test. * testsuite/libgomp.c/pr32362-2.c: New test. * testsuite/libgomp.c/pr32362-3.c: New test. Added: branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr32362-1.c branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr32362-2.c branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr32362-3.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/gimplify.c branches/gcc-4_2-branch/gcc/omp-low.c branches/gcc-4_2-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32362
[Bug tree-optimization/31866] [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
--- Comment #3 from jakub at gcc dot gnu dot org 2007-06-21 12:21 --- Subject: Bug 31866 Author: jakub Date: Thu Jun 21 12:20:42 2007 New Revision: 125919 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125919 Log: PR tree-optimization/31866 * tree-ssa-coalesce.c (create_outofssa_var_map): Do nothing if ASM_EXPR's input is not a SSA_NAME. * gcc.dg/pr31866.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr31866.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-coalesce.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug tree-optimization/31866] [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-21 12:23 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug middle-end/32362] ICE: in lookup_decl_in_outer_ctx, at omp-low.c:1508
--- Comment #4 from jakub at gcc dot gnu dot org 2007-06-21 12:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32362
[Bug target/32431] ICE in df_refs_verify, at df-scan.c:4066
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-21 12:29
---
Subject: Re: ICE in df_refs_verify, at df-scan.c:4066
rask at sygehus dot dk wrote:
> --- Comment #1 from rask at sygehus dot dk 2007-06-20 16:58 ---
> Created an attachment (id=13747)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13747&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13747&action=view)
> Preprocessed testcase
>
>
>
:ADDPATCH MIDDLE-END:
The underlying problem is that the later phases of compilation on the
m68hc11 create shared rtl. The reorg phase needs df and also needs the
rtl to be unshared. This causes problems because the unsharing process
changes insns in ways that mess up df's scanning information.
There are two ways to solve this problem:
1) Go in and fix the places that create shared rtl in this back end.
2) Make the rtl unsharing df-ready.
I chose plan (2) because I know how to do this and do not know how to do
(1).
The astute middle end/gwp maintainer may say that (1) is the right thing
to do and so the sharing police (namely honza) should investigate this
pr. If that is the proper plan of action, then this patch may go into
the trash.
I tested this on x86-64 which does call unshare_all_rtl_again (from
ifcvt) to verify that this does not cause any problems and it does fix
the immediate bug here.
Ok for trunk?
Kenny
2007-06-21 Kenneth Zadeck <[EMAIL PROTECTED]>
PR middle-end/32431
* emit-rtl.c (unshare_all_rtl_in_chain): Now rescans insns and
notes if unsharing happens.
(copy_rtx_if_shared_1): Returns true if sharing was found.
config/m68hc11/m68hc11.c: (m68hc11_reorg): Move reinitialization
of cfg to before unsharing rtl.
Index: emit-rtl.c
===
--- emit-rtl.c (revision 125916)
+++ emit-rtl.c (working copy)
@@ -184,7 +184,7 @@ static int reg_attrs_htab_eq (const void
static reg_attrs *get_reg_attrs (tree, int);
static tree component_ref_for_mem_expr (tree);
static rtx gen_const_vector (enum machine_mode, int);
-static void copy_rtx_if_shared_1 (rtx *orig);
+static bool copy_rtx_if_shared_1 (rtx *orig);
/* Probability of the conditional branch currently proceeded by try_split.
Set to -1 otherwise. */
@@ -2350,8 +2350,20 @@ unshare_all_rtl_in_chain (rtx insn)
for (; insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
{
- PATTERN (insn) = copy_rtx_if_shared (PATTERN (insn));
- REG_NOTES (insn) = copy_rtx_if_shared (REG_NOTES (insn));
+ rtx orig = PATTERN (insn);
+
+if (copy_rtx_if_shared_1 (&orig))
+ {
+ PATTERN (insn) = orig;
+ df_insn_rescan (insn);
+ }
+
+ orig = REG_NOTES (insn);
+ if (copy_rtx_if_shared_1 (&orig))
+ {
+ REG_NOTES (insn) = orig;
+ df_notes_rescan (insn);
+ }
}
}
@@ -2383,10 +2395,11 @@ copy_rtx_if_shared (rtx orig)
return orig;
}
-/* Mark *ORIG1 as in use, and set it to a copy of it if it was already in
- use. Recursively does the same for subexpressions. */
+/* Mark *ORIG1 as in use, and set it to a copy of it if it was already
+ in use. Recursively does the same for subexpressions. Return true
+ if copies were made. */
-static void
+static bool
copy_rtx_if_shared_1 (rtx *orig1)
{
rtx x;
@@ -2396,13 +2409,15 @@ copy_rtx_if_shared_1 (rtx *orig1)
const char *format_ptr;
int copied = 0;
int length;
+ bool changed = false;
+
/* Repeat is used to turn tail-recursion into iteration. */
repeat:
x = *orig1;
if (x == 0)
-return;
+return changed;
code = GET_CODE (x);
@@ -2421,15 +2436,15 @@ repeat:
case CC0:
case SCRATCH:
/* SCRATCH must be shared because they represent distinct values. */
- return;
+ return changed;
case CLOBBER:
if (REG_P (XEXP (x, 0)) && REGNO (XEXP (x, 0)) < FIRST_PSEUDO_REGISTER)
- return;
+ return changed;
break;
case CONST:
if (shared_const_p (x))
- return;
+ return changed;
break;
case INSN:
@@ -2438,7 +2453,7 @@ repeat:
case NOTE:
case BARRIER:
/* The chain of insns is not being copied. */
- return;
+ return changed;
default:
break;
@@ -2451,6 +2466,7 @@ repeat:
{
x = shallow_copy_rtx (x);
copied = 1;
+ changed = true;
}
RTX_FLAG (x, used) = 1;
@@ -2469,7 +2485,7 @@ repeat:
{
case 'e':
if (last_ptr)
-copy_rtx_if_shared_1 (last_ptr);
+changed |= copy_rtx_if_shared_1 (last_ptr);
last_ptr = &XEXP (x, i);
break;
@@ -2488,7 +2504,7 @@ repeat:
for (j = 0; j < len; j++)
{
if (last_ptr)
- copy_rtx_if_shared_1 (last_ptr);
+ changed |= copy_rtx_if_shared_1 (last_ptr);
last_ptr = &XVECEXP (x,
[Bug fortran/32454] New: Bounds-check misses overflow of lhs array
Should give with -fbounds-check something like the following (NAG f95 -C=all): Rank 1 of array operand has extent 8 instead of 4 Program terminated by fatal error In BOUNDSERROR, line 7 of test.f90 I think it might a duplicate of some PR, though I couldn't find it. program boundsError implicit none integer :: i integer, dimension(:), allocatable :: y allocate(y(4)) y = 0.0 print *, size(y) y = [y, (99,i=1,4)] print *, size(y) end program boundsError -- Summary: Bounds-check misses overflow of lhs array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32454
[Bug fortran/32454] Bounds-check misses overflow of lhs array
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-21 12:33 --- I forgot to mention: I think this file is valid Fortran 2003 and only invalid Fortran 95. Maybe using: integer, dimension(4) :: y is a better test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32454
[Bug target/32369] [frv] macro "DF_LIVE_IN" passed 2 arguments, but takes just 1
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-21 12:49 --- this was fixed with the commit. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32369
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #14 from dir at lanl dot gov 2007-06-21 12:57 --- >What is actually the expected result? Depending on the compiler and compiler >setting, I get completely different results for the second triangular matrix. >(The first matrix remains always the same.) What the program does in this section is multiply the diagonal of the matrix by 2 with the line - tt=tt+tt and so (0.8000E+01 -> 0.1600E+02), (0.1000E+02 -> 0.2000E+02) and (0.1300E+02 -> 0.2600E+02 ) and the other three elememts should stay the same. In debug mode, most compilers will give the correct answer, but the addition is sometimes being optmized away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/30381] [4.1 only] ISHFTC() constant folding is broken.
--- Comment #7 from bardeau at iram dot fr 2007-06-21 13:08 --- (In reply to comment #6) > Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm > closing this bug. > The bug still appears under cygwin with gcc 4.3: program test integer*4 a a=1 print *,"a = ", a print *,"ISHFTC(a,2,32) = ", ISHFTC(a,2,32) print *,"ISHFTC(a,2) = ", ISHFTC(a,2) end ~> ./test.exe a =1 ISHFTC(a,2,32) =1 ISHFTC(a,2) =4 This happens only if A is INTEGER*4 or 8, and if 3rd argument is present. Also, no problem under Linux. ~> uname -a CYGWIN_NT-5.1 dhcp-bardeau 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin ~> gfortran -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc43/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --enable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp Thread model: posix gcc version 4.3.0 20070512 (experimental) Cheers, Sebastien -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30381
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #15 from dir at lanl dot gov 2007-06-21 13:23 --- >BTW I do not see (beside obfuscation) the interest of the constructs: It is the construct: jt=t(j2) tt=tt+tt t(j2)=jt that is being optmized away or done incorrectly when the second matrix stays the same. The obfuscation is required because the program is doing virtual memory management and at this point floating point data is in one of the raw integer virtual arrays and so that is the game that is played to do the floating point add. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug tree-optimization/32421] [4.3 Regression] -ftree-vectorize -msse2 ICEs in build2_stat when vectorizing POINTER_PLUS_EXPR
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-21 13:32 --- *** Bug 32435 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32421
[Bug tree-optimization/32435] ICE in build2_stat for -O2 -ftree-vectorize -maltivec
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-21 13:32 --- Yes this is the same issue, we have POINTER_PLUS_EXPR and we are trying to create it with a vector type. *** This bug has been marked as a duplicate of 32421 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32435
[Bug target/32423] gcc.c-torture/compile/20020604-1.c ICEs
--- Comment #1 from zadeck at naturalbridge dot com 2007-06-21 13:37 --- What is the configure string that i use to recreate this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32423
[Bug target/32441] ICE in expand_expr_real_1, at expr.c:7109
--- Comment #5 from pinskia at gmail dot com 2007-06-21 13:47 --- Subject: Re: ICE in expand_expr_real_1, at expr.c:7109 > You shouldn't introduce calls to langhooks. Why not use mode_for_size? I was just copying code from fold-const.c. I have the mode already, I need an integer tree type that matches that mode. So really mode_for_size will not give me any more information. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
[Bug fortran/32439] f951: out of memory with '-O1 -fbounds-check'
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-21 13:50 --- (In reply to comment #1) > Can you run the compile inside gdb and check periodically where it wastes its > time? > I have a few gdb backtraces, but it looks like it is just writing the .s file. At the point where f951 dies the .s file is about 53Mb in size. The last few gdb traces I collected are: #0 shorten_branches (first=0x2ad9a29700) at /scratch/vondele/gcc_trunk/gcc/gcc/final.c:1081 #1 0x0056fca1 in rest_of_handle_shorten_branches () at /scratch/vondele/gcc_trunk/gcc/gcc/final.c:4046 #2 0x0061b396 in execute_one_pass (pass=0xcfa400) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #3 0x0061b55c in execute_pass_list (pass=0xcfa400) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1178 #4 0x0061b56e in execute_pass_list (pass=0xcfaae0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #5 0x0061b56e in execute_pass_list (pass=0xcfaa80) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #6 0x006e6358 in tree_rest_of_compilation (fndecl=0x2a96cf2300) at /scratch/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:406 #7 0x0082ba30 in cgraph_expand_function (node=0x2a96cf2500) at /scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1073 #8 0x0082de12 in cgraph_optimize () at /scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1142 #0 0x0061d09d in pointer_set_insert (pset=0x26b622f0, p=0x2ae2aebea0) at /scratch/vondele/gcc_trunk/gcc/gcc/pointer-set.c:68 #1 0x00698881 in verify_stmts () at /scratch/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:3573 #2 0x0079c317 in verify_ssa (check_modified_stmt=1 '\001') at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:614 #3 0x0061b1a5 in execute_function_todo (data=Variable "data" is not available. ) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:972 #4 0x0061aeef in execute_todo (flags=Variable "flags" is not available. ) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:996 #5 0x0061b3ee in execute_one_pass (pass=0xcfcd40) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1147 #6 0x0061b55c in execute_pass_list (pass=0xcfcd40) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1178 #7 0x0061b56e in execute_pass_list (pass=0xcfc1a0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #0 0x00669b9e in refers_to_regno_p (regno=17, endregno=18, x=0x2aba886640, loc=0x0) at /scratch/vondele/gcc_trunk/gcc/gcc/rtlanal.c:1285 #1 0x0099c4e9 in record_value_for_reg (reg=0x2aba8864e0, insn=0x2ad6f2db40, value=0x2aba886640) at /scratch/vondele/gcc_trunk/gcc/gcc/combine.c:11194 #2 0x009ae29a in rest_of_handle_combine () at /scratch/vondele/gcc_trunk/gcc/gcc/combine.c:1069 #3 0x0061b396 in execute_one_pass (pass=0xcfed60) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #0 0x004ff2f0 in df_lr_bb_local_compute (bb_index=64) at /scratch/vondele/gcc_trunk/gcc/gcc/df-problems.c:1379 #1 0x00500bbf in df_lr_verify_transfer_functions () at /scratch/vondele/gcc_trunk/gcc/gcc/df-problems.c:1905 #2 0x004fbcde in df_verify () at /scratch/vondele/gcc_trunk/gcc/gcc/df-core.c:1514 #3 0x004fc809 in df_analyze () at /scratch/vondele/gcc_trunk/gcc/gcc/df-core.c:1106 #4 0x009d5757 in move_loop_invariants () at /scratch/vondele/gcc_trunk/gcc/gcc/loop-invariant.c:641 #5 0x009d3d57 in rtl_move_loop_invariants () at /scratch/vondele/gcc_trunk/gcc/gcc/loop-init.c:238 #6 0x0061b396 in execute_one_pass (pass=0xcff4e0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #0 0x0063ed17 in init_subregs_of_mode () at /scratch/vondele/gcc_trunk/gcc/gcc/regclass.c:2410 #1 0x0061b396 in execute_one_pass (pass=0xcfb340) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32439
[Bug c/32455] New: internal compiler error: in convert_move, at expr.c:362
HARDWARE: - System: HP-UX B.11.00 Machine: 9000/785 COMPILATION: /usr/local/bin/gcc -v -save-temps -c TP.c -o TP_c.o Using built-in specs. Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure Thread model: posix gcc version 4.1.2 /usr/local/libexec/gcc/hppa2.0w-hp-hpux11.11/4.1.2/cc1 -E -quiet -v TP.c -fpch-preprocess -o TP.i ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/hppa2.0w-hp-hpux11.11/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc/hppa2.0w-hp-hpux11.11/4.1.2/include /usr/include End of search list. /usr/local/libexec/gcc/hppa2.0w-hp-hpux11.11/4.1.2/cc1 -fpreprocessed TP.i -quiet -dumpbase TP.c -auxbase-strip TP_c.o -version -o TP.s GNU C version 4.1.2 (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.1.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 74aa6c12f75acdb1c74c59fde58fd82f In file included from TP.c:130: atu.inc: In function 'CONCAT_STR_C': atu.inc:264: warning: second parameter of 'va_start' not last named argument atu.inc:264: internal compiler error: in convert_move, at expr.c:362 I try to compil a source code comes from a library target chpgnu of TestRealTime -- Summary: internal compiler error: in convert_move, at expr.c:362 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: frederic dot schuh at neuf dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug target/32455] internal compiler error: in convert_move, at expr.c:362
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |target GCC target triplet||hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug libfortran/32456] New: IO error message should show Unit/Filename
! echo "z" > foo.dat program test implicit none integer :: i open(99,file="foo.dat") read(99,*) i print *, i end program gfortran: At line 5 of file x.f90 Fortran runtime error: Bad integer for item 1 in list input Expected: gfortran prints out the filename and/or unit as other compilers do; especially useful for users which don't have the source code. g95: At line 5 of file x.f90 (Unit 99 "foo.dat") Fortran runtime error: Bad integer for item 1 in list input NAG f95: Invalid input for integer editing Program terminated by I/O error on unit 99 (File="foo.dat",Formatted,Sequential) ifort: forrtl: severe (59): list-directed I/O syntax error, unit 99, file /dev/shm/foo.dat sunf95: Error 1083: unexpected character in integer value Location: the READ statement at line 5 of "x.f90" Unit: 99 File: foo.dat Input: z For stdin * they show (g95,NAG f95, ifort, sunf95): At line 4 of file x.f90 (Unit 5) Program terminated by I/O error on unit 5 (Input_Unit,Formatted,Sequential) forrtl: severe (59): list-directed I/O syntax error, unit -4, file /dev/pts/0 Unit: * File: standard input -- Summary: IO error message should show Unit/Filename Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: libfortran 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=32456
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #3 from jv244 at cam dot ac dot uk 2007-06-21 14:28 --- this is the list of options I have tested, the comment indicates if this yields a failure or not, basically, you need -O2 and -march=native to trigger the bug using '-O1 -march=native -pg' or '-O2 -pg' are not sufficient # OK FCFLAGS="-O3 -ffast-math -ftree-vectorize -funroll-loops -march=native" # wrong FCFLAGS="-O3 -ffast-math -ftree-vectorize -march=native -funroll-loops -pg" # OK FCFLAGS="-O1 -march=native -pg" # OK FCFLAGS="-O1 -march=native -ftree-vectorize -pg" # wrong FCFLAGS="-O2 -march=native -ftree-vectorize -pg" # wrong FCFLAGS="-O2 -march=native -pg" # OK FCFLAGS="-O2 -pg" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug middle-end/32447] without-decimal-float needed
--- Comment #3 from malitzke at metronets dot com 2007-06-21 14:33 --- Thanks for helping out again. Enjoy Japan. I was there quite often, dealing with NEC and Mitsubishi, but as a buyer representative for for multi-million $ projects. At that level it was pleasure to do business, even enduring sitting cross-legged on the floor; washing down raw fish with japanese whiskey on the rocks. But to matters at hand. What is called a compiler is actually a crime against traditional usage of the term. "compilare to plunder; 1: to collect into a volume 2: to compose out of materials from other documents" this more accurately describes the function of a traditional loader. A, so-called, compiler is really a translator. In the case of GCC the Italian saying "tradutore; traditore" translator; traitor seems appropriate. I know how hard it is to do technical translation, but that was my first well-paid career at about 15 years of age. My third career was being a real-time assembly language programmer. I received a letter of commendation as a super-programmer for committing the following programming crimes 1) jumping into the middle of instructions; 2) writing self-modifying code. You do what you have to do to put food on the table. I actually jeopardized a three month engagement by showing with the help of simple queuing theory that the project (in-spite of the above tricks) was doomed to fail. The COBOL manager assured me that I was doing a marvelous job squeezing code into 128 byte overlays and not to worry about over-all design. They bought back that contract. In my fourth career I was termed by the company president to-be "our secret weapon" for writing specifications, contracts, and inter-national standards that with-stood the test of legality but were blatantly uni-sided in favor of my employer (very good money). Now, being retired and considering the C and FORTRAN compilers as quite important tools in my UNIX tool-chest; I am trying to prevent GCC being destroyed by mis-interpretation and mis-use of standards legal shenanigans, etc. My loyalty is to "my" tools and not to the people involved with GCC or even GCC as now interpreted. See PR32347. Incidentally, two quotes from K&R "Again because the language reflects the capabilities of current computers, C programs tend to be efficient enough that there is no compulsion to write assembly language instead" (Intro 1st ed). '(ANSI) established a committee whose goal was to produce "and unambiguous and machine-independent definition of the language C" while still _retaining_ its _spirit_'. Preface 2nd Ed, emphasis added. Ritchie got a "Turing Award" and the current crop of people should respect the creator's wishes. If they want to make changes against that original design and call it something else; just as Ritchie acknowledges BCPL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32447
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #9 from hubicka at ucw dot cz 2007-06-21 14:39 --- Subject: Re: [4.3 Regression] cannot take address of bit field > > > --- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-21 11:19 > --- > Ping? I tought the bug is long fixed by moving the folding from fold into Gimple fold_stmt. We probably should not emit frontend warnings/errors that late, I will check if I can get it done earlier at gimplification time. Otherwise Andrew's patch to avoid the folding for bit_field_type is probably way to go. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug target/32455] internal compiler error: in convert_move, at expr.c:362
--- Comment #1 from frederic dot schuh at neuf dot fr 2007-06-21 14:49 --- Created an attachment (id=13757) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13757&action=view) preprocessed file in attachment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug target/32457] New: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
This is with the polyhedron test gas_dyn.f90 http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html It only occurs for gas_dyn.f90 and only with -m32 (-m64 is ok). This is with gcc-Version 4.3.0 20070621 on x86_64-unknown-linux-gnu. gfortran -m32 -march=opteron -ftree-vectorize -O1 gas_dyn.f90 time ./a.out real0m0.005s -- Summary: [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: i586-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #10 from rguenther at suse dot de 2007-06-21 14:52 --- Subject: Re: [4.3 Regression] cannot take address of bit field On Thu, 21 Jun 2007, hubicka at ucw dot cz wrote: > > > --- Comment #9 from hubicka at ucw dot cz 2007-06-21 14:39 --- > Subject: Re: [4.3 Regression] cannot take address of bit field > > > > > > > --- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-21 11:19 > > --- > > Ping? > > I tought the bug is long fixed by moving the folding from fold into > Gimple fold_stmt. We probably should not emit frontend warnings/errors > that late, I will check if I can get it done earlier at gimplification > time. Otherwise Andrew's patch to avoid the folding for bit_field_type > is probably way to go. The bug is still there and we fail to build the kernel because of it still. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-21 14:54 --- Subject: Bug 32453 Author: rguenth Date: Thu Jun 21 14:54:47 2007 New Revision: 125922 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125922 Log: 2007-06-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32453 * tree-vrp.c (extract_range_from_assert): Build POINTER_PLUS_EXPR for pointer anti-range. * gcc.c-torture/compile/pr32453.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32453.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug tree-optimization/32453] [4.3 Regression] ICE in build2_stat, at tree.c:3074 (extract_range_from_assert)
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-21 14:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32453
[Bug tree-optimization/32451] [4.3 Regression] ICE in verify_flow_info after DOM2
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-06-21 14:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32451
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-21 15:58 --- Missed to say that yesterday's version (r125874) was ok. Occurs here with 125909 (bootstrapped) and 125922 (only build). svn status shows no changes in my tree. However, it could not be reproduced by Uros with 125920 on i686. (Mine was x86-64 with -m32.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #9 from rask at sygehus dot dk 2007-06-21 15:59 ---
I tried this on top of the patch in comment 3 of bug 32441:
Index: gcc/config/m32c/m32c.c
===
--- gcc/config/m32c/m32c.c (revision 125892)
+++ gcc/config/m32c/m32c.c (working copy)
@@ -1143,7 +1143,7 @@ m32c_eh_return_stackadj_rtx (void)
{
rtx sa;
- sa = gen_reg_rtx (Pmode);
+ sa = gen_rtx_REG (Pmode, R0_REGNO);
cfun->machine->eh_stack_adjust = sa;
}
return cfun->machine->eh_stack_adjust;
The build then ends with a reload failure in libstdc++.
Spilling for insn 228.
reload failure for reload 0
Reloads for insn # 228
Reload 0: reload_in (HI) = (plus:HI (reg/f:HI 7 fb)
(const_int 0 [0x0]))
A_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (plus:HI (reg/f:HI 7 fb)
(const_int 0 [0x0]))
The lreg dump shows some insn sequences which use up both registers in
A_REGS:
(jump_insn 237 235 238 5 (set (pc)
(label_ref 236)) 163 {jump} (nil))
(barrier 238 237 227)
(code_label/s 227 238 230 6 56 "" [1 uses])
(note 230 227 228 6 [bb 6])
(insn 228 230 229 6 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
(insn 229 228 102 6 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))
...
(jump_insn 243 241 244 13 (set (pc)
(label_ref 242)) 163 {jump} (nil))
(barrier 244 243 223)
(code_label/s 223 244 226 14 55 "" [1 uses])
(note 226 223 224 14 [bb 14])
(insn 224 226 225 14 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
(insn 225 224 166 14 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))
(note/s 166 225 168 14 "" 52)
...
(insn 203 197 231 15
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527
(use (reg/i:HI 0 r0)) -1 (nil))
(code_label/s 231 203 234 16 57 "" [1 uses])
(note 234 231 232 16 [bb 16])
(insn 232 234 233 16 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
(insn 233 232 185 16 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))
(code_label/s 185 233 186 17 53 "" [3 uses])
(note 186 185 187 17 [bb 17])
The usage count is one too high for all the code labels shown above. In
other words, the code that is causing reload problems is dead code. The code
first appears in the "eh" pass and refers to a0 and a1 from the beginning.
int
m32c_eh_return_data_regno (int n)
{
switch (n)
{
case 0:
return A0_REGNO;
case 1:
return A1_REGNO;
default:
return INVALID_REGNUM;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #10 from rask at sygehus dot dk 2007-06-21 16:15 ---
Created an attachment (id=13758)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13758&action=view)
Preprocessed source code for the problem in comment 9.
$ ./xgcc -B./ -S -dp -o /dev/null ~/complex_io.cc
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:
In function 'std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&)
[with _Tp = long double, _CharT = char, _Traits = std::char_traits]':
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
error: unable to find a register to spill in class 'A_REGS'
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
error: this is the insn:
(insn 228 230 229 6 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
internal compiler error: in spill_failure, at reload1.c:2002
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #16 from dir at lanl dot gov 2007-06-21 16:16 --- Created an attachment (id=13759) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13759&action=view) Warning free version -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug c++/32458] New: __attribute((section(".myname"))) is not working as expected in G++ but works ni GCC
I used the simple program provided in the gcc help pages.
i am using gcc-4.2.0 cross compiler for ARM (I think the problem
should persist in native compilers as well)
a.c
#include
int main(void) {
static int a __attribute__ ((section (".offsets"))) = 0;
static int myname __attribute__ ((section (".offsets"))) = 0 ;
//static char stack[1] __attribute__ ((section (".stack"))) =
{ 0 };
static int init_data __attribute__ ((section (".prems"))) = 0;
printf("Hellow world %d\n", 0);
return 0;
}
---
---a.cc
#include
int main(void) {
static int a __attribute__ ((section (".offsets"))) = 0;
static int myname __attribute__ ((section (".offsets"))) = 0 ;
//static char stack[1] __attribute__ ((section (".stack"))) =
{ 0 };
static int init_data __attribute__ ((section (".prems"))) = 0;
printf("Hellow world %d\n", 0);
return 0;
}
-
The files 'a.c' and 'a.cc' are the same except that the 'a.cc' is
treated as c++ file.
in a.o created from 'a.c' has the sections. but the a.o created from
'a.cc' doesn't have
command used:
arm-none-linux-gnueabi-gcc -c a.c
arm-none-linux-gnueabi-gcc -c a.cc
Please let me know if I am wrong here, or let me know if there is a
workaround to make the 'a.cc' to have the sections compiled in.
/Prem
--
Summary: __attribute((section(".myname"))) is not working as
expected in G++ but works ni GCC
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prem dot mallappa at gmail dot com
GCC build triplet: x86_64-pc-linux
GCC host triplet: x86_64-pc-linux
GCC target triplet: x86_64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32458
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #17 from dir at lanl dot gov 2007-06-21 16:29 --- I have attached version that generates no warnings with gfortran or g95. As I reduced, it the bug changed - that is the problem with optmization bugs - they are hard to trap. Anyway there is still a bug for some compilers. gfortran on the Macintosh and Linux are Ok. g77 is happy and gets the correct answer - [dranta:~/tests] dir% g77 -o g95Test02 g95Test02.f [dranta:~/tests] dir% g95Test02 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 g95 cannot decide which wrong answer it likes - [dranta:~/tests] dir% g95 -Wall -g -o g95Test02 g95Test02.f [dranta:~/tests] dir% g95Test02 1 lower triangular matrix with 3 rows row 1 -0.2000E+01 row 20.1000E+01 0.2000E+01 row 30.3000E+01 0.4000E+01 0.5000E+01 iprec = 1 1 lower triangular matrix with 3 rows row 1 -0.3999E+01 row 20.1000E+01 0.4000E+01 row 30.3000E+01 0.4000E+01 0.1000E+02 [dranta:~/tests] dir% g95 -Wall -O3 -o g95Test02 g95Test02.f [dranta:~/tests] dir% g95Test02 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 gfortran (i386-pc-mingw32) on windows now gets the wrong answer with -O3 - [EMAIL PROTECTED] ~/tests $ gfortran -g -o g95Test02 g95Test02.f [EMAIL PROTECTED] ~/tests $ g95Test02 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1100E+02 0.1200E+02 0.1300E+02 iprec = 1 1 lower triangular matrix with 3 rows row 10.1600E+02 row 20.9000E+01 0.2000E+02 row 30.1100E+02 0.1200E+02 0.2600E+02 [EMAIL PROTECTED] ~/tests $ gfortran -O3 -o g95Test02 g95Test02.f [EMAIL PROTECTED] ~/tests $ g95Test02 1 lower triangular matrix with 3 rows row 10.E+00 row 20.1000E+01 0.2000E+01 row 30.3000E+01 0.4000E+01 0.5000E+01 iprec = 1 1 lower triangular matrix with 3 rows row 10.E+00 row 20.1000E+01 0.4000E+01 row 30.3000E+01 0.4000E+01 0.1000E+02 [EMAIL PROTECTED] ~/tests $ gfortran --v Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070522 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
--- Comment #2 from sje at cup dot hp dot com 2007-06-21 16:30 ---
Here is a preprocessed test case"
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
unsigned char inb_local(unsigned long port) { unsigned char value; __asm__
__vol
atile__("in" "b" " %w1, %" "b" "0" : "=a"(value) : "Nd"(port)); return value; }
void
printk(const char *fmt, ...)
{
va_list argptr;
__builtin_va_start(argptr,fmt);
__builtin_va_end(argptr);
}
void
x_inb(unsigned short port)
{
unsigned char val;
val = inb_local(port);
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug c/31537] duplicate weakref emitted with IMA
--- Comment #5 from aldot at gcc dot gnu dot org 2007-06-21 16:44 --- Without combine, the attribute is ignored: $ gcc-4.3.orig-HEAD -c pr.c -o /dev/null pr.c: In function 'f1': pr.c:3: warning: '__weakref__' attribute ignored pr.c: In function 'f2': pr.c:7: warning: '__weakref__' attribute ignored while with combine and the original testcase, current trunk still gives: $ gcc-4.3.orig-HEAD -c f1.i f2.i -combine -o /dev/null /tmp/ccmg6Twk.s: Assembler messages: /tmp/ccmg6Twk.s:3: Error: symbol `__gthrw_pthread_once' is already defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31537
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #18 from burnus at gcc dot gnu dot org 2007-06-21 16:48 --- > Created an attachment (id=13759) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13759&action=view) [edit] > Warning free version Thanks, it finally compiles with NAG "f95 -dusty", which finds directly one problem: Subscript 1 of IA (value 2) is out of range (1:1) In PRMX, line 134 of test.f I changed ia(1) to ia(20) - then it works. Actually, it works on my system (x86_64-unknown-linux-gnu, 4.3.0 20070621) up to the option -O3 -ffast-math -ftree-vectorize -funroll-all-loops It also works now with ifort -O3 -xW, NAG f95, sunf95 and gfortran 4.1.0. Interestingly, both gfortran 4.2.0 and g95 now produce (no options) for the first matrix: row 10.E+00 row 20.1000E+01 0.2000E+01 row 30.3000E+01 0.4000E+01 0.5000E+01 g95 produces the same result as the others using "-fzero". Using NAG f95 with -nan the program crashes with an arithmetic exception, which means that either cc or sum in vr2 must be uninitialized when calling scprod. (-nan initializes the variables with signalling NaN.) Thus there is still a bug lurking in the source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-21 16:58 --- Dump a valid program which contains equivalence to show a harder case for the checks (NAG f95 chokes on it). program main implicit none integer :: i, it, jt real:: tt equivalence(jt,tt) dimension it(10) do i=1,10 tt=i print *, tt, jt it(i)=jt end do end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #19 from dominiq at lps dot ens dot fr 2007-06-21 17:04 --- > Subscript 1 of IA (value 2) is out of range (1:1) I don't think it really matter as dimension ia(1),a(20) is the old style for passing arrays. However there are many uninitialized variables: call vr2 ( intp, ivg, cc, ns, it) as far as I can tell none of them are initialized. On ppc-darwin7 latest 4.3 snapshot the new code gives the expected result as does xlf, but not g95. Tracing what is wrong with this code explains why so many people don't like fortran! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #16 from spop at gcc dot gnu dot org 2007-06-21 17:06 --- Subject: Bug 19590 Author: spop Date: Thu Jun 21 17:06:05 2007 New Revision: 125925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125925 Log: PR tree-optimization/19590 * tree-vrp.c (adjust_range_with_scev): Set the range when the result of scev is a constant. * gcc/testsuite/gcc.dg/tree-ssa/pr19590.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr19590.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
--- Comment #3 from sje at cup dot hp dot com 2007-06-21 17:10 ---
Slightly shorter test case:
unsigned char inb_local(unsigned long port)
{
unsigned char value;
__asm__ __volatile__("in" "b" " %w1, %" "b" "0" : "=a"(value) :
"Nd"(port));
return value;
}
void
x_inb(unsigned short port)
{
unsigned char val;
val = inb_local(port);
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-21 17:10:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug middle-end/32370] [4.3 Regression] Segfault after rejecting bogus assembler
--- Comment #4 from sje at cup dot hp dot com 2007-06-21 17:13 --- With optimization, it looks like we die because df_insn_change_bb can handle insn_info being NULL but it can't handle insn_info->defs (or uses or eq_uses) being NULL and that is what is happening with -O2. When no optimization is being done then the failure looks different. I believe this is due to the dataflow merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32370
[Bug fortran/32393] gfortran - incorrect run time results
--- Comment #20 from burnus at gcc dot gnu dot org 2007-06-21 17:14 --- > as far as I can tell none of them are initialized. This is why I'm eagerly waiting for Asher fixing PR20441 and why g95 has -fzero. > Tracing what is wrong with this code explains why so many people don't like > fortran! Well, modern Fortran code should be much better manageable; and initializing all variables by (signalling) NaN helps finding these errors for real/complex variables. Initializing all variables by zero circumvents these errors (and may yield the correct result if zero is the correct number for the initialization ;-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
[Bug target/32457] [4.3 Regression] Complete program optimized away (i686, -ftree-vectorize)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-21 17:22 --- Further note: -march=pentium2 works -march=pentium3 fails -march=pentium2 -msse fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
mjpegtools-1.9.0rc2 - internal compiler error - in a PowerPC
* the exact version of GCC; gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) * the system type; uname -a Linux ... 2.6.18-4-powerpc #1 Wed Apr 18 01:52:23 UTC 2007 ppc GNU/Linux * the complete command line that triggers the bug; cd mjpegtools-1.9.0rc2; ./configure; make Hi, GCC devs, This file: http://sourceforge.net/project/downloading.php?group_id=5776&use_mirror=ufpr&filename=mjpegtools-1.9.0rc2.tar.gz&46187108 ...generate this GCC error when we try make (allways): make[2]: Entrando no diretório `/tmp/mjpegtools-1.9.0rc2/y4mdenoise' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/local/include -I../utils -DNDEBUG -finline-functions -g -O2 -pthread -DHAVE_ALTIVEC_H=1 -maltivec -mabi=altivec -MT newdenoise.o -MD -MP -MF ".deps/newdenoise.Tpo" -c -o newdenoise.o newdenoise.cc; \ then mv -f ".deps/newdenoise.Tpo" ".deps/newdenoise.Po"; else rm -f ".deps/newdenoise.Tpo"; exit 1; fi MotionSearcher.hh: In instantiation of 'MotionSearcher, ReferencePixel >, ReferenceFrame >, short int, int> >::MatchThrottleFloodFillControl': MotionSearcher.hh:507: instantiated from 'MotionSearcher, ReferencePixel >, ReferenceFrame >, short int, int> >' newdenoise.cc:32: instantiated from here MotionSearcher.hh:2444: internal compiler error: in tsubst, at cp/pt.c:7226 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I wait that it helps. Aurium
[Bug fortran/31820] Warning if case label value exceeds maximum value for type
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-21 17:49 --- http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html -Wsurprising [...] This currently produces a warning under the following circumstances: * An INTEGER SELECT construct has a CASE that can never be matched as its lower value is greater than its upper value. * A LOGICAL SELECT construct has three CASE statements. The latter is implemented and gives: Warning: Logical SELECT CASE block at (1) has more that two cases but the former? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31820
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #19 from pault at gcc dot gnu dot org 2007-06-21 18:12 --- (In reply to comment #18) > Due to huge time constraints, I won't be able to > do anything with this for the next few weeks. Unassigning > myself for the time. > If anybody wants to look over my partial patch and fly with it, > he's welcome :-) My patch to 31726 fixes the inline stuff, or it does not break it, at least. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug libfortran/31726] minloc/maxloc: wrong results with empty array (F2003 only)
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-21 18:14 --- This fixes Tobias' testcase of comment #4. Note that it is a diff relative to the patch for 32298. I'll resubmit the latter in this new form. Paul Index: gcc/fortran/trans-intrinsic.c === *** gcc/fortran/trans-intrinsic.c (révision 125706) --- gcc/fortran/trans-intrinsic.c (copie de travail) *** gfc_conv_intrinsic_minmaxloc (gfc_se * s *** 1928,1933 --- 1928,1934 tree tmp; tree elsetmp; tree ifbody; + tree offset; gfc_loopinfo loop; gfc_actual_arglist *actual; gfc_ss *arrayss; *** gfc_conv_intrinsic_minmaxloc (gfc_se * s *** 2045,2059 /* Assign the value to the limit... */ gfc_add_modify_expr (&ifblock, limit, arrayse.expr); ! /* Remember where we are. */ ! gfc_add_modify_expr (&ifblock, pos, loop.loopvar[0]); ifbody = gfc_finish_block (&ifblock); ! /* If it is a more extreme value or pos is still zero. */ ! tmp = build2 (TRUTH_OR_EXPR, boolean_type_node, ! build2 (op, boolean_type_node, arrayse.expr, limit), ! build2 (EQ_EXPR, boolean_type_node, pos, gfc_index_zero_node)); tmp = build3_v (COND_EXPR, tmp, ifbody, build_empty_stmt ()); gfc_add_expr_to_block (&block, tmp); --- 2046,2068 /* Assign the value to the limit... */ gfc_add_modify_expr (&ifblock, limit, arrayse.expr); ! /* Remember where we are. An offset must be added to the loop ! counter to obtain the required position. */ ! if (loop.temp_dim) ! offset = build_int_cst (type, 1); ! else ! offset =fold_build2 (MINUS_EXPR, gfc_array_index_type, !gfc_index_one_node, loop.from[0]); ! offset = gfc_evaluate_now (offset, &block); ! ! tmp = build2 (PLUS_EXPR, TREE_TYPE (pos), ! loop.loopvar[0], offset); ! gfc_add_modify_expr (&ifblock, pos, tmp); ifbody = gfc_finish_block (&ifblock); ! /* If it is a more extreme value. */ ! tmp = build2 (op, boolean_type_node, arrayse.expr, limit); tmp = build3_v (COND_EXPR, tmp, ifbody, build_empty_stmt ()); gfc_add_expr_to_block (&block, tmp); *** gfc_conv_intrinsic_minmaxloc (gfc_se * s *** 2098,2109 } gfc_cleanup_loop (&loop); ! /* Return a value in the range 1..SIZE(array). */ ! tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, loop.from[0], !gfc_index_one_node); ! tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, pos, tmp); ! /* And convert to the required type. */ ! se->expr = convert (type, tmp); } static void --- 2107,2113 } gfc_cleanup_loop (&loop); ! se->expr = convert (type, pos); } static void -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-27 13:16:34 |2007-06-21 18:14:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31726
[Bug target/32418] ICE in global_alloc, at global.c:514
--- Comment #11 from rask at sygehus dot dk 2007-06-21 18:19 --- Disregard the comment about the code label use count. They have LABEL_PRESERVE_P (/s) set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32418
