[Bug tree-optimization/23821] [4.0/4.1 Regression] DOM and VRP creating harder to optimize code
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-14 09:16 --- The testcase comes from gcc testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-11-14 09:27 --- Subject: Re: IVs with the same evolution not eliminated > They can happen due to macro expansion or C++ template inlining. And do they? > I wonder if PRE for scalar-evolutions would be useful ;) I would guess that this would be unnecessarily expensive. The only place where scev should give you some useful information should be for induction variables inside loops, in which case you can simply pass over the loop phi nodes and merge the variables with the same evolution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug c/24839] Mudflap not registering unreferenced globals
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||fche at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 10:35:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24839
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #7 from steven at gcc dot gnu dot org 2005-11-14 10:32 --- It would be more interesting to measure than think ;-) My experience is that when it is in Briggs' test suite, it usually also happens in actually useful code. But, only the numbers will tell :-) Zdenek is right, it's just a matter of comparing the evolutions of loop PHI nodes. Instrumenting the compiler to count how often this happens is half the work of implementing the optimization if it turns out to be useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug tree-optimization/18048] [4.0/4.1 Regression] mgrid loop performance regression with ivopts (register pressure)
--- Comment #22 from steven at gcc dot gnu dot org 2005-11-14 10:36 --- Yes, mesa is down. But is that related to this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-14 09:45 --- > > They can happen due to macro expansion or C++ template inlining. > And do they? If they can, they will do. Will this regularly happen? I think no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug treelang/24844] New: syntax error when running treelang testsuite
seen with trunk 20051112
mkdir testsuite/treelang
rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../src/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=expect ; export EXPECT ; \
TRANSFORM=s,$,-4.1,;; export TRANSFORM; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ../../src/gcc/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; fi ; \
PATH=`cd ..;${PWDCMD-pwd}`:$PATH; export PATH; \
gcc_extras="-B`cd ..;${PWDCMD-pwd}` -B`cd ..;${PWDCMD-pwd}`/treelang"; export
gcc_extras; \
runtest --tool treelang
/bin/sh: Syntax error: ";;" unexpected
make[4]: [treelang.check] Error 2 (ignored)
build/gcc/Makfile:
program_transform_name := s,$$,-4.1,;
not sure, if the error is in the added ;, or in treelang. The rest of the build
does work ok when configured with --program-suffix=-4.1
Matthias
--
Summary: syntax error when running treelang testsuite
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: treelang
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24844
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #18 from charlet at gcc dot gnu dot org 2005-11-14 13:06 --- Subject: Bug 18434 Author: charlet Date: Mon Nov 14 13:05:58 2005 New Revision: 106886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106886 Log: 2005-11-14 Robert Dewar <[EMAIL PROTECTED]> PR ada/18434 * osint-m.adb: Add pragma Elaborate_All for Osint Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/osint-m.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug other/24845] New: [gomp] make "-fopenmp" imply "-lgomp" when linking
When linking an OpenMP program it is necessary to explicitly supply the flag "-lgomp" on the command line; using "-fopenmp" is not sufficient. Would it be possible to make "-fopenmp" imply "-lgomp" when linking is performed, as most other compilers do? Or does this lead to problems? -- Summary: [gomp] make "-fopenmp" imply "-lgomp" when linking Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24845
[Bug target/24837] move dynamic linker names out of LINK_SPEC and into new DYNAMIC_LINKER
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:16 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 13:16:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24837
[Bug libgcj/24832] Modularization of Java libraries
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:17 --- Confirmed, I thought I saw this somewhere else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24832
[Bug libgcj/24832] Modularization of Java libraries
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 13:17:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24832
[Bug libgcj/24834] PersistentByteMap close() method is not catching Exception
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:18 --- Do you have a testcase for this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24834
[Bug java/24835] gcj accepts invalid code with static final variables
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 13:19 --- Confirmed, since this was a split off. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 13:19:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24835
[Bug target/24626] [4.1 Regression] internal compiler error: verify_flow_info failed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug rtl-optimization/24810] [4.1 Regression] mov + mov + testl generated instead of testb
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i686-pc-linux-gnu |i?86-*-*, x86_64-*-* Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24810
[Bug c++/12272] wrong error message using declaration shadows namespace
--- Comment #13 from reichelt at gcc dot gnu dot org 2005-11-14 13:24
---
Fixed on mainline by Mark's patch for PR20293:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00942.html
We now get:
PR12272.cc:10: error: reference to 'NS2' is ambiguous
PR12272.cc:5: error: candidates are: namespace NS2 { }
PR12272.cc:2: error: namespace NS1::NS2 { }
PR12272.cc:10: error: expected initializer before 'Y'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|NEW |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12272
[Bug target/24831] [4.1 regression] gthr-dce.h:77: error: expected expression before '{' token
--- Comment #1 from aoliva at gcc dot gnu dot org 2005-11-14 13:55 --- So is pthread_key_delete not declared in HP-UX's DCE headers? Is it actually the correct spelling, or have we always had a harmless typo in gthr-dce.h? It looks suspicious because pthread_keycreate doesn't have the second underscore. Anyhow, it seems to me like we could simply remove or comment out the pthread_key_delete line, since this function is not used anywhere. Could you please test such a change? Thanks, -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24831
[Bug middle-end/23195] [4.0 Regression] Using frexp with fabs produces negative result
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-14 13:56 --- For the record: I contacted the maintainer of the Linux man pages about the inaccurate description of frexp (see comment #6). A corrected version will be in man-pages-2.14. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23195
[Bug other/24845] [gomp] make "-fopenmp" imply "-lgomp" when linking
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-14 13:57 --- There is a problem - -static. If -fopenmp automatically adds -lgomp, then -static -fopenmp should add -lgomp -lrt -lpthread on some platforms, -lgomp -lpthread on others, maybe something different elsewhere. But specs are these days usually just compiled in into gcc/g++/gfortran driver and libgomp is configured separately. I'm not saying it is impossible to solve this, but it is certainly non-trivial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24845
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #3 from aoliva at gcc dot gnu dot org 2005-11-14 13:58 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 13:58:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug c++/24847] New: Instantiates un-called copy constructor
enum A{b,c};
template
struct foo {
explicitfoo(T& t);
explicitfoo(foo);
};
int main() {
int i;
foo v(i);
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In instantiation of `foo':
foo.cc:10: instantiated from here
foo.cc:5: error: invalid constructor; you probably meant `foo
(const foo&)'
The error arises because it thinks I am instantiating "foo(foo)", i.e. a copy constructor that is not taking a const reference argument.
But I'm not; I'm instantiating the plain constructor "foo(int&)".
The second constructor is intended to catch the case: "foo(foo", i.e. to convert an instance of foo with second argument zero to a foo with
any other second argument. It looks like when it is expanding the argument type
of the second constructor (i.e. "foo") that it is not just parsing the
resulting template but also applying the "valid copy constructor?" check for
that type. But as that second constructor is never called by anyone it the
compiler should just syntax check it (valid) and not semantic check it (invalid
for "foo(T, 0, A)" but valid for everything else).
Ivan
--
Summary: Instantiates un-called copy constructor
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #4 from aoliva at gcc dot gnu dot org 2005-11-14 14:19 --- Does this target actually support weak declarations? It appears to me that it only does when the assembler supports .weak, but even then, the linker will object to undefined weak symbols, which is something this test relies on. I suppose we'd have to mark it as an XFAIL on hpux, or use some alternate dg-require to indicate we need the ability to refer to undefined weak symbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug other/24829] [4.1 Regression] libobjc testsuite failures
--- Comment #5 from aoliva at gcc dot gnu dot org 2005-11-14 14:25 --- Hmm, this is tricky. I hadn't considered the case of having one of these functions defined with a symbol that does not have external linkage. I suppose we may have to take care of this case :-( even though it probably wouldn't have worked with the #pragma weaks. Or would it? Anyhow, please confirm how you configured the compiler. I'm particularly interested in what assembler you're using, and what `grep HAVE_GAS_WEAK gcc/auto-host.h' prints. Anyhow, one solution that comes to mind is to modify the __gthrw macro to declare not a function with the same symbol name, but rather a static const pointer to the original function. In a perfect world, we'd be able to define preprocessor macros within preprocessor macros, but without this ability, that's the best I can think of, short of adding explicit defines for some conditions. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 14:25:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24829
[Bug other/24829] [4.1 Regression] libobjc testsuite failures
--- Comment #6 from aoliva at gcc dot gnu dot org 2005-11-14 14:30 --- Another idea that's just occurred to me is to use a preprocessor macro to *refer* to the symbols throughout the source files. Say, __gthrw_(x) would expand to __gthrw_x when weakrefs are available, and to just x otherwise. Or something like that. I'll need the info requested above before deciding how to proceed, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24829
[Bug c++/24848] New: g++ issues parse error on constructor template specialization.
The following code generates a parse error:
struct Foo
{
template Foo();
};
template <> Foo::Foo()
{
}
--
Summary: g++ issues parse error on constructor template
specialization.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seefeld at sympatico dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24848
[Bug target/23731] [4.1 regression] [hppa] 475 test failures in libjava
--- Comment #4 from debian-gcc at lists dot debian dot org 2005-11-14 14:57 --- with the patch proposed in PR24348 down to 12. Matthias Running target unix FAIL: comment compilation from source FAIL: PR12416 -O3 compilation from bytecode FAIL: PR6729 -O3 compilation from source FAIL: SyncTest execution - source compiled test FAIL: SyncTest execution - gij test FAIL: SyncTest execution - bytecode->native test FAIL: SyncTest -O3 execution - source compiled test FAIL: SyncTest execution - gij test FAIL: SyncTest -O3 execution - bytecode->native test FAIL: Thread_Monitor execution - bytecode->native test FAIL: Throw_1 -O3 compilation from bytecode FAIL: Throw_2 compilation from bytecode === libjava Summary === # of expected passes3959 # of unexpected failures12 # of expected failures 10 # of untested testcases 23 -- debian-gcc at lists dot debian dot org changed: What|Removed |Added BugsThisDependsOn||24348 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23731
[Bug c++/24849] New: [gomp] ICE in expand_expr_real_1
The head of the gomp branch reports an ICE when trying to compile the snippet
below:
template struct Healpix_Map {
T *map;
int npix_;
void Import_nograde (const Healpix_Map &orig) {
#pragma omp parallel
{
int m;
#pragma omp for schedule (dynamic)
for (m=0; m &a, Healpix_Map &b) {
a.Import_nograde(b);
}
~/tmp>g++ -v -c -fopenmp test.cc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/gompcc/configure --quiet --prefix=/scratch/ugccgomp
--enable-languages=c++,f
ortran --with-gmp=/afs/mpa/data/martin/mygmp
Thread model: posix
gcc version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged
20051109)
/scratch/ugccgomp/libexec/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/cc1plus
-quiet -v -D_GNU_S
OURCE test.cc -quiet -dumpbase test.cc -mtune=pentiumpro -auxbase test -version
-fopenmp -o /tmp/ccCSV
0EZ.s
ignoring nonexistent directory
"/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch
/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-
gomp-20050608-branch
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-
gomp-20050608-branch/i686-pc-linux-gnu
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/../../../../include/c++/4.1.0-
gomp-20050608-branch/backward
/usr/local/include
/scratch/ugccgomp/include
/scratch/ugccgomp/lib/gcc/i686-pc-linux-gnu/4.1.0-gomp-20050608-branch/include
/usr/include
End of search list.
GNU C++ version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged
20051109) (i686-pc-linux-gn
u)
compiled by GNU C version 4.1.0-gomp-20050608-branch 20051109
(experimental) (merged 20051109)
.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: d8a8851eea700f35b0082059a490739d
test.cc: In member function 'void Healpix_Map::Import_nograde(const
Healpix_Map&) [with T = int]
':
test.cc:9: internal compiler error: in expand_expr_real_1, at expr.c:6681
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [gomp] ICE in expand_expr_real_1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24849
[Bug tree-optimization/24709] [4.1 Regression] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #6 from amacleod at redhat dot com 2005-11-14 15:18 --- Subject: Bug 24709 Author: amacleod Revision: 106865 Modified property: svn:log Modified: svn:log at Mon Nov 14 15:18:46 2005 -- --- svn:log (original) +++ svn:log Mon Nov 14 15:18:46 2005 @@ -1,24 +1,4 @@ - -In an attempt to prevent an infinite loop when verifying the immediate use links, an arbitrary limit was checked which is higher than one would ever expect to see. Unfortunately, the limit was set too low. the original value of 30,000 uses -was exceeded by this test case (It peaked at about 32,000+). The new limit should never be reached - + PR tree-optimization/24709 * tree-ssa-operands.c (verify_imm_links): Increase limit for infinite loop check. - - -Index: tree-ssa-operands.c -=== tree-ssa-operands.c(revision 106272) -+++ tree-ssa-operands.c(working copy) -@@ -2012,8 +2012,8 @@ - - prev = ptr; - ptr = ptr->next; -- /* Avoid infinite loops. */ -- if (count++ > 3) -+ /* Avoid infinite loops. 50,000,000 uses probably indicates a problem. */ -+ if (count++ > 5000) - goto error; - } - -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug c++/24849] [gomp] ICE in expand_expr_real_1
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-11-14 15:14 --- > gcc version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged 20051109) BTW, it appears as if the compiler datestamp is not correctly updated on the gomp branch (it says 20051109, but there have been commits to the branch after that date). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24849
[Bug target/24850] New: [4.1 regression] bootstrap failure on m68k-linux
trunk 20051112 fails to bootstrap on m68k-linux, maybe related to 22049
Matthias
stage1/xgcc -Bstage1/ -B/usr/lib/gcc-snapshot/m68k-linux-gnu/bin/ -c -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -fno-common -Wno-error -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include -o
build/gengtype-yacc.o gengtype-yacc.c
gengtype-yacc.c: In function 'yyparse':
gengtype-yacc.c:1738: error: insn does not satisfy its constraints:
(insn 1888 1120 1889 92 (set (reg:SI 1 %d1)
(sign_extend:SI (reg:HI 10 %a2 [orig:43 temp.310 ] [43]))) 65
{*68k_extendhisi2} (nil)
(nil))
gengtype-yacc.c:1738: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [build/gengtype-yacc.o] Error 1
--
Summary: [4.1 regression] bootstrap failure on m68k-linux
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24850
[Bug tree-optimization/24851] New: [4.1 Regression] f2c miscompilation
We miscompile yyparse of f2c to just
yyparse ()
{
...
:
save1 = yylval;
save2 = yyval;
save3 = yynerrs;
save4 = yyerrflag;
yynerrs = 0;
yyerrflag = 0;
yyerror (&"yacc stack overflow"[0]);
ret:;
yylval = save1;
yyval = save2;
yynerrs = save3;
yyerrflag = save4;
return 1;
}
which makes f2c pretty useless. This happens at -O1.
--
Summary: [4.1 Regression] f2c miscompilation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug tree-optimization/24851] [4.1 Regression] f2c miscompilation
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-14 15:27 --- Created an attachment (id=10233) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10233&action=view) testcase self-contained (but complete) yyparse function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug tree-optimization/24851] [4.1 Regression] f2c miscompilation
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-14 15:29 --- The problem is that with 31.ccp we introduce: : save1 = yylval; save2 = yyval; save3_92 = yynerrs; save4_94 = yyerrflag; yystate_95 = 0; yychar_96 = -1; yynerrs = 0; yyerrflag = 0; yyp_99 = &yys[536870911]; goto (yystack); ... # yychar_56 = PHI <-1(0), -1(13), yychar_61(31), ... # yystate_52 = PHI <0(0), yystate_2511(13), yystate_2467(31), ... # yyp_48 = PHI <&yys[536870911](0), yyp_129(13), yyp_49(31), ... yystack:; yyp_129 = yyp_48 + 8B; D.1934_130 = &yys[150]; if (yyp_129 >= &yys[150]) goto ; else goto ; :; yyerror (&"yacc stack overflow"[0]); goto (ret1); ... and later we will say that (yyp_129 >= &yys[150]) is always true because of this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug tree-optimization/24851] [4.1 Regression] f2c miscompilation
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug c++/24848] g++ issues parse error on constructor template specialization.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 --- *** This bug has been marked as a duplicate of 6259 *** -- 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=24848
[Bug c++/6259] Explicit instantiation of template constructor not allowed
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:38 --- *** Bug 24848 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||seefeld at sympatico dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6259
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-14 15:40 ---
Reduced testcase:
void abort(void);
int main()
{
int a[10], *p;
p = &a[-1];
if (p >= &a[9])
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24842] testsuite failure: gcc.dg/attr-weakref-1.c execution test
--- Comment #1 from aoliva at gcc dot gnu dot org 2005-11-14 15:41 --- Yeah, weakref support in the compiler is independent of .weakref support in the assembler. If .weakref is not available, the compiler will emulate that by always using the target symbol name, and deciding at the last minute whether to issue a .weak directive for the target or not. Will you please let me know what the excess errors are that you get, so that I can decide whether to delve into the issue myself or not? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24842
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-14 15:42 --- C++ frontend is fine. With C out of (.03.gimple) p = &a + -4B; D.1282 = &a + 36B; we (fold?) get (.10.cleanup_cfg) p = &a[1073741823]; D.1282 = &a[9]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-14 15:42 ---
Confirmed, short testcase:
int f(void)
{
int i = -1;
int a[10];
int *b = &a[2];
return &a[i]>=b;
}
int main(void)
{
if (f())
abort();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-14 15:42:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #17 from sje at cup dot hp dot com 2005-11-14 15:44 --- Eric, can you be more specific about what won't work? The regression testing with Zack's patch seemed to go fine and hand testing some cases looks OK too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-14 15:52 --- > Eric, can you be more specific about what won't work? The regression testing > with Zack's patch seemed to go fine and hand testing some cases looks OK too. Do you have a eh_dummy.o file for both -milp32 and -mlp64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-14 15:56 --- The problem here is that we are comparing in unsigned when we shoud be comparing in a signed type. This was introduced by: 2005-01-29 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/15791 * fold-const.c (extract_array_ref): New function. (fold): Fold comparisons between &a[i] and &a[j] or semantically equivalent trees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #19 from sje at cup dot hp dot com 2005-11-14 16:01 --- Yes, I checked the installed libgcc_eh.a (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain eh_dummy.o. I do not getting any warnings messages from ld when compiling and linking C or C++, with or without -mlp64 and with or without -shared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug tree-optimization/24709] [4.1 Regression] 4.1.0 HEAD crashes with enable-checking on huge switch statement
--- Comment #7 from amacleod at redhat dot com 2005-11-14 16:01 --- Subject: Bug 24709 Author: amacleod Date: Sun Nov 13 16:09:14 2005 New Revision: 106865 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106865 Log: PR tree-optimization/24709 * tree-ssa-operands.c (verify_imm_links): Increase limit for infinite loop check. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24709
[Bug c++/24852] New: [4.0 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
// compile this with -O3 to get segfault on 4.0.3,
// note the "warning: inline function 'A::~A()' used but never defined".
// 3.3 and 4.1 accept this code without warning.
// This bug was originally reported by Alexey Maximov <[EMAIL PROTECTED]>
struct A;
template
struct P
{
P() : p(0) { }
~P();
T *p;
};
template
P::~P()
{
delete p;
}
struct Q : private P
{
};
struct V
{
virtual ~V();
};
#pragma interface
struct A
{
V d;
Q p;
};
struct T
{
T ();
Q q;
};
T::T ()
{
}
--
Summary: [4.0 regression] Segmentation fault (infinite recursion
in cgraph_clone_inlined_nodes)
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24852
[Bug c++/24852] [4.0 regression] Segmentation fault (infinite recursion in cgraph_clone_inlined_nodes)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 --- This is a dup of bug 24248 which in turn is a dup of bug 22252. *** This bug has been marked as a duplicate of 22252 *** -- 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=24852
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-14 16:04 --- *** Bug 24852 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #20 from bugzilla-gcc at thewrittenword dot com 2005-11-14 16:07 --- (In reply to comment #19) > Yes, I checked the installed libgcc_eh.a > (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and > lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain > eh_dummy.o. I do not getting any warnings messages from ld when compiling and > linking C or C++, with or without -mlp64 and with or without -shared. Odd. We have the latest linker patch installed on our system (PHSS_33349) and applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still gave a warning. I guess 'struct eh_dummy;' didn't add enough symbolic information to the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us. Looking at Zack's patch, I don't see how eh_dummy.o would get added to libgcc_eh.a on gcc-3.4 without adding it to $libgcc2_eh_static_objs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:09 --- > Yes, I checked the installed libgcc_eh.a > (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and > lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain > eh_dummy.o. I do not getting any warnings messages from ld when compiling and > linking C or C++, with or without -mlp64 and with or without -shared. I must have dreamt... could you send to <[EMAIL PROTECTED]> the patched 3.4.x mklibgcc.in as well as the generated $objdir/gcc/libgcc.mk? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24850] [4.1 regression] bootstrap failure on m68k-linux
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24850
[Bug middle-end/24853] New: scheduling takes 40% or more time
For current mainline and Apple 3.3/4.0, the top pass in the profile is scheduling: 14.99 (42%) usr 4.32 (75%) sys 19.32 (46%) wall Note that at -O0, instead, it is global alloc : 1.06 (30%) usr 0.03 ( 5%) sys 1.09 (26%) wall but I doubt we can do much about it. -- Summary: scheduling takes 40% or more time Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin8.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #1 from bonzini at gcc dot gnu dot org 2005-11-14 16:22 --- Created an attachment (id=10234) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10234&action=view) file used for benchmarking -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-14 16:27 ---
Valid testcase (?):
void abort(void);
int main()
{
int a[10], *p, *q;
q = &a[1];
p = &q[-1];
if (p >= &a[9])
abort ();
return 0;
}
fold_stmt is doing the &a[0] + -4B to &a[1073741823] transformation. But it
somehow looks the C representation of &a[X] with pointer addition is not a
good idea. The C++ frontend makes out of the above
int main() ()
{
int a[10];
:
if (&a[9] <= &a[1073741824]) goto ; else goto ;
:;
abort ();
:;
return 0;
}
I'm unsure how to fix this without completely disabling the comparison
folding for anything but == and !=.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:28 --- > Odd. We have the latest linker patch installed on our system (PHSS_33349) and > applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still > gave > a warning. I guess 'struct eh_dummy;' didn't add enough symbolic information > to > the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us. It could be nice to compare the versions of 'ar' and 'ranlib' you have. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #23 from sje at cup dot hp dot com 2005-11-14 16:33 --- I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib when building GCC: ar --version GNU ar 2.16.91 20051103 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. ranlib --version GNU ranlib 2.16.91 20051103 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #24 from bugzilla-gcc at thewrittenword dot com 2005-11-14 16:59 --- (In reply to comment #23) > I build binutils 2.16 as part of my GCC build/test so I used that ar and > ranlib > when building GCC: We're using the system ar/ranlib. I built binutils-2.16 with _no_ patches but ar doesn't work: $ ./ar /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-14 17:03 --- Patch to avoid the situation posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00996.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-14 17:04 --- (In reply to comment #8) > Patch to avoid the situation posted. So this patch makes the real bug latent. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |11/msg00996.html| Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #25 from sje at cup dot hp dot com 2005-11-14 17:05 --- I build binutils with --disable-shared and using flex/bison instead of lex/yacc, that is probably why my ar works. I experimented with the use of the system ar/ranlib by just building eh_dummy.o and .a by hand and they look OK to me, I.e. they have a symbol table in them and thus should not get the warning message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #26 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:18 --- (In reply to comment #25) > I build binutils with --disable-shared and using flex/bison instead of > lex/yacc, that is probably why my ar works. I experimented with the use of > the > system ar/ranlib by just building eh_dummy.o and .a by hand and they look OK > to > me, I.e. they have a symbol table in them and thus should not get the warning > message. Ok, I have a working binutils-2.16 ar. And, binutils-2.16 ar creates a libgcc_eh.a that does not cause linker errors whereas HP as does _not_, with the _same_ eh_dummy.o file. Replace your libgcc_eh.a in your GCC tree with the version created by the system ar and I expect you'll see the same as me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug fortran/24828] Z and negative integers
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-14 17:25 --- Gfortran is doing the right thing with respect to a BOZ-literal-constant (other than a BOZ can only be used in a DATA statement per the F95 standard, so the code is invalid). If you look at the definition of BOZ in the standard, you'll find that a BOZ is converted to an integer of the largest available kind. In this case, it appears that integer(8) is the largest kind, so it's converted to that type and kind. The program assigns this integer(8) value to an integer(4), which explains the (int8) cast in the if statement. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #27 from sje at cup dot hp dot com 2005-11-14 17:26 --- In your last comment you mention the binutils ar, but later the binutils as. I cannot reproduce the problem by just using the binutils ar command but I can reproduce it using the binutils as (assembler) command. Which assembler are you using when you get the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug fortran/24828] Z and negative integers
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-14 17:29 --- Remove "wrong-code" keyword because gfortran is doing the correct thing with a BOZ-literal-constant with the exception of permitting BOZ-literal-constant in non-DATA statements. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code | Last reconfirmed|2005-11-12 23:53:06 |2005-11-14 17:29:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-14 17:29 --- Actually I was wrong on which patch caused/exposed this, This was caused by: 2005-05-14 Richard Guenther <[EMAIL PROTECTED]> * fold-const.c (div_if_zero_remainder): New function. (try_move_mult_to_index): Use it. div_if_zero_remainder uses the unsigned ness of the domain, which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #28 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:29 --- (In reply to comment #27) > In your last comment you mention the binutils ar, but later the binutils as. > I > cannot reproduce the problem by just using the binutils ar command but I can > reproduce it using the binutils as (assembler) command. Which assembler are > you using when you get the problem. Oops. "HP as" -> "HP ar". So, with a eh_dummy.o created from an eh_dummy.c with 'struct eh_dummy;', libgcc_eh.a created by HP ar gives me a linker warning and a libgcc_eh.a created by binutils-2.16 ar does not give me a linker warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #29 from sje at cup dot hp dot com 2005-11-14 17:31 --- In my comment I meant to say I could reproduce the problem with the HP assembler, but not with the GNU assembler (even if I use the GNU ar). I will test some more combinations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-14 17:31 --- div_if_zero_remainder assumes that the type of the agruments comming in are the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #30 from sje at cup dot hp dot com 2005-11-14 17:35 --- OK, I have reproduced it with GNU as (assembler) and HP ar. Should we bypass the whole issue by putting 'int __libgcc_eh_dummy;' in eh_dummy.o and use that as the 3.4 patch? I am willing to test and submit such a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-14 17:39 --- A regression hunt on powerpc-linux shows that the testcase from comment #8 starts failing with this large merge from the autovect branch, within the date range that the submitter identified: http://gcc.gnu.org/viewcvs?view=rev&rev=102356 r102356 | irar | 2005-07-25 12:05:07 + (Mon, 25 Jul 2005) | 83 lines A regression hunt on powerpc-linux using the testcase from comment #2 identified this patch; the original larger testcase fails at the same place: http://gcc.gnu.org/viewcvs?view=rev&rev=88404 r88404 | rakdver | 2004-10-01 18:26:37 + (Fri, 01 Oct 2004) | 9 lines * common.opt (ftree-loop-ivcanon): Enable by default. * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Enable complete loop unrolling. (canonicalize_induction_variables, tree_unroll_loops_completely): Reset scev info. * gcc.dg/tree-ssa/loop-1.c: Check that unrolling occurs already on tree level. The reghunts used "-O2 -ftree-loop-linear". Let me know if there are other options that could be used to find earlier failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #31 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:41 --- Sure. I don't understand how Zack's patch works but as long as we have a solution that works, fine by me. Eric might be interested in reviewing the patch too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #32 from sje at cup dot hp dot com 2005-11-14 17:46 --- Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to use the same eh_dummy.c file (struct eh_dummy;) as 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #33 from bugzilla-gcc at thewrittenword dot com 2005-11-14 17:51 --- (In reply to comment #32) > Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to > use the same eh_dummy.c file (struct eh_dummy;) as 3.4. 4.0.2 had the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-11-14 17:51 --- > Sure. I don't understand how Zack's patch works but as long as we have a > solution that works, fine by me. Eric might be interested in reviewing the > patch too. The misunderstanding has been cleared with Steve. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #10 from mark at codesourcery dot com 2005-11-14 17:59 --- Subject: Re: [4.1 Regression] ICE on pointer initialization with C99 initializer giovannibajo at libero dot it wrote: > --- Comment #9 from giovannibajo at libero dot it 2005-11-14 00:30 > --- > Mark, do you believe that the introduction of COMPOUND_LITERAL_EXPR in the C++ > frontend could be feasable for 4.1? It's possible, but I somewhat doubt it. I'm afraid we won't know all the places that need to change. I'd actually like to understand better why the middle-end is no longer able to handle CONSTRUCTORs as it used to; this was a change in the middle-end interface at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #2 from bonzini at gcc dot gnu dot org 2005-11-14 18:12 --- Top of the profile: 1051747.2325 cc1 cc1sched_analyze_insn 98121 6.7475 cc1 cc1free_deps 89078 6.1256 cc1 cc1bitmap_set_bit 63000 4.3323 cc1 cc1free_list 48690 3.3482 cc1 cc1alloc_INSN_LIST 39632 2.7254 cc1 cc1compute_global_livein 26382 1.8142 cc1 cc1free_INSN_LIST_list 25567 1.7582 cc1 cc1bitmap_bit_p -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #11 from dberlin at gcc dot gnu dot org 2005-11-14 18:14 --- Mark, the frontend is producing the address of a constructor, and nothing in the middle end used to be really analyzing static iniatlizers which is why it didn't break before (those that do try to look at them would give up in this case, but static vars analysis can't give up without destroying the results of the entire analysis) IMHO, this easier to fix in the frontend than in the middle end, by simply not producing &CONSTRUCTOR. What exactly is ADDRESSOF(CONSTRUCTOR) anyway? ISTM it should require a temporary variable to evaluate. However, we can't GIMPLIFY it and do that for you because it's a static initializer (and we don't gimplify those), so it's either teach *every single thing that wants to look at DECL_INITIAL for a static initializer* what ADDRESSOF(CONSTUCTOR) is supposed to mean, or make the frontend do something like split it into two variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug middle-end/24853] scheduling takes 40% or more time
-- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-14 18:15:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #10 from dberlin at gcc dot gnu dot org 2005-11-14 18:18 --- It probably did *nothing at all* before the merge. The ICE is not too hard to fix, i just haven't gotten to it yet I will hopefully soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-11-14 18:21 --- > For current mainline and Apple 3.3/4.0, the top pass in the profile is > > scheduling: 14.99 (42%) usr 4.32 (75%) sys 19.32 (46%) wall Is it the first scheduling pass? If so, we have a patch at AdaCore to limit its explosion. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-11-14 18:26 --- Subject: Re: scheduling takes 40% or more time >Is it the first scheduling pass? If so, we have a patch at AdaCore to limit >its explosion. > > Yes, it is. schedule_insns2 takes nothing. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #12 from mark at codesourcery dot com 2005-11-14 18:27 --- Subject: Re: [4.1 Regression] ICE on pointer initialization with C99 initializer dberlin at gcc dot gnu dot org wrote: > --- Comment #11 from dberlin at gcc dot gnu dot org 2005-11-14 18:14 > --- > Mark, the frontend is producing the address of a constructor, and nothing in > the middle end used to be really analyzing static iniatlizers which is why it > didn't break before (those that do try to look at them would give up in this > case, but static vars analysis can't give up without destroying the results of > the entire analysis) OK, that's a good summary of the key change. My point was simply that this is not something new the front-end started doing; it's been using this construct to mean "address of a temporary" for a long time. > IMHO, this easier to fix in the frontend than in the middle end, by simply not > producing &CONSTRUCTOR. I agree that, at least, the best fix is in the front-end. However, it probably won't be trivial to do. If the problem only affects static initializers, then we should probably try to localize the change to that code, rather than trying to introduce COMPOUND_LITERAL_EXPR throughout the front end at this point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug target/24842] testsuite failure: gcc.dg/attr-weakref-1.c execution test
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-14 18:35 --- In response to comment #1 regarding "excess errors", see the original description: I don't get any, I just get a call to abort when the test-program is executed (as you know, the "*** EXIT code 4242" is the status-wrapper's way of telling this). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24842
[Bug libgcj/24834] PersistentByteMap close() method is not catching Exception
--- Comment #2 from m4341 at abc dot se 2005-11-14 18:42 --- This was detected by opening the whole set of Java files in Eclipse (and not having any standard Java library at all selected). The close method stood out as an error. since it was declared to throw an exception in the classes AbstractInterruptibleChannel and FileChannel, but when used in PersistentByteMap it was not caught. I did this as an effort to try to strip out the parts I didn't need like AWT and then I encountered this. I hope that this is sufficient as an explanation to the bug. It doesn't seem to be critical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24834
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-14 18:47 --- Note we haveyyp = &yys[-1]; (where yys is an array) in the orginal testcase so that is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24853] scheduling takes 40% or more time
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-11-14 18:50 --- Created an attachment (id=10236) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10236&action=view) Patch (against 3.4.x) for controlling the explosion of the 1st scheduling pass. * params.def (PARAM_MAX_SCHED_READY_INSNS): New parameter, defaulting to 100. * params.h (MAX_SCHED_READY_INSNS): New macro. * haifa-sched.c: Include param.h. (queue_to_ready): Re-queue insns past MAX_SCHED_READY_INSNS for the next cycle during the first scheduling pass. (schedule_block): Delay insns past MAX_SCHED_READY_INSNS in the ready list for 1 cycle during the first scheduling pass. * doc/invoke.texi (--param): New parameter max-sched-ready-insns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24853
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-14 19:08 --- I have a fix for the only valid testcase (comment #7) here. -- pinskia at gcc dot gnu dot org changed: 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=24851
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-14 19:09 --- (In reply to comment #13) > I have a fix for the only valid testcase (comment #7) here. s/valid/defined/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24831] [4.1 regression] gthr-dce.h:77: error: expected expression before '{' token
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14
19:15 ---
Subject: Re: [4.1 regression] gthr-dce.h:77: error: expected expression before
'{' token
> So is pthread_key_delete not declared in HP-UX's DCE headers? Is it actually
> the correct spelling, or have we always had a harmless typo in gthr-dce.h? It
> looks suspicious because pthread_keycreate doesn't have the second underscore.
It's not declared, and as far as I can tell, not available in HP-UX 10.20.
pthread_keycreate is available. I don't have DCE threads installed under
HP-UX 11 but the functions are pthread_key_create and pthread_key_delete
for the posix threads library.
> Anyhow, it seems to me like we could simply remove or comment out the
> pthread_key_delete line, since this function is not used anywhere.
>
> Could you please test such a change? Thanks,
I'll test it when my current build completes.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24831
[Bug libgcj/24832] Modularization of Java libraries
--- Comment #2 from m4341 at abc dot se 2005-11-14 19:18 --- Created an attachment (id=10237) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10237&action=view) Proposal for the initial split. This is the initial split I did, and I must admit that it isn't thoroughly tested. There are one text file for each module I created. The text file contains an initial dependency description and a list of files incorporated in that module. In addition to this there is one Java-file with code modified to dynamically load the DefaultContentHandlerFactory that now resides in the AWT package from the URLConnection class. This wasn't necessary earlier. Beware that this is completely untested and I see it as a proposed modification. I REALLY wanted to break out the security classes too, since they have a significant size and aren't really needed on an embedded system. This is my minimal effort breakup - it could have been even better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24832
[Bug c++/24847] Instantiates un-called copy constructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:32 --- Comeau also rejects this. I don't understand why we are trying to instantiate foo::foo(foo) except to try to match the constructor, so maybe this is invalid after all. Some one else really needs to look at this. A weird testcase at best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24847
[Bug ada/24855] New: Missing stdarg.h in ada/raise.c for arm-rtems
>From Joel Sherril arm-rtems4.7 - C, C++ OK. Ada fails with this: ../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2 -Dinhibit_libc -fno-inline -fexceptions -DIN_RTS |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` \ -I. -I.. -I../.. -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../config -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../../include -I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/.. -I./../.. raise.c -o raise.o raise.c: In function 'db': raise.c:233: error: 'va_list' undeclared (first use in this function) raise.c:233: error: (Each undeclared identifier is reported only once raise.c:233: error: for each function it appears in.) raise.c:233: error: expected ';' before 'msg_args' raise.c:237: error: 'msg_args' undeclared (first use in this function) raise.c: In function 'get_region_description_for': raise.c:595: warning: pointer targets in assignment differ in signedness -- Summary: Missing stdarg.h in ada/raise.c for arm-rtems Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC target triplet: arm-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24855
[Bug tree-optimization/24840] [4.1 Regression] ICE process_assert_insertions_for, at tree-vrp.c:2807
--- Comment #8 from janis at gcc dot gnu dot org 2005-11-14 19:40 --- A regression hunt on powerpc-linux using -O2 with the testcase in comment #7 identified the following large patch: http://gcc.gnu.org/viewcvs?view=rev&rev=100478 r100478 | dnovillo | 2005-06-02 02:57:15 + (Thu, 02 Jun 2005) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24840
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14 19:40 --- Subject: Re: FAIL: gcc.dg/attr-weakref-1.c > Does this target actually support weak declarations? It appears to me that it > only does when the assembler supports .weak, but even then, the linker will > object to undefined weak symbols, which is something this test relies on. I > suppose we'd have to mark it as an XFAIL on hpux, or use some alternate > dg-require to indicate we need the ability to refer to undefined weak symbols. See PR 23387. The HP linkers and dynamic loaders don't like undefined weak symbols. GAS provides support for ".weak" using SOM secondary definition symbols on the 32-bit port. We use this under HP-UX 11 and it is good enough for most purposes. However, the semantics differ from that defined in the sysv ABI. The 64-bit support is a little better supported by the linker, but the dynamic linker still doesn't like undefined weak symbols. We don't support ".weak' under HP-UX 10 due to linker bugs. Either XFAIL or dg-require would be ok. If more tests are likely to be added, maybe dg-require would be better. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug c/24856] New: call to setlocale doesn't return expected value
-- Summary: call to setlocale doesn't return expected value Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tedoc2000 at gmail dot com GCC build triplet: powerpc-ibm-aix4.3.2.0 GCC host triplet: powerpc-ibm-aix4.3.2.0 GCC target triplet: powerpc-ibm-aix4.3.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug ada/24857] New: ada/s-auxdec.ads alignment issue for arm-rtems
>From Joel Sherrill:
Gcc on the head fails to compile arm-rtems4.7 at the following point
when Ada is enabled.
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-auxdec.adb -o
s-auxdec.o
s-auxdec.ads:286:13: alignment for "Aligned_Word" must be at least 4
The code is:
type Aligned_Word is record
Value : Short_Integer;
end record;
for Aligned_Word'Alignment use
Integer'Min (2, Standard'Maximum_Alignment);
I (Laurent) think Standard'Maximum_Alignment comes from ada/targtyps.c
get_target_maximum_alignment (void)
{
return BIGGEST_ALIGNMENT / BITS_PER_UNIT;
}
Joel confirmed that changing "Min (2" to "Min (4" enable this file to be
compiled, however my reading of the source would imply that BIGGEST_ALIGNMENT
is at least 32 on arm, so something else must be at play here, any idea?
--
Summary: ada/s-auxdec.ads alignment issue for arm-rtems
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
GCC target triplet: arm-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24857
[Bug c/24856] call to setlocale doesn't return expected value
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-14 19:48 --- Why do you think this is a GCC bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24856
[Bug ada/24855] Missing stdarg.h in ada/raise.c for arm-rtems
--- Comment #1 from joel at gcc dot gnu dot org 2005-11-14 19:48 --- Created an attachment (id=10238) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10238&action=view) Simple fix This is the simplest way to fix this bug. I just added an include of stdarg.h but I don't know if this is the right place or if it should be protected by some conditional compilation flags. It fixes the problem and arm-rtems4.7 compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24855
[Bug libfortran/21468] vectorizing libfortran
--- Comment #7 from jb at gcc dot gnu dot org 2005-11-14 19:48 --- Subject: Bug 21468 Author: jb Date: Mon Nov 14 19:48:31 2005 New Revision: 106898 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106898 Log: 2005-11-14 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/21468 * Makefile.am: Add -ftree-vectorize for compiling matmul. * m4/matmul.m4: Add const and restrict to type declarations as appropriate. * m4/matmull.m4: Likewise. * Makefile.in: Regenerated. * generated/matmul_*.c: Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_l16.c trunk/libgfortran/generated/matmul_l4.c trunk/libgfortran/generated/matmul_l8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/m4/matmul.m4 trunk/libgfortran/m4/matmull.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
