date:20091205

[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*

2009-12-05 Thread howarth at nitro dot med dot uc dot edu



--- Comment #30 from howarth at nitro dot med dot uc dot edu  2009-12-05 
08:21 ---
Confirmed that, as expected, the proposed patch,
http://gcc.gnu.org/ml/java/2009-12/msg00027.html, eliminates the crashes in gcj
in gcc 4.4.2 on x86_64-apple-darwin9 without any other changes.


-- 


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

[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*

2009-12-05 Thread howarth at nitro dot med dot uc dot edu



--- Comment #31 from howarth at nitro dot med dot uc dot edu  2009-12-05 
08:54 ---
Interestingly gcc-4.4.2 with the proposed patch,
http://gcc.gnu.org/ml/java/2009-12/msg00027.html, shows gcj crashing the same
way as gcc trunk with the same patch

(gdb) r testme.java
-fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.4/share/java/libgcj-4.4.2.jar
-fsource=1.5 -ftarget=1.5 -fzip-dependency
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccyWYcT2.zip -fzip-target
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccHDO5f8.jar
Starting program: /sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/ecj1
testme.java
-fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/share/xtal/ccp4-6.1.2/bin/:/sw/lib/gcc4.4/share/java/libgcj-4.4.2.jar
-fsource=1.5 -ftarget=1.5 -fzip-dependency
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccyWYcT2.zip -fzip-target
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccHDO5f8.jar
Reading symbols for shared libraries +. done

Program received signal SIGABRT, Aborted.
0x7fff843d4fe6 in __kill ()
(gdb) bt
#0  0x7fff843d4fe6 in __kill ()
#1  0x7fff84475e32 in abort ()
#2  0x7fff844bffc9 in _Unwind_FindEnclosingFunction ()
#3  0x0001fcbc in gnu::classpath::VMStackWalker::getCallingClassLoader
(pc=0x100980d1c) at
../../../gcc-4.4.2/libjava/gnu/classpath/natVMStackWalker.cc:104
Previous frame inner to this frame (gdb could not unwind past this frame)

So the crash on darwin10 appears to be independent of the libgcc_ext changes
added to gcc trunk.


-- 


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

[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*

2009-12-05 Thread howarth at nitro dot med dot uc dot edu



--- Comment #32 from howarth at nitro dot med dot uc dot edu  2009-12-05 
09:02 ---
Disassembling the crash on gcc-4.4.2 with the proposed patch on
x86_64-apple-darwin10 shows...

(gdb) x/10i 0x0001fcbc
0x1fcbc
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+28>:
 mov%rax,%rbx
0x1fcbf
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+31>:
 callq  0x151e0 <_ZN14_Jv_StackTrace14UpdateNCodeMapEv>
0x1fcc4
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+36>:
 lea0x1bf2f75(%rip),%rax# 0x101c02c40
<_ZN14_Jv_StackTrace8ncodeMapE>
0x1fccb
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+43>:
 mov%rbx,%rsi
0x1fcce
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+46>:
 mov(%rax),%rdi
0x1fcd1
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+49>:
 mov(%rdi),%rdx
0x1fcd4
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+52>:
 callq  *0x60(%rdx)
0x1fcd7
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+55>:
 test   %rax,%rax
0x1fcda
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+58>:
 je 0x1fcf0
<_ZN3gnu9classpath13VMStackWalker21getCallingClassLoaderEJPN4java4lang11ClassLoaderEPNS_3gcj7RawDataE+80>
0x1fcdc
<_ZN4java4lang5Class22getClassLoaderInternalEJPNS0_11ClassLoaderEv>:mov
   0xa8(%rax),%rax
(gdb) 

which is almost identical to what I saw with my previous tests of gcc trunk on
darwin10 and a variation of the -allow_stack_execute fix...

http://gcc.gnu.org/ml/java/2009-12/msg00018.html


-- 


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

[Bug c++/42296] template : missing in analyse of possible constructor

2009-12-05 Thread schwab at linux-m68k dot org



--- Comment #1 from schwab at linux-m68k dot org  2009-12-05 09:14 ---
*** Bug 42297 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/42297] template : missing in analyse of possible constructor

2009-12-05 Thread schwab at linux-m68k dot org



--- Comment #1 from schwab at linux-m68k dot org  2009-12-05 09:14 ---


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


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42296] template : missing in analyse of possible constructor

2009-12-05 Thread paolo dot carlini at oracle dot com



--- Comment #2 from paolo dot carlini at oracle dot com  2009-12-05 09:45 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42272] derived template default argument

2009-12-05 Thread paolo dot carlini at oracle dot com



--- Comment #9 from paolo dot carlini at oracle dot com  2009-12-05 09:45 
---
*** Bug 42296 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/42296] template : missing in analyse of possible constructor

2009-12-05 Thread debian dot templier at free dot fr



--- Comment #3 from debian dot templier at free dot fr  2009-12-05 10:58 
---
missing in analyse of possible constructor :
template <  typename X , typename XT2 = T , typename X2 = typename XT2 :: X >
SMART(SMART & value) : data(value.operator T* ()) {} ;

with X=A XT2=T X2=T::A (X2 is unherited constraint(B is public derived of A ),
XT2 is to delayed analyse of X2 at instanciation)

you must change the resolution state :

there is a probleme of matching with "typename X2 = typename XT2 :: X" =A then
find the constructor possible for analyse in gcc constructors matching miss

the reason is the scope "typename X2 = typename XT2 :: X" with X in "template <
 typename X ... " , i suppose X is not search in template parameter ...

bug 42296 replace 42272


-- 

debian dot templier at free dot fr changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

2009-12-05 Thread janus at gcc dot gnu dot org



--- Comment #9 from janus at gcc dot gnu dot org  2009-12-05 11:20 ---
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.

Confirmed. This may be an initialization issue of the vtypes. Reduced test
case:

module m
  type :: t1
integer :: i = 42
  contains
procedure, pass :: prod => i_m_j
  end type t1
contains
  integer function i_m_j (arg)
class(t1), intent(in) :: arg
print *,"in i_m_j"
i_m_j = 0
  end function i_m_j
end module m

  use m
  class(t1), pointer :: a
  type(t1), target :: b
  integer :: itmp
  a => b
  itmp = a%prod()
  print *, itmp
end


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug ada/41675] GNAT rejects type with 64 bits, claiming it has 65 bits

2009-12-05 Thread dirk dot herrmann-privat at gmx dot de



--- Comment #2 from dirk dot herrmann-privat at gmx dot de  2009-12-05 
11:25 ---
Hello,

thanks for considering the bug.

I checked that the maximum value that could be stored in scalars of type T
would be 0xFF80.  Thus, a representation within 64 bits is
possible.

I have also taken a look at the AARM, where in section 13.3 "Operational and
Representation Attributes"
(http://www.adaic.com/standards/1zaarm/html/AA-13-3.html) paragraphs 54 and 55
it says:

54 {recommended level of support (Size attribute) [partial]} The recommended
level of support for the Size attribute of subtypes is:

55 * The Size (if not specified) of a static discrete or fixed point subtype
should be the number of bits needed to represent each value belonging to the
subtype using an unbiased representation, leaving space for a sign bit only if
the subtype contains negative values. If such a subtype is a first subtype,
then an implementation should support a specified Size for it that reflects
this representation.

So, it may not be a bug, but as I understand it, it would at least be against
the recommendation from the AARM.

Best regards,
Dirk


-- 


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

[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test

2009-12-05 Thread ebotcazou at gcc dot gnu dot org



--- Comment #15 from ebotcazou at gcc dot gnu dot org  2009-12-05 11:34 
---
> The attached change seems to fix the Array_3 linux fail.  Testing a
> similar change for hpux.  However, need to fix the following warnings:
> 
> ../../../gcc/libjava/prims.cc:178:1: warning: unused parameter
> '_dummy'../../../gcc/libjava/prims.cc:178:1: warning: unused parameter
> '_info'../../../gcc/libjava/prims.cc:178:1: warning: unused parameter 'arg'

include/sparc-signal.h has:

#define SIGNAL_HANDLER(_name)   \
static void _name (int _dummy __attribute__ ((__unused__)), \
   siginfo_t *_info __attribute__ ((__unused__)), \
   void *arg __attribute__ ((__unused__)))


-- 


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

[Bug c/42299] New: another verify_ssa failure with -g -O2

2009-12-05 Thread dcb314 at hotmail dot com

I just tried to compile the Linux kernel 2.6.30 with the GNU C compiler
version 4.5 snapshot 20091203 and the compiler said

drivers/scsi/bfa/bfad.c:196:1: error: definition in block 14 does not dominate
use in block 19
for SSA_NAME: rc_4 in statement:
# DEBUG rc => rc_4
drivers/scsi/bfa/bfad.c:196:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flags -O2 -g required.

I know this bug looks similar to #40676, but that was
fixed months ago.


-- 
   Summary: another verify_ssa failure with -g -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c/42299] another verify_ssa failure with -g -O2

2009-12-05 Thread dcb314 at hotmail dot com



--- Comment #1 from dcb314 at hotmail dot com  2009-12-05 11:36 ---
Created an attachment (id=19236)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19236&action=view)
gzipped C source code


-- 


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

2009-12-05 Thread ebotcazou at gcc dot gnu dot org



--- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-12-05 12:11 
---
Reopening, this happens on Solaris 8 as well:

This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) set args libgcc2.i -O
(gdb) run
Starting program: /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/gcc/cc1
libgcc2.i -O
 __muldi3
Analyzing compilation unit
Performing interprocedural optimizations
  <*free_lang_data> 
Program received signal SIGSEGV, Segmentation fault.
0x01258a98 in compare_access_positions (a=0x256ff7c, b=0x256ff84)
at /nile.build/botcazou/gcc-head/src/gcc/tree-sra.c:1114
1114  if (f1->offset != f2->offset)
(gdb) bt
#0  0x01258a98 in compare_access_positions (a=0x256ff7c, b=0x256ff84)
at /nile.build/botcazou/gcc-head/src/gcc/tree-sra.c:1114
#1  0xff2cb8ec in qsort () from /usr/lib/libc.so.1
#2  0x0125a15c in sort_and_splice_var_accesses (var=0xff145aa0)
at /nile.build/botcazou/gcc-head/src/gcc/tree-sra.c:1426

It's a known issue on Solaris 8 when the comparer function returns inconsistent
results, i.e. when it fails to impose a total order on the array.  Given its
complexity, that isn't very suprising and should be fixed.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
  GCC build triplet|mips-sgi-irix5.3|
   GCC host triplet|mips-sgi-irix5.3|
 GCC target triplet|mips-sgi-irix5.3|
Summary|[4.5 regression] ICE|[4.5 regression] ICE
   |building stage 1 libgcc on  |building stage 1 libgcc:
   |IRIX 5.3: SEGV in   |SEGV in
   |compare_access_positions|compare_access_positions


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

2009-12-05 Thread ebotcazou at gcc dot gnu dot org



--- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-12-05 12:12 
---
Reopened.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug other/42280] libiberty configure script fails checking pid_t when without-headers

2009-12-05 Thread viriketo at gmail dot com



--- Comment #5 from viriketo at gmail dot com  2009-12-05 12:34 ---
Sorry for not posting the full log before, but I noticed that the failing
target is "configure-target-libiberty".

I don't understand how libiberty can be built for the target when building a
cross compiler "--without-headers", because it requires system libraries.
Shouldn't "target-libiberty" be disabled under cross-compilation without
headers?

I see that under the same configure parameters, in 4.3.4, target-libiberty is
not built (looking at build logs).


-- 


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

2009-12-05 Thread ebotcazou at gcc dot gnu dot org



--- Comment #6 from ebotcazou at gcc dot gnu dot org  2009-12-05 12:39 
---
The problem is that the comparison of types is not anti-symmetrical:

(gdb) call compare_access_positions(&access_vec->base.vec[2],
&access_vec->base.vec[3])
$37 = 1
(gdb) call compare_access_positions(&access_vec->base.vec[3],
&access_vec->base.vec[2])
$38 = 1

(gdb) call compare_access_positions(&access_vec->base.vec[2],
&access_vec->base.vec[2])
$39 = 1

(gdb) p debug_tree(access_vec->base.vec[2]->type)
 
constant 32>
unit size 
constant 4>
align 32 symtab 0 alias set -1 canonical type ff0242a0 precision 32 min
 max >

(gdb) p debug_tree(access_vec->base.vec[3]->type)
 
constant 32>
unit size 
constant 4>
align 32 symtab 0 alias set -1 canonical type ff0242a0 precision 32 min
 max >


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-05 12:39:08
   date||


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

2009-12-05 Thread ebotcazou at gcc dot gnu dot org



-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |major


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

[Bug debug/41371] [4.5 Regression] -g causes compiler to hang

2009-12-05 Thread dcb314 at hotmail dot com



--- Comment #5 from dcb314 at hotmail dot com  2009-12-05 12:50 ---
(In reply to comment #3)
> Reconfirmed.

It seems to be still broken in snapshot 20091203


-- 


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

[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures

2009-12-05 Thread dominiq at lps dot ens dot fr



--- Comment #25 from dominiq at lps dot ens dot fr  2009-12-05 12:54 ---
If there is no objection, I'll close tomorrow this pr as fixed. The failure of
libffi.call/nested_struct5.c is pr34311 (Opened: 2007-12-01) and I'll open a
new pr for the failures of libffi.call/cls_*double_va.c.


-- 


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

[Bug c/42299] another verify_ssa failure with -g -O2

2009-12-05 Thread hjl dot tools at gmail dot com



--- Comment #2 from hjl dot tools at gmail dot com  2009-12-05 12:58 ---
It is caused by revision 154402:

http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00623.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-05 12:58:18
   date||


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

[Bug other/36595] Multiple warnings about C++ for C codes

2009-12-05 Thread dominiq at lps dot ens dot fr



--- Comment #2 from dominiq at lps dot ens dot fr  2009-12-05 13:10 ---
I no longer see these warnings on trunk at revisions above 154978 on
*-apple-darwin*. Closing as fixed.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

2009-12-05 Thread dominiq at lps dot ens dot fr



--- Comment #10 from dominiq at lps dot ens dot fr  2009-12-05 13:31 ---
With the patch in comment #7 the tests gfortran.dg/class_9.f03 and
gfortran.dg/dynamic_dispatch_[1-6].f03 also give a segfault at runtime.


-- 


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

[Bug other/42280] libiberty configure script fails checking pid_t when without-headers

2009-12-05 Thread viriketo at gmail dot com



--- Comment #6 from viriketo at gmail dot com  2009-12-05 14:03 ---
Ok, I traced the problem down. The main change between 4.3.4 and 4.4.1 that
triggered the problem was the addition of 'zlib' in the core package (what I am
trying to build).

The configure script has the following logic around line 5370:
# Sometimes the tools are distributed with libiberty but with no other
# libraries.  In that case, we don't want to build target-libiberty.
# Don't let libgcc imply libiberty either.
if test -n "${target_configdirs}" ; then
  libgcc=
  others=
  for i in `echo ${target_configdirs} | sed -e s/target-//g` ; do
if test "$i" = "libgcc"; then
  libgcc=target-libgcc
elif test "$i" != "libiberty" ; then # OFFENDING CHECK
  if test -r $srcdir/$i/configure ; then
others=yes;
break;
  fi
fi
  done
  if test -z "${others}" ; then
target_configdirs=$libgcc  # This happens only if 'zlib' is not there - and
this line should be run in my use case.
  fi
fi

So, I can't really propose a patch. What I did to get gcc 4.4.2 building is
remove the zlib directory after unpacking the core package.

I don't know the packaging procedure of gcc, but this concerns this procedure.
I don't know what status apply to the bug.


-- 


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

[Bug libfortran/41711] BOZ format does not support reading large kind reals

2009-12-05 Thread dominiq at lps dot ens dot fr



--- Comment #14 from dominiq at lps dot ens dot fr  2009-12-05 14:29 ---
> According to a note I spotted on clf , reading and writing reals with BOZ is
> invalid, so what we are doing here is an extension. 

Do you have a pointer? Also the extension should probably be documented. 

> I am tempted to just close this one and do no more.
>
> Any opinions?

On 64 bit platforms, the read can also be fixed by a simple patch like the one
in comment #1 (at some point I have even tested it). Since 64 bit platforms are
becoming the mainstream, I think this fix could be good enough. The dirty
details to implement the read on 32 bit platforms probably do not worth the
required work.


-- 


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

[Bug other/42280] libiberty configure script fails checking pid_t when without-headers

2009-12-05 Thread rearnsha at gcc dot gnu dot org



--- Comment #7 from rearnsha at gcc dot gnu dot org  2009-12-05 14:37 
---
There probably is no patch.  If you are building a compiler with no headers,
then you can't just type 'make' and expect it to work.

Instead you must just build those targets you really need (like the core
compiler)

I tend to use make all-gcc in those circumstances.  You build and install a
compiler binary, then build and install your system headers and then finally go
back and build the support libraries you need.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug other/42280] libiberty configure script fails checking pid_t when without-headers

2009-12-05 Thread viriketo at gmail dot com



--- Comment #8 from viriketo at gmail dot com  2009-12-05 14:49 ---
As I said in a previous comment, removing the 'zlib' subdirectory (not included
in releases older than 4.4.2) made "make all" and "make installl" work
perfectly.


-- 


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

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

2009-12-05 Thread burnus at gcc dot gnu dot org



--- Comment #15 from burnus at gcc dot gnu dot org  2009-12-05 15:01 ---
(In reply to comment #14)
> > According to a note I spotted on clf , reading and writing reals with BOZ is
> > invalid, so what we are doing here is an extension. 
> Do you have a pointer?

I have the following:

"10.6.1 Numeric editing"
"The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify
the input/output of integer, real, and complex data."
[...]
"(6) On output, with I, B, O, Z, and F editing, the specified value of the
field width w may be zero. In such cases, the processor selects the smallest
positive actual field width that does not result in a field filled with
asterisks. The specified value of w shall not be zero on input."

Thus it looks valid also for non-integers. However, going on one finds that the
B, O, & Z edit descriptors are only mentioned in "10.6.1.1 Integer editing"
whereas "10.6.1.2 Real and complex editing" starts with "The F, E, EN, ES, and
D edit descriptors specify the editing of real and complex data. [...] The G
edit descriptor also may be used to edit real and complex data."

Thus, combining the two, using BOZ edit descriptors is invalid in F95/F2003.
How about F2008? The first quote is essentially the same but one finds there:

"10.7.2.3 Real and complex editing": "The G, B, O, and Z edit
descriptors also may be used to edit real and complex data (10.7.5.2.2,
10.7.2.4)."


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-05 15:01:04
   date||
Summary|BOZ format does not support |[F2008] BOZ format does not
   |reading large kind reals|support reading large kind
   ||reals


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

2009-12-05 Thread janus at gcc dot gnu dot org



--- Comment #11 from janus at gcc dot gnu dot org  2009-12-05 15:14 ---
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.

Since these run fine with a clean fortran-dev, this is a regression of my
patch, more exactly of the following part:

Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 154956)
+++ gcc/fortran/symbol.c(working copy)
@@ -4751,6 +4751,7 @@ add_proc_component (gfc_component *c, gfc_symbol *
   if (!c->tb)
 c->tb = XCNEW (gfc_typebound_proc);
   *c->tb = *st->n.tb;
+  c->tb->ppc = 1;
   c->attr.procedure = 1;
   c->attr.proc_pointer = 1;
   c->attr.flavor = FL_PROCEDURE;

However, I fail to see why. Paul, do you have an idea?


-- 


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

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

2009-12-05 Thread dominiq at lps dot ens dot fr



--- Comment #12 from dominiq at lps dot ens dot fr  2009-12-05 16:41 ---
Removing the line outlined in comment#11, slightly improve the situation:
class_9.f03 and dynamic_dispatch_5.f03, and the test in comment #9 now pass and
I get for pr41829.f90:

[macbook] f90/bug% gfc pr41829.f90 
[macbook] f90/bug% a.out 
 FOO%DOIT base version
 Getit value :1
Segmentation fault


-- 


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

[Bug c/42300] New: Having LIBRARY_PATH set but with null contents, makes gcc read ./specs

2009-12-05 Thread viriketo at gmail dot com

I think that a LIBRARY_PATH set, but without any contents (as done in shell
with LIBRARY_PATH= ) will make gcc read the specs file from the directory '.'.
Having no LIBRARY_PATH in the environment does not make gcc read ./specs.

For example. this can break the build of a cross-compiler with g++, because the
g++ is compiled with the build gcc after building the cross-gcc, which created
a 'specs' file in the current directory (build/gcc).
In this build, the built-in specs in the build gcc should be used, and not
those of the cross compiler (./specs).

This can be reproduced trying to make a g++ cross-compiler with the
LIBRARY_PATH environment variable set but with a null string content.

I could reproduce this with gcc 4.3.4 too, either a native or a cross compiler.

If it is a feature, I think the LIBRARY_PATH section in the gcc manual should
explain about this, because I would expect this behaviour only under
LIBRARY_PATH=.


-- 
   Summary: Having LIBRARY_PATH set but with null contents, makes
gcc read ./specs
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: viriketo at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux or any target for a cross-compiler


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

2009-12-05 Thread jvdelisle at gcc dot gnu dot org



--- Comment #19 from jvdelisle at gcc dot gnu dot org  2009-12-05 17:01 
---
Try this patch:

Index: data.c
===
--- data.c  (revision 155006)
+++ data.c  (working copy)
@@ -497,7 +497,13 @@ gfc_assign_data_value_range (gfc_expr *lvalue, gfc
  expr->expr_type = EXPR_ARRAY;
  expr->rank = ref->u.ar.as->rank;
}
- else
+ else if (expr->expr_type != EXPR_ARRAY)
+   {
+ gfc_error ("Duplicate initialization at %L",
+&expr->where);;
+ return;
+   }
+
gcc_assert (expr->expr_type == EXPR_ARRAY);

  if (ref->u.ar.type == AR_ELEMENT)
@@ -558,8 +564,12 @@ gfc_assign_data_value_range (gfc_expr *lvalue, gfc
   pred->next = con;
}
}
- else
-   gcc_assert (ref->next != NULL);
+ else if (ref->next == NULL)
+   {
+ gfc_error ("Duplicate initialization at %L",
+&rvalue->where);;
+ return;
+   }
  break;

case REF_COMPONENT:


-- 


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

[Bug pending/41998] GCC 4.6 pending patches meta-bug

2009-12-05 Thread aesok at gcc dot gnu dot org



--- Comment #5 from aesok at gcc dot gnu dot org  2009-12-05 17:15 ---
Patch to turn TARGET_FUNCTION_VALUE_REGNO_P macro into a hook.

http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00729.html


-- 


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

[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library

2009-12-05 Thread rwild at gcc dot gnu dot org



--- Comment #2 from rwild at gcc dot gnu dot org  2009-12-05 17:19 ---
Subject: Bug 40972

Author: rwild
Date: Sat Dec  5 17:18:53 2009
New Revision: 155012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155012
Log:
Sync from git Libtool and regenerate.

/:
PR target/38384
PR bootstrap/40972
* libtool.m4: Sync from git Libtool.
* ltoptions.m4: Likewise.
* ltversion.m4: Likewise.
* lt~obsolete.m4: Likewise.
* ltmain.sh: Likewise.

boehm-gc/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* include/Makefile.in: Regenerate.

fixincludes/:
* configure: Regenerate.

gcc/:
* configure: Regenerate.

libffi/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* include/Makefile.in: Regenerate.
* man/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

libgfortran/:
* Makefile.in: Regenerate.
* configure: Regenerate.

libgomp/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.in: Regenerate.

libjava/classpath/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.
* doc/api/Makefile.in: Regenerate.
* examples/Makefile.in: Regenerate.
* external/Makefile.in: Regenerate.
* external/jsr166/Makefile.in: Regenerate.
* external/relaxngDatatype/Makefile.in: Regenerate.
* external/sax/Makefile.in: Regenerate.
* external/w3c_dom/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* lib/Makefile.in: Regenerate.
* native/Makefile.in: Regenerate.
* native/fdlibm/Makefile.in: Regenerate.
* native/jawt/Makefile.in: Regenerate.
* native/jni/Makefile.in: Regenerate.
* native/jni/classpath/Makefile.in: Regenerate.
* native/jni/gconf-peer/Makefile.in: Regenerate.
* native/jni/gstreamer-peer/Makefile.in: Regenerate.
* native/jni/gtk-peer/Makefile.in: Regenerate.
* native/jni/java-io/Makefile.in: Regenerate.
* native/jni/java-lang/Makefile.in: Regenerate.
* native/jni/java-math/Makefile.in: Regenerate.
* native/jni/java-net/Makefile.in: Regenerate.
* native/jni/java-nio/Makefile.in: Regenerate.
* native/jni/java-util/Makefile.in: Regenerate.
* native/jni/midi-alsa/Makefile.in: Regenerate.
* native/jni/midi-dssi/Makefile.in: Regenerate.
* native/jni/native-lib/Makefile.in: Regenerate.
* native/jni/qt-peer/Makefile.in: Regenerate.
* native/jni/xmlj/Makefile.in: Regenerate.
* native/plugin/Makefile.in: Regenerate.
* resource/Makefile.in: Regenerate.
* scripts/Makefile.in: Regenerate.
* tools/Makefile.in: Regenerate.

libjava/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* gcj/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

libmudflap/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.in: Regenerate.

libobjc/:
* configure: Regenerate.

libssp/:
* Makefile.in: Regenerate.
* configure: Regenerate.

libstdc++-v3/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* libsupc++/Makefile.in: Regenerate.
* po/Makefile.in: Regenerate.
* python/Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

lto-plugin/:
* configure: Regenerate.
* Makefile.in: Regenerate.

zlib/:
* Makefile.in: Regenerate.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/boehm-gc/ChangeLog
trunk/boehm-gc/Makefile.in
trunk/boehm-gc/configure
trunk/boehm-gc/include/Makefile.in
trunk/fixincludes/ChangeLog
trunk/fixincludes/configure
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/libffi/ChangeLog
trunk/libffi/Makefile.in
trunk/libffi/configure
trunk/libffi/include/Makefile.in
trunk/libffi/man/Makefile.in
trunk/libffi/testsuite/Makefile.in
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.in
trunk/libgfortran/configure
trunk/libgomp/ChangeLog
trunk/libgomp/Makefile.in
trunk/libgomp/configure
trunk/libgomp/testsuite/Makefile.in
trunk/libjava/ChangeLog
trunk/libjava/Makefile.in
trunk/libjava/classpath/ChangeLog
trunk/libjava/classpath/Makefile.in
trunk/libjava/classpath/configure
trunk/libjava/classpath/doc/Makefile.in
trunk/libjava/classpath/doc/api/Makefile.in
trunk/libjava/classpath/examples/Makefile.in
trunk/libjava/classpath/external/Makefile.in
trunk/libjava/classpath/external/jsr166/Makefile.in
trunk/libjava/classpat

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

2009-12-05 Thread rwild at gcc dot gnu dot org



--- Comment #49 from rwild at gcc dot gnu dot org  2009-12-05 17:19 ---
Subject: Bug 38384

Author: rwild
Date: Sat Dec  5 17:18:53 2009
New Revision: 155012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155012
Log:
Sync from git Libtool and regenerate.

/:
PR target/38384
PR bootstrap/40972
* libtool.m4: Sync from git Libtool.
* ltoptions.m4: Likewise.
* ltversion.m4: Likewise.
* lt~obsolete.m4: Likewise.
* ltmain.sh: Likewise.

boehm-gc/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* include/Makefile.in: Regenerate.

fixincludes/:
* configure: Regenerate.

gcc/:
* configure: Regenerate.

libffi/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* include/Makefile.in: Regenerate.
* man/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

libgfortran/:
* Makefile.in: Regenerate.
* configure: Regenerate.

libgomp/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.in: Regenerate.

libjava/classpath/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.
* doc/api/Makefile.in: Regenerate.
* examples/Makefile.in: Regenerate.
* external/Makefile.in: Regenerate.
* external/jsr166/Makefile.in: Regenerate.
* external/relaxngDatatype/Makefile.in: Regenerate.
* external/sax/Makefile.in: Regenerate.
* external/w3c_dom/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* lib/Makefile.in: Regenerate.
* native/Makefile.in: Regenerate.
* native/fdlibm/Makefile.in: Regenerate.
* native/jawt/Makefile.in: Regenerate.
* native/jni/Makefile.in: Regenerate.
* native/jni/classpath/Makefile.in: Regenerate.
* native/jni/gconf-peer/Makefile.in: Regenerate.
* native/jni/gstreamer-peer/Makefile.in: Regenerate.
* native/jni/gtk-peer/Makefile.in: Regenerate.
* native/jni/java-io/Makefile.in: Regenerate.
* native/jni/java-lang/Makefile.in: Regenerate.
* native/jni/java-math/Makefile.in: Regenerate.
* native/jni/java-net/Makefile.in: Regenerate.
* native/jni/java-nio/Makefile.in: Regenerate.
* native/jni/java-util/Makefile.in: Regenerate.
* native/jni/midi-alsa/Makefile.in: Regenerate.
* native/jni/midi-dssi/Makefile.in: Regenerate.
* native/jni/native-lib/Makefile.in: Regenerate.
* native/jni/qt-peer/Makefile.in: Regenerate.
* native/jni/xmlj/Makefile.in: Regenerate.
* native/plugin/Makefile.in: Regenerate.
* resource/Makefile.in: Regenerate.
* scripts/Makefile.in: Regenerate.
* tools/Makefile.in: Regenerate.

libjava/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* gcj/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

libmudflap/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.in: Regenerate.

libobjc/:
* configure: Regenerate.

libssp/:
* Makefile.in: Regenerate.
* configure: Regenerate.

libstdc++-v3/:
* Makefile.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* libsupc++/Makefile.in: Regenerate.
* po/Makefile.in: Regenerate.
* python/Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

lto-plugin/:
* configure: Regenerate.
* Makefile.in: Regenerate.

zlib/:
* Makefile.in: Regenerate.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/boehm-gc/ChangeLog
trunk/boehm-gc/Makefile.in
trunk/boehm-gc/configure
trunk/boehm-gc/include/Makefile.in
trunk/fixincludes/ChangeLog
trunk/fixincludes/configure
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/libffi/ChangeLog
trunk/libffi/Makefile.in
trunk/libffi/configure
trunk/libffi/include/Makefile.in
trunk/libffi/man/Makefile.in
trunk/libffi/testsuite/Makefile.in
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.in
trunk/libgfortran/configure
trunk/libgomp/ChangeLog
trunk/libgomp/Makefile.in
trunk/libgomp/configure
trunk/libgomp/testsuite/Makefile.in
trunk/libjava/ChangeLog
trunk/libjava/Makefile.in
trunk/libjava/classpath/ChangeLog
trunk/libjava/classpath/Makefile.in
trunk/libjava/classpath/configure
trunk/libjava/classpath/doc/Makefile.in
trunk/libjava/classpath/doc/api/Makefile.in
trunk/libjava/classpath/examples/Makefile.in
trunk/libjava/classpath/external/Makefile.in
trunk/libjava/classpath/external/jsr166/Makefile.in
trunk/libjava/classpa

[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test

2009-12-05 Thread danglin at gcc dot gnu dot org

--- Comment #16 from danglin at gcc dot gnu dot org  2009-12-05 17:46 
---
Subject: Bug 41912

Author: danglin
Date: Sat Dec  5 17:45:59 2009
New Revision: 155013

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155013
Log:
PR ada/41912
* pa/linux-unwind.h (pa32_fallback_frame_state): Set fs->signal_frame
for signal frames.
* pa/hpux-unwind.h (pa32_fallback_frame_state): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/hpux-unwind.h
trunk/gcc/config/pa/linux-unwind.h

-- 

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

[Bug c++/42301] New: Segmentation fault during brace initialization of an empty vector of tuples.

2009-12-05 Thread kgsmith at gmail dot com

I built gcc-4.4.2 from source with "../gcc-4.4.2/configure --prefix=/my/path"
and no other modifications.  I built it with gmp-4.3.1.tar.bz2 and
mpfr-2.4.1.tar.bz2.

Here is the source file that triggers the bug.

#include 
#include 

const std::vector> input {};
EOF

Here is the compile command and resultant output.

g++ --save-temps -std=c++0x -c -g -I/usr/local/include main.cpp -o main.o
main.cpp:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I will upload the .ii file next.


-- 
   Summary: Segmentation fault during brace initialization of an
empty vector of tuples.
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgsmith at gmail dot com
 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=42301

[Bug c++/42301] Segmentation fault during brace initialization of an empty vector of tuples.

2009-12-05 Thread kgsmith at gmail dot com



--- Comment #1 from kgsmith at gmail dot com  2009-12-05 18:03 ---
Created an attachment (id=19237)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19237&action=view)
saved intermediate compiler output

autogenerated file


-- 


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

[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library

2009-12-05 Thread ktietz at gcc dot gnu dot org



--- Comment #3 from ktietz at gcc dot gnu dot org  2009-12-05 18:16 ---
hmm, I still don't see in gcc's root in libtool.m4 the patch for detecting
x64_64 archives. Did I miss here something?

Cheers,
Kai


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu dot
   ||org


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

[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library

2009-12-05 Thread Ralf dot Wildenhues at gmx dot de



--- Comment #4 from Ralf dot Wildenhues at gmx dot de  2009-12-05 18:20 
---
Subject: Re:  libtool fails to detect pe-x86-64 import
 library

* ktietz at gcc dot gnu dot org wrote on Sat, Dec 05, 2009 at 07:16:12PM CET:
> hmm, I still don't see in gcc's root in libtool.m4 the patch for detecting
> x64_64 archives. Did I miss here something?

The patch in #1 is in ltmain.sh.  Did you mean another patch?


-- 


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

[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95

2009-12-05 Thread tkoenig at gcc dot gnu dot org



--- Comment #6 from tkoenig at gcc dot gnu dot org  2009-12-05 18:28 ---
$ cat huhu.f90
CHARACTER (kind=4,len=*) MY_STRING4(1:3), my_string_s4
PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) )
end
$ gfortran huhu.f90
huhu.f90:1.54:

CHARACTER (kind=4,len=*) MY_STRING4(1:3), my_string_s4
  1
Error: Entity with assumed character length at (1) must be a dummy argument or
a PARAMETER

Changing the len=* to len=1 removes that error.

Let's commit a modified test case and close the bug.


-- 


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

[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library

2009-12-05 Thread ktietz at gcc dot gnu dot org



--- Comment #5 from ktietz at gcc dot gnu dot org  2009-12-05 18:31 ---
I meant in libtool.m4, too:

We have here:
mingw* | pw32*)
  # Base MSYS/MinGW do not provide the 'file' command needed by
  # func_win32_libid shell function, so use a weaker test based on 'objdump',
  # unless we find 'file', for example because we are cross-compiling.
  # func_win32_libid assumes BSD nm, so disallow it if using MS dumpbin.
  if ( test "$lt_cv_nm_interface" = "BSD nm" && file / ) >/dev/null 2>&1; then
lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'

lt_cv_file_magic_cmd='func_win32_libid'
  else
lt_cv_deplibs_check_method='file_magic file format
pei*-i386(.*architecture: i386)?'
lt_cv_file_magic_cmd='$OBJDUMP -f'
  fi
  ;;

But well, this is not about library, so my fault. It is about shared libraries.

Cheers,
Kai


-- 


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

[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test

2009-12-05 Thread ebotcazou at gcc dot gnu dot org



--- Comment #17 from ebotcazou at gcc dot gnu dot org  2009-12-05 18:32 
---
Patch installed.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||12/msg00315.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95

2009-12-05 Thread burnus at gcc dot gnu dot org



--- Comment #7 from burnus at gcc dot gnu dot org  2009-12-05 18:54 ---
(In reply to comment #5)
> It looks like this is fixed.  I could not reproduce the problem.

I still get this problem:

$ cat fhjfff.f90
CHARACTER (kind=4,len=*) MY_STRING4(1:3)
PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) )
end

$ gfortran -pedantic fhjfff.f90
fhjfff.f90:2.45:

PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) )
 1
Warning: Obsolescent feature: CHARACTER(*) function '__convert_s1_s4' at (1)


-- 


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

[Bug fortran/40766] this fortran program is too slow

2009-12-05 Thread burnus at gcc dot gnu dot org



--- Comment #17 from burnus at gcc dot gnu dot org  2009-12-05 19:01 ---
(In reply to comment #16)
> This is a glibc issue with software sin function.

AMD has some patches for this, which are seemingly only used by (open)SUSE's
glibc. Try http://developer.amd.com/CPU/LIBRARIES/LIBM/Pages/default.aspx
(The source can be found in the repository of Open64.)


-- 


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

[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library

2009-12-05 Thread ktietz at gcc dot gnu dot org



--- Comment #6 from ktietz at gcc dot gnu dot org  2009-12-05 19:21 ---
(In reply to comment #4)
> Subject: Re:  libtool fails to detect pe-x86-64 import
>  library
> 
> * ktietz at gcc dot gnu dot org wrote on Sat, Dec 05, 2009 at 07:16:12PM CET:
> > hmm, I still don't see in gcc's root in libtool.m4 the patch for detecting
> > x64_64 archives. Did I miss here something?
> 
> The patch in #1 is in ltmain.sh.  Did you mean another patch?
> 

What I missed to say. Many thanks for your hard work.

I think we can close this bug, can't we?

Cheers,
Kai


-- 


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

[Bug c++/42302] New: compiler accepts calling private c++ constructor from outside of the class

2009-12-05 Thread csaba dot fekete at blck dot org

Hi,

The code below can be compiled without any complain from the compiler:

class A {
private:
A() {};
};

int main(int argc, char *argv[]) {
A a;
}

Thanks,
Csaba


-- 
   Summary: compiler accepts calling private c++ constructor from
outside of the class
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csaba dot fekete at blck dot org


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

[Bug c++/42296] template : missing in analyse of possible constructor

2009-12-05 Thread paolo dot carlini at oracle dot com



--- Comment #4 from paolo dot carlini at oracle dot com  2009-12-05 19:32 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42272] derived template default argument

2009-12-05 Thread paolo dot carlini at oracle dot com



--- Comment #10 from paolo dot carlini at oracle dot com  2009-12-05 19:32 
---
*** Bug 42296 has been marked as a duplicate of this bug. ***


-- 


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

[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library

2009-12-05 Thread Ralf dot Wildenhues at gmx dot de



--- Comment #7 from Ralf dot Wildenhues at gmx dot de  2009-12-05 19:46 
---
Subject: Re:  libtool fails to detect pe-x86-64 import
 library

* ktietz at gcc dot gnu dot org wrote on Sat, Dec 05, 2009 at 07:31:22PM CET:
> I meant in libtool.m4, too:
> 
> We have here:
> mingw* | pw32*)

>   if ( test "$lt_cv_nm_interface" = "BSD nm" && file / ) >/dev/null 2>&1; then
> lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
> 
> lt_cv_file_magic_cmd='func_win32_libid'

Well, if this needs changed, then please report it upstream on the
bug-libtool list.  I cannot test your system, so we rely on feedback.


-- 


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

[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library

2009-12-05 Thread rwild at gcc dot gnu dot org



--- Comment #8 from rwild at gcc dot gnu dot org  2009-12-05 19:47 ---
Fixed.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/42303] New: Shift left as wide as mode is expanded into RTL as shift

2009-12-05 Thread hutchinsonandy at gcc dot gnu dot org

Shift LEFT by the full length of integer is carried through to RTL as shift - 
rather than being ZERO.

This hidden zero prevents further optimization. For example x = a + (B<<16)
should be reduced to x = a. Instead we get x = 0 | a;
This can also be seen in rotate expressions.



int16_t shiftzero(uint16_t x,uint16_t y)
{
return x + (y<<16);
}




shiftzero (uint16_tD. xD., uint16_tD. yD.)
{
  uint16_tD. D.;
  uint16_tD. D.;
  int16_tD. D.;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D._2 = yD._1(D) << 16;
  D._4 = D._2 + xD._3(D);
  D._5 = (int16_tD.) D._4;
  return D._5;
  # SUCC: EXIT [100.0%] 

}






/* NOTE Same on rotate - since expander is uses shift */
int16_t rotatezero(uint16_t x,uint16_t y)
{
return ROTATE (x,16);
}

rotatezero (uint16_tD. xD., uint16_tD. yD.)
{
  uint16_tD. D.;
  uint16_tD. D.;
  int16_tD. D.;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D._2 = xD._1(D) << 16;
  D._3 = D._2 | xD._1(D);
  D._4 = (int16_tD.) D._3;
  return D._4;
  # SUCC: EXIT [100.0%] 

}


-- 
   Summary: Shift left as wide as mode is expanded into RTL as shift
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-unknown-none


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

[Bug c++/42301] Segmentation fault during brace initialization of an empty vector of tuples.

2009-12-05 Thread paolo dot carlini at oracle dot com



-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.4.2
  Known to work||4.4.1 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-12-05 20:19:09
   date||


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

[Bug target/42287] xgcc: Internal error: Segmentation fault (program as)

2009-12-05 Thread mark at advancedtechcorp dot com



--- Comment #4 from mark at advancedtechcorp dot com  2009-12-05 20:33 
---
(In reply to comment #3)
> Which would be http://sourceware.org/bugzilla/
> 

Sorry, I'm getting old.  I read the instructions in the config log that stated:

 "Please submit a full bug report.  See  for
instructions".  So, looking at that page it says:

"Where to post it"  Please submit your bug report directly to the "GCC bug
database".  And the GCC bug database link points to 
http://gcc.gnu.org/bugzilla/

I guess I misread something.


-- 


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

[Bug boehm-gc/42304] New: found a resource leak

2009-12-05 Thread ettl dot martin at gmx dot de

Hi,

during check of the current trunk with the static code analysis tool cppcheck
(https://sourceforge.net/projects/cppcheck/) i discovered a resource leak.
Please see the attached patch that fixes the issue.

Best regards

Ettl Martin


Index: os_dep.c
===
--- os_dep.c(Revision 155013)
+++ os_dep.c(Arbeitskopie)
@@ -1165,6 +1165,7 @@
   } 
   GC_add_roots_inner(O32_BASE(seg), O32_BASE(seg)+O32_SIZE(seg), FALSE);
 }
+   fclose(myexefile);
 }

 # else /* !OS2 */


-- 
   Summary: found a resource leak
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ettl dot martin at gmx dot de


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

[Bug boehm-gc/42304] found a resource leak

2009-12-05 Thread ettl dot martin at gmx dot de



--- Comment #1 from ettl dot martin at gmx dot de  2009-12-05 21:02 ---
Created an attachment (id=19238)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19238&action=view)
a patch that fixes the resource leak


-- 


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

[Bug libfortran/30694] minval/maxval with +/-Inf

2009-12-05 Thread tkoenig at gcc dot gnu dot org



--- Comment #30 from tkoenig at gcc dot gnu dot org  2009-12-05 21:53 
---
(In reply to comment #29)
> Probably fixed by the commit of PR 40643 comment 7
> 
> Author: jakub
> Date: Fri Jul 24 07:57:13 2009
> New Revision: 150041
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150041
> Log:
> PR fortran/40643
> PR fortran/31067
> 

Yes, this is fixed.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1

2009-12-05 Thread tkoenig at gcc dot gnu dot org



--- Comment #8 from tkoenig at gcc dot gnu dot org  2009-12-05 21:54 ---
As far as I can see, this is fixed.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815

2009-12-05 Thread tkoenig at gcc dot gnu dot org



--- Comment #3 from tkoenig at gcc dot gnu dot org  2009-12-05 22:14 ---
Reduced test case, from c2.f90:

module m_sort
  implicit none
  type, abstract :: sort_t
  contains
procedure(gt_cmp), deferred :: gt_cmp
  end type sort_t
contains
  subroutine bsort(a)
class(sort_t), intent(inout) :: a(:)
if (a(1)%gt_cmp(a(2))) then ! ICE
end if
  end subroutine bsort
end module m_sort


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-05 22:14:52
   date||


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

[Bug debug/41806] G++ fails to compile a testcase with -fcompare-debug

2009-12-05 Thread d dot g dot gorbachev at gmail dot com



--- Comment #2 from d dot g dot gorbachev at gmail dot com  2009-12-05 
22:28 ---
Can't reproduce with this testcase and g++ 4.5.0 20091203.


-- 


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

[Bug other/42305] New: Inconsistent description of -O1 and -finline-small-functions options in documentation

2009-12-05 Thread howard_b_golden at yahoo dot com

The GCC manual and man page state that -O1 includes -finline-small-functions.
However, the description of -finline-small-functions states that it is included
by -O2 not by -O1.

I believe that the documentation should be corrected to state that -O1 includes
-finline-functions-called-once (and _not_ -finline-small-functions).

This issue was mentioned by Rafał Mużyło in bug #39333 (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333#c13), but it deserves to be
tracked separately.


-- 
   Summary: Inconsistent description of -O1 and -finline-small-
functions options in documentation
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howard_b_golden at yahoo dot com


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

[Bug bootstrap/42306] New: [4.5 regression] Revision 155012 breaks lto-plugin

2009-12-05 Thread hjl dot tools at gmail dot com

I got

libtool: Version mismatch error.  This is libtool 2.2.7a, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.7a
libtool: and run autoconf again.
make[6]: *** [lto-plugin.lo] Error 63
make[6]: Leaving directory `/export/gnu/import/svn/gcc-test/bld/lto-plugin'
make[5]: *** [all-stage1-lto-plugin] Error 2

--enable-gold is used to configure gcc.


-- 
   Summary: [4.5 regression] Revision 155012 breaks lto-plugin
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/42306] [4.5 regression] Revision 155012 breaks lto-plugin

2009-12-05 Thread hjl dot tools at gmail dot com



--- Comment #1 from hjl dot tools at gmail dot com  2009-12-05 23:51 ---
lto-plugin/:
* configure: Regenerate.
* Makefile.in: Regenerate.

is bogus. Those files aren't changed at all.


-- 


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

[Bug bootstrap/42306] [4.5 regression] Revision 155012 breaks lto-plugin

2009-12-05 Thread hjl at gcc dot gnu dot org



--- Comment #2 from hjl at gcc dot gnu dot org  2009-12-05 23:58 ---
Subject: Bug 42306

Author: hjl
Date: Sat Dec  5 23:57:50 2009
New Revision: 155017

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155017
Log:
2009-12-05  H.J. Lu  

PR bootstrap/42306
* configure: Regenerated.
* Makefile.in: Likewise.

Modified:
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/Makefile.in
trunk/lto-plugin/configure


-- 


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

[Bug bootstrap/42306] [4.5 regression] Revision 155012 breaks lto-plugin

2009-12-05 Thread hjl dot tools at gmail dot com



--- Comment #3 from hjl dot tools at gmail dot com  2009-12-06 00:12 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95

2009-12-05 Thread jvdelisle at gcc dot gnu dot org



--- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-12-06 00:16 
---
I can not reproduce at all.  Can you try an update.  Maybe one our patches
recently fixed this.


-- 


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

[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95

2009-12-05 Thread jvdelisle at gcc dot gnu dot org



--- Comment #9 from jvdelisle at gcc dot gnu dot org  2009-12-06 01:02 
---
OK we have a Heisenbug going on here.

Running from Valgrind like this:

 valgrind --leak-check=full f951 -pedantic ' as free form
.file   ""
:2.51:

  PARAMETER ( MY_STRING4 = (/ "A" , "B", "C" /) )
   1
Warning: Obsolescent feature: CHARACTER(*) function '__convert_s1_s4' at (1)

 snip 

==14463== 316 bytes in 2 blocks are definitely lost in loss record 2 of 6
==14463==at 0x4A05174: calloc (vg_replace_malloc.c:397)
==14463==by 0xCD3CA8: xcalloc (xmalloc.c:162)
==14463==by 0x629AF4: init_emit (emit-rtl.c:5565)
==14463==by 0x6C2CB7: prepare_function_start (function.c:4169)
==14463==by 0x6C2D58: init_function_start (function.c:4217)
==14463==by 0x53B5FD: trans_function_start (trans-decl.c:1925)
==14463==by 0x5423FE: gfc_generate_function_code (trans-decl.c:4272)
==14463==by 0x4EF4F3: gfc_parse_file (parse.c:4223)
==14463==by 0x52587C: gfc_be_parse_file (f95-lang.c:239)
==14463==by 0x81B205: toplev_main (toplev.c:1049)
==14463==by 0x3F6841E329: (below main) (libc-start.c:220)
==14463== 
==14463== LEAK SUMMARY:
==14463==definitely lost: 316 bytes in 2 blocks.
==14463==  possibly lost: 64 bytes in 2 blocks.
==14463==still reachable: 423,076 bytes in 1,336 blocks.
==14463== suppressed: 0 bytes in 0 blocks.
==14463== Reachable blocks (those to which a pointer was found) are not shown.
==14463== To see them, rerun with: --leak-check=full --show-reachable=yes


-- 


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

[Bug java/42307] New: WalkerTest execution failures

2009-12-05 Thread howarth at nitro dot med dot uc dot edu

On x86_64-apple-darwin10, we have been failing...

FAIL: WalkerTest execution - source compiled test
FAIL: WalkerTest -findirect-dispatch execution - source compiled test
FAIL: WalkerTest -O3 execution - source compiled test
FAIL: WalkerTest -O3 -findirect-dispatch execution - source compiled test

since the initial darwin10 release. Interestingly, when one tries to load the
WalkerTest.exe created with...

/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/testsuite/../libtool
--silent --tag=GCJ --mode=link
/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/./gcc/gcj
-B/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/
-B/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/./gcc/
-B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/bin/
-B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/lib/ -isystem
/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/include -isystem
/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/sys-include --encoding=UTF-8
-B/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/x86_64-apple-darwin10.2.0/libjava/testsuite/../
/sw/src/fink.build/gcc45-4.4.999-20091205/gcc-4.5-20091205/libjava/testsuite/libjava.lang/WalkerTest.jar
-w -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute
--main=WalkerTest -g
-L/sw/src/fink.build/gcc45-4.4.999-20091205/darwin_objdir/x86_64-apple-darwin10.2.0/./libjava/.libs
-lm -o WalkerTest.exe

into gdb, the following error is reported...

gdb ./WalkerTest.exeGNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep
18 20:40:51 UTC 2009)Copyright 2004 Free Software Foundation, Inc.GDB is free
software, covered by the GNU General Public License, and you arewelcome to
change it and/or distribute copies of it under certain conditions.Type "show
copying" to see the conditions.There is absolutely no warranty for GDB.  Type
"show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries .. done

gdb stack crawl at point of internal error:
0   gdb-i386-apple-darwin   0x0001001076e7 internal_vproblem +
308
1   gdb-i386-apple-darwin   0x0001001078c1 internal_verror + 27
2   gdb-i386-apple-darwin   0x00010010795f align_down + 0
3   gdb-i386-apple-darwin   0x0001000b1fc4
find_partial_die_in_comp_unit + 79
4   gdb-i386-apple-darwin   0x0001000bd97f find_partial_die +
626
5   gdb-i386-apple-darwin   0x0001000bd9cc fixup_partial_die +
55
6   gdb-i386-apple-darwin   0x0001000be08d scan_partial_symbols
+ 58
7   gdb-i386-apple-darwin   0x0001000bef51
dwarf2_build_psymtabs + 2982
8   gdb-i386-apple-darwin   0x000100144af3 macho_symfile_read +
294
9   gdb-i386-apple-darwin   0x00010004bbb8 syms_from_objfile +
1401
10  gdb-i386-apple-darwin   0x00010004c601
symbol_file_add_with_addrs_or_offsets_using_objfile + 690
11  gdb-i386-apple-darwin   0x00010004c5bb
symbol_file_add_with_addrs_or_offsets_using_objfile + 620
12  gdb-i386-apple-darwin   0x00010004c894
symbol_file_add_name_with_addrs_or_offsets + 117
13  gdb-i386-apple-darwin   0x00010004cd5c
symbol_file_add_main_1 + 207
14  gdb-i386-apple-darwin   0x00010006e75d catch_command_errors
+ 65
/SourceCache/gdb/gdb-1346/src/gdb/dwarf2read.c:8233: internal-error: could not
find partial DIE in cache

A problem internal to GDB has been detected,
further debugging may prove unreliable.


-- 
   Summary: WalkerTest execution failures
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug java/42307] WalkerTest execution failures

2009-12-05 Thread howarth at nitro dot med dot uc dot edu



--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-12-06 
01:11 ---
Created an attachment (id=19239)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19239&action=view)
preprocessed source for WalkerTestmain.i created on x86_64-apple-darwin10


-- 


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

[Bug java/42307] WalkerTest execution failures

2009-12-05 Thread howarth at nitro dot med dot uc dot edu



--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-12-06 
01:12 ---
Created an attachment (id=19240)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19240&action=view)
assembly for WalkerTestmain.s created on x86_64-apple-darwin10


-- 


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

[Bug java/42307] WalkerTest execution failures

2009-12-05 Thread howarth at nitro dot med dot uc dot edu



--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-12-06 
01:12 ---
Created an attachment (id=19241)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19241&action=view)
assembly for WalkerTest.s created on x86_64-apple-darwin10


-- 


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

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

2009-12-05 Thread kargl at gcc dot gnu dot org



--- Comment #16 from kargl at gcc dot gnu dot org  2009-12-06 01:16 ---
(In reply to comment #15)
> (In reply to comment #14)
> > > According to a note I spotted on clf , reading and writing reals with BOZ 
> > > is
> > > invalid, so what we are doing here is an extension. 
> > Do you have a pointer?
> 
> I have the following:
> 
> "10.6.1 Numeric editing"
> "The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to 
> specify
> the input/output of integer, real, and complex data."
> [...]
> "(6) On output, with I, B, O, Z, and F editing, the specified value of the
> field width w may be zero. In such cases, the processor selects the smallest
> positive actual field width that does not result in a field filled with
> asterisks. The specified value of w shall not be zero on input."
> 
> Thus it looks valid also for non-integers. However, going on one finds that 
> the
> B, O, & Z edit descriptors are only mentioned in "10.6.1.1 Integer editing"
> whereas "10.6.1.2 Real and complex editing" starts with "The F, E, EN, ES, and
> D edit descriptors specify the editing of real and complex data. [...] The G
> edit descriptor also may be used to edit real and complex data."
> 
> Thus, combining the two, using BOZ edit descriptors is invalid in F95/F2003.
> 

I disagree with your conclusion that this is invalid. :-)

10.6.1 explicitly says that the BOZ descriptors may be used
for real and complex.  Yes, I understand that 10.6.1.2 does
not specify the BOZ details for real and complex; but, and
is a big but, it does not explicitly disallow BOZ descriptors.

Probably, time to submit an interpretation request.  I won't
have time until Sunday to pursue this.



-- 


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

[Bug java/42307] WalkerTest execution failures

2009-12-05 Thread howarth at nitro dot med dot uc dot edu



--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-12-06 
01:33 ---
This appears to be a case where the new VTA merge debug code confuses the older
Apple gdb. Using current gdb cvs on x86_64-apple-darwin10, this failing
testcase debugs as...

../gdb_cvs/dist/bin/gdb ./WalkerTest.exe
GNU gdb (GDB) 7.0.50.20091206-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin10.2.0".
For bug reporting instructions, please see:
...
Reading symbols from /Users/howarth/libjava_bug/WalkerTest.exe...(no debugging
symbols found)...done.
(gdb) r
Starting program: /Users/howarth/libjava_bug/WalkerTest.exe 
limit: stacksize: Can't remove limit (Invalid argument)
[New Thread 0x1503 of process 66709]

Program received signal SIGABRT, Aborted.
0x7fff843d4fe6 in __kill () from /usr/lib/libSystem.B.dylib
(gdb) bt
#0  0x7fff843d4fe6 in __kill () from /usr/lib/libSystem.B.dylib
#1  0x7fff84475e32 in abort () from /usr/lib/libSystem.B.dylib
#2  0x7fff844bffc9 in _Unwind_FindEnclosingFunction () from
/usr/lib/libSystem.B.dylib
#3  0x000100083bfc in ?? ()
#4  0x000103f17f90 in ?? ()
#5  0x00010dcb in _ZN3Foo3barEJPN4java4lang5ClassEv (this=0x103f17f90)
at WalkerTest.java:5
#6  0x00010d53 in _ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE
(argv=0x103d9af30) at WalkerTest.java:13
#7  0x000100086cfe in ?? ()
#8  0x000103de6dc0 in ?? ()
#9  0x7fff5fbff110 in ?? ()
#10 0x7fff5fbff150 in ?? ()
#11 0x0001000e9024 in ?? ()
#12 0x000103de6dc0 in ?? ()
#13 0x7fff5fbff110 in ?? ()
#14 0x7fff5fbff150 in ?? ()
#15 0x00010009400a in ?? ()
#16 0x in ?? ()
(gdb)  x/10i 0x00010d53
   0x10d53 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+131>:
mov%rax,%rbx
   0x10d56 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+134>:
mov%r12,%rax
   0x10d59 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+137>:
test   %rax,%rax
   0x10d5c <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+140>: 
jne0x10d63
<_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+147>
   0x10d5e <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+142>:
callq  0x10de0
   0x10d63 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+147>:
mov%rax,%rdx
   0x10d66 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+150>:
mov(%rdx),%rdx
   0x10d69 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+153>:
add$0xf0,%rdx
   0x10d70 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+160>:
mov(%rdx),%rdx
   0x10d73 <_ZN10WalkerTest4mainEJvP6JArrayIPN4java4lang6StringEE+163>:
mov%rdx,%rcx
(gdb) x/10i 0x00010dcb
   0x10dcb <_ZN3Foo3barEJPN4java4lang5ClassEv+31>:  leaveq 
   0x10dcc <_ZN3Foo3barEJPN4java4lang5ClassEv+32>:  retq   
   0x10dcd: add%bh,%bh
   0x10dcf: and$0x25c,%eax
   0x10dd4: jmpq   *0x25e(%rip)# 0x11038
   0x10dda: jmpq   *0x260(%rip)# 0x11040
   0x10de0: jmpq   *0x262(%rip)# 0x11048
   0x10de6: jmpq   *0x264(%rip)# 0x11050
   0x10dec: jmpq   *0x266(%rip)# 0x11058
   0x10df2 < stub helpers>: lea0x20f(%rip),%r11# 0x11008


-- 


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

[Bug testsuite/42308] New: test-demangle, test-pexecute and test-expandargv compiled with wrong compiler

2009-12-05 Thread howarth at nitro dot med dot uc dot edu

On x86_64-apple-darwin9, since the system compiler defaults to -m32, an error
in the testsuite is revealed where the test-demangle, test-expandargv, and 
test-pexecute executables are erroneously compiled with the system compiler
instead of the newly built gcc compiler. This shows up as...

make[2]: Nothing to be done for `check'.
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20091205/libiberty/testsuite/../../include  -o test-demangle
\
../../../gcc-4.5-20091205/libiberty/testsuite/test-demangle.c
../libiberty.a
ld warning: in ../libiberty.a, file is not of required architecture
Undefined symbols:
  "_cplus_demangle_name_to_style", referenced from:
  _main in ccVk85Q2.o
  _main in ccVk85Q2.o
  "_cplus_demangle", referenced from:
  _main in ccVk85Q2.o
  _main in ccVk85Q2.o
  "_cplus_demangle_set_style", referenced from:
  _main in ccVk85Q2.o
  "_is_gnu_v3_mangled_dtor", referenced from:
  _main in ccVk85Q2.o
  "_xmalloc", referenced from:
  _get_line in ccVk85Q2.o
  "_xrealloc", referenced from:
  _get_line in ccVk85Q2.o
  "_is_gnu_v3_mangled_ctor", referenced from:
  _main in ccVk85Q2.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [test-demangle] Error 1
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20091205/libiberty/testsuite/../../include  -DHAVE_CONFIG_H
-I.. -o test-pexecute \
../../../gcc-4.5-20091205/libiberty/testsuite/test-pexecute.c
../libiberty.a
ld warning: in ../libiberty.a, file is not of required architecture
Undefined symbols:
  "_pexecute", referenced from:
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  "_pex_read_output", referenced from:
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  "_pex_get_status", referenced from:
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  "_pex_init", referenced from:
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  "_pex_run", referenced from:
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  "_pex_free", referenced from:
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
  "_xstrerror", referenced from:
  _fatal_error in ccRO9MYo.o
  "_pwait", referenced from:
  _main in ccRO9MYo.o
  _main in ccRO9MYo.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [test-pexecute] Error 1
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20091205/libiberty/testsuite/../../include  -DHAVE_CONFIG_H
-I.. -o test-expandargv \
../../../gcc-4.5-20091205/libiberty/testsuite/test-expandargv.c
../libiberty.a
ld warning: in ../libiberty.a, file is not of required architecture
Undefined symbols:
  "_dupargv", referenced from:
  _run_tests in ccL7RWVj.o
  _run_tests in ccL7RWVj.o
  "_expandargv", referenced from:
  _run_tests in ccL7RWVj.o
  "_xstrerror", referenced from:
  _fatal_error in ccL7RWVj.o
  "_freeargv", referenced from:
  _run_tests in ccL7RWVj.o
  _run_tests in ccL7RWVj.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [test-expandargv] Error 1
make[3]: Target `check' not remade because of errors.
make[2]: *** [check-subdir] Error 2
make[2]: Target `check' not remade because of errors.
make[1]: *** [check-libiberty] Error 2
make[1]: Target `check-host' not remade because of errors.


-- 
   Summary: test-demangle, test-pexecute and test-expandargv
compiled with wrong compiler
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin9
  GCC host triplet: x86_64-apple-darwin9
GCC target triplet: x86_64-apple-darwin9


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

74 matches

Mail list logo