[Bug ada/32164] [4.1/4.2/4.3/4.4 Regression] Ada ICE when renaming predefined "=" and "/="

[sam at gcc dot gnu dot org]

--- Comment #4 from sam at gcc dot gnu dot org  2008-02-24 08:36 ---
Confirmed with trunk, with the error signaled at another place:

+===GNAT BUG DETECTED==+
| 4.4.0 20080223 (experimental) (i686-pc-linux-gnu) GCC error: |
| in gnat_to_gnu_entity, at ada/decl.c:301 |
| Error detected at pak1.ads:2:9   |


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org
   Last reconfirmed|2007-05-31 20:39:36 |2008-02-24 08:36:26
   date||


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

[Bug ada/35105] GNAT bug

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-02-24 08:40 ---
This appears to be fixed in 4.3.0 already.

GNAT 4.3.0 20080202 (experimental) [trunk revision 132072]
Copyright 1992-2007, Free Software Foundation, Inc.

Compiling: xxx/tasks.adb (source file time stamp: 2008-02-24 08:38:43)

 4. with Ada.Calendar;
 |
>>> warning: redundant with clause in body

   214.  Computations (2) := Comp;
 |
>>> cannot convert local pointer to non-local access type

 234 lines: 1 error, 1 warning


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug ada/35066] GNAT BUG DETECTED in get_indirect_ref_operands, at tree-ssa-operands.c:1476A

[sam at gcc dot gnu dot org]

--- Comment #1 from sam at gcc dot gnu dot org  2008-02-24 08:45 ---
Fabio,

since you already have this version of PolyORB around, could you please try a
pre-release of GCC 4.3.0 and see if this bug is still present?

  Sam


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org
 Status|UNCONFIRMED |WAITING


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

[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'

[rwild at gcc dot gnu dot org]

--- Comment #5 from rwild at gcc dot gnu dot org  2008-02-24 08:58 ---
Patch looks ok to me (but I cannot approve it), can you please post it to
gcc-patches for review?


-- 


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

[Bug other/35250] gmp and mpfr are erroneously configured with --target

[rwild at gcc dot gnu dot org]

--- Comment #3 from rwild at gcc dot gnu dot org  2008-02-24 09:06 ---
Can you post the patch to the gcc-patches list for review, including ChangeLog
entry and reference to this PR?

Note that, while I think it would be prudent if GMP did AC_MSG_WARN rather
than AC_MSG_ERROR for this, erroring out is in accordance with the GNU Coding
Standards which state:

|The target type normally defaults to the host type.  Programs for
| which cross-operation is not meaningful need not accept the `--target'
| option, because configuring an entire operating system for
| cross-operation is not a meaningful operation.

(which may just as well mean that the GCS should be fixed?)


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug ada/34799] [Ada] Assertion fails when no component clause is given for generic record member

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 09:11:35
   date||


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

[Bug ada/34598] GNAT BUG DETECTED

[sam at gcc dot gnu dot org]

--- Comment #4 from sam at gcc dot gnu dot org  2008-02-24 09:15 ---
Still present on trunk

+===GNAT BUG DETECTED==+
| 4.4.0 20080223 (experimental) (i686-pc-linux-gnu) Assert_Failure
atree.adb:886|
| Error detected at fp-dbs.adb:3489:35 |


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-12-27 13:15:49 |2008-02-24 09:15:20
   date||


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

[Bug c++/34749] Incorrect warning when applying dllimport to friend function

[dannysmith at gcc dot gnu dot org]

--- Comment #6 from dannysmith at gcc dot gnu dot org  2008-02-24 09:20 
---
Subject: Bug 34749

Author: dannysmith
Date: Sun Feb 24 09:19:39 2008
New Revision: 132585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132585
Log:
cp
PR c++/34749
* friend.c (do_friend): Call cplus_decl_attributes earlier.

testsuite
PR c++/34749
* g++.dg.ext/dllimport13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/dllimport13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/friend.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug other/35250] gmp and mpfr are erroneously configured with --target

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||build, patch
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 09:45:33
   date||


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

[Bug fortran/35348] New: g77 fails to warn critical real/complex assignment errors

[ohyeahq at yahoo dot co dot jp]

Dear Fortrunners:

The following code has two very common errors, but complies without errors or
warnings: (1) a complex-to-real assignment without explicit REALPART(); (2) a
subroutine call with an erroneous real-array arg in place of a complex-arrray
arg.  

  PROGRAM TESTCMPL
  IMPLICIT NONE
  REAL R,RA(2)
  COMPLEX C
  C=COMPLEX(1.0,1.0)
  R=C
  WRITE(*,*) 'C=',C,' -> R=',R
  RA(1)=1.0
  RA(2)=2.0
  WRITE(*,*) 'CALLS  AS:',RA(1),RA(2)
  CALL ARRAY(RA)
  STOP
  END

  SUBROUTINE ARRAY(CA)
  IMPLICIT NONE
  COMPLEX CA(2)
  WRITE(*,*) 'CALLED AS:',CA(1),CA(2)
  RETURN
  END

Here is the console output:

>g77 -mno-cygwin -O -fbounds-check -ftrapv -W -Wall -Wsurprising -pedantic -o 
>testcmpl.exe testcmpl.f

>testcmpl

 C= (1.,1.) -> R=  1.
 CALLS  AS:  1.  2.
 CALLED AS: (1.,2.) (7.72198524E+033,1.)

g77 should give errors or warnings, because these errors are very common in
real life.  I suffered for one week locating these :-)

Cheers


-- 
   Summary: g77 fails to warn critical real/complex assignment
errors
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ohyeahq at yahoo dot co dot jp


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

iNGYEN LETOLTES!

[andrus]

Szia!

Emlékszel amikor arról beszéltem hogy meg fog nyílni Magyarország legjobb 
letöltõ oldala?
Na, ha igen, akkor itt a link. Jó szorakozást! :)

http://href.hu/x/4pnj

[Bug preprocessor/35340] Space around the operator of a macro definition gives "too many positional arguments" when compiling an .S file

[aparna dot upadhya at gmail dot com]

--- Comment #2 from aparna dot upadhya at gmail dot com  2008-02-24 11:00 
---
(In reply to comment #1)
> I don't think this is a bug.  How are you invoking GCC?

Hi ,

Thanks for the reply. Pls find attached make output


gcc.c3.4.5-p1.ppc -mcpu=860 -ansi -nostdinc -O2  -fno-builtin  -I../h   -I.
-I/vob/t10/target/config/all -I/vob/t10/target/h -I/vob/t10/target/src/config
-I/vob/t10/target/src/drv -DCPU=PPC860  -g -x assembler-with-cpp -c -o
romInit.o ../romInit.s

 *** Error code 1

 ../romInit.s:397: Error: too many positional arguments
../romInit.s:414: Error: too many positional arguments
../romInit.s:414: Error: too many positional arguments
../romInit.s:418: Error: too many positional arguments


This error comes only when compiling ".s" files

thanks


-- 


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

[Bug preprocessor/35340] Space around the operator of a macro definition gives "too many positional arguments" when compiling an .S file

[schwab at suse dot de]

--- Comment #3 from schwab at suse dot de  2008-02-24 11:14 ---
The error is emitted by the assembler, this has nothing to do with the
preprocessor.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35349] New: gcc.c-torture/execute/20050604-1.c fails

[jrp at dial dot pipex dot com]

Native configuration is i686-pc-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/20050604-1.c execution,  -Os


Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure -v --enable-languages=c,c++,fortran
--enable-shared --with-system-zlib --without-included-gettext
--enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--with-arch=core2
Thread model: posix
gcc version 4.4.0 20080224 (experimental) (GCC)


-- 
   Summary: gcc.c-torture/execute/20050604-1.c fails
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrp at dial dot pipex dot com
 GCC build triplet: gcc version 4.4.0 20080224 (experimental) (GCC)
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug preprocessor/35340] Space around the operator of a macro definition gives "too many positional arguments" when compiling an .S file

[aparna dot upadhya at gmail dot com]

--- Comment #4 from aparna dot upadhya at gmail dot com  2008-02-24 11:56 
---
(In reply to comment #3)
> The error is emitted by the assembler, this has nothing to do with the
> preprocessor.

yes, but this error is not displayed by 2.95.3 GAS. I am trying to migrate from
2.95.3 to 3.4.5. Is there anything I am missing when configuring GCC ?


-- 


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

--- Comment #29 from fxcoudert at gcc dot gnu dot org  2008-02-24 11:59 
---
Subject: Bug 32841

Author: fxcoudert
Date: Sun Feb 24 11:59:09 2008
New Revision: 132587

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132587
Log:
PR libfortran/32841
* acinclude.m4: Don't use HAVE_MATH_H.
* configure: Regenerate.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure


-- 


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

[Bug c++/35350] New: FAIL: gcc.target/i386/isa-10.c execution test

[jrp at dial dot pipex dot com]

The above test started to fail over the last few days.

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure -v --enable-languages=c,c++,fortran
--enable-shared --with-system-zlib --without-included-gettext
--enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--with-arch=core2
Thread model: posix
gcc version 4.4.0 20080224 (experimental) (GCC)


-- 
   Summary: FAIL: gcc.target/i386/isa-10.c execution test
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrp at dial dot pipex dot com
 GCC build triplet: gcc version 4.4.0 20080224 (experimental) (GCC
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|fxcoudert 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=32841

[Bug libstdc++/35351] New: FAIL: abi_check

[jrp at dial dot pipex dot com]

The above test has started to fail in recent days

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure -v --enable-languages=c,c++,fortran
--enable-shared --with-system-zlib --without-included-gettext
--enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--with-arch=core2
Thread model: posix
gcc version 4.4.0 20080224 (experimental) (GCC)


-- 
   Summary: FAIL: abi_check
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrp at dial dot pipex dot com
 GCC build triplet: gcc version 4.4.0 20080224 (experimental) (GCC)
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libstdc++/35352] New: XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors)

[jrp at dial dot pipex dot com]

XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)  has been failing over the last couple of weeks

Compiler version: 4.4.020080224(experimental)(GCC) 
Platform: i686-pc-linux-gnu
configure flags: -v --enable-languages=c,c++,fortran --enable-shared
--with-system-zlib --without-included-gettext --enable-threads=posix
--enable-nls --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--with-arch=core2


-- 
   Summary: XPASS:
26_numerics/headers/cmath/c99_classification_macros_c.cc
(test for excess errors)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrp at dial dot pipex dot com
 GCC build triplet: 4.4.0 20080224(experimental)(GCC)
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

--- Comment #30 from fxcoudert at gcc dot gnu dot org  2008-02-24 12:09 
---
So, this was demonstrated to not be a problem on powerpc-apple-darwin9.2.0 any
more. We thus need to establish whether this was fixed in libgfortran or
whether this was fixed in the darwin8 -> darwin9 transition. To do that, the 
testcases in comments #0 (original report) and #10 should be tested on a
powerpc-apple-darwin8 machine; both the cases of a compiler configured on
powerpc-apple-darwin8 and a compiler configured on powerpc-apple-darwin9 but
run on powerpc-apple-darwin8 might prove interesting.

Other than that, I don't think there's much we can do. Related PR24685 was
closed as INVALID after showing it is due to a system libc bug (reported to
Apple). Even if we tracked this one down, the conclusion would probably be the
same :(  For now, I'm marking it as WAITING. If noone can provide information
in the near future, I'll support closing it altogether.

(The sparc-linux failure with -m64 is, as far as we know, unrelated; if more
information if available, a new PR should be open.)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug fortran/35348] g77 fails to warn critical real/complex assignment errors

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2008-02-24 12:22 
---
g77 is not supported any more; starting with GCC 4.0.0, it was replaced by
gfortran. Cygwin doesn't yet offer gfortran, so you'll have to ask them to do
so and/or download unofficial binaries from
http://gcc.gnu.org/wiki/GFortranBinaries.

For your problem: I think assignment of a complex value to a real variable is
valid Fortran, and behaves as you'd expect (assigning real part of the complex
value). The second issue is real, but hard to diagnose: it should be
incorporated in gfortran starting with 4.4.0, which is under development.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986

[fxcoudert at gcc dot gnu dot org]

--- Comment #15 from fxcoudert at gcc dot gnu dot org  2008-02-24 12:43 
---
I cannot reproduce it with mainline on powerpc-apple-darwin9.2.0: I tried the
original testcase and the trimmed one, and varied options (-m32 and -m64,
-gstabs and -gdwarf-2), but can't get it to fail anymore.


-- 


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

[Bug libstdc++/35351] FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2008-02-24 13:45 ---


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


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #8 from pcarlini at suse dot de  2008-02-24 13:45 ---
*** Bug 35351 has been marked as a duplicate of this bug. ***


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||jrp at dial dot pipex dot
   ||com


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

[Bug libstdc++/35352] XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors)

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2008-02-24 13:49 ---
You are mistaken: just have a look to the results posted to gcc-testresults,
the test XPASSes, as usual.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/35340] Space around the operator of a macro definition gives "too many positional arguments" when compiling an .S file

[aparna dot upadhya at gmail dot com]

--- Comment #5 from aparna dot upadhya at gmail dot com  2008-02-24 14:03 
---
(In reply to comment #3)
> The error is emitted by the assembler, this has nothing to do with the
> preprocessor.


Hi,

This is the dupplicate of the bug "Bugzilla Bug 1070 " which is still in Open
state. Sorry to open under a wrong component

thanks
aparna


-- 

aparna dot upadhya at gmail dot com changed:

   What|Removed |Added

 CC||aparna dot upadhya at gmail
   ||dot com, nickc at redhat dot
   ||com


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

[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-02-24 14:04 
---
The ICE itself can be gotten rid of by setting the offset of the private field
of our ISO_C derived types:

Index: trans-types.c
===
--- trans-types.c   (revision 132578)
+++ trans-types.c   (working copy)
@@ -1731,6 +1731,7 @@
 get_identifier (derived->components->name),
 gfc_typenode_for_spec (
   &(derived->components->ts)));
+  DECL_FIELD_OFFSET (derived->components->backend_decl) = size_int (0);

   derived->ts.kind = gfc_index_integer_kind;
   derived->ts.type = BT_INTEGER;


(Independently of the rest, I think that fix is desirable.) However, with that
fix, we now error out:

   C_NULL_PTR1 = transfer(0_C_INTPTR_T, C_NULL_PTR1)
1
Error: Can't convert INTEGER(4) to TYPE(c_ptr) at (1)

The reason for that is that gfc_typenode_for_spec(), which is called from
gfc_interpret_derived(), modifies the symbol itself to make it an integer:

  /* If we're dealing with either C_PTR or C_FUNPTR, we modified the
 type and kind to fit a (void *) and the basetype returned was a
 ptr_type_node.  We need to pass up this new information to the
 symbol that was declared of type C_PTR or C_FUNPTR.  */

I have always been wary of this course of actions (magically making the
ISO_C_BINDING derived types into scalar integer variables), and in that case it
is biting us hard. I have tried to work around this in target-memory.c by a
custom-tailored fix:

Index: target-memory.c
===
--- target-memory.c (revision 132578)
+++ target-memory.c (working copy)
@@ -379,7 +379,21 @@
   /* The attributes of the derived type need to be bolted to the floor.  */
   result->expr_type = EXPR_STRUCTURE;

-  type = gfc_typenode_for_spec (&result->ts);
+  /* FIXME -- This is more of a workaround than a real fix, please see
+ PR34199 for details.
+ For ISO_C_BINDING derived types, gfc_typenode_for_spec() will change
+ the symbol under our feet into an integer, which we don't want, so
+ we restore it.  */
+  if (result->ts.type == BT_DERIVED && result->ts.derived->attr.is_iso_c)
+{
+  gfc_typespec ts;
+  ts = result->ts;
+  type = gfc_typenode_for_spec (&result->ts);
+  result->ts = ts;
+}
+  else
+type = gfc_typenode_for_spec (&result->ts);
+
   cmp = result->ts.derived->components;

   /* Run through the derived type components.  */


This in turn makes the derived type constructors go into trans-expr.c's
gfc_conv_expr(), which does not deal with them. This is fixed with the
following patchlet:

Index: trans-expr.c
===
--- trans-expr.c(revision 132578)
+++ trans-expr.c(working copy)
@@ -3517,14 +3517,19 @@
 }

   /* We need to convert the expressions for the iso_c_binding derived types.
- C_NULL_PTR and C_NULL_FUNPTR will be made EXPR_NULL, which evaluates to
- null_pointer_node.  C_PTR and C_FUNPTR are converted to match the
- typespec for the C_PTR and C_FUNPTR symbols, which has already been
- updated to be an integer with a kind equal to the size of a (void *).  */
+ C_NULL_PTR, C_NULL_FUNPTR and constants (coming, for example, from the
+ simplification of TRANSFER expressions) will be made EXPR_NULL,
+ which evaluates to null_pointer_node.  C_PTR and C_FUNPTR are converted
+ to match the typespec for the C_PTR and C_FUNPTR symbols, which has
+ already been updated to be an integer with a kind equal to the size of
+ a (void *).  */
   if (expr->ts.type == BT_DERIVED && expr->ts.derived
   && expr->ts.derived->attr.is_iso_c)
 {
-  if (expr->symtree->n.sym->intmod_sym_id == ISOCBINDING_NULL_PTR
+  /* expr->expr_type == EXPR_STRUCTURE matches the constant derived
+ types.  */
+  if (expr->expr_type == EXPR_STRUCTURE
+ || expr->symtree->n.sym->intmod_sym_id == ISOCBINDING_NULL_PTR
   || expr->symtree->n.sym->intmod_sym_id == ISOCBINDING_NULL_FUNPTR)
 {
  /* Set expr_type to EXPR_NULL, which will result in


Now, with all three patches, we can compile the testcase and run it fine. I'm
not really satisfied with the patch to target-memory.c, as it is more a
workaround than a patch. For that reason, I'm not assigning this to myself and
will let the ISO_C_BINDING experts decide what course is most appropriate.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Keywords|   

[Bug c++/35353] New: C++ wide character locale doesn't work

[ivranos at freemail dot gr]

The following code works:

#include 
#include 
#include 

int main()
{
using namespace std;

char *p= setlocale( LC_ALL, "greek" );

if (!p)
  cerr<< "NULL returned!\n";

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
} 

[EMAIL PROTECTED] src]$ ./foobar-cpp 
Δοκιμαστικό
Δοκιμαστικό
[EMAIL PROTECTED] src]$ 



The following code DOES NOT work:

#include 
#include 
#include 

int main()
{
using namespace std;

wcout.imbue(locale("greek")); 

wstring ws;

wcin>> ws;

wcout<< ws<< endl;
} 


[EMAIL PROTECTED] src]$ ./foobar-cpp 
Δοκιμαστικό

[EMAIL PROTECTED] src]$ 


For the code that does not work:

[EMAIL PROTECTED] src]$ g++ -v -save-temps -ansi -pedantic-errors -Wall main.cc
-o foobar-cpp 
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
 /usr/libexec/gcc/i386-redhat-linux/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cc -mtune=generic -ansi -pedantic-errors -Wall -fpch-preprocess -o main.ii
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2

/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/i386-redhat-linux
 /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/i386-redhat-linux/4.1.2/include
 /usr/include
End of search list.
 /usr/libexec/gcc/i386-redhat-linux/4.1.2/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cc -mtune=generic -ansi -auxbase main -pedantic-errors -Wall
-ansi -version -o main.s
GNU C++ version 4.1.2 20070626 (Red Hat 4.1.2-14) (i386-redhat-linux)
compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-14).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129413
Compiler executable checksum: a9d7d7ea3146608fff5ae7eec9c8ae61
 as -V -Qy -o main.o main.s
GNU assembler version 2.17.50.0.6-5.el5 (i386-redhat-linux) using BFD version
2.17.50.0.6-5.el5 20061020
 /usr/libexec/gcc/i386-redhat-linux/4.1.2/collect2 --eh-frame-hdr -m elf_i386
--hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -o foobar-cpp
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.1.2/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.1.2 -L/usr/lib/gcc/i386-redhat-linux/4.1.2
-L/usr/lib/gcc/i386-redhat-linux/4.1.2/../../.. main.o -lstdc++ -lm -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i386-redhat-linux/4.1.2/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crtn.o
[EMAIL PROTECTED] src]$


-- 
   Summary: C++ wide character locale doesn't work
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivranos at freemail dot gr


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

[Bug c++/35353] C++ wide character locale doesn't work

[ivranos at freemail dot gr]

--- Comment #1 from ivranos at freemail dot gr  2008-02-24 14:11 ---
Created an attachment (id=15217)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15217&action=view)
The main.ii file produced by  -save-temps option

This is the file created by the 

g++ -v -save-temps -ansi -pedantic-errors -Wall main.cc -o foobar-cpp 

command, on the non-working code.


-- 


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

[Bug c++/35353] C++ wide character locale doesn't work

[ivranos at freemail dot gr]

--- Comment #2 from ivranos at freemail dot gr  2008-02-24 14:15 ---
Created an attachment (id=15218)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15218&action=view)
The produced main.s file

The main.s file produced by "g++ -v -save-temps -ansi -pedantic-errors -Wall
main.cc -o foobar-cpp"


-- 


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

[Bug c++/35353] C++ wide character locale doesn't work

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2008-02-24 14:18 ---
Not a bug, given our implementation-defined behavior: the various cin / wcin,
streams are by default synced with stdio (per the standard requirements) and
thus not converting. You can either call sync_with_stdio(false) before any I/O
or use converting stream, like fstreams.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35353] C++ wide character locale doesn't work

[ivranos at freemail dot gr]

--- Comment #4 from ivranos at freemail dot gr  2008-02-24 14:23 ---
Created an attachment (id=15219)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15219&action=view)
Screenshot of the standard I/O of the working code and of the non-working code.

This screenshot shows the I/O of the working code and of the non-working code
respectively.


-- 


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

[Bug c++/35353] C++ wide character locale doesn't work

[ivranos at freemail dot gr]

--- Comment #5 from ivranos at freemail dot gr  2008-02-24 14:35 ---
sync_with_stdio (false) doesn't work. Actually it crashes the code.

Check the screenshot I have attached in the latest attachment, to see the
difference between the C++ working code and the C++ non-working code.


-- 

ivranos at freemail dot gr changed:

   What|Removed |Added

 CC||ivranos at freemail dot gr
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/35353] C++ wide character locale doesn't work

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2008-02-24 14:40 ---
sync_with_stdio(false) works, and is tested dozens of times a day in our
testsuites. And that is only half of my answer. Please understand what I said,
study the details of the ISO C++ Standard and then come back.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/33738] -Wtype-limits misses a warning when comparing enums

[dnovillo at gcc dot gnu dot org]

--- Comment #9 from dnovillo at gcc dot gnu dot org  2008-02-24 16:41 
---
Subject: Bug 33738

Author: dnovillo
Date: Sun Feb 24 16:40:32 2008
New Revision: 132591

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

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01094.html

PR 33738
* tree-vrp.c (vrp_evaluate_conditional): With
-Wtype-limits, emit a warning when comparing against a
constant outside the natural range of OP0's type.
* c.opt (Wtype-limits): Move ...
* common.opt (Wtype-limits): ... here.

testsuite/ChangeLog

PR 33738
* g++.dg/warn/pr33738.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr33738.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c.opt
trunk/gcc/common.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug bootstrap/35354] New: ICE in libgcc2.c/__popcountsi2

[baraclese at googlemail dot com]

4.3.0-RC-20080222 configured with:
../configure -v --enable-languages=c,c++ --prefix=/usr/local --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --program-suffix=-4.3 --enable-__cxa_atexit
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-checking=release 

fails with:

/home/kevin/gcc-4.3.0-RC-20080222/bin/./gcc/xgcc
-B/home/kevin/gcc-4.3.0-RC-20080222/bin/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -g -fkeep-inline-functions -O2  -O2 -g
-g -O2   -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include -I../../../libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _popcountsi2.o -MT
_popcountsi2.o -MD -MP -MF _popcountsi2.dep -DL_popcountsi2 -c
../../../libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../libgcc/../gcc/libgcc2.c: In function ‘__popcountsi2’:
../../../libgcc/../gcc/libgcc2.c:799: internal compiler error: Illegal
instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_popcountsi2.o] Error 1
make[3]: Leaving directory
`/home/kevin/gcc-4.3.0-RC-20080222/bin/i686-pc-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/kevin/gcc-4.3.0-RC-20080222/bin'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/kevin/gcc-4.3.0-RC-20080222/bin'
make: *** [all] Error 2


-- 
   Summary: ICE in libgcc2.c/__popcountsi2
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baraclese at googlemail dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/35348] g77 fails to warn critical real/complex assignment errors

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2008-02-24 17:42 ---
FX is correct with respect to assignment of a complex expression
to a real variable.  See page 141 of the F2003 standard especially
table 7.9.

real x
complex :: z = (1,-1)
x = z
end 

The 'x = z' is treated as if you wrote 'x = real(z,kind(x))'

As to the subroutine problem, your program is technically
illegal for at least one reasone.  You've never assigned
a value to CA(2), so you're not allowed to reference it.

To avoid these types of issues if make the subroutine an
internal subprogram or use an explicit interface for the
subroutine.


-- 


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

[Bug fortran/35348] g77 fails to warn critical real/complex assignment errors

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-02-24 18:05 
---
If you do decide to give gfortran a try from the binary you download at the
link given in comment #1, please let us know how it works for you.


-- 


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

[Bug bootstrap/35354] ICE in libgcc2.c/__popcountsi2

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-24 18:07 ---
>../../../libgcc/../gcc/libgcc2.c:799: internal compiler error: Illegal 
>instruction
> Please submit a full bug report,


Can you post the output of /proc/cpuinfo ?


-- 


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

[Bug target/35349] gcc.c-torture/execute/20050604-1.c fails

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-02-24 18:24 ---
-march=core2 implies -mmmx, so this test should be executed with -mno-mmx.
Using v4hi, or anything that is defined with vector_size (8), like:

typedef short v4hi __attribute__ ((vector_size (8)));

from the test, uses MMX registers (when enabled). When MMX register is touched,
it blocks whole x87 register stack untill emms is executed.

I'll add -mno-mmx for the testcase.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 18:24:50
   date||


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

[Bug target/35349] gcc.c-torture/execute/20050604-1.c fails

[uros at gcc dot gnu dot org]

--- Comment #2 from uros at gcc dot gnu dot org  2008-02-24 19:18 ---
Subject: Bug 35349

Author: uros
Date: Sun Feb 24 19:17:15 2008
New Revision: 132596

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132596
Log:
PR target/35349
* gcc.c-torture/execute/20050604-1.x: New file.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20050604-1.x
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at gcc dot gnu dot org]

--- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-02-24 19:19 
---
Subject: Bug 35223

Author: jvdelisle
Date: Sun Feb 24 19:18:27 2008
New Revision: 132597

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

PR fortran/35223
* simplify.c (gfc_simplify_ibclr), (gfc_simplify_ibits),
(gfc_simplify_ibset): Remove call to range_check.
(simplify_cmplx), (gfc_simplify_dble), (gfc_simplify_float)
(gfc_simplify_real): Add call gfc_clear_ts to initialize the
temporary gfc_typspec variable.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c


-- 


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

[Bug target/35349] gcc.c-torture/execute/20050604-1.c fails

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-02-24 19:19 ---
Fixed testcase.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords|wrong-code  |
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c++/35350] FAIL: gcc.target/i386/isa-10.c execution test

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-02-24 19:23 ---
Confirmed.

gcc.target/i386/isa-10 was introduced by
http://gcc.gnu.org/viewcvs?view=rev&revision=132403


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 19:23:22
   date||


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

[Bug c++/35350] FAIL: gcc.target/i386/isa-10.c execution test

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-02-24 19:24 ---
H.J, please note --with-arch=core2 in config.


-- 


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

[Bug bootstrap/35354] ICE in libgcc2.c/__popcountsi2

[baraclese at googlemail dot com]

--- Comment #2 from baraclese at googlemail dot com  2008-02-24 19:41 
---
> Can you post the output of /proc/cpuinfo ?

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 800.039
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow up
bogomips: 1602.11
clflush size: 32



-- 


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

[Bug fortran/35223] IBITS gives compiler error

[jvdelisle at gcc dot gnu dot org]

--- Comment #16 from jvdelisle at gcc dot gnu dot org  2008-02-24 19:45 
---
Fixed on trunk, Thanks for report.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

--- Comment #18 from matz at gcc dot gnu dot org  2008-02-24 19:52 ---
Umm sorry.  I meant the __gmp_mt_recalc_buffer function is global in my last
comment.


-- 


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

[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2008-02-24 20:14 ---
(In reply to comment #1)
> Are you testing
> with a simulator on x86_64-unknown-linux-gnu?  I am trying to understand the
> environment.  :)

Hm, I thought I was clear enough with the bug report unambiguously indicating a
cross target, with the *-elf indicating and the message pointed to saying
"(remember, cris-elf is one of those challenged newlib simulator targets)" but
to wit: yes, your reading is correct.  If there's a clearer way of saying it,
send patches.

For the pr35132.f90 attachment, abort is called and "hexdump -C foo.txt"
produces:
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0010  00 00 00 00 00 31 32 33  34 35 36 0a 61 62 63 64  |.123456.abcd|
0020  65 66 0a 71 77 65 72 74  79 0a|ef.qwerty.|
002a
(foo.txt will also be attached as-is for your enjoyment)

I'll work on a patch to unix.c:fd_truncate.


-- 


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

[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-02-24 20:17 ---
Created an attachment (id=15220)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15220&action=view)
foo.txt as was output from above modified test-case


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[matz at gcc dot gnu dot org]

--- Comment #17 from matz at gcc dot gnu dot org  2008-02-24 19:50 ---
Honza: No recursion is involved here.  I guess (Tege: correct me if I'm wrong)
that already the first call to __gmp_mt_recalc_buffer() from
__gmp_randget_mt() will segfault, as the first call obviously will end up
in the dynamic linker, and that one wants to have $rsp aligned on 8 mod 16.

But I wonder how that could happen.  After all the __gmp_randget_mt function
is global, not local, and can be overridden, so why would GCC assume that
just because it knows its body it can ignore the usual alignment requirements
for global functions?

Is it possible that the darwin support in GCC determines that randget_mt
is a local function (perhaps because MACH-O doesn't allow symbol interposition
like ELF does)?  In that case we can't do this optimization in the darwin
case.


-- 


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

[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.

[hp at gcc dot gnu dot org]

--- Comment #5 from hp at gcc dot gnu dot org  2008-02-24 20:25 ---
The above was with 132513.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

--- Comment #19 from tege-gcc at swox dot com  2008-02-24 20:39 ---
I believe the "local call" optimization is triggered when compiling
__gmp_randget_mt() because its only call is to a function the compiler
determines to be local.  (One can easily untrigger the optimization by
inserting a dummy call to foo() in __gmp_mt_recalc_buffer().)

  After all the [__gmp_mt_recalc_buffer()] function is global, not local,
  and can be overridden, so why would GCC assume that just because it
  knows its body it can ignore the usual alignment requirements for
  global functions?

I think we're using "global" and "local" in two sense here.  Sure,
__gmp_mt_recalc_buffer() is global in visibility, but it is local
to the compilation unit, which is what counts for the semi-invalid
optimization discussed.  GCC bases its decision whether to call with
an unaligned stack solely on the latter definition of "local".


-- 


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

[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-02-24 20:49 
---
Besides not truncating or even seeking, the leading NULLs in the file are very
bad.


-- 


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

[Bug middle-end/35292] Missing Const Prop -- union fields

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2008-02-24 21:14 ---
Subject: Re:  Missing Const Prop -- union fields

On Sat, 23 Feb 2008, pinskia at gcc dot gnu dot org wrote:

> --- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-23 05:50 
> ---
> More than just constant prop, see PR 25972 for more info on what else it can 
> be
> done with union in the same way.
> 
> Actually I think MEM_REF will make it worse and will not help.  In fact I 
> still
> think MEM_REF is a bad idea and will cause worse aliasing issues with unions
> than that are already done.

Please elaborate.  This handwaving doesn't help.

Richard.


-- 


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

[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[jh at suse dot cz]

--- Comment #20 from jh at suse dot cz  2008-02-24 20:49 ---
Subject: Re:  Stack not aligned at mod 16 byte boundary in x86_64 code

Hi,
what about this patch.  There seems to be availablity check missing
earlier in code.  This way GCC will always align calls to functions that
might be overwritten (thus resolved by dynamic linker) with exception of
the recursive calls..

I still wonder how this problem can hit us so late: if we was
misaligning commonly stack on PIC calls and dynamic linker was crashing
on it, I would expect darwin to be unable to boot at all...

Honza

Index: calls.c
===
--- calls.c (revision 132575)
+++ calls.c (working copy)
@@ -2102,7 +2102,9 @@ expand_call (tree exp, rtx target, int i
   if (fndecl)
 {
   struct cgraph_rtl_info *i = cgraph_rtl_info (fndecl);
-  if (i && i->preferred_incoming_stack_boundary)
+  if (i && i->preferred_incoming_stack_boundary
+ && (cgraph_function_body_availability (cgraph_node (fndecl))
+ >= AVAIL_AVAILABLE))
preferred_stack_boundary = i->preferred_incoming_stack_boundary;
 }



-- 


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2008-02-24 21:47 
---
Could you put the breakpoint on the 'error' function rather than at line 34
and examine again the condition when it is hit?  Does the problem arise if
you add -fno-delayed-branch on the command line?


-- 


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

[Bug bootstrap/35354] ICE in libgcc2.c/__popcountsi2

[baraclese at googlemail dot com]

--- Comment #3 from baraclese at googlemail dot com  2008-02-24 21:22 
---
Apparently an old mpfr lib was the problem.

configure did warn me about it but said it was still okay afair. I switched
from mpfr-2.2.1 to mpfr-2.3.0 now and it bootstrapped okay.


-- 


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

[Bug c++/35324] [4.1/4.2/4.3/4.4 regression] Invalid argument to sizeof not rejected in template

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:08:42
   date||
   Target Milestone|4.1.3   |4.2.4


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

[Bug middle-end/35310] Late struct expansion -- missing PRE (2)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
Version|unknown |4.3.0


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

[Bug middle-end/35306] Missing expression simplication for conditional OR

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:18:42
   date||
Version|unknown |4.3.0


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

[Bug c++/35327] [4.3/4.4 regression] ICE with invalid constructor

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:06:19
   date||


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

[Bug middle-end/35342] Full unrolling limitation -- inner most loop only

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-24 21:57 ---
You might run into limits here.  I think this restriction was removed at
some point.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
   Keywords||missed-optimization
Version|unknown |4.3.0


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

[Bug c++/35326] [4.2/4.3/4.4 regression] ICE with stray digraph token

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:06:41
   date||


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

[Bug middle-end/35341] Early exit loop with short known trip count not unrolled

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
   Keywords||missed-optimization
Version|unknown |4.3.0


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

[Bug c++/35332] [4.1/4.2/4.3/4.4 regression] Broken diagnostics for builtins

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-24 22:03 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:03:18
   date||
   Target Milestone|4.1.3   |4.2.4


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

[Bug c/35330] [4.1/4.2/4.3/4.4 regression] ICE with invalid pragma weak

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:04:25
   date||
   Target Milestone|4.1.3   |4.2.4


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

[Bug tree-optimization/35344] Loop unswitching to produce perfect loop nest

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-24 21:54 ---
I think this is a dup of PR23855.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
  Component|middle-end  |tree-optimization
   Keywords||missed-optimization
Version|unknown |4.3.0


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

[Bug c++/35329] [4.2/4.3/4.4 regression] ICE with invalid template class after #pragma interface

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:05:33
   date||


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

[Bug c++/35338] [4.3/4.4 regression] Broken diagnostics for fixed-point types

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-24 21:59 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 21:59:44
   date||


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

[Bug middle-end/35346] Scalar replacement -- handling of conditional generator -- missing

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
Version|unknown |4.3.0


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

[Bug middle-end/35345] Scalar replacement to handle output dependence

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
   Keywords||missed-optimization
Version|unknown |4.3.0


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

[Bug c++/35335] [4.1/4.2/4.3/4.4 regression] Broken diagnostic: 'expr_stmt' not supported by dump_expr

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-24 22:00 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:00:44
   date||


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

[Bug ada/15479] Ada manual problems

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2008-02-24 22:44 ---
Subject: Bug 15479

Author: rwild
Date: Sun Feb 24 22:44:01 2008
New Revision: 132603

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132603
Log:
PR documentation/15479
* gnat_rm.texi, gnat_ugn.texi: Where appropriate, replace `..'
and `...' with [EMAIL PROTECTED]' or [EMAIL PROTECTED]'.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnat_rm.texi
trunk/gcc/ada/gnat_ugn.texi


-- 


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

[Bug c++/35331] [4.3/4.4 regression] ICE with invalid specialization of variadic template

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P5
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:03:54
   date||


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

[Bug ada/15479] Ada manual problems

[rwild at gcc dot gnu dot org]

--- Comment #6 from rwild at gcc dot gnu dot org  2008-02-24 22:38 ---
Subject: Bug 15479

Author: rwild
Date: Sun Feb 24 22:37:52 2008
New Revision: 132601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132601
Log:
PR documentation/15479
* gnat_ugn.texi (Using gnatmake in a Makefile): Do not ignore errors
in Makefile rules, by using `&&' rather than `;'.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnat_ugn.texi


-- 


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

[Bug fortran/35355] New: Result of call cpu_time(x) can decrease or give non credible values with repeated calls

[edunlop at utvinternet dot ie]

Inconsistent or odd "call cpu_time(x)" behaviour on the current release of
gfortran. I am using the 32 bit Mingw version of gfortran.

C:\>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads
--disable-nls --build=i386-pc-mingw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.3.0 20080127 (experimental) [trunk revision 131883] (GCC)

The "call cpu_time(x)" operations worked perfectly under a fairly recent
previous release of gfortran (sorry, I no longer have the version info).

I have declared x as follows:-

integer,parameter :: pr=selected_real_kind(6,37)
real(kind=pr) :: x

Unfortunately my code is very lengthy - but I could send it as an example if
really necessary.

Edmund Dunlop.


-- 
   Summary: Result of call cpu_time(x) can decrease or give non
credible values with repeated calls
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edunlop at utvinternet dot ie


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

[Bug fortran/35355] Result of call cpu_time(x) can decrease or give non credible values with repeated calls

[edunlop at utvinternet dot ie]

--- Comment #1 from edunlop at utvinternet dot ie  2008-02-24 22:55 ---
Inconsistent or odd "call cpu_time(x)" behaviour on the current release of
gfortran. I am using the 32 bit Mingw version of gfortran.

C:\>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads
--disable-nls --build=i386-pc-mingw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.3.0 20080127 (experimental) [trunk revision 131883] (GCC)

The "call cpu_time(x)" operations worked perfectly under a fairly recent
previous release of gfortran (sorry, I no longer have the version info).

I have declared x as follows:-

integer,parameter :: pr=selected_real_kind(6,37)
real(kind=pr) :: x

Unfortunately my code is very lengthy - but I could send it as an example if
really necessary.

Edmund Dunlop.


-- 


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

[Bug ada/15479] Ada manual problems

[rwild at gcc dot gnu dot org]

--- Comment #7 from rwild at gcc dot gnu dot org  2008-02-24 22:41 ---
Subject: Bug 15479

Author: rwild
Date: Sun Feb 24 22:40:31 2008
New Revision: 132602

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132602
Log:
PR documentation/15479
* gnat_rm.texi, gnat_ugn.texi: Where appropriate, add @command,
use @command instead of @code, @option instead of @samp or @code,
@code instead of @var, @samp instead of @file.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnat_rm.texi
trunk/gcc/ada/gnat_ugn.texi


-- 


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

[Bug middle-end/35307] Missing Simplication for div op

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:16:29
   date||
Version|unknown |4.3.0


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

[Bug c++/35333] [4.1/4.2/4.3/4.4 regression] Broken diagnostic for complex builtin

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-24 22:02 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:02:22
   date||
   Target Milestone|4.1.3   |4.2.4


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

[Bug middle-end/35343] Sum-reduction loop not recognized

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
Version|unknown |4.3.0


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

[Bug c++/35334] [4.1/4.2/4.3/4.4 regression] Broken diagnostic for complex cast

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-24 22:01 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-24 22:01:18
   date||
   Target Milestone|--- |4.2.4


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

[Bug c++/33486] namespace association doesn't handle parallel namespaces

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2008-02-25 02:03 ---
This is a compiler bug.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|bkoz at gcc dot gnu dot org |jason at gcc dot gnu dot org
  Component|libstdc++   |c++
Summary|parallel v3: functions not  |namespace association
   |in right namespace  |doesn't handle parallel
   ||namespaces


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

[Bug ada/33857] Cannot bootstrap Ada with host gnatmake-4.2

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-02-25 04:02 ---
I'm seeing essentially the same thing on i686-apple-darwin9:

# gnattools2
make -C ../gcc/ada/tools -f ../Makefile \
  "CC=../../xgcc -B../../" "CFLAGS=-O2 -g -g -O2  " "ADAFLAGS=-gnatpg
-g
nata" "INCLUDES=-I. -I.. -I../.. -I/Users/dave/gnu/gcc/gcc/gcc/ada
-I/Users/dave
/gnu/gcc/gcc/gcc/ada/../config -I/Users/dave/gnu/gcc/gcc/gcc/ada/../../include
-
I/Users/dave/gnu/gcc/gcc/gcc/ada/.." "ADA_INCLUDES=-I../rts -I.
-I/Users/dave/gn
u/gcc/gcc/gcc/ada" "exeext=" "fsrcdir=/Users/dave/gnu/gcc/gcc/gcc/ada"
"srcdir=/
Users/dave/gnu/gcc/gcc/gcc/ada" "GNATMAKE=../../gnatmake"
"GNATLINK=../../gnatli
nk" "GNATBIND=../../gnatbind" "TOOLSCASE=native" \
  ../../gnatchop ../../gnat ../../gnatkr ../../gnatls ../../gnatprep
../
../gnatxref ../../gnatfind ../../gnatname ../../gnatclean
../../gnatmake -c -I../rts -I. -I/Users/dave/gnu/gcc/gcc/gcc/ada gnatchop
--GCC=
"../../xgcc -B../../ -O2 -g -g -O2-gnatpg -gnata"
../../xgcc -c -I./ -I../rts -I. -I/Users/dave/gnu/gcc/gcc/gcc/ada -B../../ -O2
-
g -g -O2 -gnatpg -gnata -I- /Users/dave/gnu/gcc/gcc-4.3/gcc/ada/gnatchop.adb
gnatmake: error, unable to locate ../../xgcc
make[3]: *** [../../gnatchop] Error 4
make[2]: *** [gnattools-native] Error 2
make[1]: *** [all-gnattools] Error 2
make: *** [bootstrap] Error 2
Sun 24 Feb 2008 22:42:12 EST

In this case, the bootstrap compiler was gcc version 4.3.0 20070903.


-- 

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

[Bug middle-end/35356] New: Missing Index splitting support in gcc

[xinliangli at gmail dot com]

The following cases are not handled by gcc:

case 1:
Example 28:  search loop -- yes it is silly, but exists in real program:

  for (i = 0; i < n; i++)
  {
  if ( i == k)
  a[i] = ...
  }

Should eliminate the loop and generate:

if (k >= 0 && k < n)
a[k] = 


case 2:

  for (i = 0; i < n; i++)
  {
   if (i == k)
  a[i] = 1;
   else 
  a[i] = i;
  }

Should be converted into:
  for (i = 0; i < min (n, k); i++)
 a[i] = i;
  if (k >= 0 && k < n)
 a[k] = 1;
  for (i = max(k+1,0); i < n; i++)
 a[i] = i;


case 3 (similar to case 1): (from art)

int winner,numf1s,numf2s, resonant,cp,numpatterns;
double **tds;
double d, tsum;
typedef struct {
  double y;
  int   reset;
  } xyz;

xyz *Y;
int ti;

void match()
{
  int tj,tresult;
  for (tj=0;tj 0))
tsum += tds[ti][tj] * d;
}
}


-- 
   Summary: Missing Index splitting support in  gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35357] New: Loop peeling not happening

[xinliangli at gmail dot com]

//David Li

Loop peeling is special case of index splitting. Gcc has support for this
(under -O3 -funrool_loops, also -fno-tree-vectorize for the simple case), but
it does not happen for the following cases:

int a[100];
int b[1000];
void foo(int n)
{
  int i;
  for ( i = 0; i <= n; i++)
  {

   b[i*2] = a[3*i+1];
   if (i < n)
  b[i*2] +=1;
  }
}


-

int a[100];
int b[1000];
void foo(int n)
{
  int i;
  for ( i = 0; i < n; i++)
  {
  if (i==0) b[i*2] +=1;
   b[i*2] = a[3*i+1];
  }
}


-- 
   Summary: Loop peeling not happening
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug c++/33979] support for char16_t, char32_t

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-02 22:26:37 |2008-02-25 05:03:41
   date||


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

[Bug middle-end/35358] New: Ansi aliasing info not fully utilized by tree SSA optimizations

[xinliangli at gmail dot com]

// David Li

The issue is known and being worked on. File this bug report just to track the
problem.

One of the rules that can be derived from the basic rules is that if two
access's base types are the same, access offset and size can be used to
determine the overlapping relationships of the two accesses. This is currently
not handled in GCC -- most likely an implementation issue.

Example 38:

struct BUF1
{
  int b1;
  int b12;
};


int foo(int n, struct BUF1* p, struct BUF1* q)
{
int i = 0;
for (i = 0; i < n; i++)
{
p->b1 += q->b12;// Two accesses are not aliased with strict
aliasing
}
return 0;
}


The loop should be transformed into:

t1 = p->b1;
t2 = q->b12;
for (...)
{
  t1 += t2;
}
p->b1= t1;


The ansi rule can also be extended to handle cases where one type is nested
within another one.

Example 39:

struct BUF1
{
  int b1;
  int b12;
};

struct BUF2
{
  int b2;
  int g;
  struct BUF1 bf1;
};


int foo(int n, struct BUF1* p, struct BUF2* q)
{
int i = 0;
for (i = 0; i < n; i++)
{
p->b1 += q->b2;
}
return 0;
}


-- 
   Summary: Ansi aliasing info not fully utilized by tree SSA
optimizations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35359] New: Conservative aliasing related unmodified formals

[xinliangli at gmail dot com]

Unmodified formals can not point to local variables. It is NOT treated so in
GCC:

Example:

void bar(int* );
int foo(int* p, int *q)
{
   int local, i;
   bar(&local);

   for(i = 0; i < 100; i++)
   {
   *q += local;// local, *q not hoisted, *q = not sinked
   }

   return local;
}


-- 
   Summary: Conservative aliasing related unmodified formals
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35360] New: Static (base/offset/size rule) should be extended to handle array elements

[xinliangli at gmail dot com]

// David Li
the two references in the loop are not aliased. Not optimized by gcc

struct A{
 int a;
 int b;
};

struct A aa[100];


void foo(int n, int i, int j)
{
  int k = 0;
  for (k = 0; k < n; k++)
  {
  aa[i].a += aa[j].b;
  }
}


-- 
   Summary: Static (base/offset/size rule) should be extended to
handle array  elements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35361] New: Missing dead store elimination for statics

[xinliangli at gmail dot com]

// David Li

Gcc is solid in performing dead function elimination and dead variable
elimination for statics. It handles cases when a dead variable is referenced
(via initializer) by other dead variables pretty well. The missing
opportunities noticed is that it fails to discover dead stores to static
variables where are never used -- thus missing the dead variable elimination
...

Example 1:

static int s;
static int* p =&s;

int foo()
{
   p = 0;  // Dead, not eliminated
}


Example 2:

static int g = 10;
static int* gp = &g;

int foo()
{
  gp = 0;  // Dead store
  return g;// should be const proped
}


-- 
   Summary: Missing dead store elimination for statics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug rtl-optimization/35362] New: Switch expansion Enh

[xinliangli at gmail dot com]

// David Li

For switch statement with very large case value range, but the number of actual
cases are not large, gcc generated code seems suboptimal: in some cases, huge
jump table is generated (with lots of duplicated entries), while in other
cases, huge concatenated ifs are generated (the number of compares for a hit
may be more than 3 even with binary search scheme). For those cases, mixed mode
expansion may be preferred -- where both compares and jump tables are used.

// Example 1: huge jump  table (> 300 entries)

int g;
int foo(int k)
{

   switch (k)
  {

case 20: g += 10; break;
case 18: g += 11; break;
case 16: g += 12; break;
case 14: g += 13; break;
case 12: g += 14; break;
case 10: g += 15; break;
case 8: g += 3; break;
case 4: g += 2; break;
case 2: g -= 1; break;
case 0: g += 1; break;

case 120: g += 10; break;
case 118: g += 11; break;
case 116: g += 12; break;
case 114: g += 13; break;
case 112: g += 14; break;
case 110: g += 15; break;
case 119: g += 3; break;
case 121: g += 2; break;
case 122: g -= 1; break;
case 123: g += 1; break;

case 220: g += 10; break;
case 218: g += 11; break;
case 216: g += 12; break;
case 214: g += 13; break;
case 212: g += 14; break;
case 210: g += 15; break;

case 324: g += 10; break;
case 323: g += 10; break;
case 322: g += 10; break;
case 321: g += 10; break;
case 320: g += 10; break;
case 318: g += 11; break;
case 316: g += 12; break;
case 314: g += 13; break;
case 312: g += 14; break;
case 310: g += 15; break;

default: break;
 }
 return g;
}

Example 2: No jump table used:

int g;
int foo(int k)
{
   switch (k)
  {

case 20: g += 10; break;
case 18: g += 11; break;
case 16: g += 12; break;
case 14: g += 13; break;
case 12: g += 14; break;
case 10: g += 15; break;
case 8: g += 3; break;
case 4: g += 2; break;
case 2: g -= 1; break;
case 0: g += 1; break;

case 120: g += 10; break;
case 118: g += 11; break;
case 116: g += 12; break;
case 114: g += 13; break;
case 112: g += 14; break;
case 110: g += 15; break;
case 119: g += 3; break;
case 121: g += 2; break;
case 122: g -= 1; break;
case 123: g += 1; break;

case 220: g += 10; break;
case 218: g += 11; break;
case 216: g += 12; break;
case 214: g += 13; break;
case 212: g += 14; break;
case 210: g += 15; break;

case 324: g += 10; break;
case 323: g += 10; break;
case 322: g += 10; break;
case 321: g += 10; break;
case 320: g += 10; break;
case 318: g += 11; break;
case 316: g += 12; break;
case 314: g += 13; break;
case 312: g += 14; break;
case 310: g += 15; break;

case 1324: g += 10; break;
case 1323: g += 10; break;
case 1322: g += 10; break;
case 1321: g += 10; break;
case 1320: g += 10; break;
case 1318: g += 11; break;

default: break;
 }
 return g;
}


-- 
   Summary: Switch expansion Enh
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35363] New: Missing bit field coalscing optimization

[xinliangli at gmail dot com]

// David Li

struct A{
  int b1: 3;
  int b2: 3;
  int b3: 2;
  int b4: 17;
}a;
void foo()
{
a.b1 = 2;
a.b2 = 3;
a.b4 = 8;
}

This requires one LOAD + one OR + one STORE, but the generate code looks like:

foo:
.LFB2:
movzbl  a(%rip), %eax
andl$-64, %eax
orl $26, %eax
movb%al, a(%rip)
movla(%rip), %eax
andl$-33554177, %eax
orb $8, %ah
movl%eax, a(%rip)
ret


-- 
   Summary: Missing bit field coalscing optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug c++/33486] namespace association doesn't handle parallel namespaces

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2008-02-25 06:27 ---
Subject: Bug 33486

Author: jason
Date: Mon Feb 25 06:26:24 2008
New Revision: 132611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132611
Log:
* gcc/cp/parser.c (cp_parser_declaration): Handle 'inline namespace'.
(cp_parser_namespace_definition): Likewise.

PR c++/33486
* gcc/cp/name-lookup.c (arg_assoc_namespace): Look down into inline
namespaces, too.

* libstdc++-v3/include/bits/c++config: Use 'inline namespace'
instead of strong using.

Added:
trunk/gcc/testsuite/g++.dg/lookup/strong-using-5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/g++.dg/lookup/strong-using-1.C
trunk/gcc/testsuite/g++.dg/lookup/strong-using-2.C
trunk/gcc/testsuite/g++.dg/lookup/strong-using-3.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/c++config


-- 


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