[Bug middle-end/17603] [4.0 Regression] cpowf and cpowl give wrong results

[steven at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Priority|P2  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603

[Bug middle-end/18270] New: internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146

[lucier at math dot purdue dot edu]

[descartes:~/programs/gambc40b11/lib] lucier% gcc -I../include -I.
-no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2
-fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common
-DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -D___GAMBCDIR=\"/usr/local/Gambit-C\"
-c _kernel.c -save-temps
gcc: unrecognized option `-no-cpp-precomp'
In file included from os.h:185,
 from _kernel.c:1557:
/usr/include/dlfcn.h:35:2: warning: #warning "You are using dlopen(), a legacy
API. Please use the Mach-O dylib loading APIs if at all possible"
_kernel.c: In function '___H__20___kernel':
_kernel.c:1584: internal compiler error: in tree_redirect_edge_and_branch, at
tree-cfg.c:4146
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[descartes:~/programs/gambc40b11/lib] lucier% gcc -v
Reading specs from /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin7.5.0/4.0.0/specs
Configured with: ../configure --prefix=/pkgs/gcc-mainline
--with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3
Thread model: posix
gcc version 4.0.0 20041102 (experimental)


The preprocessed input file is at

http://www.math.purdue.edu/~lucier/GNATS/GNATS-14/_kernel.i.gz

-- 
   Summary: internal compiler error: in
tree_redirect_edge_and_branch, at tree-cfg.c:4146
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.5.0
  GCC host triplet: powerpc-apple-darwin7.5.0
GCC target triplet: powerpc-apple-darwin7.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18270

[Bug c++/18077] [3.3/3.4/4.0 Regression] Members of anonymous namespaces get name mangled with first global variable instead of file name

[bugzilla at familie-koegl dot de]

--- Additional Comments From bugzilla at familie-koegl dot de  2004-11-02 07:22 
---
(In reply to comment #2)
> Using -z muldefs is beyond the scope of the C++ standard.
> There is no way to win for everyone here; some people really do not want the
> random names because they want predictability from the compiler.

Yeah, and that's exactly why I would have expected the <= 3.0.4 behavior: the 
randomness in names results from later GCC's incorporating the name of the 
first global symbol in the symbol names of the unnamed namespace entities. I 
really don't see how the new behavior is less random or more predictable. 
Especially when one can switch back to the old behavior by including a file 
containing nothing but 'namespace {}' via -include. So what was the rationale 
for having changed the behavior at all?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18077

[Bug libstdc++/17922] [3.3/3.4/4.0 regression] Spurious warnings about std::ios_base::seekdir

[bkoz at gcc dot gnu dot org]

-- 
   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=17922

[Bug libstdc++/17664] Crash in std::map when using _GLIBCXX_DEBUG with multithreading

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-02 05:48 ---
Mine.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17664

[Bug target/18269] -m64 -fPIC does not work on ppc-darwin

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-02 04:40:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18269

[Bug target/18269] New: -m64 -fPIC does not work on ppc-darwin

[pinskia at gcc dot gnu dot org]

Patch for the problem is here: 
.

-- 
   Summary: -m64 -fPIC does not work on ppc-darwin
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, patch
  Severity: normal
  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: powerpc-darwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18269

[Bug tree-optimization/16808] [4.0 Regression] verify_ssa failed: Missing definition for SSA_NAME

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-02 04:38 
---
New patch here: .

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16808

[Bug middle-end/17603] [4.0 Regression] cpowf and cpowl give wrong results

[coyote at coyotegulch dot com]

--- Additional Comments From coyote at coyotegulch dot com  2004-11-02 03:07 
---
The problem is broader.

For example, the Fortran 95 abs() intrinsic is also broken for x86_64 when
compiled with -O1, as illustrated by the following Fortran 95 program (testing
on my Opteron box with cvs-20041101 mainline):

program cabs
implicit none

! Program works if K = 8, breaks if K = 4
integer, parameter :: K = 4
complex(kind=K):: z, c
real(kind=K)   :: a1, a2

z = (2.0_K, 3.0_K) ** 2.0_K
c = z - (-5.0_K, 12.0_K)
a1 = abs(c)
a2 = sqrt(aimag(c) ** 2.0_K + real(c) ** 2.0_K)

write (*,*) 'z = ', z
write (*,*) 'c = ', c
write (*,*) 'a1 = ', a1
write (*,*) 'a2 = ', a2

end program cabs

Without optimization, I get the expected results:

$ gfortran -o runme cabs.f90
$ ./runme
 z =  ( -5.00,  12.0)
 c =  (  0.00,-9.5367432E-07)
 a1 =   9.5367432E-07
 a2 =   9.5367432E-07

With -O1, the program breaks:

$ gfortran -O1 -o runme cabs.f90
$ ./runme
 z =  ( -5.00,  12.0)
 c =  (  0.00,-9.5367432E-07)
 a1 =13.0
 a2 =   9.5367432E-07

With -O1 *AND* the unfairly maligned -ffast-math, the result is:

$ gfortran -O1 -ffast-math -o runme cabs.f90
$ ./runme
 z =  ( -5.00,  12.0)
 c =  (  0.00,-9.5367432E-07)
 a1 =   9.5367432E-07
 a2 =   9.5367432E-07

The ** operation works with all three compiles; the error appears to be in the
call to cabsf(). I don't believe the problem is cabsf() itself, because *both*
the unoptimized and -O1 versions call cabsf(). Using -ffast-math changes the
code substantially, avoiding the optimizer bug.

Note that my Pentium 4 system produces correct code, using -march=pentium4
-mfpmath=sse (to correspond with the x86_64's automatic use of SSE). The code is
very similar on the two architectures, save that the x86_64 uses the extended
registers (and gets abs() wrong, of course).

I *think* the wrong arguments are being passed to cabsf() on the x86_64 --  as
evidenced by the fact that the "wrong" output is abs(c), as if the embedded
subtraction did not exist. This *may* be the same problem as with the cpowl() in
your C example -- incorrect arguments as opposed to bas C lib functions.

I'm rather burned out tonight, but I thought I'd pass this along. If no one else
runs with this, I'll keep going. I'm learning a lot about GCC internals... ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603

[Bug debug/18242] [4.0 Regression] Dignostic for unsupported debug format is incorrect

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2004-11-02 02:44 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18242

[Bug debug/18242] [4.0 Regression] Dignostic for unsupported debug format is incorrect

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-02 02:41 
---
Subject: Bug 18242

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-02 02:41:37

Modified files:
gcc: ChangeLog toplev.c 

Log message:
PR debug/18242
* toplev.c (debug_type[_names): Remove "dwarf-1".

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6129&r2=2.6130
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&r1=1.929&r2=1.930



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18242

[Bug c++/18267] external linkage of functions declared in an anonymous namespace

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-11-02 01:53 ---
This point has been discussed in a number of PRs already. I maintain 
my position that gcc could invoke the as-if rule to give these functions 
internal linkage if they aren't taken as template parameters. Since 
there is no user-visible effect, this is well within the allowed range, 
and it would save us from a good number of the problems we've had over 
time with mangling of symbol names in anonymous namespaces. 
 
W. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug middle-end/16377] ICE in emit_move_insn at expr.c:2798

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-02 01:36 
---
No feedback in 3 months.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16377

[Bug other/16996] [meta-bug] code size improvements

[pinskia at gcc dot gnu dot org]

-- 
Bug 16996 depends on bug 14859, which changed state.

Bug 14859 Summary: [tree-ssa] integrate identical cases of a switch statement.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14859

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996

[Bug tree-optimization/14859] [tree-ssa] integrate identical cases of a switch statement.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-02 01:29 
---
Fixed also on the mainline.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.1.0   |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14859

[Bug other/17652] [metabug] GCC 4.1 pending patches

[pinskia at gcc dot gnu dot org]

-- 
Bug 17652 depends on bug 16447, which changed state.

Bug 16447 Summary: out of ssa generates bloated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16447

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652

[Bug tree-optimization/14859] [tree-ssa] integrate identical cases of a switch statement.

[pinskia at gcc dot gnu dot org]

-- 
Bug 14859 depends on bug 16447, which changed state.

Bug 16447 Summary: out of ssa generates bloated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16447

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14859

[Bug tree-optimization/16447] out of ssa generates bloated code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-02 01:29 
---
Fixed on the mainline now.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.1.0   |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16447

[Bug c++/18267] external linkage of functions declared in an anonymous namespace

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-02 01:22 
---
It is not exactly a G++ choice. This is what the ISO/ANSI C++ International 
Standard mandates. I suggest you to post a mail to the newsgroup 
comp.lang.c++.moderated or to comp.std.c++ to enquire an explanation for the 
rationale.

Also, notice you can try compiling your code with -ffunction-sections to let 
the linker drop the unused functions from the final executable. But remember 
that this option might regress the code performance a bit on x86 because it 
forces the compiler to generate slower code for each function call.

Alternatively, why don't you simply use "static"?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug c++/18267] external linkage of functions declared in an anonymous namespace

[TazForEver at dlfp dot org]

--- Additional Comments From TazForEver at dlfp dot org  2004-11-02 00:48 ---
i understand your point of view though i'm not happy with g++ behaviour. A
function with external linkage that can't be called seems like an oxymoron to
me. This makes my library very big. i had to mark a lot of functions inline to
get the behaviour i expect. But it is hard to manage. I have lo live with it.

Thanks for your explanation.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug tree-optimization/16447] out of ssa generates bloated code

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-02 00:23 
---
Subject: Bug 16447

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-02 00:23:05

Modified files:
gcc: ChangeLog tree-cfg.c tree-flow.h 
 tree-optimize.c tree-outof-ssa.c 

Log message:
2004-11-01  Andrew MacLeod  <[EMAIL PROTECTED]>

PR tree-optimization/16447
* tree-cfg.c (bsi_commit_one_edge_insert): Rename from
bsi_commit_edge_inserts_1, and make funtion external.  Return new block.
(bsi_commit_edge_inserts): Use renamed bsi_commit_one_edge_insert.
* tree-optimize.c (pass_cleanup_cfg_post_optimizing): Enable listing.
* tree-flow.h (bsi_commit_one_edge_insert): Extern decl.
* tree-outof-ssa.c (rewrite_trees): Don't commit edges here.
(same_stmt_list_p): New.  Return TRUE if edge is to be forwarded.
(identical_copies_p): New.  Return true is two copies are the same.
(identical_stmt_lists_p): New.  Return true if stmt lists are the same.
(analyze_edges_for_bb): New.  Determine how best to insert edge stmts
for a basic block.
(perform_edge_inserts): New.  Determine what to do with all stmts that
have been inserted on edges.
(remove_ssa_form):  Analyze and commit edges from here.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6125&r2=2.6126
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.96&r2=2.97
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.57&r2=2.58
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-optimize.c.diff?cvsroot=gcc&r1=2.60&r2=2.61
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gcc&r1=2.27&r2=2.28



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16447

[Bug c++/18267] external linkage of functions declared in an anonymous namespace

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-02 00:19 
---
GCC is not allowed to remove the definition of a function with external 
linkage. The fact that nobody will be able to call it because it is in an 
anonymous namespace it is irrelevant.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug c++/18267] external linkage of functions declared in an anonymous namespace

[TazForEver at dlfp dot org]

--- Additional Comments From TazForEver at dlfp dot org  2004-11-02 00:10 ---
of course. but if they are not ? they should be optimize, no ?
if g++ inlines three(), why does it remove three() global definition if it's
never used ?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug c++/18267] external linkage of functions declared in an anonymous namespace

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-01 23:52 
---
Names declared in anonymous namespaces do not get internal linkage by default. 
In fact, they can be used as template non-type arguments (names with internal 
linkage cannot be used in such contexts).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug libstdc++/18053] __gnu_cxx::hash_set uses return type of A::operator&() instead of A

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-01 23:27 ---

I think this is INVALID. I've attached a corrected test case for
set/map/hash_set/hash_map.

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18053

[Bug libstdc++/18053] __gnu_cxx::hash_set uses return type of A::operator&() instead of A

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-01 23:25 ---
Created an attachment (id=7455)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7455&action=view)
testcase


corrected test case, set/hash_set/map/hash_map.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18053

[Bug libstdc++/18185] Unhandled exceptions leak

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-01 22:47 
---
Subject: Bug 18185

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-01 22:47:34

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/libsupc++: eh_globals.cc 
Added files:
libstdc++-v3/testsuite/thread: 18185.cc 

Log message:
2004-11-01  Momchil Velikov  <[EMAIL PROTECTED]>

PR libstdc++/18185
* libsupc++/eh_globals.cc (get_globals_dtor): Delete unhandled
exceptions.
* testsuite/thread/18185.cc: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2742&r2=1.2743
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/libsupc++/eh_globals.cc.diff?cvsroot=gcc&r1=1.6&r2=1.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/thread/18185.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18185

[Bug rtl-optimization/18260] generated code uses memory beyond allocated stack frame.

[jtc at acorntoolworks dot com]

--- Additional Comments From jtc at acorntoolworks dot com  2004-11-01 22:45 
---
I seem to have missed the description of the "red-zone" when I read the ABI.  It's a 
neat optimization 
for leaf functions, but violates the principal of least suprise.

I have confirmed that the MySQL4 crashes that we were experiencing went away with 
-mno-red-zone.

I have done further investigation, and it appears that NetBSD/amd64's thread context 
switch code did 
not preserve the red-zone until recently.  This has been fixed in -current, and 
hopefully the changes 
will be pulled up to the release branch before 2.0 is released.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18260

[Bug libstdc++/18185] Unhandled exceptions leak

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-01 22:31 ---
Confirmed on gcc-3_4-branch as well. 

In on mainline, will fix for 3.4.4

-benjamin

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Known to fail||3.4.3
   Target Milestone|--- |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18185

[Bug tree-optimization/18232] [4.0 Regression] ../../gcc/gcc/tree-ssa-operands.c:1624: warning: 'bi$ptr2' is used uninitialized in this function

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-01 22:25 
---
Subject: Bug 18232

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-01 22:24:53

Modified files:
gcc: ChangeLog bitmap.h 

Log message:
2004-11-01  Andrew Pinski  <[EMAIL PROTECTED]>

PR bootstrap/18232
* bitmap.h (bmp_iter_end_p): Take a const pointer instead of a struct.
(EXECUTE_IF_SET_IN_BITMAP): Update call to bmp_iter_end_p.
(EXECUTE_IF_AND_COMPL_IN_BITMAP): Likewise.
(EXECUTE_IF_AND_IN_BITMAP): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6124&r2=2.6125
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/bitmap.h.diff?cvsroot=gcc&r1=1.39&r2=1.40



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18232

[Bug tree-optimization/18232] [4.0 Regression] ../../gcc/gcc/tree-ssa-operands.c:1624: warning: 'bi$ptr2' is used uninitialized in this function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 22:24 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|../../gcc/gcc/tree-ssa- |[4.0 Regression]
   |operands.c:1624: warning:   |../../gcc/gcc/tree-ssa-
   |'bi$ptr2' is used   |operands.c:1624: warning:
   |uninitialized in this   |'bi$ptr2' is used
   |function|uninitialized in this
   ||function


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18232

[Bug tree-optimization/18232] ../../gcc/gcc/tree-ssa-operands.c:1624: warning: 'bi$ptr2' is used uninitialized in this function

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 22:22 
---
Note I filed PR 18268 for the SRA problem.
I will now commit my patch.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18232

[Bug tree-optimization/18268] New: missed SRA of a block copy

[pinskia at gcc dot gnu dot org]

I think this is a regression from a previous version of 4.0.0

typedef struct
{
  void *ptr1, *ptr2;
  unsigned word;
  unsigned word_bit;
} bitmap_iterator;
void
get_call_expr_operands ()
{
  bitmap_iterator bi;
  bi.ptr1 = 0;
  bi.word = 0;
  bi.word_bit = 0;
start:
  {
bitmap_iterator bi1 = bi;
if (bi1.ptr1 != 0)
  goto start;
  }
}

-- 
   Summary: missed SRA of a block copy
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization, diagnostic
  Severity: normal
  Priority: P2
 Component: tree-optimization
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: powerpc-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18268

[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

[ovidr at users dot sourceforge dot net]

--- Additional Comments From ovidr at users dot sourceforge dot net  2004-11-01 
22:08 ---
The app uses many java.util.WeakHashMap s (usually with null values, just 
storing objects in the keys ie: map.put(object, null), if that matters).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[stevenb at suse dot de]

--- Additional Comments From stevenb at suse dot de  2004-11-01 21:22 ---
Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch statements 
with large # of cases


I don't know about jump threading, but edge splitting in such code
is very likely because we pre-split all critical edges for GVN-PRE
and I can imagine that in such interpreter-like code you'd have lots
of critical edges.  But maybe not...




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-11-01 21:18 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Mon, 2004-11-01 at 16:56 +, giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it  2004-11-01 16:55 
> ---
> > The effect for the test case of this PR is huge.
> > The effect on everything else (for example insn-attrtab) is not
> > measurable.
> 
> We have had many bug reports from users trying to compile interpret-like code 
> which is machine generated and is effectively made by giant switch statements. 
> Improving this PR will definitely make their code go faster.
> 
> In fact, if we are going to have a performance testsuite for GCC (as I asked to 
> the SC lately), I would surely propose to put such a testcase in there.
But how often are those codes going to trigger jump threading and
edge splitting.  Just having large switches isn't enough to cause us
to trip over the representational issues that are giving us so many
compile-time problems.

jeff



--- Additional Comments From law at redhat dot com  2004-11-01 21:18 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Mon, 2004-11-01 at 20:17 +, stevenb at suse dot de wrote:
> --- Additional Comments From stevenb at suse dot de  2004-11-01 20:17 ---
> Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch 
> statements with large # of cases
> 
> > I think it'll ultimately be cleaner to simply drop the labels after
> > we've built the CFG and associate an edge with each of the cases.
> 
> Yes, this is what I would really want to do, but I don't know if such
> a patch would be safe for GCC 4.0.
I think this can be done in a reasonably localized way.  We convert
to using edges just after building the CFG and we return to using
labels after we're done with the SSA path.  I don't expect we'll have
much (if any) code that has to handle both representations.


>   I suppose we could introduce a fake
> 'x' class tree with is really just a VEC(edge) plus a tree_common, and
> stuff that into SWITCH_LABELS (which would at that point not longer be
> an appropriate name of course ;-). 
Or break out case labels in a manner similar to what we do with other
nodes that have "interesting" fields.



>  The trouble is that we still need
> to recreate the labels for expand, that's the ugly part.
Na.  That's trivial.

jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-11-01 21:18 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Mon, 2004-11-01 at 16:56 +, giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it  2004-11-01 16:55 
> ---
> > The effect for the test case of this PR is huge.
> > The effect on everything else (for example insn-attrtab) is not
> > measurable.
> 
> We have had many bug reports from users trying to compile interpret-like code 
> which is machine generated and is effectively made by giant switch statements. 
> Improving this PR will definitely make their code go faster.
> 
> In fact, if we are going to have a performance testsuite for GCC (as I asked to 
> the SC lately), I would surely propose to put such a testcase in there.
But how often are those codes going to trigger jump threading and
edge splitting.  Just having large switches isn't enough to cause us
to trip over the representational issues that are giving us so many
compile-time problems.

jeff



--- Additional Comments From law at redhat dot com  2004-11-01 21:18 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Mon, 2004-11-01 at 20:17 +, stevenb at suse dot de wrote:
> --- Additional Comments From stevenb at suse dot de  2004-11-01 20:17 ---
> Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch 
> statements with large # of cases
> 
> > I think it'll ultimately be cleaner to simply drop the labels after
> > we've built the CFG and associate an edge with each of the cases.
> 
> Yes, this is what I would really want to do, but I don't know if such
> a patch would be safe for GCC 4.0.
I think this can be done in a reasonably localized way.  We convert
to using edges just after building the CFG and we return to using
labels after we're done with the SSA path.  I don't expect we'll have
much (if any) code that has to handle both representations.


>   I suppose we could introduce a fake
> 'x' class tree with is really just a VEC(edge) plus a tree_common, and
> stuff that into SWITCH_LABELS (which would at that point not longer be
> an appropriate name of course ;-). 
Or break out case labels in a manner similar to what we do with other
nodes that have "interesting" fields.



>  The trouble is that we still need
> to recreate the labels for expand, that's the ugly part.
Na.  That's trivial.

jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

[Hans dot Boehm at hp dot com]

--- Additional Comments From Hans dot Boehm at hp dot com  2004-11-01 20:44 ---
This would be a lot easier if libgcj had been built with something like -O2 -g.

Based on approximate manual matching of the object code to finalize.s, I think 
this is failing around line 452 of finalize.c on the line

new_fo -> fo_object_size = hhdr -> hb_sz;

It appears that hhdr is in %edx and is 1.  This can occur if the first argument 
to GC_register_finalizer_inner is a pointer to somewhere in the second page of 
a large object.  It should of course be a base pointer to an object, so this 
should be impossible.

I think the GC_register_finalizer_no_order call must be coming from 
maybe_remove_all_heavy(), which called remove_all_heavy, which was presumably 
inlined into _Jv_MonitorExit().  I see no other path to 
GC_register_finalizer_no_order().

That makes it appear that an object whose heavy-weight lock we are about to 
remove has previously been garbage collected.  That should be impossible since 
we previously registered our own finalizer for the object in question, and that 
acquires the lock bit in the lock hash table entry, as does remove_all_heavy.  
Thus the finalizer should have previously been run to completion, and all 
traces of the heavy lock should have been previously removed.

Are there places we add a finalizer to an existing object without checking for 
prior finalizers?  That might explain the problem.

We really need some more evidence to confirm this chain of reasoning.  A -g 
stack trace, and the values of the finalization proc and data (and the object 
the data pointer points to, if any) that are being passed to 
GC_register_finalizer_inner might help.  So would GC_find_header
(object_being_registered_address).  Assuming that's one, as expected, then 
*GC_find_header(object_being_registered_address - 4096) together with GC_gc_no 
would also be somewhat interesting.

Does this application use some flavor of weak references?  If so, which one?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266

[Bug libstdc++/17664] Crash in std::map when using _GLIBCXX_DEBUG with multithreading

[bkoz at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17664

[Bug libstdc++/17664] Crash in std::map when using _GLIBCXX_DEBUG with multithreading

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-01 20:42 ---
Created an attachment (id=7454)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7454&action=view)
proposed patch


Here's how you'd fix it by adding mutexes. I don't know if all of these are
necessary, because I haven't bothered to reproduce it. If you can test this
patch and see if it fixes your fail I'd appreciate it.

Is there a way to get this to fail without ACE?

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17664

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[stevenb at suse dot de]

--- Additional Comments From stevenb at suse dot de  2004-11-01 20:17 ---
Subject: Re:  [4.0 Regression] jump threading on trees is slow with switch statements 
with large # of cases

> I think it'll ultimately be cleaner to simply drop the labels after
> we've built the CFG and associate an edge with each of the cases.

Yes, this is what I would really want to do, but I don't know if such
a patch would be safe for GCC 4.0.  I suppose we could introduce a fake
'x' class tree with is really just a VEC(edge) plus a tree_common, and
stuff that into SWITCH_LABELS (which would at that point not longer be
an appropriate name of course ;-).  The trouble is that we still need
to recreate the labels for expand, that's the ugly part.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug c/18239] [4.0 Regression] ICE in get_parm_info with werid attribute

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 20:11 
---
Fixed, JSM thanks for fixing this.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18239

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-11-01 20:04 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Mon, 2004-11-01 at 19:35 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu  2004-11-01 19:34 
> ---
> Subject: Re:  [4.0 Regression] jump threading
>  on trees is slow with switch statements with large # of cases
> 
> Hi Steven,
> 
> > OK, then can you see if this hack helps...?
> 
> +   /* Step 4: Update the case label vector.  */
> +   TREE_VEC_LENGTH (label_vec) = n;
> +   for (i = 0; i < n; ++i)
> + {
> +   tree elt = TREE_VEC_ELT (label_vec, i);
> +   e = case_to_edge[i];
> +   CASE_LABEL (elt) = tree_block_label (e->dest);
> + }
> 
> Wow, this is barely safe.  You are assuming that the edge redirection
> is done by changing e->dest and that cfg.c:redirect_edge_succ_nodup
> does not remove e, which is actually the case because there is no
> existing edge from the block containing SWITCH_EXPR to the new basic
> block created by split_edge.
> 
> In any case, I agree this should work.  I'll be the second one to
> admit this is gross. :-)
I think it'll ultimately be cleaner to simply drop the labels after
we've built the CFG and associate an edge with each of the cases.

We'd still have the assumption that edge redirection happens by
changing e->dest, but I think that approach is otherwise reasonably
clean.

Probably the ugliest part of that approach is the need to have edges
in the switch statement.

The nice thing is this approach matches pretty well with what we've
done with simple gotos.

Jeff



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-01 20:02 ---

Will close unless update.

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627

[Bug c/18239] [4.0 Regression] ICE in get_parm_info with werid attribute

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-01 19:50 
---
Subject: Bug 18239

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-01 19:49:56

Modified files:
gcc: ChangeLog c-decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: parm-impl-decl-1.c parm-impl-decl-2.c 

Log message:
PR c/18239
* c-decl.c (get_parm_info): Allow FUNCTION_DECLs to appear amongst
parameter declarations.

testsuite:
* gcc.dg/parm-impl-decl-1.c, gcc.dg/parm-impl-decl-2.c: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6123&r2=2.6124
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.605&r2=1.606
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4530&r2=1.4531
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/parm-impl-decl-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/parm-impl-decl-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18239

[Bug libstdc++/18159] tr1/tuple is broken on darwin

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 19:41 
---
Fixed for sure this time, thanks.

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18159

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-11-01 19:34 ---
Subject: Re:  [4.0 Regression] jump threading
 on trees is slow with switch statements with large # of cases

Hi Steven,

> OK, then can you see if this hack helps...?

+   /* Step 4: Update the case label vector.  */
+   TREE_VEC_LENGTH (label_vec) = n;
+   for (i = 0; i < n; ++i)
+ {
+   tree elt = TREE_VEC_ELT (label_vec, i);
+   e = case_to_edge[i];
+   CASE_LABEL (elt) = tree_block_label (e->dest);
+ }

Wow, this is barely safe.  You are assuming that the edge redirection
is done by changing e->dest and that cfg.c:redirect_edge_succ_nodup
does not remove e, which is actually the case because there is no
existing edge from the block containing SWITCH_EXPR to the new basic
block created by split_edge.

In any case, I agree this should work.  I'll be the second one to
admit this is gross. :-)

Kazu Hirata


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug tree-optimization/16808] [4.0 Regression] verify_ssa failed: Missing definition for SSA_NAME

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 19:31 
---
I have a newer simpler patch.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords|patch   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16808

[Bug tree-optimization/18168] SPEC CPU2000 173.applu tree-loop-linear ICE

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-11-01 19:22 
---
Fixed

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18168

[Bug tree-optimization/17672] [4.0 Regression] ICE in build_classic_dist_vector

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-11-01 19:21 
---
Fixed

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17672

[Bug c++/18267] external linkage of functions declared in an anonymous namespace

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 19:05 
---
The main reason IIRC for this is because C++ and export templates (even though we 
don't implement 
export yet).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug c++/18064] gcc accepts different pointer types as covariant return types

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18064

[Bug c++/18267] New: external linkage of functions declared in an anonymous namespace

[TazForEver at dlfp dot org]

Here are 3 functions and a dummy main:

--begin--
int one() { return 1; }

static int two() { return 2; }

namespace
{
  int three() { return 3; }
}

int main()
{
  return one() + two() + three();
}
--end--

i was expecting that g++ handled two() and three() the same way, that
is to say generated object-code with internal linkage.
 
But g++ doesn't. three() has external linkage, just like one(). TCPPPL
says that an anonymous namespace is a namespace with a unique
name. Fine. Then why g++ does not optimize this ?  The previous
program returns 6. g++ outputs a definition for three(), but it is
obvious that two() and three() definitions are no longer needed
because they've been inlined. That's why g++ doesn't output a
definition for two(). In the end, i get a never-used definition of
three() ...

Thanks

>>> LC_ALL=C g++-3.4 -v
Reading specs from /usr/lib/gcc/powerpc-linux/3.4.2/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-multilib --disable-multilib powerpc-linux
Thread model: posix
gcc version 3.4.2 (Debian 3.4.2-3)

-- 
   Summary: external linkage of functions declared in an anonymous
namespace
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: TazForEver at dlfp dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18267

[Bug c++/18064] gcc accepts different pointer types as covariant return types

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-01 18:24 
---
Subject: Bug 18064

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-01 18:24:33

Modified files:
gcc: ChangeLog 
gcc/cp : ChangeLog search.c 
gcc/testsuite  : ChangeLog 
gcc/doc: extend.texi 
gcc/testsuite/g++.old-deja/g++.mike: p811.C 

Log message:
cp:
PR c++/18064
* search.c (check_final_overrider): Deprecate gnu covariant extension.
doc:
PR c++/18064
* doc/extend.texi (Deprecated Features): Deprecate G++ covariant
extension.
testsuite:
PR c++/18064
* g++.old-deja/g++.mike/p811.C: Avoid covariant extension.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6121&r2=2.6122
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4469&r2=1.4470
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/search.c.diff?cvsroot=gcc&r1=1.337&r2=1.338
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4529&r2=1.4530
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.227&r2=1.228
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.mike/p811.C.diff?cvsroot=gcc&r1=1.5&r2=1.6



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18064

[Bug c++/18064] gcc accepts different pointer types as covariant return types

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-11-01 18:22 
---
2004-11-01  Nathan Sidwell  <[EMAIL PROTECTED]>

PR c++/18064
* search.c (check_final_overrider): Deprecate gnu covariant extension.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18064

[Bug tree-optimization/18168] SPEC CPU2000 173.applu tree-loop-linear ICE

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-01 18:08 
---
Subject: Bug 18168

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-01 18:08:03

Modified files:
gcc: ChangeLog lambda-code.c tree-data-ref.c 
 tree-loop-linear.c tree-optimize.c 
Added files:
gcc/testsuite/gcc.dg/tree-ssa: ltrans-1.c ltrans-2.c ltrans-3.c 
   ltrans-4.c ltrans-5.c 

Log message:
2004-10-16  Daniel Berlin  <[EMAIL PROTECTED]>

Fix PR tree-optimization/17672
Fix PR tree-optimization/18168

* lambda-code.c (lambda_lattice_compute_base): Fix reversed
assert test.
(gcc_tree_to_linear_expression): Add extra to existing constant.
(depth_of_nest): Factor out function used in various places.
(gcc_loop_to_lambda_loop): Clean up code a little bit. No
functional changes.
(find_induction_var_from_exit_cond): Stop guessing, and just
get the right answer :).
(gcc_loopnest_to_lambda_loopnest): Remove useless pre-allocation.
Print out message about result of attempt to create perfect nest.
(lbv_to_gcc_expression): Add type argument, use it to do math
and induction variable creation.
(lle_to_gcc_expression): Ditto.
(lambda_loopnest_to_gcc_loopnest): Create new iv with same type as
oldiv. Pass type argument to lle_to_gcc_expression and
lbv_to_gcc_expression.
Reset number of iterations after transformation.
(perfect_nestify): Remove useless pre-allocation, and cleanup
a small amount.

* tree-data-ref.c (build_classic_dist_vector): Return false for
dependences completely outside of the loop nest we asked about.
(build_classic_dir_vector): Ditto.
(compute_data_dependences_for_loop): Only add dependence relations
inside the loop we asked about.

* tree-loop-linear.c (linear_transform_loops): Use DDR_SIZE_VECT.
Compute immediate uses.

* tree-optimize.c: Move linear_transform_loops to before ivcanon.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6120&r2=2.6121
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/lambda-code.c.diff?cvsroot=gcc&r1=2.16&r2=2.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-data-ref.c.diff?cvsroot=gcc&r1=2.14&r2=2.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-loop-linear.c.diff?cvsroot=gcc&r1=2.2&r2=2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-optimize.c.diff?cvsroot=gcc&r1=2.59&r2=2.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-4.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-5.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18168

[Bug tree-optimization/17672] [4.0 Regression] ICE in build_classic_dist_vector

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-01 18:08 
---
Subject: Bug 17672

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-01 18:08:03

Modified files:
gcc: ChangeLog lambda-code.c tree-data-ref.c 
 tree-loop-linear.c tree-optimize.c 
Added files:
gcc/testsuite/gcc.dg/tree-ssa: ltrans-1.c ltrans-2.c ltrans-3.c 
   ltrans-4.c ltrans-5.c 

Log message:
2004-10-16  Daniel Berlin  <[EMAIL PROTECTED]>

Fix PR tree-optimization/17672
Fix PR tree-optimization/18168

* lambda-code.c (lambda_lattice_compute_base): Fix reversed
assert test.
(gcc_tree_to_linear_expression): Add extra to existing constant.
(depth_of_nest): Factor out function used in various places.
(gcc_loop_to_lambda_loop): Clean up code a little bit. No
functional changes.
(find_induction_var_from_exit_cond): Stop guessing, and just
get the right answer :).
(gcc_loopnest_to_lambda_loopnest): Remove useless pre-allocation.
Print out message about result of attempt to create perfect nest.
(lbv_to_gcc_expression): Add type argument, use it to do math
and induction variable creation.
(lle_to_gcc_expression): Ditto.
(lambda_loopnest_to_gcc_loopnest): Create new iv with same type as
oldiv. Pass type argument to lle_to_gcc_expression and
lbv_to_gcc_expression.
Reset number of iterations after transformation.
(perfect_nestify): Remove useless pre-allocation, and cleanup
a small amount.

* tree-data-ref.c (build_classic_dist_vector): Return false for
dependences completely outside of the loop nest we asked about.
(build_classic_dir_vector): Ditto.
(compute_data_dependences_for_loop): Only add dependence relations
inside the loop we asked about.

* tree-loop-linear.c (linear_transform_loops): Use DDR_SIZE_VECT.
Compute immediate uses.

* tree-optimize.c: Move linear_transform_loops to before ivcanon.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6120&r2=2.6121
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/lambda-code.c.diff?cvsroot=gcc&r1=2.16&r2=2.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-data-ref.c.diff?cvsroot=gcc&r1=2.14&r2=2.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-loop-linear.c.diff?cvsroot=gcc&r1=2.2&r2=2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-optimize.c.diff?cvsroot=gcc&r1=2.59&r2=2.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-4.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ltrans-5.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17672

[Bug libstdc++/18159] tr1/tuple is broken on darwin

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-01 17:53 
---
Subject: Bug 18159

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-01 17:53:24

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/include/tr1: tuple 

Log message:
2004-11-01  Chris Jefferson  <[EMAIL PROTECTED]>

PR libstdc++/18159
* include/tr1/tuple (get(pair)): Change occurrences of _I to _Int.
(get(const pair)): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2741&r2=1.2742
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/tuple.diff?cvsroot=gcc&r1=1.2&r2=1.3



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18159

[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()

[ovidr at users dot sourceforge dot net]

-- 
   What|Removed |Added

 CC||Hans dot Boehm at hp dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266

[Bug libgcj/18266] New: SIGSEGV in GC_register_finalizer_inner ()

[ovidr at users dot sourceforge dot net]

gcc version 4.0.0 20041014 (experimental)

When I leave my gcj (4.0.0 20041014 - linux) app running for a few
days, it eventually crashes/locks up in what looks like an infinite
loop of SIGSEGVs (I did an strace on one process that was hung). I
then ran the app under gdb twice (and waited 2 days each time) and the
cause was the same each time. 

Original post:
http://gcc.gnu.org/ml/java/2004-10/msg00134.html

Response:
http://gcc.gnu.org/ml/java/2004-10/msg00142.html

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1116179376 (LWP 22238)]
0x40523321 in GC_register_finalizer_inner () from ./lib/libgcj.so.6
(gdb) bt
#0  0x40523321 in GC_register_finalizer_inner () from ./lib/libgcj.so.6
#1  0x40523513 in GC_register_finalizer_no_order () from ./lib/libgcj.so.6
#2  0x403acf0d in _Jv_MonitorExit () from ./lib/libgcj.so.6
#3  0x081d1d4c in org::eclipse::swt::widgets::Synchronizer::syncExec ()
#4  0x081c4790 in org::eclipse::swt::widgets::Display::syncExec ()
#5  0x080b608a in 
sancho::view::transfer::downloads::DownloadTableTreeContentProvider::update ()
#6  0x4041d761 in java::util::Observable::notifyObservers () 
from ./lib/libgcj.so.6
#7  0x4041d627 in java::util::Observable::notifyObservers () 
from ./lib/libgcj.so.6
#8  0x080ec02e in sancho::model::mldonkey::FileCollection::sendUpdate ()
#9  0x08108aae in sancho::core::MLDonkeyCore$1::run ()
#10 0x404288ed in java::util::Timer$Scheduler::run () from ./lib/libgcj.so.6
#11 0x403d7855 in java::lang::Thread::run () from ./lib/libgcj.so.6
#12 0x403b1c3b in _Jv_ThreadRun () from ./lib/libgcj.so.6
#13 0x40511f50 in _Jv_ThreadRegister () from ./lib/libgcj.so.6
#14 0x4052f418 in GC_start_routine () from ./lib/libgcj.so.6
#15 0x435f979c in start_thread () from /lib/tls/libpthread.so.0
#16 0x433daf2a in clone () from /lib/tls/libc.so.6

(gdb) disas 0x40523281 0x40523391
Dump of assembler code from 0x40523281 to 0x40523391:
0x40523281 :   mov%eax,(%esp)
0x40523284 :   call   0x4036cecc <_init+18776>
0x40523289 :   mov0x55d8(%ebx),%eax
0x4052328f :   mov(%eax),%eax
0x40523291 :   test   %eax,%eax
0x40523293 :   jne0x40523365 

0x40523299 :   mov0xe9a0(%ebx),%esi
0x4052329f :   jmp0x405231b3 

0x405232a4 :   mov0x14(%ebp),%eax
0x405232a7 :   test   %eax,%eax
0x405232a9 :   je 0x405232b4 

0x405232ab :   mov0x14(%ebp),%edx
0x405232ae :   movl   $0x0,(%edx)
0x405232b4 :   mov0x18(%ebp),%esi
0x405232b7 :   test   %esi,%esi
0x405232b9 :   je 0x405232c4 

0x405232bb :   mov0x18(%ebp),%ecx
0x405232be :   movl   $0x0,(%ecx)
0x405232c4 :   mov0xc(%ebp),%ecx
0x405232c7 :   test   %ecx,%ecx
0x405232c9 :   je 0x4052325b 

0x405232cb :   mov0x4380(%ebx),%eax
0x405232d1 :   mov%edi,%edx
0x405232d3 :   shr$0x16,%edx
0x405232d6 :   mov0xb074(%eax,%edx,4),%edx
0x405232dd :   mov%edi,%eax
0x405232df :   shr$0xc,%eax
0x405232e2 :   and$0x3ff,%eax
0x405232e7 :   mov(%edx,%eax,4),%eax
0x405232ea :   test   %eax,%eax
0x405232ec :   mov%eax,0xfff0(%ebp)
0x405232ef :   je 0x4052325b 

0x405232f5 :   mov$0x1,%edx
0x405232fa :   mov%edx,0x4(%esp)
0x405232fe :   movl   $0x18,(%esp)
0x40523305 :   call   0x4037563c <_init+53448>
0x4052330a :   test   %eax,%eax
0x4052330c :   mov%eax,%esi
0x4052330e :   je 0x405233d1 

0x40523314 :   mov0xfff0(%ebp),%edx
0x40523317 :   not%edi
0x40523319 :   mov%edi,(%esi)
0x4052331b :   mov0xc(%ebp),%ecx
0x4052331e :   mov0x10(%ebp),%edi
0x40523321 :   mov(%edx),%eax
0x40523323 :   mov0xffec(%ebp),%edx
0x40523326 :   mov%ecx,0x8(%esi)
---Type  to continue, or q  to quit---
0x40523329 :   mov0x1c(%ebp),%ecx
0x4052332c :   mov%edi,0xc(%esi)
0x4052332f :   mov%eax,0x10(%esi)
0x40523332 :   mov0x166d4(%ebx),%eax
0x40523338 :   mov%ecx,0x14(%esi)
0x4052333b :   add%eax,%edx
0x4052333d :   mov(%edx),%eax
0x4052333f :   mov%esi,(%edx)
0x40523341 :   mov%eax,0x4(%esi)
0x40523344 :   mov0x5598(%ebx),%eax
0x4052334a :   incl   (%eax)
0x4052334c :   jmp0x4052325b 

0x40523351 :   call   0x403697ac <_init+4664>
0x40523356 :   jmp0x4052318d 

0x4052335b :   xor%ecx,%ecx
0x4052335d :   lea0x0(%esi),%esi
0x40523360 :   jmp0x40523207 

0x40523365 :   xor%ecx,%ecx
0x40523367 :   xor%eax,%eax
0x40523369 :   mov%ecx,0x10(%esp)
0x4052336d :   mov0xe9a0(%ebx),%ecx
0x40523373 :   xor%esi,%esi
0x40523375 :   mov%eax,0x18(%esp)
0x40523379 :   xor%eax,%eax
0x4052337b :   xor%edx,%edx
0x4052337d :   mov%eax,0x8(%esp)
0x40523381 :   mov$0x1,%eax
0x40523386 :   mov%esi,0x14(%esp)
0x4052338a :   shl%cl,%eax
0x4052338c :   mov%eax,0x4(%esp)
0x40523390 :   lea0xffed22fb(%ebx),%eax
End of assembler dump.


(gdb) info registers
eax0x8dc2270148644464
ecx0x405104e0   1079051488
edx0x1  1
ebx0x406ecc6c   1081003116
esp0

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-01 16:55 
---
> The effect for the test case of this PR is huge.
> The effect on everything else (for example insn-attrtab) is not
> measurable.

We have had many bug reports from users trying to compile interpret-like code 
which is machine generated and is effectively made by giant switch statements. 
Improving this PR will definitely make their code go faster.

In fact, if we are going to have a performance testsuite for GCC (as I asked to 
the SC lately), I would surely propose to put such a testcase in there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug middle-end/9200] C testsuite failures in compile/simd-5.c w/-m64 or on sparcv9/sparc64

[kghazi at verizon dot net]

--- Additional Comments From kghazi at verizon dot net  2004-11-01 16:33 ---
Subject: Re:  C testsuite failures in compile/simd-5.c w/-m64 or on sparcv9/sparc64

Ditto on Sparc64-solaris2.9, see:
http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00030.html

I'm curious though whether it was really fixed or somehow masked by an
unrelated change.

I'd also like to run an -m64 pass against plain sparc and see if it's fixed
there also.  Results of that tomorrow.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9200

[Bug target/18153] [3.4/4.0 Regression] -static-libgcc links in libunwind.so.7

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-11-01 16:29 ---
An alternative is posted at

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02209.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18153

[Bug other/17783] Top level configure doesn't support shared libraries enabled by default

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-11-01 16:28 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00795.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17783

[Bug tree-optimization/18237] [4.0 regression] tree check: expected ssa_name, have var_decl in verify_ssa

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at dberlin dot org  2004-11-01 16:01 ---
Subject: Re:  [4.0 regression]  tree check:
 expected ssa_name, have var_decl in verify_ssa



On Mon, 1 Nov 2004, pinskia at gcc dot gnu dot org wrote:

>
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 14:28 
> ---
> We are adding a VUSE which has a VAR_DECL and not a SSA_NAME.  This is after 
> 32.redphi2.
>

This occurs if you screw the vuses.
just add mark_new_variables_for_renaming when you modify the statement, 
and TODO_rename_vars to the pass todo flags, and it'll DTRT.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18237

[Bug tree-optimization/18237] [4.0 regression] tree check: expected ssa_name, have var_decl in verify_ssa

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 15:57 
---
Actually adding a vuse without a SSA_NAME is fine but not renaming it is the problem.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18237

[Bug tree-optimization/14329] [tree-ssa] badly formatted warnings for SRA replacements

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 15:47 
---
*** Bug 18265 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||nathan at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329

[Bug middle-end/18265] unititlized warning and SRA give confusing names

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 15:47 
---


*** This bug has been marked as a duplicate of 14329 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18265

[Bug middle-end/18265] unititlized warning and SRA give confusing names

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-11-01 15:45 
---
Created an attachment (id=7452)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7452&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18265

[Bug middle-end/18265] New: unititlized warning and SRA give confusing names

[nathan at gcc dot gnu dot org]

The attached test case, when compiled with '-O2 -Wall' gives the
following warning,

sra.i: In function 'foo':
sra.i:8: warning: 'a$m' is used uninitialized in this function

A user will know nothing of SRA and think 'I have no variable called a$m -- heck
that's not even a valid name'.

Why can't the SRA names use '.' rather than '$' as the separator?

-- 
   Summary: unititlized warning and SRA give confusing names
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nathan at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18265

[Bug middle-end/9200] C testsuite failures in compile/simd-5.c w/-m64 or on sparcv9/sparc64

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2004-11-01 15:33 
---
 simd-5.c succeeded for me on sparc64-linux today both on -O1 and -O0 that is
without any changes in the build tree.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9200

[Bug libstdc++/18262] [3.4 Regression] New libstdc++ testsuite fails

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-11-01 
15:24 ---
Subject: Re:  [3.4 Regression] New libstdc++ testsuite fa

> Dave, do you have time to work out what patch is causing the problem?  If
> not,
> please let me know, and I'll try to do it.

I don't have a lot of time at the moment, only evenings and weekends.

I found that the locale setup on the machine had likely changed.  The
system manager did some cleanups on it a couple of months ago and removed
some stuff needed by GCC.  I installed the debian locale package and
regenerated the locales needed for the v3 testsuite.  However, at first
crack this doesn't seem to have changed the situation.  I had built 3.4.2
last night and it now shows the same 16 fails.  Thus, it doesn't look like
a GCC patch is the cause of the regressions.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18262

[Bug tree-optimization/18264] [4.0 Regression] Internal compiler error when compiling C++ file with optimisations enabled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 15:09 
---
Yes this is already fixed in a newer 4.0.0.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18264

[Bug tree-optimization/18264] [4.0 Regression] Internal compiler error when compiling C++ file with optimisations enabled

[pavenis at latnet dot lv]

--- Additional Comments From pavenis at latnet dot lv  2004-11-01 15:06 ---
Created an attachment (id=7451)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7451&action=view)
Preprocessed source compressed with bzip2

To reproduce bug:

gcc -c -O2 filelist.ii


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18264

[Bug tree-optimization/18264] [4.0 Regression] Internal compiler error when compiling C++ file with optimisations enabled

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 15:06 
---
This might be already fixed, please attach the preprocessed source.

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|Internal compiler error when|[4.0 Regression] Internal
   |compiling C++ file with |compiler error when
   |optimisations enabled   |compiling C++ file with
   ||optimisations enabled
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18264

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[s dot bosscher at student dot tudelft dot nl]

--- Additional Comments From s dot bosscher at student dot tudelft dot nl  
2004-11-01 15:03 ---
Subject: RE:  [4.0 Regression] jump threading
 on trees is slow with switch statements with large # of cases

I created a special function for the split_critical_edges pass
to split edges out of SWITCH_EXPR blocks in linear time wrt. the
number of outgoing edges E and the number of case labels C.  The
function makes the edge splitting take O(E+2C) time, instead of
E*C which is effectively quadratic.

The effect for the test case of this PR is huge.

The effect on everything else (for example insn-attrtab) is not
measurable.

Dunno if this is worth the trouble.  The patch I have is a hack
and the real solution is using a smarter representation for the
case label targets.  I'll try some other code and perhaps post
the patch.  We might want to just do it as a hack on the gcc 4.0
release branch...



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug tree-optimization/18264] New: Internal compiler error when compiling C++ file with optimisations enabled

[pavenis at latnet dot lv]

I got following internal compiler error with gcc-4.0.0 20041028

Reading specs from /disk2/gcc400/lib/gcc/i586-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/disk2/gcc400 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --with-gnu-ld --verbose
--target=i586-pc-linux-gnu --host=i586-pc-linux-gnu --build=i586-pc-linux-gnu
Thread model: posix
gcc version 4.0.0 20041028 (experimental)
 /disk2/gcc400/libexec/gcc/i586-pc-linux-gnu/4.0.0/cc1plus -fpreprocessed
filelist.ii -quiet -dumpbase filelist.ii -mtune=pentium -auxbase filelist -O2
-version -o /tmp/cct4ToGb.s
GNU C++ version 4.0.0 20041028 (experimental) (i586-pc-linux-gnu)
compiled by GNU C version 4.0.0 20041028 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
fileutil/filelist.cc: In member function `bool FileList::SearchPath(const
std::string&, const std::string&, char)':
fileutil/filelist.cc:107: error: Type mismatch between an SSA_NAME and its symbol.
fileutil/filelist.cc:107: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


when compiling C++ source. Initially noticed it for i586-pc-msdosdjgpp, after
that reproduced for i586-pc-linux-gnu with the same GCC version and source

-- 
   Summary: Internal compiler error when compiling C++ file with
optimisations enabled
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pavenis at latnet dot lv
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18264

[Bug tree-optimization/18219] [4.0 Regression] gcc-4.0.0 bloats code by 31%

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz  
2004-11-01 14:57 ---
Subject: Re:  [4.0 Regression] gcc-4.0.0 bloats code by 31%

> Zdenek, thanks for the patch!
> What is the generated code like after your patch?

It seems that the 3.4 code is still smaller (I haven't measured it, just
guessing from looking at your disassembly), but -fno-ivopts no longer
changes it.

pushl   %ebp
movl%esp, %ebp
pushl   %edi
pushl   %esi
pushl   %ebx
movl8(%ebp), %edi
movl20(%ebp), %esi
movl16(%ebp), %ebx
incl%ebx
movl%ebx, %ecx
leal0(,%ebx,4), %edx
addl12(%ebp), %edx
jmp .L2
.L3:
movl-4(%edi,%ecx,4), %eax
incl%eax
sall%eax
subl(%edx), %eax
movl%eax, (%edx)
incl%ecx
addl$4, %edx
.L2:
cmpl%esi, %ecx
jle .L3
popl%ebx
popl%esi
popl%edi
leave
ret



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219

[Bug tree-optimization/18219] [4.0 Regression] gcc-4.0.0 bloats code by 31%

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-01 14:40 
---
Zdenek, thanks for the patch!
What is the generated code like after your patch?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219

[Bug c/18239] [4.0 Regression] ICE in get_parm_info with werid attribute

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2004-11-01 14:29 
---
Subject: Re:  [4.0 Regression] ICE in get_parm_info with werid
 attribute

On Mon, 1 Nov 2004, pinskia at gcc dot gnu dot org wrote:

> The C++ front-end rejects the code out right.

But the bug can be triggered on valid C90 code:

int f (int [sizeof(g())]);

I'm now looking at fixing it.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18239

[Bug tree-optimization/18237] [4.0 regression] tree check: expected ssa_name, have var_decl in verify_ssa

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 14:28 
---
We are adding a VUSE which has a VAR_DECL and not a SSA_NAME.  This is after 
32.redphi2.

-- 
   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18237

[Bug tree-optimization/18237] [4.0 regression] tree check: expected ssa_name, have var_decl in verify_ssa

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 14:09 
---
I can also confirm it on powerpc-darwin (my build does not get this far yet, I have to 
try to reproduce it 
with the command below).

-- 
   What|Removed |Added

 GCC target triplet|powerpc-*-linux |powerpc-*-linux, powerpc-
   ||darwin
Summary|[4.0 regression] tree check:|[4.0 regression]  tree
   |expected ssa_name, have |check: expected ssa_name,
   |var_decl in verify_ssa  |have var_decl in verify_ssa


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18237

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-11-01 14:09 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Mon, 2004-11-01 at 05:16 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 05:16 
> ---
> We are still way behind 3.3, it takes 15 seconds on my 1.5GHz PPC 7400 with 3.3 but 
> with 4.0, well for 
> 4.0 time just look at Jeff's data and see that we are way behind still.
Well, I haven't looked at 3.3, but I can make a reasonable guess that
we're still way way way behind due to the way we update case labels
when forwarding edges and splitting critical edges.  Some early 
experiments I've done with that indicate there's another 30-35%
improvement that can be made by fixing that problem.  Then there's
*another* 30% or so we're burning in the RTL branch prediction code
(I haven't looked to see if there's anything we can do with that code
yet).

I doubt it makes much sense to look closely at 3.3 vs 4.0 for this
testcase and similar code until we fix those glaring problems.

It's also not clear to me how much of an improvement those changes
will make in real-world code.  ie, we could easily run into a case
where we drastically improve that testcase without improving any
real code, much like what happened recently with my changes to 
improve how we find/record equivalences for edges.

Jeff



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug c/18239] [4.0 Regression] ICE in get_parm_info with werid attribute

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 14:05 
---
The C++ front-end rejects the code out right.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18239

[Bug c/18239] [4.0 Regression] ICE in get_parm_info with werid attribute

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 14:03 
---
We have a function_decl at this point for vector_size.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18239

[Bug target/18263] Build broken for ARC.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 13:45 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||build, patch
   Last reconfirmed|-00-00 00:00:00 |2004-11-01 13:45:17
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18263

[Bug target/17889] gcc 3.4 branch does not build for arc-elf32

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-01 13:43 
---
Confirmed

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-01 13:43:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17889

[Bug target/16286] Compile errors on altivec ops after #undef vector

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2004-11-01 13:28 ---
Followup patch . 

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
   Keywords||patch
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16286

[Bug tree-optimization/18219] [4.0 Regression] gcc-4.0.0 bloats code by 31%

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-11-01 13:21 
---
Unfortunately I do not think this will help much in other related PRs.

Patch:

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00025.html

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219

[Bug rtl-optimization/18260] generated code uses memory beyond allocated stack frame.

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2004-11-01 13:06 ---
(In reply to comment #0)
> It appears that the memory for local
> variables is not accounted for entirely correctly.  There are 1024+ bytes of
> local variables, but the stack pointer (%rsp) is only adjusted by 912 bytes. 
> And it appears local variable "count" is referenced before the stack pointer
> (-120(%rsp)).

This is OK, since the AMD64 ABI specifies a 128 byte "red zone" below the stack
pointer that the kernel must not touch on an interrupt. If it does, it's
a kernel bug. You can try -fno-red-zone to see whether this is actually the
problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18260

[Bug libgcj/14164] [Win32] gcj fails to load resource bundle based on classloader

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|java|libgcj


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14164

[Bug target/18263] Build broken for ARC.

[ramana dot radhakrishnan at codito dot com]

--- Additional Comments From ramana dot radhakrishnan at codito dot com  
2004-11-01 12:23 ---
Patch submitted at : 

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00024.html

-- 
   What|Removed |Added

Summary|Build broken for ARC.   |Build broken for ARC.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18263

[Bug target/18263] New: Build broken for ARC.

[ramana dot radhakrishnan at codito dot com]

The build for ARC got broken inadvertently due to a typo in a patch submitted
earlier by me for lib1funcs.asm . 

This is because cmp is not a valid instruction in the ARCTangent A4.


./xgcc -B./ -B/usr/local/arcfsf/arc-elf32/bin/ -isystem
/usr/local/arcfsf/arc-elf32/include -isystem
/usr/local/arcfsf/arc-elf32/sys-include
-L/mnt/tools/fsf/fsfbuild/build-gcc-arc-elf32/gcc/../ld -O2  -DIN_GCC
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I.
-I/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc
-I/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc/.
-I/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc/../include
-I/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc/../libcpp/include  -DL_umulsidi3
-xassembler-with-cpp -c
/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc/config/arc/lib1funcs.asm -o
libgcc/./_umulsidi3.o
/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc/config/arc/lib1funcs.asm: Assembler
messages:
/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc/config/arc/lib1funcs.asm:70:
Warning: ".option" directive overrides command-line (default) value
/mnt/tools/fsf/fsfgcc/gcc-4.0-fresh/gcc/gcc/config/arc/lib1funcs.asm:92: Error:
bad instruction `cmp r0,0'
make[1]: *** [libgcc/./_umulsidi3.o] Error 1
make[1]: Leaving directory `/mnt/tools/fsf/fsfbuild/build-gcc-arc-elf32/gcc'
make: *** [libgcc.a] Error 2

I will be submitting a patch to fix this PR shortly.

-- 
   Summary: Build broken for ARC.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at codito dot com
CC: gcc-bugs at gcc dot gnu dot org,giovannibajo at libero
dot it,mark at codesourcery dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arc-elf32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18263

Inviting you to participate in SCI 2005

[Prof. Nagib Callaos]

Dear Dr. Claudio Gabellini:

On behalf of the SCI 2005 Organizing Committee, I would like to invite you to 
participate in the 9th World Multi-Conference on Systemics, Cybernetics and 
Informatics (http://www.iiisci.org/sci2005), which will take place in Orlando, 
Florida, USA, from July 10-13, 2005.

You can get the conference´s Call for papers in 
(http://www.iiisci.org/sci2005/website/callforpapers.asp).

The best 10% of the papers will be published in Volume 3 of SCI Journal 
(http://www.iiisci.org/Journal/SCI/Home.asp ). 12 issues of the volumes 1 and 2 of the 
Journal have been sent to about 200 university and research libraries. Free 
subscriptions, for 2 years, are being considered for the organizations of the 
Journals´ authors.

We are emphasizing the area of Computing Techniques which is related to your specific 
area.

Also, we would like to invite you to organize an invited session related to a topic of 
your research interest. If you are interested in organizing an invited session, 
please, fill the respective form provided in the conference web page, and we will send 
you a password, so you can include and modify papers in your invited session.

Organizers of the invited sessions with the best performance will be co-editors of the 
proceeding volume where their sessions' papers were included and of the CD electronic 
proceedings. They will also be candidate for invited editors, or co-editors of a 
possible SCI Journal issue related to their invited session papers.

You can find information about the suggested steps to organize an invited session in 
the Call for Papers and in the conference web page: http://www.iiisci.org/sci2005 .

If by any reasons you are not able to access the page mentioned above, please, try the 
following pages: http://www.iiis.org/sci2005 .

If you need a detailed Call for Papers, don't hesitate in asking us for it.

If the deadlines are tight and you need more time, let me know about a suitable time 
and I will inform you if it is feasible for us.

Best regards,

Professor Nagib Callaos
SCI 2005 General Chair