[Bug inline-asm/34833] rejects i(var) with -fpic -m32
--- Comment #3 from stsp at users dot sourceforge dot net 2008-01-19 08:25 --- Yes, I know, but... without -m32 it compiles. So either way it might be a bug - maybe it should not compile without -m32 too? Why does -m32 make the difference here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
[Bug c++/34864] New: ldexp variants, folding
Briefly: of all the ldexp variants only straight ldexp consistently get folded.
The overloaded c++ version, std::ldexp, is the easiest to derail, as this
testcase demonstrates (note: you can't get much more than 1 such call folded);
but it has also happened to me with ldexpf, it's just harder to trigger.
$ cat pr-ldexp.cc
#include cmath
#define L1(x) ldexp((float)(x | (123)), -23)
#define L2(x) std::ldexp((float)(x | (123)), -23)
int main(int argc, char *argv[]) {
const float tbl[] = { L(0), L(1), L(2), L(3) };
return int(tbl[argc]);
}
$ /usr/local/gcc-4.3-20080104/bin/g++ -O2 -march=k8 -DL=L1 pr-ldexp.cc -o pr1
$ /usr/local/gcc-4.3-20080104/bin/g++ -O2 -march=k8 -DL=L2 pr-ldexp.cc -o pr2
pr1:
401091: f3 0f 10 04 9d 00 20movss 0x402000(,%ebx,4),%xmm0
40109e: f3 0f 2c c0 cvttss2si %xmm0,%eax
4010a2: c9 leave
pr2:
401090: c7 45 e8 00 00 80 3fmovl $0x3f80,0xffe8(%ebp)
401097: c7 45 ec 01 00 80 3fmovl $0x3f81,0xffec(%ebp)
40109e: c7 45 f0 02 00 80 3fmovl $0x3f82,0xfff0(%ebp)
4010a5: c7 45 f4 03 00 80 3fmovl $0x3f83,0xfff4(%ebp)
4010ac: f3 0f 10 44 9d e8 movss 0xffe8(%ebp,%ebx,4),%xmm0
4010b2: 8b 5d fcmov0xfffc(%ebp),%ebx
4010b5: f3 0f 2c c0 cvttss2si %xmm0,%eax
4010b9: c9 leave
(k8/sse codegen selected for clarity)
--
Summary: ldexp variants, folding
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34864
[Bug inline-asm/34830] rejects i(const_var) without -O1
--- Comment #3 from stsp at users dot sourceforge dot net 2008-01-19 08:35 --- Yes, but the point was that the same code should not compile/reject depending only on an optimizer options. If this code is invalid, then with -O2 it should give the error as well, or at least a warning. The optimizer can not silently turn the wrong code into the right code and vice versa. Also, g++ compiles it even without an optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34830
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-01-19 08:33 --- (In reply to comment #4) Testing a patch. Here it is: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00881.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #55 from steven at gcc dot gnu dot org 2008-01-19 09:41 --- IMHO we can close this one now as fixed. Objections to that, anyone? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug target/34865] New: valgrind error indication in testsuite from i386.c:merge_classes
A r131535 of trunk bootstrapped with --enable-langugages=c --enable-checking=release,valgrind shows this indication for several test-cases, the first being tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o compile (just the first indication of several identical is shown): Executing on host: /tmp/hptest8/obj/gcc/xgcc -B/tmp/hptest8/obj/gcc/ -w -I/tmp/hptest8/gcc/gcc/testsuite/gcc.dg/compat -fno-show -column -c -o c_compat_x_tst.o /tmp/hptest8/obj/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t001_x.c(timeout = 300) ==22344== Conditional jump or move depends on uninitialised value(s) ==22344==at 0x7046E2: merge_classes (i386.c:3558) ==22344==by 0x7082A0: classify_argument (i386.c:3682) ==22344==by 0x7083F5: examine_argument (i386.c:3883) ==22344==by 0x708660: ix86_return_in_memory (i386.c:4752) ==22344==by 0x5F3178: default_return_in_memory (targhooks.c:113) ==22344==by 0x52A419: aggregate_value_p (function.c:1801) ==22344==by 0x543704: gimplify_modify_expr_rhs (gimplify.c:3653) ==22344==by 0x53D616: gimplify_modify_expr (gimplify.c:3857) ==22344==by 0x53ED72: gimplify_expr (gimplify.c:5680) ==22344==by 0x541086: gimplify_and_add (gimplify.c:348) ==22344==by 0x53D37C: internal_get_tmp_var (gimplify.c:631) ==22344==by 0x53DF74: gimplify_expr (gimplify.c:6245) -- Summary: valgrind error indication in testsuite from i386.c:merge_classes Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34865
[Bug target/34865] valgrind error indication in testsuite from i386.c:merge_classes
--- Comment #1 from hp at gcc dot gnu dot org 2008-01-19 10:43 --- Using a later revision is recommended, at least = r131589. -- hp 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-01-19 10:43:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34865
[Bug target/34865] valgrind error indication in testsuite from i386.c:merge_classes
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-19 10:48 --- merge_classes() itself is clear, so the problem must be in the caller. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34865
[Bug preprocessor/34866] New: valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c
A r131535 of trunk bootstrapped with --enable-langugages=c --enable-checking=release,valgrind shows this indication for gcc.dg/cpp/Wmissingdirs.c and also an ICE: Executing on host: /tmp/hptest8/obj/gcc/xgcc -B/tmp/hptest8/obj/gcc/ /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/Wmissingdirs.c -s td=gnu99 -I /jolly/well/better/not/exist -Wmissing-include-dirs -fno-show-column -fno-show-column -E -o Wmissingdirs.i(timeou t = 300) ==23626== Invalid read of size 4 ==23626==at 0x9245B4: cpp_error (errors.c:156) ==23626==by 0x4489FB: remove_duplicates (c-incpath.c:235) ==23626==by 0x448B32: register_include_chains (c-incpath.c:331) ==23626==by 0x44268B: c_common_post_options (c-opts.c:1029) ==23626==by 0x5F5B1D: toplev_main (toplev.c:1732) ==23626==by 0x387301E073: (below main) (in /lib64/libc-2.7.so) ==23626== Address 0x4C67958 is not stack'd, malloc'd or (recently) free'd ==23626== ==23626== Invalid read of size 4 ==23626==at 0x92D464: linemap_lookup (line-map.c:282) ==23626==by 0x9241CA: _cpp_begin_message (errors.c:47) ==23626==by 0x9245C3: cpp_error (errors.c:159) ==23626==by 0x4489FB: remove_duplicates (c-incpath.c:235) ==23626==by 0x448B32: register_include_chains (c-incpath.c:331) ==23626==by 0x44268B: c_common_post_options (c-opts.c:1029) ==23626==by 0x5F5B1D: toplev_main (toplev.c:1732) ==23626==by 0x387301E073: (below main) (in /lib64/libc-2.7.so) ==23626== Address 0xC is not stack'd, malloc'd or (recently) free'd cc1: internal compiler error: Segmentation fault -- Summary: valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34866
[Bug preprocessor/34866] valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c
--- Comment #1 from hp at gcc dot gnu dot org 2008-01-19 10:54 --- Using a later revision is recommended, at least = r131589. -- hp 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-01-19 10:54:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34866
[Bug fortran/34868] New: Internal error compiler errror appears.
Following preprocessed program can not be compiled with -ff2c option due to the internal compiler error (all the messages are listed below test.f). beginning of test.f function f(a) implicit none complex(8) :: f real(8),intent(in) :: a(:) f=cmplx(0d0,0d0,8) end function f end of test.f % gfortran -O0 -ff2c -c test.f test.f: In function 'f': test.f:5: internal compiler error: in convert_memory_address, at explow.c:325 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: Internal error compiler errror appears. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yamagen at coral dot t dot u-tokyo dot ac dot jp GCC build triplet: powerpc-apple-darwin8.10.0 GCC host triplet: powerpc-apple-darwin8.11.0 GCC target triplet: powerpc-apple-darwin8.10.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34868
[Bug preprocessor/34869] New: valgrind error indication in testsuite from _cpp_lex_token (lex.c:783) with gcc.dg/cpp/line5.c
A r131535 of trunk (a later revision is recommended, at least = r131589) bootstrapped with --enable-langugages=c --enable-checking=release,valgrind shows these error indications for gcc.dg/cpp/line5.c (as in gcc.log, but only the first 3 are shown): Executing on host: /tmp/hptest8/obj/gcc/xgcc -B/tmp/hptest8/obj/gcc/ /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/line5.c -fpreproc essed -fno-show-column -E -o line5.i(timeout = 300) ==24251== Conditional jump or move depends on uninitialised value(s) ==24251==at 0x92D27B: _cpp_lex_token (lex.c:783) ==24251==by 0x92F6FC: cpp_get_token (macro.c:1110) ==24251==by 0x4499B7: preprocess_file (c-ppoutput.c:148) ==24251==by 0x4422C0: c_common_init (c-opts.c:1237) ==24251==by 0x44C21D: c_objc_common_init (c-objc-common.c:72) ==24251==by 0x5F5FA7: toplev_main (toplev.c:2128) ==24251==by 0x387301E073: (below main) (in /lib64/libc-2.7.so) ==24251== ==24251== Conditional jump or move depends on uninitialised value(s) ==24251==at 0x92F712: cpp_get_token (macro.c:1137) ==24251==by 0x4499B7: preprocess_file (c-ppoutput.c:148) ==24251==by 0x4422C0: c_common_init (c-opts.c:1237) ==24251==by 0x44C21D: c_objc_common_init (c-objc-common.c:72) ==24251==by 0x5F5FA7: toplev_main (toplev.c:2128) ==24251==by 0x387301E073: (below main) (in /lib64/libc-2.7.so) ==24251== ==24251== Conditional jump or move depends on uninitialised value(s) ==24251==at 0x4499C2: preprocess_file (c-ppoutput.c:150) ==24251==by 0x4422C0: c_common_init (c-opts.c:1237) ==24251==by 0x44C21D: c_objc_common_init (c-objc-common.c:72) ==24251==by 0x5F5FA7: toplev_main (toplev.c:2128) ==24251==by 0x387301E073: (below main) (in /lib64/libc-2.7.so) -- Summary: valgrind error indication in testsuite from _cpp_lex_token (lex.c:783) with gcc.dg/cpp/line5.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34869
[Bug c/34867] New: valgrind error indication in testsuite from c-lex.c:996:c_lex_with_flags for gcc.dg/cpp/charconst.c
A r131535 of trunk (a later revision is recommended, at least = r131589) bootstrapped with --enable-langugages=c --enable-checking=release,valgrind shows these indications for gcc.dg/cpp/charconst.c (show as in gcc.log): Executing on host: /tmp/hptest8/obj/gcc/xgcc -B/tmp/hptest8/obj/gcc/ /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c-ans i -pedantic-errors -fno-show-column -S -o charconst.s(timeout = 300) /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:10: error: empty character constant /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:12: error: empty character constant /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:14: warning: character constant too long for its type /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:16: warning: character constant too long for its type /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:19: warning: multi-character character constant /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:27: error: empty character constant ==23842== Conditional jump or move depends on uninitialised value(s) ==23842==at 0x4041B7: c_lex_with_flags (c-lex.c:996) ==23842==by 0x44D20E: c_lex_one_token (c-parser.c:310) ==23842==by 0x453666: c_parser_cast_expression (c-parser.c:415) ==23842==by 0x4537C1: c_parser_conditional_expression (c-parser.c:4691) ==23842==by 0x453F24: c_parser_expr_no_commas (c-parser.c:4452) ==23842==by 0x4540A6: c_parser_expr_no_commas (c-parser.c:4492) ==23842==by 0x454121: c_parser_expression (c-parser.c:5699) ==23842==by 0x4543E8: c_parser_expression_conv (c-parser.c:5719) ==23842==by 0x450AB5: c_parser_statement_after_labels (c-parser.c:3880) ==23842==by 0x451C07: c_parser_compound_statement_nostart (c-parser.c:3565) ==23842==by 0x457004: c_parser_compound_statement (c-parser.c:3413) ==23842==by 0x45750C: c_parser_declaration_or_fndef (c-parser.c:1412) /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:28: error: empty character constant /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:30: warning: character constant too long for its type /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:31: warning: character constant too long for its type /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:33: warning: multi-character character constant /tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/charconst.c:35: warning: character constant too long for its type -- Summary: valgrind error indication in testsuite from c- lex.c:996:c_lex_with_flags for gcc.dg/cpp/charconst.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34867
[Bug c++/34870] template not instantiated for argument-dependent lookup
--- Comment #1 from dragan at plusplus dot co dot yu 2008-01-19 11:39 --- Created an attachment (id=14974) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14974action=view) a simple test case (the same as in the bug description) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34870
[Bug c++/34870] New: template not instantiated for argument-dependent lookup
This code should be legal:
template typename T
struct Foo
{
template typename Z
friend void func(const Foo ) {}
};
void check(const Fooint x)
{
// Fooint weird; // uncomment this line and all works
funcint(x);// -- GCC issues an ERROR
}
After a brief discussion on [EMAIL PROTECTED], it has been concluded that this
sample code should work. Apparently, 'func' should have been found by
argument-dependent lookup, instantiating 'Fooint' in the process.
Here are links to backup these claims, as specified in the discussion by people
involved:
- C++ Standard
- 3.4.2 [basic.lookup.koenig]
- 14.6.5 [temp.inject]
- 7.3.1.2 [namespace.memdef] p3
- Vandevoorde and Josuttis' C++ Templates, section 9.2.2
- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#34
([EMAIL PROTECTED] thread 'A simple sample code involving templates, friends and
lookup')
--
Summary: template not instantiated for argument-dependent lookup
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dragan at plusplus dot co dot yu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34870
[Bug fortran/34868] Internal error compiler errror appears.
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-19 11:34 --- Confirmed on darwin9 (ppc/intel) with adifferent error: pr34868.f90: In function 'f': pr34868.f90:5: internal compiler error: in gimplify_expr, at gimplify.c:6285 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34868
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-19 12:03 --- Does the regression on C2 duo show even without vectorizing? It looks like generic SSE fpmath performance issue. There should be no reason why SSE math in combination with SSE vectorization should result in regression... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug tree-optimization/34864] array constants after inlining and staticification
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-19 12:04 ---
It is constant folded but not until after inlining.
A simplier example is:
static inline int f(int a)
{
return a+2;
}
int g(int a)
{
const int b[] = {f(1), f(2), f(3) };
return b[a];
}
int g1(int a)
{
const int b[] = {(1)+2, (2)+2, (3)+2 };
return b[a];
}
CUT
Where g and g1 could produce the same code if wanted to.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Component|c++ |tree-optimization
Ever Confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2008-01-19 12:04:07
date||
Summary|ldexp variants, folding |array constants after
||inlining and
||staticification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34864
[Bug inline-asm/34830] rejects i(const_var) without -O1
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-19 12:07 --- Oh, in C++, const_var is a constant integral expression after all so that is why it is accepted with C++ front-end, I had forgot the exact rules for C++ for a second there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34830
[Bug inline-asm/34833] rejects i(var) with -fpic -m32
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-19 12:08 --- Well with x86_64, PIC addressing global variables is simpler as you have access to the rip register. Try this on any other target, you will get a rejection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
[Bug fortran/34868] Internal error compiler errror appears with -ff2c
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-19 12:11 --- complex(kind=8) __result_f; *__result_f = 0.0; return __result_f; :) Well that is obviously wrong. Also is there a reason why you are using -ff2c anyways? It does change the ABI slightly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2008-01-19 12:11:47 date|| Summary|Internal error compiler |Internal error compiler |errror appears. |errror appears with -ff2c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34868
[Bug fortran/34871] New: Flavor VARIABLE vs. FUNCTION: Accepts invalid
MODULE TESTS dimension :: k(4) CONTAINS function k() k = 35 end function k END MODULE is invalid (variable k vs. function k), but not detected. Needs to be fixed in decl.c's get_proc_name; I have a patch, but it causes regressions -- Summary: Flavor VARIABLE vs. FUNCTION: Accepts invalid Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871
[Bug bootstrap/33200] install fails when trying to install fix-header since fix-header wasn't built
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-19 12:37 --- Bruce, Can you please have a look. How is that ment to work? -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||bkorb at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200
[Bug fortran/34868] ICE with -ff2c for function returning a complex number
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-19 12:43 ---
Without -ff2c, gfortran uses (-fdump-tree-original):
complex(kind=8) __result_f;
__result_f = __complex__ (0.0, 0.0);
but for -ff2c it looks odd:
f (a)
{
complex(kind=8) __result_f;
*__result_f = 0.0;
return __result_f;
}
Besides, the complex result should not be returned as function result but as
additional parameter. At least this is what the gfortran manual claims:
The calling conventions used by g77 (originally implemented in f2c) require
functions that return type default REAL to actually return the C type double,
and functions that return type COMPLEX to return the values via an extra
argument in the calling sequence that points to where to store the return
value
g77 manual: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Functions.html
But it would be better if you could avoid the option -ff2c; it is much less
tested, incompatible to almost all other Fortran compilers including g77 with
the -fno-f2c compiler option.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|powerpc-apple-darwin8.10.0 |
GCC host triplet|powerpc-apple-darwin8.11.0 |
GCC target triplet|powerpc-apple-darwin8.10.0 |
Last reconfirmed|2008-01-19 12:11:47 |2008-01-19 12:43:02
date||
Summary|Internal error compiler |ICE with -ff2c for function
|errror appears with -ff2c |returning a complex number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34868
[Bug inline-asm/34833] rejects i(var) with -fpic -m32
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-19 12:47 --- OK, I understand, thank you. Closing it then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #56 from zadeck at naturalbridge dot com 2008-01-19 13:09 --- Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions Let me commit the patch first. Sent from my iPod On Jan 19, 2008, at 4:41 AM, steven at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #55 from steven at gcc dot gnu dot org 2008-01-19 09:41 --- IMHO we can close this one now as fixed. Objections to that, anyone? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug bootstrap/33200] install fails when trying to install fix-header since fix-header wasn't built
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-19 14:14 ---
Assuming build=i386-linux-*, host==target==sh4-linux-*, i.e. cross-compiling a
native compiler for SuperH:
-) sh*-* forces use_fixproto in config.gcc (why?)
See config.gcc: line 2308
-) stmp-install-fixproto: fixproto
- The comment above this rule is wrong, fixproto is a shell-script.
- this rule doesn't depend on any fix-header, but the stamp is used
to unconditionally install fix-header.
-) build/fix-header${build_exeext}
Tries to compile a binary with mixed build- and host- objects, like
(abbreviated):
$HOSTCC -DGENERATOR_FILE -o build/fix-header \
build/fix-header.o c-incpath.o cppdefault.o build/scan-decls.o prefix.o \
build/scan.o build/errors.o ../libcpp/libcpp.a ../libiberty/libiberty etc.
where build/* is of course incompatible with the other object files.
This suggests that use_fixproto resp. stmp-install-fixproto makes only sense
for
host == build *or* (assuming this is not correct) that we need fix-header for
both build and for host (which is currently not implemented AFAICS).
Please advise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200
[Bug fortran/34760] [4.3 Regression] PRIVATE variable not allowed as STAT variable in ALLOCATE
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-19 14:16 --- Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00236.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug fortran/34795] inquire statement , direct= specifier incorrectly returns YES
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-19 15:31 --- Not that this reference is always right, but Metcalf, Reid, and Cohen state: direct=dir where dir ... are character variables that are assigned the value YES, NO, or UNKNOWN, depending on whether the file may be opened for ... direct access ... or whether this can not be determined. To me, key here is may be opened which implies the file is not open yet. So, if the file has been opened already,its nonsense to use inquire this way, but the answer is obviously NO for a file opened for sequential. The standard could be improved by addressing this case where the file is already opened. So based on that, I agree we change gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34795
[Bug fortran/34872] New: Spurious error in snapshot of 01/18/08: Statement at (1) is not a valid branch target statement for the branch statement at (2)
When I compile the function listed below using the January 18 snapshot of gfortran, I get the following error: t.f90:2.2: 10 CONTINUE 1 t.f90:3.7: GOTO 10 2 Error: Statement at (1) is not a valid branch target statement for the branch statement at (2) I believe it applies to all platforms. CHARACTER FUNCTION t() 10 CONTINUE GOTO 10 t = ' ' END FUNCTION t -- Summary: Spurious error in snapshot of 01/18/08: Statement at (1) is not a valid branch target statement for the branch statement at (2) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34872
[Bug fortran/34760] [4.3 Regression] PRIVATE variable not allowed as STAT variable in ALLOCATE
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-19 15:41 --- Subject: Bug 34760 Author: burnus Date: Sat Jan 19 15:41:04 2008 New Revision: 131652 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131652 Log: 2008-01-19 Tobias Burnus [EMAIL PROTECTED] PR fortran/34760 * primary.c (match_variable): Handle FL_UNKNOWN without uneducated guessing. (match_variable): Improve error message. 2008-01-19 Tobias Burnus [EMAIL PROTECTED] PR fortran/34760 * gfortran.dg/implicit_11.f90: New. * gfortran.dg/allocate_stat.f90: Update dg-error pattern. * gfortran.dg/entry_15.f90: Ditto. * gfortran.dg/func_assign.f90: Ditto. * gfortran.dg/gomp/reduction3.f90: Ditto. * gfortran.dg/proc_assign_1.f90: Ditto. * gfortran.dg/interface_proc_end.f90: Use dg-error instead of dg-excess-errors. Added: trunk/gcc/testsuite/gfortran.dg/implicit_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_stat.f90 trunk/gcc/testsuite/gfortran.dg/entry_15.f90 trunk/gcc/testsuite/gfortran.dg/func_assign.f90 trunk/gcc/testsuite/gfortran.dg/gomp/reduction3.f90 trunk/gcc/testsuite/gfortran.dg/interface_proc_end.f90 trunk/gcc/testsuite/gfortran.dg/proc_assign_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug fortran/34872] [4.3 Regression] Spurious error in snapshot of 01/18/08: Statement at (1) is not a valid branch target statement for the branch statement at (2)
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-19 16:03 ---
Confirm. I think it is a fallout of Paul's typespec patch (PR 34429 et alia).
In resolve_branch (which prints the error message), label-defined ==
ST_LABEL_BAD_TARGET.
The problem is probably that ST_GET_FCN_CHARACTERISTICS is not taken care of
correctly. check_statement_label has:
switch (st)
{
case ST_END_PROGRAM: [... some more ST_END*]
case_executable:
case_exec_markers:
type = ST_LABEL_TARGET;
case ST_FORMAT:
type = ST_LABEL_FORMAT;
default:
type = ST_LABEL_BAD_TARGET;
The question is now whether one simply adds the ST_GET_FCN_CHARACTERISTICS to
the cases or whether one adds it to, e.g., #define case_executable ?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2008-01-19 16:03:40
date||
Summary|Spurious error in snapshot |[4.3 Regression] Spurious
|of 01/18/08: Statement at |error in snapshot of
|(1) is not a valid branch |01/18/08: Statement at (1)
|target statement for the|is not a valid branch target
|branch statement at (2) |statement for the branch
||statement at (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34872
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #10 from ubizjak at gmail dot com 2008-01-19 16:31 --- (In reply to comment #9) Does the regression on C2 duo show even without vectorizing? It looks like generic SSE fpmath performance issue. There should be no reason why SSE math in combination with SSE vectorization should result in regression... Hm, using latest SVN, the C2D difference is only marginal: gfortran -O3 -m64 -march=core2 -msse3 -ffast-math -funroll-loops -ftree-loop-linear -fno-tree-vectorize -fno-vect-cost-model -mfpmath=sse 21.37 21.3821.41 -mfpmath=387 20.73 20.6420.69 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU X6800 @ 2.93GHz stepping: 5 cpu MHz : 2933.422 cache size : 4096 KB gcc version 4.3.0 20080119 (experimental) [trunk revision 131650] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug libfortran/34712] Formatted write of float broken (mingw32)
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:12 --- (In reply to comment #4) Reply to comment #2: I will update and see if that fixes it. Thanks Danny I'm closing this: I have built new binaries and I still don't this it. Jerry, if updating doesn't fix it, please reopen. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
[Bug fortran/34760] [4.3 Regression] PRIVATE variable not allowed as STAT variable in ALLOCATE
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-19 17:13 --- FIXED on the trunk (4.3.0). Thanks for the bug report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
[Bug libfortran/34712] Formatted write of float broken (mingw32)
--- Comment #6 from jvdelisle at verizon dot net 2008-01-19 17:20 --- Subject: Re: Formatted write of float broken (mingw32) fxcoudert at gcc dot gnu dot org wrote: --- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:12 --- (In reply to comment #4) Reply to comment #2: I will update and see if that fixes it. Thanks Danny I'm closing this: I have built new binaries and I still don't this it. Jerry, if updating doesn't fix it, please reopen. Agree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
[Bug fortran/34860] -O3 optimization fails for simple fortran77 extrapolation routine
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:20 --- Works for me with a more recent version (version 4.3.0 20071231), on my MacOS 10.4.11/Intel Core Duo, so I'm closing this as fixed. Could you try to update your compiler (see http://gcc.gnu.org/wiki/GFortranBinaries, if that's where you downloaded it from last time) and reopen this bug report if you still see the bug? Thanks for the detailed and precise bug report, that's how we like them! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34860
[Bug fortran/34858] [4.3 Regression] ICE on invalid depending of the length of the source name
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-19 17:21 --- Some debuging (this as fas as I can go on my own): note the line 5: csym-value = (struct gfc_expr *) warning: Got an error handling event: Cannot access memory at for the case that does not crash. (gdb) run 1234567.f90 Starting program: /opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin9/4.3.0/f951 1234567.f90 Reading symbols for shared libraries +. done 1234567.f90:6.13: block data bd 1 Error: Unexpected BLOCK DATA statement at (1) 1234567.f90:7.10: common c 1 Error: Unexpected COMMON statement at (1) 1234567.f90:8.3: end block data bd 1 Error: Expecting END PROGRAM statement at (1) 1234567.f90:10.14: common /a_t/ c 1 Error: Unexpected COMMON statement at (1) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xc04f resolve_common_vars (sym=value temporarily unavailable, due to optimizations, named_common=1 '\001') at ../../gcc-4.3-work/gcc/fortran/resolve.c:657 657 if (csym-value || csym-attr.data) (gdb) b 655 Breakpoint 1 at 0x62f0e: file ../../gcc-4.3-work/gcc/fortran/resolve.c, line 655. (gdb) b 657 Breakpoint 2 at 0x62f47: file ../../gcc-4.3-work/gcc/fortran/resolve.c, line 657. (gdb) display csym-value Disabling display 1 to avoid infinite recursion. 1: csym-value = (struct gfc_expr *) Cannot access memory at address 0xc04f (gdb) run 1234567.f90 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin9/4.3.0/f951 1234567.f90 1234567.f90:6.13: block data bd 1 Error: Unexpected BLOCK DATA statement at (1) 1234567.f90:7.10: common c 1 Error: Unexpected COMMON statement at (1) 1234567.f90:8.3: end block data bd 1 Error: Expecting END PROGRAM statement at (1) 1234567.f90:10.14: common /a_t/ c 1 Error: Unexpected COMMON statement at (1) Breakpoint 1, resolve_common_vars (sym=0x40d06d80, named_common=0 '\0') at ../../gcc-4.3-work/gcc/fortran/resolve.c:655 655 for (; csym; csym = csym-common_next) (gdb) display csym-value Disabling display 2 to avoid infinite recursion. 2: csym-value = (struct gfc_expr *) Cannot access memory at address 0x4c (gdb) c Continuing. Breakpoint 2, resolve_common_vars (sym=value temporarily unavailable, due to optimizations, named_common=0 '\0') at ../../gcc-4.3-work/gcc/fortran/resolve.c:657 657 if (csym-value || csym-attr.data) (gdb) display csym-value 3: csym-value = (struct gfc_expr *) 0x0 (gdb) c Continuing. Breakpoint 1, resolve_common_vars (sym=0x40d06f50, named_common=1 '\001') at ../../gcc-4.3-work/gcc/fortran/resolve.c:655 655 for (; csym; csym = csym-common_next) Disabling display 3 to avoid infinite recursion. 3: csym-value = (struct gfc_expr *) warning: Got an error handling event: Cannot access memory at address 0x4c. (gdb) c Continuing. Breakpoint 2, resolve_common_vars (sym=value temporarily unavailable, due to optimizations, named_common=1 '\001') at ../../gcc-4.3-work/gcc/fortran/resolve.c:657 657 if (csym-value || csym-attr.data) (gdb) c Continuing. Breakpoint 2, resolve_common_vars (sym=value temporarily unavailable, due to optimizations, named_common=1 '\001') at ../../gcc-4.3-work/gcc/fortran/resolve.c:657 657 if (csym-value || csym-attr.data) (gdb) display csym-value Disabling display 4 to avoid infinite recursion. 4: csym-value = (struct gfc_expr *) Cannot access memory at address 0xc04f (gdb) c Continuing. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xc04f resolve_common_vars (sym=value temporarily unavailable, due to optimizations, named_common=1 '\001') at ../../gcc-4.3-work/gcc/fortran/resolve.c:657 657 if (csym-value || csym-attr.data) (gdb) run 1234567890a.f90 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin9/4.3.0/f951 1234567890a.f90 1234567890a.f90:6.13: block data bd 1 Error: Unexpected BLOCK DATA statement at (1) 1234567890a.f90:7.10: common c 1 Error: Unexpected COMMON statement at (1) 1234567890a.f90:8.3: end block data bd 1 Error: Expecting END PROGRAM statement at (1) 1234567890a.f90:10.14: common /a_t/ c 1 Error: Unexpected COMMON statement at (1) Breakpoint 1, resolve_common_vars (sym=0x40d06d90, named_common=0 '\0') at ../../gcc-4.3-work/gcc/fortran/resolve.c:655 655 for (; csym; csym = csym-common_next) (gdb) c Continuing. Breakpoint 2, resolve_common_vars (sym=value temporarily unavailable, due to optimizations, named_common=0 '\0') at ../../gcc-4.3-work/gcc/fortran/resolve.c:657 657 if (csym-value || csym-attr.data) (gdb) display csym-value 5: csym-value = (struct gfc_expr *) 0x0 (gdb) c Continuing.
[Bug bootstrap/33200] install fails when trying to install fix-header since fix-header wasn't built
--- Comment #6 from bkorb at gnu dot org 2008-01-19 17:23 --- fixincludes has nothing to do with fixproto, other than both working with fixing up headers and having names that start with fix. So, I know little about it and even less about canadian crosses. fix-header also starts with fix, but has a different purpose: gcc/fix-header.c:/* fix-header.c - Make C header file suitable for C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200
[Bug fortran/34804] Porting aid: flag to disable BYTE, INTEGER*1 and INTEGER(KIND=1)
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:25 --- (In reply to comment #5) I do not have a strong feeling about it, and I would accept it if you propose to close this issue. [...] A -ffake-lack-of-integer-kind-1 option would have made it easier to resolve clashes in interfaces and similar issues. Yes, I do understand that it would be useful to you. The problem is: there are so many other similar options that could be useful, once in a lifetime, to someone, how do we choose which we implement? I suspect your problem is not very common (lack of kind=1), and that's not worth the cost: at some point, NEC might add kind=1, and our option becomes useless. Or, on some other platform, it might be another kind missing, or maybe the kind numbers are just different even though all integer types are really available, etc. I'm closing this PR as WONTFIX, as I think others would probably have the same opinion than mine, but please really feel free to bring the issue to the list if you think otherwise: we can always reopen the PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34804
[Bug target/34719] N_GSYM stabs warning with common blocks on Mac OS X Leopard
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:33 --- Reproduced on powerpc-apple-darwin9.1.0, both with -m32 and -m64. It happens with stabs, but not with dwarf. $ gfortran -gstabs test.f -g -m32 can't find atom for N_GSYM stabs nrange:G(0,5) in /var/tmp//cco3n4ye.o can't find atom for N_GSYM stabs nrange:G(0,5) in /var/tmp//cco3n4ye.o $ gfortran -gstabs test.f -g -m64 can't find atom for N_GSYM stabs nrange:G(0,5) in /var/tmp//ccHIBm2j.o can't find atom for N_GSYM stabs nrange:G(0,5) in /var/tmp//ccHIBm2j.o Marked as wrong-debug and assigned to target component. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|fortran |target Ever Confirmed|0 |1 GCC build triplet||*-apple-darwin89 GCC host triplet||*-apple-darwin89 GCC target triplet||*-apple-darwin89 Keywords||wrong-debug Last reconfirmed|-00-00 00:00:00 |2008-01-19 17:33:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34719
[Bug fortran/34854] Valid USE statement is rejected
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-19 17:17:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34854
[Bug fortran/34858] [4.3 Regression] ICE on invalid depending of the length of the source name
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-19 17:47 --- On x86-64 linux using valgrind: ==2713== Invalid read of size 8 ==2713==at 0x45C16C: resolve_common_vars (resolve.c:657) and ==2713== Invalid read of size 1 ==2713==at 0x45C230: resolve_common_vars (resolve.c:657) No segfault but doing something wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34858
[Bug fortran/34838] [4.3 Regression] ICE: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-01-19 17:48 --- I'm 95% certain this was caused by my patch. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-18 23:57:49 |2008-01-19 17:48:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
[Bug gcov-profile/34610] [4.3 regression] ICE with -fprofile-arcs -fopenmp
--- Comment #11 from jakub at gcc dot gnu dot org 2008-01-19 17:50 --- Subject: Bug 34610 Author: jakub Date: Sat Jan 19 17:49:46 2008 New Revision: 131653 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131653 Log: PR gcov-profile/34610 * tree-cfg.c (make_edges): Mark both outgoing edges from OMP_CONTINUE and from OMP_FOR as EDGE_ABNORMAL. * omp-low.c (expand_omp_for): Clear EDGE_ABNORMAL bits from OMP_FOR and OMP_CONTINUE outgoing edges. * tree-profile.c (tree_profiling): Return early if cfun-after_tree_profile != 0. Set cfun-after_tree_profile at the end. * omp-low.c (expand_omp_parallel): Copy after_tree_profile from cfun to child_cfun. * function.h (struct function): Add after_tree_profile bit. * gcc.dg/gomp/pr34610.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr34610.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.h trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-profile.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34610
[Bug c/34873] New: varasm.c:3387: warning: right shift count = width of type
/usr/bin/gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc -I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/. -I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/../include -I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/../libcpp/include -I/there.pentium4/toolchain_build_i686/gmp/include -I/there.pentium4/toolchain_build_i686/mpfr/include -I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/../libdecnumber -I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/../libdecnumber/bid -I../libdecnumber /there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/varasm.c -o varasm.o /there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/varasm.c: In function 'const_rtx_hash_1': /there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc/varasm.c:3387: warning: right shift count = width of type $ /usr/bin/gcc -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 20061115 (prerelease) (Debian 4.1.1-21) -- Summary: varasm.c:3387: warning: right shift count = width of type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i686-linux-uclibc GCC host triplet: i386-linux-gnu GCC target triplet: i686-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34873
[Bug gcov-profile/34610] [4.3 regression] ICE with -fprofile-arcs -fopenmp
--- Comment #12 from jakub at gcc dot gnu dot org 2008-01-19 17:56 --- 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=34610
[Bug tree-optimization/34864] array constants after inlining and staticification
--- Comment #2 from tbptbp at gmail dot com 2008-01-19 17:56 --- Gah. Seems that i've managed to hit another issue than what i was after with my simplistic testcase then, because in the original code there's no array anywhere - but static definitions - and i get calls to ldexpf (at runtime init) if use std::ldexp or ldexpf instead of straight ldexp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34864
[Bug fortran/34817] [4.3 regression] mixed-kind any and all intrinsics with expressions
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-19 18:04 --- Why is a Fortran FE bug considered P2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34817
[Bug c/34748] cc1 fails with Not a directory on trivial file
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-19 18:06 --- I'm closing because the original reporter could not reproduce. If you think this is in error, post a note here and I will reopen this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34748
[Bug fortran/34861] ICE in function with entry (and result?)
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-19 18:09 ---
It fails in array.c's
compare_bounds (gfc_expr *bound1, gfc_expr *bound2)
{
if (bound1 == NULL || bound2 == NULL
|| bound1-expr_type != EXPR_CONSTANT
|| bound2-expr_type != EXPR_CONSTANT
|| bound1-ts.type != BT_INTEGER
|| bound2-ts.type != BT_INTEGER)
gfc_internal_error (gfc_compare_array_spec(): Array spec clobbered);
which is called in turn in gfc_compare_array_spec as:
if (as1-type == AS_EXPLICIT)
for (i = 0; i as1-rank; i++)
{
if (compare_bounds (as1-lower[i], as2-lower[i]) == 0)
return 0;
which is called by resolve.c's resolve_entries:
else if (as fas gfc_compare_array_spec (as, fas) == 0)
gfc_error (Function %s at %L has entries with mismatched
array specifications, ns-entries-sym-name,
ns-entries-sym-declared_at);
The problem is therefore that SIZE(IDA2,NF3) does not evaluate at compile time
to an integer, but that this is expected as the type is AS_EXPLICIT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #12 from danglin at gcc dot gnu dot org 2008-01-19 18:33 --- I also see the ICE reported in comment #12 on hppa-unknown-linux-gnu. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug fortran/34861] ICE in function with entry (and result?)
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 18:42 --- Is really SIZE(IDA2,NF3) done on purpose? or is this a typo for SIZE(IDA2,3)? It does not change the ICE AFAICT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-19 18:36 --- Subject: Re: [4.3 regression] ICE with invalid variadic template functions I also see the ICE reported in comment #12 on hppa-unknown-linux-gnu. Sorry, comment #7. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug fortran/34858] [4.3 Regression] ICE on invalid depending of the length of the source name
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 19:47 ---
Further debug:
Breakpoint 2, resolve_common_blocks (common_root=0x40d02c50) at
../../gcc-4.3-work/gcc/fortran/resolve.c:692
692 {
(gdb) c
Continuing.
Breakpoint 3, resolve_common_vars (sym=0x40d06f50, named_common=1 '\001') at
../../gcc-4.3-work/gcc/fortran/resolve.c:652
652 {
(gdb) c
Continuing.
Breakpoint 4, resolve_common_vars (sym=0x40d06f50, named_common=1 '\001') at
../../gcc-4.3-work/gcc/fortran/resolve.c:655
655 for (; csym; csym = csym-common_next)
(gdb) print csym
$11 = value temporarily unavailable, due to optimizations
(gdb) print csym-common_next
Cannot access memory at address 0x64
and
Breakpoint 3, resolve_common_vars (sym=0x40d06f50, named_common=1 '\001') at
../../gcc-4.3-work/gcc/fortran/resolve.c:652
652 {
(gdb) print csym
$15 = value temporarily unavailable, due to optimizations
(gdb) print csym-common_next
Cannot access memory at address 0x64
(gdb) print sym-common_next
$16 = (struct gfc_symbol *) 0xc003
(gdb) print sym-common_next-common_next
Cannot access memory at address 0xc067
So it seems that the list in common_root-n.common-head is not properly
terminated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34858
[Bug middle-end/34874] New: struct reorg valgrind failure
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors) valgrind --tool=memcheck --db-attach=yes --error-limit=no /home/zadeck/gbB2/gcc/cc1 -fpreprocessed wo_prof_malloc_size_var.i -quiet -dumpbase wo_prof_malloc_size_var.i -mtune=generic -auxbase wo_prof_malloc_size_var -O3 -version -fipa-struct-reorg -fdump-ipa-all -fwhole-program -fipa-type-escape -fno-show-column -o wo_prof_malloc_size_var.s ==27272== Invalid read of size 8 ==27272==at 0xEACB12: htab_traverse_noresize (hashtab.c:747) ==27272==by 0xEACBA5: htab_traverse (hashtab.c:765) ==27272==by 0xBB65D2: check_cond_exprs (ipa-struct-reorg.c:3547) ==27272==by 0xBB6FD3: collect_data_accesses (ipa-struct-reorg.c:3830) ==27272==by 0xBB7281: reorg_structs (ipa-struct-reorg.c:3944) ==27272==by 0xBB72A0: reorg_structs_drive (ipa-struct-reorg.c:3967) ==27272==by 0x7B7476: execute_one_pass (passes.c:1118) ==27272==by 0x7B7656: execute_ipa_pass_list (passes.c:1187) ==27272==by 0xB98102: ipa_passes (cgraphunit.c:1340) ==27272==by 0xB98215: cgraph_optimize (cgraphunit.c:1387) ==27272==by 0x431628: c_write_global_declarations (c-decl.c:8079) ==27272==by 0x87CAB6: compile_file (toplev.c:1055) ==27272== Address 0x587A700 is 16 bytes inside a block of size 104 free'd ==27272==at 0x4C2191B: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==27272==by 0xEAC5D4: htab_expand (hashtab.c:550) ==27272==by 0xEACB94: htab_traverse (hashtab.c:763) ==27272==by 0xBB014D: free_accesses (ipa-struct-reorg.c:1674) ==27272==by 0xBB1192: free_data_struct (ipa-struct-reorg.c:2111) ==27272==by 0xBB20C8: remove_structure (ipa-struct-reorg.c:2353) ==27272==by 0xBB5268: safe_cond_expr_check (ipa-struct-reorg.c:3090) ==27272==by 0xEACB34: htab_traverse_noresize (hashtab.c:750) ==27272==by 0xEACBA5: htab_traverse (hashtab.c:765) ==27272==by 0xBB65D2: check_cond_exprs (ipa-struct-reorg.c:3547) ==27272==by 0xBB6FD3: collect_data_accesses (ipa-struct-reorg.c:3830) ==27272==by 0xBB7281: reorg_structs (ipa-struct-reorg.c:3944) -- Summary: struct reorg valgrind failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zadeck at naturalbridge dot com GCC host triplet: x86-64-linux-gni GCC target triplet: x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34874
[Bug middle-end/34874] struct reorg valgrind failure
--- Comment #1 from zadeck at naturalbridge dot com 2008-01-19 20:13 --- I am about to commit the last fix to p34400 and at least on my machine, this patch will make this failure disappear from the test suite. however the bug is still there if you look with valgrind. pinskia, i am sorry, i am about to leave for the day I want to close 34400 and i did not get to do a dup check to see if this was already there. kenny. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34874
[Bug libstdc++/34853] c++ runtime of basic_string has a bug in certain case
--- Comment #6 from pcarlini at suse dot de 2008-01-19 20:24 --- This is not a bug, and already spuriously reported: yu *cannot* use -D_GLIBCXX_FULLY_DYNAMIC_STRING, it's completely unsupported and not described anywhere in the documentation. You can only completely rebuild the library with --enable-fully-dynamic-string. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34853
[Bug fortran/34875] New: read into vector-valued section doesn't transfer any values
With compiler 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC) vector valued reads into an array don't appear to read in values. The test program prints out kind of qda =4 vector valued read failed 1 -100.00 1. 2 -100.00 2.000 3 -100.00 3.000 4 -100.00 4.000 5 -100.00 5.000 6 -100.00 6.000 7 -100.00 7.000 8 -100.00 8.000 9 -100.00 9.000 10 -100.00 10.000 subscript range read succeeded Dick Hendrickson Program QH0008 REAL(4) QDA(10) REAL(4) QDA1(10) integer, dimension(10) :: nfv1 = (/1,2,3,4,5,6,7,8,9,10/) qda1 = nfv1 qda = -100 print *, 'kind of qda = ', kind(qda) OPEN (UNIT=47, $ STATUS='SCRATCH', $ FORM='UNFORMATTED', $ ACTION='READWRITE') ISTAT = -314 REWIND (47, IOSTAT = ISTAT) IF ( ISTAT .NE. 0) THEN stop ' FIRST REWIND FAILED ' ENDIF ISTAT = -314 WRITE (47,IOSTAT = ISTAT) QDA1 IF ( ISTAT .NE. 0) THEN stop ' WRITE FAILED ' ENDIF ISTAT = -314 REWIND (47, IOSTAT = ISTAT) IF ( ISTAT .NE. 0) THEN stop ' SECOND REWIND FAILED ' ENDIF READ (47,IOSTAT = ISTAT) QDA(NFV1) IF ( ISTAT .NE. 0) THEN stop ' READ FAILED ' ENDIF IF ( ANY (QDA .ne. QDA1) ) then print *, 'vector valued read failed' DO I = 1,10 print *, I, qda(i), qda1(i) enddo else print *, 'vector valued read succeeded' endif ISTAT = -314 REWIND (47, IOSTAT = ISTAT) IF ( ISTAT .NE. 0) THEN stop ' THIRD REWIND FAILED ' ENDIF qda = -200 READ (47,IOSTAT = ISTAT) QDA(1:10) IF ( ISTAT .NE. 0) THEN stop ' READ FAILED ' ENDIF IF ( ANY (QDA .ne. QDA1) ) then print *, 'vector valued read failed' DO I = 1,10 print *, I, qda(i), qda1(i) enddo else print *, 'subscript range read succeeded' endif END -- Summary: read into vector-valued section doesn't transfer any values Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34875
[Bug fortran/34858] [4.3 Regression] ICE on invalid depending of the length of the source name
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-19 20:49 --- I can reproduce it on x86-64-linux. The first error valgrind shows is ==25404== Invalid read of size 8 ==25404==at 0x44361B: gfc_match_common (match.c:2756) ==25404==by 0x4522B9: match_word (parse.c:64) That line is: while (old_blank_common-common_next) The problem is essentially the same as for PR 33375: We have a half-deleted symbol somewhere. I believe the right spot is gfc_match_common; somewhere the error recovery does not properly delete a symbol or forgets a pointer = NULL. When trying to debug PR 33375 I never quite understood why it was failing. I had also the feeling that the patch in PR 33375 might not be fully right. My starting point would be gfc_match_common either with the current tree or with the patch of PR 33375 reverted. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-apple-darwin9 | GCC host triplet|i686-apple-darwin9 | GCC target triplet|i686-apple-darwin9 | Last reconfirmed|-00-00 00:00:00 |2008-01-19 20:49:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34858
[Bug fortran/34875] read into vector-valued section doesn't transfer any values
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.3 4.2.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-01-19 21:05:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34875
[Bug fortran/34875] read into vector-valued section doesn't transfer any values
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-19 21:06 --- I will have a look. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-19 21:05:19 |2008-01-19 21:06:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34875
[Bug fortran/34876] can't read zero length array sections
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-19 21:21 --- I will check into this one while I am at it as well -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-19 21:21:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34876
[Bug fortran/34876] New: can't read zero length array sections
The following program prints READ FAILED. A similar program with an unformatted, rather than direct access, file also fails. Dick Hendrickson Program qi0011 CHARACTER(9) BDA(10) CHARACTER(9) BDA1(10) INTEGER J_LEN ISTAT = -314 INQUIRE(IOLENGTH = J_LEN) BDA1 ISTAT = -314 OPEN (UNIT=48, $ STATUS='SCRATCH', $ ACCESS='DIRECT', $ RECL = j_len, $ IOSTAT = ISTAT, $ FORM='UNFORMATTED', $ ACTION='READWRITE') IF (ISTAT /= 0) stop BDA = 'x' WRITE (48,IOSTAT = ISTAT, REC = 10) BDA1(4:3) IF ( ISTAT .NE. 0) THEN stop ' WRITE FAILED ' ENDIF ISTAT = -314 READ (48,IOSTAT = ISTAT, REC=10) BDA(4:3) IF ( ISTAT .NE. 0) THEN stop ' READ FAILED ' ENDIF end -- Summary: can't read zero length array sections Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34876
[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-19 21:38 ---
From FSFChangelog.10:
Mon Feb 12 20:42:11 1996 Randy Smith [EMAIL PROTECTED]
* i386/x-osfrose (XCFLAGS{,_NODEBUG}): Remove $(SHLIB).
(XCFLAGS): New variable.
(libdir, mandir, bindir): Delete.
* i386/t-osf: New file.
* i860/paragon.h (STARTFILE_SPEC): Make gcc find crt0.o, not loader.
(LIB_SPEC): Remove /usr/lib.
* Makefile.in (TCFLAGS): New variable.
(GCC_CFLAGS): Add $(TCFLAGS).
(LIBGCC2_CFLAGS): Add -D for __GCC_FLOAT_NOT_NEEDED.
(libgcc1-test): Remove -nostdlib.
(float.h-cross): Don't give error #ifdef __GCC_FLOAT_NOT_NEEDED.
* enquire.c: Define __GCC_FLOAT_NOT_NEEEDED.
* configure (i[3456]86-*-osfrose): Add t-osf as tmake_file.
Nowadays we compile libgcc with it (for the very same reasons, i suspect):
[from gcc/Makefile.in]
# Options to use when compiling libgcc2.a.
#
LIBGCC2_DEBUG_CFLAGS = -g
LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS)
\
$(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) \
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED \
$(INHIBIT_LIBC_CFLAGS)
Current trunk still fails of you don't have a fenv.h or none of the respective
functions provided in fenv.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
[Bug c++/34219] gcc doesn't accept const members of variadic templates as const
--- Comment #3 from rbuergel at web dot de 2008-01-19 22:38 ---
another testcase:
templatetemplatetypename... T class Comp, typename... T void f( T... Value)
{
static_assert( CompT::value 0, );
}
template typename... T
struct Foo
{
static const int value=1;
};
int main()
{
fFoo( 2 );
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34219
[Bug fortran/34872] [4.3 Regression] Spurious error in snapshot of 01/18/08: Statement at (1) is not a valid branch target statement for the branch statement at (2)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34872
[Bug fortran/34817] [4.3 regression] mixed-kind any and all intrinsics with expressions
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-19 22:48 --- Subject: Bug 34817 Author: tkoenig Date: Sat Jan 19 22:47:47 2008 New Revision: 131660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131660 Log: 2008-01-19 Thomas Koenig [EMAIL PROTECTED] PR fortran/34817 PR fortran/34838 * iresolve.c (gfc_resolve_all): Remove conversion of mask argument to kind=1 by removing call to resolve_mask_arg(). (gfc_resolve_any): Likewise. 2008-01-19 Thomas Koenig [EMAIL PROTECTED] PR fortran/34817 PR fortran/34838 * gfortran.dg/any_all_1.f90: New test. * gfortran.dg/any_all_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/any_all_1.f90 trunk/gcc/testsuite/gfortran.dg/any_all_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34817
[Bug fortran/34838] [4.3 Regression] ICE: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-01-19 22:48 --- Subject: Bug 34838 Author: tkoenig Date: Sat Jan 19 22:47:47 2008 New Revision: 131660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131660 Log: 2008-01-19 Thomas Koenig [EMAIL PROTECTED] PR fortran/34817 PR fortran/34838 * iresolve.c (gfc_resolve_all): Remove conversion of mask argument to kind=1 by removing call to resolve_mask_arg(). (gfc_resolve_any): Likewise. 2008-01-19 Thomas Koenig [EMAIL PROTECTED] PR fortran/34817 PR fortran/34838 * gfortran.dg/any_all_1.f90: New test. * gfortran.dg/any_all_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/any_all_1.f90 trunk/gcc/testsuite/gfortran.dg/any_all_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
[Bug fortran/34817] [4.3 regression] mixed-kind any and all intrinsics with expressions
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-19 22:51 --- Fixed. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34817
[Bug fortran/34838] [4.3 Regression] ICE: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-01-19 22:52 --- Fixed. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS
--- Comment #13 from rsandifo at gcc dot gnu dot org 2008-01-20 00:05 --- Subject: Bug 34831 Author: rsandifo Date: Sun Jan 20 00:05:07 2008 New Revision: 131662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131662 Log: gcc/ PR target/34831 * config/mips/mips.md (divmode3): Use recip_condition when deciding whether to use reciprocal instructions. gcc/testsuite/ PR target/34831 * gcc.target/mips/pr34831.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/pr34831.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34831
[Bug target/34831] [4.3 Regression] ICE on gcc.dg/pr34233.c for MIPS
--- Comment #14 from rsandifo at gcc dot gnu dot org 2008-01-20 00:08 --- Fixed. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34831
[Bug libstdc++/34851] libstdc++ isn't parallel build safe
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-01-20 00:49 --- If confirmed, this is a serious regression. Is the make -j 4 command at toplevel in a newly configured clean build tree (not a build tree previously built with an older version of the sources, for example)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
[Bug libstdc++/34851] libstdc++ isn't parallel build safe
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 00:54 --- I built last night with revision 131650 with -j3 and it worked. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
[Bug libstdc++/34851] libstdc++ isn't parallel build safe
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 00:54 --- How did you configure GCC? How exactly did you invoke make? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
[Bug fortran/34861] ICE in function with entry (and result?)
--- Comment #4 from dick dot hendrickson at gmail dot com 2008-01-20 01:21 --- Subject: Re: ICE in function with entry (and result?) Sorry, basically a typo on my part. This is part of a large test suite and I cut it down to a small case. The variable NF3 has the value 3 and the value is set in a way that the compiler shouldn't be able to use the value in any optimizations. You can either replace the NF3 by 3, add NF3 to the argument list, or put the function in a module and declare NF3 above the contains. I try to run these small examples through another compiler as a check on my typing skills. This one clearly slipped by without the check. I hope it didn't cause too much trouble. Dick Hendrickson On 19 Jan 2008 18:42:13 -, dominiq at lps dot ens dot fr [EMAIL PROTECTED] wrote: --- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 18:42 --- Is really SIZE(IDA2,NF3) done on purpose? or is this a typo for SIZE(IDA2,3)? It does not change the ICE AFAICT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
[Bug c++/34877] New: Invalid conversion in lookup of variadic template
consider templatetypename T, typename... Args T max( T a, T b, Args... args
);
templatetypename T T max( T a)
{
return a;
}
templatetypename T, typename... Args T max( T a, T b, Args... args )
{
return a maxT(b, args...) ? a : maxT(b, args...);
}
#include iostream
int main()
{
std::cout max(3u, 2u, -1) std::endl;
}
Guess, what it prints: 4294967295
That means, the -1 is converted from signed int to unsigned int in the call to
max(2u, -1) [ with T = unsigned int, Args = ], which may not occur in a
template lookup! The call should be rejected as invalid by the compiler,
because it must not find a definition for max(unsigned int, int).
This happens only in the recursion of the variadic template, calling max(3u,
-1) is rejected as desired.
gcc version 4.3.0-20080111
--
Summary: Invalid conversion in lookup of variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34877
[Bug middle-end/34874] struct reorg valgrind failure
--- Comment #2 from zadeck at naturalbridge dot com 2008-01-20 01:43 --- actually the commit for 34400 does not seem to effect this bug. but the bug does have that nice heisenbug quality to it. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34874
[Bug c++/34877] Invalid conversion in lookup of variadic template
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 01:46 --- I think this is valid code as you specify maxT(b, args...) which means the type for the first template argument will be unsigned so it will convert the second argument to unsigned int. Isn't that correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34877
[Bug middle-end/34874] struct reorg valgrind failure
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 01:47 --- Sorry Kenny I forgot to say we already have a bug report about this, PR 34472. *** This bug has been marked as a duplicate of 34472 *** -- 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=34874
[Bug tree-optimization/34472] [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-20 01:47 --- *** Bug 34874 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #57 from zadeck at gcc dot gnu dot org 2008-01-20 01:49 --- Subject: Bug 34400 Author: zadeck Date: Sun Jan 20 01:48:25 2008 New Revision: 131670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131670 Log: 2008-01-19 Kenneth Zadeck [EMAIL PROTECTED] PR rtl-optimization/26854 PR rtl-optimization/34400 * ddg.c (create_ddg_dep_from_intra_loop_link): Do not use DF_RD-gen. * df.h (df_changeable_flags.DF_RD_NO_TRIM): New. (df_rd_bb_info.expanded_lr_out): New. * loop_invariant.c (find_defs): Added DF_RD_NO_TRIM flag. * loop_iv.c (iv_analysis_loop_init): Ditto. * df-problems.c (df_rd_free_bb_info, df_rd_alloc, df_rd_confluence_n, df_rd_bb_local_compute, df_rd_transfer_function, df_rd_free): Added code to allocate, initialize or free expanded_lr_out. (df_rd_bb_local_compute_process_def): Restructured to make more understandable. (df_rd_confluence_n): Add code to do nothing with fake edges and code to no apply invalidate_by_call sets if the sets are being trimmed. (df_lr_local_finalize): Renamed to df_lr_finalize. (df_live_local_finalize): Renamed to df_live_finalize. Modified: trunk/gcc/ChangeLog trunk/gcc/ddg.c trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/loop-invariant.c trunk/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #59 from zadeck at gcc dot gnu dot org 2008-01-20 01:49 --- Subject: Bug 26854 Author: zadeck Date: Sun Jan 20 01:48:25 2008 New Revision: 131670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131670 Log: 2008-01-19 Kenneth Zadeck [EMAIL PROTECTED] PR rtl-optimization/26854 PR rtl-optimization/34400 * ddg.c (create_ddg_dep_from_intra_loop_link): Do not use DF_RD-gen. * df.h (df_changeable_flags.DF_RD_NO_TRIM): New. (df_rd_bb_info.expanded_lr_out): New. * loop_invariant.c (find_defs): Added DF_RD_NO_TRIM flag. * loop_iv.c (iv_analysis_loop_init): Ditto. * df-problems.c (df_rd_free_bb_info, df_rd_alloc, df_rd_confluence_n, df_rd_bb_local_compute, df_rd_transfer_function, df_rd_free): Added code to allocate, initialize or free expanded_lr_out. (df_rd_bb_local_compute_process_def): Restructured to make more understandable. (df_rd_confluence_n): Add code to do nothing with fake edges and code to no apply invalidate_by_call sets if the sets are being trimmed. (df_lr_local_finalize): Renamed to df_lr_finalize. (df_live_local_finalize): Renamed to df_live_finalize. Modified: trunk/gcc/ChangeLog trunk/gcc/ddg.c trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/loop-invariant.c trunk/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c++/34877] Invalid conversion in lookup of variadic template
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 01:49 ---
This is accepted for the same reason why the code you have is accepted:
std::cout maxunsigned(3u, -1) std::endl;
If we write the second max as:
templatetypename T, typename... Args T max( T a, T b, Args... args )
{
return a max(b, args...) ? a : max(b, args...);
}
We get a correct rejection so this is not a bug.
t.cc: In function 'T max(T, T, Args ...) [with T = unsigned int, Args = int]':
t.cc:17: instantiated from here
t.cc:11: error: no matching function for call to 'max(unsigned int, int)'
t.cc:11: error: no matching function for call to 'max(unsigned int, int)'
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34877
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #58 from zadeck at naturalbridge dot com 2008-01-20 02:13 --- The three patches that have been committed seem to have brought this under control. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug middle-end/34878] New: fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
Bootstrap of revision 131654. Testsuite has one failure. Executing on host: /home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran -B/home/kargl/gcc/obj4x/ gcc/testsuite/gfortran/../../ /home/kargl/gcc/gcc4x/gcc/testsuite/gfortran.dg/vect/fast-math-pr33299.f9 0 -O2 -ftree-vectorize -fno-vect-cost-model -ftree-vectorizer-verbose=4 -fdump-tree-vect-stats -msse2 -ffast-math -L/home/kargl/gcc/obj4x/i386-unknown-freebsd8.0/./libgfortran/.libs -L/home/kargl/gcc/obj 4x/i386-unknown-freebsd8.0/./libgfortran/.libs -L/home/kargl/gcc/obj4x/i386-unknown-freebsd8.0/./libibe rty -lm -o ./fast-math-pr33299.exe(timeout = 300) PASS: gfortran.dg/vect/fast-math-pr33299.f90 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/kargl/gcc/obj4x/i386-unknown-freebsd8.0/./libgfortran/.libs:/home/ka rgl/gcc/obj4x/i386-unknown-freebsd8.0/./libgfortran/.libs:/home/kargl/gcc/obj4x/gcc:.:/home/kargl/gcc/o bj4x/i386-unknown-freebsd8.0/./libgfortran/.libs:/home/kargl/gcc/obj4x/i386-unknown-freebsd8.0/./libgfo rtran/.libs:/home/kargl/gcc/obj4x/gcc FAIL: gfortran.dg/vect/fast-math-pr33299.f90 execution test This is a -ffast-math issue as illustrated by 2 command lines. I copied the guilty program into tmp/ kargl[205] gfc4x -o z -O2 -ftree-vectorize -fno-vect-cost-model -ftree-vectorize r-verbose=4 -fdump-tree-vect-stats -fdump-tree-vect-stats -msse2 fast-math-pr332 99.f90 kargl[206] ./z kargl[207] gfc4x -o z -O2 -ftree-vectorize -fno-vect-cost-model -ftree-vectorize r-verbose=4 -fdump-tree-vect-stats -fdump-tree-vect-stats -msse2 -ffast-math fa st-math-pr33299.f90 kargl[208] ./z Illegal instruction (core dumped) -- Summary: fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org GCC host triplet: i386-unknown-freebsd8. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90
--- Comment #4 from kargl at gcc dot gnu dot org 2008-01-20 02:20 --- Just a quick note. The bug is not present on i386-*-freebsd, but is present on x86_64-*-*freebsd. This is most likely a 32-bit versus 64-bit pointer issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
[Bug fortran/34876] can't read zero length array sections
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-20 02:56
---
Here is a reduced case that illustrates the problem. Not specifying the
negative stride in either the read or write results in a failure. See the
commented lines.
program qi0011
character(9) bda(10)
character(9) bda1(10)
integer j_len
istat = -314
inquire(iolength = j_len) bda1
print '(j_len=,i2)',j_len
istat = -314
open (unit=48,
$ access='direct',
$ recl = j_len,
$ status=scratch,
$ iostat = istat,
$ form='unformatted',
$ action='readwrite')
bda = 'x'
bda1 ='123456789'
write (48, rec = 10) bda1(4:3:-1)! This works
c write (48, rec = 10) bda1(4:3) ! This fails
read (48, rec=10) bda(7:6:-1)! This works
c read (48, rec=10) bda(7:6) ! This fails
print '(10(a))', bda1
print '(10(a))', bda
end
Looking at -fdump-tree-original:
With stride given:
{
struct array1_unknown parm.9;
parm.9.dtype = 625;
parm.9.dim[0].lbound = 1;
parm.9.dim[0].ubound = 2;
parm.9.dim[0].stride = -1;
parm.9.data = (void *) (character(kind=1)[0:][1:9] *) bda1[3];
parm.9.offset = 0;
_gfortran_transfer_array (dt_parm.8, parm.9, 1, 9);
}
Without stride given:
{
struct array1_unknown parm.9;
parm.9.dtype = 625;
parm.9.dim[0].lbound = 1;
parm.9.dim[0].ubound = 0;
parm.9.dim[0].stride = 1;
parm.9.data = (void *) (character(kind=1)[0:][1:9] *) bda1[3];
parm.9.offset = -4;
_gfortran_transfer_array (dt_parm.8, parm.9, 1, 9);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34876
[Bug libstdc++/34851] libstdc++ isn't parallel build safe
--- Comment #4 from hjl dot tools at gmail dot com 2008-01-20 03:06 --- Revision 131671 passed the last failure point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
[Bug target/34879] New: __builtin_setjmp / __builtin_longjmp fails stack frame address with O2, O3 and Os
The test case is gcc.c-torture/execute/built-in-setjmp.c. The __builtin_setjmp stores Y+1 in the setjmp buffer. With -O0 the first instruction after the jmp does a sbiw r28, 1 that restores the original value, but for some reason, with higher optimization levels, this instruction is optimized away, leaving R28 pointing to the wrong address by one. The __builtin_setjmp code: if (__builtin_setjmp (buf)) 16a:ce 01 movwr24, r28 16c:01 96 adiwr24, 0x01 ; 1 Notice the increment here, before storing R28 16e:90 93 07 01 sts 0x0107, r25 172:80 93 06 01 sts 0x0106, r24 176:8f ee ldi r24, 0xEF ; 239 178:90 e0 ldi r25, 0x00 ; 0 17a:90 93 09 01 sts 0x0109, r25 17e:80 93 08 01 sts 0x0108, r24 182:ed b7 in r30, 0x3d ; 61 184:fe b7 in r31, 0x3e ; 62 186:f0 93 0b 01 sts 0x010B, r31 18a:e0 93 0a 01 sts 0x010A, r30 The __builtin_longjmp code: __builtin_longjmp (buf, 1); 10c:e0 91 08 01 lds r30, 0x0108 110:f0 91 09 01 lds r31, 0x0109 114:c0 91 06 01 lds r28, 0x0106 118:d0 91 07 01 lds r29, 0x0107 11c:80 91 0a 01 lds r24, 0x010A 120:90 91 0b 01 lds r25, 0x010B no decrement, R28 is used as is. -- Summary: __builtin_setjmp / __builtin_longjmp fails stack frame address with O2, O3 and Os Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmarques at grupopie dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34879
[Bug target/34210] ffs builtin calls undefined __ffshi2
--- Comment #4 from pmarques at grupopie dot com 2008-01-20 03:41 --- gcc.c-torture/execute/ffs-1.c and gcc.c-torture/execute/ffs-2.c also fail with this message. The test case gcc.c-torture/execute/builtin-bitops-1.c shows some more similar errors: builtin-bitops-1.c:(.text+0x6b4): undefined reference to `__popcounthi2' builtin-bitops-1.c:(.text+0x6ee): undefined reference to `__parityhi2' builtin-bitops-1.c:(.text+0x183e): undefined reference to `__clzhi2' I tried to add the suggested libgcc/config/avr/t-avr. It didn't work, and I don't know enough of gcc internals to understand what is going on. -- pmarques at grupopie dot com changed: What|Removed |Added CC||pmarques at grupopie dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34210
[Bug testsuite/34880] New: gcc.c-torture/execute/float-floor.c fails for targets with no 64-bit double type
gcc.c-torture/execute/float-floor.c depends on the target supporting an actual 64-bit double type. Since the type double in the avr target is actually a 32-bit float, the test always fails. -- Summary: gcc.c-torture/execute/float-floor.c fails for targets with no 64-bit double type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmarques at grupopie dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34880
[Bug target/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 04:09 --- What instructions is causing the crash? Are you testing on a machine which has SSE2 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug target/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2008-01-20 04:17 --- Subject: Re: fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math. On Sun, Jan 20, 2008 at 04:09:19AM -, pinskia at gcc dot gnu dot org wrote: What instructions is causing the crash? Are you testing on a machine which has SSE2 ? Nope. From FreeBSD's dmesg: CPU: AMD Athlon(tm) Processor (1208.75-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc0440800SYSCALL,b18,MMX+,3DNow!+,3DNow! SSE2 isn't one of the listed features. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug testsuite/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 04:19 --- There is the issue, the testcase should be not run on your computer as it is using SSE2. So this is a testsuite issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug c++/34862] [4.3 Regression] operator new placement varient with reference arg not accepted by g++ 4.3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|operator new placement |[4.3 Regression] operator |varient with reference arg |new placement varient with |not accepted by g++ 4.3 |reference arg not accepted ||by g++ 4.3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug bootstrap/34881] New: Bootstrap fails on building libstdc++: can't find file for: -lgcc_s.10.4
The bootstrap fails at stage 3 for an up-to-date repo The configure is: ../gcc/configure --prefix=/Users/ed/bin-4.3 --enable-languages=c,c++,objc,obj-c++,fortran,treelang I do a search in the build directory and find: MacOSX:~/obj-4.3 ed$ find . -name libgcc_s.10.4.\* ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.10.4.dylib ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.10.4.dylib ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.10.4.dylib So the library exists. I've tried setting DYLD_LIBRARY_PATH to one of these locations and still no dice. I've noticed three libraries: MacOSX:~/obj-4.3 ed$ ll powerpc-apple-darwin7.9.0/libgcc/*.dylib -rwxr-xr-x 1 ed ed 238008 19 Jan 23:35 powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib -rwxr-xr-x 1 ed ed9468 19 Jan 23:35 powerpc-apple-darwin7.9.0/libgcc/libgcc_s.10.4.dylib -rwxr-xr-x 1 ed ed9936 19 Jan 23:35 powerpc-apple-darwin7.9.0/libgcc/libgcc_s.10.5.dylib I don't know if this helps but the 10.4 *and* the 10.5 look fishy. Ed -- Summary: Bootstrap fails on building libstdc++: can't find file for: -lgcc_s.10.4 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: 3dw4rd at verizon dot net GCC build triplet: powerpc-apple-darwin7.9.0 GCC host triplet: powerpc-apple-darwin7.9.0 GCC target triplet: powerpc-apple-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34881
[Bug c++/34846] [4.3 regression] ICE on STL container iterator copy
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34846
[Bug fortran/34838] [4.3 Regression] ICE: Can't convert LOGICAL(1) to LOGICAL(1)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
