[Bug target/29413] -EB / -EL don't properly affect gcc predefined symbols
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-12 07:05 --- [EMAIL PROTECTED] gcc]$ ./xgcc -B. -EL -dM -E -C -x c /dev/null | grep MIPSE #define __MIPSEL__ 1 #define MIPSEL 1 #define _MIPSEL 1 #define __MIPSEL 1 [EMAIL PROTECTED] gcc]$ ./xgcc -B. -EB -dM -E -C -x c /dev/null | grep MIPSE #define MIPSEB 1 #define __MIPSEB__ 1 #define _MIPSEB 1 #define __MIPSEB 1 [EMAIL PROTECTED] gcc]$ ./xgcc -B. -EB -dM -E -C -x c /dev/null -v Using built-in specs. Target: mipsisa32-elf Configured with: ../configure --target=mipsisa32-elf : (reconfigured) Thread model: single gcc version 4.0.4 20061010 (prerelease) Hmm, If this does not work then the order of config/linux.h and config/mips/mips.h are wrong and config/linux.h is being included first which defines CC1_SPEC and then config/mips/mips.h checks to see if CC1_SPEC is defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug target/29413] -EB / -EL don't properly affect gcc predefined symbols
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 07:08 ---
Yep that is what is happening:
mips64*-*-linux*)
tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h
mips/linux64.h"
.
;;
mips*-*-linux*) # Linux MIPS, either endian.
tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h"
esac
;;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug target/29413] -EB / -EL don't properly affect gcc predefined symbols
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-12 07:27 --- Actually it was only caused recently for mips-linux (non64bit): 2002-08-02 Eric Christopher <[EMAIL PROTECTED]> * config.gcc (mips*-*-linux*): Fix ordering of tm_file. * config/mips/mips.h (READONLY_DATA_SECTION_ASM_OP): Change #ifndef to #undef. (TARGET_MEM_FUNCTIONS): Define instead of define to 1. mips64-linux-gnu was always wrong. The correct order was in http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01743.html But was wrong before that patch And then was broken again with http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00204.html The not having the define means we are also creating wrong code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|mips*-linux |mips*-linux* Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug target/29413] -EB / -EL don't properly affect gcc predefined symbols
-- 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 |2006-10-12 07:29:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug target/29413] -EB / -EL don't properly affect endian for Linux on MIPS
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-12 07:33 --- *** Bug 23824 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ondrap at penguin dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug target/23824] Using mipsel to compile BigEndian -O2 does not work
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 07:33 --- The problem is that -EB and -EL are not recognized by the compiler because of a bug. you can work around this issue by using -meb or -mel. Anyways this is a dup of bug 29413 which shows the problem and shows what is wrong and maybe a way to fix it. *** This bug has been marked as a duplicate of 29413 *** -- 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=23824
[Bug c++/29388] [4.0/4.1/4.2 regression] ICE with invalid nested name specifier
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-12 08:13 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2006-10-12 08:13:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-12 08:20 --- Execution times (seconds) garbage collection: 0.88 ( 1%) usr 0.00 ( 0%) sys 0.87 ( 1%) wall 0 kB ( 0%) ggc preprocessing : 0.10 ( 0%) usr 0.04 ( 1%) sys 0.22 ( 0%) wall 796 kB ( 0%) ggc parser: 17.90 (14%) usr 0.77 (15%) sys 19.39 (15%) wall 325217 kB (64%) ggc name lookup : 94.51 (76%) usr 4.25 (84%) sys 98.43 (75%) wall 175474 kB (34%) ggc tree gimplify : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 2548 kB ( 1%) ggc varconst : 11.33 ( 9%) usr 0.01 ( 0%) sys 11.33 ( 9%) wall 2833 kB ( 1%) ggc symout: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 32 kB ( 0%) ggc TOTAL : 124.80 5.08 130.45 508745 kB and using peak 1.7GB ram (x86_64 with -m32) on the trunk. I guess we're just not collecting garbage during parsing at all. Note that I get errors from compiling the testcase though: [... very large template ...] test_basic_metafunctions.hpp:176: instantiated from here ../src/sd/../static_component.hpp:91: error: 'process_outputs' is not a member of 'mpl_::void_' (4.1 also isn't happy with the testcase) Can you by any chance provide a testcase that compiles ok with at least gcc 4.1.x? (even better mainline...) Thanks! Profiling the bugger yields: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ks/call Ks/call name 12.44178.30 178.30 121375686 0.00 0.00 comptypes 9.29311.48 133.18 218375227 0.00 0.00 dump_aggr_type 8.69436.02 124.54 19998 0.00 0.00 comp_template_args 8.59559.19 123.17 620924334 0.00 0.00 pp_base_append_text 7.85671.72 112.53 1278486 0.00 0.00 retrieve_specialization 6.92770.9999.27 173585104 0.00 0.00 template_args_equal 6.54864.8093.81 462049326 0.00 0.00 pp_base_character 5.05937.2472.4467358 0.00 0.00 ht_lookup 3.32984.7947.55 620924334 0.00 0.00 pp_base_string 3.13 1029.7144.92 186232097 0.00 0.00 dump_decl 2.58 1066.6536.95 218532269 0.00 0.00 pp_c_type_qualifier_list 2.36 1100.4633.81 16289532 0.00 0.00 dump_template_parms 2.32 1133.7133.25 404449103 0.00 0.00 dump_scope 2.28 1166.4032.69 218677178 0.00 0.00 dump_type 1.95 1194.4028.00 404642903 0.00 0.00 pp_c_identifier 1.78 1219.9225.53 218375227 0.00 0.00 class_key_or_enum_as_string 1.38 1239.6519.73 216176146 0.00 0.00 dump_template_argument 1.03 1254.3714.72 3919144 0.00 0.00 purpose_member 0.88 1266.9412.57 108004962 0.00 0.00 pp_base_last_position_in_text 0.68 1276.74 9.80 162182109 0.00 0.00 pp_cxx_separate_with 0.61 1285.53 8.80 202214181 0.00 0.00 pp_cxx_colon_colon 0.41 1291.38 5.85 54002002 0.00 0.00 pp_cxx_end_template_argument_list 0.41 1297.19 5.81 5800051 0.00 0.00 ggc_alloc_stat 0.40 1302.92 5.73 4113746 0.00 0.00 tsubst 0.37 1308.20 5.29 54002002 0.00 0.00 pp_cxx_begin_template_argument_list 0.31 1312.58 4.38 301296 0.00 0.00 pp_base_emit_prefix 0.30 1316.88 4.30 450268 0.00 0.00 gt_ggc_mx_lang_tree_node 0.27 1320.81 3.93 302601 0.00 0.00 reinit_cxx_pp 0.27 1324.73 3.92 6289194 0.00 0.00 ggc_set_mark 0.26 1328.46 3.73 21 0.00 0.00 pp_base_newline 0.25 1332.04 3.59 892391 0.00 0.00 lookup_template_class 0.24 1335.43 3.39 14090587 0.00 0.00 pp_c_constant 0.20 1338.34 2.9167465 0.00 0.00 push_to_top_level 0.20 1341.19 2.85 2159736 0.00 0.00 dfs_walk_all 0.17 1343.61 2.43 935808 0.00 0.00 coerce_template_parms 0.17 1346.03 2.42 1554163 0.00 0.00 lookup_field_1 0.16 1348.27 2.24 1034 0.00 0.00 cp_tree_equal 0.15 1350.49 2.22 222604 0.00 0.00 ht_lookup_with_hash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug preprocessor/28709] [4.0/4.1/4.2 regression] Bad diagnostic pasting tokens with ##
--- Comment #2 from jakub at gcc dot gnu dot org 2006-10-12 09:26 --- Subject: Bug 28709 Author: jakub Date: Thu Oct 12 09:25:59 2006 New Revision: 117664 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117664 Log: PR preprocessor/28709 * macro.c (paste_tokens): Do error reporting here, use BUF with the spelled LHS token as opposed to spelling it again. (paste_all_tokens): Don't report errors here, just break on failure. * gcc.dg/cpp/paste14.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/paste14.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #7 from grayyoga at gmail dot com 2006-10-12 09:51 --- Created an attachment (id=12415) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12415&action=view) preprocessed source file (version 2) The previous test case had common C++ error in it, which prevents it from being compiled properly. Try this one. It generates the same "internal error" message, but I think that it's free from the C++ errors. If not, I'll make some steps back and provide an example which also requires a lot of memory to compile, but compiles properly, without "internal error". -- grayyoga at gmail dot com changed: What|Removed |Added Attachment #12409|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug driver/29430] Assembler messages: Error: invalid architecture -xarch=v8
--- Comment #2 from geraldine-n dot bert at edfgdf dot fr 2006-10-12 09:57 --- (In reply to comment #1) > This > > > ../configure --with-mpfr=/logiciels/public/gmp-4.1.4/lib --enable-shared > > --with-gnu-as=/logiciels/public/binutils-2.9/bin/as > > --with-gnu-ld=/logiciels/public/binutils-2.9/bin/ld > > and that > > > I thought it was a pb of as and ld so I compiled binutils2.16 > > but I've got the same pb (before I've used sun as -and gnu ld) > > seems to be contradictory. > > Your syntax is incorrect: --with-gnu-as and --with-gnu-ld take no argument. > Configure like your 3.2.1 compiler was configured and that will work. > It works thank you very much! Géraldine -- geraldine-n dot bert at edfgdf dot fr changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29430
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-12 11:15 --- Created an attachment (id=12416) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12416&action=view) Patch for LBOUND/UBOUND This patch fixes this bug completely. It builds fine, regtest and works fine with a few other extra examples that I'll add as testcases. The idea behind it is explained here: http://gcc.gnu.org/ml/fortran/2006-10/msg00379.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)
--- Comment #3 from razya at il dot ibm dot com 2006-10-12 11:44 ---
(In reply to comment #0)
> gcc -O3 test.c --ipa-cp -m64
> test.c:
>
> #include
> int
> bar (int b, int c)
> {
> printf ("%d %d\n", b, c);
> }
> int
> foo (int a)
> {
> if (a++ > 0)
> bar (a, 3);
> foo (7);
> }
> int
> main ()
> {
> foo (7);
> return 0;
> }
>
> test.c: In function âfooâ:
> test.c:16: error: unrecognizable insn:
> (call_insn/j 31 30 32 5 (parallel [
> (set (reg:DI 3 3)
> (call (mem:SI (symbol_ref:DI ("T.10")) [0 S4 A8])
> (const_int 64 [0x40])))
> (use (const_int 0 [0x0]))
> (use (reg:SI 126))
> (return)
> ]) -1 (nil)
> (expr_list:REG_EH_REGION (const_int 0 [0x0])
> (nil))
> (expr_list:REG_DEP_TRUE (use (reg:DI 3 3))
> (nil)))
I would like to be assigned to this PR.
Razya
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29122
[Bug c++/29437] [decl.init.ref]/5 wrongly implemented
--- Comment #4 from joseph dot rajesh at gmail dot com 2006-10-12 12:10 --- (In reply to comment #3) > Forget this, the type of the rhs is of course an rvalue of type Base, > there is no need to copy the entire Derived object. > > W. > Hi, I was pointing to the same error. But I think I haven't put across it properly... But I think in the latest version of C++ standard they are changing this. They modified the line in the draft(not yet released though). Please have a look at the latest C++ draft http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf Following is the extract from section 5.16.3 of the draft. The process for determining whether an operand expression E1 of type T1 can be converted to match an operand expression E2 of type T2 is defined as follows: If E2 is an lvalue: E1 can be converted to match E2 if E1 can be implicitly converted (clause 4) to the type reference to T2, subject to the constraint that in the conversion the reference must bind directly (8.5.3) to E1. If E2 is an rvalue, or if the conversion above cannot be done: - if E1 and E2 have class type, and the underlying class types are the same or one is a base class of the other: E1 can be converted to match E2 if the class of T2 is the same type as, or a base class of, the class of T1, and the cv-qualification of T2 is the same cv-qualification as, or a greater cv-qualification than, the cv-qualification of T1. If the conversion is applied, E1 is changed to an rvalue of type T2 that [DELETE]still refers to the original source class object (or the appropriate subobject thereof). [ Note: that is, no copy is made. end note][/DELETE] by copy-initializing a temporary of type T2 from E1 and using that temporary as the converted operand. The [DELETE][/DELETE] section is deleted from the draft. So if this section is there in the yet to be released standard then it says that the copy will be made. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29437
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-12 12:18 --- (In reply to comment #5) > I try as soon as possible. > Thanks for your help. > This subroutine is one of an open-source project which contains about > 1.000.000 > lines of fortran : http://www.code-aster.org. Mathieu, Can I close this one, please? Paul Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug c++/29438] New: Friendship problem
Hi. Today, while working on libstdc++/28277 I encountered this problem, which
currently prevents me from extending the fix to ext/vstring. The below is a
rather small self-contained testcase, which current mainline does not compile
because of ambiguous overloading, whereas compilers based on the EDG front-end
accept it, in strict mode too. Is it a known issue? Thanks.
namespace __gnu_cxx
{
template
class __sso_string_base { };
template class _Base
= __sso_string_base>
class __versa_string { };
}
namespace std
{
template
class basic_ostream;
template class _Base>
basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __os,
const __gnu_cxx::__versa_string<_CharT, _Traits,
_Alloc, _Base>&)
{ return __os; }
}
namespace std
{
template
class basic_ostream
{
template class _Base>
friend basic_ostream<_CharT2, _Traits2>&
operator<<(basic_ostream<_CharT2, _Traits2>&,
const __gnu_cxx::__versa_string<_CharT2, _Traits2,
_Alloc, _Base>&);
};
}
int main()
{
std::basic_ostream bo;
__gnu_cxx::__versa_string vs;
bo << vs;
}
--
Summary: Friendship problem
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #9 from pault at gcc dot gnu dot org 2006-10-12 12:31 --- (In reply to comment #8) > Paul, Jakub, > Is the patch in comment #7 considered to be the right approach? > I tried applying to my local tree, but a few chunks were rejected. Jakub? What about it? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug c++/29318] [4.0/4.1/4.2 Regression] ICE: type_info of pointer to VLA
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-12 12:39 ---
EDG chooses to reject the code with
t.C(7): error: a variable-length array type is not allowed
const std::type_info& info(typeid(&va));
^
though I cannot find anything in the standard that justifies this behavior. Of
course C++ VLA are a gcc extension... (but we still ICE even with -pedantic)
We're ICEing in mangling the VLA type
intD.2[0:(long unsigned intD.7) (SAVE_EXPR <() iD.2580 - 1>)]
if we "fix" that by patching write_array_type to strip NOPs and SAVE_EXPRs
in the VLA case like so:
/* Strip NOP and SAVE_EXPR */
while (TREE_CODE (max) == NOP_EXPR
|| TREE_CODE (max) == SAVE_EXPR)
max = TREE_OPERAND (max, 0);
max = TREE_OPERAND (max, 0);
if (!abi_version_at_least (2))
{
that case goes fine, but then we ICE mangling
intD.2[0:D.2586]
which doesn't tell us the number of elements in a symbolical way? (and
so we ICE on the TREE_OPERAND (max, 0))
The gimplifier produces that out of the first variant and we get to the
mangler again through
#2 0x005d22b1 in write_array_type (type=0x2b0b2b686b00)
at /space/rguenther/src/svn/trunk/gcc/cp/mangle.c:2396
#3 0x005cd546 in write_type (type=0x2b0b2b686b00)
at /space/rguenther/src/svn/trunk/gcc/cp/mangle.c:1557
#4 0x005cd9f0 in write_type (type=0x2b0b2b686d10)
at /space/rguenther/src/svn/trunk/gcc/cp/mangle.c:1620
#5 0x005d323f in mangle_type_string (type=0x2b0b2b686d10)
at /space/rguenther/src/svn/trunk/gcc/cp/mangle.c:2617
#6 0x0053a437 in tinfo_name (type=0x2b0b2b686d10)
at /space/rguenther/src/svn/trunk/gcc/cp/rtti.c:330
#7 0x0053c720 in tinfo_base_init (ti=0x2b0b2b4d6598,
target=0x2b0b2b686d10) at /space/rguenther/src/svn/trunk/gcc/cp/rtti.c:813
#8 0x0053cebd in ptr_initializer (ti=0x2b0b2b4d6598,
target=0x2b0b2b686d10) at /space/rguenther/src/svn/trunk/gcc/cp/rtti.c:908
#9 0x0053d59d in get_pseudo_ti_init (type=0x2b0b2b686d10, tk_index=6)
at /space/rguenther/src/svn/trunk/gcc/cp/rtti.c:1018
#10 0x0053fce3 in emit_tinfo_decl (decl=0x2b0b2b686dc0)
at /space/rguenther/src/svn/trunk/gcc/cp/rtti.c:1491
#11 0x0050498c in cp_finish_file ()
at /space/rguenther/src/svn/trunk/gcc/cp/decl2.c:3127
#12 0x00402945 in finish_file ()
at /space/rguenther/src/svn/trunk/gcc/cp/cp-lang.c:144
#13 0x006451ee in c_common_parse_file (set_yydebug=0)
at /space/rguenther/src/svn/trunk/gcc/c-opts.c:1176
#14 0x00b860fc in compile_file ()
at /space/rguenther/src/svn/trunk/gcc/toplev.c:1033
#15 0x00b87c72 in do_compile ()
at /space/rguenther/src/svn/trunk/gcc/toplev.c:2006
#16 0x00b87cd6 in toplev_main (argc=3, argv=0x7fff7f92b998)
at /space/rguenther/src/svn/trunk/gcc/toplev.c:2038
#17 0x0065bc1b in main (argc=3, argv=0x7fff7f92b998)
at /space/rguenther/src/svn/trunk/gcc/main.c:35
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
[Bug fortran/23060] %VAL construct not implemented
-- pault at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords|rejects-valid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #10 from jakub at gcc dot gnu dot org 2006-10-12 12:46 --- No, that sounds wrong. Not all dummy arguments have such type, so such a change just leads to strict aliasing violations and there are also dummy arguments that are larger than long. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug other/2873] [3.3 only][fixinclude] Bogus fixinclude of stdio.h from glibc 2.2.3
--- Comment #8 from cvs-commit at developer dot classpath dot org 2006-10-12 12:52 --- Subject: Bug 2873 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Roman Kennke 06/10/12 12:50:44 Modified files: javax/swing/plaf/basic: BasicTabbedPaneUI.java . : ChangeLog Log message: 2006-10-12 Roman Kennke <[EMAIL PROTECTED]> PR 2873 * javax/swing/plaf/basic/BasicTabbedPaneUI.java (TabPaneLayout.normalizeTabRuns): Replaced algorithm with one that avoids faulty state that could cause division by zero error. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java?cvsroot=classpath&r1=1.56&r2=1.57 http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.8669&r2=1.8670 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2873
[Bug other/29439] New: ICE in fold-const.c:1385 ( expected integer_cst, have var_decl in int_const_binop )
after closing the PR28230 the bootstrap ICEs on ada. (...) /home/users/pluto/rpm/BUILD/trunk/builddir/./gcc/xgcc -B/home/users/pluto/rpm/BUILD/trunk/builddir/./gcc/ -B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/ -isystem /usr/x86_64-pld-linux/include -isystem /usr/x86_64-pld-linux/sys-include -c -O2 -fwrapv -march=x86-64 -gdwarf-2 -g2 -fPIC -W -Wall -gnatpg a-stwifi.adb -o a-stwifi.o +===GNAT BUG DETECTED==+ | 4.2.0 20061012 (experimental) (PLD-Linux) (x86_64-pld-linux-gnu) GCC error:| | tree check: expected integer_cst, have var_decl in int_const_binop, | |at fold-const.c:1385 | | Error detected at a-stwifi.adb:677:1 -- Summary: ICE in fold-const.c:1385 ( expected integer_cst, have var_decl in int_const_binop ) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-12 13:09 --- No success yet: test_basic_metafunctions.hpp:176: instantiated from here ../src/sd/../static_component.hpp:57: error: 'process_outputs' is not a member of 'mpl_::void_' and other errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-10-12 13:15 --- Created an attachment (id=12417) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12417&action=view) New patch This updated patch is the result of re-reading the Standard about assumed-size arrays. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Attachment #12416|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
[Bug fortran/23060] %VAL construct not implemented
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-12 13:19 --- [Paul changed this bug into enhancement] I'm changing this back (again) into a bug, not an enhancement, because it was supported by g77, and we're trying to make a drop-in replacement for g77 in most cases. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug target/29413] -EB / -EL don't properly affect endian for Linux on MIPS
--- Comment #6 from ralf at linux-mips dot org 2006-10-12 13:33 ---
> %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
Shouldn't the combination of both -EB and -EL be legal that is later options
override preceeding ones just like with other -ffoo / -fno-foo options?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug target/29413] -EB / -EL don't properly affect endian for Linux on MIPS
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-12 14:11 ---
(In reply to comment #6)
> > %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
>
> Shouldn't the combination of both -EB and -EL be legal that is later options
> override preceeding ones just like with other -ffoo / -fno-foo options?
That is not the problem, the problem is that CC1_SPEC does not contain the
above but instead the one that is in config/linux.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2006-10-12 14:13 --- Subject: Re: Internal Error: gfc_resolve_expr(): Bad expression type On Thu, Oct 12, 2006 at 12:18:30PM -, pault at gcc dot gnu dot org wrote: > > > --- Comment #6 from pault at gcc dot gnu dot org 2006-10-12 12:18 --- > (In reply to comment #5) > > I try as soon as possible. > > Thanks for your help. > > This subroutine is one of an open-source project which contains about > > 1.000.000 > > lines of fortran : http://www.code-aster.org. > > Mathieu, > > Can I close this one, please? > I think the anwser to this is "yes". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug c++/29438] [4.0/4.1/4.2 Regression] Friendship problem
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 14:18 --- This looks very closely related to PR 29236. Confirmed, a regression from 2.95.3. I still want to say this is just another example of PR 29236 but the testcases are semi different. Though the use of templates with template arugments which are templates themselve make them very closely related. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29236 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||3.0.4 4.0.0 4.1.0 4.2.0 ||3.3.3 3.2.3 3.4.0 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2006-10-12 14:18:54 date|| Summary|Friendship problem |[4.0/4.1/4.2 Regression] ||Friendship problem Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
[Bug c++/29438] [4.0/4.1/4.2 Regression] Friendship problem
--- Comment #2 from pcarlini at suse dot de 2006-10-12 14:21 --- Indeed, I was about to add to the audit trail that the template template parameter is essential. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
[Bug c/29440] New: 4.2 20061007 experiemental misscompiles libavcodec/h264.o
4.2 misscompiles libavcodec/h264.o from FFmpeg project. The likely cause of this problem is lies in the file cabac.h (in attachment) gcc-4.0 and 4.1.0 compile this file correctly. Here's the commandline: /home/guillaume/Prgm/gcc/bin/gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdeclaration-after-statement -fno-PIC -O4 -march=pentium-m -mtune=pentium-m -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include -I/usr/include/SDL -D_REENTRANT -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -I/usr/include/dvdnav -I/usr/include/freetype2 -c -o h264.o h264.c -v -save-temps gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20061007/configure --prefix=/home/guillaume/Prgm/gcc/ Thread model: posix gcc version 4.2.0 20061007 (experimental) /home/guillaume/Prgm/gcc/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -E -quiet -v -I.. -I.. -I../libavutil -I/usr/include -I/usr/include/SDL -I/usr/include/kde/artsc -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -I/usr/include/dvdnav -I/usr/include/freetype2 -iprefix /home/guillaume/Prgm/gcc/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/ -D_REENTRANT -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_REENTRANT h264.c -march=pentium-m -mtune=pentium-m -Wdeclaration-after-statement -fno-PIC -ffast-math -fomit-frame-pointer -O4 -fpch-preprocess -o h264.i ignoring nonexistent directory "/home/guillaume/Prgm/gcc/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory "/home/guillaume/Prgm/gcc//lib/gcc/i686-pc-linux-gnu/4.2.0/include" ignoring nonexistent directory "/home/guillaume/Prgm/gcc//lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory ".." ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: .. ../libavutil /usr/include/SDL /usr/include/kde/artsc /usr/include/glib-2.0 /usr/lib/glib-2.0/include /usr/include/dvdnav /usr/include/freetype2 /home/guillaume/Prgm/gcc/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/include /usr/local/include /home/guillaume/Prgm/gcc//include /usr/include End of search list. /home/guillaume/Prgm/gcc/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -fpreprocessed h264.i -quiet -dumpbase h264.c -march=pentium-m -mtune=pentium-m -auxbase-strip h264.o -O4 -Wdeclaration-after-statement -version -fno-PIC -ffast-math -fomit-frame-pointer -o h264.s GNU C version 4.2.0 20061007 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0 20061007 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 9d78c482f3158f545a4217a7c698d3a2 h264.c: In function 'decode_cabac_residual': h264.c:6120: warning: initialization from incompatible pointer type as -V -Qy -o h264.o h264.s GNU assembler version 2.16.91 (i486-linux-gnu) using BFD version 2.16.91 20060118 Debian GNU/Linux -- Summary: 4.2 20061007 experiemental misscompiles libavcodec/h264.o Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: poirierg at gmail dot com GCC build triplet: (no options) GCC host triplet: i686, Linux, debian GCC target triplet: i686, Linux, debian http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug c++/29438] [4.0/4.1/4.2 Regression] Friendship problem
--- Comment #3 from pcarlini at suse dot de 2006-10-12 14:24 --- ... and I also agree that the issue seems *very* similar to 29236. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
[Bug c/29440] 4.2 20061007 experiemental misscompiles libavcodec/h264.o
--- Comment #1 from poirierg at gmail dot com 2006-10-12 14:25 --- Created an attachment (id=12418) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12418&action=view) the offending file (results in a grey picture) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug c/29440] 4.2 20061007 experiemental misscompiles libavcodec/h264.o
--- Comment #2 from poirierg at gmail dot com 2006-10-12 14:28 --- Created an attachment (id=12419) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12419&action=view) The header that seems to hold the code that's misscompiled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug other/29439] ICE in fold-const.c:1385 ( expected integer_cst, have var_decl in int_const_binop )
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-12 14:30 --- I had ada included in the set of languages for the bootstrap & regtest for PR28230. So you need to find another one ;) Or are you complaining about the next failure with a -fwrapv bootstrap? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug middle-end/29440] 4.2 20061007 experimental misscompiles libavcodec/h264.o
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug middle-end/29440] 4.2 20061007 experimental misscompiles libavcodec/h264.o
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 14:34 --- Does it work when compiled with -O0 instead of -O4? How about -O1? Besies above, I noticed that the asm in get_cabac looks to be clobbering memory but is not marked as such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug other/29439] ICE in fold-const.c:1385 ( expected integer_cst, have var_decl in int_const_binop )
--- Comment #2 from pluto at agmk dot net 2006-10-12 14:38 --- (In reply to comment #1) > I had ada included in the set of languages for the bootstrap & regtest for > PR28230. So you need to find another one ;) try to bootstrap C+ADA with CFLAGS='-O2 -fwrapv' ;) > Or are you complaining about the next failure with a -fwrapv bootstrap? exactly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug middle-end/29440] 4.2 20061007 experimental misscompiles libavcodec/h264.o
--- Comment #4 from pluto at agmk dot net 2006-10-12 14:40 --- (In reply to comment #3) > Does it work when compiled with -O0 instead of -O4? How about -O1? > > Besies above, I noticed that the asm in get_cabac looks to be clobbering > memory > but is not marked as such. > Andrew, this testcase violates aliasing rules. h264.c: In function 'filter_mb_fast': h264.c:7074: warning: dereferencing type-punned pointer will break strict-aliasing rules -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug middle-end/29440] 4.2 20061007 experimental misscompiles libavcodec/h264.o
--- Comment #5 from poirierg at gmail dot com 2006-10-12 14:53 --- Hello, (In reply to comment #3) > Does it work when compiled with -O0 instead of -O4? How about -O1? The code compiles and produces the expected result with -O1, O2, but can't be compiled with -O0: In file included from h264.c:36: cabac.h: In function 'get_cabac': cabac.h:454: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' cabac.h:454: error: 'asm' operand has impossible constraints h264.c: In function 'decode_cabac_residual': h264.c:6120: warning: initialization from incompatible pointer type > Besies above, I noticed that the asm in get_cabac looks to be clobbering > memory > but is not marked as such. I can't really comment on that as I'm not too inline-asm fluent... however, I can say that this code can't be compiled without -fomit-frame-pointer. Is GCC supposed to produce valid code with this source to begin with? Guillaume -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug fortran/29441] New: mathematical functions and constant expressions
Hi conside the following code $cat const_math_func.f90 program printpi ! This program is not standard complaint real, parameter :: pi = 4.0*atan(1.0) write(*,*) pi end program This code is not Fortran 95 standard compliant ( http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/11eeb6ec2896183c/95d5ab27eb5e94e9#95d5ab27eb5e94e9 ). But still gfortran does not give any errors/warning when compiling this code. $gfortran -Wall -std=f95 const_math_func.f90 $./a.out 3.141593 $gfortran -v Using built-in specs. Target: i486-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 --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) -- Summary: mathematical functions and constant expressions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kamaraju at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug middle-end/29440] 4.2 20061007 experimental misscompiles libavcodec/h264.o
--- Comment #6 from poirierg at gmail dot com 2006-10-12 15:03 --- (In reply to comment #4) > (In reply to comment #3) > > Does it work when compiled with -O0 instead of -O4? How about -O1? > > > > Besies above, I noticed that the asm in get_cabac looks to be clobbering > > memory > > but is not marked as such. > > > > Andrew, this testcase violates aliasing rules. > > h264.c: In function 'filter_mb_fast': > h264.c:7074: warning: dereferencing type-punned pointer will break > strict-aliasing rules For what it's worth, the code around line 7074 compiled correctly with snapshot 4.2-20060909 and has been in FFmpeg since Mon Aug 28 09:33:01 2006 UTC, so IMHO it shouldn't be the cause of the problem I'm reporting today. However, if you have a suggestion to improve this code, I'm all ears Guillaume -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29440
[Bug fortran/29441] non-constant parameter (constant) accepted
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 15:10 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-10-12 15:10:40 date|| Summary|mathematical functions and |non-constant parameter |constant expressions|(constant) accepted Version|unknown |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug fortran/29441] non-constant parameter (constant) accepted
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-12 15:12 --- Actually adding -pedantic, and this is rejected: In file t.f90:3 real, parameter :: pi = 4.0*atan(1.0) 1 Error: Extension: Evaluation of nonstandard initialization expression at (1) And has since 4.0.3: [EMAIL PROTECTED] ~]$ ~/gcc-4.0/bin/gfortran t.f90 -std=f95 -pedantic-errors In file t.f90:3 real, parameter :: pi = 4.0*atan(1.0) 1 Error: Extension: Evaluation of nonstandard initialization expression at (1) [EMAIL PROTECTED] ~]$ ~/gcc-4.1/bin/gfortran t.f90 -std=f95 -pedantic-errors In file t.f90:3 real, parameter :: pi = 4.0*atan(1.0) 1 Error: Extension: Evaluation of nonstandard initialization expression at (1) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug fortran/29391] LBOUND(TRANSPOSE(I)) doesn't work
--- Comment #11 from paulthomas2 at wanadoo dot fr 2006-10-12 15:57 ---
Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work
FX
! if (upper)
! {
! cond1 = fold_build2 (GE_EXPR, boolean_type_node, ubound, lbound);
! cond2 = fold_build2 (LE_EXPR, boolean_type_node, ubound, lbound);
! cond3 = fold_build2 (GT_EXPR, boolean_type_node, stride,
!gfc_index_zero_node);
!
! cond = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3,
cond1);
! cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond, cond2);
!
! se->expr = fold_build3 (COND_EXPR, gfc_array_index_type, cond,
! ubound, gfc_index_zero_node);
! }
! else
! {
! tree cond1, cond2, cond3;
Repeated declaration
!
! if (as->type == AS_ASSUMED_SIZE)
! cond = fold_build2 (EQ_EXPR, boolean_type_node, bound,
! build_int_cst (TREE_TYPE (bound),
!arg->expr->rank));
! else
! cond = boolean_false_node;
!
! cond1 = fold_build2 (GE_EXPR, boolean_type_node, ubound, lbound);
! cond2 = fold_build2 (LE_EXPR, boolean_type_node, ubound, lbound);
! cond3 = fold_build2 (GT_EXPR, boolean_type_node, stride,
!gfc_index_zero_node);
Same assignment for upper and lower - put it before the if
! cond1 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, cond3,
cond1);
! cond1 = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond1,
cond2);
!
! cond = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, cond, cond1);
!
! se->expr = fold_build3 (COND_EXPR, gfc_array_index_type, cond,
! lbound, gfc_index_one_node);
! }
I have tested the above corrections, verified the logic and regtested
the patch right now. My version of the diff is attached. I added a
comment that consists of the appropriate extracts from the standard.
gfortran and ifort now agree on the testcase in #1, whilst g95 differs
on the last line.
With an appropriate testcase and ChangeLog entries, this is OK for trunk.
Paul
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (revision 117628)
--- gcc/fortran/trans-intrinsic.c (working copy)
*** gfc_conv_intrinsic_bound (gfc_se * se, g
*** 710,718
tree type;
tree bound;
tree tmp;
! tree cond;
gfc_se argse;
gfc_ss *ss;
int i;
arg = expr->value.function.actual;
--- 710,722
tree type;
tree bound;
tree tmp;
! tree cond, cond1, cond2, cond3, size;
! tree ubound;
! tree lbound;
gfc_se argse;
gfc_ss *ss;
+ gfc_array_spec * as;
+ gfc_ref *ref;
int i;
arg = expr->value.function.actual;
*** gfc_conv_intrinsic_bound (gfc_se * se, g
*** 773,782
}
}
! if (upper)
! se->expr = gfc_conv_descriptor_ubound(desc, bound);
else
! se->expr = gfc_conv_descriptor_lbound(desc, bound);
type = gfc_typenode_for_spec (&expr->ts);
se->expr = convert (type, se->expr);
--- 777,883
}
}
! ubound = gfc_conv_descriptor_ubound (desc, bound);
! lbound = gfc_conv_descriptor_lbound (desc, bound);
!
! /* Follow any component references. */
! if (arg->expr->expr_type == EXPR_VARIABLE
! || arg->expr->expr_type == EXPR_CONSTANT)
! {
! as = arg->expr->symtree->n.sym->as;
! for (ref = arg->expr->ref; ref; ref = ref->next)
! {
! switch (ref->type)
! {
! case REF_COMPONENT:
! as = ref->u.c.component->as;
! continue;
!
! case REF_SUBSTRING:
! continue;
!
! case REF_ARRAY:
! {
! switch (ref->u.ar.type)
! {
! case AR_ELEMENT:
! case AR_SECTION:
! case AR_UNKNOWN:
! as = NULL;
! continue;
!
! case AR_FULL:
! break;
! }
! }
! }
! }
! }
! else
! as = NULL;
!
! /* 13.14.53: Result value for LBOUND
! Case (i): For an array section or for an array expression other than a
whole
! array or array structure component, LBOUND(ARRAY, DIM) has the value 1.
For a
! whole array or array structure component, LBOUND(ARRAY, DIM) has the
value:
! (a) equal to the lower bound for subscript DIM of ARRAY if dimension DIM
of
! does not have extent zero or if ARRAY is an assumed-size array of rank
! DIM, or
! (b) 1 otherwise..
!
! 13.14.113: Result value for UBOUND
! Case (i): For an array section or for an array expression other than a
whole
! array or array structure component, UBOUND(ARRAY, DIM) has the value
equal
! to the number of elements in the given dimension; otherwise, it has a
value
! equal to the
[Bug other/29442] New: insn-attrtab has grown too large
When compiling gcc-4.1.1, there is at least a serious slowdown, and on many machines a failure, when insn-attrtab is compiled. There are several threads on the Gentoo forums about this, some involving machines with 512M of memory. This file seems to be automatically generated, and has become so large that one user graphically describes it as a "swapfest". Compiling on a machine with the specified Gentoo minimum of 64M is not practical. Is it possible to split this file? -- Summary: insn-attrtab has grown too large Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rick at hartmantech dot com GCC build triplet: i686-pc-linux-gnu-4.1.1 GCC host triplet: i686-pc-linux-gnu-4.1.1 GCC target triplet: i686-pc-linux-gnu-4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
[Bug bootstrap/29402] Parallel make fails with --disable-bootstrap
--- Comment #2 from ghazi at gcc dot gnu dot org 2006-10-12 16:28 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00662.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||10/msg00662.html Known to fail||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29402
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #9 from grayyoga at gmail dot com 2006-10-12 16:50 --- Created an attachment (id=12420) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12420&action=view) preprocessed source file (version 3) Compiles without errors on my laptop, but still eats a LOT of memory. -- grayyoga at gmail dot com changed: What|Removed |Added Attachment #12415|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug testsuite/29093] gcc.dg/debug/dwarf2/dwarf-file1.c fails on targets that have .loc
--- Comment #4 from sje at gcc dot gnu dot org 2006-10-12 16:52 --- Subject: Bug 29093 Author: sje Date: Thu Oct 12 16:52:33 2006 New Revision: 117667 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117667 Log: PR testsuite/29093 * gcc.dg/debug/dwarf2/dwarf-file1.c: Check for ".file". Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-file1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29093
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #4 from dje at gcc dot gnu dot org 2006-10-12 16:58 --- You should be using --with-gmp=/usr/local Are you sure that /usr/local/lib/libgmp.a exists and was built correct? Use static libraries and make sure that you are building 32-bit libgmp and libmpfr. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
gcc-bugs@gcc.gnu.org
--- Comment #6 from oschmidt at gmx dot net 2006-10-12 17:03 --- > You therefore initialize a variable with itself. This is > a documented way to generate uninitialized variables and > Here's the right combination of flags that warns (for f3() only): Thank you for your answer, this is very interesting (but where is it documented?). But still *very* dangerous, because the destructor of this unitialized object is called and such the destructor is working with some random memory. So a compiler warning for this makes really sense not only for f3() but also for f4(). BTW: I found that the IBM-C++ Compiler for MVS has similar behaviour, so it really might be a feature and not a bug, althoug a very strange feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
gcc-bugs@gcc.gnu.org
--- Comment #7 from oschmidt at gmx dot net 2006-10-12 17:10 --- >So a compiler warning for this makes really sense >not only for f3() but also for f4(). So I think it would be a good idea to reopen this bug report. It is then not a bug report about inproper compiler behaviour but a bug report about missing compiler warnings ;-) What do You think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
[Bug target/29250] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #4 from dje at gcc dot gnu dot org 2006-10-12 17:20 --- How is expand even generating this? This is completely invalid RTL for PPC. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #23 from janis at gcc dot gnu dot org 2006-10-12 17:23 --- Subject: Bug 28690 Author: janis Date: Thu Oct 12 17:23:10 2006 New Revision: 117668 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117668 Log: PR middle-end/28690 * explow.c (force_reg): Set REG_POINTER flag according to MEM_POINTER flag. Modified: branches/ibm/gcc-4_1-branch/gcc/ChangeLog branches/ibm/gcc-4_1-branch/gcc/explow.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug testsuite/29093] gcc.dg/debug/dwarf2/dwarf-file1.c fails on targets that have .loc
--- Comment #5 from sje at cup dot hp dot com 2006-10-12 17:36 --- Fixed with a testsuite change to check for "File Entry:" or ".file". Platforms that set DWARF2_ASM_LINE_DEBUG_INFO will output a ".file" line but not a "File Entry:" line and the test now checks for either. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29093
[Bug c++/24056] failed lookup of static non-member operator function with certain templated arguments
--- Comment #5 from pogonyshev at gmx dot net 2006-10-12 18:58 --- OK, thanks for the help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24056
[Bug target/29250] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #5 from dje at gcc dot gnu dot org 2006-10-12 19:15 --- The expander is producing invalid RTL. If the index variable "offs" is changed from "long long" to "long", the code compiles correctly and the memory loads are placed in temporary pseudos. Only with "long long" does GCC punt and expand to a sum of memory references. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug other/29439] ICE in fold-const.c:1385 ( expected integer_cst, have var_decl in int_const_binop )
--- Comment #3 from pluto at agmk dot net 2006-10-12 19:45 --- cwd: ada/rts: $ ../../gnat1 -quiet -dumpbase a-stwifi.adb -O1 -fwrapv -ftree-vrp \ -gnatpg a-stwifi.adb -o a-stwifi.s (gdb) bt #0 int_const_binop (code=PLUS_EXPR, arg1=0x2b8302f027b0, arg2=0x2b8302f02810, notrunc=0) at ../../gcc/fold-const.c:1385 #1 0x0077c1e0 in round_up (value=0x2b8302f027b0, divisor=8) at ../../gcc/fold-const.c:12841 #2 0x0090a7ea in finalize_type_size (type=0x2b8302f0f160) at ../../gcc/stor-layout.c:1431 #3 0x0090e2a4 in layout_type (type=0x2b8302f0f160) at ../../gcc/stor-layout.c:1861 #4 0x0090ee38 in make_signed_type (precision=) at ../../gcc/stor-layout.c:1881 #5 0x0092433e in build_common_tree_nodes (signed_char=1 '\001', signed_sizetype=) at ../../gcc/tree.c:6460 #6 0x00423e00 in gnat_init_decl_processing () at ../../gcc/ada/utils.c:405 #7 0x0041bc9e in gnat_init () at ../../gcc/ada/misc.c:421 #8 0x00912d1a in toplev_main (argc=, argv=) at ../../gcc/toplev.c:1900 #9 0x2b8302cf0134 in __libc_start_main () from /lib64/libc.so.6 #10 0x004030e9 in _start () (gdb) c debug_tree(arg1) constant invariant 8> Value can't be converted to integer. (gdb) c debug_tree(arg2) constant invariant 7> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
gcc-bugs@gcc.gnu.org
--- Comment #8 from bangerth at dealii dot org 2006-10-12 19:55 --- (In reply to comment #6) > Thank you for your answer, this is very interesting (but where is it > documented?). In the gcc manual. > But still *very* dangerous, because the destructor of this unitialized object > is called and such the destructor is working with some random memory. Yes. You get what you deserve. The compiler warns you about that, if you ignore this, then you shouldn't expect anything good to come out of it. > So a compiler warning for this makes really sense not only for f3() but also > for f4(). It does: g/x> /home/bangerth/bin/x86_64/gcc-4.0.2/bin/c++ -Winit-self -Wuninitialized -O2 -c x.cc x.cc: In function 'void f4()': x.cc:79: warning: 'd4$c$v' is used uninitialized in this function x.cc: In function 'void f3()': x.cc:69: warning: 'd3$c$v' is used uninitialized in this function W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #10 from grayyoga at gmail dot com 2006-10-12 19:56 --- Subject: Re: using boost::MPL requires lots of memory Try preprocessed source file v3. It compiles without error on my laptop, but still takes a LOT of memory and time to compile. On 12 Oct 2006 13:09:02 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-12 13:09 > --- > No success yet: > > test_basic_metafunctions.hpp:176: instantiated from here > ../src/sd/../static_component.hpp:57: error: 'process_outputs' is not a member > of 'mpl_::void_' > > and other errors. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug debug/29443] New: [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs
I get the following ICE with -gstabs with gcc 4.1.2 20060901 (Debian 4.1.1-13) but not with 4.0 and 4.2. (sid)1186:[EMAIL PROTECTED]: ~] g++-4.1 -O -fPIC -gstabs libapt-front-state.cpp libapt-front-state.cpp: In member function std::string aptFront::cache::component::State::sizeString(double): libapt-front-state.cpp:336: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . Preprocessed source stored into /tmp/ccgRM3uh.out file, please attach this to your bugreport. (sid)1187:[EMAIL PROTECTED]: ~] -- Summary: [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug debug/29443] [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #1 from tbm at cyrius dot com 2006-10-12 19:58 --- Created an attachment (id=12421) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12421&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug c++/27961] [4.1/4.2 regression] ICE on invalid template declaration
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-12 20:03 --- Subject: Bug 27961 Author: lmillward Date: Thu Oct 12 20:02:53 2006 New Revision: 117671 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117671 Log: PR c++/27961 * decl.c (start_decl): Return error_mark_node if a function is initialized like a variable. (check_var_type): If a variable of field is declared void, set the type to error_mark_node. (grokdeclarator): Check the return type of check_var_type. * class.c (finish_struct_1): Robustify. * g++.dg/template/crash60.C: New test. * g++.dg/other/large-size-array.C: Adjust error markers. * g++.dg/parse/crash27.C: Likewise. * g++.dg/template/crash1.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/large-size-array.C trunk/gcc/testsuite/g++.dg/parse/crash27.C trunk/gcc/testsuite/g++.dg/template/crash1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug c++/27961] [4.1/4.2 regression] ICE on invalid template declaration
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-10-12 20:06 --- Subject: Bug 27961 Author: lmillward Date: Thu Oct 12 20:06:36 2006 New Revision: 117672 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117672 Log: PR c++/27961 * g++.dg/template/crash60.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash60.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug c++/27961] [4.1 regression] ICE on invalid template declaration
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-10-12 20:06 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE on |[4.1 regression] ICE on |invalid template declaration|invalid template declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug target/24649] Hello world c++ prog core dumps
--- Comment #15 from steve at telxio dot com 2006-10-12 20:27 --- Subject: RE: Hello world c++ prog core dumps I have found the cause of the problem. It isn't a problem with gcc. I use the binutils shipped with Solaris10 to strip the binaries and create separate debug symbol files. If I do not strip g++/libstdc++, the test program runs with no problems. -Original Message- From: ebotcazou at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 11:35 PM To: [EMAIL PROTECTED] Subject: [Bug target/24649] Hello world c++ prog core dumps --- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-09-12 06:35 --- I've never been able to reproduce this. Do you still have the problem with the 4.x series of compiler? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24649 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24649
[Bug c/29444] New: parser bug for variable declaration immediately following case statement in switch block
The following code:
int main( int argc, char** argv )
{
switch ( 1 )
{
case 1:
int bug = 0;
break;
}
return 0;
}
is valid C syntax and should compile, but gcc gives the error:
bug.c: In function 'main':
bug.c:6: error: expected expression before 'int'
gcc doesn't properly interpret the variable declaration immediately following
the "case 1:" However, if another statement is inserted (even a blank
statement, just a semicolon) such as:
int main( int argc, char** argv )
{
switch ( 1 )
{
case 1:
; // workaround
int bug = 0;
break;
}
return 0;
}
gcc compiles this fine.
I have successfully reproduced this on multiple platforms both 32 bit and 64
bit in gcc 4.1.1 and 4.0.2. I suspect earlier and intermediate versions suffer
from this bug as well.
--
Summary: parser bug for variable declaration immediately
following case statement in switch block
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alx at gotnull dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29444
[Bug target/24649] Hello world c++ prog core dumps
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-10-12 20:31 --- > I have found the cause of the problem. It isn't a problem with gcc. > > I use the binutils shipped with Solaris10 to strip the binaries and create > separate debug symbol files. If I do not strip g++/libstdc++, the test > program runs with no problems. Thanks a lot for your investigation! -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24649
[Bug c/29444] parser bug for variable declaration immediately following case statement in switch block
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 20:47 --- This is not valid C code. even though declarations can appear intermixed with statements, they are still not a statement and cannot be placed anywhere a statement can. This is a dup of bug 29062. *** This bug has been marked as a duplicate of 29062 *** -- 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=29444
[Bug c/29062] Parse error after label and variable declaration
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-12 20:47 --- *** Bug 29444 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||alx at gotnull dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug c++/29048] [4.0/4.1/4.2 Regression] "`x' is private" error duplicated when scope specified
--- Comment #3 from steven at gcc dot gnu dot org 2006-10-12 21:22 ---
I thought it would simply be a matter of using TREE_NO_WARNING ... until I
realized this was not a warning but an error.
Anyway, following the method of the fix for PR19375, I bootstrapped and tested
this patch below, but since this is a language issue and my understanding of
C++ is non-existing, I'm unassigning myself from this PR.
Index: semantics.c
===
--- semantics.c (revision 117672)
+++ semantics.c (working copy)
@@ -1559,8 +1559,12 @@ finish_qualified_id_expr (tree qualifyin
transformation, as there is no "this" pointer. */
;
else if (TREE_CODE (expr) == FIELD_DECL)
-expr = finish_non_static_data_member (expr, current_class_ref,
- qualifying_class);
+{
+ push_deferring_access_checks (dk_no_check);
+ expr = finish_non_static_data_member (expr, current_class_ref,
+ qualifying_class);
+ pop_deferring_access_checks ();
+}
else if (BASELINK_P (expr) && !processing_template_decl)
{
tree fns;
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
[Bug c/29445] New: Add attribute for 'experimental'
It would be useful to have a a function attribute 'experimental' a la 'deprecated'. (Also useful would be something like -Werror-deprecated and -Werror-experimental to go with it.) -- Summary: Add attribute for 'experimental' Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29445
Re: [Bug c/29444] parser bug for variable declaration immediately following case statement in switch block
pinskia at gcc dot gnu dot org wrote:- > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 20:47 > --- > This is not valid C code. > even though declarations can appear intermixed with statements, they are still > not a statement and cannot be placed anywhere a statement can. > > This is a dup of bug 29062. It's going to keep getting reported until the diagnostic improves and shows that it's not the compiler that is confused. Neil.
[Bug c/29444] parser bug for variable declaration immediately following case statement in switch block
--- Comment #2 from neil at daikokuya dot co dot uk 2006-10-12 22:27 --- Subject: Re: parser bug for variable declaration immediately following case statement in switch block pinskia at gcc dot gnu dot org wrote:- > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-12 20:47 > --- > This is not valid C code. > even though declarations can appear intermixed with statements, they are still > not a statement and cannot be placed anywhere a statement can. > > This is a dup of bug 29062. It's going to keep getting reported until the diagnostic improves and shows that it's not the compiler that is confused. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29444
[Bug fortran/29446] New: VRP ICE in compare_names
troutmask:kargl[206] gfc -m32 -O3 -fbounds-check -c vrp.f90 vrp.f90: In function 'abc': vrp.f90:1: internal compiler error: in compare_names, at tree-vrp.c:3645 The Fortran code is function abc(n) integer :: xsd(n), abc(size(xsd),n), i, j, n do i=1,2 do j=1,3 if (i /= j) then abc(1,1) = 0 else abc(1,j) = xsd(1) end if end do end do end function abc -- Summary: VRP ICE in compare_names Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug target/29250] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #6 from dje at gcc dot gnu dot org 2006-10-12 23:02 --- The reason this is going off the rails is a "long" index invokes expand_expr_real_1 with PLUS_EXP and modifier=EXPAND_NORMAL while "long long" invokes it with modifier=EXPAND_SUM. For EXPAND_NORMAL, GCC invokes expand_operands() and then calls expand_binop(), which tests predicates. For EXPAND_SUM, expand_operands() is followed by simplify_gen_binary(), which does not check predicates. Invalid RTL is created and fun ensues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug target/29250] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #7 from dje at gcc dot gnu dot org 2006-10-12 23:39 --- unit size align 64 symtab 0 alias set -1 precision 64 pointer_to_this > sizes-gimplified unsigned SI size unit size align 32 symtab 0 alias set -1> arg 0 arg 0 arg 0 arg 0 arg 0 arg 0 arg 0 arg 1 > arg 1 arg 1 arg 2 arg 5 arg 6 arg 1 >> arg 1 used tree_1 unsigned decl_5 SI file /farm/dje/gui.cc line 17 size unit size align 32 context (reg/v/f:SI 151 [ fm ])>> The INDIRECT_REF case of expand_expr() sets modifier=EXPAND_SUM, but EXPAND_SUM only should apply to the top level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #5 from danp57 at optonline dot net 2006-10-12 23:42 --- Subject: Re: configure produces strange gmp, mpfr lib directories. Thank you very much for the question! It never occurred to me to use/ force 32-bit. Configure worked smoothly. I did do a build of C, which doesn't need gmp and mpfr, thinking that some of the confusion could have been due to odd library re-directions due to the placement of a back-level gcc in a non-standard place (the machine I'm using mounted it elsewhere). I'm now using the 4.1.1 to build this with, with 32 bit selected. Other headaches: ulimit. Another comment: I WISH I could tell you it fixed the problem... but I will not be able to know for a few days. The "checking for... usability, presence" stuff takes forever... much longer than much more modest machines (like my wife's old laptop running cygwin). You'll just have to wait a day or so to find out how this went! Dan On Oct 12, 2006, at 12:58 PM, dje at gcc dot gnu dot org wrote: > > > --- Comment #4 from dje at gcc dot gnu dot org 2006-10-12 > 16:58 --- > You should be using > > --with-gmp=/usr/local > > Are you sure that /usr/local/lib/libgmp.a exists and was built > correct? Use > static libraries and make sure that you are building 32-bit libgmp > and libmpfr. > > > -- > > dje at gcc dot gnu dot org changed: > >What|Removed |Added > -- > -- > CC||dje at gcc dot gnu > dot org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-12 23:46 --- (In reply to comment #5) > Another comment: I WISH I could tell you it fixed the problem... but > I will not be able to know for a few days. The "checking for... > usability, presence" stuff takes forever... much longer than much > more modest machines (like my wife's old laptop running cygwin). > You'll just have to wait a day or so to find out how this went! Try setting CONFIG_SHELL to bash or ksh which is faster than the default AIX shell. Closing as invalid because the libraries were installed wrong to begin with. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug c++/29175] [4.0/4.1 regression] ICE on invalid C++ variable length array
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-10-12 23:53 --- Subject: Bug 29175 Author: mmitchel Date: Thu Oct 12 23:53:04 2006 New Revision: 117677 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117677 Log: PR c++/29175 * decl.c (check_initializer): Issue errors about trying to initialize arrays whose elements have variable size. PR c++/29175 * g++.dg/init/array24.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/array24.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29175
[Bug c++/29175] [4.0 regression] ICE on invalid C++ variable length array
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 regression] ICE on |[4.0 regression] ICE on |invalid C++ variable length |invalid C++ variable length |array |array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29175
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #7 from dje at gcc dot gnu dot org 2006-10-12 23:59 --- Yes, please read the target-specific build and installation notes for AIX. Set CONFIG_SHELL (and SHELL) environment variables to invoke bash. The installation notes also mention process limits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug fortran/29447] New: Getting different answers for DLSODE demo code
I tried to run DLSODE and its demo code that I got directly off from netlib. Surprisingly, I got different answers for some examples. Compiling option matters but I finally could get the idential numbers out of gfortran and g77 compared with what the demo code produced. At this point, I am not sure if the exactly same answer from gfortrn as the output of original demo code ensures its correctness. If so, can pgf90 (v. 5.2) and ifort (intel's fortran compiler) be wrong? Following are the example lines showing differences. These are specifically line 313 of the demo outputs. In the demo code (or text) says (note that I replaced original "E" with "D" in number expressions for my own convenience): 0.1D+03 0.908D-081 0.992D+02 gfortran with -static -O1: 0.1D+03 0.908D-081 0.992D+02 pgf90 with -pc 64 -O1 -Bstatic: 0.1D+03 0.335D-091 0.251D+02 ifort without any option: 0.1D+03 0.333D-081 0.225D+02 Does anyone know what the best way is to ensure minimizing numerical errors (or differences) between compilers? Or, a way to check if my compiled binary is indeed more accurate than others? -- Summary: Getting different answers for DLSODE demo code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: byeonguk dot kim at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29447
[Bug c++/29318] [4.0/4.1/4.2 Regression] ICE: type_info of pointer to VLA
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #8 from danp57 at optonline dot net 2006-10-13 00:25 --- Subject: Re: configure produces strange gmp, mpfr lib directories. Yup -- CONFIG_SHELL helps a lot. Thanks to both you and pinskia. However, I had *tried* to find aix installation notes at http:// gcc.gnu.org/install/specific.html -- didn't see any listed in powerpc section, though there is a generic aix page. None of then specified the 32-bit library build for gmp and mpfr required for gfortran (I did find a ref under sparc systems). I also noted the comment that online docs were back-level, and to check the bugzilla pages ;-) Given the simplicity of what it actually took to fix this, they might be worth adding to the install/specific.html pages. I also noticed significant efforts to update the web pages... looks good. Dan On Oct 12, 2006, at 7:59 PM, dje at gcc dot gnu dot org wrote: > > > --- Comment #7 from dje at gcc dot gnu dot org 2006-10-12 > 23:59 --- > Yes, please read the target-specific build and installation notes > for AIX. Set > CONFIG_SHELL (and SHELL) environment variables to invoke bash. The > installation notes also mention process limits. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. Daniel Platt [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug fortran/29447] Getting different answers for DLSODE demo code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29447
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-13 00:39 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90 > Can you try the attached patch? This fixes the PR. The gfortran testsuite is now clean on hppa2.0w-hp-hpux11.11. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms
--- Comment #7 from patchapp at dberlin dot org 2006-10-13 01:30 --- Subject: Bug number PR29277 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00677.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #9 from danp57 at optonline dot net 2006-10-13 01:33 --- Subject: Re: configure produces strange gmp, mpfr lib directories. Build was successful. Thank you each for your assistance! Dan On Oct 12, 2006, at 7:59 PM, dje at gcc dot gnu dot org wrote: > > > --- Comment #7 from dje at gcc dot gnu dot org 2006-10-12 > 23:59 --- > Yes, please read the target-specific build and installation notes > for AIX. Set > CONFIG_SHELL (and SHELL) environment variables to invoke bash. The > installation notes also mention process limits. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. Daniel Platt [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-13 01:41 --- Note: I believe it may be necessary to explicitly inject a '\r' when a '\n' is embedded in a string. I am not quite set up to test this yet here. So I would much appreciate if some one can do that, while I continue to study that part. The patch submitted in comment #7 is fully test on '\n' only system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug c++/29225] [4.0/4.1/4.2 regression] ICE in gimplify_expr, at gimplify.c:4513
--- Comment #5 from seongbae dot park at gmail dot com 2006-10-13 02:27
---
A modified and valid case which doesn't cause ICE:
template bool operator<( LHS lhs, RHS rhs );
struct ComputedAttribute {
int descriptor();
};
class AttributeDescriptor {};
template
struct less_member_2_m
{
typedef R (T::* T_mem_ptr) ();
T_mem_ptr mem_ptr;
template
bool operator()(R_alt & rhs )
{
T a;
return ( a.*mem_ptr )() < rhs ;
}
};
void computedAttribute( AttributeDescriptor & desc )
{
less_member_2_m m;
m.mem_ptr = &ComputedAttribute::descriptor;
m(desc);
}
Change the operator() to:
template
bool operator()(R_alt & rhs )
{
T a;
return ( a.*mem_ptr ) < rhs ;
}
causes the ICE.
# /home/spark/blds/trunk-work/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/spark/local/ws/trunk-work/configure
--prefix=/home/spark/blds/trunk-work/ --disable-nls --disable-multilib
-enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit -enable-c99
--enable-long-long --enable-shared --enable-languages=c,c++
Thread model: posix
gcc version 4.2.0 20061006 (experimental)
# /home/spark/blds/trunk-work/bin/g++ correct.cc -c
# /home/spark/blds/trunk-work/bin/g++ incorrect.cc -c
incorrect.cc: In member function 'bool less_member_2_m::operator()(R_alt&) [with R_alt = AttributeDescriptor, T =
ComputedAttribute, R = int]':
incorrect.cc:28: instantiated from here
incorrect.cc:19: internal compiler error: in gimplify_expr, at gimplify.c:5806
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
#
Note that this is the same ICE I get from the attachment.
--
seongbae dot park at gmail dot com changed:
What|Removed |Added
CC||seongbae dot park at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29225
[Bug debug/29443] [4.1 regression] ICE: output_operand: invalid expression as operand with -gstabs
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-13 02:44 --- This works on 4.1.2 20061007 on i686-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29443
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-13 03:19 ---
C testcase:
void f(int *n, int *m)
{
int i;
int ubound0;
int ubound1;
int stride2;
int offset3;
int size4;
int j;
int ubound5;
int size6;
int D919;
__SIZE_TYPE__ D920;
int D921;
unsigned int D922;
__SIZE_TYPE__ D923;
unsigned int D924;
ubound0 = *m;
stride2 = ubound0;
ubound1 = *n;
size4 = stride2 * ubound1;
D922 = size4 - 1;
int (*abc)[D922];
abc = _gfortran_internal_malloc (size4 * 4);
offset3 = ~stride2;
ubound5 = *n;
size6 = ubound5;
D919 = size6 - 1;
int (*xsd)[D919];
xsd = _gfortran_internal_malloc (size6 * 4);
i = 1;
if (i <= 2)
{
while (1)
{
{
_Bool D918;
j = 1;
if (j <= 3)
{
while (1)
{
{
_Bool D917;
if (i != j)
{
if (__builtin_expect (ubound0 <= 0, 0))
{
__builtin_abort ();
}
else
{
(void) 0;
}
if (__builtin_expect (ubound1 <= 0, 0))
{
__builtin_abort ();
}
else
{
(void) 0;
}
(*abc)[stride2 + offset3 + 1] = 0;
}
else
{
{
int D916;
if (__builtin_expect (ubound0 <= 0, 0))
{
__builtin_abort ();
}
else
{
(void) 0;
}
D916 = j;
if (__builtin_expect (D916 <= 0, 0))
{
__builtin_abort ();
}
else
{
(void) 0;
}
if (__builtin_expect (D916 > ubound1, 0))
{
__builtin_abort ();
}
else
{
(void) 0;
}
if (__builtin_expect (ubound5 <= 0, 0))
{
__builtin_abort ();
}
else
{
(void) 0;
}
(*abc)[D916 * stride2 + offset3 + 1] = (*xsd)[0];
}
}
D917 = j == 3;
j = j + 1;
if (D917) break; else (void) 0;
}
}
}
else
{
(void) 0;
}
// L4:;
D918 = i == 2;
i = i + 1;
if (D918) break; else (void) 0;
}
}
}
else
{
(void) 0;
}
//L2:;
_gfortran_internal_free ((void *) xsd);
_gfortran_internal_free ((void *) abc);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.2.0
Known to work||4.1.2
Last reconfirmed|-00-00 00:00:00 |2006-10-13 03:19:26
date||
Summary|VRP ICE in compare_names|[4.2 Regression] VRP ICE in
||compare_names
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-13 03:34 ---
here is a shorter testcase:
void f(void)
{
int i, ubound1, j, ubound5;
int (*abc)[3];
i = 1;
while (1)
{
if (j <= 3)
while (1)
{
_Bool D917;
if (i != j)
{
if (__builtin_expect (ubound1 <= 0, 0))
__builtin_abort ();
(*abc)[1] = 0;
}
else
{
int D916;
D916 = j;
if (__builtin_expect (D916 > ubound1, 0))
__builtin_abort ();
if (__builtin_expect (ubound5 <= 0, 0))
__builtin_abort ();
}
j = j + 1;
if (D917)
break;
}
i = i + 1;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug c++/29318] [4.0/4.1/4.2 Regression] ICE: type_info of pointer to VLA
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-10-13 04:09 --- Subject: Bug 29318 Author: mmitchel Date: Fri Oct 13 04:09:41 2006 New Revision: 117683 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117683 Log: PR c++/29318 * rtti.c (get_tinfo_decl): Refuse to create type info objects for variably modified types. PR c++/29318 * g++.dg/ext/vla4.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/vla4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
[Bug c++/29318] [4.0 Regression] ICE: type_info of pointer to VLA
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-10-13 04:15 --- Fixed in 4.1.2, 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1/4.2 Regression]|[4.0 Regression] ICE: |ICE: type_info of pointer to|type_info of pointer to VLA |VLA | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
[Bug c++/28506] [4.0/4.1/4.2 regression] ICE with initializers for functions
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28506
[Bug fortran/29434] array bounds of allocatable components of derived types?
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-13 05:13 --- Thanks, Dominique, for provoking the discussion and to veryone else for the discussion and the resolution of the PR. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29434
[Bug bootstrap/29402] Parallel make fails with --disable-bootstrap
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-10-13 06:09 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00684.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2006- |patches/2006- |10/msg00662.html|10/msg00684.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29402
