[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #6 from janus at gcc dot gnu dot org 2008-10-20 08:09 --- Actually I don't understand this ifort error message. I had a look in the standard, but couldn't find anything which would render the IMPORT statement invalid. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-20 08:09:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-20 08:56 --- With ifort (IFORT) 10.1 20070913, I get: fortcom: Error: pr35971_red.f90, line 11: Syntax error, found IDENTIFIER 'INTERFACE' when expecting one of: => = . ( : % abstract interface ^ fortcom: Error: pr35971_red.f90, line 14: This statement is permitted only in an INTERFACE block import my_message -^ fortcom: Error: pr35971_red.f90, line 11: This statement must not appear in the specification part of a module abstract interface ---^ fortcom: Error: pr35971_red.f90, line 11: A specification statement cannot appear in the executable section. abstract interface ^ ... a lot of errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-10-20 09:40 --- Heh, nobody ever will need more than 32 parameters! -- 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=37669
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #12 from dodji at gcc dot gnu dot org 2008-10-20 10:20 --- So what do we do with this PR ? Do we mark it with "waiting for feeback" until someone comes up with numbers about debug info size ?. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #24 from ktietz at gcc dot gnu dot org 2008-10-20 11:24 --- This bug is reasoned by some problems in ira. IIUC, mingw 32-bit has the same issue here. This bug can be worked around by disable ira optimization via -fno-ira. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug fortran/35971] ICE on valid code with C_FUNPTR and transfer
--- Comment #3 from janus at gcc dot gnu dot org 2008-10-20 12:02 --- *** This bug has been marked as a duplicate of 36463 *** -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35971
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #9 from janus at gcc dot gnu dot org 2008-10-20 12:02 --- *** Bug 35971 has been marked as a duplicate of this bug. *** -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab
--- Comment #9 from krebbel at gcc dot gnu dot org 2008-10-20 12:07 --- (In reply to comment #8) > Does s390x-linux bootstrap now (possibly with PR37815 fix as well)? Can this > be closed? This particular problem seems to be fixed for s390x. GCC still doesn't bootstrap - even with the patch from PR37815. There still is a problem with value range propagation. I'm working on this. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab
--- Comment #10 from krebbel at gcc dot gnu dot org 2008-10-20 12:08 --- My testcase works fine with current GCC mainline. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug c++/37876] New: making QuantLib-0.9.6 on AIX 5300-07
installed boost ok, then ran ./configure --with-boost-include=/usr/local/include/boost-1_36 --with-boost-lib=/usr/local/lib to configure quantlib which worked OK then ran make which coredumped at building conundrumpricer. built other objects prior but dumps on this one. Below is extract ouptput only for this object. if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../.. -I/usr/local/include/boost-1_36 -g -O2 -Wall -MT conundrumpricer.lo -MD -MP -MF ".deps/conundrumpricer.Tpo" -c -o conundrumpricer.lo conundrumpricer.cpp; then mv -f ".deps/conundrumpricer.Tpo" ".deps/conundrumpricer.Plo"; else rm -f ".deps/conundrumpricer.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../.. -I/usr/local/include/boost-1_36 -g -O2 -Wall -MT conundrumpricer.lo -MD -MP -MF .deps/conundrumpricer.Tpo -c conundrumpricer.cpp -DPIC -o .libs/conundrumpricer.o conundrumpricer.cpp:912: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 1. Stop. -- Summary: making QuantLib-0.9.6 on AIX 5300-07 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ibellinfantie at yahoo dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37876
[Bug rtl-optimization/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537
--- Comment #7 from martin at mpa-garching dot mpg dot de 2008-10-20 12:48
---
I still see the crash:
/scratch/blah4/planck/LevelS>gfortran -v -c -O2 testcase.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data/martin/ugcc --with-mpfr-include=/usr/include
--with-mpfr-lib=/usr/lib --with-gmp-include=/usr/include
--with-gmp-lib=/usr/lib --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.4.0 20081020 (experimental) [trunk revision 141239] (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-mtune=generic'
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951
testcase.f90 -quiet -dumpbase testcase.f90 -mtune=generic -auxbase testcase -O2
-version -fintrinsic-modules-path
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0/finclude -o
/tmp/cc4O8vOv.s
GNU Fortran (GCC) version 4.4.0 20081020 (experimental) [trunk revision 141239]
(i686-pc-linux-gnu)
compiled by GNU C version 4.4.0 20081020 (experimental) [trunk revision
141239], GMP version 4.2.1, MPFR version 2.3.1.
warning: GMP header version 4.2.1 differs from library version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
testcase.f90: In function 'gn_monte_rand':
testcase.f90:50: internal compiler error: in subst_stack_regs_pat, at
reg-stack.c:1537
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
[Bug c/37874] gcc sometimes accepts attribute in identifier list
--- Comment #4 from joseph at codesourcery dot com 2008-10-20 12:48 --- Subject: Re: gcc sometimes accepts attribute in identifier list On Mon, 20 Oct 2008, sabre at nondot dot org wrote: > as it turns out, f3 could also be considered valid in c89... because it makes > x > and y be implicit int's, not an identifier list. All parameters need a nonempty list of declaration specifiers in a parameter type list, which y doesn't have in that case. Implicit int in C90 (removed in C99) means that list could just be "const", for example, but not completely empty. That the first parameter in a parameter type list must have some *non-attribute* declaration specifier is documented in "Attribute Syntax" along with the ambiguity this resolves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37874
[Bug c++/37877] New: Invalid "invalid use of static" error
I believe this is valid C++:
extern "C++" struct S { static int x; } s;
g++ 4.2.4, 4.3.1, and the Debian version of 4.3.2 reject the declaration with
the error:
static.cpp:1: error: invalid use of static in linkage specification
I don't think static members of structures were intended to be disallowed by
the prohibition duplicate storage classes in declarations like
extern "lang" static int x;
This seems to fix the problem:
===
--- gcc/gcc/cp/parser.c (revision 5135)
+++ gcc/gcc/cp/parser.c (revision 5136)
@@ -13423,6 +13423,7 @@
bool nested_name_specifier_p;
unsigned saved_num_template_parameter_lists;
bool saved_in_function_body;
+ bool saved_in_unbraced_linkage_specification_p;
tree old_scope = NULL_TREE;
tree scope = NULL_TREE;
tree bases;
@@ -13475,6 +13476,10 @@
/* We are not in a function body. */
saved_in_function_body = parser->in_function_body;
parser->in_function_body = false;
+ /* We are not immediately inside an extern "lang" block */
+ saved_in_unbraced_linkage_specification_p
+= parser->in_unbraced_linkage_specification_p;
+ parser->in_unbraced_linkage_specification_p = false;
/* Start the class. */
if (nested_name_specifier_p)
@@ -13587,6 +13592,8 @@
parser->in_function_body = saved_in_function_body;
parser->num_template_parameter_lists
= saved_num_template_parameter_lists;
+ parser->in_unbraced_linkage_specification_p
+= saved_in_unbraced_linkage_specification_p;
return type;
}
--
Summary: Invalid "invalid use of static" error
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jfc at mit dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37877
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-20 13:45 --- Created an attachment (id=16516) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16516&action=view) gcc44-pr36038.patch My bet is that adding a zero based alternative IV for a pointer is always a bug, the zero based IV will necessarily act as an offset to some other pointer (the original pointer). With this patch the ivopts dump looks much saner, the ivtmp is sizetype and so nothing is cast to and back from a pointer all the time, additionally vrp2 doesn't optimize it out and so the testcase succeeds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug c++/37875] New: [c++0x] misinterpreted closing angle bracket in decltype operand
I think g++ incorrectly rejects the following code when compiled with
-std=c++0x:
template struct X {};
X 2)> x;
// t.cpp:2: error: template argument 1 is invalid
// t.cpp:2: error: invalid type in declaration before ; token
For comparison, here is very similar code that is accepted:
template struct Y {};
Y 2)> y;
Hence, I suspect it is a problem with decltype.
--
Summary: [c++0x] misinterpreted closing angle bracket in decltype
operand
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37875
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #19 from jakub at gcc dot gnu dot org 2008-10-20 14:02 --- As arg_mask is only 1, 2 or 4, the fix could be e.g. just break at the end of if ((arg_mask >> i) & 1) body, or changing the for condition to i < nargs && i <= 31. But if the former, we might as well turn arg_mask into arg_index, we never set more than 1 bit in it, and not loop at all. The loop made sense in 4.2 and earlier where we had to walk the tree chain to get at the arguments, now we have an array, so all we need is verify we have enough arguments (assert should be enough, otherwise it wouldn't be a builtin?) and just call get_maxval_strlen on the right argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
--- Comment #8 from janus at gcc dot gnu dot org 2008-10-20 09:19 --- I think ifort 10.1 does neither support ABSTRACT interfaces, nor PROCEDURE statements (therefore it cannot compile this test case). But there is a 11.0 beta which does support both, and which gives the error Tobias reported in comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug debug/37020] [4.4 Regression] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-20 11:10 --- Mine. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-08 14:38:39 |2008-10-20 11:10:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37020
[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab
--- Comment #8 from jakub at gcc dot gnu dot org 2008-10-20 11:46 --- Does s390x-linux bootstrap now (possibly with PR37815 fix as well)? Can this be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #8 from sje at cup dot hp dot com 2008-10-20 15:02 --- With respect to comment #5, the problem isn't changing the library side. It is changing the compiler side. The compiler, as near as I can tell, doesn't declare the structure the way the library does but builds offsets based on the type information in ioparm.def. Is is these offsets that need to change and ioparm.def can't be ifdef'ed as is. We would need to add an explicit preprocessing of the file or add code to the compiler to adjust the offsets after creating them from ioparm.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #26 from jakub at gcc dot gnu dot org 2008-10-20 15:10 --- On the #c11 testcase with -O2 -funsafe-math-optimizations I still see # cn_38 = PHI <-1.0e+0(4), 1.0e+0(11)> D.1262_39 = __builtin_pow (cn_38, 2.0e+0); D.1263_41 = 1.0e+0 - D.1262_39; D.1264_42 = __builtin_sqrt (D.1263_41); before and after PRE, so the recent pre change doesn't handle it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #27 from dberlin at gcc dot gnu dot org 2008-10-20 16:22 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math Err, works for me with -O2 -ffast-math Replaced D.1587_48 - D.1591_50 with prephitmp.17_60 in D.1600_23 = D.1587_48 - D.1591_50; Replaced ABS_EXPR with prephitmp.17_62 in D.1601_24 = ABS_EXPR ; Replaced __builtin_pow (cn_35, 2.0e+0) with 1.0e+0 in D.1583_36 = __builtin_pow (cn_35, 2.0e+0); Replaced 1.0e+0 - D.1583_36 with 0.0 in D.1584_37 = 1.0e+0 - D.1583_36; Replaced __builtin_sqrt (D.1584_37) with 0.0 in D.1585_38 = __builtin_sqrt (D.1584_37); Replaced __builtin_atan2 (D.1585_38, cn_35) with prephitmp.17_1 in D.1586_39 = __builtin_atan2 (D.1585_38, cn_35); and -O2 -funsafe-math-optimizations Replaced D.1587_48 - D.1591_50 with prephitmp.17_60 in D.1600_23 = D.1587_48 - D.1591_50; Replaced ABS_EXPR with prephitmp.17_62 in D.1601_24 = ABS_EXPR ; Replaced __builtin_pow (cn_35, 2.0e+0) with 1.0e+0 in D.1583_36 = __builtin_pow (cn_35, 2.0e+0); Replaced 1.0e+0 - D.1583_36 with 0.0 in D.1584_37 = 1.0e+0 - D.1583_36; Replaced __builtin_sqrt (D.1584_37) with 0.0 in D.1585_38 = __builtin_sqrt (D.1584_37); Replaced __builtin_atan2 (D.1585_38, cn_35) with prephitmp.17_1 in D.1586_39 = __builtin_atan2 (D.1585_38, cn_35); Are you sure you updated? On Mon, Oct 20, 2008 at 11:10 AM, jakub at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #26 from jakub at gcc dot gnu dot org 2008-10-20 15:10 > --- > On the #c11 testcase with -O2 -funsafe-math-optimizations I still see > # cn_38 = PHI <-1.0e+0(4), 1.0e+0(11)> > D.1262_39 = __builtin_pow (cn_38, 2.0e+0); > D.1263_41 = 1.0e+0 - D.1262_39; > D.1264_42 = __builtin_sqrt (D.1263_41); > before and after PRE, so the recent pre change doesn't handle it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #28 from jakub at gcc dot gnu dot org 2008-10-20 17:27 --- -fno-math-errno was needed too to get it optimized out, with that it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug c/12603] No return statement warning on function that never returns with -O3
--- Comment #8 from manu at gcc dot gnu dot org 2008-10-20 18:27 --- Subject: Bug 12603 Author: manu Date: Mon Oct 20 18:26:21 2008 New Revision: 141244 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141244 Log: 2008-10-20 Manuel López-Ibáñez <[EMAIL PROTECTED]> PR 12603 * gcc.dg/pr12603.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr12603.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
[Bug c/12603] No return statement warning on function that never returns with -O3
--- Comment #9 from manu at gcc dot gnu dot org 2008-10-20 18:28 --- This got fixed somehow. There is a testcase in the testsuite to make sure we do not regress. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #13 from jason at redhat dot com 2008-10-20 19:01 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always Could you (Dodji) try building libstdc++ with -femit-class-debug-always, and see how much it affects the size of the library? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #14 from jason at redhat dot com 2008-10-20 19:02 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always Building Firefox or OpenOffice with/without the flag would also be a good test. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug rtl-optimization/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537
--- Comment #8 from ubizjak at gmail dot com 2008-10-20 19:37 --- Adding either -fno-reorder-blocks or -fno-ira works OK for orignal fortran testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
[Bug c/12603] No return statement warning on function that never returns with -O3
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-10-20 20:42 --- (In reply to comment #9) > This got fixed somehow. There is a testcase in the testsuite to make sure we > do > not regress. This was most likely fixed by: 2008-09-17 Jan Hubicka <[EMAIL PROTECTED]> PR c++/18071 * tree.h (DECL_INLINE): remove. (DECL_DECLARED_INLINE_P): Update docs. (DECL_NO_INLINE_WARNING_P): new. (tree_function_decl): Replace inline_flag by no_inline_warning_flag. * tree-inline.c (inlinable_function_p): Set DECL_NO_INLINE_WARNING_P. :) Which removed DECL_INLINE. As I mentioned in comment #4 DECL_INLINE was the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
[Bug middle-end/37876] making QuantLib-0.9.6 on AIX 5300-07
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-20 21:06 --- What are your limits set to and can you provide the preprocessed source as requested by http://gcc.gnu.org/bugs.html ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37876
[Bug fortran/37836] ICE in gfc_trans_auto_array_allocation
--- Comment #1 from pault at gcc dot gnu dot org 2008-10-20 22:21 --- minval and maxval do not get simplified. Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-20 22:21:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37836
[Bug debug/37020] [4.4 Regression] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-20 23:00 --- Subject: Bug 37020 Author: jakub Date: Mon Oct 20 22:59:13 2008 New Revision: 141253 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141253 Log: PR debug/37020 * c-decl.c (merge_decls): Don't call outlining_inline_function hook. Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37020
[Bug debug/37020] [4.4 Regression] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-20 23:09 --- 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=37020
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #29 from jakub at gcc dot gnu dot org 2008-10-20 23:14 --- Closing as INVALID, as using -ffast-math is wrong for calculix, at least for the distilled testcase from it. In the testcase +0 vs. -0 makes very big difference (atan2 acts very similarly to copysign) and so compiling with an option that says to the compiler that +0 vs. -0 is insignificant may result in very unexpected results. Most probably compiling calculix with -O -ffast-math -fsigned-zeros could work. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-20 23:15 --- Patch posted. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00835.html Status|NEW |ASSIGNED Last reconfirmed|2008-04-25 09:24:16 |2008-10-20 23:15:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug target/37878] New: PPC64 ldu command generated with invalid offset
With this compiler: [descartes:gcc/objdirs/gambc-v4_1_2] lucier% /pkgs/gcc-4.4.0-64/bin/gcc -v Using built-in specs. Target: powerpc64-apple-darwin9.5.0 Configured with: ../../mainline/configure CC='/usr/bin/gcc-4.0 -mcpu=970 -m64' --disable-werror --build=powerpc64-apple-darwin9.5.0 --host=powerpc64-apple-darwin9.5.0 --target=powerpc64-apple-darwin9.5.0 --with-gmp-include=/sw/include/ --with-gmp-lib=/sw/lib/ppc64 --with-mpfr-include=/sw/include/ --with-mpfr-lib=/sw/lib/ppc64 --prefix=/pkgs/gcc-4.4.0-64 --with-libiconv-prefix=/usr --with-system-zlib Thread model: posix gcc version 4.4.0 20081020 (experimental) [trunk revision 141240] (GCC) I get this error: [descartes:gcc/objdirs/gambc-v4_1_2] lucier% /pkgs/gcc-4.4.0-64/bin/gcc -save-temps -mcpu=970 -m64 -I../include -I. -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -c assemtest.i gcc: unrecognized option '-no-cpp-precomp' assemtest.s:69:Parameter error: expression must be a multiple of 4 (parameter 2) The offending assembler command is ldu r0,7(r9) I'll include assemtest.i; the code itself is about 50 lines of machine-generated C code, plus a lot of declarations so I could get it to compile separately. -- Summary: PPC64 ldu command generated with invalid offset Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc64-apple-darwin9.5.0 GCC host triplet: powerpc64-apple-darwin9.5.0 GCC target triplet: powerpc64-apple-darwin9.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug target/37878] PPC64 ldu command generated with invalid offset
--- Comment #1 from lucier at math dot purdue dot edu 2008-10-21 00:32 --- Created an attachment (id=16517) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16517&action=view) test file input This is the .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug target/37878] PPC64 ldu command generated with invalid offset
--- Comment #2 from lucier at math dot purdue dot edu 2008-10-21 00:33 --- Created an attachment (id=16518) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16518&action=view) test file output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug fortran/33759] ICE in transfer_simplify_4.f90 at any level of optimization
--- Comment #14 from pault at gcc dot gnu dot org 2008-10-21 06:28 --- This one keeps falling off the pending pile - unassigning myself for now. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pault at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
