[Bug fortran/34471] Wrong precedence of kinds in typespecs.

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 08:15:05
   date||


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

[Bug c++/32565] [4.3 regression] ICE with specialization of variadic template

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-07 20:14:04 |2007-12-15 08:29:12
   date||


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

[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter

[dgregor at gcc dot gnu dot org]

--- Comment #3 from dgregor at gcc dot gnu dot org  2007-12-15 08:31 ---
This is valid code, so it's more serious than we thought.


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords|error-recovery, ice-on- |ice-on-valid-code
   |invalid-code|
   Last reconfirmed|2007-11-19 05:03:36 |2007-12-15 08:31:29
   date||


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

[Bug fortran/34476] New: Parameters: Bogus out of bounds error in array constructor

[burnus at gcc dot gnu dot org]

The following valid program is rejected with

   integer(1), parameter :: ARR1(len(HEX1)) = [( MSKa1(i), i=1,len(HEX1) )]
  1
Error: index in dimension 1 is out of bounds at (1)

module abuse_mod
   implicit none
   integer i
   character(8), parameter :: HEX1 = '40490FDB'
   integer(1), parameter :: MSKa1(len(HEX1)) =  [(1,i=1,len(HEX1))]
   integer(1), parameter :: ARR1(len(HEX1)) = [( MSKa1(i), i=1,len(HEX1) )]
end module abuse_mod

For a longer example (which uses supported vendor extensions), see:
http://groups.google.com/group/comp.lang.fortran/msg/2499294cb9a33299


-- 
   Summary: Parameters: Bogus out of bounds error in array
constructor
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/34476] Parameters: Bogus out of bounds error in array constructor

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 10:08:30
   date||


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

[Bug fortran/34431] type(t) function with imported/use-associated "t" fails

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-12-15 10:08 ---
Created an attachment (id=14765)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14765&action=view)
Draft patch, does not work yet, looks clumsy

Attachment: Very rough draft patch, which does not work, but tries to fix this
PR and PR 34471. The problem is either when to do the symbol checking or to do
multiple symbol checking (which currently fails with ambiguous symbols (type)
or with not re-evaluating (kind)).

The following program is also valid:

  type(t) function func()
  type t
integer :: i = 0
  end type t
  end function func

Test also the same with the combination of
host-/use-associated/function-defined types to make sure the right one is
picked.

See:

"5.1.1.1 TYPE
[...]
Where a data entity is declared explicitly using the TYPE type specifier, the
specified derived type shall have been defined previously in the scoping unit
or be accessible there by use or host association. If the data entity is a
function result, the derived type may be specified in the FUNCTION statement
provided the derived type is defined within the body of the function or is
accessible there by use or host association. If the derived type is specified
in the FUNCTION statement and is defined within the body of the function, it is
as if the function result variable was declared with that derived type
immediately following the derived-type-def of the specified derived type."

This contrasts with kind/length parameters, which may not be defined in the
function itself:

"5.1.2.10 PARAMETER attribute
[...]
A named constant shall not be referenced unless it has been defined previously
in the same statement, defined in a prior statement, or made accessible by use
or host association."


-- 


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

[Bug middle-end/34477] New: [4.3 regression] Standard autoconf mktime test is too slow when compiled with -O2

[ismail at pardus dot org dot tr]

See the timing, testcase is the usual mktime test from autoconf :

[~]> gcc -O2 -o mktime mktime.c
[~]> time ./mktime
zsh: alarm  ./mktime
./mktime  32,22s user 27,70s system 99% cpu 1:00,00 total

[~]> gcc -o mktime mktime.c
[~]> time ./mktime
./mktime  0,04s user 0,03s system 100% cpu 0,067 total

[~]> gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
--datadir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0
--mandir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/man
--infodir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj
--disable-libssp --disable-multilib --disable-nls --disable-werror
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--enable-languages=c,c++,fortran,objc,obj-c++,treelang
--enable-libstdcxx-allocator=new --enable-shared --enable-ssp
--enable-threads=posix --enable-version-specific-runtime-libs
--without-included-gettext --without-system-libunwind --with-system-zlib
--with-pkgversion='Pardus Linux' --with-bugurl=http://bugs.pardus.org.tr
Thread model: posix
gcc version 4.3.0 20071215 [trunk revision 130952] (Pardus Linux)


-- 
   Summary: [4.3 regression] Standard autoconf mktime test is too
slow when compiled with -O2
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ismail at pardus dot org dot tr


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

[Bug middle-end/34477] [4.3 regression] Standard autoconf mktime test is too slow when compiled with -O2

[ismail at pardus dot org dot tr]

--- Comment #1 from ismail at pardus dot org dot tr  2007-12-15 10:27 
---
Created an attachment (id=14766)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14766&action=view)
testcase


-- 


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

[Bug middle-end/34477] [4.3 regression] Standard autoconf mktime test is too slow when compiled with -O2

[ismail at pardus dot org dot tr]

--- Comment #2 from ismail at pardus dot org dot tr  2007-12-15 10:30 
---
Timings with gcc 3.4.6 :

[~]> gcc -o mktime mktime.c
[~]> time ./mktime

real0m0.052s
user0m0.021s

[~]> gcc -O2 -o mktime mktime.c
[~]> time ./mktime

real0m0.032s
user0m0.021s
sys 0m0.011s

So this is a regression.


-- 


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[mmokrejs at ribosome dot natur dot cuni dot cz]

--- Comment #4 from mmokrejs at ribosome dot natur dot cuni dot cz  
2007-12-15 10:59 ---
None of these works:

find . -type l -or -type d -print
find . -type l OR -type d -print
find . -type l or -type d -print


-- 


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[mmokrejs at ribosome dot natur dot cuni dot cz]

--- Comment #5 from mmokrejs at ribosome dot natur dot cuni dot cz  
2007-12-15 11:00 ---
Created an attachment (id=14767)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14767&action=view)
fixinc.in.patch

There was one more left ...


-- 


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

[Bug middle-end/34477] [4.3 regression] Standard autoconf mktime test is too slow when compiled with -O2

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-12-15 11:43 ---
Hmm, I think time_t is signed so this is just a case of signed overflow being
undefined.


-- 


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

[Bug middle-end/34477] [4.3 regression] Standard autoconf mktime test is too slow when compiled with -O2

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-12-15 11:46 ---
Yes this is invalid, time_t is signed so the following loop is empty:

  for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2)
continue;


-- 

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

[Bug driver/34478] New: Memory leak in genconditions

[wuhui1973 at 21cn dot com]

in genconditions source, can see following code:

183int main(int argc, char **argv)
184{
 ...
194  if (init_md_reader (argv[1]) != SUCCESS_EXIT_CODE)
195 return (FATAL_EXIT_CODE);
196 
197   condition_table = htab_create (1000, hash_c_test, cmp_c_test, NULL);
  ...
   }

While in function init_md_reader, condition_table has been allocated as
following:

907  int
908  init_md_reader (const char *filename)
909  {
...
928 condition_table = htab_create (n_insn_conditions,
929  hash_c_test, cmp_c_test, NULL);
...
}

condition_table is allocated by xalloc, which seems not control by GC, so it
seems some memory leak here.
Suggest to add
if (condition_table)
   delete condition_table;

just before line 197 above.


-- 
   Summary: Memory leak in genconditions
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wuhui1973 at 21cn dot com


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

[Bug middle-end/34477] [4.3 regression] Standard autoconf mktime test is too slow when compiled with -O2

[ismail at pardus dot org dot tr]

--- Comment #5 from ismail at pardus dot org dot tr  2007-12-15 11:52 
---
I don't believe this is invalid changing time_t_max and time_t_min to unsigned
long doesn't fix the problem.


-- 


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

[Bug middle-end/34477] [4.3 regression] Standard autoconf mktime test is too slow when compiled with -O2

[ismail at pardus dot org dot tr]

--- Comment #6 from ismail at pardus dot org dot tr  2007-12-15 11:52 
---
Created an attachment (id=14768)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14768&action=view)
Testcase with unsigned long values


-- 

ismail at pardus dot org dot tr changed:

   What|Removed |Added

  Attachment #14766|0   |1
is obsolete||


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

[Bug driver/34478] Memory leak in genconditions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-12-15 12:04 ---
Fixed by:
r110119 | zack | 2006-01-23 07:15:05 -0800 (Mon, 23 Jan 2006) | 37 lines

 [EMAIL PROTECTED]:  zack | 2006-01-22 14:44:34 -0800
* genconditions.c (condition_table, add_condition): Delete.
(write_conditions): Don't emit n_insn_conditions nor
insn_elision_unavailable.  Issue the gcc version #ifdef here,
inside the table, with no #else clause ...
(write_header): ...not here.
(write_writer): New function.
(main): Don't initialize condition_table.  Use add_c_test.
Call write_writer.
* gensupport.c (init_md_reader_args_cb): Handle multiple input
files on the command line.
(maybe_eval_c_test): Don't check insn_elision_unavailable.
Return -1 if there is no entry in the table, don't abort.
(add_c_test, traverse_c_tests): New functions.
* gensupport.h (insn_elision_unavailable, insn_conditions)
(n_insn_conditions): Delete declarations.
(add_c_test, traverse_c_tests): Declare.
* read-rtl.c: Include gensupport.h.
(read_conditions): New function.
(read_rtx): If read_rtx_1 returns 0, treat as EOF.
(read_rtx_1): If we get EOF when we were looking for an initial
open paren, return 0.  Call read_conditions when appropriate.
* Makefile.in: Kill BUILD_EARLY_SUPPORT and all references to
dummy-conditions.o.  Eliminate references to insn-conditions.o,
or change them to build/gencondmd.o, as appropriate.  Remove
insn-constants.h from $(simple_generated_h) and insn-conditions.c
from $(simple_generated_c).  For all files remaining in those
two lists, add insn-conditions.md to the generator command line.
Give insn-constants.h/s-constants their own rules.  Add rules
for build/gencondmd.c, s-conditions, insn-conditions.md, s-condmd.
(build/read-rtl.o): Depend on gensupport.h.
(genprognormal): Include preds.
(genprogearly): Rename genprognoprint; only difference is now that
they don't link with $(BUILD_PRINT).
* dummy-conditions.c: Delete.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-12-15 12:13 ---
The code is still invalid C++98 so the regression is still just an error
recovery issue :).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||error-recovery, ice-on-
   ||invalid-code


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[aldot at gcc dot gnu dot org]

--- Comment #6 from aldot at gcc dot gnu dot org  2007-12-15 12:49 ---
(In reply to comment #4)
> None of these works:
> 
> find . -type l -or -type d -print
> find . -type l OR -type d -print
> find . -type l or -type d -print
> 
In current busybox (IIRC >= 1.6) these are available if you ENABLE_DESKTOP, but
that pulls in alot of big cruft so is nothing you want, generally.

Confirmed.


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 12:49:28
   date||


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2007-12-15 13:25 ---
Three questions:
1. According to the 'find(1)' man pages, -o is specified in POSIX.  Should GCC
support non-POSIX find commands?  IMHO, no.
2. Why would you build in a busybox environment in the first place?  This seems
like a highly unusual thing to do.  IMHO gcc should not have to be able to
build in such a limited environment as busybox.
3. Assuming you have good reasons for (2), is there anything stopping you from
just installing and using a POSIX conforming 'find(1)' command?

Either way, http://gcc.gnu.org/install/prerequisites.html should be updated to
reflect what we require to build gcc.


-- 


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

[Bug middle-end/34475] TLS and PIE don't mix on x86-64

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-12-15 13:40 ---
--- gcc/varasm.c.jj101  2007-12-06 11:53:42.0 +0100
+++ gcc/varasm.c2007-12-15 14:33:36.0 +0100
@@ -5519,7 +5519,7 @@ decl_default_tls_model (const_tree decl)
   is_local = targetm.binds_local_p (decl);
   if (!flag_shlib)
 {
-  if (is_local)
+  if (is_local && !flag_pic)
kind = TLS_MODEL_LOCAL_EXEC;
   else
kind = TLS_MODEL_INITIAL_EXEC;
will fix this (for all targets).  Will work on a testcase that covers at least
a bunch of common targets.


-- 

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|UNCONFIRMED |ASSIGNED
  Component|target  |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 13:40:08
   date||


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[mmokrejs at ribosome dot natur dot cuni dot cz]

--- Comment #8 from mmokrejs at ribosome dot natur dot cuni dot cz  
2007-12-15 14:01 ---
The hardware is a Western Digital MyBookWorldII small NAS system, and it is
bundled with the linux and just these tools. Everybody is glad that at least a
working old gcc is available. We just can't upgrade everything, it has only
32MB RAM and most importantly, has to run samba and sshd. Spot briefly over the
following pages.

http://martin.hinner.info/mybook/
http://ribosome.natur.cuni.cz/~mmokrejs/MyBookWorldII/
http://www.welped.com/2007/08/29/hacking-the-mybook-world-edition-into-a-php-powered-web-server/
http://chayden.net/mybook/
http://www.ismprofessional.net/pascucci/documenti/mybook/mybook-hacking-en.html
http://www.ismprofessional.net/pascucci/index.php/mybook-repository/
http://nihilisme.ca:8080/arm/
http://www.nabble.com/Re-3A-Arm-926ejs-questions-to10674608.html
http://www.dark-legion.org/en/ARM%20Holdings
http://www.arm.com/linux/ARM-Linux-Notes.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0157g/DDI0157.pdf


I don't see an issue why the bootstrap step would have to unnecessarily require
POSIX compliant find. Why? To have one exec() of find instead of two exec()
calls?

Regarding installing more apps. Well, the system has no iconv, no gettext, no
auto* tools, has only uClibc, has no libtool and e.g. to compile GNU file-4.21
I had to report two bugs to get it compiled, one of them is still not fixed.
So, no, I cannot upgrade apps and please do not require that unnecessarily. Who
cares about a bit more ugly fixinc.sh script which is used only during build
process? It does not affect resulting gcc compatibility/performance/features,
so why?
Yes, I really need to have as small as possible apps with minimum features and
I cannot even overwrite some shared libs and upgrade them (remember the
hardware has no KBD/VGA/MOUSE, serial console is a wild hack at 3.3V and so the
only sane way is to disassemble the box and mount drives elsewhere).


-- 


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

[Bug driver/34479] New: "gcc -x c - -save-temps" does not work

[bonzini at gnu dot org]

It should produce files -.i and -.s, or better gccdump.i and gccdump.s. 
However, it fails with this error:

cc1: error: unrecognized command line option "-.i"


-- 
   Summary: "gcc -x c - -save-temps" does not work
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org


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

[Bug c++/34480] New: Argument packs treat __null oddly

[gcc at magfr dot user dot lysator dot liu dot se]

The following program fails to compile in c++0x mode:

template  void* f(A... a) { return new (char*)(a...); }

int main() {
f(__null);
}

Now, this doesn't sound that bad until one notice that this is functionally
equivalent with

#include 

int main() {
std::vector v;
v.push_back(NULL);
}

and that used to and still do work perfectly well under c++98.

Note that if __null is replaced with 0 then it works so this suggests that the
__null case have been forgotten somewhere.


-- 
   Summary: Argument packs treat __null oddly
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at magfr dot user dot lysator dot liu dot se
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug bootstrap/34481] New: stage3-intl: error: C compiler cannot create executables

[andry at inbox dot ru]

Tring to make gcc with reinstalled cygwin, which already have patch from:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039

Still getting the same error, this happend then i catching another error from
here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34414

host-i686-pc-cygwin\intl\config.log:
///
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ /cygdrive/e/work/gcc_4_2_2_release/intl/configure
--cache-file=./config.cache --build=i686-pc-cygwin --host=i686-pc-cygwin
--target=i686-pc-cygwin --enable-languages=c,c++,objc
--program-transform-name=s,y,y, --srcdir=../.././intl
--with-build-libsubdir=host-i686-pc-cygwin

## - ##
## Platform. ##
## - ##

hostname = andry_host
uname -m = i686
uname -r = 1.5.25(0.156/4/2)
uname -s = CYGWIN_NT-5.1
uname -v = 2007-12-09 09:47

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/X11R6/bin
PATH: /cygdrive/c/Program Files/PC Connectivity Solution/
PATH: /cygdrive/c/Programs/Dev/www.ruby-lang.org/Ruby v1.8.6/bin
PATH: /cygdrive/c/WINXP/system32
PATH: /cygdrive/c/WINXP
PATH: /cygdrive/c/WINXP/System32/Wbem
PATH: /cygdrive/c/Programs/Tools/Console/Console v2.00b130
PATH: /cygdrive/c/Programs/Dev/CollabNet/Subversion v1.4.3/bin
PATH: /cygdrive/c/Programs/Dev/Perforce/Perforce v2006.2
PATH: /cygdrive/c/Programs/Dev/CVSHome/cvsnt
PATH: /cygdrive/c/Program Files/Microsoft Visual Studio 2008
SDK/VisualStudioIntegration/Tools/Sandcastle/ProductionTools/


## --- ##
## Core tests. ##
## --- ##

configure:1228: creating cache ./config.cache
configure:1323: checking whether make sets $(MAKE)
configure:1343: result: yes
configure:1390: checking for a BSD-compatible install
configure:1445: result: /usr/bin/install -c
configure:1470: checking whether NLS is requested
configure:1479: result: yes
configure:1517: checking for msgfmt
configure:1551: result: no
configure:1557: checking for gmsgfmt
configure:1588: result: :
configure:1627: checking for xgettext
configure:1661: result: no
configure:1698: checking for msgmerge
configure:1731: result: no
configure:1771: checking for i686-pc-cygwin-gcc
configure:1797: result: 
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/
configure:2079: checking for C compiler version
configure:2082: 
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ --version &5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2083:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2085: $? = 127
configure:2087: 
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -v &5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2088:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2090: $? = 127
configure:2092: 
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -V &5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2093:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2095: $? = 127
configure:2118: checking for C compiler default output file name
configure:2121: 
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc
-B/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -g -O2   conftest.c  >&5
/cygdrive/e/work/gcc_4_2_2_release/intl/configure: line 2122:
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc-cygwin/prev-gcc/xgcc: No such
file or directory
configure:2124: $? = 127
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:2163: error: C compiler cannot create executables
See `config.log' for more details.

##  ##
## Cache variables. ##
##  ##

ac_cv_env_CC_set=set
ac_cv_env_CC_value='
/cygdrive/e/work/gcc_4_2_2_release/host-i686-pc

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[aldot at gcc dot gnu dot org]

--- Comment #9 from aldot at gcc dot gnu dot org  2007-12-15 14:44 ---
Is suggest you get a current busybox-1.8.2 and just turn on the applets you
need, including DESKTOP support for find (which is a required feature according
to SUSv3, as steven mentioned).

With everything turned on this find isn't all that big:
$ ls -ln busybox && size busybox
-rwxr-xr-x 1 1000 1000 14492 2007-12-15 15:39 busybox
   textdata bss dec hex filename
  12525 450  60   1303532eb busybox


-- 


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

[Bug middle-end/34475] TLS and PIE don't mix on x86-64

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2007-12-15 14:59 ---
Actually, thinking about it again, this might be a linker bug instead.
Because while code/data in PIEs is relocatable, the relative addresses of
TLS vars within TLS block should be constant, so ld should be able to insert
that (constant) offset into the instructions without needing a dynamic
relocation.


-- 


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2007-12-15 16:31 
---
Why do you need to bootstrap gcc on a small NAS box?  Use a cross-compiler.


-- 


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

[Bug fortran/34482] New: FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[danglin at gcc dot gnu dot org]

Executing on host:
/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../gf
ortran -B/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../
/home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gfortran.dg/nan_4.f90   -O  -std=gnu
-S  -o nan_4.s(timeout = 300)
FAIL: gfortran.dg/nan_4.f90  -O   (test for errors, line 11)
FAIL: gfortran.dg/nan_4.f90  -O   (test for errors, line 13)
FAIL: gfortran.dg/nan_4.f90  -O   (test for errors, line 14)
PASS: gfortran.dg/nan_4.f90  -O  (test for excess errors)

No error messages are generated.


-- 
   Summary: FAIL: gfortran.dg/nan_4.f90  -O tests for errors
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-*
  GCC host triplet: hppa*-*-*
GCC target triplet: hppa*-*-*


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

[Bug tree-optimization/34413] gfortran.dg/ltrans-7.f90 doesn't work

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2007-12-15 16:51 ---
I'm seeing this on hppa64-hp-hpux11.11.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/34413] gfortran.dg/ltrans-7.f90 doesn't work

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2007-12-15 17:00 ---
Same thing on Darwin at -m64. It comes from
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00277.html, but I don't know why
it has been commited and why it fails with -m64 but not with -m32.

[ibook-dhum] f90/bug% gfc -m64 -O2 -ftree-loop-linear -fdump-tree-ltrans-all
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/ltrans-7.f90
[ibook-dhum] f90/bug% a.out 

 PC =   0.E+00
 UC =   0.E+00
 VC =   0.E+00

[ibook-dhum] f90/bug% grep "transformed loop" ltrans-7.f90.101t.ltrans
[ibook-dhum] f90/bug%


-- 


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

[Bug middle-end/34483] New: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c   -O3
-fipa-struct
-reorg -fdump-ipa-all -fwhole-program -combine -fipa-type-escape
-fno-show-colum
n  -lm   -o ./wo_prof_two_strs.exe(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c: In function
'm
ain':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c:56: internal
co
mpiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c: In function
'm
ain':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c:56: internal
co
mpiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gcc.dg/struct/wo_prof_two_strs.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_two_strs.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/wo_prof_two_strs.c:56: internal
co
mpiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

WARNING: gcc.dg/struct/wo_prof_two_strs.c compilation failed to produce
executab
le
FAIL: gcc.dg/struct/wo_prof_two_strs.c scan-ipa-dump ipa_struct_reorg "Number
of
 structures to transform is 2"

and

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c-O3
-fwhole-prog
ram -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all
-
fno-show-column  -lm   -o
/test/gnu/gcc/objdir/gcc/testsuite/gcc/w_prof_two_strs
.x02(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c: In function
'ma
in':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c:53: internal
com
piler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c: In function
'ma
in':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_two_strs.c:53: internal
com
piler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gcc.dg/struct/w_prof_two_strs.c compilation,  -O3 -fwhole-program
-combine
 -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all (internal
com
piler error)
UNRESOLVED: gcc.dg/struct/w_prof_two_strs.c execution,-O3 -fwhole-program
-c
ombine -fipa-type-escape -fprofile-use -fipa-struct-reorg -fdump-ipa-all

For the first, I see the following backtrace:

(gdb) p var
$2 = (new_var) 0x0
(gdb) bt
#0  find_new_var_of_type (orig_var=0x83fffde810a0,
new_type=0x83fffde7dcc0) at ../../gcc/gcc/ipa-struct-reorg.c:605
#1  0x40d4f140 in gen_cast_stmt (before_cast=0x83fffde916e0,
new_type=0x83fffde7dcc0, orig_cast_stmt=0x83fffde79f30,
res_p=0x83fffdff1460) at ../../gcc/gcc/ipa-struct-reorg.c:652
#2  0x40d56564 in create_new_malloc (malloc_stmt=0x83fffde79f00,
new_type=0x83fffde7dcc0, new_stmts=0x83fffdff1370,
num=0x83fffde8d0c0) at ../../gcc/gcc/ipa-struct-reorg.c:1747
#3  0x40d582a0 in create_new_alloc_sites (m_data=0x800100128410,
context=0x83fffde7b270) at ../../gcc/gcc/ipa-struct-reorg.c:2167
#4  0x40d5bd98 in create_new_alloc_sites_for_func (
node=0x83fffde41400) at ../../gcc/gcc/ipa-struct-reorg.c:2645
#5  0x40d5f4c4 in do_reorg_for_func (node=0x83fffde41400)
at ../../gcc/gcc/ipa-struct-reorg.c:3191
#6  0x40d61b40 in do_reorg_1 ()
at ../../gcc/gcc/ipa-struct-reorg.c:3664
#7  0x40d629e4 in do_reorg () at ../../gcc/gcc/ipa-struct-reorg.c:3915
#8  0x40d62b04 in reorg_structs ()
at ../../gcc/gcc/ipa-struct-reorg.c:3956
#9  0x40d62b58 in reorg_structs_drive ()
at ../../gcc/gcc/ipa-struct-reorg.c:3967
#10 0x407349c8 in execute_one_pass (pass=0x800100048cd8)
at ../../gcc/gcc/passes.c:1118
---Type  to continue, or q  to quit---
#11 0x40734e30 in execute_ipa_pass_list (pass=0x800100048cd8)
at ../../gcc/gcc/passes.c:1187
#12 0x40d2ceb0 in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1339
#13 0x40d2d154 in cgraph_optimize ()
at ../../gcc/gcc/cgraphunit.c:1386
#14 0x401a80e4 in c_write_global_declarations ()
at ../../gcc/gcc/c-decl.c:8077
#15 0x40881768 in compile_file () at ../../gcc/gcc/toplev.c:1055
#16 0x408852dc in do_compile () at ../../gcc/gcc/to

[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA

[aldot at gcc dot gnu dot org]

--- Comment #8 from aldot at gcc dot gnu dot org  2007-12-15 17:23 ---
Two disfunctional testcases:
pr31529_1a.i:
extern getline(){}
pr31529_1b.i:
extern getline(){}

pr31529_2a.i:
extern getline(){}
pr31529_2a.i:
extern __inline getline(){}

Trying to fix this in cfg led to verify_curr_properties barfing on me or, for a
different approach, to ICEs in dominator opts later on, so these approaches
were improper and/or incomplete so far.
Uncertain if catching this in the FE is a sensible thing to do, although i
think  it is not.


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 17:23:07
   date||
   Target Milestone|--- |4.3.0


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

[Bug c/34484] New: pulls in allegedly unneeded floatingpoint exception access funcs

[aldot at gcc dot gnu dot org]

My libc is configured to omit any FP support (UCLIBC_HAS_FLOATS is not set)
but the recent libbid updates seems to unconditionally pull in floatingpoint
accessor functions thus breaking bootstrap -- since feclearexcept et al are
thus unavailable. My notes on this read:

8<
Follows:
Precedes:

do not pull in allegedly unneeded floatingpoint exception access funcs

  HJL's recent update of libbid would pull in Floating-point exception
  handling, although __GCC_FLOAT_NOT_NEEDED is defined.   

  Prevent pulling in feclearexcept, feraiseexcept et al for now.
  FIXME: revisit
8<
A proposed patch is in this thread:
http://gcc.gnu.org/ml/gcc/2007-12/msg00149.html


-- 
   Summary: pulls in allegedly unneeded floatingpoint exception
access funcs
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: hjl at lucon dot org
ReportedBy: aldot at gcc dot gnu dot org


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

[Bug c/34484] [4.3 Regression] pulls in allegedly unneeded floatingpoint exception access funcs

[aldot at gcc dot gnu dot org]

-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.2.2
Summary|pulls in allegedly unneeded |[4.3 Regression] pulls in
   |floatingpoint exception |allegedly unneeded
   |access funcs|floatingpoint exception
   ||access funcs
   Target Milestone|--- |4.3.0


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[aldot at gcc dot gnu dot org]

--- Comment #11 from aldot at gcc dot gnu dot org  2007-12-15 17:55 ---
Using programs that are required by SUSv3 in their complete feature set is
fine.


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-12-15 19:01 ---
Hmm, looking at the test suite results, it works on
  i686-pc-linux-gnu, i386-pc-linux-gnu,
  ia64-suse-linux-gnu, x86_64-unknown-linux-gnu,
  arm-unknown-elf, v850-unknown-elf, i686-pc-cygwin,
  hppa2.0w-hp-hpux11.11
but fails on
  hppa-unknown-linux-gnu, hppa64-hp-hpux11.11,
  powerpc-apple-darwin8.5.0, powerpc64-apple-darwin8.11.0,
  m32r-unknown-elf, powerpc64-suse-linux-gnu

I wonder whether this is an endian problem. I am transferring the hexadecimal
constant   z''   bitwise to a 4-byte-wide real variable.

(Actually, I do not care about its value, only about that (a) the value is
transferred bitwise and (b) that if an error is printed for an
overflow/underflow/NaN/+-Inf.)

On the "working" systems the bit pattern is equivalent to NaN, but I do not
know the value is on the failing systems.

Which version of the MPFR library are you using?

Can you compile and run the following program and post the output? 
(If needed, use the option -fno-range-check, but seemingly the option is not
needed as the message is missing.)

print *, real(z'')
end


-- 


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 
19:24 ---
Subject: Re:  FAIL: gfortran.dg/nan_4.f90  -O tests for errors

> Hmm, looking at the test suite results, it works on
>   hppa2.0w-hp-hpux11.11

My last build on hppa2.0w-hp-hpux11.11 was 130926 (i.e., before the
test was added).

> On the "working" systems the bit pattern is equivalent to NaN, but I do not
> know the value is on the failing systems.

The bit pattern is a Signaling NaN on PA-RISC.

> Which version of the MPFR library are you using?

4.3.0

> Can you compile and run the following program and post the output? 
> (If needed, use the option -fno-range-check, but seemingly the option is not
> needed as the message is missing.)
> 
> print *, real(z'')
> end

On hppa-unknown-linux-gnu, it prints

[EMAIL PROTECTED]:~/gnu/gcc-4.3/objdir/gcc$ ./a.out
   0.000

Dave


-- 


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

[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs

[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|c   |target
 GCC target triplet||i386-pc-linux-gnu
Summary|[4.3 Regression] pulls in   |pulls in allegedly unneeded
   |allegedly unneeded  |floatingpoint exception
   |floatingpoint exception |access funcs
   |access funcs|
   Target Milestone|4.3.0   |---


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

[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-12-15 20:07 ---
Note it is unusual to disable fp support for x86.  So really I think it is a
bug that you can disable it.  Actually I think we should declare this as
invalid.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|i386-pc-linux-gnu   |i386-pc-linux-uclibc


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

[Bug c++/34480] Argument packs treat __null oddly

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-12-15 20:10 ---
Well what type does NULL would have when passed?

And passing 0 also fails.

This might be a defect in the C++0x part of the standard.

Also I think we really do have an ODR violation in libstdc++ if the methods
change with -std=c++0x (which I think the C++0x standard really should
mention).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs

[aldot at gcc dot gnu dot org]

--- Comment #2 from aldot at gcc dot gnu dot org  2007-12-15 20:15 ---
IIRC i initially experienced this not on i386 but with mips or arm.


-- 


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

[Bug debug/7081] DWARF enhancements for C++

[aoliva at gcc dot gnu dot org]

--- Comment #11 from aoliva at gcc dot gnu dot org  2007-12-15 20:19 ---
Subject: Bug 7081

Author: aoliva
Date: Sat Dec 15 20:19:23 2007
New Revision: 130960

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130960
Log:
gcc/ChangeLog:
PR debug/7081
* dwarf2out.c (dwarf_tag_name): Synchronize with dwarf2.h.
(is_type_die): Cover interface types.
(class_or_namespace_scope_p): Cover interface and class types.
(record_type_tag): New.
(gen_inlined_structure_type_die): Use it.
(gen_struct_or_union_type_die): Likewise.
(prune_unused_types_walk): Cover interface types.
* langhooks.h (classify_record): New enum.
(classify_record): New member in struct langhooks_for_types.
* langhooks-def.h (LANG_HOOKS_CLASSIFY_RECORD): New.
(LANGHOOKS_FOR_TYPES_INITIALIZER): Adjust.
gcc/cp/ChangeLog:
PR debug/7081
* cp-lang.c (cp_classify_record): New.
(LANG_HOOKS_CLASSIFY_RECORD): Override.
gcc/java/ChangeLog:
PR debug/7081
* lang.c (java_classify_record): New.
(LANG_HOOKS_CLASSIFY_RECORD): Override.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-lang.c
trunk/gcc/dwarf2out.c
trunk/gcc/java/ChangeLog
trunk/gcc/java/lang.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h


-- 


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

[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-12-15 20:22 ---
Even then you have to have some kind of fp support for GCC to work correctly. 
Even if it is soft fp.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|i386-pc-linux-uclibc|*-pc-linux-uclibc


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

[Bug debug/7081] DWARF enhancements for C++

[aoliva at gcc dot gnu dot org]

--- Comment #12 from aoliva at gcc dot gnu dot org  2007-12-15 20:22 ---
1) is now fixed.  I wish I'd had time to get to 2), but my time slot for this
is over for the time being, so I'll leave this up for grabs.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|aoliva at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug tree-optimization/34123] [4.3 Regression] verify_ssa failed with -ftree-loop-linear

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2007-12-15 20:37 ---
Subject: Re:  [4.3 Regression] verify_ssa failed with -ftree-loop-linear

I have a fix for this one, cleaning up the complex logic in
can_convert_to_perfect_nest.

Sebastian


-- 


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

[Bug c/34308] gcc internal error (seg fault) (program cc1) with ill formed foo.c

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-12-15 20:46 ---
There are too many pointers here for a recursive decent parser to handle.  This
is common and really just hard to do correctly.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/31804] gcc segfaults on very long pointer chains

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-12-15 20:46 ---
*** Bug 34308 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dominique dot pelle at free
   ||dot fr


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

[Bug target/34352] Multi-line descriptions are not picked up for translation

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-12-15 20:48 ---
This is a bug in config/bfin/bfin.opt .  We should not have mutliple lines
descriptions.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|other   |target
 Ever Confirmed|0   |1
 GCC target triplet||bfin-*-*
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 20:48:06
   date||


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

[Bug tree-optimization/34445] [4.3 Regression] internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98

[dorit at gcc dot gnu dot org]

-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dorit at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-12 20:00:40 |2007-12-15 20:50:23
   date||


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-12-15 20:52 ---
(In reply to comment #2)
> > Which version of the MPFR library are you using?
> 4.3.0

That's the GCC version, the MPFR version should be something like 2.2.x or
2.3.0.

> > print *, real(z'')
>
> On hppa-unknown-linux-gnu, it prints 
> [EMAIL PROTECTED]:~/gnu/gcc-4.3/objdir/gcc$ ./a.out
>0.000

Hmmm. That's strange. Can you try the following program (if needed, use
-fno-range-check):

print *, transfer(4294967295_8, 0.0)
print '(z12)', transfer(real(z''), 1)
print *, transfer(2143289344_8, 0.0)
print '(z12)', transfer(real(z'7FC0'), 1)
print *, real(z'7FC0')
END

In principle, I would expect: NaN, , NaN, 7FC0, NaN
At least that's what I get on x86-64 with several compilers.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 20:52:39
   date||


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

[Bug other/34433] Internal error while porting to PISA

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-12-15 21:02 ---
This is not the correct location for asking for help on porting.  Ask the gcc@
list.  But you might as well run cc1 under the debugger and see why there is an
assert happening.


-- 

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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-12-15 21:03 ---
As jerry pointed out on IRC, the default integer size could be 8, which
explains the result. Try instead:

  print *, real(z'', 4)
  print *, transfer(4294967295_8, 0.0_4)
  print '(z12)', transfer(real(z'',4), 1_4)
  print *, transfer(2143289344_8, 0.0_4)
  print '(z12)', transfer(real(z'7FC0',4), 1_4)
  print *, real(z'7FC0',4)
END


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2007-12-15 
21:35 ---
I find the following works here...

cd /sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/gcc
./xgcc -m64 -B./ -B/sw/lib/gcc4.3/i686-apple-darwin9/bin/ -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/include -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/sys-include
-L/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/gcc/../ld -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -msse -minline-all-stringops -c
../../gcc-4.3-20071214/gcc/config/i386/crtfastmath.c -o x86_64/crtfastmath.o

This eliminates the failures in make check at -m64. I wonder if we really
shouldn't be using lines like...

EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o crtbeginS.o crtendS.o \
 crtbeginT.o crtprec32.o crtprec64.o crtprec80.o \
 crtfastmath.o

from gcc/config/i386/t-linux64 for t-darwin? On x86-64 linux, a build of gcc
trunk properly creates the correct architecture of crtfastmath.o in the 32
subdirectory. Or alternatively maybe it would be sufficient to just add
crtfastmath.o to the line...

# How to build crt3.o
EXTRA_MULTILIB_PARTS=crt3.o

in gcc/config/t-darwin since that seems to properly build the correct
architecture of crt3.o for the x86_64 subdirectory on i686-apple-darwin9.


-- 


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 
21:51 ---
Subject: Re:  FAIL: gfortran.dg/nan_4.f90  -O tests for errors

> --- Comment #4 from burnus at gcc dot gnu dot org  2007-12-15 21:03 
> ---
> As jerry pointed out on IRC, the default integer size could be 8, which
> explains the result. Try instead:
> 
>   print *, real(z'', 4)
>   print *, transfer(4294967295_8, 0.0_4)
>   print '(z12)', transfer(real(z'',4), 1_4)
>   print *, transfer(2143289344_8, 0.0_4)
>   print '(z12)', transfer(real(z'7FC0',4), 1_4)
>   print *, real(z'7FC0',4)
> END

With 4.2.3, the results for the above are:
  4.2949673E+09 0.00 4F80 0.00 4EFF8000 2.1432893E+09

The first version gave:
  0.00 4F80 0.00 4EFF8000 2.1432893E+09

Dave


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2007-12-15 
21:58 ---
Hmmm... I see...

file *.o
crt3.o:Mach-O 64-bit object x86_64
crtfastmath.o: Mach-O object i386
crtprec32.o:   Mach-O object i386
crtprec64.o:   Mach-O object i386
crtprec80.o:   Mach-O object i386

in /sw/lib/gcc4.3/lib/gcc/i686-apple-darwin9/4.3.0/x86_64. This makes me wonder
if we shouldn't really have...

--- gcc-4.3-20071214/gcc/config/t-darwin.org2007-12-15 16:37:44.0
-0500
+++ gcc-4.3-20071214/gcc/config/t-darwin2007-12-15 16:38:24.0
-0500
@@ -18,7 +18,7 @@
  $(srcdir)/config/darwin-driver.c

 # How to build crt3.o
-EXTRA_MULTILIB_PARTS=crt3.o
+EXTRA_MULTILIB_PARTS=crt3.o crtfastmath.o crtprec32.o crtprec64.o crtprec80.o
 # Pass -fno-tree-dominator-opts to work around bug 26840.
 $(T)crt3$(objext): $(srcdir)/config/darwin-crt3.c $(GCC_PASSES) \
$(TCONFIG_H) stmp-int-hdrs tsystem.h

I'll try a test build of that next.


-- 


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

[Bug target/34484] pulls in allegedly unneeded floatingpoint exception access funcs

[hjl at lucon dot org]

--- Comment #4 from hjl at lucon dot org  2007-12-15 22:05 ---
Where is __GCC_FLOAT_NOT_NEEDED documented? Is this a supported gcc macro?


-- 


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

[Bug middle-end/26061] error and warning count

[ismail at pardus dot org dot tr]

--- Comment #14 from ismail at pardus dot org dot tr  2007-12-15 22:05 
---
Created an attachment (id=14769)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14769&action=view)
Better patch


-- 


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

[Bug middle-end/26061] error and warning count

[ismail at pardus dot org dot tr]

--- Comment #15 from ismail at pardus dot org dot tr  2007-12-15 22:06 
---
Attached is a better patch which adds -f{no}-show-error-count and uses it in
regression tests so regtests works now. IDE's also can use this option.

Is it possible to get this in for gcc 4.3 or gcc 4.4?


-- 


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

[Bug c++/34485] New: [4.1/4.2/4.3 regression] ICE with undefined type in template parameter

[reichelt at gcc dot gnu dot org]

The following invalid testcase triggers an ICE since GCC 4.1.0:

==
struct A
{
  template struct X;
};
==

bug.cc:3: error: 'T' has not been declared
bug.cc:3: error: declaration of 'template struct A::X'
bug.cc:3: error:  shadows template parm 'int X'
bug.cc:3: internal compiler error: in pop_binding, at cp/name-lookup.c:405
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3 regression] ICE with undefined type in
template parameter
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/34485] [4.1/4.2/4.3 regression] ICE with undefined type in template parameter

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c++/34486] New: [4.1/4.2/4.3 regression] ICE invalid using declaration

[reichelt at gcc dot gnu dot org]

The following invalid testcase triggers an ICE since GCC 4.1.0:

==
template struct A
{
  typedef A* X;
};

template struct B
{
  using A::X::Y;
};

B b;
==

bug.cc: In instantiation of 'B':
bug.cc:11:   instantiated from here
bug.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3 regression] ICE invalid using declaration
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/34486] [4.1/4.2/4.3 regression] ICE invalid using declaration

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 
22:29 ---
Subject: Re:  FAIL: gfortran.dg/nan_4.f90  -O tests for errors

> That's the GCC version, the MPFR version should be something like 2.2.x or
> 2.3.0.

2.3.0.

Dave


-- 


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 
22:29 ---
Subject: Re:  FAIL: gfortran.dg/nan_4.f90  -O tests for errors

> With 4.2.3, the results for the above are:
>   4.2949673E+09 0.00 4F80 0.00 4EFF8000 2.1432893E+09
> 
> The first version gave:
>   0.00 4F80 0.00 4EFF8000 2.1432893E+09

With yesterdays trunk, the results for the second test are:
   0.000 0.000 0 0.000 0 0.000

The first version gives:
   0.000 0 0.000 0 0.000

Dave


-- 


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2007-12-15 22:34 
---
On ppc64 I get on example of #4:

   0.000
   0.000
   0
   0.000
   0
   0.000


-- 


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

[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2007-12-15 22:37 
---
The dump for nan_4.f90 has:

test ()
{
  static real(kind=4) r = 0.0;
  static integer(kind=4) options.0[7] = {68, 127, 0, 0, 0, 1, 0};

  _gfortran_set_options (7, (void *) &options.0);
  r = 0.0;
... snip ...


-- 


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

[Bug c++/34487] New: [4.1/4.2/4.3 regression] ICE using class instead of typename

[reichelt at gcc dot gnu dot org]

The following invalid testcase triggers an ICE since GCC 4.1.2:


template struct A
{
  template struct B { typedef A X; };
};

template struct C
{
  class A::template B<0>::X x;
};

C c;


bug.cc: In instantiation of 'A::B<0>':
bug.cc:8:   instantiated from 'C'
bug.cc:11:   instantiated from here
bug.cc:3: internal compiler error: in instantiate_class_template, at
cp/pt.c:6765
Please submit a full bug report, [etc.]

The code was accepted before.

If I make B a non-template the situation is reversed, i.e. the code is
wrongly accepted since GCC 4.1.2 while it ICE'd before:


template struct A
{
  struct B { typedef A X; };
};

template struct C
{
  class A::B::X x;
};

C c;


The problem is probably related to PR32029 (which ICEs since GCC 3.4.0,
though).


-- 
   Summary: [4.1/4.2/4.3 regression] ICE using class instead of
typename
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, accepts-invalid, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/34487] [4.1/4.2/4.3 regression] ICE using class instead of typename

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c++/34488] New: [4.3 regression] ICE on invalid friend declaration

[reichelt at gcc dot gnu dot org]

The following invalid testcase triggers an ICE on mainline:


struct A
{
  friend A A() {}
};


bug.cc:3: error: return type specification for constructor invalid
bug.cc: In static member function 'static A::A()':
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3 regression] ICE on invalid friend declaration
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/34488] [4.3 regression] ICE on invalid friend declaration

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug ada/34489] New: Compilation of applicationservices-qd-quickdraw.ads fails

[rogermc at iinet dot net dot au]

+===GNAT BUG DETECTED==+
| 4.3.0 20071103 (experimental) [trunk revision 129867] (i686-apple-darwin8)
GCC error:|
| tree check: expected identifier_node, have type_decl in  |
| dbxout_symbol, at dbxout.c:2668  |
| Error detected around
/usr/local/Bindings/Frameworks/applicationservices-qd-quickdraw.ads:7018|
| 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).   |
+==+


-- 
   Summary: Compilation of applicationservices-qd-quickdraw.ads
fails
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogermc at iinet dot net dot au


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

[Bug middle-end/34490] New: [4.3 Regression] r128833 causes miscompilation of glibc clock_gettime.c

[jakub at gcc dot gnu dot org]

Following testcase distilled from x86_64 glibc clock_gettime.c is miscompiled
on the trunk since r128833.  CSE1 removes all the c's return value checks
and assumes it wasn't small negative value:

extern void abort (void);
int (*fnp) (int, void *);
unsigned long bar (int, void *);

int
foo (int x, void *y)
{
  long int b;
  int (*c) (int, void *) = fnp;
  if (c)
{
  b = c (x, y);
  if ((unsigned long) b < -4095L)
return b;
  if (-b != 38)
goto lab;
}
  unsigned long d = bar (x, y);
  b = (long) d;
  if ((unsigned long) b >= -4095L)
{
lab:
  b = -1L;
}
  return b;
}

int
__attribute__((noinline))
baz (int x, void *y)
{
  return -x;
}

unsigned long
__attribute__((noinline))
bar (int x, void *y)
{
  if (x != 38)
abort ();
  return 0;
}

int
main (void)
{
  fnp = baz;
  if (foo (39, 0) != -1)
abort ();
  if (foo (38, 0) != 0)
abort ();
  return 0;
}


-- 
   Summary: [4.3 Regression] r128833 causes miscompilation of glibc
clock_gettime.c
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux


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

[Bug middle-end/34490] [4.3 Regression] r128833 causes miscompilation of glibc clock_gettime.c

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-15 23:04:53
   date||
   Target Milestone|--- |4.3.0


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

[Bug bootstrap/34003] [4.2/4.3 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

[jakub at gcc dot gnu dot org]

--- Comment #34 from jakub at gcc dot gnu dot org  2007-12-15 23:09 ---
Subject: Bug 34003

Author: jakub
Date: Sat Dec 15 23:08:47 2007
New Revision: 130979

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130979
Log:
PR bootstrap/34003
* c-decl.c (merge_decls): Copy RTL from olddecl to newdecl.
* config/pa/pa.c (pa_encode_section_info): If !first, preserve
SYMBOL_FLAG_REFERENCED flag.

* gcc.dg/pr34003-1.c: New test.
* gcc.dg/pr34003-2.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr34003-1.c
trunk/gcc/testsuite/gcc.dg/pr34003-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/config/pa/pa.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/34491] New: [4.1/4.2/4.3 regression] ICE invalid template specialization

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.3:


template struct A;

template<0> struct A
{
  static const int i = 0;
};

int n = A::i;


bug.cc:3: error: expected identifier before numeric constant
bug.cc:3: error: expected '>' before numeric constant
bug.cc:3: error: template parameters not used in partial specialization:
bug.cc:3: error: ''
bug.cc: In instantiation of 'const int A::i':
bug.cc:8:   instantiated from here
bug.cc:8: internal compiler error: in instantiate_decl, at cp/pt.c:14598
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3 regression] ICE invalid template
specialization
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/34491] [4.1/4.2/4.3 regression] ICE invalid template specialization

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug bootstrap/34003] [4.2 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

[jakub at gcc dot gnu dot org]

--- Comment #35 from jakub at gcc dot gnu dot org  2007-12-15 23:10 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3 Regression] gcc|[4.2 Regression] gcc 4.3.0
   |4.3.0 unable to bootstrap   |unable to bootstrap itself;
   |itself; Unsatisfied symbols:|Unsatisfied symbols:
   |ggc_free|ggc_free


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2007-12-15 
23:14 ---
This should probably be added as...

-- gcc-4.3-20071214/gcc/config/i386/t-darwin.org   2007-12-15
18:12:06.0 -0500
+++ gcc-4.3-20071214/gcc/config/i386/t-darwin   2007-12-15 18:12:43.0
-0500
@@ -2,6 +2,7 @@
 MULTILIB_DIRNAMES = x86_64
 LIB2_SIDITI_CONV_FUNCS=yes
 LIB2FUNCS_EXTRA = $(srcdir)/config/darwin-64.c
+EXTRA_MULTILIB_PARTS=crtfastmath.o crtprec32.o crtprec64.o crtprec80.o

 softfp_wrap_start := '\#ifdef __x86_64__'
 softfp_wrap_end := '\#endif'

instead. Testing that now.


-- 


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

[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 
23:17 ---
Subject: Re:  [4.1/4.2/4.3 Regression] Endless
loop while building a 64-bit 2.6.20 kernel

> What does the full cse1 dump look like at that point (don't forget to call
> fflush(dump_file) from gdb ;-)  Is this reproducible with a cross-compiler?

gdb has trouble doing fflush(dump_file) on hppa64-hp-hpux11.11 ;-(

The problem seems to have gone away on the trunk.

I've attached pr31944.c.111r.jump and pr31944.c.112r.cse1.  The cse1
file has two dumps in it.  The second was taken at the time of the
hang.  These are using the stage1 compiler for hppa64-hp-hpux11.11,
version 4.2.3, revision 130785.

Dave


--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 
23:17 ---
Created an attachment (id=14770)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14770&action=view)


--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-15 
23:17 ---
Created an attachment (id=14771)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14771&action=view)


-- 


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

[Bug ada/34489] Compilation of applicationservices-qd-quickdraw.ads fails

[rogermc at iinet dot net dot au]

--- Comment #1 from rogermc at iinet dot net dot au  2007-12-15 23:24 
---
Created an attachment (id=14772)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14772&action=view)
concatenated Framework files (compressed)

command generating error (from mac intel, leopard, Xcode version 3.0)

gcc -c -I./ -I/usr/local/Bindings/Frameworks -gnatf -g -I- -o /Xtool
Projects/Ada
Projects/Ada_Carbon_Temp_Conv/build/Ada_Carbon_Temp_Conv.build/Release/Ada_Carbon_Temp_Conv.build/Objects-normal/ppc/applicationservices-qd-quickdraw.o
/usr/local/Bindings/Frameworks/applicationservices-qd-quickdraw.ads


-- 


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

[Bug ada/34489] Compilation of applicationservices-qd-quickdraw.ads fails

[rogermc at iinet dot net dot au]

--- Comment #2 from rogermc at iinet dot net dot au  2007-12-15 23:29 
---
Created an attachment (id=14773)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14773&action=view)
concatenated framework files (compressed)

command causing bug generated by Xcode 3.0, Intel Mac Leopard:

gcc -c -I./ -I/usr/local/Bindings/Frameworks -gnatf -g -I- -o /Xtool
Projects/Ada
Projects/Ada_Carbon_Temp_Conv/build/Ada_Carbon_Temp_Conv.build/Release/Ada_Carbon_Temp_Conv.build/Objects-normal/ppc/applicationservices-qd-quickdraw.o
/usr/local/Bindings/Frameworks/applicationservices-qd-quickdraw.ads


-- 

rogermc at iinet dot net dot au changed:

   What|Removed |Added

  Attachment #14772|0   |1
is obsolete||


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

[Bug ada/34492] New: corefoundation-cfbase.ads failed to compile

[rogermc at iinet dot net dot au]

Mac Intel Leopard Xtools 3.0

Compilation of corefoundation-cfbase.ads failed at line 317.
Confused by Ptr parameter name and return type Ptr!

function CFAllocatorReallocate (

 Allocator : Cfallocatorref; 
  Ptr   : Void_Ptr;   
  Newsize   : CFIndex;
  Hint  : CFOptionFlags   ) 
  return Ptr; 

Fixed by changing 
Ptr   : Void_Ptr;   
to
aPtr   : Void_Ptr;


-- 
   Summary: corefoundation-cfbase.ads failed to compile
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogermc at iinet dot net dot au


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

[Bug ada/34492] corefoundation-cfbase.ads failed to compile

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-12-15 23:45 ---
And where did you get corefoundation-cfbase.ads from?  And why do you think
this is a GCC bug?


-- 


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

[Bug c++/34470] [4.3.0 regression] spurious "is used uninitialized" from auto_ptr

[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
   Target Milestone|--- |4.3.0


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

[Bug ada/34492] corefoundation-cfbase.ads failed to compile

[rogermc at iinet dot net dot au]

--- Comment #2 from rogermc at iinet dot net dot au  2007-12-16 00:24 
---
The bindings were installed from Carbon_Bindings_xcode.pkg which I think I got
via the www.adapower.net site.
I previously submitted bug 34489 in response to a compilation message
requesting me to do so, so that's why I thought it might be a ggc bug.
As a result of that request, I thought I should also submit this one.
Since upgrading my Mac Intel system to Leopard and Xcode version 3.0, I have
also experienced numerous other compilation failures of this nature with C++
programs which also led me to think it might be a gcc bug.

The program that I was building had previously built successfully prior to  the
upgrade to  Leopard and Xcode version 3.0.
 As I am only returning to Ada after a very long absence, I don't know whether
or not the compiler is now correctly reporting an Ada syntax error. If it is,
then this is not a bug which seems strange as the previous version of  Xcode
compiled without complaint.

If there is a better free version of Ada framework bindings that I could
install I would be grateful to be advised where I could obtain it.


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #10 from howarth at nitro dot med dot uc dot edu  2007-12-16 
00:35 ---
The last formulation doesn't fix the problem.


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #11 from howarth at nitro dot med dot uc dot edu  2007-12-16 
01:05 ---
For some reason the last change isn't forcing the MULTILIB_CFLAGS to actually
be used on the build lines for the objects added to EXTRA_MULTILIB_PARTS.

# Recursively invoke make in the GCC directory to build any
# startfiles (for now).  We must do this just once, passing
# it all the GCC_EXTRA_PARTS as simultaneous goal targets,
# so that rules which cannot execute simultaneously are properly
# serialized.  We indirect through T_TARGET in case any multilib
# directories contain an equals sign, to prevent make from
# interpreting any of the goals as variable assignments.
# We must use cd && make rather than make -C, or else the stage
# number will be embedded in debug information.
T=`${PWDCMD-pwd}`/ \
&& cd ../../.././gcc \
&& make
GCC_FOR_TARGET="/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/
-B/sw/lib/gcc4.3/i686-apple-darwin9/bin/
-B/sw/lib/gcc4.3/i686-apple-darwin9/lib/ -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/include -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/sys-include" \
  MULTILIB_CFLAGS="-g -O2 -fomit-frame-pointer -m64" \
  T=$T \
  T_TARGET="${T}crtfastmath.o ${T}crtprec32.o ${T}crtprec64.o
${T}crtprec80.o" \
  T_TARGET
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/
-B/sw/lib/gcc4.3/i686-apple-darwin9/bin/
-B/sw/lib/gcc4.3/i686-apple-darwin9/lib/ -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/include -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/sys-include -O2  -O2 -g -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -msse -minline-all-stringops -c \
../../gcc-4.3-20071214/gcc/config/i386/crtfastmath.c \
-o
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/i686-apple-darwin9/x86_64/libgcc/crtfastmath.o
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/
-B/sw/lib/gcc4.3/i686-apple-darwin9/bin/
-B/sw/lib/gcc4.3/i686-apple-darwin9/lib/ -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/include -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/sys-include -O2  -O2 -g -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -D__PREC=32 -c \
../../gcc-4.3-20071214/gcc/config/i386/crtprec.c \
-o
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/i686-apple-darwin9/x86_64/libgcc/crtprec32.o
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/
-B/sw/lib/gcc4.3/i686-apple-darwin9/bin/
-B/sw/lib/gcc4.3/i686-apple-darwin9/lib/ -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/include -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/sys-include -O2  -O2 -g -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -D__PREC=64 -c \
../../gcc-4.3-20071214/gcc/config/i386/crtprec.c \
-o
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/i686-apple-darwin9/x86_64/libgcc/crtprec64.o
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/
-B/sw/lib/gcc4.3/i686-apple-darwin9/bin/
-B/sw/lib/gcc4.3/i686-apple-darwin9/lib/ -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/include -isystem
/sw/lib/gcc4.3/i686-apple-darwin9/sys-include -O2  -O2 -g -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -D__PREC=80 -c \
../../gcc-4.3-20071214/gcc/config/i386/crtprec.c \
-o
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/i686-apple-darwin9/x86_64/libgcc/crtprec80.o


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #12 from howarth at nitro dot med dot uc dot edu  2007-12-16 
01:13 ---
I can't help but wonder if this issue is due to the fact that darwin is the
only architecture that uses a single value for MULTILIB_OPTIONS. We only
have...

MULTILIB_OPTIONS = m64

whereas all the other architectures seem to have something like...

MULTILIB_OPTIONS = m64/m32

I'll take a stab at changing this to...

MULTILIB_OPTIONS = m32/m64


-- 


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

[Bug target/34493] New: [4.2/4.3 Regression] ICE reload_cse_simplify_operands, at postreload.c:392 on powerpc with -funroll-loops

[tbm at cyrius dot com]

[ Forwarded from http://bugs.debian.org/452811 ]

We're seeing the following ICE with 4.2/4.3 and -funroll-loops:

/home/tbm/14406.c: In function 'fp_mul_comba_small':
/home/tbm/14406.c:2073: error: insn does not satisfy its constraints:
(insn 30288 1486 1488 11 (set (mem/c:DI (plus:SI (reg/f:SI 1 1)
(const_int 32760 [0x7ff8])) [0 t.6656+0 S8 A8])
(reg:DI 27 27)) 282 {*movdi_internal32} (nil)
(nil))
/home/tbm/14406.c:2073: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:392
Please submit a full bug report,

I've been running delta for 10 days (!) now but the file hasn't gotten
smaller than 150KB yet.


-- 
   Summary: [4.2/4.3 Regression] ICE reload_cse_simplify_operands,
at postreload.c:392 on powerpc with -funroll-loops
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: powerpc-linux-gnu


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

[Bug target/34493] [4.2/4.3 Regression] ICE reload_cse_simplify_operands, at postreload.c:392 on powerpc with -funroll-loops

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2007-12-16 01:21 ---
Created an attachment (id=14774)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14774&action=view)
preprocessed source


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #13 from howarth at nitro dot med dot uc dot edu  2007-12-16 
01:38 ---
The last change just creates an endless loop in the build.


-- 


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[steven at gcc dot gnu dot org]

--- Comment #26 from steven at gcc dot gnu dot org  2007-12-16 01:50 ---
For Eric's second test case, pr24400-2.c, I have on cygwin in tree-ssa 1006
basic blocks, 2044 edges and "only" 840 DFS back edges.  After expanding to RTL
we have 1046 basic blocks, 78005 edges, and 38760 DFS back edges.

In terms of Muchnick's text on worklist dataflow solvers (section 8.4, p. 233
in my copy) we have A >> |N|, where A is the number of back edges on any
acyclic path in the flow graph.  The test case has no cyclic paths, so A is
38760 and the expected number of passes in an iterative solver is A + 2 = 38760
if the blocks are presented in reverse post order.

Measurements show that for the LR problem df_worklist_dataflow needs 39902
iterations to converge, and for the LIVE problem it also needs 39902 iterations
without df_hack2.diff, and 11442 with that patch applied.  I counted the number
of iterations in the "while (!bitmap_empty_p (pending))" loop.

My conclusion must be that df_worklist_dataflow really doesn't behave
unreasonably for the test case.

df_iterative_dataflow needs at most 5 iterations, counting the number of times
we loop in the "while (1)" main loop.  That is, 5 times visiting all basic
blocks, so in total 5*1046=5230 basic block visits.  Optimistically assuming
one block visted per iteration in df_worklist_dataflow, 39902 basic block
visits.


What are the reasons for not just *always* using the hybrid search solver?  The
comment before df_worklist_dataflow says that "measurements shows worklist
algorithm beats iterative algorithm by some margin overall".  Which
measurements are this?  And which iterative algorithm, i.e. the classic
iterative algorithm or the hybrid search??


-- 


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[steven at gcc dot gnu dot org]

--- Comment #27 from steven at gcc dot gnu dot org  2007-12-16 01:54 ---
Typos.  Wanted to say:

"The test case has no cyclic paths, so A is
38760 and the optimal number of passes in a worklist solver is A + 2 = 38762
if the blocks are presented in reverse post order."


-- 


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

[Bug ada/34489] Compilation of applicationservices-qd-quickdraw.ads fails

[rogermc at iinet dot net dot au]

--- Comment #3 from rogermc at iinet dot net dot au  2007-12-16 02:08 
---
Error occurs for both MacOSX10.4u.sdk and MacOSX10.5.sdk


-- 


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

[Bug target/34493] [4.2/4.3 Regression] ICE reload_cse_simplify_operands, at postreload.c:392 on powerpc with -funroll-loops

[tbm at cyrius dot com]

--- Comment #2 from tbm at cyrius dot com  2007-12-16 02:45 ---
Apparently it works with 4.3 now, but 4.2 definitely still has the ICE.


-- 


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

[Bug tree-optimization/34413] gfortran.dg/ltrans-7.f90 doesn't work

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-12-16 03:23 
---
I think Sebastian committed this patch with the intent to fix the bug.  Usually
we don't commit test cases until after we have it fixed and use the PR to track
the issue.  So I think we just wait for Sebastian to finish.  If its going to
be a while, we can XFAIL it.

Is this correct Sebastian?


-- 


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

[Bug target/34384] Poor code generated when passing returned struct as a parameter

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-12-16 04:15 ---
Hmm, for some reason x86-darwin has a different ABI than x86-linux and I
thought they had the same ABIs here.

What version of GCC are you using?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement


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

[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2007-12-16 04:53 
---
Aftter 
2007-11-06  Jakub Jelinek  <[EMAIL PROTECTED]>

PR tree-optimization/33993
* tree-vect-transform.c (vect_get_constant_vectors): Use build_vector
rather than build_constructor_from_list if all list values are
constants.
(get_initial_def_for_induction): Use build_vector instead of
build_constructor_from_list.

We get for the original testcase:
.L3:
vadduwm 1,1,0
vadduwm 0,0,13
bdnz .L3

As the vectorizer now VECTOR_CST which are handled correctly.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2007-12-16 
05:43 ---
Created an attachment (id=14775)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14775&action=view)
add missing MULTILIB_CFLAGS


-- 


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