[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #12 from jason at gcc dot gnu dot org  2006-09-07 06:53 ---
Subject: Bug 26195

Author: jason
Date: Thu Sep  7 06:53:21 2006
New Revision: 116740

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116740
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

Added:
trunk/gcc/testsuite/g++.dg/ext/interface2.C
trunk/gcc/testsuite/g++.dg/ext/interface2a.h
trunk/gcc/testsuite/g++.dg/ext/interface2b.cc
trunk/gcc/testsuite/g++.dg/ext/interface3/
trunk/gcc/testsuite/g++.dg/ext/interface3/dir1/
trunk/gcc/testsuite/g++.dg/ext/interface3/dir1/interface3.h
trunk/gcc/testsuite/g++.dg/ext/interface3/dir2/
trunk/gcc/testsuite/g++.dg/ext/interface3/dir2/interface3.h
trunk/gcc/testsuite/g++.dg/ext/interface3/interface3a.C
trunk/gcc/testsuite/g++.dg/ext/interface3/interface3a2.cc
trunk/gcc/testsuite/g++.dg/ext/interface3/interface3b.C
trunk/gcc/testsuite/g++.dg/ext/interface3/interface3b2.cc
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/lex.c
trunk/gcc/cp/semantics.c


-- 


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



[Bug target/26968] [4.1 Regression] HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)

2006-09-07 Thread uros at kss-loka dot si


--- Comment #9 from uros at kss-loka dot si  2006-09-07 06:58 ---
I have built and run a testsuite of HDF5 library on i686-pc-linux-gnu with:

gcc version 4.2.0 20060906 (experimental)

hdf5-1.6.5 (production):
(CFLAGS=-fno-strict-aliasing is needed before configure)
All tests PASS with default compile flags out of the box.

hdf5-1.8.0-alpha4:
All tests PASS with defult compile flags out of the box.

I guess this bugreport can be considered as 4.1 regression only.


-- 

uros at kss-loka dot si changed:

   What|Removed |Added

  Component|middle-end  |target
 GCC target triplet||i386-pc-linux-gnu
  Known to work||4.2.0
Summary|[4.1/4.2 Regression] HDF5   |[4.1 Regression] HDF5 1.7.52
   |1.7.52 test segfaults with  |test segfaults with 4.1.0,
   |4.1.0, fine with 4.0.2  |fine with 4.0.2 (regression)
   |(regression)|


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



[Bug c++/26195] [4.0/4.1 regression] pragma interface no longer handles explicit names

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #13 from jason at gcc dot gnu dot org  2006-09-07 07:08 ---
The patch looked good to me, so I applied it.  Sorry for the delay.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Known to fail|4.0.3 4.1.0 4.2.0   |4.0.3 4.1.0
  Known to work|3.3.6 3.4.5 |3.3.6 3.4.5 4.2.0
   Last reconfirmed|2006-02-13 18:48:40 |2006-09-07 07:08:04
   date||
Summary|[4.0/4.1/4.2 regression]|[4.0/4.1 regression] pragma
   |pragma interface no longer  |interface no longer handles
   |handles explicit names  |explicit names


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



[Bug c++/26693] [4.0/4.1/4.2 regression] Access checks not performed for types in templates

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #2 from jason at gcc dot gnu dot org  2006-09-07 07:18 ---
If we resolve A::X to int while parsing the template definition, we need to
check access then, too.


-- 


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



[Bug rtl-optimization/28940] [4.1/4.2 Regression] address selection does not work correctly

2006-09-07 Thread bonzini at gnu dot org


--- Comment #2 from bonzini at gnu dot org  2006-09-07 08:11 ---
It's not really CSE's fault, though I agree that doing addressing mode
selection there is wrong.  fwprop does not fix the bug for example, though
teaching it about this case could be easier than teaching CSE.

Unlike CSE, fwprop fixes this case:

char a[10], b[10];

int f1(log i)
{
return a[i+1] + b[i+1];
}

which generates

incq%rdi
movsbl  a(%rdi),%eax
movsbl  b(%rdi),%edx
addl%edx, %eax

with current GCC.  So one way to fix this bug (assuming fwprop is merged in
4.3) is to teach something (expand?) that


(set (reg:DI 58 [ D.1872 ])
(sign_extend:DI (reg:SI 60 [ D.1872 ])))

(parallel [
(set (reg:DI 62 [ D.1872 ])
(plus:DI (reg/v:DI 58 [ i ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
])

at least when we can disregard overflow, might be better than

(parallel [
(set (reg:SI 58 [ D.1872 ])
(plus:SI (reg/v:SI 60 [ i ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
])

(set (reg:DI 62 [ D.1872 ])
(sign_extend:DI (reg:SI 58 [ D.1872 ])))


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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



[Bug rtl-optimization/28940] [4.1/4.2 Regression] address selection does not work correctly

2006-09-07 Thread bonzini at gnu dot org


--- Comment #3 from bonzini at gnu dot org  2006-09-07 08:15 ---
BTW, what did 4.0 and 3.4 produce?


-- 


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



[Bug target/27117] SH backend cheats to reload -- disables indexed addressing but uses it internally

2006-09-07 Thread bonzini at gcc dot gnu dot org


--- Comment #16 from bonzini at gnu dot org  2006-09-07 08:19 ---
Subject: Bug 27117

Author: bonzini
Date: Thu Sep  7 08:19:32 2006
New Revision: 116746

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116746
Log:
2006-09-07  Paolo Bonzini  [EMAIL PROTECTED]

PR target/27117
* config/sh/sh.md (divsi_inv_qitable, divsi_inv_hitable): New patterns.
(divsi_inv_m1): Use them.
(UNSPEC_DIV_INV_TABLE): New constant.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md


-- 


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



[Bug target/27117] SH backend cheats to reload -- disables indexed addressing but uses it internally

2006-09-07 Thread bonzini at gnu dot org


--- Comment #17 from bonzini at gnu dot org  2006-09-07 08:20 ---
fixed.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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



[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?

2006-09-07 Thread pcarlini at suse dot de


--- Comment #19 from pcarlini at suse dot de  2006-09-07 09:11 ---
A side note, maybe not completely obvious to everyone and clarifying the
relationship to 24581. I understand that:

 (+0) + (-0) = +0

therefore, when in the expansion of the complex product one of the two terms of
the imaginary part is +0 and the other -0 the result doesn't show the sign. The
same product as complex * real (like in this PR) must lead instead to -0.
Thus, barring additional evidence, it may well be that the mess is limited to
complex * real and real * complex, as stated in 24581, but definitely affects
both C and C++ (in different, inconsistent, ways :(


-- 


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



[Bug fortran/28971] New: ICE: Segmentation fault on valid code

2006-09-07 Thread enok at lysator dot liu dot se
When compiling a small file with standard flags the compiler crashes.
This seems to be related to a WHERE construct.
The code is accepted without warnings by e.g. Intel fortran compiler and
others.
The version of gfortran is 4.2.0 20060819


-- 
   Summary: ICE: Segmentation fault on valid code
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enok at lysator dot liu dot se
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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



[Bug fortran/28971] ICE: Segmentation fault on valid code

2006-09-07 Thread enok at lysator dot liu dot se


--- Comment #1 from enok at lysator dot liu dot se  2006-09-07 09:31 ---
Created an attachment (id=12201)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12201action=view)
Valid code snippet that causes ICE

gfortran -c tst.f90
tst.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.


-- 


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



[Bug java/28972] New: gcjh does not correctly handle dollar symbol in class name

2006-09-07 Thread raif at swiftdsl dot com dot au
invoking gcjh on a class named OC$ for example, the generated JNI header file
includes method definitions with names like so:

JNIEXPORT void JNICALL Java_OC_00024_method...


-- 
   Summary: gcjh does not correctly handle dollar symbol in class
name
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raif at swiftdsl dot com dot au
GCC target triplet: i386-redhat-linux


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



[Bug java/28972] gcjh does not correctly handle dollar symbol in class name

2006-09-07 Thread raif at swiftdsl dot com dot au


--- Comment #1 from raif at swiftdsl dot com dot au  2006-09-07 10:36 
---
Created an attachment (id=12202)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12202action=view)
class file with name ending with dollar


-- 


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



[Bug java/28972] gcjh does not correctly handle dollar symbol in class name

2006-09-07 Thread raif at swiftdsl dot com dot au


--- Comment #2 from raif at swiftdsl dot com dot au  2006-09-07 10:37 
---
Created an attachment (id=12203)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12203action=view)
generated JNI header file


-- 


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



[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3

2006-09-07 Thread jsm28 at gcc dot gnu dot org


--- Comment #1 from jsm28 at gcc dot gnu dot org  2006-09-07 14:38 ---
This bug appeared on 4.1 branch between 20060718 (revision 115546) and 20060721
(revision 115639), so a regression.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-09-07 14:38:42
   date||
Summary|gcc.c-  |[4.1/4.2 Regression] gcc.c-
   |torture/execute/20050604-1.c|torture/execute/20050604-1.c
   |fails on IA64 at -O3|fails on IA64 at -O3
   Target Milestone|--- |4.1.2


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



[Bug testsuite/28969] FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization 2

2006-09-07 Thread joseph at codesourcery dot com


--- Comment #1 from joseph at codesourcery dot com  2006-09-07 14:46 ---
Subject: Re:   New: FAIL: gcc.dg/nrv3.c scan-tree-dump-times
 return slot optimization 2

On Thu, 7 Sep 2006, danglin at gcc dot gnu dot org wrote:

 Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc
 -B/home/dave/gnu/gcc-4
 .2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/nrv3.c   -O
 -fdum
 p-tree-optimized -fno-show-column -S  -o nrv3.s(timeout = 300)
 PASS: gcc.dg/nrv3.c (test for excess errors)
 FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization 2
 GCC target triplet: hppa*-*-* (32-bit)

I see this failing on hppa64 as well.


-- 


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



[Bug fortran/28974] New: Extremely slow compilation of enumerated DATA statements.

2006-09-07 Thread franke dot daniel at gmail dot com
Compilation of enumerated DATA statements is extremely slow. 
Related PR: 
 * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13465
Related threads on ML: 
 * http://gcc.gnu.org/ml/fortran/2004-08/msg00131.html
 * http://gcc.gnu.org/ml/fortran/2006-09/msg00025.html

Shell script to generate example data:
$ cat datagen.sh
#! /bin/bash
outfile=data.f90
dim1=50
dim2=1000
echo MODULE appdata${outfile}
echo INTEGER :: thedata(${dim1}, ${dim2}) ${outfile}
for i in `seq 1 ${dim1}` ; do
  for j in `seq 1 ${dim2}` ; do
echo DATA thedata(${i}, ${j}) / $((i*j)) /${outfile}
  done
done
echo END MODULE   ${outfile}

P4 3.2 GHz, 2GB RAM:
$ bash datagen.sh
$ time gfortran-4.2 -c data.f90
real3m31.646s
user3m29.545s
sys 0m0.172s


-- 
   Summary: Extremely slow compilation of enumerated DATA
statements.
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: franke dot daniel at gmail dot com
 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=28974



[Bug c/27702] the trampoline code of nested functions depends on executable stacks

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2006-09-07 15:20 ---
(In reply to comment #4)
 Andrew, could you elaborate on the FC5 kernel bug and the rules that are
 always used?
This kernel problem has been fixed for a while now, since around June or so.


-- 


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



[Bug c++/28975] New: conflicting declaration 'typedef struct mbstate_t mbstate_t'

2006-09-07 Thread waspswarm at gmail dot com
When compiling the following test application with g++ and
-D__STDC_VERSION__=199901 I receive errors about duplicate declarations.

$ uname -a
HP-UX yellow B.11.23 U ia64 1794711014 unlimited-user license

// g++ -o test.o -g -O2 -mlp64 -D__STDC_VERSION__=199901 -c testmbstate.cpp
// remove -D__STDC_VERSION__=199901 and it compiles cleanly

#include iostream
int main(int argc, char** argv)
{
return 0;
}

$ g++ -v -o test.o -g -O2 -mlp64 -D__STDC_VERSION__=199901 -c testmbsta
Using built-in specs.
Target: ia64-hp-hpux11.23
Configured with: ../gcc-4.1.1/configure --enable-checking=release
--disable-shared --enable-threads=posix --disable-nls --enable-c99
--enable-languages=c,c++ : (reconfigured) ../gcc-4.1.1/configure
--enable-checking=release --disable-shared --enable-threads=posix --disable-nls
--enable-c99 --enable-languages=c,c++ --with-gnu-as
--with-as=/opt/hp-gcc/bin/as --without-gnu-ld
Thread model: posix
gcc version 4.1.1
 /usr/local/libexec/gcc/ia64-hp-hpux11.23/4.1.1/cc1plus -quiet -v
-D__STDC_VERSION__=199901 testmbstate.cpp -quiet -dumpbase testmbstate.cpp
-mlp64 -auxbase-strip test.o -g -O2 -version -o /var/tmp//ccLUuqb0.s
ignoring nonexistent directory NONE/include
ignoring nonexistent directory
/usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../ia64-hp-hpux11.23/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1

/usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1/ia64-hp-hpux11.23

/usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1/backward
 /usr/local/include
 /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/include
 /usr/include
End of search list.
GNU C++ version 4.1.1 (ia64-hp-hpux11.23)
compiled by GNU C version 3.4.6.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8d13e28aaeb67511ccb5485a483e1cbb
/usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.1/../../../../include/c++/4.1.1/cwchar:66:
error: conflicting declaration 'typedef struct mbstate_t mbstate_t'
/usr/include/sys/_mbstate_t.h:15: error: 'mbstate_t' has a previous declaration
as 'typedef struct mbstate_t mbstate_t'


-- 
   Summary: conflicting declaration 'typedef struct mbstate_t
mbstate_t'
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: waspswarm at gmail dot com
 GCC build triplet: ia64-hp-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


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



[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #11 from pinskia at gcc dot gnu dot org  2006-09-07 15:37 
---
Subject: Bug 28862

Author: pinskia
Date: Thu Sep  7 15:36:50 2006
New Revision: 116751

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116751
Log:
2006-09-07  Andrew Pinski  [EMAIL PROTECTED]

PR middle-end/28862
* stor-layout.c (relayout_decl): Don't zero the alignment if it
was set by the user.

2006-09-07  Andrew Pinski  [EMAIL PROTECTED]

PR middle-end/28862
* gcc.c-torture/compile/vector-align-1.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/vector-align-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug middle-end/28862] [4.0/4.1 Regression] attribute ((aligned)) ignored on vector variables

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #12 from pinskia at gcc dot gnu dot org  2006-09-07 15:37 
---
Waiting for the testcase to settle before applying to the 4.1/4.0 branches.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.0.0 4.1.0 4.2.0   |4.0.0 4.1.0
  Known to work|3.4.0   |3.4.0 4.2.0
Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression]
   |attribute ((aligned))   |attribute ((aligned))
   |ignored on vector variables |ignored on vector variables


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



[Bug c++/28975] conflicting declaration 'typedef struct mbstate_t mbstate_t'

2006-09-07 Thread waspswarm at gmail dot com


--- Comment #1 from waspswarm at gmail dot com  2006-09-07 15:39 ---
Here is /usr/include/sys/_mbstate_t.h

/*
 * @(#)B11.23_LR
 */

#ifndef _MBSTATE_T_INCLUDED
#define _MBSTATE_T_INCLUDED

#  ifndef _MBSTATE_T
# define _MBSTATE_T
  typedef struct {
 unsigned char __parse_size:3;
 unsigned char __dummy:4;
 unsigned char __shift_state:1;
 char __parse_buf[7];
  } mbstate_t;
#  endif

#endif /* _MBSTATE_T_INCLUDED */

Here is the section of /usr/local/include/c++/4.1.1/cwchar around line 66:
// Need to do a bit of trickery here with mbstate_t as char_traits
// assumes it is in wchar.h, regardless of wchar_t specializations.
#ifndef _GLIBCXX_HAVE_MBSTATE_T
extern C
{
  typedef struct
  {
int __fill[6];
  } mbstate_t;
}
#endif

namespace std
{
  using ::mbstate_t;
}


-- 

waspswarm at gmail dot com changed:

   What|Removed |Added

 CC||waspswarm at gmail dot com


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



[Bug target/28975] conflicting declaration 'typedef struct mbstate_t mbstate_t'

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-07 15:42 ---
So that means when __STDC_VERSION__=199901  then _GLIBCXX_HAVE_MBSTATE_T needs
to be defined or something like that.

Anyways this is a target issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |target
  GCC build triplet|ia64-hp-hpux11.23   |
   GCC host triplet|ia64-hp-hpux11.23   |


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



[Bug target/28975] conflicting declaration 'typedef struct mbstate_t mbstate_t'

2006-09-07 Thread waspswarm at gmail dot com


--- Comment #3 from waspswarm at gmail dot com  2006-09-07 15:46 ---
(In reply to comment #2)
 So that means when __STDC_VERSION__=199901  then _GLIBCXX_HAVE_MBSTATE_T needs
 to be defined or something like that.
 
 Anyways this is a target issue.
 

Thanks!

Adding -D_GLIBCXX_HAVE_MBSTATE_T to the compile line gets around the error.


-- 


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



[Bug fortran/28971] ICE: Segmentation fault on valid code

2006-09-07 Thread paul dot thomas at jet dot uk


--- Comment #2 from paul dot thomas at jet dot uk  2006-09-07 16:16 ---
Oskar,

This works for me with gcc-4.2.0 20060905; I know of nothing that would have
effected this change so I am at a bit of a loss.  I hung a main program on it
and checked the output too.

Paul


-- 


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



[Bug fortran/28971] ICE: Segmentation fault on valid code

2006-09-07 Thread kargl at gcc dot gnu dot org


--- Comment #3 from kargl at gcc dot gnu dot org  2006-09-07 16:58 ---
Paul, the code fails with

troutmask:kargl[205] gfc --version
GNU Fortran 95 (GCC) 4.2.0 20060711 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.

but works with

troutmask:sgk[248] gfc4x --version
GNU Fortran 95 (GCC) 4.2.0 20060906 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.

On a quick scan of ChangeLog, I did not see an entry that jumps out that
fixed/caused the problem.

Oskar,

Can you update to a newer version and verify the code works?


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug c++/28284] [4.2 regression] ICE with invalid static const variable

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #4 from jason at gcc dot gnu dot org  2006-09-07 17:25 ---
Subject: Bug 28284

Author: jason
Date: Thu Sep  7 17:25:05 2006
New Revision: 116755

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116755
Log:
PR c++/28284
* pt.c (fold_non_dependent_expr): Make sure expr is not dereferenced if
it
is NULL.

Added:
trunk/gcc/testsuite/g++.dg/template/pr28284.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c


-- 


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



[Bug bootstrap/28976] New: ld internal error building libmath in gcc 4.1.1

2006-09-07 Thread jeff dot lanam at hp dot com
I was attempting to build gcc 4.1.1 on an I386 system running Linux, RedHat 4ES
U3, and got an internal error from ld.  I realize that ld is not part of gcc
but I could not find anywhere to report bugs on it.  Since I was building gcc
at the time, I decided to file a report with you. Please let me know where I
should file it, if not here.

The source directory for the gcc was /tmp/gcc-4.1.1, the target was
/tmp/gccbld.
I entered the following commands:
cd /tmp/gccbld
/tmp/gcc-4.1.1/configure
make bootstrap

Here is a portion of the make output.  As you see, it was trying to build
libmath:

Making all in libmath
make[5]: Entering directory
`/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/libmath'make[5]: Nothing to be done
for `all'.
make[5]: Leaving directory `/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/libmath'
Making all in src
make[5]: Entering directory `/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src'
/bin/sh ../libtool --tag CXX --mode=link /tmp/gccbld/./gcc/xgcc -shared-libgcc
-B/tmp/gccbld/./gcc -nostdinc++
-L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src
-L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -Wl,-O1 -Wl,-z,relro 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual 
-fdiagnostics-show-location=once  -ffunction-sections -fdata-sections   -o
libstdc++.la -rpath /usr/local/lib -version-info 6:8:0
-Wl,--version-script=libstdc++-symbol.ver -lm  bitmap_allocator.lo
pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo
ctype.lo debug.lo debug_list.lo functexcept.lo globals_locale.lo globals_io.lo
ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo
locale_init.lo locale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo
allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo
iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo locale-misc-inst.lo
misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo
string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo
codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo
monetary_members.lo numeric_members.lo time_members.lo basic_file.lo
c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm
 /tmp/gccbld/./gcc/xgcc -shared-libgcc -B/tmp/gccbld/./gcc -nostdinc++
-L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src
-L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -shared -nostdlib /usr/lib/crti.o
/tmp/gccbld/./gcc/crtbeginS.o  .libs/bitmap_allocator.o .libs/pool_allocator.o
.libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o
.libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o
.libs/globals_locale.o .libs/globals_io.o .libs/ios.o .libs/ios_failure.o
.libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o
.libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o
.libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o
.libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o
.libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
.libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o
.libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o
.libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o
.libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o
.libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o
.libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o
.libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive
../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a
-Wl,--no-whole-archive  -L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src
-L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lm
../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a -lm
-L/tmp/gccbld/./gcc -L/usr/local/lib -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc
-lgcc_s   /tmp/gccbld/./gcc/crtendS.o /usr/lib/crtn.o  -Wl,-O1 -Wl,-z -Wl,relro
-Wl,--version-script=libstdc++-symbol.ver -Wl,-soname -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.8
/usr/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting at
../../bfd/elf32-i386.c line 2262 in elf_i386_relocate_section

/usr/bin/ld: Please report this bug.


-- 
   Summary: ld internal error building libmath in gcc 4.1.1
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff dot lanam at hp dot com



[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero

2006-09-07 Thread uros at gcc dot gnu dot org


--- Comment #11 from uros at gcc dot gnu dot org  2006-09-07 17:45 ---
Subject: Bug 28946

Author: uros
Date: Thu Sep  7 17:45:48 2006
New Revision: 116756

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116756
Log:
PR target/28946
* config/i386/i386.md (*ashldi3_cconly_rex64, *ashlsi3_cconly,
*ashlhi3_cconly, *ashlqi3_cconly, *ashrdi3_one_bit_cconly_rex64,
*ashrdi3_cconly_rex64, *ashrsi3_one_bit_cconly, *ashrsi3_cconly,
*ashrhi3_one_bit_cconly, *ashrhi3_cconly,
*ashrqi3_one_bit_cconly, *ashrqi3_cconly,
*lshrdi3_cconly_one_bit_rex64, *lshrdi3_cconly_rex64,
*lshrsi3_one_bit_cconly, *lshrsi3_cconly,
*lshrhi3_one_bit_cconly, *lshrhi3_cconly,
*lshrqi2_one_bit_cconly, *lshrqi2_cconly: New patterns to
implement only CC setting effects of shift instructions.

testsuite/ChangeLog:

   PR target/28946
   * gcc.target/i386/pr28946.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr28946.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.

2006-09-07 Thread steven at gcc dot gnu dot org


--- Comment #1 from steven at gcc dot gnu dot org  2006-09-07 17:36 ---
Quadratic (or worse?) behavior


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||compile-time-hog
   Last reconfirmed|-00-00 00:00:00 |2006-09-07 17:36:45
   date||


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



[Bug bootstrap/28976] ld internal error building libmath in gcc 4.1.1

2006-09-07 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2006-09-07 18:01 ---
binutils has its owner bug tracker: http://sourceware.org/bugzilla/
Also, 2.15 is fairly old.  Can you try with the current binutils release, 2.17?


-- 


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



[Bug bootstrap/28976] ld internal error building libmath in gcc 4.1.1

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-07 18:01 ---
This is a bug in Redhat's ld and should be reported to them.  It has been fixed
on the mainline (and in a couple of releases) of binutils already.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug libgcj/28977] UTF-16 endianness differs between gcj and Sun JDK

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-07 18:28 ---
Does this really matter as UTF-16 BOM is correct?


-- 


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



[Bug libgcj/28977] UTF-16 endianness differs between gcj and Sun JDK

2006-09-07 Thread marcus at better dot se


--- Comment #2 from marcus at better dot se  2006-09-07 18:37 ---
(In reply to comment #1)
 Does this really matter as UTF-16 BOM is correct?

Well, I have a library for XML processing that comes with a test suite, and it
expects the Sun behaviour. Besides it's documented in Sun's API, so it can
potentially matter.


-- 


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



[Bug libgcj/28977] UTF-16 endianness differs between gcj and Sun JDK

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-07 18:40 ---
(In reply to comment #2)
 Well, I have a library for XML processing that comes with a test suite, and it
 expects the Sun behaviour. Besides it's documented in Sun's API, so it can
 potentially matter.

Really if the testsuite (or the library itself) does not check the BOM, then it
is incorrect.  Yes we should follow the Java documention.


-- 


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



[Bug bootstrap/28976] ld internal error building libmath in gcc 4.1.1

2006-09-07 Thread jeff dot lanam at hp dot com


--- Comment #3 from jeff dot lanam at hp dot com  2006-09-07 18:36 ---
Subject: RE:  ld internal error building libmath in gcc 4.1.1

Thank you for the quick response.  I updated binutils and got past that.

I'm a novice at using GNU. 

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 07, 2006 11:02 AM
To: Lanam, Jeff
Subject: [Bug bootstrap/28976] ld internal error building libmath in gcc
4.1.1



--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-07 18:01
--- This is a bug in Redhat's ld and should be reported to them.  It
has been fixed on the mainline (and in a couple of releases) of binutils
already.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added


 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

--- You are receiving this mail because: --- You reported the
bug, or are watching the reporter.


-- 


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



[Bug c++/28284] [4.2 regression] ICE with invalid static const variable

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2006-09-07 18:36 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug libgcj/28977] New: UTF-16 endianness differs between gcj and Sun JDK

2006-09-07 Thread marcus at better dot se
This program gives different results with Sun's JDK (Debian sun-java5-jdk
1.5.0-08-1) and gcj:

 Test.java 
import java.io.*;

public class Test
{
public static void main(String[] args) throws java.io.IOException
{
OutputStreamWriter o = new OutputStreamWriter(System.out, UTF-16);
o.write(Hello!);
o.flush();
}
}
===

According to Sun's API docs
  http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/Charset.html
the UTF-16 encoding is supposed to default to big-endian. This is also
what I get when running with Sun's JVM:

: feff 0048 0065 006c 006c 006f 0021   ...H.e.l.l.o.!

But when I run the same program with gij, I get little-endian output:

: fffe 4800 6500 6c00 6c00 6f00 2100   ..H.e.l.l.o.!.

In both cases I executed the same .class file, compiled with the Sun
JDK.

The system is Debian i386 testing/unstable.

$ gij --version
java version 1.4.2
gij (GNU libgcj) version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)

This bug was also reported in the Debian bug-tracking system:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386443


-- 
   Summary: UTF-16 endianness differs between gcj and Sun JDK
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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



[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871

2006-09-07 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|-00-00 00:00:00 |2006-09-07 18:21:39
   date||


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



[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #10 from jason at gcc dot gnu dot org  2006-09-07 19:09 ---
Created an attachment (id=12205)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12205action=view)
Patch to clear DECL_VALUE_EXPR

This patch fixes the testcase in comment #3 with a cross compiler.  Could
someone with hppa hardware give it a whirl?


-- 


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



[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)

2006-09-07 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-21 12:45:28 |2006-09-07 19:45:38
   date||


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



[Bug java/28972] gcjh does not correctly handle dollar symbol in class name

2006-09-07 Thread raif at swiftdsl dot com dot au


--- Comment #3 from raif at swiftdsl dot com dot au  2006-09-07 19:57 
---
Created an attachment (id=12206)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12206action=view)
JNI header file generated by javah (JDK 1.4.2_12)


-- 


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



[Bug java/28972] gcjh does not correctly handle dollar symbol in class name

2006-09-07 Thread raif at swiftdsl dot com dot au


--- Comment #4 from raif at swiftdsl dot com dot au  2006-09-07 19:58 
---
Created an attachment (id=12207)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12207action=view)
JNI header file generated by javah (JDK 1.5.0_08)


-- 


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



[Bug java/28972] gcjh does not correctly handle dollar symbol in class name

2006-09-07 Thread raif at swiftdsl dot com dot au


--- Comment #5 from raif at swiftdsl dot com dot au  2006-09-07 20:03 
---
comparing the JNI header files, generated by javah in both versions 1.4.2_12
and 1.5.0_08, with that generated by gcjh indicates that gcjh is producing a
similar output.

i'm resolving this PR as invalid.


-- 

raif at swiftdsl dot com dot au changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #19 from jason at gcc dot gnu dot org  2006-09-07 20:24 ---
You can work around this bug with -mpreferred-stack-boundary=4


-- 


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



[Bug middle-end/28970] [4.1 Regression] Wrong code for simple loop test case

2006-09-07 Thread janis at gcc dot gnu dot org


--- Comment #2 from janis at gcc dot gnu dot org  2006-09-07 20:26 ---
A regression hunt on powerpc-linux identified the following patch:

http://gcc.gnu.org/viewcvs?view=revrev=99850

r99850 | rakdver | 2005-05-17 19:55:53 + (Tue, 17 May 2005)


-- 


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



[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #11 from jason at gcc dot gnu dot org  2006-09-07 21:06 ---
Subject: Bug 26957

Author: jason
Date: Thu Sep  7 21:06:28 2006
New Revision: 116760

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116760
Log:
PR c++/26957
* method.c (use_thunk): Clear DECL_HAS_VALUE_EXPR_P on copied
parms.

Added:
trunk/gcc/testsuite/g++.dg/inherit/thunk6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c


-- 


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



[Bug c++/27371] [4.1 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))

2006-09-07 Thread hjl at lucon dot org


--- Comment #6 from hjl at lucon dot org  2006-09-07 21:10 ---
FWIW, g++.dg/warn/unused-result1.C fails:

http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00338.html


-- 


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



[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #12 from jason at gcc dot gnu dot org  2006-09-07 21:23 ---
waiting for feedback.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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



[Bug libfortran/28978] New: Problem compiling gcc 4.1.1

2006-09-07 Thread pierre42d at 9online dot fr
[...]
make[2]: Entering directory
`/tmp/gcc-4.1.1/build/i686-pc-linux-gnu/libgfortran'
/bin/sh ../../../libgfortran/mk-kinds-h.sh '/tmp/gcc-4.1.1/build/./gcc/gfortran
-B/tmp/gcc-4.1.1/build/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/
-B/usr/local/i686-pc-linux-gnu/lib/ -isystem
/usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -I . -Wall -fno-repack-arrays
-fno-underscoring '  kinds.h || rm kinds.h
../../../libgfortran/mk-kinds-h.sh: Unknown type
grep '^#'  kinds.h  kinds.inc
/bin/sh: line 1: kinds.h: No such file or directory
make[2]: *** [kinds.inc] Error 1
make[2]: Leaving directory `/tmp/gcc-4.1.1/build/i686-pc-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/tmp/gcc-4.1.1/build'
make: *** [all] Error 2


-- 
   Summary: Problem compiling gcc 4.1.1
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pierre42d at 9online dot fr


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



[Bug libfortran/28978] Problem compiling gcc 4.1.1

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-07 21:55 ---
../../../libgfortran/mk-kinds-h.sh: Unknown type

This means you have a broken GMP.
Please reinstall GMP and try again.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c++/26696] [4.0/4.1 Regression] ICE with statement forming unused static member function reference

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #7 from jason at gcc dot gnu dot org  2006-09-07 22:27 ---
Subject: Bug 26696

Author: jason
Date: Thu Sep  7 22:27:01 2006
New Revision: 116763

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116763
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/26102
* name-lookup.c (do_class_using_decl): Try to find the base even
if bases_dependent_p.
* pt.c (type_dependent_expression_p): A USING_DECL is dependent.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cvt.c
branches/gcc-4_1-branch/gcc/cp/decl.c
branches/gcc-4_1-branch/gcc/cp/lex.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/cp/semantics.c
branches/gcc-4_1-branch/gcc/cp/tree.c
branches/gcc-4_1-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26671] [4.0/4.1 Regression] Missing warning: reference to local variable returned

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #5 from jason at gcc dot gnu dot org  2006-09-07 22:27 ---
Subject: Bug 26671

Author: jason
Date: Thu Sep  7 22:27:01 2006
New Revision: 116763

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116763
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/26102
* name-lookup.c (do_class_using_decl): Try to find the base even
if bases_dependent_p.
* pt.c (type_dependent_expression_p): A USING_DECL is dependent.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cvt.c
branches/gcc-4_1-branch/gcc/cp/decl.c
branches/gcc-4_1-branch/gcc/cp/lex.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/cp/semantics.c
branches/gcc-4_1-branch/gcc/cp/tree.c
branches/gcc-4_1-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26195] [4.0/4.1 regression] pragma interface no longer handles explicit names

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #14 from jason at gcc dot gnu dot org  2006-09-07 22:27 ---
Subject: Bug 26195

Author: jason
Date: Thu Sep  7 22:27:01 2006
New Revision: 116763

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116763
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/26102
* name-lookup.c (do_class_using_decl): Try to find the base even
if bases_dependent_p.
* pt.c (type_dependent_expression_p): A USING_DECL is dependent.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cvt.c
branches/gcc-4_1-branch/gcc/cp/decl.c
branches/gcc-4_1-branch/gcc/cp/lex.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/cp/semantics.c
branches/gcc-4_1-branch/gcc/cp/tree.c
branches/gcc-4_1-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26571] [4.0/4.1 regression] Bad diagnostic using type modifier with struct

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #4 from jason at gcc dot gnu dot org  2006-09-07 22:27 ---
Subject: Bug 26571

Author: jason
Date: Thu Sep  7 22:27:01 2006
New Revision: 116763

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116763
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/26102
* name-lookup.c (do_class_using_decl): Try to find the base even
if bases_dependent_p.
* pt.c (type_dependent_expression_p): A USING_DECL is dependent.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cvt.c
branches/gcc-4_1-branch/gcc/cp/decl.c
branches/gcc-4_1-branch/gcc/cp/lex.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/cp/semantics.c
branches/gcc-4_1-branch/gcc/cp/tree.c
branches/gcc-4_1-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26102] [4.1 regression] using Base::member nonsense

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #9 from jason at gcc dot gnu dot org  2006-09-07 22:27 ---
Subject: Bug 26102

Author: jason
Date: Thu Sep  7 22:27:01 2006
New Revision: 116763

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116763
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/26102
* name-lookup.c (do_class_using_decl): Try to find the base even
if bases_dependent_p.
* pt.c (type_dependent_expression_p): A USING_DECL is dependent.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cvt.c
branches/gcc-4_1-branch/gcc/cp/decl.c
branches/gcc-4_1-branch/gcc/cp/lex.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/cp/semantics.c
branches/gcc-4_1-branch/gcc/cp/tree.c
branches/gcc-4_1-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/19809] [4.0/4.1 Regression] Multiple definitions of friend functions in template classes

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #12 from jason at gcc dot gnu dot org  2006-09-07 22:27 ---
Subject: Bug 19809

Author: jason
Date: Thu Sep  7 22:27:01 2006
New Revision: 116763

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116763
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/26102
* name-lookup.c (do_class_using_decl): Try to find the base even
if bases_dependent_p.
* pt.c (type_dependent_expression_p): A USING_DECL is dependent.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cvt.c
branches/gcc-4_1-branch/gcc/cp/decl.c
branches/gcc-4_1-branch/gcc/cp/lex.c
branches/gcc-4_1-branch/gcc/cp/name-lookup.c
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/cp/semantics.c
branches/gcc-4_1-branch/gcc/cp/tree.c
branches/gcc-4_1-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26571] [4.0/4.1 regression] Bad diagnostic using type modifier with struct

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #5 from jason at gcc dot gnu dot org  2006-09-07 22:38 ---
Subject: Bug 26571

Author: jason
Date: Thu Sep  7 22:38:03 2006
New Revision: 116764

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116764
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/cvt.c
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/cp/lex.c
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/cp/pt.c
branches/gcc-4_0-branch/gcc/cp/semantics.c
branches/gcc-4_0-branch/gcc/cp/tree.c
branches/gcc-4_0-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/19809] [4.0/4.1 Regression] Multiple definitions of friend functions in template classes

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #13 from jason at gcc dot gnu dot org  2006-09-07 22:38 ---
Subject: Bug 19809

Author: jason
Date: Thu Sep  7 22:38:03 2006
New Revision: 116764

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116764
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/cvt.c
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/cp/lex.c
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/cp/pt.c
branches/gcc-4_0-branch/gcc/cp/semantics.c
branches/gcc-4_0-branch/gcc/cp/tree.c
branches/gcc-4_0-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26195] [4.0/4.1 regression] pragma interface no longer handles explicit names

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #15 from jason at gcc dot gnu dot org  2006-09-07 22:38 ---
Subject: Bug 26195

Author: jason
Date: Thu Sep  7 22:38:03 2006
New Revision: 116764

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116764
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/cvt.c
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/cp/lex.c
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/cp/pt.c
branches/gcc-4_0-branch/gcc/cp/semantics.c
branches/gcc-4_0-branch/gcc/cp/tree.c
branches/gcc-4_0-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26671] [4.0/4.1 Regression] Missing warning: reference to local variable returned

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #6 from jason at gcc dot gnu dot org  2006-09-07 22:38 ---
Subject: Bug 26671

Author: jason
Date: Thu Sep  7 22:38:03 2006
New Revision: 116764

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116764
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/cvt.c
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/cp/lex.c
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/cp/pt.c
branches/gcc-4_0-branch/gcc/cp/semantics.c
branches/gcc-4_0-branch/gcc/cp/tree.c
branches/gcc-4_0-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/26696] [4.0/4.1 Regression] ICE with statement forming unused static member function reference

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #8 from jason at gcc dot gnu dot org  2006-09-07 22:38 ---
Subject: Bug 26696

Author: jason
Date: Thu Sep  7 22:38:03 2006
New Revision: 116764

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116764
Log:
PR c++/26195
* decl.c (make_rtl_for_nonlocal_decl),
(start_preparsed_function): Don't use lbasename on
input_filename when calling get_fileinfo.
* semantics.c (begin_class_definition): Likewise.
* lex.c (cxx_make_type): Likewise.
(handle_pragma_interface): Call get_fileinfo on input_filename,
not on the parameter to the directive.

PR c++/26696
* cvt.c (convert_to_void): Replace a subexpression with no side
effects with void_zero_node.
* tree.c (is_overloaded_fn): Look through COMPONENT_REF.
(get_first_fn): Ditto.
* decl.c (grokdeclarator): No need to look through COMPONENT_REF.

PR c++/26571
* parser.c (cp_parser_diagnose_invalid_type_name): Handle the case
where the name is a type used incorrectly.

PR c++/26671
* typeck.c (maybe_warn_about_returning_address_of_local): Look
through COMPONENT_REF and ARRAY_REF.

PR c++/19809
* pt.c (tsubst_friend_function): Set DECL_INITIAL before pushdecl.

Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/cvt.c
branches/gcc-4_0-branch/gcc/cp/decl.c
branches/gcc-4_0-branch/gcc/cp/lex.c
branches/gcc-4_0-branch/gcc/cp/parser.c
branches/gcc-4_0-branch/gcc/cp/pt.c
branches/gcc-4_0-branch/gcc/cp/semantics.c
branches/gcc-4_0-branch/gcc/cp/tree.c
branches/gcc-4_0-branch/gcc/cp/typeck.c


-- 


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



[Bug c++/27371] [4.1 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #7 from jason at gcc dot gnu dot org  2006-09-07 22:47 ---
Subject: Bug 27371

Author: jason
Date: Thu Sep  7 22:47:34 2006
New Revision: 116765

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116765
Log:
PR c++/27371
* cvt.c (convert_to_void): Enable previous change.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c


-- 


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



[Bug c++/27371] [4.1 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))

2006-09-07 Thread jason at redhat dot com


--- Comment #8 from jason at redhat dot com  2006-09-07 22:50 ---
Subject: Re:  [4.1 Regression] Does not warn about unused function
 result (__attribute__((warn_unused_result)))

Whoops, I checked the patch in disabled.  Fixed.


-- 


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



[Bug testsuite/28969] FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization 2

2006-09-07 Thread dave at hiauly1 dot hia dot nrc dot ca


--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2006-09-07 
22:56 ---
Subject: Re:  FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization
2

 I see this failing on hppa64 as well.

Same here.  When I filed the report, I thought I had seen a codesourcery
build where the test didn't fail.

Dave


-- 


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



[Bug c++/19809] [4.0/4.1 Regression] Multiple definitions of friend functions in template classes

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #14 from jason at gcc dot gnu dot org  2006-09-07 23:03 ---
fixed


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/26102] [4.1 regression] using Base::member nonsense

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #10 from jason at gcc dot gnu dot org  2006-09-07 23:03 ---
fixed


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/26195] [4.0/4.1 regression] pragma interface no longer handles explicit names

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #16 from jason at gcc dot gnu dot org  2006-09-07 23:04 ---
fixed in 4.0, 4.1, 4.2


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/26571] [4.0/4.1 regression] Bad diagnostic using type modifier with struct

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #6 from jason at gcc dot gnu dot org  2006-09-07 23:04 ---
Fixed


-- 


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



[Bug c++/26671] [4.0/4.1 Regression] Missing warning: reference to local variable returned

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #7 from jason at gcc dot gnu dot org  2006-09-07 23:05 ---
Fixed


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/26696] [4.0/4.1 Regression] ICE with statement forming unused static member function reference

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #9 from jason at gcc dot gnu dot org  2006-09-07 23:05 ---
Fixed


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/27371] [4.1 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #9 from jason at gcc dot gnu dot org  2006-09-07 23:07 ---
I don't think this patch is safe enough to backport to 4.1.  Closing.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/26571] [4.0/4.1 regression] Bad diagnostic using type modifier with struct

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #7 from jason at gcc dot gnu dot org  2006-09-07 23:07 ---
now closed, too


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/28886] [4.1 regression] Template specialization with array rejected

2006-09-07 Thread mmitchel at gcc dot gnu dot org


--- Comment #14 from mmitchel at gcc dot gnu dot org  2006-09-08 00:04 
---
Subject: Bug 28886

Author: mmitchel
Date: Fri Sep  8 00:04:42 2006
New Revision: 116768

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116768
Log:
PR c++/28886
* pt.c (unify): Avoid unnecessary calls to fold_build2 for array
dimensions.
PR c++/28886
* g++.dg/template/array16.C: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/array16.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/pt.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/28886] [4.1 regression] Template specialization with array rejected

2006-09-07 Thread mmitchel at gcc dot gnu dot org


--- Comment #15 from mmitchel at gcc dot gnu dot org  2006-09-08 00:05 
---
Fixed in GCC 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #20 from jason at gcc dot gnu dot org  2006-09-08 00:28 ---
Subject: Bug 13685

Author: jason
Date: Fri Sep  8 00:28:30 2006
New Revision: 116775

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116775
Log:
PR target/13685
* config/i386/i386.c (override_options): Use 128-bit
stack boundary if -msse.

Added:
trunk/gcc/testsuite/gcc.target/i386/sse-20.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c


-- 


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



[Bug libgcj/28979] New: GCJ errors out when compiling .class files produced by Scala 2.1.8

2006-09-07 Thread vnasardinov at gmail dot com
I'm getting an error when trying to compile the following classes with
gcj:

 | $ scalac hamming.scala 
 | $ ls -lh *.class
 | -rw-rw-r-- 1 vadim vadim 1.1K Sep  7 20:16 hamming$$anonfun$0.class
 | -rw-rw-r-- 1 vadim vadim 1.1K Sep  7 20:16 hamming$$anonfun$1.class
 | -rw-rw-r-- 1 vadim vadim 1.1K Sep  7 20:16 hamming$$anonfun$2.class
 | -rw-rw-r-- 1 vadim vadim 1.5K Sep  7 20:16
hamming$$anonfun$3$$anonfun$4.class
 | -rw-rw-r-- 1 vadim vadim 1.5K Sep  7 20:16
hamming$$anonfun$3$$anonfun$5.class
 | -rw-rw-r-- 1 vadim vadim 1.5K Sep  7 20:16
hamming$$anonfun$3$$anonfun$6.class
 | -rw-rw-r-- 1 vadim vadim 1.3K Sep  7 20:16 hamming$$anonfun$3.class
 | -rw-rw-r-- 1 vadim vadim  868 Sep  7 20:16 hamming.class
 | -rw-rw-r-- 1 vadim vadim 2.4K Sep  7 20:16 hamming$.class
 | $ jar cf hamming.jar *.class
 | $ gcj --main=hamming
--classpath=/usr/local/scala/share/scala/lib/scala-library.jar hamming.jar 
 | hamming.scala: In class 'hamming$':
 | hamming.scala: In constructor '()':
 | hamming$.java:0: warning: assignment to final static field `MODULE$' not in
class initializer
 | /tmp/cc8cPsFr.s: Assembler messages:
 | /tmp/cc8cPsFr.s:85: Error: symbol `_ZN18hamming$$anonfun$05applyEv' is
already defined
 | /tmp/cc8cPsFr.s:514: Error: symbol `_ZN18hamming$$anonfun$15applyEv' is
already defined
 | /tmp/cc8cPsFr.s:841: Error: symbol `_ZN18hamming$$anonfun$25applyEv' is
already defined
 | /tmp/cc8cPsFr.s:2416: Error: symbol `_ZN18hamming$$anonfun$35applyEv' is
already defined

The .class files were produced by Scala 2.1.8:
  http://scala.epfl.ch/downloads/distrib/files/scala-2.1.8.tar.gz

The above is under the following version of GCJ:

 | $ gcj -v
 | Using built-in specs.
 | Reading specs from /usr/lib/gcc/x86_64-redhat-linux/4.1.1/libgcj.spec
 | rename spec lib to liborig
 | Target: x86_64-redhat-linux
 | Configured with: ../configure --prefix=/usr --mandir=/usr/share/man \
 |   --infodir=/usr/share/info --enable-shared --enable-threads=posix \
 |   --enable-checking=release --with-system-zlib --enable-__cxa_atexit \
 |   --disable-libunwind-exceptions --enable-libgcj-multifile \
 |   --enable-languages=c,c++,objc,obj-c++,java,fortran,ada \
 |   --enable-java-awt=gtk --disable-dssi \
 |   --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre \
 |   --with-cpu=generic --host=x86_64-redhat-linux
 | Thread model: posix
 | gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)

I will attach the offending .jar file in a minute.


-- 
   Summary: GCJ errors out when compiling .class files produced by
Scala 2.1.8
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vnasardinov at gmail dot com


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



[Bug libgcj/28979] GCJ errors out when compiling .class files produced by Scala 2.1.8

2006-09-07 Thread vnasardinov at gmail dot com


--- Comment #1 from vnasardinov at gmail dot com  2006-09-08 00:35 ---
Created an attachment (id=12208)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12208action=view)
hamming.jar

the promised jar file


-- 


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



[Bug libgcj/28979] GCJ errors out when compiling .class files produced by Scala 2.1.8

2006-09-07 Thread vnasardinov at gmail dot com


--- Comment #2 from vnasardinov at gmail dot com  2006-09-08 00:36 ---
Created an attachment (id=12209)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12209action=view)
hamming.scala

the offending Scala program


-- 


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



[Bug java/28979] GCJ errors out when compiling .class files produced by Scala 2.1.8

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-08 00:37 ---
I bet this was fixed in 4.2.0 with the ABI changing patch which changed the ABI
to also include the return type.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|libgcj  |java


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



[Bug middle-end/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #17 from jason at gcc dot gnu dot org  2006-09-08 00:43 ---
I don't think disabling the assertion is enough.  Yes, the compiler would do
the right thing for this particular testcase, but would be wrong if the
subtraction produces a negative result.

Rather, we should stop stripping the conversions in cases where they are
significant.  Testing a patch now.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-05-23 06:51:13 |2006-09-08 00:43:21
   date||


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



[Bug target/27537] XMM alignment fault when compiling for i386 with -Os

2006-09-07 Thread hjl at lucon dot org


--- Comment #12 from hjl at lucon dot org  2006-09-08 00:45 ---


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


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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



[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)

2006-09-07 Thread hjl at lucon dot org


--- Comment #21 from hjl at lucon dot org  2006-09-08 00:45 ---
*** Bug 27537 has been marked as a duplicate of this bug. ***


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 CC||agner at agner dot org


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



[Bug target/28621] [4.1 Regression] SIGSEGV in set_fast_math () at -Os

2006-09-07 Thread hjl at lucon dot org


--- Comment #9 from hjl at lucon dot org  2006-09-08 00:51 ---
Fix for PR 13685 should also fix this bug. In fact, we can back out the
change in comment #3.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

  BugsThisDependsOn|27537   |13685


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



[Bug target/28621] [4.1 Regression] SIGSEGV in set_fast_math () at -Os

2006-09-07 Thread hjl at lucon dot org


--- Comment #10 from hjl at lucon dot org  2006-09-08 00:52 ---
We can even back out the patch and close it as a dup for PR 13685.


-- 


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



[Bug target/28621] [4.1 Regression] SIGSEGV in set_fast_math () at -Os

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #11 from pinskia at gcc dot gnu dot org  2006-09-08 01:18 
---
(In reply to comment #10)
 We can even back out the patch and close it as a dup for PR 13685.
Not really and here is why:
-Os on the file containing main will still crash.  -Os -msse on the file with
main will not crash.


-- 


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



[Bug c++/28906] [4.2 regression] rejects valid arrays

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #13 from pinskia at gcc dot gnu dot org  2006-09-08 02:49 
---
Subject: Bug 28906

Author: pinskia
Date: Fri Sep  8 02:49:11 2006
New Revision: 116776

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116776
Log:
006-09-07  Andrew Pinski  [EMAIL PROTECTED]

PR C++/28906
* init.c (build_new_1): Build a distinct type copy
for the array type that was returned from
build_cplus_array_type.
2006-09-07  Andrew Pinski  [EMAIL PROTECTED]

PR C++/28906
* g++.dg/other/array3.C: New test.
* g++.dg/other/array4.C: New test.
* g++.dg/other/array5.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/other/array3.C
trunk/gcc/testsuite/g++.dg/other/array4.C
trunk/gcc/testsuite/g++.dg/other/array5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/28906] [4.2 regression] rejects valid arrays

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #14 from pinskia at gcc dot gnu dot org  2006-09-08 02:49 
---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug treelang/28980] New: internal compiler error: in tree_low_cst, at tree.c:4423

2006-09-07 Thread mkgnu at mkgnu dot net
internal compiler error: in tree_low_cst, at tree.c:4423

First, If I run this with -E, I get the preprocessed source that I will attach.

vmfreebsd# gcc42 -E -g -I/usr/local/include
-I/root/devel/dynamos/src/shared/include
-I/root/devel/dynamos/src/framework/include
-I/root/devel/dynamos/src/disassembler/slicer/include
-I/root/devel/dynamos/src/os/include -I/root/devel/dynamos/config
-I/root/devel/dynamos/src/libslicer/include -I/root/devel/dynamos/devel/include
-c dynreplace.c  preprocessed_source.c


And now, the bug:

vmfreebsd# gcc42 -g -I/usr/local/include
-I/root/devel/dynamos/src/shared/include
-I/root/devel/dynamos/src/framework/include
-I/root/devel/dynamos/src/disassembler/slicer/include
-I/root/devel/dynamos/src/os/include -I/root/devel/dynamos/config
-I/root/devel/dynamos/src/libslicer/include -I/root/devel/dynamos/devel/include
-c dynreplace.c
dynreplace.c: In function 'dynreplace_add_trampoline':
dynreplace.c:71: warning: incompatible implicit declaration of built-in
function 'memcpy'
dynreplace.c:48: internal compiler error: in tree_low_cst, at tree.c:4423
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.

vmfreebsd# gcc42 --version
gcc42 (GCC) 4.2.0 20060218 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vmfreebsd# uname -a
FreeBSD vmfreebsd.mkgnu.net 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May  7
04:32:43 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386


This is running inside a VMWare virtual machine loaded with FreeBSD 6.1.

No bug occurs when compiling with gcc-2.95 or gcc-3.3.4.


-- 
   Summary: internal compiler error: in tree_low_cst, at tree.c:4423
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: treelang
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkgnu at mkgnu dot net
 GCC build triplet: i386-unknown-freebsd6.1
  GCC host triplet: i386-unknown-freebsd6.1
GCC target triplet: i386-unknown-freebsd6.1


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



[Bug treelang/28980] internal compiler error: in tree_low_cst, at tree.c:4423

2006-09-07 Thread mkgnu at mkgnu dot net


--- Comment #1 from mkgnu at mkgnu dot net  2006-09-08 04:11 ---
Created an attachment (id=12210)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12210action=view)
The preprocessed source that causes this bug.


-- 


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



[Bug treelang/28980] internal compiler error: in tree_low_cst, at tree.c:4423

2006-09-07 Thread mkgnu at mkgnu dot net


--- Comment #2 from mkgnu at mkgnu dot net  2006-09-08 04:14 ---
gcc42 originated from running a:

# pkg_add -r gcc42

in FreeBSD 6.1. This command installed the package gcc-4.2.0_20060218


-- 


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



[Bug middle-end/28980] internal compiler error: in tree_low_cst, at tree.c:4423

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-08 04:20 ---
Well 20060218 is almost 7 months ago but I get a different error with the
mainline as of yesterday:
dynreplace.c:110: internal compiler error: in loc_descriptor_from_tree_1, at
dwarf2out.c:9407
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.


-- 


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



[Bug middle-end/28980] [4.0/4.1/4.2 Regression] ICE with loc_descriptor_from_tree_1 with -g

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2006-09-08 04:31 ---
Reduced testcase:
extern void dynreplace_trampoline(void);
extern void dynreplace_trampoline_endlabel(void);
int dynreplace_add_trampoline(void)
{
  unsigned long trampoline_code[(((unsigned long)
((dynreplace_trampoline_endlabel))
-(unsigned long) (dynreplace_trampoline)))
];
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|internal compiler error: in |[4.0/4.1/4.2 Regression] ICE
   |tree_low_cst, at tree.c:4423|with
   ||loc_descriptor_from_tree_1
   ||with -g
   Target Milestone|--- |4.0.4


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



[Bug middle-end/28980] [4.0/4.1/4.2 Regression] ICE with loc_descriptor_from_tree_1 with -g

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2006-09-08 04:33 ---
Confirmed, note this is semi undefined code.  Really this is a big weird as we
are taking the difference between two function pointers.  I think the ICE with
tree_low_cst has been fixed but the ICE with loc_descriptor_from_tree_1 still
exists.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i386-unknown-freebsd6.1 |
   GCC host triplet|i386-unknown-freebsd6.1 |
 GCC target triplet|i386-unknown-freebsd6.1 |
   Last reconfirmed|-00-00 00:00:00 |2006-09-08 04:33:23
   date||


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



[Bug middle-end/28980] [4.0/4.1/4.2 Regression] ICE with loc_descriptor_from_tree_1 with -g

2006-09-07 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2006-09-08 04:44 ---
This is just like PR 14492 now.

Janis,
  Could you do a regression hunt on when the reduced testcase in comment #4
started to pass without any options?

Thanks,
Andrew


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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



[Bug middle-end/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #18 from jason at gcc dot gnu dot org  2006-09-08 05:11 ---
Subject: Bug 27724

Author: jason
Date: Fri Sep  8 05:11:40 2006
New Revision: 116777

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116777
Log:
PR middle-end/27724
* varasm.c (output_constant): Only strip actual no-op conversions.

Added:
trunk/gcc/testsuite/gcc.dg/long-long-cst1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/varasm.c


-- 


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



[Bug middle-end/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #19 from jason at gcc dot gnu dot org  2006-09-08 05:16 ---
Subject: Bug 27724

Author: jason
Date: Fri Sep  8 05:16:26 2006
New Revision: 116778

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116778
Log:
PR middle-end/27724
* varasm.c (output_constant): Only strip actual no-op conversions.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/long-long-cst1.c
  - copied unchanged from r116777,
trunk/gcc/testsuite/gcc.dg/long-long-cst1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/varasm.c


-- 


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



[Bug middle-end/27724] [4.1 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer

2006-09-07 Thread jason at gcc dot gnu dot org


--- Comment #20 from jason at gcc dot gnu dot org  2006-09-08 05:38 ---
fixed in 4.1 as well.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug middle-end/28493] [4.1/4.2 Regression] Wrong address of stack object used for destructor call on PPC

2006-09-07 Thread jason at gcc dot gnu dot org


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-08-09 00:39:20 |2006-09-08 05:39:30
   date||


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



[Bug target/28924] x86 sync builtins fail for char and short memory operands

2006-09-07 Thread uros at kss-loka dot si


--- Comment #3 from uros at kss-loka dot si  2006-09-08 05:47 ---
I have been playing with following patch to optabs.c that forces operands in
functions expand_sync_operation(), expand_sync_fetch_operation() and
expand_sync_lock_test_and_set() into registers through subregs of word-mode
temp registers. The testcase in the description is then expanded as:

;; __sync_fetch_and_add_1 (s, 255) [tail call]
(insn 10 8 11 (set (reg:SI 58)
(const_int 255 [0xff])) -1 (nil)
(nil))

(insn 11 10 0 (parallel [
(set (mem/v:QI (symbol_ref:SI (s) var_decl 0x402410b0 s) [-1 S1
A8])
(unspec_volatile:QI [
(plus:QI (mem/v:QI (symbol_ref:SI (s) var_decl
0x402410b0 s) [-1 S1 A8])
(subreg:QI (reg:SI 58) 0))
] 13))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

and RTL optimizers are able to optimize this back into:

(insn:HI 11 8 12 2 (parallel [
(set (mem/v:QI (symbol_ref:SI (s) var_decl 0x402410b0 s) [-1 S1
A8])
(unspec_volatile:QI [
(plus:QI (mem/v:QI (symbol_ref:SI (s) var_decl
0x402410b0 s) [-1 S1 A8])
(const_int -1 [0x]))
] 13))
(clobber (reg:CC 17 flags))
]) 924 {sync_addqi} (insn_list:REG_DEP_TRUE 10 (nil))
(nil))

This results in expected asm code:

tests:
lock
addb   $-1, s
ret

However, the patch does not cover all backup code-paths in sync_* expanders, so
in some cases an integer argument can still be forced into register in the
wrong way.

--cut here--
Index: optabs.c
===
--- optabs.c (revision 116739)
+++ optabs.c (working copy)
@@ -6023,7 +6023,7 @@
   if (GET_MODE (val) != VOIDmode  GET_MODE (val) != mode)
val = convert_modes (mode, GET_MODE (val), val, 1);
   if (!insn_data[icode].operand[1].predicate (val, mode))
-   val = force_reg (mode, val);
+   val = gen_lowpart (mode, copy_to_mode_reg (word_mode, val));

   insn = GEN_FCN (icode) (mem, val);
   if (insn)
@@ -6156,7 +6156,7 @@
   if (GET_MODE (val) != VOIDmode  GET_MODE (val) != mode)
val = convert_modes (mode, GET_MODE (val), val, 1);
   if (!insn_data[icode].operand[2].predicate (val, mode))
-   val = force_reg (mode, val);
+   val = gen_lowpart (mode, copy_to_mode_reg (word_mode, val));

   insn = GEN_FCN (icode) (target, mem, val);
   if (insn)
@@ -6243,7 +6243,7 @@
   if (GET_MODE (val) != VOIDmode  GET_MODE (val) != mode)
val = convert_modes (mode, GET_MODE (val), val, 1);
   if (!insn_data[icode].operand[2].predicate (val, mode))
-   val = force_reg (mode, val);
+   val = gen_lowpart (mode, copy_to_mode_reg (word_mode, val));

   insn = GEN_FCN (icode) (target, mem, val);
   if (insn)
--cut here--


-- 


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



  1   2   >