[Bug target/35910] [4.4 Regression] error: �struct function� has no member named �args_info�

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-11 07:21 ---
This was fixed long ago.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||build
 Resolution||FIXED
Summary|error: ‘struct function’ has|[4.4 Regression] error:
   |no member named ‘args_info’ |‘struct function’ has no
   ||member named ‘args_info’
   Target Milestone|--- |4.4.0


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

[Bug c++/36149] -O2 optimization generates wrong code

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |WAITING
   Keywords||alias, wrong-code


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

[Bug middle-end/35970] [4.4 Regression] except.c:3382: error: 'struct eh_status' has no member named 'call

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-11 07:20 ---
This was fixed long ago.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||build
 Resolution||FIXED
Summary|except.c:3382: error:   |[4.4 Regression]
   |'struct eh_status' has no   |except.c:3382: error:
   |member named 'call  |'struct eh_status' has no
   ||member named 'call
   Target Milestone|--- |4.4.0


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

[Bug fortran/36206] New: ice for legal code with -O3

[dcb314 at hotmail dot com]

I just tried to compile the lapack package
version 3.3.1 with the GNU Fortran compiler  
version 4.4 snapshot 20080509

The compiler said

sspr.f: In function 'sspr':
sspr.f:1: internal compiler error: tree check: expected integer_cst, have
plus_expr in int_cst_value, at tree.c:8002
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Source code attached. Flag -O3 required, but this
code compiles at -O2, so I don't think the problem
is in the Fortran front end, more likely the back-end.


-- 
   Summary: ice for legal code with -O3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-11 07:54 ---
Most likely the same issue as PR 36198.


-- 


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|fortran |middle-end
Summary|ice for legal code with -O3 |[4.4 Regression] ice for
   ||legal code with -O3
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/36198] [4.4 Regression] expected integer_cst, have mult_expr

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|expected integer_cst, have  |[4.4 Regression] expected
   |mult_expr   |integer_cst, have mult_expr
   Target Milestone|--- |4.4.0


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

[Bug ada/36207] New: [4.4 regression] Ada bootstrap fails in uintp.adb:1595

[aaronavay62 at aaronwl dot com]

The type size seems to be getting set to zero when calling
Build_Signed_Integer_Type in cstand.adb.  It's possible that the stage2 gnat
has been miscompiled.

/mingw/src/gccsvn/obj/./prev-gcc/xgcc -B/mingw/src/gccsvn/obj/./prev-gcc/
-B/mingw/i386-pc-mingw32/bin/ -c -g -O2 -D__USE_MINGW_ACCESS  -gnatpg
-gnata -gnatws -nostdinc -I- -I. -Iada -I../../svn/gcc/ada
../../svn/gcc/ada/ada.ads -o ada/ada.o -v -save-temps
Reading specs from /mingw/src/gccsvn/obj/./prev-gcc/specs
Target: i386-pc-mingw32
Configured with: ../svn/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-libgcj --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks
--enable-version-specific-runtime-libs --prefix=/mingw
--with-gmp=/mingw/src/gcc/gmp-mpfr-root
--with-mpfr=/mingw/src/gcc/gmp-mpfr-root
--with-libiconv-prefix=/mingw/src/gcc/libiconv-root
Thread model: win32
gcc version 4.4.0 20080510 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-B/mingw/src/gccsvn/obj/./prev-gcc/'
'-B/mingw/i386-pc-mingw32/bin/' '-c' '-g' '-O2' '-D__USE_MINGW_ACCESS'
'-gnatpg' '-gnata' '-gnatws' '-nostdinc' '-I-' '-I.' '-Iada'
'-I../../svn/gcc/ada' '-o' 'ada/ada.o' '-v' '-save-temps' '-mtune=i386'
 /mingw/src/gccsvn/obj/./prev-gcc/gnat1.exe -I- -I. -Iada -I../../svn/gcc/ada
-quiet -nostdinc -dumpbase ada.ads -O2 -g -gnatpg -gnata -gnatws -mtune=i386
-gnatO ada/ada.o ../../svn/gcc/ada/ada.ads -o ada.s
+===GNAT BUG DETECTED==+
| 4.4.0 20080510 (experimental) (i386-pc-mingw32) Assert_Failure
uintp.adb:1595|
| No source file position information available|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

(gdb) run
Starting program: /mingw/src/gccsvn/obj/./prev-gcc/gnat1.exe -I- -I. -Iada
-I../../svn/gcc/ada -quiet -nostdinc -dumpbase ada.ads -O2 -g -gnatpg -gnata
-gnatws -mtune=i386 -gnatO ada/ada.o ../../svn/gcc/ada/ada.ads -o ada.s
[New thread 1908.0x11bc]

Breakpoint 5, uintp.ui_expon (left=600032770, right=600032767)
at ../../svn/gcc/ada/uintp.adb:1595
1595  pragma Assert (Right >= Uint_0);
(gdb) print Right
$7 = 600032767
(gdb) print Uint_0
$8 = 600032768
(gdb) bt
#0  uintp.ui_expon (left=600032770, right=600032767)
at ../../svn/gcc/ada/uintp.adb:1595
#1  0x00497451 in cstand.build_signed_integer_type (e=17, siz=0)
at ../../svn/gcc/ada/cstand.adb:160
#2  0x00498917 in cstand.create_standard ()
at ../../svn/gcc/ada/cstand.adb:473
#3  0x005556d5 in frontend () at ../../svn/gcc/ada/frontend.adb:88
#4  0x006a0b37 in gnat1drv () at ../../svn/gcc/ada/gnat1drv.adb:432
#5  0x00422657 in gnat_parse_file (set_yydebug=0)
at ../../svn/gcc/ada/misc.c:240
#6  0x006fe03e in toplev_main (argc=20, argv=0x3d42f8)
at ../../svn/gcc/toplev.c:962
#7  0x006a14d9 in main (argc=) at ../../svn/gcc/main.c:35
(gdb) frame 2
#2  0x00498917 in cstand.create_standard ()
at ../../svn/gcc/ada/cstand.adb:473

(gdb) print Standard_Short_Short_Integer
$9 = 694
(gdb) print Standard_Short_Short_Integer_Size
$10 = 8


-- 
   Summary: [4.4 regression] Ada bootstrap fails in uintp.adb:1595
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: build
  Severity: major
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaronavay62 at aaronwl dot com
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


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

[Bug libstdc++/36022] stl templates exported as weak symbols though visibility hidden is used

[mh+gcc at glandium dot org]

--- Comment #2 from mh+gcc at glandium dot org  2008-05-11 09:18 ---
Usually, when you're using visibility hidden, that means you want to avoid
exporting a lot of cruft symbols from a shared library... that the std::
namespace is always visibility default is an annoyance. Especially considering
the set of exported symbols change with optimization, since some of these might
end up inlined:

$ g++-4.3 -O3 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o
foo.so foo.cpp 
$ objdump -T -C foo.so | grep std
0780  w   DF .text  02fe  Basevoid
std::__introsort_loop(int*, int*, long)

$ g++-4.3 -O2 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o
foo.so foo.cpp 
$ objdump -T -C foo.so | grep std
0a40  w   DF .text  00a6  Basevoid
std::__insertion_sort(int*, int*)
08d0  w   DF .text  0161  Basevoid
std::__introsort_loop(int*, int*, long)
07e0  w   DF .text  00eb  Basevoid
std::__adjust_heap(int*, long, long, int)

$ g++-4.3 -O1 -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -o
foo.so foo.cpp 
$ objdump -T -C foo.so | grep std
0c65  w   DF .text  0063  Basevoid
std::make_heap(int*, int*)
0ee0  w   DF .text  0051  Basevoid
std::__final_insertion_sort(int*, int*)
0b52  w   DF .text  0024  Basevoid
std::__unguarded_linear_insert(int*, int)
0b76  w   DF .text  0053  Basevoid
std::__push_heap(int*, long, long, int)
0b10  w   DF .text  0042  Baseint*
std::__unguarded_partition(int*, int*, int)
0d21  w   DF .text  0053  Basevoid
std::sort_heap(int*, int*)
0cc8  w   DF .text  0059  Basevoid
std::__heap_select(int*, int*, int*)
0e72  w   DF .text  006a  Basevoid
std::__insertion_sort(int*, int*)
0d80  w   DF .text  00f2  Basevoid
std::__introsort_loop(int*, int*, long)
0bc9  w   DF .text  009c  Basevoid
std::__adjust_heap(int*, long, long, int)


-- 


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

[Bug libgomp/36208] New: Boolean type discrepancy between gfortran and libgomp

[rsandifo at gcc dot gnu dot org]

Sorry in advance if this is a dup or known issue.  While writing
a patch for IRA, I came across a hang in libgomp.fortran/do2.f90.
The problem is that gomp_loop_ordered_static_next & friends
return a C _Bool, which on i686-pc-linux-gnu is a single byte
(i.e. it has QImode).  But omp-builtins.def says that the function
returns a BT_BOOL, which means boolean_type_node.  boolean_type_node
is logical(kind=4) for Fortran (i.e. it maps to SImode), so the
upper 24 bits of the return value can be tested uninitialised.

We get lucky on trunk because %eax happens to be zero before
the "sete %al" instruction in gomp_loop_ordered_static_next.
This is not deliberate; it just so happens that the locking
code always leaves it that way.  The patch I'm working on
swaps the allocation of %eax and %edx for two allocnos,
such that %edx is accidentally zero instead.

Richard


-- 
   Summary: Boolean type discrepancy between gfortran and libgomp
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
 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=36208

[Bug libfortran/36200] [mingw] Wrong rounding in floating-point I/O

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-05-11 11:00 
---
This should be double-checked by someone who understand this weird printf
format better than me, but I think it's a __mingw_snprintf bug:

$ cat u.c
#include 
extern int __mingw_snprintf (char *, size_t, const char *, ...);

int main (void) {
  char buf[100];
  __mingw_snprintf (buf, 50, "%+-#31.*e\n", 0, 39.);
  puts (buf);
  snprintf (buf, 50, "%+-#31.*e\n", 0, 39.);
  puts (buf);
  return 0;
}

$ gcc u.c && a
+3.e+01

+4.e+001   


The same printf on x86_64-linux gives: "+4.e+01", so it looks both native
Windows and mingw are wrong.


-- 


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[dcb314 at hotmail dot com]

--- Comment #2 from dcb314 at hotmail dot com  2008-05-11 10:35 ---

>Most likely the same issue as PR 36198.

Maybe, but that one only happens with -fprofile-use,
and this one is -O3.

The code compiled fine last week with 20080502,
so the bug looks to be introduced sometime between
20080502 and 20080509.


-- 


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

[Bug bootstrap/25502] I64d format Werror problem in build

[joseph at codesourcery dot com]

--- Comment #15 from joseph at codesourcery dot com  2008-05-11 12:15 
---
Subject: Re:  Werror problem in build

On Sun, 11 May 2008, aaronavay62 at aaronwl dot com wrote:

> --- Comment #13 from aaronavay62 at aaronwl dot com  2008-05-11 03:04 
> ---
> What would be an acceptable solution other than having bootstrap perpetually
> broken, and other than --disable-werror?

You could disable -pedantic when bootstrapping on Windows hosts, or use 
-Wno-error=format, or make it possible to control these warnings 
separately with -Wno-error=format-pedantic.

> 1) We could only enable this warning when in strict mode, eg -std=c99
> -pedantic.  -std=gnu99 -pedantic would not warn.  This seems like it might be
> best.

This isn't how the warning options are meant to work; I don't think we 
want yet more variations on when particular warnings are enabled.


-- 


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

[Bug bootstrap/25502] I64d format Werror problem in build

[joseph at codesourcery dot com]

--- Comment #16 from joseph at codesourcery dot com  2008-05-11 12:17 
---
Subject: Re:  I64d format Werror problem in build

On Sun, 11 May 2008, aaronavay62 at aaronwl dot com wrote:

> Another question: why does "lld" not cause warnings on linux here?  I don't 
> see
> what the difference is.  Whatever the situation is, I don't see any reason 
> that
> "I64d" should behave differently from "lld" in gnu89 mode.

The difference is that "lld" is a standard C99 format and "I64d" isn't; 
-Wno-long-long disables warnings in gnu89 -pedantic mode for certain 
standard C99 usages, not for non-standard usages.  You could add 
-Wno-long-long-windows-formats to disable warning for "I64d" in both gnu89 
and gnu99 modes.


-- 


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

[Bug c/36209] New: arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7

[john dot spelis at 3dlabs dot com]

Whilst building the 'procps'
package, using a 4.3.0 (ARM) cross-compiler
the compiler segment faulted.

  arm-3d-linux-gnueabi-gcc -c -D_GNU_SOURCE
-I proc -I/usr/include/ncurses -fno-common -ffast-math -W -Wall
-Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast
-Wcast-qual -Wwrite-strings -Waggregate-return
-Wstrict-prototypes -Wmissing-prototypes -O2 -s
-Wdeclaration-after-statement -Wpadded -Wstrict-aliasing
-fweb -frename-registers -fomit-frame-pointer
-fno-inline-functions -DSHARED=1 -fpic proc/sysinfo.c -o proc/sysinfo.o

  proc/sysinfo.c: In function get_pid_digits
  proc/sysinfo.c:896: internal compiler error: Segmentation fault

The woraround is not use any optimisation in this file at all
as all of -O, -O2, -O3 cause the segment fault.

The 'procps' package was the latest release

   http://procps.sourceforge.net/
procps-3.2.7.tar.gz

The procps package builds within it's own src tree

   make CC=arm-3d-linux-gnueabi-gcc

#
  arm-3d-linux-gnueabi-gcc -v -save-temps -Wall -c -D_GNU_SOURCE
-I proc -I/usr/include/ncurses -fno-common -ffast-math -W -Wall
-Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast
-Wcast-qual -Wwrite-strings -Waggregate-return
-Wstrict-prototypes -Wmissing-prototypes -O2 -s
-Wdeclaration-after-statement -Wpadded -Wstrict-aliasing
-fweb -frename-registers -fomit-frame-pointer
-fno-inline-functions -DSHARED=1 -fpic proc/sysinfo.c -o proc/sysinfo.o
# --

Using built-in specs.
Target: arm-3d-linux-gnueabi
Configured with: /homes/system/s5_eabi_tools/gcc-4.3.0/gcc-4.3.0/configure
--prefix=/opt/s5toolsl21/lx_eabi --with-mpfr=/opt/s5toolsl21/native_utils/mpfr
--with-gmp=/opt/s5toolsl21/native_utils/gmp --with-gnu-as --with-gnu-ld
--with-as=/opt/s5toolsl21/lx_eabi/bin/arm-3d-linux-gnueabi-as
--with-ld=/opt/s5toolsl21/lx_eabi/bin/arm-3d-linux-gnueabi-ld
--srcdir=/homes/system/s5_eabi_tools/gcc-4.3.0/gcc-4.3.0
--with-sysroot=/opt/s5toolsl21/syslx_eabi --target=arm-3d-linux-gnueabi
--with-cpu=arm926ej-s --enable-languages=c,c++ --without-newlib
Thread model: posix
gcc version 4.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-D_GNU_SOURCE' '-I' 'proc'
'-I/usr/include/ncurses' '-fno-common' '-ffast-math' '-W' '-Wall' '-Wshadow'
'-Wcast-align' '-Wredundant-decls' '-Wbad-function-cast' '-Wcast-qual'
'-Wwrite-strings' '-Waggregate-return' '-Wstrict-prototypes'
'-Wmissing-prototypes' '-O2' '-s' '-Wdeclaration-after-statement' '-Wpadded'
'-Wstrict-aliasing' '-fweb' '-frename-registers' '-fomit-frame-pointer'
'-fno-inline-functions' '-DSHARED=1' '-fpic' '-o' 'proc/sysinfo.o'
'-mcpu=arm926ej-s'
 /opt/s5toolsl21/lx_eabi/libexec/gcc/arm-3d-linux-gnueabi/4.3.0/cc1 -E -quiet
-v -I proc -I/usr/include/ncurses -D_GNU_SOURCE -DSHARED=1 proc/sysinfo.c
-mcpu=arm926ej-s -W -Wall -Wshadow -Wcast-align -Wredundant-decls
-Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return
-Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -Wpadded
-Wstrict-aliasing -fno-common -ffast-math -fweb -frename-registers
-fomit-frame-pointer -fno-inline-functions -fpic -O2 -fpch-preprocess -o
sysinfo.i
ignoring nonexistent directory "/opt/s5toolsl21/syslx_eabi/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 proc
 /usr/include/ncurses
 /opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.3.0/include
 /opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.3.0/include-fixed

/opt/s5toolsl21/lx_eabi/lib/gcc/arm-3d-linux-gnueabi/4.3.0/../../../../arm-3d-linux-gnueabi/include
 /opt/s5toolsl21/syslx_eabi/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-D_GNU_SOURCE' '-I' 'proc'
'-I/usr/include/ncurses' '-fno-common' '-ffast-math' '-W' '-Wall' '-Wshadow'
'-Wcast-align' '-Wredundant-decls' '-Wbad-function-cast' '-Wcast-qual'
'-Wwrite-strings' '-Waggregate-return' '-Wstrict-prototypes'
'-Wmissing-prototypes' '-O2' '-s' '-Wdeclaration-after-statement' '-Wpadded'
'-Wstrict-aliasing' '-fweb' '-frename-registers' '-fomit-frame-pointer'
'-fno-inline-functions' '-DSHARED=1' '-fpic' '-o' 'proc/sysinfo.o'
'-mcpu=arm926ej-s'
 /opt/s5toolsl21/lx_eabi/libexec/gcc/arm-3d-linux-gnueabi/4.3.0/cc1
-fpreprocessed sysinfo.i -quiet -dumpbase sysinfo.c -mcpu=arm926ej-s
-auxbase-strip proc/sysinfo.o -O2 -W -Wall -Wshadow -Wcast-align
-Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
-Wdeclaration-after-statement -Wpadded -Wstrict-aliasing -version -fno-common
-ffast-math -fweb -frename-registers -fomit-frame-pointer -fno-inline-functions
-fpic -o sysinfo.s
GNU C (GCC) version 4.3.0 (arm-3d-linux-gnueabi)
compiled by GNU C version 4.3.0, GMP version 4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7c3f80f5d14a419f1f92cb195c805d22
proc/sysinfo.c: In function �

[Bug c/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7

[john dot spelis at 3dlabs dot com]

--- Comment #1 from john dot spelis at 3dlabs dot com  2008-05-11 13:32 
---
Created an attachment (id=15625)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15625&action=view)
The sysinfo.i output for the segment fault compilation


-- 


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

[Bug libfortran/36202] [mingw] Namelist read fails with CRLF

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-05-11 13:32 
---
I will see if I can sort this out.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-10 22:04:55 |2008-05-11 13:32:59
   date||


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

[Bug other/36210] New: [4.3/4.4 Regression] as doesn't like the assembler code

[bunk at stusta dot de]

$ arm-linux-gcc -Wp,-MD,arch/arm/mm/.mmu.o.d  -nostdinc -isystem
/usr/local/DIR/gcc-arm-4.3-20080508/lib/gcc/arm-linux/4.3.1/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -mlittle-endian
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mm -Iarch/arm/mm -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Os -fno-stack-protector -marm
-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux
-mno-thumb-interwork -D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=xscale
-Wa,-mcpu=xscale -msoft-float -Uarm -fno-omit-frame-pointer
-fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign 
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(mmu)" 
-D"KBUILD_MODNAME=KBUILD_STR(mmu)" -c -o arch/arm/mm/mmu.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mm/mmu.c -save-temps
mmu.s: Assembler messages:
mmu.s:382: Error: can't resolve `_end' {*UND* section} - `_stext' {*UND*
section}
$ 

Working:
- 4.3-20080501

Broken:
- 4.3-20080508

Not tested:
- 4.4

Preprocessed source is the same, diff of the assembler code:

--- mmu.s-working   2008-05-11 16:03:42.0 +0300
+++ mmu.s-broken2008-05-11 16:05:10.0 +0300
@@ -365,10 +365,9 @@
sub fp, ip, #4
sub sp, sp, #4
ldr r1, .L51
-   ldr r2, .L51+4
mov r4, r0
+   ldr r2, .L51+4
mov r3, #0
-   rsb r2, r1, r2
bl  reserve_bootmem_node
mov r0, r4
ldr r1, .L51+8
@@ -380,7 +379,7 @@
.align  2
 .L51:
.word   _stext-536870912
-   .word   _end-536870912
+   .word   _end-_stext
.word   swapper_pg_dir-536870912
.size   reserve_node_zero, .-reserve_node_zero
.section.rodata.str1.1


-- 
   Summary: [4.3/4.4 Regression] as doesn't like the assembler code
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-unknown-linux-gnu


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

[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code

[bunk at stusta dot de]

--- Comment #1 from bunk at stusta dot de  2008-05-11 14:01 ---
Created an attachment (id=15626)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15626&action=view)
preprocessed source


-- 


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

[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code

[bunk at stusta dot de]

--- Comment #2 from bunk at stusta dot de  2008-05-11 14:02 ---
Created an attachment (id=15627)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15627&action=view)
assembler generated by 4.3-20080501 (working)


-- 


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

[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code

[bunk at stusta dot de]

--- Comment #3 from bunk at stusta dot de  2008-05-11 14:03 ---
Created an attachment (id=15628)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15628&action=view)
assembler generated by 4.3-20080508 (broken)


-- 


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

[Bug libstdc++/36211] New: __iconv_adaptor chooses char** where const char** is required

[tprince at computer dot org]

libstdc++ testsuite cases which require libiconv fail on account of trying the
wrong choice in __iconv_adaptor:
/cygdrive/c/gnu/gcc-4.4-20080509/xp/i686-pc-cygwin/libstdc++-v3/include/ext/code
cvt_specializations.h:302: undefined reference to `_libiconv'^M

#ifndef LIBICONV_PLUG
#define iconv libiconv
#endif
extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft,
char*
 * outbuf, size_t *outbytesleft);


-- 
   Summary: __iconv_adaptor chooses char** where const char** is
required
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tprince at computer dot org
 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=36211

[Bug libfortran/36202] [mingw] Namelist read fails with CRLF

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-05-11 14:25 
---
Here is proposed patch:

Index: list_read.c
===
--- list_read.c (revision 135150)
+++ list_read.c (working copy)
@@ -347,20 +347,12 @@ eat_separator (st_parameter_dt *dtp)
 case '\r':
   dtp->u.p.at_eol = 1;
   n = next_char(dtp);
-  if (n == '\n')
+  if (n != '\n')
{
- if (dtp->u.p.namelist_mode)
-   {
- do
-   c = next_char (dtp);
- while (c == '\n' || c == '\r' || c == ' ');
- unget_char (dtp, c);
-   }
+ unget_char (dtp, n);
+ break;
}
-  else
-   unget_char (dtp, n);
-  break;
-
+/* Fall through.  */
 case '\n':
   dtp->u.p.at_eol = 1;
   if (dtp->u.p.namelist_mode)


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug libfortran/36200] [mingw] Wrong rounding in floating-point I/O

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2008-05-11 14:53 
---
Bug reported to mingw:
http://sourceforge.net/tracker/index.php?func=detail&aid=1961893&group_id=2435&atid=102435

Closing here.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/36120] selected_char_kind_1.f90 undefined reference with -m32

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2008-05-11 14:58 
---
Closing.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/36202] [mingw] Namelist read fails with CRLF

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-05-11 15:03 
---
Subject: Bug 36202

Author: jvdelisle
Date: Sun May 11 15:02:41 2008
New Revision: 135177

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135177
Log:
2008-05-11  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/36202
* io/list_read (eat_separator): Handle the CR-LF case correctly.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c


-- 


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

[Bug libfortran/36202] [mingw] Namelist read fails with CRLF

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-05-11 15:10 
---
Fixed on trunk


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[tprince at computer dot org]

--- Comment #1 from tprince at computer dot org  2008-05-11 15:57 ---
2 unicode.cc tests fail.  Several other tests with -liconv pass.


-- 


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

[Bug c++/8045] Missing "unused variable" warning

[flameeyes at gentoo dot org]

--- Comment #4 from flameeyes at gentoo dot org  2008-05-11 16:31 ---
I think this applies to 4.3 as well, as the following code does only warn in
the second function:

#include 
#include 

char* oldstyle(const char *foo) {
  size_t foolen;

  if ( foo == NULL )
return NULL;

  foolen = strlen(foo);

  return strdup(foo);
}

char* newstyle(const char *foo) {
  if ( foo == NULL )
return NULL;

  const size_t foolen = strlen(foo);

  return strdup(foo);
}

And I could really make use of such a warning in xine-lib's code :)


-- 

flameeyes at gentoo dot org changed:

   What|Removed |Added

 CC||flameeyes at gentoo dot org


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

[Bug fortran/36192] ICE with wrong index types and bad parens

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2008-05-11 16:40 ---
For the record: after fixing the syntax errors, the executable gives an
infinite loop when compiled with gfortran 4.3.0 on *i-apple-darwin9 and 4.4.0
(patched) on i686-apple-darwin9, but not on 4.4.0 (also patched) on
powerpc-apple-darwin9.  The infinite loop comes from a nasty (even for trained
eyes) typo which leaves the intent(out) dummies xn and vn unset on return of
subroutine step (since the code seems to be some homework, I leave the reporter
complete the debugging himself).

The points of interest for the gfortran maintainers are: 

(1) are there other platforms on which there is no infinite loop? and if yes
why?
(2) I think the problem could be diagnosed at compiled time (possibly with -O
only). If it can now, I did not find the right option. If not, should I open a
pr along this line or would it deemed too difficult to implement?

Final note, the code has at least another bug (hint: set n=2, d=3 and compile
with -fbounds-check).


-- 


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-05-11 17:13 
---
Why, exactly, do you believe the problem is with the const? The code and the
comment in codecvt_specializations.h appear to indicate that we are already
dealing correctly with the issue and indeed you are reporting that other tests
link fine...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||dannysmith at users dot
   ||sourceforge dot net


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/36139] ICE in snapshot of 05/02/08 under HPPA Linux with IMPLICIT, PARAMETER, and function call

[michael dot a dot richmond at nasa dot gov]

--- Comment #2 from michael dot a dot richmond at nasa dot gov  2008-05-11 
17:16 ---
(In reply to comment #1)
> Though I do not get segfault, I can confirm valgrind errors.

The segfault does not occur in the snapshot of May 9. I suspect the valgrind
errors occur on multiple platforms, but they produce a segfault only when some
chance condition is met.

Jerry, can you tell me how to test for these errors?


-- 


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[tprince at computer dot org]

--- Comment #3 from tprince at computer dot org  2008-05-11 17:26 ---
I see that the failing case is looking for a libiconv in the library to match
the char ** prototype, and failing to find one, while the one in the actual
library is set up for the const char ** version.  The comment in
codecvt_specializations.h indicates this should be taken care of by 
__iconv_adaptor, yet the link failure shows this is not working.
I don't understand the usage well enough to know what to conclude, why some
cases (do they also exercise __iconv_adaptor ?) work, while the unicode.cc
cases fail to link at that point.
This problem has been brought up by others in mail lists, but as far as I know
no one wrote up a PR.


-- 


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-05-11 17:31 
---
Please add pointers to the discussions on those mailing lists.


-- 


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

[Bug fortran/36139] ICE in snapshot of 05/02/08 under HPPA Linux with IMPLICIT, PARAMETER, and function call

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-05-11 17:34 
---
Use the following

 valgrind --leak-check=full f951 pr36139.f90

In my case f951 is in my search path as a link:

f951 -> /home/jerry/gcc/obj44/gcc/f951

obj44 is the build directory


-- 


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

[Bug tree-optimization/36204] [4.4 Regression] missed store sinking out of a loop

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-05-11 17:48 ---
I think this is related to PR36009.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||36009
  nThis||


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

[Bug tree-optimization/36009] PRE causes missed loop store motion, store sinking doesn't work

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-11 17:51 ---
I bet this is a regression in fact and not really an enhancement.  Lim  was
doing the store motion in previous versions of GCC but was disabled when the
aliasing oracle patch went in (there was no explication for that part of the
change).


-- 


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-05-11 17:54 ---
Which is good, as in the end these are the same bugs.  But - where's the
testcase
for this?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||36198
  nThis||
 Status|UNCONFIRMED |WAITING


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

[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-05-11 17:55 ---
I think this was fixed on the 4.3 branch by

2008-05-08  David Edelsohn  <[EMAIL PROTECTED]>

PR target/36090
* config/rs6000/rs6000.c (print_operand_address): If the TOC
address RHS contains an offset, output it as well.

PR target/36182
Revert:
2008-05-08  Paolo Bonzini  <[EMAIL PROTECTED]>
PR target/36090
* simplify-rtx.c (simplify_plus_minus): Create CONST of
similar RTX_CONST_OBJ before CONST_INT.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Target Milestone|--- |4.3.1


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[tprince at computer dot org]

--- Comment #5 from tprince at computer dot org  2008-05-11 18:04 ---
Only the gcc-testresults reports where others report the same thing are clearly
relevant:
http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg01444.html
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01528.html


In other cases, the poster did not provide sufficient information to establish
conclusively it was the same problem.
It is generally not reported in testresults whether libstdc++ tests were run
with libiconv installed.  If libiconv is not installed, none of these tests are
attempted.


-- 


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-05-11 18:13 
---
Frankly, we badly need more details and/or the help of a cygwin maintainer,
because by looking statically at the code I don't see how possibly
__iconv_adaptor can be wrong and most (all?) the active libstdc++ maintainers
do not have a cygwin machine available.


-- 


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

[Bug tree-optimization/36129] [4.3 Regression] ICE with -fprofile-use

[uros at gcc dot gnu dot org]

--- Comment #15 from uros at gcc dot gnu dot org  2008-05-11 18:54 ---
Subject: Bug 36129

Author: uros
Date: Sun May 11 18:54:15 2008
New Revision: 135180

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135180
Log:
Backport from mainline:
2008-05-09  Uros Bizjak  <[EMAIL PROTECTED]>

PR tree-optimization/36129
* tree-ssa-ccp.c: Include value-prof.h.
(execute_fold_all_builtins): Call gimple_remove_stmt_histograms if
built-in function was folded to a constant.
* Makefile.in (tree-ssa-ccp.c): Depend on value-prof.h


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/Makefile.in
branches/gcc-4_3-branch/gcc/tree-ssa-ccp.c


-- 


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

[Bug tree-optimization/36129] [4.3 Regression] ICE with -fprofile-use

[ubizjak at gmail dot com]

--- Comment #16 from ubizjak at gmail dot com  2008-05-11 18:56 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[dcb314 at hotmail dot com]

--- Comment #4 from dcb314 at hotmail dot com  2008-05-11 19:11 ---
Created an attachment (id=15629)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15629&action=view)
Fortran source code


-- 


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[dcb314 at hotmail dot com]

--- Comment #5 from dcb314 at hotmail dot com  2008-05-11 19:12 ---
(In reply to comment #3)
> But - where's the testcase for this?

Sorry - now attached.


-- 


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

[Bug c/36212] New: Vector alignment overides Target alignment

[hutchinsonandy at gcc dot gnu dot org]

For avr we have multiple failures of testcases due to alignment warnings such
as:

gcc/gcc/testsuite/gcc.dg/debug/const-1.c:3: warning: alignment of 'Foo' is 
 greater than maximum object file alignment.  Using 1

Which in this example occurs due to:

typedef float FloatVect __attribute__((__vector_size__(16)));
FloatVect Foo = { 25000.0, 0.0, 0.0, 0.0 };

While trying to fix this I have discovered several issues which make the
"correct" fix somewhat unclear and perhaps indicating more than one bug.

The warning occurs because alignment of the vector is 16 bytes regardless of
all target alignment controls. In particular:

#define BIGGEST_ALIGNMENT 8


By default this also determines MAX_OFILE_ALIGNMENT which is used by the
alignment check in varasm.c (if (16>1) Warning)

Problem 1) varasm.c - is the only place MAX_OFILE_ALIGNMENT is used. Here it
immediately tries to increase or decrease alignment AFTER it does check - which
suggests the check is misplaced or not useful in the first place.


To get around the test failure target MAX_OFILE_ALIGNMENT can be increased.
(and logically should be to permit user defined alignments)


Problem 2) Without hard limit imposed by MAX_OFILE_ALIGNMENT vectors are
aligned at 16 bytes - which break the supposed limit of BIGGEST_ALIGNMENT (1
byte).

Vector size is set in stor-layout.c :

/* Always naturally align vectors.  This prevents ABI changes
   depending on whether or not native vector modes are supported.  */
TYPE_ALIGN (type) = tree_low_cst (TYPE_SIZE (type), 0);
break;

There is no way for target to override this alignment. It does not seem correct
to assume a specific vector alignment independent of target. Perhaps there
should be:

#ifdef  TARGET_VECTOR_ALIGN (..)
...
...
#else


Some may say that vectors are relevant only targets that support hardware
vector operations and thus alignment choice is currently moot. But..

Problem 3) gcc provide no hooks for  the target or testsuite to elegantly
disable vector extensions (that I can find anyway).


-- 
   Summary: Vector alignment overides Target alignment
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
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=36212

[Bug c++/35578] [4.2/4.3 Regression] Error about misplaced 'friend' word is issued on a wrong line

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2008-05-11 19:33 
---
Subject: Bug 35578

Author: reichelt
Date: Sun May 11 19:32:51 2008
New Revision: 135181

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135181
Log:
PR c++/35578
* parser.c (cp_parser_decl_specifier_seq): Add location to error
message.

* g++.dg/parse/friend8.C: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/friend8.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35578] [4.2/4.3 Regression] Error about misplaced 'friend' word is issued on a wrong line

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2008-05-11 19:36 
---
Subject: Bug 35578

Author: reichelt
Date: Sun May 11 19:35:20 2008
New Revision: 135182

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135182
Log:
PR c++/35578
* parser.c (cp_parser_decl_specifier_seq): Add location to error
message.

* g++.dg/parse/friend8.C: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/parse/friend8.C
Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/parser.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35578] [4.2/4.3 Regression] Error about misplaced 'friend' word is issued on a wrong line

[reichelt at gcc dot gnu dot org]

--- Comment #7 from reichelt at gcc dot gnu dot org  2008-05-11 19:37 
---
Now also fixed on the 4.3 and 4.2 branch.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36212] Vector alignment overides Target alignment

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-11 19:38 ---
>Problem 3) gcc provide no hooks for  the target or testsuite to elegantly
> disable vector extensions (that I can find anyway).

Problem 3 is bogus as vector extensions are generic and use what ever exist for
your target.  Now the alignment should also be constraint by BIGGEST_ALIGNMENT
.

I am in the process of rewriting the vector extension documentation so it
should become more clear that it is a generic extension and has nothing to do
with the target at all except for the fact they become faster.


-- 


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

[Bug preprocessor/36213] New: Wrong search path generation

[martin dot drab at fjfi dot cvut dot cz]

The gcc version 4.4.0 20080511 (experimental) (GCC) when compiled with these
options:


$ gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../../../gcc-SVN-20080511/gcc-SVN-20080511/configure
--build=x86_64-pc-linux-gnu --prefix=/usr/local/opt/MDL/opt/gcc-4.4
--exec-prefix=/usr/local/opt/MDL/opt/gcc-4.4 --sysconfdir=/etc
--libdir=/usr/local/opt/MDL/opt/gcc-4.4/lib64
--libexecdir=/usr/local/opt/MDL/opt/gcc-4.4/libexec64
--includedir=/usr/local/opt/MDL/opt/gcc-4.4/include
--infodir=/usr/local/opt/MDL/opt/gcc-4.4/share/info
--mandir=/usr/local/opt/MDL/opt/gcc-4.4/share/man --program-suffix=-4.4
--sharedstatedir=/var --localstatedir=/var --enable-languages=c,c++,fortran
--enable-generated-files-in-srcdir --enable-targets=all --disable-libada
--enable-libssp --disable-werror --enable-shared --enable-static
--enable-parallel-mark --with-gnu-ld --disable-werror-always --enable-multilib
--enable-threads=posix --enable-tls --disable-rpath
--enable-version-specific-runtime-libs --with-demangler-in-ld --with-gnu-as
--with-x --disable-coverage --disable-checking --enable-visibility
--with-arch=core2
Thread model: posix
gcc version 4.4.0 20080511 (experimental) (GCC)


generates wrong paths in the search list:


$ gcc -print-search-dirs
install:
/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0x86_64-pc-linux-gnu/4.4.0/
programs:
=/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../libexec64/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../libexec64/gcc/:/usr/local/opt/MDL/opt/gcc-4.4/libexec64/gcc/x86_64-pc-linux-gnu/4.4.0/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/libexec64/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/bin/
libraries:
=/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/32/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib64/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib32/../lib64/:/usr/local/opt/MDL/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/lib64/../lib64/:/usr/local/opt/MDL/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/lib32/../lib64/:/lib64/x86_64-pc-linux-gnu/4.4.0/:/lib64/../lib64/:/lib32/x86_64-pc-linux-gnu/4.4.0/:/lib32/../lib64/:/usr/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/lib64/../lib64/:/usr/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/lib32/../lib64/:/usr/local/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/local/lib64/../lib64/:/usr/local/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/lib32/../lib64/:/usr/X11R6/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/X11R6/lib64/../lib64/:/usr/X11R6/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/X11R6/lib32/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../lib64/:/lib/x86_64-pc-linux-gnu/4.4.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.4.0/:/usr/lib/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/32/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib32/:/usr/local/opt/MDL/lib64/:/usr/local/opt/MDL/lib32/:/lib64/:/lib32/:/usr/lib64/:/usr/lib32/:/usr/local/lib64/:/usr/local/lib32/:/usr/X11R6/lib64/:/usr/X11R6/lib32/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/lib/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../:/lib/:/usr/lib/


Here notice namely the "install:" line, where the tail seems to be somehow
strangely duplicated, creating a nonexisting directory. It

[Bug preprocessor/36213] Wrong search path generation

[martin dot drab at fjfi dot cvut dot cz]

--- Comment #1 from martin dot drab at fjfi dot cvut dot cz  2008-05-11 
19:43 ---
Moreover, I think that the "../../" that also appears in some of the search
paths that are found as nonexistent should actually be "../../../".


-- 


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

[Bug preprocessor/36213] Wrong search path generation

[martin dot drab at fjfi dot cvut dot cz]

-- 

martin dot drab at fjfi dot cvut dot cz changed:

   What|Removed |Added

   Severity|normal  |major


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-05-11 19:52 ---
Sebastian - this has a way simpler testcase than PR36198.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org
 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-05-11 19:52:49
   date||


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

[Bug middle-end/36212] Vector alignment overides Target alignment

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #2 from hutchinsonandy at gcc dot gnu dot org  2008-05-11 19:53 
---
I was just covering bases with 3. I'll be quite content if the vectors could
obey BIGGEST_ALIGNMENT.


-- 


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

[Bug fortran/36139] ICE in snapshot of 05/02/08 under HPPA Linux with IMPLICIT, PARAMETER, and function call

[michael dot a dot richmond at nasa dot gov]

--- Comment #4 from michael dot a dot richmond at nasa dot gov  2008-05-11 
19:56 ---
(In reply to comment #3)
> Use the following
> 
>  valgrind --leak-check=full f951 pr36139.f90

I downloaded http://valgrind.org/downloads/valgrind-3.3.0.tar.bz2 and attempted
to build valgrind on HP-PA 1.1 and MIPS systems running Debian Linux 4.0. On
both systems I got the message "configure: error: Unsupported host
architecture. Sorry"


-- 


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

[Bug fortran/35719] pointer to zero sized array not associated

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2008-05-11 20:29 ---
Subject: Bug 35719

Author: tkoenig
Date: Sun May 11 20:28:52 2008
New Revision: 135187

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135187
Log:
2008-05-11  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/35719
* trans.c (gfc_call_malloc): If size equals zero, allocate one
byte; don't return a null pointer.

2008-05-11  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/35719
* gfortran.dg/associated_5.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associated_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36176] TRANSFER of constant substrings

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||05/msg00659.html
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2008-05-11 20:31:26
   date||


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

[Bug fortran/35719] pointer to zero sized array not associated

[tkoenig at gcc dot gnu dot org]

--- Comment #9 from tkoenig at gcc dot gnu dot org  2008-05-11 20:39 ---
Fixed on trunk.

I don't think this really needs to be fixed on 4.3, so
I am closing this.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail||4.3.1
  Known to work||4.4.0
 Resolution||FIXED


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

[Bug target/35661] __attribute__((cold)) generates wrong code

[dannysmith at gcc dot gnu dot org]

--- Comment #6 from dannysmith at gcc dot gnu dot org  2008-05-11 21:04 
---
Subject: Bug 35661

Author: dannysmith
Date: Sun May 11 21:03:27 2008
New Revision: 135188

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135188
Log:
Backport from mainline:
2008-04-15  Zuxy Meng  <[EMAIL PROTECTED]>

PR target/35661
* config/i386/winnt.c (i386_pe_section_type_flags): Mark
".text.unlikely" section as executable.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/winnt.c


-- 


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

[Bug target/35661] __attribute__((cold)) generates wrong code

[dannysmith at users dot sourceforge dot net]

--- Comment #7 from dannysmith at users dot sourceforge dot net  2008-05-11 
21:09 ---
Fixed on 4_3 branch


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.1


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

[Bug bootstrap/25502] I64d format Werror problem in build

[aaronavay62 at aaronwl dot com]

--- Comment #17 from aaronavay62 at aaronwl dot com  2008-05-11 21:24 
---
(In reply to comment #16)
> -Wno-long-long disables warnings in gnu89 -pedantic mode for certain 
> standard C99 usages, not for non-standard usages.  You could add 
> -Wno-long-long-windows-formats to disable warning for "I64d" in both gnu89 
> and gnu99 modes.

I like this idea; it lets us resolve this issue without having to neuter this
port in one way or another.  If there are no objections, I will prepare a patch
for this.

On naming, this isn't so much a Windowsism as a MSVCism.  Maybe this should be
named -Wlong-long-ms-formats similarly to -fms-extension or
-fvisibility-ms-compat?


-- 

aaronavay62 at aaronwl dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aaronavay62 at aaronwl dot
   |dot org |com
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-11 04:48:20 |2008-05-11 21:24:33
   date||


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

[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3

[spop at gcc dot gnu dot org]

-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-11 19:52:49 |2008-05-11 21:30:11
   date||


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

[Bug tree-optimization/36198] [4.4 Regression] expected integer_cst, have mult_expr

[spop at gcc dot gnu dot org]

-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-10 12:36:11 |2008-05-11 21:30:18
   date||


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

[Bug c/35761] GCC 4.3.0 tar 1.19 and glibc 2.7 bug with __cplusplus and -O2

[channelzero at web dot de]

--- Comment #3 from channelzero at web dot de  2008-05-11 21:54 ---
I can confirm a make error in tar, last step of build fails:

gcc -std=gnu99  -g -O2   -o tar  buffer.o compare.o create.o delete.o extract.o
xheader.o incremen.o list.o misc.o names.o sparse.o system.o tar.o transform.o
update.o utf8.o ../lib/libtar.a   -lrt

lots of messages like this with other function names:

../lib/libtar.a(argp-fmtstream.o): In function `argp_fmtstream_putc':
/mnt/lfs/builder/build/tar-1.19/lib/argp-fmtstream.h:233: multiple definition
of `argp_fmtstream_putc'
tar.o:/mnt/lfs/builder/build/tar-1.19/src/../lib/argp-fmtstream.h:233: first
defined here

I tried -O0, this worked, only difference is inline functions will not used.
Then I tried -O2 -fno-inline-functions won't work.

It seems to be an tar problem, I just read this:
http://lists.gnu.org/archive/html/bug-tar/2008-04/msg6.html

Ok fixed with tar-1.20


-- 


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

[Bug fortran/36214] New: Wrong simplification of BOZ constants

[fxcoudert at gcc dot gnu dot org]

$ cat u.f90
   implicit none
   real, parameter :: r = transfer(0,0.)
   real(kind=8), parameter :: rd = dble(b'&
 &0110100101010001')

   if (cmplx(b'&
  &0110100101010001',0,8) /= rd) call abort

end
$ gfortran u.f90 && ./a.out 
Aborted


That's on x86_64-linux, and the weird thing is: if you remove the useless
definition of r, it starts working again :)  And yet valgrind doesn't have
anything to say. I'm mystified.

(PS: I found that one while investigating PR36186, but it's independent.)


-- 
   Summary: Wrong simplification of BOZ constants
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[dannysmith at users dot sourceforge dot net]

--- Comment #7 from dannysmith at users dot sourceforge dot net  2008-05-11 
22:46 ---
Following is with mingw but it applies to cygwin as well 

This is the command line from log for FAILing 22_locale/locale/cons/unicode.cc

Executing on host: /develop/svn/trunk/build/./gcc/g++ -shared-libgcc
-B/develop/svn/trunk/build/./gcc -nostdinc++
-L/develop/svn/trunk/build/mingw32/libstdc++-v3/src
-L/develop/svn/trunk/build/mingw32/libstdc++-v3/src/.libs
-L/develop/svn/trunk/build/mingw32/winsup/mingw
-L/develop/svn/trunk/build/mingw32/winsup/w32api/lib -isystem
/develop/svn/trunk/src/winsup/mingw/include -isystem
/develop/svn/trunk/src/winsup/w32api/include -B/mingw/mingw32/bin/
-B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem
/mingw/mingw32/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0
-ffunction-sections -fdata-sections -g -O2 -g -O2   -DLOCALEDIR="." -nostdinc++
-I/develop/svn/trunk/build/mingw32/libstdc++-v3/include/mingw32
-I/develop/svn/trunk/build/mingw32/libstdc++-v3/include
-I/develop/svn/trunk/src/libstdc++-v3/libsupc++
-I/develop/svn/trunk/src/libstdc++-v3/include/backward
-I/develop/svn/trunk/src/libstdc++-v3/testsuite/util -Wl,--gc-sections
/mingw/lib/libiconv.a
/develop/svn/trunk/src/libstdc++-v3/testsuite/22_locale/locale/cons/unicode.cc 
  -include bits/stdc++.h ./libtestc++.a  -lm   -o ./unicode.exe(timeout =
600)


Note that although the correct libiconv "/mingw/lib/libiconv.a" is passed to
linker, it is  passed  *before*  the objects and libraries that reference
libiconv symbols.
With PE-COFF, the order of objects really does  matter and  since the libiconv
symbols have not yet been referenced when the linker looks at the lib, the
symbols are not resolved. They are not resolved lazily as is possible in ELF


Danny


-- 


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

[Bug fortran/36215] New: [4.4 regression] Fortran bootstrap fails on _abs_c4.F90

[aaronavay62 at aaronwl dot com]

I've had at least three different (but possibly related) problems when trying
to bootstrap Fortran in 4.4 20080510

1) I get a popup message telling me gfortran.exe has crashed in some configure
scripts, which I have not investigated further

2) When compiling _abs_c4.F90, build fails.  Strangely, when using the build
driver, no output is visible, but when f951.exe is invoked directly, the error
message is visible.

/mingw/src/gccsvn/obj/./gcc/gfortran -B/mingw/src/gccsvn/obj/./gcc/
-L/mingw/src/gccsvn/obj/i386-pc-mingw32/winsup/mingw
-L/mingw/src/gccsvn/obj/i386-pc-mingw32/winsup/w32api/lib -isystem
/mingw/src/gccsvn/svn/winsup/mingw/include -isystem
/mingw/src/gccsvn/svn/winsup/w32api/include -B/mingw/i386-pc-mingw32/bin/
-B/mingw/i386-pc-mingw32/lib/ -isystem /mingw/i386-pc-mingw32/include -isystem
/mingw/i386-pc-mingw32/sys-include -DHAVE_CONFIG_H -I.
-I../../../svn/libgfortran -I. -iquote../../../svn/libgfortran/io
-I../../../svn/libgfortran/../gcc -I../../../svn/libgfortran/../gcc/config
-I../.././gcc -D_GNU_SOURCE -I . -Wall -fno-repack-arrays -fno-underscoring
-fallow-leading-underscore -g -O2 -c
../../../svn/libgfortran/generated/_abs_c4.F90  -DDLL_EXPORT -o .libs/_abs_c4.o
-save-temps -v
Reading specs from /mingw/src/gccsvn/obj/./gcc/specs
Target: i386-pc-mingw32
Configured with: ../svn/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions
--enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry
--enable-libstdcxx-debug --enable-concept-checks
--enable-version-specific-runtime-libs --prefix=/mingw
--with-gmp=/mingw/src/gcc/gmp-mpfr-root
--with-mpfr=/mingw/src/gcc/gmp-mpfr-root
--with-libiconv-prefix=/mingw/src/gcc/libiconv-root
Thread model: win32
gcc version 4.4.0 20080510 (experimental) (GCC) 
...collect2 and cpp noise omitted...
/mingw/src/gccsvn/obj/./gcc/f951.exe _abs_c4.f95 -ffree-form -quiet -dumpbase
_abs_c4.F90 -mtune=i386 -auxbase-strip .libs/_abs_c4.o -g -O2 -Wall -version
-fno-repack-arrays -fno-underscoring -fallow-leading-underscore -I.
-I../../../svn/libgfortran -I. -I../../../svn/libgfortran/../gcc
-I../../../svn/libgfortran/../gcc/config -I../.././gcc -I . -fpreprocessed
-fintrinsic-modules-path finclude -o _abs_c4.s
GNU Fortran (GCC) version 4.4.0 20080510 (experimental) (i386-pc-mingw32)
compiled by GNU C version 4.4.0 20080510 (experimental), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Error: Can't open file '_abs_c4.f95'
:0: fatal error: can't open input file: _abs_c4.f95
compilation terminated.

However, the output file _abs_c4.f95 is actually there.

3) When I attempted to re-run the above command in GDB, I got a crash in
malloc:

Program received signal SIGSEGV, Segmentation fault.
0x7c91b3fb in wcsncat () from C:\WINDOWS\system32\ntdll.dll

(The above message is incorrect due to GDB limitations)

#0  xmalloc (size=54) at ../../svn/libiberty/xmalloc.c:147
#1  0x00440ea8 in gfc_getmem (n=54) at ../../svn/gcc/fortran/misc.c:37
#2  0x0045ed50 in gfc_widechar_to_char (s=0x282a788, length=-1)
at ../../svn/gcc/fortran/scanner.c:198
#3  0x0046058a in preprocessor_line (c=0x282ab4c)
at ../../svn/gcc/fortran/scanner.c:1606
#4  0x00460870 in load_file (
filename=0x282aa00 "../../../svn/libgfortran/generated/_abs_c4.F90", 
initial=1 '\001') at ../../svn/gcc/fortran/scanner.c:1800
#5  0x00460dd9 in gfc_new_file () at ../../svn/gcc/fortran/scanner.c:1912
#6  0x004768e2 in gfc_init () at ../../svn/gcc/fortran/f95-lang.c:288
#7  0x00527e16 in toplev_main (argc=29, argv=0x3d4518)
at ../../svn/gcc/toplev.c:2039
#8  0x004bfa09 in main (argc=) at ../../svn/gcc/main.c:35

So, it looks like there is some sort of heap corruption.

I'm going to look at this more after I've resolved some other issues, and I'm
going to re-bootstrap with more conservative options to see if that helps.


-- 
   Summary: [4.4 regression] Fortran bootstrap fails on _abs_c4.F90
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: build
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaronavay62 at aaronwl dot com
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


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

[Bug libgcj/20654] exception.o is not included in libgcj.a due to case-insensitivity

[aaronavay62 at aaronwl dot com]

--- Comment #9 from aaronavay62 at aaronwl dot com  2008-05-11 23:21 ---
I didn't fix it, but this apparently has been resolved some sort of way in
4.3.0.


-- 

aaronavay62 at aaronwl dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug bootstrap/36216] New: [meta-bug] Bootstrap problems on mingw32

[aaronavay62 at aaronwl dot com]

Meta bug for issues blocking all languages, all subdirectories bootstrap on
i386-pc-mingw32 on 4.4.0 experimental.

These should all be regressions, as this works (except for libmudflap) in
4.3.0.


-- 
   Summary: [meta-bug] Bootstrap problems on mingw32
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaronavay62 at aaronwl dot com
 GCC build triplet: i386-pc-mingw32
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
 BugsThisDependsOn: 25502,36207,36215


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

[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required

[tprince at computer dot org]

--- Comment #8 from tprince at computer dot org  2008-05-12 01:58 ---
Yes, -liconv precedes the source file, where it must follow:
Executing on host: /cygdrive/c/gnu/gcc-4.4-20080509/xp/./gcc/g++ -shared-libgcc
-B/cygdrive/c/gnu/gcc-4.4-20080509/xp/./gcc -nostdinc++
-L/cygdrive/c/gnu/gcc-4.
4-20080509/xp/i686-pc-cygwin/libstdc++-v3/src
-L/cygdrive/c/gnu/gcc-4.4-20080509
/xp/i686-pc-cygwin/libstdc++-v3/src/.libs
-B/usr/local/gcc44/i686-pc-cygwin/bin/
 -B/usr/local/gcc44/i686-pc-cygwin/lib/ -isystem
/usr/local/gcc44/i686-pc-cygwin
/include -isystem /usr/local/gcc44/i686-pc-cygwin/sys-include -g -O2
-D_GLIBCXX_
ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2  
-D
LOCALEDIR="." -nostdinc++
-I/cygdrive/c/gnu/gcc-4.4-20080509/xp/i686-pc-cygwin/l
ibstdc++-v3/include/i686-pc-cygwin
-I/cygdrive/c/gnu/gcc-4.4-20080509/xp/i686-pc
-cygwin/libstdc++-v3/include
-I/cygdrive/c/gnu/gcc-4.4-20080509/libstdc++-v3/lib
supc++ -I/cygdrive/c/gnu/gcc-4.4-20080509/libstdc++-v3/include/backward
-I/cygdr
ive/c/gnu/gcc-4.4-20080509/libstdc++-v3/testsuite/util -Wl,--gc-sections
-liconv

/cygdrive/c/gnu/gcc-4.4-20080509/libstdc++-v3/testsuite/22_locale/locale/cons/u
nicode.cc-include bits/stdc++.h ./libtestc++.a -o ./unicode.exe   
(time


-- 


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

[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2008-05-12 06:47 ---
This also fixes sse3-* failures with -fpic at
http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01014.html


-- 


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