[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:51 ---
Hmm, but vectors are not consider as aggregates.
at the tree level right before optimization, we have:
A_6 = {1.299523162841796875e+0, 1.299523162841796875e+0,
1.299523162841796875e+0, 1.299523162841796875e+0};
# result_26 = V_MAY_DEF ;
__builtin_ia32_storeups (&result, A_6);
I would have thought that VECTOR_CST would be considered a constant and
propgrated into
__builtin_ia32_storeups and that we would have folded __builtin_ia32_storeups
at the tree level.
So I think there are two issues now, the first is that we don't constant prop
VECTOR_CST (if this is truely
a VECTOR_CST in store_ccp):
A_6 = {1.299523162841796875e+0, 1.299523162841796875e+0,
1.299523162841796875e+0, 1.299523162841796875e+0};
Lattice value changed to VARYING. Adding SSA edges to worklist.
And then we need a fold specific to x86 for __builtin_ia32_storeups, after that
it should just work.
--
What|Removed |Added
BugsThisDependsOn|14295 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 06:36 --- Another way to fix this would have copy-propagation for aggregates, see PR 14295. -- What|Removed |Added BugsThisDependsOn||14295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug middle-end/23125] [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 06:31 --- I Have a fix which I will posting in the morning. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23125
[Bug fortran/17740] ICE in gfc_trans_arrayfunc_assign, at fortran/trans-expr.c:2011
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-14 06:31 --- Fixed on mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17740
[Bug c/10719] invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 06:25 --- "as promoted according to the default argument promotions" is what makes this undefined by the way. char is promoted to int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug c/10719] invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-14 06:15 --- > I still say generating code that is not executable is a ridiculous way to > handle this ambiguity in the standard... You still don't get the point. Read again comment #2, the bottom line is that it's the best code the compiler can generate portably. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug target/23876] Accepts model on local variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 05:16 --- (In reply to comment #0) > if ((DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl)) >== FUNCTION_DECL) One more thing is that the DECL_CONTEXT at the point where we call the function to add the attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23876
[Bug target/23876] New: Accepts model on local variables
Take the following code:
void f(void)
{
int a __attribute__((model(small)));
}
We should reject the attribute but don't as of today even though the code in
ia64.c thinks it should be
rejected:
case VAR_DECL:
if ((DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl))
== FUNCTION_DECL)
&& !TREE_STATIC (decl))
{
error ("%Jan address area attribute cannot be specified for "
"local variables", decl);
*no_add_attrs = true;
}
--
Summary: Accepts model on local variables
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: minor
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23876
[Bug fortran/19358] [gfortran] Segfault with missing upper bound
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14 05:12 --- Subject: Bug 19358 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-14 05:12:12 Modified files: gcc/fortran: trans-array.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: assumed_dummy_1.f90 Log message: 2005-09-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/19358 * trans-array.c (gfc_trans_dummy_array_bias): correct the typo which uses dim[i].upper for lbound, rather than dim[i].lower. 2005-09-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/19358 * gfortran.fortran-torture/assumed_dummy_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.62&r2=1.63 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.553&r2=1.554 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assumed_dummy_1.f90.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6062&r2=1.6063 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19358
[Bug libstdc++/21674] basic_string vs debug_mode
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14 03:22 --- Subject: Bug 21674 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-14 03:22:17 Modified files: libstdc++-v3 : ChangeLog Added files: libstdc++-v3/testsuite/21_strings/basic_string/element_access/char: 21674.cc libstdc++-v3/testsuite/21_strings/basic_string/element_access/wchar_t: 21674.cc Log message: 2005-09-13 Jonathan Wakely <[EMAIL PROTECTED]> Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/21674 * testsuite/21_strings/basic_string/element_access/char/21674.cc: New. * testsuite/21_strings/basic_string/element_access/wchar_t/21674.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3104&r2=1.3105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/element_access/char/21674.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/element_access/wchar_t/21674.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug tree-optimization/23835] [4.1 Regression] case where gcc 4.1.0 -O3 compile takes two times longer than gcc 3.4.3 and 4.0.0
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-14 02:49 --- I have a patch for the alias portion of this -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2005-09-14 02:49:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug target/22068] Multiply-immediate opportunity
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22068
[Bug target/22068] Multiply-immediate opportunity
--- Additional Comments From dje at gcc dot gnu dot org 2005-09-14 01:28 --- Patch committed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22068
[Bug target/22068] Multiply-immediate opportunity
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14 01:12 --- Subject: Bug 22068 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-14 01:12:48 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md Log message: PR target/22068 * config/rs6000/rs6000.md (muldi3): Add mulli alternative. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9951&r2=2.9952 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&r1=1.408&r2=1.409 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22068
[Bug libstdc++/21674] basic_string vs debug_mode
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-05-21 14:13:55 |2005-09-14 01:02:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug libstdc++/23875] operator<<(short) should not call operator<<(long), etc.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-14 00:53:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23875
[Bug libstdc++/23875] New: operator<<(short) should not call operator<<(long), etc.
DR117 is not implemented in the same way of DR118: operator<<(short) calls operator<<(long), operator<<(unsigned short) calls operator<<(unsigned long), operator<<(int) calls operator<<(long), etc... I think the way we implemented DR118 is better (i.e., following the letter of the resolution, without calling other inserters/extractors), even if it adds more code for now (*), because allows the user to specialize, say, only operator<<(long), without affecting the other inserters. (*) Then, another project would clean-up and commonize the code in those bodies to, say, _M_insert and _M_extract. -- Summary: operator<<(short) should not call operator<<(long), etc. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23875
[Bug tree-optimization/23835] [4.1 Regression] case where gcc 4.1.0 -O3 compile takes two times longer than gcc 3.4.3 and 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 00:42 --- Hmm, in 4.0.0, we have about 6,800 SSA_NAMEs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug tree-optimization/23835] [4.1 Regression] case where gcc 4.1.0 -O3 compile takes two times longer than gcc 3.4.3 and 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 00:35 --- Hmm, in 4.0.0, we take a nice time at -O3. may_alias took only: tree alias analysis : 0.28 ( 3%) usr 0.01 ( 1%) sys 0.21 ( 2%) wall Total time: TOTAL : 8.55 1.04 9.75 -- What|Removed |Added Summary|case where gcc 4.1.0 -O3|[4.1 Regression] case where |compile takes two times |gcc 4.1.0 -O3 compile takes |longer than gcc 3.4.3 |two times longer than gcc ||3.4.3 and 4.0.0 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug tree-optimization/23835] case where gcc 4.1.0 -O3 compile takes two times longer than gcc 3.4.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 00:32 --- [20:26] < pinskia> but 38% are in compute_may_aliases [20:27] < pinskia> and 80% of that is in the loop which is going through all SSA_NAMES [20:27] < pinskia> this is in create_name_tags [20:28] < pinskia> it is O(n^2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c++/23180] [4.1 regression] Segfault on const initializer with bogus pointer arithmetics
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14 00:25 --- Subject: Bug 23180 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-14 00:25:02 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/init: struct2.C struct3.C Log message: PR c++/23180 * g++.dg/init/struct2.C: New test. * g++.dg/init/struct3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6061&r2=1.6062 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/struct2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/struct3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23180
[Bug c/10719] invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Additional Comments From appfault at hotmail dot com 2005-09-14 00:16 --- Ok, disregard comment 16, the issue I saw was the same as comment 0. Unfortunately, there was a '-w' sneakily in a 3rd-party makefile which hid the warning. Maybe I should open another zilla for warning you that '-w -Werror' is nonsensical. I still say generating code that is not executable is a ridiculous way to handle this ambiguity in the standard... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug tree-optimization/23835] case where gcc 4.1.0 -O3 compile takes two times longer than gcc 3.4.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 23:29 --- (In reply to comment #8) > We have at least 5 SSA_NAMEs, that is just huge. We have only V_MAY_DEFs > for .GLOBAL_VAR > and a TMT. Over half, 40,000 are scalars registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug libstdc++/22205] [4.1 Regression] errors debug mode on aix
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 23:21 --- It was discovered that to use string, you have to do all this magic with the debug mode that involves not using extern template and a bunch of the other linkage optimizations. There were some PRs about this. That's why systems without weak will no longer support the debug mode. That's not going to change. However, fixing this so that debug mode is not tested (marked unsupported) instead of failing seems reasonable. Working on a patch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
[Bug middle-end/23845] missed strength reduction costs performance
--- Additional Comments From tprince at computer dot org 2005-09-13 23:15 --- Created an attachment (id=9726) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9726&action=view) include files from libgfortran, required in build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug tree-optimization/23835] case where gcc 4.1.0 -O3 compile takes two times longer than gcc 3.4.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 23:13 --- We have at least 5 SSA_NAMEs, that is just huge. We have only V_MAY_DEFs for .GLOBAL_VAR and a TMT. This happens on all targets and not just ia64. -- What|Removed |Added GCC build triplet|ia64-unknown-linux-gnu | GCC host triplet|ia64-unknown-linux-gnu | GCC target triplet|ia64-unknown-linux-gnu | Summary|case where gcc 4.1.0 -O3|case where gcc 4.1.0 -O3 |compile takes two times |compile takes two times |longer than gcc 3.4.3, on |longer than gcc 3.4.3 |ia64| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug target/23153] [4.1 Regression] [meta-bug] code size regression from 4.0 on x86
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-13 23:09 --- Additional data: For the testcase in PR8361: size -f generate-3.4*.o textdata bss dec hex filename 297025 4 181 297210 488fa generate-3.4-4.0.o 318366 8 181 318555 4dc5b generate-3.4-4.1.o so about a 7% increase for 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23153
[Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 23:02 --- (In reply to comment #4) >/* We can't use regparm(3) for nested functions as these use > static chain pointer in third argument. */ >if (local_regparm == 3 && DECL_CONTEXT (decl) >&& !DECL_NO_STATIC_CHAIN (decl)) > local_regparm = 2; Instead of the above check, change it to: if (local_regparm == 3 && DECL_STRUCT_FUNCTION (fn)->static_chain_decl) local_regparm = 2; That should make it work and work better at that too because it would also help C++ functions which currently have the same issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
[Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-13 22:57 --- (In reply to comment #6) > Maybe a better check would be check in the decl's function struct's > field > static_chain_decl is set. I am not sure I understand what you mean here... Maybe adding a test like this TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL) should work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
[Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-13 22:49 --- Subject: Re: local calling convention not used when using -fwhole-program --combine On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu wrote: > > --- Additional Comments From dann at godzilla dot ics dot uci dot > edu 2005-09-13 22:36 --- > It looks like the -fwhole-program version of ClearLeft only passes the > first 2 arguments to the ClearInLine call in register, the 3rd one is > passed on the stack. > The reason for that is this code in i386.c:ix86_function_regparm: Maybe a better check would be check in the decl's function struct's field static_chain_decl is set. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
Re: [Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu wrote: --- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-13 22:36 --- It looks like the -fwhole-program version of ClearLeft only passes the first 2 arguments to the ClearInLine call in register, the 3rd one is passed on the stack. The reason for that is this code in i386.c:ix86_function_regparm: Maybe a better check would be check in the decl's function struct's field static_chain_decl is set. -- Pinski
[Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-13 22:41 --- Subject: Re: local calling convention not used when using -fwhole-program --combine On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu wrote: > > But the above just fixes the symptoms, it's probably not the correct > way to test for a nested function. DECL_NO_STATIC_CHAIN (decl) should be true for this function but why is it not? /* In a FUNCTION_DECL with a nonzero DECL_CONTEXT, indicates that a static chain is not needed. */ #define DECL_NO_STATIC_CHAIN(NODE) \ (FUNCTION_DECL_CHECK (NODE)->function_decl.regdecl_flag) -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
Re: [Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu wrote: But the above just fixes the symptoms, it's probably not the correct way to test for a nested function. DECL_NO_STATIC_CHAIN (decl) should be true for this function but why is it not? /* In a FUNCTION_DECL with a nonzero DECL_CONTEXT, indicates that a static chain is not needed. */ #define DECL_NO_STATIC_CHAIN(NODE) \ (FUNCTION_DECL_CHECK (NODE)->function_decl.regdecl_flag) -- Pinski
[Bug tree-optimization/23835] case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 22:37 --- The main function is huge, no wonder this takes more time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-13 22:36 --- It looks like the -fwhole-program version of ClearLeft only passes the first 2 arguments to the ClearInLine call in register, the 3rd one is passed on the stack. The reason for that is this code in i386.c:ix86_function_regparm: /* We can't use regparm(3) for nested functions as these use static chain pointer in third argument. */ if (local_regparm == 3 && DECL_CONTEXT (decl) && !DECL_NO_STATIC_CHAIN (decl)) local_regparm = 2; The test for nested functions is incorrect, in the -fwhole-program case DECL_CONTEXT (DECL_for_ClearLeft) is a TRANSLATION_UNIT_DECL so the test is true even though it should not be. Changing the code to: if (local_regparm == 3 && DECL_CONTEXT (decl) && (TREE_CODE (DECL_CONTEXT (decl)) != TRANSLATION_UNIT_DECL) && !DECL_NO_STATIC_CHAIN (decl)) local_regparm = 2; fixes the testcase. But the above just fixes the symptoms, it's probably not the correct way to test for a nested function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
[Bug libstdc++/23871] [4.0 Regression] iostream operator<<(int) uses || on integral operands
--- Additional Comments From pcarlini at suse dot de 2005-09-13 22:27 --- Yes, for 4.0.3 backporting only those bits would make sense. Thanks Janis for testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23871
[Bug tree-optimization/23835] case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 22:18 --- tree alias analysis : 5.56 (17%) usr 0.07 ( 8%) sys 5.66 (17%) wall 13812 kB ( 3%) ggc tree SSA incremental : 3.15 (10%) usr 0.01 ( 2%) sys 3.18 (10%) wall 8152 kB ( 2%) ggc hmm, we most likely just have too many VOPS but I don't know for sure yet. -- What|Removed |Added Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c++/23835] case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 22:09 --- Can you run with -ftime-report and attach the results? -- What|Removed |Added Keywords||compile-time-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c++/23835] case where gcc 4.1.0 -O3 compile takes 4 times longer than gcc 3.4.3, on ia64
--- Additional Comments From jaffe at broad dot mit dot edu 2005-09-13 22:03 --- We recompiled gcc 4.1.0 with checking disabled. The results are now less dramatic but still of concern: optimized 4.1.0 compiles take about twice as long as 3.4.3 compiles on the test case: Compile time in seconds -O0 -O1-O2 -O3 3.4.3 5.659 9.515 13.811 14.779 4.1.0 5.863 22.025 32.208 32.611 % gcc -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../configure --prefix=/wga1/gcc --enable-checking=release Thread model: posix gcc version 4.1.0 20050730 (experimental) -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug fortran/17740] ICE in gfc_trans_arrayfunc_assign, at fortran/trans-expr.c:2011
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13 21:46 --- Subject: Bug 17740 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-13 21:46:04 Modified files: gcc/fortran: ChangeLog trans-expr.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: generic_4.f90 Log message: 2005-09-13 Erik Edelmann <[EMAIL PROTECTED]> fortran/ PR fortran/17740 * trans-expr.c (gfc_trans_arrayfunc_assign): Check value of attr.elemental for specific function instead of generic name. testsuite/ PR fortran/17740 * gfortran.dg/generic_4.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.552&r2=1.553 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.63&r2=1.64 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6058&r2=1.6059 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/generic_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17740
[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 21:13 --- (In reply to comment #13) > Are there remaining issues with them? Yes, it does not work when configuring gcc with --with-cpu=pentium4 see PR 19161. -- What|Removed |Added BugsThisDependsOn||19161 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent
--- Additional Comments From fjahanian at apple dot com 2005-09-13 21:09 --- Hello, What is the status of Uros's patches in: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html Looks like they did not make it to FSF mainline? Are there remaining issues with them? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug c/23872] .t02.original dump weirdness
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-13 20:45 --- The fact that the dump is different depending on function order or compilation flags seems to point to either an uninitialized variable or some memory corruption. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
[Bug libgcj/23829] FreeBSD 5 support for libjava
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:32:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug rtl-optimization/23813] redundant register assignments not eliminated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:31 --- Confirmed, just the subreg issue. -- What|Removed |Added BugsThisDependsOn||15792, 18427, 23812 Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization, ra Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:31:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23813
[Bug c/23872] .t02.original dump weirdness
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:28 --- >int result = 0; <--- this line appears twice... That is because there is DECL_EXPR there and you just don't see it. This is all really a front-end issue. -- What|Removed |Added Severity|normal |minor Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
[Bug libstdc++/23871] [4.0 Regression] iostream operator<<(int) uses || on integral operands
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:26 --- Confirmed, a regression from 3.4.0. Just a note, 4.0 branch is frozen right now. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Known to fail||4.0.0 Known to work||3.4.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:26:41 date|| Summary|iostream operator<<(int)|[4.0 Regression] iostream |uses || on integral operands|operator<<(int) uses || on ||integral operands Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23871
[Bug middle-end/23872] New: .t02.original dump weirdness
Using gcc -O2 -fdump-tree-all -S
to compile:
int bar (void) { return 0;}
int foo (int reject) { int result = 0; return result;}
the .t02.original dump looks like:
;; Function bar (bar)
;; enabled by -tree-original
{
return 0;
}
;; Function foo (foo)
;; enabled by -tree-original
{
int result = 0;
int result = 0; <--- this line appears twice...
return result;
}
If the order of the 2 functions is reversed in the file then the dump looks
like:
;; Function foo (foo)
;; enabled by -tree-original
{
int result = 0;
<--- the return does not appear...
}
;; Function bar (bar)
;; enabled by -tree-original
{
return 0;
}
Using just -fdump-tree-original then the dump for "foo" always looks like the
second version.
--
Summary: .t02.original dump weirdness
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
[Bug libstdc++/23871] New: iostream operator<<(int) uses || on integral operands
This testcase from an IBM internal user:
#include
class mytest {
public:
mytest (int);
unsigned char operator|| (const mytest&) const;
friend unsigned char operator|| (const int&, const mytest&);
};
inline unsigned char operator|| (const int& lhs, const mytest& rhs)
{
std::cout << 1 << std::endl;
return (mytest)lhs || rhs;
}
fails with FSF 4.0 releases and the current 4.0 branch with:
elm3b11% /opt/gcc-nightly/4.0/bin/g++ -c bug.cc
/home/gcc-nightly/4.0-20050913/bin/../lib/gcc/powerpc64-linux/4.0.2/../../../../include/c++/4.0.2/ostream:
In member function ‘std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(int) [with _CharT = char,
_Traits = std::char_traits]Â’:
bug.cc:10: instantiated from here
/home/gcc-nightly/4.0-20050913/bin/../lib/gcc/powerpc64-linux/4.0.2/../../../../include/c++/4.0.2/ostream:194:
error: ISO C++ says that these are ambiguous, even though the worst conversion
for the first is better than the worst conversion
for the second:
/home/gcc-nightly/4.0-20050913/bin/../lib/gcc/powerpc64-linux/4.0.2/../../../../include/c++/4.0.2/ostream:194:
note: candidate 1: operator||(bool, bool)
bug.cc:8: note: candidate 2: unsigned char operator||(const int&, const mytest&)
This is due to code for operator<<(int) in std_ostream.h that uses || on
integral (not bool) operands, leading to the ambiguity between the built-in
|| operator and one defined in the testcase. It is a regression because
versions earlier than 4.0 failed to report the error.
The testcase passes on mainline starting with this patch from Paolo Carlini:
http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00424.html
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00726.html
I'm currently testing this part of that patch with the 4.0 branch:
* include/std/std_ostream.h (operator<<(short), operator<<(int)):
Adjust logic, as per the letter of the resolution of DR117 [WP].
--
Summary: iostream operator<<(int) uses || on integral operands
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23871
[Bug libstdc++/22205] [4.1 Regression] errors debug mode on aix
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED GCC build triplet||powerpc-ibm-aix5.2.0.0 GCC host triplet||powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22205
[Bug middle-end/23848] stack deallocation more efficient in 3.4
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:21 --- Confirmed. We should recognized that __builtin_stack_restore at the end of the function is not needed. This should be done while doing CFG exand. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |middle-end Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:21:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23848
[Bug libstdc++/22222] New Tru64 UNIX libstdc++ testsuite failures: #warning debug mode disabled due to lack of weak symbol support
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 20:20 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug libstdc++/22339] iconv functions not found by libstdc++v3 configure
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 20:19 --- Created an attachment (id=9723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9723&action=view) Checks for libiconv_ open and close functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22339
[Bug tree-optimization/23834] Not removing a SSA_NAME which is not used
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:18 --- Confirmed, I don't know how offten this shows up but what I have seen from compiling GCC, is that it does not show up at all. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:18:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23834
[Bug libstdc++/22339] iconv functions not found by libstdc++v3 configure
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 20:18 --- Is this in reference to _GLIBCXX_USE_ICONV? That is only useful for the codecvt specializations that use iconv. As of 4.0.0, this is in libstdc++-v3/include/ext/codecvt_specializations.h. Or is this in reference to runtime testing? That looks different. However, what you are suggesting is still easy to do. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22339
[Bug c++/23833] warning: "ignoring packed attribute on unpacked non-POD field" on templates
-- What|Removed |Added CC||nathan at gcc dot gnu dot ||org Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23833
[Bug target/23832] libjava build failure on sh64
-- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|sh64-unknown-linux-gnu |sh64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23832
[Bug middle-end/23830] inline optimization possibility - reorder compilation step
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:15 --- Confirmed. After IPA constant prop and before inlining, we need early optimizations, like DCE and constant prop. But that is it. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:15:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23830
[Bug fortran/19928] Reference of constant derived type component causes failure
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-13 20:11 --- *** Bug 17123 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||refson dot temp at ntlworld ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928
[Bug fortran/17123] Assertion fail in trans-const.c
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-13 20:11 --- This has been fixed on mainline by the patch for PR 19928. As noted there PR 17123 really seems to be a duplicate. *** This bug has been marked as a duplicate of 19928 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17123
[Bug tree-optimization/23855] Should not do loop header copying for inner loop
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug other/23870] continue hangs compiler (and whole computer!)
--- Additional Comments From fredrik at hederstierna dot com 2005-09-13 20:08 --- This bug only shows when you compile with -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23870
[Bug fortran/23862] Select Fortran source form appropriately for "-pipe"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:03 --- Confirmed. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||08/msg01290.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:03:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
[Bug driver/23861] Build failure due to "-pipe" not working with .F90 and .F95 files
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 20:03 --- Confirmed. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||08/msg01289.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-09-13 20:03:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
[Bug testsuite/23867] libstdc++ ABI testsuite should work for installed compiler testing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 19:59 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-13 19:59:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23867
[Bug middle-end/23868] builtin_apply uses wrong mode for multi-hard-register return values
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 19:58 --- Confirmed, note I did add this to the patch queue: http://www.dberlin.org/cgi-bin/patches.py -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-13 19:58:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug other/23870] continue hangs compiler (and whole computer!)
-- What|Removed |Added Component|c |other GCC host triplet|Linux Fedora Core3 kernel |i686-pc-linux-gnu |2.6.9 | Keywords||compile-time-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23870
[Bug c/23870] New: continue hangs compiler (and whole computer!)
When I try to compile any of these functions below, GCC 3.4.4 hangs the whole
computer! I was needed to reboot my Feodore Core3 system - severe memory leak?
I'm compiling on a Linux machine running Feodore Core3 kernel 2.6.9.
The compiler is arm-elf-gcc-3.4.4 compiled with binutils-2.16.1, newlib-1.13.0.
I compiled binutils like this:
"../../$BINUTILS_DIR/configure" --target="$TARGET" --prefix="$DEST"
--disable-nls
make LDFLAGS=-s all install
I compiled GCC like this:
"../../$GCC_DIR/configure" --enable-languages=c,c++,f77 --target="$TARGET"
--prefix="$DEST" --with-gnu-as --with-gnu-ld --with-newlib --disable-nls
make LDFLAGS=-s all-gcc all-target-libstdc++-v3 install-gcc
install-target-libstdc++-v3
The code that hangs the compiler looks like this:
(Simplified stupid code example just to show the error.)
void hang_compiler1(signed long long x)
{
while (1) {
if (x < 0)
continue;
}
}
void hang_compiler2(signed long long x)
{
for (;;) {
if (x < 0)
continue;
}
}
void hang_compiler3(signed long long x)
{
do {
if (x < 0)
continue;
} while (1);
}
--
Summary: continue hangs compiler (and whole computer!)
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fredrik at hederstierna dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: Linux Fedora Core3 kernel 2.6.9
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23870
[Bug middle-end/23869] Missed optimization with integer booleans when compiling for pentium and higher
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 19:52 --- Confirmed, a known issue. Related to PR 15911. and Really is caused by not doing PR 15357 late in the game. -- What|Removed |Added BugsThisDependsOn||15357, 15911 Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-09-13 19:52:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23869
[Bug target/23816] [4.1 Regression] ICE in extract_insn, at recog.c:2084
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-09-13 19:51 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23816
[Bug tree-optimization/21274] SSA Crash, reproducable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 19:48 --- Fixed on the mainline and since this is not a regression closing as fixed. Fixed with 4.1.0 20050802 and 4.1.0 20050714. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274
[Bug c/23869] New: Missed optimization with integer booleans when compiling for pentium and higher
On x86 architectures, when the target is -march=pentium or higher, the compiler
seems to replace (x || y) by ((x | y) != 0) too soon for optimizations to apply,
when x and y are integers.
Testcase (compiled with "gcc -O3 -march=something"):
typedef int T;
void g(T);
void f(T x, T y) {
if (x || y) return;
g(!x);
}
When the target is -march=i386, GCC is doing a great job and it is able to
replace !x by 1 when optimizing:
if (x || y) return;
g(1);
However, when the target is -march=pentium, the generated code is equivalent to:
if ((x | y) != 0) return; /* this is a bit better than previously */
g(x != 0);/* this is a lot worse */
If int is replaced by _Bool in the typedef, then the code is correctly
optimized: !x is replaced by 1 whatever the target. So the misoptimization is
triggered only when boolean values are passed through integers (quite a common
situation in C) and when some specific x86 architectures are targeted.
$ gcc-snapshot -v
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,obj-c++,treelang
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/gcc-snapshot/jre --enable-mpfr
--disable-werror i686-linux-gnu
Thread model: posix
gcc version 4.1.0 20050904 (experimental)
--
Summary: Missed optimization with integer booleans when compiling
for pentium and higher
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23869
[Bug tree-optimization/21274] SSA Crash, reproducable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
19:45 ---
Hmm, we are trying to gimplify a SCEV tree:
() ((long unsigned intD.7) {0, +, D.2009_8}_2 * 8)
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |tree-optimization
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-09-13 19:45:09
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274
[Bug middle-end/21274] SSA Crash, reproducable
-- What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274
[Bug c++/21274] SSA Crash, reproducable
-- What|Removed |Added GCC target triplet||x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:40 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22612] linking error while compiling ddd
-- What|Removed |Added GCC build triplet||sparc-sun-solaris2.9 GCC host triplet||sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22612
[Bug middle-end/23868] builtin_apply uses wrong mode for multi-hard-register return values
-- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||08/msg00129.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug libstdc++/22554] [4.1 Regression] pb_assoc header build and install overflows exec
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:35 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22554
[Bug middle-end/23868] New: builtin_apply uses wrong mode for multi-hard-register return values
apply_result_size uses reg_raw_mode for every register that is flagged with FUNCTION_VALUE_REGNO_P. However, reg_raw_mode is the mode to save a single hard register, while a return value can be held in multiple consecutive hard registers, and FUNCTION_VALUE_REGNO_P has to be true only for the first one of these. The problem can be observed at the moment (at least) for sh-elf as: FAIL: gcc.dg/builtin-apply4.c execution test -- Summary: builtin_apply uses wrong mode for multi-hard-register return values Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug libstdc++/22612] linking error while compiling ddd
-- What|Removed |Added Known to fail||3.4.0 Summary|linking error while |linking error while |compiling ddd with g++ 3.4.0|compiling ddd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22612
[Bug libstdc++/22612] linking error while compiling ddd with g++ 3.4.0
-- What|Removed |Added Known to work||3.3.2 Summary|linking error while |linking error while |compiling ddd with g++ 3.4.0|compiling ddd with g++ 3.4.0 |on solaris 9, | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22612
[Bug c++/21274] SSA Crash, reproducable
--- Additional Comments From callahan at sci dot utah dot edu 2005-09-13 19:32 --- Subject: Re: SSA Crash, reproducable This still crashes for me with the latest Ubuntu g++ build. g++ (GCC) 4.0.2 20050808 (prerelease) (Debian 4.0.1-4ubuntu6) The error is the same, but the crash is line 4186. Michael On Mon, 2005-05-02 at 16:36 +, callahan at sci dot utah dot edu wrote: > --- Additional Comments From callahan at sci dot utah dot edu 2005-05-02 > 16:36 --- > I suspect that this is an x86-64 bug. > > I have a different computer available to me here. I get the same result as > Dorit. Note that it appears to be the same Ubuntu beta version as the x86-64 > version. I recommend have someone run it on a recent x86-64 and if it's not a > problem there then just close out the bug. > > > [EMAIL PROTECTED]:/tmp$ g++-4.0 -msse2 -O3 -ftree-vectorize > -ftree-vectorizer-verbose=5 -c testcast.o testcast.cc > g++-4.0: testcast.o: No such file or directory > > testcast.cc:11: note: Alignment of access forced using peeling. > testcast.cc:11: note: LOOP VECTORIZED. > testcast.cc:26: note: not vectorized: pointer access is not simple. > testcast.cc:26: note: not vectorized: unhandled data ref: *D.1981_38 = 1.0e+0 > testcast.cc:21: note: vectorized 1 loops in function. > [EMAIL PROTECTED]:/tmp$ g++-4.0 --version > g++-4.0 (GCC) 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu7) > Copyright (C) 2005 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274
[Bug libstdc++/22612] linking error while compiling ddd with g++ 3.4.0 on solaris 9,
-- What|Removed |Added GCC target triplet||sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22612
[Bug c++/23278] SJLJ-exceptions broken
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:29 --- Moving to c++ component, maybe they can help him... -- What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23278
[Bug libstdc++/23734] [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list too long
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13 19:23 --- Subject: Bug 23734 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-13 19:22:52 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include: Makefile.am Makefile.in Log message: 2005-09-12 David Edelsohn <[EMAIL PROTECTED]> PR libstdc++/22554 PR libstdc++/23734 * include/Makefile.am (stamp-assoc): Install each subgroup of headers separately. * include/Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3103&r2=1.3104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/Makefile.am.diff?cvsroot=gcc&r1=1.106&r2=1.107 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/Makefile.in.diff?cvsroot=gcc&r1=1.144&r2=1.145 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23734
[Bug libstdc++/22554] [4.1 Regression] pb_assoc header build and install overflows exec
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13 19:23 --- Subject: Bug 22554 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-13 19:22:52 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include: Makefile.am Makefile.in Log message: 2005-09-12 David Edelsohn <[EMAIL PROTECTED]> PR libstdc++/22554 PR libstdc++/23734 * include/Makefile.am (stamp-assoc): Install each subgroup of headers separately. * include/Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3103&r2=1.3104 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/Makefile.am.diff?cvsroot=gcc&r1=1.106&r2=1.107 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/Makefile.in.diff?cvsroot=gcc&r1=1.144&r2=1.145 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22554
[Bug testsuite/23867] New: libstdc++ ABI testsuite should work for installed compiler testing
The libstdc++ ABI testsuite does not work when testing an installed compiler because: * abi.exp checks for "../src/.libs/libstdc++.so", which of course is not available with an installed compiler. * abi.exp requires baseline_file to be set in site.exp; with installed compiler testing, site.exp is generally created to set generic variables such as CC and CXX being the compilers to test, but not libstdc++-specific ones such as baseline_file. The testsuite should be arranged so that it can find the libstdc++ being used by an installed toolchain, and the logic to find the baseline file should be implemented within the testsuite. It would probably then no longer be necessary to restrict the ABI testing to native compilers only. Mark has asked for this PR to be assigned to him. -- Summary: libstdc++ ABI testsuite should work for installed compiler testing Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: mark at codesourcery dot com ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23867
[Bug fortran/21063] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-13 19:19 --- Just for the record: This was fixed by Richard Sandiford's patch for PR19239: http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00346.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug fortran/19358] [gfortran] Segfault with missing upper bound
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13 19:03 --- Subject: Bug 19358 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-13 19:02:57 Modified files: gcc/fortran: trans-array.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: assumed_dummy_1.f90 Log message: 2005-09-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/19358 * trans-array.c (gfc_trans_dummy_array_bias): correct the typo which uses dim[i].upper for lbound, rather than dim[i].lower. 2005-09-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/19358 * gfortran.fortran-torture/assumed_dummy_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39.2.7&r2=1.39.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.117&r2=1.335.2.118 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assumed_dummy_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.404&r2=1.5084.2.405 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19358
[Bug target/23816] [4.1 Regression] ICE in extract_insn, at recog.c:2084
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13 19:02 --- Subject: Bug 23816 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-13 19:02:05 Modified files: gcc: ChangeLog gcc/config/i386: sse.md Added files: gcc/testsuite/gcc.dg/vect: pr23816-1.c pr23816-2.c Log message: PR target/23816 * config/i386/sse.md (*ieee_sminv4sf3, *ieee_smaxv4sf3) (*ieee_sminv2df3, *ieee_smaxv2df3): New insn patterns. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9946&r2=2.9947 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/sse.md.diff?cvsroot=gcc&r1=1.24&r2=1.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/pr23816-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/pr23816-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23816
[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13 18:51 --- This is what we get one the mainline: .L4: movl(%ecx), %eax addl$4, %ecx movl%eax, (%edi,%edx,4) movl(%ebp,%edx,4), %eax movl%eax, (%esi,%edx,4) incl%edx cmpl%edx, %ebx jne .L4 Note the code in comment #4 has a target patch which improves this a little further: Index: i386.c === RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v retrieving revision 1.858 diff -u -p -r1.858 i386.c --- i386.c 6 Sep 2005 19:57:46 - 1.858 +++ i386.c 13 Sep 2005 18:49:44 - @@ -5273,6 +5273,10 @@ ix86_address_cost (rtx x) /* More complex memory references are better. */ if (parts.disp && parts.disp != const0_rtx) cost--; + + if (parts.scale != 1) +cost--; + if (parts.seg != SEG_DEFAULT) cost--; But since I don't have SPEC, I have not submitted the patch. Steven could you test this patch and submit it for me? ChangeLog (please make a better changelog): (ix86_address_cost): More complex is cheaper than anything else. -- What|Removed |Added Summary|[4.0/4.1 Regression]|[4.0 Regression] suboptimal |suboptimal use of fancy x86 |use of fancy x86 addressing |addressing modes|modes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug middle-end/23845] missed strength reduction costs performance
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13 18:29 --- Please provide a standalone testcase. gcc -O2 -S matmul_r8.c matmul_r8.c:31:20: error: config.h: No such file or directory matmul_r8.c:35:25: error: libgfortran.h: No such file or directory matmul_r8.c:49: error: syntax error before '*' token matmul_r8.c:50: warning: parameter names (without types) in function declaration matmul_r8.c:50: warning: data definition has no type or storage class matmul_r8.c:53: error: syntax error before '*' token ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-13 18:17 --- I'm still looking at this. My earlier comment about having fixed it on mainline was wrong; I thought it was a problem in altivec.h, but it's in the compiler itself and this problem never showed up on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
-- What|Removed |Added Attachment #9720 is|1 |0 patch|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions
--- Additional Comments From benjamin at smedbergs dot us 2005-09-13 16:34 --- Created an attachment (id=9720) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9720&action=view) Failure even with the latest patch I'm wrong. attachment 9035 fixes the compile errors in the main mozilla tree, but does not fix the errors in NSPR. Attached is the preprocessed source that's failing. This was compiled with -pipe -ansi -Wall -pthread -g -fno-inline -fPIC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[Bug fortran/23862] Select Fortran source form appropriately for "-pipe"
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:06 --- Created an attachment (id=9719) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9719&action=view) gcc-4.0.1-fortran-form-free.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
[Bug fortran/23862] New: Select Fortran source form appropriately for "-pipe"
When "-pipe" is used for .F90 and .F95 sources this warning is produced: Warning: Reading file '' as free form. The reason is the compiler cannot deduce the form from the file name suffix as in this case it's only known to the preprocessor. Here is an obvious patch following the approach used for .F/.fpp/.FPP and .f/.for/.FOR files. 2005-08-22 Maciej W. Rozycki <[EMAIL PROTECTED]> * fortran/lang-specs.h: Pass "-ffree-form" by default for Fortran 90 sources. Tested successfully in a native bootstrap for "i386-linux-gnu" for GCC 4.0.1. Inspection of sources shows it is needed for HEAD as well. -- Summary: Select Fortran source form appropriately for "-pipe" Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: macro at linux-mips dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
[Bug driver/23861] Build failure due to "-pipe" not working with .F90 and .F95 files
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:03 --- Created an attachment (id=9718) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9718&action=view) gcc-4.0.1-specs-pipe-suffix.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
[Bug driver/23861] New: Build failure due to "-pipe" not working with .F90 and .F95 files
Bootstrapping with Fortran enabled fails for 4.0.1 if "-pipe" is included
among flags passed through to library builds. It used to work for 4.0.0.
The reason is "libgfortran/intrinsics/f2c_specifics.F90", which is new to
4.0.1, and the "%|" operator used in the specs
("gcc/fortran/lang-specs.h") which does not expect numeric characters:
/home/macro/src/redhat/BUILD/gcc-4.0.1/obj/gcc/gfortran
-B/home/macro/src/redhat/BUILD/gcc-4.0.1/obj/gcc/ -B/usr/i386-linux/bin/
-B/usr/i386-linux/lib/ -isystem /usr/i386-linux/include -isystem
/usr/i386-linux/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -I.
-iquote../../../libgfortran/io -Wall -fno-repack-arrays -fno-underscoring
-pipe -O2 -fomit-frame-pointer -mtune=i486 -c
../../../libgfortran/intrinsics/f2c_specifics.F90 -fPIC -o
.libs/f2c_specifics.o
cc1: warning: command line option "-fno-repack-arrays" is valid for F95
but not for C
cc1: warning: command line option "-fno-underscoring" is valid for F95
but not for C
f951: error: unrecognized command line option "-95"
The following patch fixes the problem for me -- digits should be safe to
accept in file names, shouldn't they?
2005-08-22 Maciej W. Rozycki <[EMAIL PROTECTED]>
* gcc.c (do_spec_1): Accept numeric characters in file name
suffixes.
Tested successfully in a native bootstrap for "i386-linux-gnu" for GCC
4.0.1. Inspection of sources shows it is needed for HEAD as well.
--
Summary: Build failure due to "-pipe" not working with .F90 and
.F95 files
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: macro at linux-mips dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
