[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #71 from hp at gcc dot gnu dot org  2008-08-30 06:27 ---
Created an attachment (id=16169)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169&action=view)
Patch, take 6.

Sigh.  This just moves the TREE_STATIC check from the early-return to the
weak-test, since it's wrong for *some* external declarations.
It shouldn't matter for Darwin (which doesn't define ASM_OUTPUT_EXTERNAL,
right?) but will fix the test-case for hppa2.0w-hp-hpux11.11, which BTW seems
not to support weak.  Test in progress, native and cris-elf as before.

I'm thankful as always for any testing, this time particularly on hppa-hpux
targets.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16146|0   |1
is obsolete||


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

[Bug middle-end/36583] [4.3/4.4 Regression] ICE on 5282/5206 at -O2

[corsepiu at gcc dot gnu dot org]

--- Comment #5 from corsepiu at gcc dot gnu dot org  2008-08-30 05:13 
---
With gcc-4.3.2, for me, the "j1.c" testcase doesn't segfault anymore.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #70 from hp at gcc dot gnu dot org  2008-08-30 03:37 ---
(In reply to comment #67)
> > -   .IMPORT _ZNSoD1Ev,CODE
> 
> If any of these functions is present in the .s, then there's a problem.
> The default for a 32-bit HP-UX symbol that isn't imported is DATA.

The problem here, is just that the .IMPORT lines are gone.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #69 from hp at gcc dot gnu dot org  2008-08-30 03:20 ---
(In reply to comment #64)
> Not sure what you meant by that comment; that's not what happens here AFAICT.
> I stated that output_operand does not see the same symbol_ref as was passed to
> the rtl insn expander, so target-specific code is needed just like for Darwin
> - or maybe it's just missing in generic code, for the constant pool.

No, that's not it.  The TREE_STATIC test is wrong.
I should merge extern and (extern) weak handling somehow.


-- 


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

[Bug fortran/33229] ICE with "intrinsic" plus calling a subroutine as function

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2008-08-30 02:58 ---
I may have a patch for this problem.  Note, there is an ambiguity
due to a set of intrinsics such as ETIME, which has both a function
form and a subroutine form.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-30 
02:48 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> > If the encoding for function names is getting stripped, then
> > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
> 
> Not sure what you meant by that comment; that's not what happens here AFAICT.
> I stated that output_operand does not see the same symbol_ref as was passed to
> the rtl insn expander, so target-specific code is needed just like for Darwin
> - or maybe it's just missing in generic code, for the constant pool.

I believe that the only special aspect of symbol_ref processing on the
32-bit hppa port is the symbol name encoding.  There's also some flag
bits.  Other than that, it's not clear why output_operand would see
something different from what was passed to the rtl insn expander.

There's nothing new in the hppa backend wrt symbol references.

Besides the .import issue, function pointers have to point to a
function descriptor (not the real code).  This is done using a plabel
which is a relocation which tells the linker to create a pointer to
a function descriptor.  This happens automatically if the output for
the function pointer output uses assembler_integer (assuming the name
encoding is correct).

Because the output of .import directives is a two stage process, there
might be an issue if a symbol_ref was garbage collected after the
assemble_external call.

Dave


-- 


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

[Bug rtl-optimization/37262] Two branches of the same condition being emitted

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-30 01:41 ---
I have seen this in other cases even for the non doloop case, though I don't
know if it is because of -O1 or because it is not removing it.
Testcase:
int _bfd_xcoff_canonicalize_dynamic_reloc (unsigned long long l_symndx)
{
  if (l_symndx < 3)
{
  switch (l_symndx)
  {
case 0:
case 1:
 break;
case 2:
 return _bfd_abort ();
}
  }
}
--- CUT ---
Compile at -O1 on powerpc-linux and you will see the double branches:
bne 0,.L7
bne 0,.L8


-- 


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

[Bug middle-end/37285] [4.4 Regression] ICE while building binutils on ppc

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
   Target Milestone|--- |4.4.0


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

[Bug middle-end/37285] New: [4.4 Regression] ICE while building binutils on ppc

[pinskia at gcc dot gnu dot org]

Hi, it looks like some of the VRP enhancements for switch statements is causing
an ICE on some code in binutils.
Testcase:
_bfd_xcoff_canonicalize_dynamic_reloc (unsigned long long l_symndx)
{
  if (l_symndx < 3)
{
  switch (l_symndx)
  {
case 0:
case 1:
 break;
case 2:
 _bfd_abort ("HI");
}
  }
}
--- CUT ---
With VRP turned on we get:
  switch (l_symndx) , case 2: >

But without it turned on we get:
  switch (l_symndx) , case 2: >

Most likely caused by the patch to fix PR 14495.


-- 
   Summary: [4.4 Regression] ICE while building binutils on ppc
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #67 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-30 
01:19 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> If the extern references had been "sort -u":ed, they'd had looked like this,
> diff from unpatched to patched for the attachment in comment #61, compiled 
> with
> -O2:
> 
> --- ../../../comboo/hppa2/gcc/hppa2.s   2008-08-29 22:32:02.0 +0200
> +++ ./hppa2.s   2008-08-29 22:31:38.0 +0200
> @@ -6664,13 +6664,7 @@ L$ASFDE0143:
> .align 4
>  L$EFDE0143:
> .word   0x0
> -   .IMPORT _ZNSdD0Ev,CODE
> -   .IMPORT _ZNSdD1Ev,CODE
> .IMPORT _ZNSdD2Ev,CODE
> -   .IMPORT _ZNSiD0Ev,CODE
> -   .IMPORT _ZNSiD1Ev,CODE
> -   .IMPORT _ZNSoD0Ev,CODE
> -   .IMPORT _ZNSoD1Ev,CODE

If any of these functions is present in the .s, then there's a problem.
The default for a 32-bit HP-UX symbol that isn't imported is DATA.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #66 from hp at gcc dot gnu dot org  2008-08-30 01:08 ---
(In reply to comment #61)
> Created an attachment (id=16165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view) [edit]
> preprocessed source from hppa2.0w-hp-hpux11.11 

Could you please dig out the cc1plus options too, so I'm not missing the
original case?


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #65 from hp at gcc dot gnu dot org  2008-08-30 01:05 ---
If the extern references had been "sort -u":ed, they'd had looked like this,
diff from unpatched to patched for the attachment in comment #61, compiled with
-O2:

--- ../../../comboo/hppa2/gcc/hppa2.s   2008-08-29 22:32:02.0 +0200
+++ ./hppa2.s   2008-08-29 22:31:38.0 +0200
@@ -6664,13 +6664,7 @@ L$ASFDE0143:
.align 4
 L$EFDE0143:
.word   0x0
-   .IMPORT _ZNSdD0Ev,CODE
-   .IMPORT _ZNSdD1Ev,CODE
.IMPORT _ZNSdD2Ev,CODE
-   .IMPORT _ZNSiD0Ev,CODE
-   .IMPORT _ZNSiD1Ev,CODE
-   .IMPORT _ZNSoD0Ev,CODE
-   .IMPORT _ZNSoD1Ev,CODE
.IMPORT _ZNSt15basic_streambufIcSt11char_traitsIcEE4syncEv,CODE
.IMPORT
_ZNSt15basic_streambufIcSt11char_traitsIcEE5imbueERKSt6locale,CODE
.IMPORT _ZNSt15basic_streambufIcSt11char_traitsIcEE5uflowEv,CODE
@@ -6684,13 +6678,6 @@ L$EFDE0143:
.IMPORT _ZNSt8ios_baseD2Ev,CODE
.IMPORT
_ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E,CODE
.IMPORT _ZNSt9basic_iosIcSt11char_traitsIcEED2Ev,CODE
-   .IMPORT _ZTISd,DATA
-   .IMPORT _ZTISi,DATA
-   .IMPORT _ZTISo,DATA
-   .IMPORT _ZTISt15basic_streambufIcSt11char_traitsIcEE,DATA
-   .IMPORT _ZTVN10__cxxabiv120__si_class_type_infoE,DATA
-   .IMPORT _ZTVSt15basic_streambufIcSt11char_traitsIcEE,DATA
-   .IMPORT _ZTVSt9basic_iosIcSt11char_traitsIcEE,DATA
.IMPORT _ZThn8_NSdD0Ev,CODE
.IMPORT _ZThn8_NSdD1Ev,CODE
.IMPORT _ZTv0_n12_NSdD0Ev,CODE


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #64 from hp at gcc dot gnu dot org  2008-08-30 00:39 ---
(In reply to comment #63)
> If the encoding for function names is getting stripped, then
> ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.

Not sure what you meant by that comment; that's not what happens here AFAICT.
I stated that output_operand does not see the same symbol_ref as was passed to
the rtl insn expander, so target-specific code is needed just like for Darwin
- or maybe it's just missing in generic code, for the constant pool.


-- 


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

[Bug c++/37284] ICE on valid code with -fstrict-aliasing

[mckelvey at maskull dot com]

--- Comment #3 from mckelvey at maskull dot com  2008-08-30 00:14 ---
Created an attachment (id=16168)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16168&action=view)
Smaller test case


-- 


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

[Bug c++/37284] ICE on valid code with -fstrict-alaising

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-29 23:52 ---
change_dynamic_type should have been removed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug c++/37284] ICE on valid code with -fstrict-alaising

[mckelvey at maskull dot com]

--- Comment #1 from mckelvey at maskull dot com  2008-08-29 23:51 ---
Created an attachment (id=16167)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16167&action=view)
Compressed preprocessed source


-- 


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

[Bug c++/37284] New: ICE on valid code with -fstrict-alaising

[mckelvey at maskull dot com]

Does not ICE without -fstrict-aliasing:

$ g++ -c -fstrict-aliasing PatternDriverTop.cc
In file included from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/i686-pc-cygwin/bits/c++allocator.h:40,
 from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/bits/allocator.h:54,
 from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/bits/stl_tree.h:69,
 from
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/set:66,
 from SeenSet.h:6,
 from PatternDriverTop.h:6,
 from PatternDriverTop.cc:2:
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/ext/new_allocator.h:
In member function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, const
_Tp&) [with _Tp = const PatternDriver::PatternDriverTop*]':
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/ext/new_allocator.h:107:
error: Unrecognized GIMPLE statement during RTL expansion
<<>>
/usr/local/lib/gcc/i686-pc-cygwin/4.4.0/../../../../include/c++/4.4.0/ext/new_allocator.h:107:
internal compiler error: in gimple_to_tree, at cfgexpand.c:300
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ uname -a
CYGWIN_NT-5.1 MCKELVEY-XP 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

$ g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --disable-win32-registry
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20080826 (experimental) (GCC)

$ alias CONFIGURECVS
alias CONFIGURECVS='/cygdrive/f/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --disable-win32-registry
--enable-languages=c,c++'

$ alias BUILD
alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g
-O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap'


-- 
   Summary: ICE on valid code with -fstrict-alaising
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug target/36756] [4.4 Regression] g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time, no-toplevel-reorder

[sam at gcc dot gnu dot org]

--- Comment #7 from sam at gcc dot gnu dot org  2008-08-29 23:46 ---
I think the fix is wrong: when optimization_options() is called, user options
have not been processed yet. It is likely that section anchors are always
disabled by this change.

The patch for PR37283 at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02325.html may solve this.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org


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

[Bug bootstrap/37086] [4.4 Regression] GCC 3.4 miscompiles trunk (for cross compiling)

[jsm28 at gcc dot gnu dot org]

--- Comment #13 from jsm28 at gcc dot gnu dot org  2008-08-29 23:31 ---
Subject: Bug 37086

Author: jsm28
Date: Fri Aug 29 23:30:18 2008
New Revision: 139792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139792
Log:
PR bootstrap/37086
* tree-vrp.c (find_switch_asserts): Make idx volatile for GCC
versions before 4.0.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug fortran/36153] ICE on size with kind parameter [F2003]

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2008-08-29 23:20 ---
See

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02322.html


Your welcome.


-- 


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

[Bug target/37283] [4.4 Regression] Cannot build crtbegin.o for ARM

[sam at gcc dot gnu dot org]

--- Comment #3 from sam at gcc dot gnu dot org  2008-08-29 22:53 ---
Right. There are two problems indeed, fix is being tested.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-29 22:53:08
   date||


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-29 
22:39 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> Looks like the HPPA port, like Darwin, transforms the original symbol_refs 
> upon
> seeing them, such that output_operand doesn't see all required,

If the encoding for function names is getting stripped, then
ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #62 from hp at gcc dot gnu dot org  2008-08-29 20:51 ---
Looks like the HPPA port, like Darwin, transforms the original symbol_refs upon
seeing them, such that output_operand doesn't see all required,


-- 


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

[Bug target/37283] [4.4 Regression] Cannot build crtbegin.o for ARM

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-29 20:48 ---
First the back-end does not disable section anchors for -fno-toplevel-reorder
so that is being produced.


-- 


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

[Bug target/37283] [4.4 Regression] Cannot build crtbegin.o for ARM

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pbrook at gcc dot gnu dot
   ||org
  Component|c   |target
Summary|Cannot build crtbegin.o for |[4.4 Regression] Cannot
   |ARM |build crtbegin.o for ARM
   Target Milestone|--- |4.4.0


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

[Bug c/37283] Cannot build crtbegin.o for ARM

[sam at gcc dot gnu dot org]

--- Comment #1 from sam at gcc dot gnu dot org  2008-08-29 20:37 ---
Created an attachment (id=16166)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16166&action=view)
crtstuff.s produced by GCC


-- 


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

[Bug c/37283] New: Cannot build crtbegin.o for ARM

[sam at gcc dot gnu dot org]

GCC (SVN trunk 139772) generates code that GNU as (Binutils 2.18.50.20080827)
refuses to assemble:

T=`${PWDCMD-pwd}`/ \
&& cd ../.././gcc \
&& make GCC_FOR_TARGET="/home/arm/build/gcc/./gcc/xgcc
-B/home/arm/build/gcc/./gcc/ -B/home/arm/install/arm-elf/bin/
-B/home/arm/install/arm-elf/lib/ -isystem /home/arm/install/arm-elf/include
-isystem /home/arm/install/arm-elf/sys-include" \
  MULTILIB_CFLAGS="-g -O2" \
  T=$T \
  T_TARGET="${T}crtbegin.o ${T}crtend.o ${T}crti.o ${T}crtn.o" \
  T_TARGET
make[3]: Entering directory `/home/arm/build/gcc/gcc'
/home/arm/build/gcc/./gcc/xgcc -B/home/arm/build/gcc/./gcc/
-B/home/arm/install/arm-elf/bin/ -B/home/arm/install/arm-elf/lib/ -isystem
/home/arm/install/arm-elf/include -isystem
/home/arm/install/arm-elf/sys-include -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include 
-I. -I/home/arm/build/gcc/arm-elf/libgcc -I/home/sam/Dev/gcc/gcc
-I/home/sam/Dev/gcc/gcc//home/arm/build/gcc/arm-elf/libgcc
-I/home/sam/Dev/gcc/gcc/../include -I/home/sam/Dev/gcc/gcc/../libcpp/include 
-I/home/sam/Dev/gcc/gcc/../libdecnumber
-I/home/sam/Dev/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -g -O2 -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-Dinhibit_libc  \
  -c /home/sam/Dev/gcc/gcc/crtstuff.c -DCRT_BEGIN \
  -o /home/arm/build/gcc/arm-elf/libgcc/crtbegin.o
/tmp/ccSpvfmn.s: Assembler messages:
/tmp/ccSpvfmn.s:47: Error: can't resolve `__DTOR_END__' {*UND* section} -
`.LANCHOR1' {.data section}
make[3]: *** [/home/arm/build/gcc/arm-elf/libgcc/crtbegin.o] Error 1


-- 
   Summary: Cannot build crtbegin.o for ARM
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sam at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-elf


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

[Bug bootstrap/37277] bootstrap failure with --with-dwarf2 on Solaris 10

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2008-08-29 20:26 
---
Remove --with-dwarf2, it is useless now.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2008-08-29 19:46 
---
(In reply to comment #14)
> I suspect this patch
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html
> 

That patch enabled IRA by default, before it was only enabled via the -fira
flag.  So please test before that patch with -fira and get back to us about
which patch really caused the regressions 


-- 


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

[Bug middle-end/37282] Regression 139582 on IRA branch caused many regressions

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-29 19:45 ---
I think that patch is a mis labeled.  Before that patch IRA was not enabled by
default so running the testsuite without -fira as the option passed to GCC to
one after that patch does not show the regressions.


-- 

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

[Bug middle-end/37282] Regression 139582 on IRA branch caused many regressions

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-08-29 19:40 ---
On Linux/ia64, it caused

+FAIL: g++.dg/opt/eh3.C execution test
+FAIL: gfortran.dg/list_read_8.f90  -O0  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O1  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O2  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -g  execution test
+FAIL: gfortran.dg/list_read_8.f90  -Os  execution test


-- 


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

[Bug middle-end/37282] New: Regression 139582 on IRA branch caused many regressions

[hjl dot tools at gmail dot com]

On IRA branch, revision 139582 caused

+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test

on Linux/ia32 and

+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: gcc.target/i386/pr36246.c scan-assembler-not movq
+FAIL: g++.old-deja/g++.eh/rethrow6.C execution test

on Linux/x86-64.


-- 
   Summary: Regression 139582 on IRA branch caused many regressions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
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=37282

[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax

[vmakarov at redhat dot com]

--- Comment #4 from vmakarov at redhat dot com  2008-08-29 19:17 ---
I believe that patch

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html

solves the problem.


-- 


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

[Bug c/37261] [4.3/4.4 Regression] Spurious (?) "integer overflow in expression" warnings

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-08-29 19:11 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/37261] [4.3/4.4 Regression] Spurious (?) "integer overflow in expression" warnings

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-08-29 19:09 ---
Subject: Bug 37261

Author: jakub
Date: Fri Aug 29 19:08:18 2008
New Revision: 139786

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139786
Log:
PR c/37261
* fold-const.c (fold_binary): In (X | C1) & C2 canonicalization
compute new & and | in type rather than TREE_TYPE (arg0).

* gcc.dg/pr37261.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr37261.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/37261] [4.3/4.4 Regression] Spurious (?) "integer overflow in expression" warnings

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-08-29 19:00 ---
Subject: Bug 37261

Author: jakub
Date: Fri Aug 29 18:59:13 2008
New Revision: 139784

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139784
Log:
PR c/37261
* fold-const.c (fold_binary): In (X | C1) & C2 canonicalization
compute new & and | in type rather than TREE_TYPE (arg0).

* gcc.dg/pr37261.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr37261.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-08-29 18:48 ---
Subject: Bug 24790

Author: jakub
Date: Fri Aug 29 18:47:19 2008
New Revision: 139777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139777
Log:
PR fortran/24790
* trans-decl.c (create_function_arglist): Set DECL_BY_REFERENCE on
PARM_DECLs with pointer or reference type.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c


-- 


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

[Bug fortran/23057] Fortran common blocks are not described with DW_TAG_common_block

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-08-29 18:46 ---
Subject: Bug 23057

Author: jakub
Date: Fri Aug 29 18:45:25 2008
New Revision: 139775

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139775
Log:
PR fortran/23057
* dwarf2out.c (gen_variable_die): Represent Fortran COMMON vars
as DW_TAG_variable children of DW_TAG_common_block rather than
DW_TAG_member children.  Put DW_AT_external to individual
DW_TAG_variable DIEs, not to DW_TAG_common_block.

* gfortran.dg/debug/pr35154-dwarf2.f: Adjust for replacement
of DW_TAG_member with DW_TAG_variable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f


-- 


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2008-08-29 18:46 
---
FWIW, this kind of contortion appear to work, but really I'd rather prefer not
using it...

namespace my_std
{
  inline double
  atan(double __x)
  { return __builtin_atan(__x); }

  inline double
  atanh(double __x)
  { return __builtin_atanh(__x); }
}

namespace std
{
  using ::my_std::atan;
  using ::my_std::atanh;
}

int main()
{
  std::atan(.3); // works
  std::atanh(.3);// works
}


-- 


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

[Bug fortran/29635] debug info of modules

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-08-29 18:42 ---
Subject: Bug 29635

Author: jakub
Date: Fri Aug 29 18:41:19 2008
New Revision: 139773

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139773
Log:
PR fortran/29635
PR fortran/23057
* debug.h (struct gcc_debug_hooks): Add NAME and CHILD
arguments to imported_module_or_decl.
(debug_nothing_tree_tree): Removed.
(debug_nothing_tree_tree_tree_bool): New prototype.
* debug.c (do_nothing_debug_hooks): Adjust.
(debug_nothing_tree_tree): Removed.
(debug_nothing_tree_tree_tree_bool): New function.
* dwarf2out.c (is_symbol_die): Handle DW_TAG_module.
(gen_variable_die): Put all common vars for the
same COMMON block under one DW_TAG_common_block.
(declare_in_namespace): Return new context_die, for Fortran
return the module DIE instead of adding extra declarations into
the namespace.
(gen_type_die_with_usage): Adjust declare_in_namespace caller.
(gen_namespace_die): If is_fortran (), generate DW_TAG_module
instead of DW_TAG_namespace.  If DECL_EXTERNAL is set, add
DW_AT_declaration.
(dwarf2out_global_decl): Don't skip Fortran global vars.
(gen_decl_die): Likewise.  Adjust declare_in_namespace callers.
(dwarf2out_imported_module_or_decl): Add NAME and CHILD arguments.
If NAME is non-NULL, add DW_AT_name.  If CHILD is non-NULL, put
DW_TAG_imported_declaration as child of previous
DW_TAG_imported_module.
* dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Adjust.
* sdbout.c (sdb_debug_hooks): Likewise.
* vmsdbgout.c (vmsdbg_debug_hooks): Likewise.

* name-lookup.c (do_using_directive, cp_emit_debug_info_for_using):
Adjust debug_hooks->imported_module_or_decl callers.

* f95-lang.c (gfc_init_ts): New function.
(LANG_HOOKS_INIT_TS): Define.
* gfortran.h (gfc_use_rename): New type, moved from module.c.
(gfc_get_use_rename): New macro, moved from module.c.
(gfc_use_list): New type.
(gfc_get_use_list): New macro.
(gfc_namespace): Add use_stmts field.
(gfc_free_use_stmts): New prototype.
* Make-lang.in (fortran/trans-decl.o): Depend on debug.h.
* module.c (gfc_use_rename, gfc_get_use_rename): Moved to
gfortran.h.
(gfc_use_module): Chain the USE statement info to
ns->use_stmts.
(gfc_free_use_stmts): New function.
* symbol.c (gfc_free_namespace): Call gfc_free_use_stmts.
* trans.h (struct module_htab_entry): New type.
(gfc_find_module, gfc_module_add_decl): New functions.
* trans.c (gfc_generate_module_code): Create NAMESPACE_DECL for
the module, adjust DECL_CONTEXTs of module procedures and
call gfc_module_add_decl for them.
* trans-common.c (build_common_decl): Set DECL_IGNORED_P
on the common variable.
(create_common): Set DECL_IGNORED_P for use associated vars.
* trans-decl.c: Include debug.h.
(gfc_get_symbol_decl): Set DECL_IGNORED_P on use_assoc vars from
modules.
(build_function_decl): Allow current_function_decl's context
to be a NAMESPACE_DECL.
(module_htab, cur_module): New variables.
(module_htab_do_hash, module_htab_eq, module_htab_decls_hash,
module_htab_decls_eq, gfc_find_module, gfc_module_add_decl): New
functions.
(gfc_create_module_variable): Adjust DECL_CONTEXTs of module
variables and types and call gfc_module_add_decl for them.
(gfc_generate_module_vars): Temporarily set cur_module.
(gfc_trans_use_stmts): New function.
(gfc_generate_function_code): Call it.
(gfc_generate_block_data): Set DECL_IGNORED_P on decl.
* trans-types.c (gfc_get_derived_type): Adjust DECL_CONTEXT
and TYPE_CONTEXT of module derived types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/dbxout.c
trunk/gcc/debug.c
trunk/gcc/debug.h
trunk/gcc/dwarf2out.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/Make-lang.in
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/module.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-common.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/gcc/sdbout.c
trunk/gcc/vmsdbgout.c


-- 


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

[Bug fortran/23057] Fortran common blocks are not described with DW_TAG_common_block

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-08-29 18:42 ---
Subject: Bug 23057

Author: jakub
Date: Fri Aug 29 18:41:19 2008
New Revision: 139773

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139773
Log:
PR fortran/29635
PR fortran/23057
* debug.h (struct gcc_debug_hooks): Add NAME and CHILD
arguments to imported_module_or_decl.
(debug_nothing_tree_tree): Removed.
(debug_nothing_tree_tree_tree_bool): New prototype.
* debug.c (do_nothing_debug_hooks): Adjust.
(debug_nothing_tree_tree): Removed.
(debug_nothing_tree_tree_tree_bool): New function.
* dwarf2out.c (is_symbol_die): Handle DW_TAG_module.
(gen_variable_die): Put all common vars for the
same COMMON block under one DW_TAG_common_block.
(declare_in_namespace): Return new context_die, for Fortran
return the module DIE instead of adding extra declarations into
the namespace.
(gen_type_die_with_usage): Adjust declare_in_namespace caller.
(gen_namespace_die): If is_fortran (), generate DW_TAG_module
instead of DW_TAG_namespace.  If DECL_EXTERNAL is set, add
DW_AT_declaration.
(dwarf2out_global_decl): Don't skip Fortran global vars.
(gen_decl_die): Likewise.  Adjust declare_in_namespace callers.
(dwarf2out_imported_module_or_decl): Add NAME and CHILD arguments.
If NAME is non-NULL, add DW_AT_name.  If CHILD is non-NULL, put
DW_TAG_imported_declaration as child of previous
DW_TAG_imported_module.
* dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Adjust.
* sdbout.c (sdb_debug_hooks): Likewise.
* vmsdbgout.c (vmsdbg_debug_hooks): Likewise.

* name-lookup.c (do_using_directive, cp_emit_debug_info_for_using):
Adjust debug_hooks->imported_module_or_decl callers.

* f95-lang.c (gfc_init_ts): New function.
(LANG_HOOKS_INIT_TS): Define.
* gfortran.h (gfc_use_rename): New type, moved from module.c.
(gfc_get_use_rename): New macro, moved from module.c.
(gfc_use_list): New type.
(gfc_get_use_list): New macro.
(gfc_namespace): Add use_stmts field.
(gfc_free_use_stmts): New prototype.
* Make-lang.in (fortran/trans-decl.o): Depend on debug.h.
* module.c (gfc_use_rename, gfc_get_use_rename): Moved to
gfortran.h.
(gfc_use_module): Chain the USE statement info to
ns->use_stmts.
(gfc_free_use_stmts): New function.
* symbol.c (gfc_free_namespace): Call gfc_free_use_stmts.
* trans.h (struct module_htab_entry): New type.
(gfc_find_module, gfc_module_add_decl): New functions.
* trans.c (gfc_generate_module_code): Create NAMESPACE_DECL for
the module, adjust DECL_CONTEXTs of module procedures and
call gfc_module_add_decl for them.
* trans-common.c (build_common_decl): Set DECL_IGNORED_P
on the common variable.
(create_common): Set DECL_IGNORED_P for use associated vars.
* trans-decl.c: Include debug.h.
(gfc_get_symbol_decl): Set DECL_IGNORED_P on use_assoc vars from
modules.
(build_function_decl): Allow current_function_decl's context
to be a NAMESPACE_DECL.
(module_htab, cur_module): New variables.
(module_htab_do_hash, module_htab_eq, module_htab_decls_hash,
module_htab_decls_eq, gfc_find_module, gfc_module_add_decl): New
functions.
(gfc_create_module_variable): Adjust DECL_CONTEXTs of module
variables and types and call gfc_module_add_decl for them.
(gfc_generate_module_vars): Temporarily set cur_module.
(gfc_trans_use_stmts): New function.
(gfc_generate_function_code): Call it.
(gfc_generate_block_data): Set DECL_IGNORED_P on decl.
* trans-types.c (gfc_get_derived_type): Adjust DECL_CONTEXT
and TYPE_CONTEXT of module derived types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/dbxout.c
trunk/gcc/debug.c
trunk/gcc/debug.h
trunk/gcc/dwarf2out.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/Make-lang.in
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/module.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-common.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans.c
trunk/gcc/fortran/trans.h
trunk/gcc/sdbout.c
trunk/gcc/vmsdbgout.c


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

--- Comment #14 from hjl dot tools at gmail dot com  2008-08-29 18:24 
---
I suspect this patch

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html

is incorrect. Back it out from IRA branch fixed the testcase
in comment #11. I am running SPEC CPU 2000/2006 with IRA
branch using revision 139581 and revision 139582 on Linux/ia32
and Linux/Intel64. It will tell us if revision 139582 is bad.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[andreast at gcc dot gnu dot org]

--- Comment #61 from andreast at gcc dot gnu dot org  2008-08-29 17:16 
---
Created an attachment (id=16165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view)
preprocessed source from hppa2.0w-hp-hpux11.11 


-- 


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

[Bug other/37280] weak symbol regression breaks linux kernel

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-08-29 17:03 ---
A wee bit shorter:
extern int kallsyms_token_index[] __attribute__((weak));
extern int kallsyms_token_table[] __attribute__((weak));
void kallsyms_expand_symbol(int *result)
{
  int len = *result;
  int *tptr;
  while(len) {
tptr = &kallsyms_token_table[ kallsyms_token_index[*result] ];
len--;
while (*tptr) tptr++;
*tptr = 1;
  }
 *result = 0;
}


-- 


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

[Bug c++/37281] bad code generation with enum and -m32

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-08-29 17:00 ---
In GCC 4.4 we warn about this with -Wconversion.

warning: the result of the conversion is unspecified because ‘32’ is outside
the range of type ‘MyTypes::Type’


-- 


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

[Bug c++/37281] bad code generation with enum and -m32

[gmorin1 at bloomberg dot net]

--- Comment #2 from gmorin1 at bloomberg dot net  2008-08-29 16:57 ---
I thought it was correct because it seems that the standard allows to cast
explicity inside the range.  The range is not the one of the integral type but
the one of smallest bit field that can stop all the values.  So you're
completely correct.  Sorry.


-- 

gmorin1 at bloomberg dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/37281] bad code generation with enum and -m32

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2008-08-29 16:39 ---
Subject: Re:   New: bad code generation with enum and -m32

This code is undefined as the value of  32 is outside the range of the  
enum.

Sent from my iPhone

On Aug 29, 2008, at 9:29, "gmorin1 at bloomberg dot net"
<[EMAIL PROTECTED] 
 > wrote:

> This is a copy of a Debian report that I made (I thought I might as  
> well report
> it directly here too): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496965
>
> g++ generates bad code for this program on an amd64 machine.  It  
> works with
> fine in 64-bit and with older versions of gcc.
>
> #include 
> struct MyTypes {
>enum Type {
>NOVALUE = 1,
>VALUE   = 30,
>VALUE2 = 31,
>VALUE3 = -3
>};
>
>static bool isValue(MyTypes::Type value);
> };
>
> bool MyTypes::isValue(MyTypes::Type value)
> {
>switch (value) {
>  case MyTypes::VALUE:
>  case MyTypes::VALUE2:
>  case MyTypes::VALUE3: {
>return true;
>  }
>  default: {
>return false;
>  }
>}
> }
>
> int main(int argc, char *argv[])
> {
>if (true == MyTypes::isValue(MyTypes::Type(32))) {
>abort();
>}
>return 0;
> }
>
> [EMAIL PROTECTED]:~$ g++ -m32 -Wall -o e enumtest.cpp
> [EMAIL PROTECTED]:~$ ./e
> Aborted
> [EMAIL PROTECTED]:~$ g++ -Wall -o e enumtest.cpp
> [EMAIL PROTECTED]:~$ ./e
> [EMAIL PROTECTED]:~$ g++-4.2 -m32 -Wall -o e enumtest.cpp
> [EMAIL PROTECTED]:~$ ./e
> [EMAIL PROTECTED]:~$ g++-4.1 -m32 -Wall -o e enumtest.cpp
> [EMAIL PROTECTED]:~$ ./e
>
> It works with -O2 though (not -O1):
> [EMAIL PROTECTED]:~$ g++ -O2 -m32 -Wall -o e enumtest.cpp
> [EMAIL PROTECTED]:~$ ./e
>
>
> -- System Information:
> Debian Release: lenny/sid
>  APT prefers testing
>  APT policy: (990, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
>
> -- 
>   Summary: bad code generation with enum and -m32
>   Product: gcc
>   Version: 4.3.1
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: gmorin1 at bloomberg dot net
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37281
>


-- 


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

Re: [Bug c++/37281] New: bad code generation with enum and -m32

[Andrew Thomas Pinski]

This code is undefined as the value of  32 is outside the range of the  
enum.


Sent from my iPhone

On Aug 29, 2008, at 9:29, "gmorin1 at bloomberg dot net" <[EMAIL PROTECTED] 
> wrote:


This is a copy of a Debian report that I made (I thought I might as  
well report

it directly here too): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496965

g++ generates bad code for this program on an amd64 machine.  It  
works with

fine in 64-bit and with older versions of gcc.

#include 
struct MyTypes {
   enum Type {
   NOVALUE = 1,
   VALUE   = 30,
   VALUE2 = 31,
   VALUE3 = -3
   };

   static bool isValue(MyTypes::Type value);
};

bool MyTypes::isValue(MyTypes::Type value)
{
   switch (value) {
 case MyTypes::VALUE:
 case MyTypes::VALUE2:
 case MyTypes::VALUE3: {
   return true;
 }
 default: {
   return false;
 }
   }
}

int main(int argc, char *argv[])
{
   if (true == MyTypes::isValue(MyTypes::Type(32))) {
   abort();
   }
   return 0;
}

[EMAIL PROTECTED]:~$ g++ -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
Aborted
[EMAIL PROTECTED]:~$ g++ -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
[EMAIL PROTECTED]:~$ g++-4.2 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
[EMAIL PROTECTED]:~$ g++-4.1 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e

It works with -O2 though (not -O1):
[EMAIL PROTECTED]:~$ g++ -O2 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e


-- System Information:
Debian Release: lenny/sid
 APT prefers testing
 APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)


--
  Summary: bad code generation with enum and -m32
  Product: gcc
  Version: 4.3.1
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: gmorin1 at bloomberg dot net


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

[Bug other/37280] weak symbol regression breaks linux kernel

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2008-08-29 16:30 ---
This is fixed by the patch in PR37170.


-- 


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

[Bug c++/37281] New: bad code generation with enum and -m32

[gmorin1 at bloomberg dot net]

This is a copy of a Debian report that I made (I thought I might as well report
it directly here too): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496965

g++ generates bad code for this program on an amd64 machine.  It works with
fine in 64-bit and with older versions of gcc.  

#include 
struct MyTypes {
enum Type {
NOVALUE = 1,
VALUE   = 30,
VALUE2 = 31,
VALUE3 = -3
};

static bool isValue(MyTypes::Type value);
};

bool MyTypes::isValue(MyTypes::Type value)
{
switch (value) {
  case MyTypes::VALUE:
  case MyTypes::VALUE2:
  case MyTypes::VALUE3: {
return true;
  }
  default: {
return false;
  }
}
}

int main(int argc, char *argv[])
{
if (true == MyTypes::isValue(MyTypes::Type(32))) {
abort();
}
return 0;
}

[EMAIL PROTECTED]:~$ g++ -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
Aborted
[EMAIL PROTECTED]:~$ g++ -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
[EMAIL PROTECTED]:~$ g++-4.2 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e
[EMAIL PROTECTED]:~$ g++-4.1 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e

It works with -O2 though (not -O1):
[EMAIL PROTECTED]:~$ g++ -O2 -m32 -Wall -o e enumtest.cpp
[EMAIL PROTECTED]:~$ ./e


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)


-- 
   Summary: bad code generation with enum and -m32
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gmorin1 at bloomberg dot net


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

[Bug rtl-optimization/37251] [4.4 Regression] ICE with ira: delete_allocno_from_bucket

[vmakarov at gcc dot gnu dot org]

--- Comment #7 from vmakarov at gcc dot gnu dot org  2008-08-29 16:19 
---
Subject: Bug 37251

Author: vmakarov
Date: Fri Aug 29 16:18:11 2008
New Revision: 139770

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139770
Log:
2008-08-29  Vladimir Makarov  <[EMAIL PROTECTED]>

PR rtl-opt/37251

* ira-color.c (push_allocnos_to_stack): Truncate
removed_splay_allocno_vec.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[vmakarov at gcc dot gnu dot org]

--- Comment #13 from vmakarov at gcc dot gnu dot org  2008-08-29 16:18 
---
Subject: Bug 37243

Author: vmakarov
Date: Fri Aug 29 16:16:45 2008
New Revision: 139769

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139769
Log:
2008-08-29  Vladimir Makarov  <[EMAIL PROTECTED]>

PR rtl-opt/37243
* ira-color (ira_fast_allocation): Don't assign hard registers to
global allocnos.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c


-- 


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

[Bug debug/33044] Local static variable in C++ constructor not visible for debugging

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2008-08-29 16:09 ---
Dodji is right: since the variable is shared between all concrete instances,
there is no need to repeat anything about it in the concrete instance.  The
debugger should find the information it wants in the abstract instance.

This is a bug in GDB.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2008-08-29 16:05 
---
(In reply to comment #7)
> The strict c++98 standard, without GNU extensions, doesn't know anything about
> atanh - there isn't a single mention in the entire Standard - therefore I 
> don't
> see why any difference is wanted.

Sorry, I got this first part of my reply backward. In any case, I don't think
enabling the GNU extensions (-std=gnu++98 is the default) should lead to such
nasty problem.


-- 


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

[Bug other/37280] weak symbol regression breaks linux kernel

[andi-gcc at firstfloor dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-08-29 16:02 ---
(In reply to comment #0)
> I attached a preprocessed test case.

Where?


--- Comment #2 from andi-gcc at firstfloor dot org  2008-08-29 16:02 ---
Created an attachment (id=16164)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16164&action=view)
preprocessed test case


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug other/37280] weak symbol regression breaks linux kernel

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-08-29 16:02 ---
(In reply to comment #0)
> I attached a preprocessed test case.

Where?


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2008-08-29 16:01 
---
The strict c++98 standard, without GNU extensions, doesn't know anything about
atanh - there isn't a single mention in the entire Standard - therefore I don't
see why any difference is wanted. Even less I see why we want Seg-faults at
run-time. Even less, why we want that in the C++0x era, when C99 math
facilities are on a par with C89 ones.


-- 


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-08-29 15:56 
---
Why?


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[vmakarov at redhat dot com]

--- Comment #12 from vmakarov at redhat dot com  2008-08-29 15:55 ---
Here is the analysis of regressions on pr36222 and pr36246.  PR36222 contains
the following code:
p64:V4SI=vec_concat (p66:V2SI, p65:V2SI) dead p66 and p65
xmm0:V2DI=subreg:V2DI (p64:V4SI)

IRA allocates p65, p66, and p64 in this order.  p65 gets xmm0, p66 gets xmm1,
and p64 gets xmm0.  Reload generates additional move insn because p66 and p64
should be the same operand according to the 1st insn constraints.

IRA uses copies to propagate preferences.  p66 and pc64, p66 and p64 connected
by copies with same frequencies as dying pseudos.  IRA did not create copy
connecting p66 and p64 as operands should be in the same register according to
the insn constraints because IRA does not create copies for allocnos with
different modes.

Preference of xmm0 was not propagated to p64 because IRA does not create copies
for subregs.

Another pitfall of IRA, it propagates preferences only from allocnos *directly*
connected by copies.

The patch solving the problem will be sent soon.


-- 


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-08-29 15:52 ---
I think this testcase is invalid without -std=c++98.


-- 


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

[Bug target/37168] [4.3/4.4 Regression] ICE: in final_scan_insn, at final.c:2615 (altivec)

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||08/msg02275.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-19 23:03:11 |2008-08-29 15:42:18
   date||


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

[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2008-08-29 15:29 ---
Created an attachment (id=16163)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16163&action=view)
A reduced version of the testcase

I still do not feel much the wiser - making vector visible in class motion
makes the problem go away.  This evidently gives the component 'law_y' of
'motion' a visible type that is no longer ambiguous with the "real" 'vector'.

Paul


-- 


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

[Bug other/37280] New: weak symbol regression breaks linux kernel

[ak at muc dot de]

The linux kernel doesn't build anymore with gcc version 4.4.0 20080826

The problem seems to be that one extern variable (kallsyms_token_index)
declared with  __attribute__((weak)) does not get a ".weak" in the assembler
output
anymore (compared the gcc 4.3)

I attached a preprocessed test case.

Build options:
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Os -m64 -mtune=generic
-mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2
-mno-3dnow -Iinclude/asm-x86/mach-default -Wframe-larger-than=2048
-fno-stack-protector -fomit-frame-pointer --param large-stack-frame=100 --param
large-stack-frame-growth=100 -Wdeclaration-after-statement -Wno-pointer-sign
-fverbose-asm

Built with gcc43:

% grep kallsyms_token_index kernel/kallsyms.s
 movzwl  kallsyms_token_index(%rax,%rax), %eax   # kallsyms_token_index, tmp118
movzwl  kallsyms_token_index(%rax,%rax), %eax   # kallsyms_token_index,
tmp124
movzwl  kallsyms_token_index(%rax,%rax), %eax   # kallsyms_token_index,
tmp105
movzwl  kallsyms_token_index(%rax,%rax), %eax   # kallsyms_token_index,
tmp102
movzwl  kallsyms_token_index(%rax,%rax), %eax   # kallsyms_token_index,
tmp106
movzwl  kallsyms_token_index(%rax,%rax), %eax   # kallsyms_token_index,
tmp93
.weak   kallsyms_token_index


With 4.4:
  movzwl  kallsyms_token_index(%rdx,%rdx), %edx   # kallsyms_token_index,
tmp116
movzwl  kallsyms_token_index(%rdi,%rdi), %edi   # kallsyms_token_index,
tmp122
movzwl  kallsyms_token_index(%rdx,%rdx), %edx   # kallsyms_token_index,
tmp103
movzwl  kallsyms_token_index(%rdx,%rdx), %edx   # kallsyms_token_index,
tmp100
movzwl  kallsyms_token_index(%rcx,%rcx), %ecx   # kallsyms_token_index,
tmp103
movzwl  kallsyms_token_index(%rcx,%rcx), %ecx   # kallsyms_token_index,
tmp91


Note no ".weak" in the second case. This breaks the build because it relies
on this symbol being weak on the first link pass.


-- 
   Summary: weak symbol regression breaks linux kernel
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ak at muc dot de
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug middle-end/37278] [4.4 Regression] Revision 139760 causes many failures

[hubicka at gcc dot gnu dot org]

--- Comment #2 from hubicka at gcc dot gnu dot org  2008-08-29 14:58 ---
Subject: Bug 37278

Author: hubicka
Date: Fri Aug 29 14:57:20 2008
New Revision: 139768

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139768
Log:

PR middle-end/37278
* predict.c (optimize_loop_nest_for_speed_p): Do not ICE
for cold internal loops.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c


-- 


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

[Bug debug/33044] Local static variable in C++ constructor not visible for debugging

[dodji at gcc dot gnu dot org]

--- Comment #13 from dodji at gcc dot gnu dot org  2008-08-29 14:41 ---
Created an attachment (id=16162)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16162&action=view)
The debug info of the program

Okay, here is a more accurate analysis. I will refer to the debug info
attached.

As I said in my previous comment, the foofoo variable is decribed by DIE ,
which is a child DIE of the DW_TAG_subprogram DIE at .  is the DIE of
the constructor A::A(int, int).

In GDB, When I set a beakpoint in A::A(int, int) the debugger actually stops on
a subprogram which DIE is <107>. This <107> DIE describes an "Out-of-Line
Instance" of of A::A(int, int). So <107> rightfully has an
DW_AT_abstract_origin attribute that links back to the abstract tree of
A::A(int, int) at .

However, foofoo does not have any DIE that is a child node of <107>. The DIE
<14d> seems to be the DIE describing iii, not foofoo.
That might be the reason why GDB is not finding foofoo.

On the other hand, the DWARF3 specs says (in section 3.3.8.2, point 1).

"An entry in the concrete instance tree may be omitted if it contains only a
DW_AT_abstract_origin attribute and either has no children, or its children are
omitted. Such
entries would provide no useful information.".

This text is at PDF page 65 (or document page 53).

So by the DWARF3 spec, I would believe that the debugger should be able to walk
through the DIE of the abstract tree A::A(int, int) to find the entry  that
describes foofoo.

On the other hand, GCC could maybe play nice and generate a DIE for foofoo as a
child node of the lexical block of <107>. But then maybe that would incur some
dwarf bloat.

Any comment ?


-- 


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

[Bug middle-end/37278] [4.4 Regression] Revision 139760 causes many failures

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-08-29 14:40 ---
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:
In function 'test6':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:557:
internal compiler error: Bus error

I have also similar errors with gfortran.


-- 


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-08-29 14:18 
---
>From the "outside", without looking deeper, I agree it seems a front-end issue.
The following seg-faults only when built with the C++ compiler:

inline double
atanh(double __x)
{ return __builtin_atanh(__x); }

int main()
{
  atanh(.3);
  return 0;
}


-- 


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

[Bug bootstrap/37279] New: bootstrap on sparc fails on genattrtab

[laurent at guerby dot net]

Last successful sparc testresult (sun or linux) is from 06Aug2008:

http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00636.html
"trunk revision 138734"

Whereas there were plenty of results before.

At trunk revision 139756 on sparc-unknown-linux-gnu I get during stage2:

build/genconfig ../../trunk/gcc/config/sparc/sparc.md \
  insn-conditions.md > tmp-config.h
/bin/sh ../../trunk/gcc/../move-if-change tmp-config.h insn-config.h
echo timestamp > s-config
build/genattrtab ../../trunk/gcc/config/sparc/sparc.md \
  insn-conditions.md > tmp-attrtab.c
/bin/sh: line 1: 31220 Erreur du bus   build/genattrtab
../../trunk/gcc/config/sparc/sparc.md insn-conditions.md > tmp-attrtab.c
make[3]: *** [s-attrtab] Erreur 138
make[3]: *** Attente des tâches non terminées
rm gcov.pod fsf-funding.pod gfdl.pod cpp.pod gcc.pod
make[3]: quittant le répertoire « /home/guerby/build01/gcc »
make[2]: *** [all-stage2-gcc] Erreur 2
make[2]: quittant le répertoire « /home/guerby/build01 »
make[1]: *** [stage2-bubble] Erreur 2
make[1]: quittant le répertoire « /home/guerby/build01 »
make: *** [bootstrap] Erreur 2

If I try to debug:

[EMAIL PROTECTED]:~/build01/gcc$ gdb build/genattrtab
GNU gdb 6.8-debian
Copyright (C) 2008 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 "sparc-linux-gnu"...

warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration
of GDB.  Attempting to continue with the default sparc:v9 settings.

Breakpoint 1 at 0x110b94: file ../../trunk/gcc/errors.c, line 133.
Breakpoint 2 at 0x110bbc: file ../../trunk/gcc/errors.c, line 96.
Breakpoint 3 at 0x21c4e0
Breakpoint 4 at 0x21c500
(gdb) r  ../../trunk/gcc/config/sparc/sparc.md insn-conditions.md
Starting program: /home/guerby/build01/gcc/build/genattrtab
../../trunk/gcc/config/sparc/sparc.md insn-conditions.md
/* Generated automatically by the program `genattrtab'
from the machine description file `md'.  */


Program received signal SIGBUS, Bus error.
0x001092e4 in main (argc=Unhandled dwarf expression opcode 0x0
) at ../../trunk/gcc/genattrtab.c:1373
1373  condexp = XVECEXP (delay->def, 1, i);
(gdb) bt
#0  0x001092e4 in main (argc=Unhandled dwarf expression opcode 0x0
) at ../../trunk/gcc/genattrtab.c:1373
(gdb) quit


-- 
   Summary: bootstrap on sparc fails on genattrtab
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: sparc-unknown-linux-gnu
  GCC host triplet: sparc-unknown-linux-gnu
GCC target triplet: sparc-unknown-linux-gnu


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

[Bug fortran/37099] [4.3, 4.4 regression] Wrong results when comparing a character array to a character expression

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug bootstrap/37277] bootstrap failure with --with-dwarf2 on Solaris 10

[jwakely dot gcc at gmail dot com]

--- Comment #2 from jwakely dot gcc at gmail dot com  2008-08-29 13:36 
---
I think this is a regression against 4.2.2 as I have working compilers for
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 which were both configured
with --with-dwarf2 (although I didn't build them myself so I'm not 100% sure)


-- 


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

[Bug c/12603] No return statement warning on function that never returns with -O3

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-08-29 13:28 ---
No warning in GCC 4.4 with any of those:

-O0 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O1 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O2 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O3 -Wall -Wextra -Wreturn-type -Wunreachable-code
-O3 -finline -Wall -Wextra -Wreturn-type -Wunreachable-code

If you can reproduce the problem in a recent GCC, let us know. I will add the
testcase to the testsuite before closing this.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |manu at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Known to fail||4.4.0
   Last reconfirmed|2005-12-18 00:38:04 |2008-08-29 13:28:06
   date||


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

[Bug middle-end/37278] New: [4.4 Regression] Revision 139760 causes many failures

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 139760 causes

FAIL: g++.dg/tree-ssa/pr29902.C (internal compiler error)
FAIL: g++.dg/tree-ssa/pr29902.C (test for excess errors)
FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O3
-fomit-frame-pointer  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O3
-fomit-frame-pointer -funroll-loops  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O3 -g 
(internal compiler error)
UNRESOLVED: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/memset-2.c compilation,  -O3 -fomit-frame-pointer 
(internal compiler error)
UNRESOLVED: gcc.c-torture/execute/memset-2.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.c-torture/execute/memset-2.c compilation,  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/memset-2.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/memset-2.c compilation,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/memset-2.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/memset-2.c compilation,  -O3 -g  (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/memset-2.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/memset-3.c compilation,  -O3 -fomit-frame-pointer 
(internal compiler error)
UNRESOLVED: gcc.c-torture/execute/memset-3.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.c-torture/execute/memset-3.c compilation,  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/memset-3.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/memset-3.c compilation,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
UNRESOLVED: gcc.c-torture/execute/memset-3.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/memset-3.c compilation,  -O3 -g  (internal compiler
error)
UNRESOLVED: gcc.c-torture/execute/memset-3.c execution,  -O3 -g 
FAIL: gcc.dg/torture/pr34330.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/pr34330.c  -Os  (test for excess errors)


-- 
   Summary: [4.4 Regression] Revision 139760 causes many failures
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
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=37278

[Bug target/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2

[amonakov at gcc dot gnu dot org]

--- Comment #43 from amonakov at gcc dot gnu dot org  2008-08-29 13:12 
---
Checking original testcase times on x86_64 prescott with gentoo 4.2, 4.3 and
today's trunk:
2.960sg++-4.2.4 (GCC) 4.2.4 (Gentoo 4.2.4 p1.0)
2.916sg++-4.3.1 (Gentoo 4.3.1-r1 p1.1) 4.3.1
3.993sg++ (GCC) 4.4.0 20080829 (experimental)
2.796sg++ (GCC) 4.4.0 20080829 (experimental) with --param
max-inline-insns-auto=126

So I believe lack of inlining is the biggest 4.4's problem. We do not inline
3x3 matrix multiplication in benchmark loop.

While looking at it I found that einline2 dump does not always show the reason
for not inlining. I would like to propose the following patch:

--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -1494,6 +1494,8 @@ cgraph_decide_inlining_incrementally (struct cgraph_node
*node,
  }
if (cgraph_default_inline_p (e->callee, &failed_reason))
  inlined |= try_inline (e, mode, depth);
+   else if (dump_file)
+ fprintf (dump_file, "Not inlining: %s.\n", failed_reason);
   }
   node->aux = (void *)(size_t) old_mode;
   return inlined;


-- 


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-29 13:11 ---
Actually, it looks like we treat

namespace std
{
  inline double
  atanh(double __x)
  { return __builtin_atanh(__x); }
}

as a definition of ::atanh (with C linkage), and emit

atanh:
.LFB0:
pushq   %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
subq$32, %rsp
.LCFI2:
movsd   %xmm0, -8(%rbp)
movsd   -8(%rbp), %xmm0
callatanh
movsd   %xmm0, -24(%rbp)
movq-24(%rbp), %rax
movq%rax, -24(%rbp)
movsd   -24(%rbp), %xmm0
leave
ret

main:
.LFB1:
pushq   %rbp
.LCFI3:
movq%rsp, %rbp
.LCFI4:
movsd   .LC0(%rip), %xmm0
callatanh
movl$0, %eax
leave
ret


So, this is a frontend bug.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
   Keywords||wrong-code


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

[Bug bootstrap/37277] bootstrap failure with --with-dwarf2 on Solaris 10

[jwakely dot gcc at gmail dot com]

--- Comment #1 from jwakely dot gcc at gmail dot com  2008-08-29 13:11 
---
Created an attachment (id=16161)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16161&action=view)
gcc/gtyp-input.list

Here is the generated file with the duplicate entry


-- 


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

[Bug bootstrap/37277] New: bootstrap failure with --with-dwarf2 on Solaris 10

[jwakely dot gcc at gmail dot com]

/home/wakelyjo/src/gcc/gcc-4.3.2/configure
--prefix=/home/wakelyjo/src/gcc/sol10-64/INSTALL 
--with-gmp=/home/wakelyjo/src/gcc/sol10-64/INSTALL
--with-mpfr=/home/wakelyjo/src/gcc/sol10-64/INSTALL --with-dwarf2

Bootstrap fails with:

build/gengtype /home/wakelyjo/src/gcc/gcc-4.3.2/gcc gtyp-input.list
gtyp-input.list:20: file
/home/wakelyjo/src/gcc/gcc-4.3.2/gcc/config/tm-dwarf2.h specified more than
once for language (all)
make[3]: *** [s-gtype] Error 1
make[3]: Leaving directory `/home/wakelyjo/src/gcc/tmp/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/wakelyjo/src/gcc/tmp'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/wakelyjo/src/gcc/tmp'
make: *** [all] Error 2


-- 
   Summary: bootstrap failure with --with-dwarf2 on Solaris 10
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
 GCC build triplet: sparc-sun-solaris2.10
  GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-29 13:08 ---
Funny.  (just look at the asm...)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-29 13:04:17 |2008-08-29 13:08:02
   date||


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[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
   Last reconfirmed|-00-00 00:00:00 |2008-08-29 13:04:17
   date||


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

[Bug c++/37276] Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-08-29 13:04 
---
I think it can be safely confirmed.


-- 


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

[Bug c++/37276] New: Trouble with some (C99?) math builtins and namespace std

[paolo dot carlini at oracle dot com]

Hi, I'm getting this annoying run-time Seg-fault for the below. Apparently,
isn't a regression, but really, if we could fix it, the C++ library would
benefit a lot from the fix!



namespace my_std
{
  inline double
  atan(double __x)
  { return __builtin_atan(__x); }

  inline double
  atanh(double __x)
  { return __builtin_atanh(__x); }
}

namespace std
{
  inline double
  atan(double __x)
  { return __builtin_atan(__x); }

  inline double
  atanh(double __x)
  { return __builtin_atanh(__x); }
}

int main()
{
  double d;

  my_std::atan(.3);  // works
  my_std::atanh(.3); // works

  std::atan(.3); // works
  std::atanh(.3);// seg-faults at run-time
}


-- 
   Summary: Trouble with some (C99?) math builtins and namespace std
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com


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

[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug c/37261] [4.3/4.4 Regression] Spurious (?) "integer overflow in expression" warnings

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-08-29 12:23 ---
Caused by PR33691 fix btw.


-- 


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

[Bug c/37261] [4.3/4.4 Regression] Spurious (?) "integer overflow in expression" warnings

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-08-29 11:55 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-28 09:16:34 |2008-08-29 11:55:56
   date||


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

[Bug middle-end/37236] [4.3 Regression] ICE: in mark_operand_necessary, at tree-ssa-dce.c:242

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-08-29 11:49 
---
Fixed for the trunk.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.2
  Known to work||4.4.0
Summary|[4.3/4.4 Regression] ICE: in|[4.3 Regression] ICE: in
   |mark_operand_necessary, at  |mark_operand_necessary, at
   |tree-ssa-dce.c:242  |tree-ssa-dce.c:242


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

[Bug middle-end/37236] [4.3/4.4 Regression] ICE: in mark_operand_necessary, at tree-ssa-dce.c:242

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-08-29 11:42 
---
Subject: Bug 37236

Author: rguenth
Date: Fri Aug 29 11:40:47 2008
New Revision: 139763

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139763
Log:
2008-08-29  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/37236
* tree-ssa-structalias.c (intra_create_variable_infos): Mark
PARAM_NOALIAS tags with is_heapvar.
* tree-ssa-operands.c (access_can_touch_variable): Offset
based tests do not apply for heapvars.  Fix offset test.

* gfortran.fortran-torture/compile/pr37236.f: New testcase.

Added:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr37236.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-operands.c
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug debug/33044] Local static variable in C++ constructor not visible for debugging

[dodji at gcc dot gnu dot org]

--- Comment #12 from dodji at gcc dot gnu dot org  2008-08-29 09:58 ---
This is an update of what we get with gcc-4_3-branch.

For the program (line numbers added for better legibility):

 1  #include 
 2  class A {
 3  public:
 4A (int a, int b);
 5int a_;
 6int b_;
 7int c_;
 8  };
 9  
10  A::A (int a, int b) : a_ (a), b_ (b), c_ (0)
11  {
12int iii;
13iii = 42;
14c_ = a_ * b_;
15c_ += iii;
16static const int foofoo[6][4] = { {0,1,2,3},
17  {1,2,3,4},
18  {2,3,4,5},
19  {3,4,5,6},
20  {4,5,6,7},
21  {5,6,7,8} };
22  
23printf("c_ = %d\n", c_);
24printf("foofoo = %d\n", foofoo);
25  }
26  
27  int main (int, char* *)
28  {
29int a = 34, b = 56;
30A x (a, b);
31return x.a_ + x.b_;
32  }
33  

I get the dwarf info below:

[...]

<1>: Abbrev Number: 11 (DW_TAG_subprogram) <-- //This is the A::A
constructor at line 10.
   DW_AT_specification: <0xa6>  
   DW_AT_decl_line   : 10   
   DW_AT_inline  : 0(not inlined)
   DW_AT_sibling : <0x102>  
 <2>: Abbrev Number: 12 (DW_TAG_formal_parameter)
   DW_AT_name: (indirect string, offset: 0x47): this
   DW_AT_type: <0x102>  
   DW_AT_artificial  : 1
 <2>: Abbrev Number: 13 (DW_TAG_formal_parameter)
   DW_AT_name: a
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 10   
   DW_AT_type: <0x57>   
 <2>: Abbrev Number: 13 (DW_TAG_formal_parameter)
   DW_AT_name: b
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 10   
   DW_AT_type: <0x57>   
 <2>: Abbrev Number: 14 (DW_TAG_variable) <--- this if the foofoo variable
   DW_AT_name: (indirect string, offset: 0x0): foofoo
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 16 
   DW_AT_type: <0x214>  
   DW_AT_location: 9 byte block: 3 20 8 40 0 0 0 0 0   
(DW_OP_addr: 400820)

[...]

So we see here that the foofoo variable is generated with an DW_AT_location,
inside the A::A constructor we are interested in.

However, in GDB, at line 23:
(gdb) bt
#0  A (this=0x7fff6616bd80, a=34, b=56) at test-PR33044.cc:23
#1  0x00400645 in main () at test-PR33044.cc:30

I get:
(gdb) p foofoo
No symbol "foofoo" in current context.

As Andrew pointed, gcc can generate several copies (two, or three) of a given
constructor. Those copies don't necessarily have the same signatures, of
course. So A::A(int, int) might yield to an additional copy of the constructor
being generated.
The debugging for A::A(int, int) info is only generated for the "initial"
constructor. Not for the additional copy.

So my question now is what happens when GDB actually breaks in the additional
copy ? Can it detect that it broke in a constructor that is "only" a copy of
the "real" one ? Or does it expect that all the copies be associated with
debugging info ?


-- 


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

[Bug target/37101] [4.2 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct

[ubizjak at gmail dot com]

--- Comment #14 from ubizjak at gmail dot com  2008-08-29 09:44 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/37101] [4.2 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct

[uros at gcc dot gnu dot org]

--- Comment #13 from uros at gcc dot gnu dot org  2008-08-29 09:43 ---
Subject: Bug 37101

Author: uros
Date: Fri Aug 29 09:41:57 2008
New Revision: 139758

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139758
Log:
Backport from mainline:
2008-08-14  Christophe Saout  <[EMAIL PROTECTED]>
Uros Bizjak  <[EMAIL PROTECTED]>

PR target/37101
* config/i386/sse.md (vec_concatv2di): Remove movlps alternative.

testsuite/ChangeLog:

Backport from mainline:
2008-08-14  Uros Bizjak  <[EMAIL PROTECTED]>

PR target/37101
* gcc.target/i386/pr37101.c: New test.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr37101.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/i386/sse.md
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37236] [4.3/4.4 Regression] ICE: in mark_operand_necessary, at tree-ssa-dce.c:242

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-08-29 09:30 
---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-27 11:53:51 |2008-08-29 09:30:59
   date||


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

[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2008-08-29 08:54 ---
(In reply to comment #4)
> Does it have anything to do with 36374? 
> 

Salvatore,

I don't think so, since this PR is a regression. Anyway, I'll take a look at
them both together in a few days. I'm still not entirely back in action
after my move to Barcelona and the theft of my laptop; in particular, I still
do not have a working tree that I can use for debugging.

As soon as posssible honest!

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||4.4.0
  Known to work||4.2.4
Summary|error: type name is |[Regression 4.4 (and 4.3?)]
   |ambiguous.  |error: type name is
   ||ambiguous.


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

[Bug fortran/37274] error: type name is ambiguous.

[sfilippone at uniroma2 dot it]

--- Comment #4 from sfilippone at uniroma2 dot it  2008-08-29 08:46 ---
Does it have anything to do with 36374? 


-- 


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

[Bug fortran/37274] error: type name is ambiguous.

[sfilippone at uniroma2 dot it]

--- Comment #3 from sfilippone at uniroma2 dot it  2008-08-29 08:39 ---
Yes, it's the release.

[EMAIL PROTECTED] type_ambiguity]$ gfortran -v -c type_ambiguity.f90 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.4/configure 
Thread model: posix
gcc version 4.2.4
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.2.4/f951 type_ambiguity.f90 -quiet
-dumpbase type_ambiguity.f90 -mtune=generic -auxbase type_ambiguity -version -I
/usr/local/lib/gcc/i686-pc-linux-gnu/4.2.4/finclude -o /tmp/ccZJJLfj.s
GNU F95 version 4.2.4 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 as -V -Qy -o type_ambiguity.o /tmp/ccZJJLfj.s
GNU assembler version 2.17.50.0.12-4 (i386-redhat-linux) using BFD version
2.17.50.0.12-4 20070128
[EMAIL PROTECTED] type_ambiguity]$ 


-- 


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

[Bug tree-optimization/37207] [4.4 Regression] ice at tree-ssa-ifcombine.c:222 for -Os

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-29 08:37 ---
Subject: Bug 37207

Author: rguenth
Date: Fri Aug 29 08:36:10 2008
New Revision: 139754

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139754
Log:
2008-08-29  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/37207
* tree-vrp.c (extract_range_from_binary_expr): Also try
to constant fold if only one of the operands is a constant.

* gcc.dg/tree-ssa/vrp46.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug fortran/37274] error: type name is ambiguous.

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2008-08-29 08:31 ---
Confirmed

Salvatore, what is the date on your 4.2.4?  Is it the release version - ie.
19th May 2008?

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-29 08:31:35
   date||
Summary|error: type name is |error: type name is
   |ambiguous.  |ambiguous.


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

[Bug c++/37268] ICE in template typedef with aligned attribute

[svobodamo at gmail dot com]

--- Comment #3 from svobodamo at gmail dot com  2008-08-29 07:53 ---
okay, i'll try to upgrade, thanks guys


-- 


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

[Bug middle-end/37275] ICE when compile libgomp/task.c

[linuxl4 at sohu dot com]

--- Comment #1 from linuxl4 at sohu dot com  2008-08-29 07:52 ---
Created an attachment (id=16160)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16160&action=view)
the preprocessed source 


-- 


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

[Bug middle-end/37275] New: ICE when compile libgomp/task.c

[linuxl4 at sohu dot com]

gcc (GCC) 4.4.0 20080828 (experimental)

gcc  -g -O2 -march=i686 -fstack-protector -c task.c -o task.o


-- 
   Summary: ICE when compile libgomp/task.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: linuxl4 at sohu dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu


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

[Bug fortran/37274] error: type name is ambiguous.

[sfilippone at uniroma2 dot it]

--- Comment #1 from sfilippone at uniroma2 dot it  2008-08-29 07:42 ---
Created an attachment (id=16159)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16159&action=view)
test case


-- 


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

[Bug fortran/37274] New: error: type name is ambiguous.

[sfilippone at uniroma2 dot it]

With the attached test case I get: 
[EMAIL PROTECTED] type_ambiguity]$ gfortran -v -c type_ambiguity.f90 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefix=/usr/local/gcc43
--with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp
Thread model: posix
gcc version 4.3.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic'
 /usr/local/gcc43/libexec/gcc/i686-pc-linux-gnu/4.3.1/f951 type_ambiguity.f90
-quiet -dumpbase type_ambiguity.f90 -mtune=generic -auxbase type_ambiguity
-version -fintrinsic-modules-path
/usr/local/gcc43/lib/gcc/i686-pc-linux-gnu/4.3.1/finclude -o /tmp/cc6I26kb.s
GNU F95 (GCC) version 4.3.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
type_ambiguity.f90:283.14:

  type(vector) :: new_pos  ! the new vertex position, after smoothing
 1
Error: Type name 'vector' at (1) is ambiguous

I cannot see any ambiguity in the source code. 

The code compiles cleanly on 4.2.4, fails on 4.4-20080822, compiles cleanly on
Intel 10.1.015 and on XLF 10.1. 

The code has been extracted from an application, and has been heavily pruned. 

The Intel compiler  gives a warning about an intent(out) variable not being
set, but this is an artifact of pruning the test case. 

The most puzzling things are the two workarounds that I have found so far: 
1. In the subroutine smooth_mesh, comment the USE statement at line 279. 
   This is not an option in the original application code, though. 
2. In the subroutine smooth_mesh, switch the order of the USE statements at   
lines 277/278; this also fixes the original application code. 

I cannot see anything illegal in the code, so I presume it is a reject-valid;
however even if the code is shown to be illegal, the reported error does
precious little to help the user. 


Salvatore


-- 
   Summary: error: type name is ambiguous.
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sfilippone at uniroma2 dot it
 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=37274

[Bug target/25199] crashing code output from -mtune=pentium4 but not -mtune=pentiumpro

[jakub at gcc dot gnu dot org]

--- Comment #16 from jakub at gcc dot gnu dot org  2008-08-29 07:22 ---
It is not incorrect, but is a code quality regression, which counts too.
So I'd prefer the testcase to stay as is and let the RA get fixed.


-- 


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