[Bug fortran/36689] PRINT and WRITE eat minus sign

[dennis dot wassel at googlemail dot com]

--- Comment #4 from dennis dot wassel at googlemail dot com  2008-07-02 
08:54 ---
> (In reply to myself)
> The problem seems to remain the same, regardless of the type of array of XP,
> that is allocatable or fixed-size (compile-time).
> Stupid I didn't check this earlier...

Out of curiosity, I tried turning XP into a scalar. Still no signs of any minus
signs.


-- 


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

[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-07-02 09:22 ---
This is caused by the implicit gotos at the end of basic blocks.
See http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01840.html
During cfgexpand this can be IMHO fixed by setting curr_location before
emitting the jump, not after it (otherwise e->goto_locus is IMHO useless,
as most likely the following statements will change curr_location before
anything is emitted):
--- gcc/cfgexpand.c.jj 2008-06-06 09:17:07.0 +0200
+++ gcc/cfgexpand.c 2008-07-02 10:43:54.0 +0200
@@ -1610,9 +1610,9 @@ expand_gimple_basic_block (basic_block b

   if (e && e->dest != bb->next_bb)
 {
-  emit_jump (label_rtx_for_bb (e->dest));
   if (e->goto_locus)
 set_curr_insn_source_location (e->goto_locus);
+  emit_jump (label_rtx_for_bb (e->dest));
   e->flags &= ~EDGE_FALLTHRU;
 }

Not sure if expand_gimple_cond_expr should stay as is or be modified as well.

This fixes this problem for the few early RTL passes, but then we go into
cfglayout mode and the JUMP is removed again.
force_nonfallthru_and_redirect then when going out of cfglayout mode recreates
the JUMP again, but completely ignores e->goto_locus:

  if (target == EXIT_BLOCK_PTR)
{
#ifdef HAVE_return
emit_jump_insn_after_noloc (gen_return (), BB_END (jump_block));
#else
gcc_unreachable ();
#endif
}
  else
{
  rtx label = block_label (target);
  emit_jump_insn_after_noloc (gen_jump (label), BB_END (jump_block));
  JUMP_LABEL (BB_END (jump_block)) = label;
  LABEL_NUSES (label)++;
}

One problem is that we have just locus for the edges, not BLOCK, so if
force_nonfallthru_and_redirect were to call emit_jump_insn_after_setloc
instead,
the question is what BLOCK should be used for it (e.g. pick the block from insn
before the jump (if any)?  What to do if there is none in the basic block?).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org, hubicka at gcc dot gnu
   ||dot org


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

[Bug middle-end/36691] [4.1/4.2/4.3/4.4 Regression] wrong value left in induction variable

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-07-02 09:36 ---
This is SCCP.  And then both ivcanon and ivopts.  Thus,

 -fno-tree-scev-cprop -fno-ivopts -fno-tree-loop-ivcanon

fixes it.

Confirmed with -O.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, spop at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.1.1 4.3.1
  Known to work||4.1.0
   Last reconfirmed|-00-00 00:00:00 |2008-07-02 09:36:54
   date||
Summary|wrong value left in |[4.1/4.2/4.3/4.4 Regression]
   |induction variable  |wrong value left in
   ||induction variable
   Target Milestone|--- |4.1.3


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

[Bug c/36693] New: missed optimization for pointer access with offset on powerpc

[rbuergel at web dot de]

the following two equivalent functions are compiled into different asm-code.
The bad thing is, that the more readable function (get_and_increment2) creates
worse code. It is bigger and slower. This is because it uses one register more
than the more optimized version get_and_increment1.


struct IntPtr
{
int* m_ReadPtr;
};

int get_and_increment1(struct IntPtr* i)
{
return *(i->m_ReadPtr++);
}

int get_and_increment2(struct IntPtr* i)
{
i->m_ReadPtr++;
return *(i->m_ReadPtr - 1);
}


 :
   0:   81 23 00 00 lwz r9,0(r3)
   4:   80 09 00 00 lwz r0,0(r9)
   8:   39 29 00 04 addir9,r9,4
   c:   91 23 00 00 stw r9,0(r3)
  10:   7c 03 03 78 mr  r3,r0
  14:   4e 80 00 20 blr

0018 :
  18:   81 23 00 00 lwz r9,0(r3)
  1c:   39 29 00 04 addir9,r9,4
  20:   91 23 00 00 stw r9,0(r3)
  24:   80 69 ff fc lwz r3,-4(r9)
  28:   4e 80 00 20 blr


-- 
   Summary: missed optimization for pointer access with offset on
powerpc
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: powerpc-linux-uclibc


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

[Bug c/36692] _Complex __float128 doesn't work

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2008-07-02 10:31 ---


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


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/32187] Complex __float128 is rejected

[jsm28 at gcc dot gnu dot org]

--- Comment #6 from jsm28 at gcc dot gnu dot org  2008-07-02 10:31 ---
*** Bug 36692 has been marked as a duplicate of this bug. ***


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug c++/36694] New: g++-4.2 rejects code, that other versions of gcc accept

[tim at klingt dot org]

the attached preprocessed source does not compile with g++-4.2. it does compile
with g++-4.0, 4.1 and 4.3, though, so i don't know whether there is any
interest to work on a reduced test case and work on a bug fix ... 

from my reading of the compiler error, it has to do with the compiler-generated
copy constructor ...

g++-4.2 -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-2+b1)


-- 
   Summary: g++-4.2 rejects code, that other versions of gcc accept
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim at klingt dot org


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

[Bug c++/36694] g++-4.2 rejects code, that other versions of gcc accept

[tim at klingt dot org]

--- Comment #1 from tim at klingt dot org  2008-07-02 10:58 ---
Created an attachment (id=15843)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15843&action=view)
compressed preprocessed source


-- 


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

[Bug fortran/36681] compiler error message with gfortran 4.3.1 but not with 4.2.1

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-07-02 12:34 ---
I caused this.

Here's an obvious patch:

Index: iresolve.c
===
--- iresolve.c  (revision 137255)
+++ iresolve.c  (working copy)
@@ -106,7 +106,7 @@ resolve_mask_arg (gfc_expr *mask)
   /* In the library, we access the mask with a GFC_LOGICAL_1
 argument.  No need to waste memory if we are about to create
 a temporary array.  */
-  if (mask->expr_type == EXPR_OP)
+  if (mask->expr_type == EXPR_OP && mask->ts.kind != 1)
{
  ts.type = BT_LOGICAL;
  ts.kind = 1;


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-07-01 00:51:28 |2008-07-02 12:34:13
   date||


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

[Bug fortran/36590] internal error: Can't convert LOGICAL(1) to LOGICAL(1)

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-06-21 20:17:00 |2008-07-02 12:34:20
   date||


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

[Bug c++/36695] New: [4.4 Regression] Value-initialization of reference type is allowed.

[chris dot fairles at gmail dot com]

int main() { typedef int& T; T a = T(); }

Compiling the snippet above produces no diagnostic with gcc 4.4.0 20080701 or
gcc 4.1.2. However, reading n2691, 8.5 paragraph 6:

A program that calls for default-initialization or value-initialization of an
entity of reference type is ill-formed.

I'm pretty sure there's a similar statement in the current std.

Comeau seems to issue a diagnostic for the same snippet:
"ComeauTest.c", line 1: error: invalid type conversion
  int main() { typedef int& T; T a = T(); }


-- 
   Summary: [4.4 Regression] Value-initialization of reference type
is allowed.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot fairles at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/36681] compiler error message with gfortran 4.3.1 but not with 4.2.1

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-07-02 14:20 
---
OK to commit after testing.


-- 


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

[Bug c++/36696] New: Default constructor instance definition with empty argument list quietly ignored

[mike dot allen at facsim dot org]

Compile following with -Wall:

#include 

class Raii
{
public:
Raii () throw ()
{
std::cout << "Raii::Raii () called..." << std::endl;
}
public:
~Raii () throw ()
{
std::cout << "Raii::~Raii () called..." << std:: endl;
}
};

int main (int /*argc*/, char** /*argv*/)
{
Raii raii ();
std::cout << "Inside main ()..." << std::endl;
return 0;
}

This compiles with no errors.  When the result is executed, you get the
following output:

Inside main ()...

And that's all.  The compiler quietly ignored the declaration of an Raii
instance with an empty argument list.  No warnings, no errors, nothing.

If the empty argument list is removed, that is, if you have:

#include 

class Raii
{
public:
Raii () throw ()
{
std::cout << "Raii::Raii () called..." << std::endl;
}
public:
~Raii () throw ()
{
std::cout << "Raii::~Raii () called..." << std:: endl;
}
};

int main (int /*argc*/, char** /*argv*/)
{
Raii raii;
std::cout << "Inside main ()..." << std::endl;
return 0;
}

Then you get the expected output:

Raii::Raii () called...
Inside main ()...
Raii::~Raii () called...

Is this correct behavior?

g++ -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)


-- 
   Summary: Default constructor instance definition with empty
argument list quietly ignored
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mike dot allen at facsim dot org
GCC target triplet: i486-linux-gnu


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

[Bug fortran/36689] PRINT and WRITE eat minus sign

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-07-02 14:27 
---
To debug this we will probably need to get remote ssh access to a machine like
this.  I can think of three possible causes of the problem at the moment.

1) The executable is accessing the wrong version of libgfortran. You might need
to set LD_LIBRARY_PATH.

2) The system has a broken printf or memory allocation.

3) Some sort of endianess or sizeof issue.  For example, in some places in the
gfortran runtime library, characters are stored in type int.  When moving bytes
around, an overwrite of the least signigicant byte may be happening.

Send me private email if you can give access to machine.


-- 


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

[Bug fortran/36681] compiler error message with gfortran 4.3.1 but not with 4.2.1

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2008-07-02 14:38 ---
Subject: Bug 36681

Author: tkoenig
Date: Wed Jul  2 14:36:58 2008
New Revision: 137355

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

PR fortran/36590
PR fortran/36681
* iresolve.c (resolve_mask_arg):  Don't convert mask to
kind=1 logical if it is of that type already.

2008-07-02  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/36590
PR fortran/36681
* gfortran.dg/count_mask_1.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/count_mask_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/iresolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36590] internal error: Can't convert LOGICAL(1) to LOGICAL(1)

[tkoenig at gcc dot gnu dot org]

--- Comment #7 from tkoenig at gcc dot gnu dot org  2008-07-02 14:38 ---
Subject: Bug 36590

Author: tkoenig
Date: Wed Jul  2 14:36:58 2008
New Revision: 137355

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

PR fortran/36590
PR fortran/36681
* iresolve.c (resolve_mask_arg):  Don't convert mask to
kind=1 logical if it is of that type already.

2008-07-02  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/36590
PR fortran/36681
* gfortran.dg/count_mask_1.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/count_mask_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/iresolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36689] PRINT and WRITE eat minus sign

[dennis dot wassel at googlemail dot com]

--- Comment #6 from dennis dot wassel at googlemail dot com  2008-07-02 
14:39 ---
(In reply to comment #5)

> 1) The executable is accessing the wrong version of libgfortran. You might 
> need to set LD_LIBRARY_PATH.

Nope, everything in order here, as far as I can tell:

isaac:/tmp$ ldd minus
libgfortran.so.3 =>
/usr/local/lang/lib/gcc/i386-pc-solaris2.11/4.3.1/libgfortran.so.3
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 =>
/usr/local/lang/lib/gcc/i386-pc-solaris2.11/4.3.1/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1

> 
> Send me private email if you can give access to machine.
> 

Aye, will see what I can do.


-- 


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

[Bug fortran/36590] internal error: Can't convert LOGICAL(1) to LOGICAL(1)

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2008-07-02 14:40 ---
Fixed.  Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/36681] compiler error message with gfortran 4.3.1 but not with 4.2.1

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2008-07-02 14:41 ---
Fixed.  Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/36696] Default constructor instance definition with empty argument list quietly ignored

[mike dot allen at facsim dot org]

--- Comment #1 from mike dot allen at facsim dot org  2008-07-02 14:41 
---
Is the line:

Raii raii();

being interpreted by the compiler as the declaration of a function that takes
no arguments and returns a Raii instance?


-- 


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

[Bug fortran/36632] OpenMP code with access to module variable causes Fortran compiler to crash

[wirawan0 at gmail dot com]

--- Comment #3 from wirawan0 at gmail dot com  2008-07-02 14:43 ---
This problem also occurs with gfortran 4.3.1.


-- 


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

[Bug fortran/36689] PRINT and WRITE eat minus sign

[dennis dot wassel at googlemail dot com]

--- Comment #7 from dennis dot wassel at googlemail dot com  2008-07-02 
15:00 ---
(In reply to comment #5)
>
> 2) The system has a broken printf or memory allocation.
>

printf seems to be fine. If I compile and link this snippet of C

#include 
void cprint_(float *x) {
  printf("with printf X = %12.8f\n", *x);
}

into my Fortran code

PROGRAM Minus

  implicit none
  real :: XP

  XP = +1.23
  print *, "pos X = ", XP
  call cprint(xp)

  XP = -1.23
  print *, "neg X = ", XP
  call cprint(xp)

  print *, "zero = ", XP+1.23

END PROGRAM Minus

the output is
 pos X =1.230
with printf X =   1.2302
 neg X =   1.2302
with printf X =  -1.2302
 zero =0.000


Ho-hum. Memory allocation? It's not even an array any more, could that still be
an issue?

Won't be able to give you access to that machine before tomorrow.


-- 


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

[Bug c/36697] New: SIGSEGV on program exit with gcc 4.3.1

[benny at ammitzboell-consult dot dk]

I get SIGSEGV when my C and C++ programs exits. I have tracked it down to the
__do_global_dtors_aux function. The newly added code under HIDDEN_DTOR_LIST_END
does not check if the function ptr from the list is 0 - which the old code
below does. On my platform (no-mmu ARM, uclibc, uclinux) at least there are
zero-pointers in that __DTOR_LIST__.

This patch solved the issue for me:

--- gcc-4.3.1.org/gcc/crtstuff.c2008-07-02 15:52:23.0 +0200
+++ gcc-4.3.1/gcc/crtstuff.c2008-07-02 17:03:35.0 +0200
@@ -298,6 +298,7 @@
 while (dtor_idx < max_idx)
   {
f = __DTOR_LIST__[++dtor_idx];
+   if (!f) break;
f ();
   }
   }


-- 
   Summary: SIGSEGV on program exit with gcc 4.3.1
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benny at ammitzboell-consult dot dk
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-linux-uclibc


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

[Bug target/36698] New: gcc.c-torture/compile/20001226-1.c exceeds SPU local store size with -O0

[uweigand at gcc dot gnu dot org]

The gcc.c-torture/compile/20001226-1.c test case, when compiled with -O0
on the spu-elf target, results in a single function that exceeds local store
size (256 KB) on the SPU.  This cannot run (cannot even be linked!); and 
because it is a single function, overlay support does not help either.

This PR is opened to document the XFAIL reason for that test case.
In the future, it is hoped that enhancements to overlay support (by
splitting up large functions into multiple sections) will enable this
test case to pass as well.


-- 
   Summary: gcc.c-torture/compile/20001226-1.c exceeds SPU local
store size with -O0
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: spu-unknown-elf


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

[Bug target/36698] gcc.c-torture/compile/20001226-1.c exceeds SPU local store size with -O0

[uweigand at gcc dot gnu dot org]

--- Comment #1 from uweigand at gcc dot gnu dot org  2008-07-02 15:57 
---
Subject: Bug 36698

Author: uweigand
Date: Wed Jul  2 15:56:31 2008
New Revision: 137367

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137367
Log:
PR target/36698
* gcc.c-torture/compile/20001226-1.c: XFAIL -O0 case on SPU.

* gcc.dg/pr27095.c: Provide target-specific regexp for SPU.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
trunk/gcc/testsuite/gcc.dg/pr27095.c


-- 


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

[Bug target/36698] gcc.c-torture/compile/20001226-1.c exceeds SPU local store size with -O0

[uweigand at gcc dot gnu dot org]

--- Comment #2 from uweigand at gcc dot gnu dot org  2008-07-02 15:59 
---
Subject: Bug 36698

Author: uweigand
Date: Wed Jul  2 15:58:09 2008
New Revision: 137368

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137368
Log:
PR target/36698
* gcc.c-torture/compile/20001226-1.c: XFAIL -O0 case on SPU.

* gcc.dg/pr27095.c: Provide target-specific regexp for SPU.

Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr27095.c


-- 


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

[Bug target/36669] Wrong versioning for __float128

[hjl at gcc dot gnu dot org]

--- Comment #22 from hjl at gcc dot gnu dot org  2008-07-02 16:00 ---
Subject: Bug 36669

Author: hjl
Date: Wed Jul  2 15:59:19 2008
New Revision: 137369

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

2008-07-02  H.J. Lu  <[EMAIL PROTECTED]>

PR target/36669
* config/libgcc-glibc.ver: Add %exclude.
* config/m32r/libgcc-glibc.ver: Likwise.
* config/s390/libgcc-glibc.ver: Likwise.
* config/sh/libgcc-glibc.ver: Likwise.
* config/sparc/libgcc-sparc-glibc.ver: Likwise.

* config/i386/libgcc-glibc.ver: New.

* config/i386/libgcc-x86_64-glibc.ver: Removed.

2008-07-02  H.J. Lu  <[EMAIL PROTECTED]>

* config.gcc: Remove i386/t-fprules-softfp64 soft-fp/t-softfp
from tmake_file from i[34567]86-*-darwin*, x86_64-*-darwin*,
i[34567]86-*-linux*, x86_64-*-linux*.  Add
i386/t-fprules-softfp and soft-fp/t-softfp to tmake_file for
i[34567]86-*-darwin*, x86_64-*-darwin*, i[34567]86-*-linux*,
x86_64-*-linux*.  Add i386/t-linux to tmake_file for
i[34567]86-*-linux*, x86_64-*-linux*.

* libgcc-std.ver: Add empty GCC_4.4.0.

* mkmap-symver.awk: Support multiple versions per symbol.

* config/i386/i386.c (ix86_init_builtins): Always define
__builtin_fabsq and __builtin_copysignq with fallbacks.
(ix86_expand_builtin): Emit normal call for __builtin_fabsq
and __builtin_copysignq if SSE2 isn't available.

* config/i386/linux.h (LIBGCC2_HAS_TF_MODE): Defined.
(LIBGCC2_TF_CEXT): Likwise.
(TF_SIZE): Likwise.

* config/i386/linux64.h (LIBGCC2_HAS_TF_MODE): Defined as 1.

* config/i386/sfp-machine.h: Moved to libgcc.

* config/i386/sfp-machine.h: New.
* config/i386/t-linux: Likwise.

* config/i386/t-darwin: Remove softfp_wrap_start and
softfp_wrap_end.
* config/i386/t-darwin64: Likewise.

* config/i386/t-fprules-softfp64: Renamed to ...
* config/i386/t-fprules-softfp: This.

* config/i386/t-linux64: Remove SHLIB_MAPFILES, softfp_wrap_start
and softfp_wrap_end.

libgcc/

2008-07-02  H.J. Lu  <[EMAIL PROTECTED]>

PR target/36669
* shared-object.mk ($(base)_s$(objext)): Add -DSHARED.

* config/i386/64/_divtc3-compat.c: New.
* config/i386/64/_multc3-compat.c: Likewise.
* config/i386/64/_powitf2-compat.c: Likewise.
* config/i386/64/eqtf2.c: Likewise.
* config/i386/64/getf2.c: Likewise.
* config/i386/64/letf2.c: Likewise.
* config/i386/64/t-fprules-softfp: Likewise.

2008-07-02  H.J. Lu  <[EMAIL PROTECTED]>

* config.host: Add i386/${host_address}/t-fprules-softfp to
tmake_file for i[34567]86-*-darwin*, x86_64-*-darwin*,
i[34567]86-*-linux*, x86_64-*-linux*. 

* configure.ac: Set host_address to 64 or 32 for x86.
* configure: Regenerated.

* Makefile.in (config.status): Also depend on
$(srcdir)/config.host.

* config/i386/32/t-fprules-softfp: New.
* config/i386/32/tf-signs.c: Likewise.

* config/i386/64/sfp-machine.h: New. Moved from gcc.

2008-07-02  H.J. Lu  <[EMAIL PROTECTED]>
Uros Bizjak  <[EMAIL PROTECTED]>

* config/i386/32/sfp-machine.h: New.

Added:
trunk/gcc/config/i386/libgcc-glibc.ver
trunk/gcc/config/i386/t-fprules-softfp
trunk/gcc/config/i386/t-linux
trunk/libgcc/config/i386/32/
trunk/libgcc/config/i386/32/sfp-machine.h
trunk/libgcc/config/i386/32/t-fprules-softfp
trunk/libgcc/config/i386/32/tf-signs.c
trunk/libgcc/config/i386/64/
trunk/libgcc/config/i386/64/_divtc3-compat.c
trunk/libgcc/config/i386/64/_multc3-compat.c
trunk/libgcc/config/i386/64/_powitf2-compat.c
trunk/libgcc/config/i386/64/eqtf2.c
trunk/libgcc/config/i386/64/getf2.c
trunk/libgcc/config/i386/64/letf2.c
trunk/libgcc/config/i386/64/sfp-machine.h
trunk/libgcc/config/i386/64/t-fprules-softfp
Removed:
trunk/gcc/config/i386/libgcc-x86_64-glibc.ver
trunk/gcc/config/i386/t-fprules-softfp64
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/linux.h
trunk/gcc/config/i386/linux64.h
trunk/gcc/config/i386/sfp-machine.h
trunk/gcc/config/i386/t-darwin
trunk/gcc/config/i386/t-darwin64
trunk/gcc/config/i386/t-linux64
trunk/gcc/config/libgcc-glibc.ver
trunk/gcc/config/m32r/libgcc-glibc.ver
trunk/gcc/config/s390/libgcc-glibc.ver
trunk/gcc/config/sh/libgcc-glibc.ver
trunk/gcc/config/sparc/libgcc-sparc-glibc.ver
trunk/gcc/libgcc-std.ver
trunk/gcc/mkmap-symver.awk
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in
trunk/libgcc/config.host
trunk/libgcc/configure
trunk/libgcc/configure.ac
trunk/libgcc/shared-object.mk


-- 


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

[Bug target/36622] 4.3.1 failed to compile gcse.c file.

[rwild at gcc dot gnu dot org]

--- Comment #19 from rwild at gcc dot gnu dot org  2008-07-02 16:11 ---
(In reply to comment #7)
> > >So, you are suggesting that I should remove fPIC option, correct?
> > Yes.  Is there a reason why you have CFLAGS set anyways?

> 2.  -fPIC has always been set in all the other gcc versions that I have
> compiled through CFLAGS.  So, I did not think about this issue until you
> pointed it out.

This does not explain _why_ you used -fPIC in the first place.
IOW, why did you ever start using -fPIC?

We could just recommend to you not to use -fPIC in the CFLAGS
for configuring GCC.  But from the PR history it is not clear whether
you had a good reason to use it in the first place, thus it is difficult
to know what you may be working around here for.

> Do I need to exclude -fPIC for the other platform (e.g. x86_64) builds when I
> build gcc 4.3.1?  I have tried building 4.3.1 in SLES10 with -fPIC option , 
> and
> it built OK for me.

That may well be.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org


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

[Bug c++/36694] g++-4.2 rejects code, that other versions of gcc accept

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2008-07-02 16:12 ---
Please post the compile command and the error.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org


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

[Bug c++/36694] g++-4.2 rejects code, that other versions of gcc accept

[tim at klingt dot org]

--- Comment #3 from tim at klingt dot org  2008-07-02 16:15 ---
compiled via:
g++-4.2 server_dsp_thread_test.ii 

error message:
libs/boost/boost/concept_check.hpp: In instantiation of
‘boost::CopyConstructible::dummy_runnable>*>’:
libs/boost/boost/concept_check.hpp:154:   instantiated from
‘boost::CopyConstructibleConcept::dummy_runnable>*>’
libs/boost/boost/concept/detail/has_constraints.hpp:40:   instantiated from
‘const bool
boost::concept::not_satisfied::dummy_runnable>*>
>::value’
libs/boost/boost/concept/detail/has_constraints.hpp:43:   instantiated from
‘boost::concept::not_satisfied::dummy_runnable>*>
>’
libs/boost/boost/mpl/if.hpp:67:   instantiated from
‘boost::mpl::if_::dummy_runnable>*>
>,
boost::concept::constraint::dummy_runnable>*>
>,
boost::concept::requirement::dummy_runnable>*>
> >’
libs/boost/boost/concept/detail/general.hpp:19:   instantiated from
‘boost::concept::requirement_::dummy_runnable>*>)>’
libs/lockfree/fifo.hpp:60:   instantiated from
‘lockfree::detail::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’
libs/lockfree/fifo.hpp:272:   instantiated from
‘lockfree::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’
testsuite/../source/server/dsp_thread_queue.hpp:315:   instantiated from
‘nova::dsp_queue_interpreter<::dummy_runnable>’
testsuite/../source/server/dsp_thread.hpp:87:   instantiated from
‘nova::dsp_threads<::dummy_runnable>’
testsuite/server_dsp_thread_test.cpp:32:   instantiated from here
libs/boost/boost/concept_check.hpp:156: error:
‘boost::concept::requirement::failed [with Model =
boost::concept::usage_requirements::dummy_runnable>*>
>]’ is not a valid template argument for type ‘void (*)()’ because
function ‘static void boost::concept::requirement::failed() [with
Model =
boost::concept::usage_requirements::dummy_runnable>*>
>]’ has not external linkage
libs/lockfree/fifo.hpp: In instantiation of
‘lockfree::detail::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’:
libs/lockfree/fifo.hpp:272:   instantiated from
‘lockfree::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’
testsuite/../source/server/dsp_thread_queue.hpp:315:   instantiated from
‘nova::dsp_queue_interpreter<::dummy_runnable>’
testsuite/../source/server/dsp_thread.hpp:87:   instantiated from
‘nova::dsp_threads<::dummy_runnable>’
testsuite/server_dsp_thread_test.cpp:32:   instantiated from here
libs/lockfree/fifo.hpp:60: error: ‘boost::concept::requirement::failed
[with Model =
boost::CopyConstructibleConcept::dummy_runnable>*>]’
is not a valid template argument for type ‘void (*)()’ because function
‘static void boost::concept::requirement::failed() [with Model =
boost::CopyConstructibleConcept::dummy_runnable>*>]’
has not external linkage
libs/boost/boost/concept_check.hpp: In instantiation of
‘boost::DefaultConstructible::dummy_runnable>*>’:
libs/boost/boost/concept_check.hpp:127:   instantiated from
‘boost::DefaultConstructibleConcept::dummy_runnable>*>’
libs/boost/boost/concept/detail/has_constraints.hpp:40:   instantiated from
‘const bool
boost::concept::not_satisfied::dummy_runnable>*>
>::value’
libs/boost/boost/concept/detail/has_constraints.hpp:43:   instantiated from
‘boost::concept::not_satisfied::dummy_runnable>*>
>’
libs/boost/boost/mpl/if.hpp:67:   instantiated from
‘boost::mpl::if_::dummy_runnable>*>
>,
boost::concept::constraint::dummy_runnable>*>
>,
boost::concept::requirement::dummy_runnable>*>
> >’
libs/boost/boost/concept/detail/general.hpp:19:   instantiated from
‘boost::concept::requirement_::dummy_runnable>*>)>’
libs/lockfree/fifo.hpp:61:   instantiated from
‘lockfree::detail::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’
libs/lockfree/fifo.hpp:272:   instantiated from
‘lockfree::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’
testsuite/../source/server/dsp_thread_queue.hpp:315:   instantiated from
‘nova::dsp_queue_interpreter<::dummy_runnable>’
testsuite/../source/server/dsp_thread.hpp:87:   instantiated from
‘nova::dsp_threads<::dummy_runnable>’
testsuite/server_dsp_thread_test.cpp:32:   instantiated from here
libs/boost/boost/concept_check.hpp:129: error:
‘boost::concept::requirement::failed [with Model =
boost::concept::usage_requirements::dummy_runnable>*>
>]’ is not a valid template argument for type ‘void (*)()’ because
function ‘static void boost::concept::requirement::failed() [with
Model =
boost::concept::usage_requirements::dummy_runnable>*>
>]’ has not external linkage
libs/lockfree/fifo.hpp: In instantiation of
‘lockfree::detail::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’:
libs/lockfree/fifo.hpp:272:   instantiated from
‘lockfree::fifo::dummy_runnable>*,
false, 1024u,
std::allocator::dummy_runnable>*> >’
testsuite/../source/server/dsp_t

[Bug target/36622] 4.3.1 failed to compile gcse.c file.

[imam dot toufique at intel dot com]

--- Comment #20 from imam dot toufique at intel dot com  2008-07-02 16:17 
---
(In reply to comment #19)
> (In reply to comment #7)
> > > >So, you are suggesting that I should remove fPIC option, correct?
> > > Yes.  Is there a reason why you have CFLAGS set anyways?
> > 2.  -fPIC has always been set in all the other gcc versions that I have
> > compiled through CFLAGS.  So, I did not think about this issue until you
> > pointed it out.
> This does not explain _why_ you used -fPIC in the first place.
> IOW, why did you ever start using -fPIC?
> We could just recommend to you not to use -fPIC in the CFLAGS
> for configuring GCC.  But from the PR history it is not clear whether
> you had a good reason to use it in the first place, thus it is difficult
> to know what you may be working around here for.
> > Do I need to exclude -fPIC for the other platform (e.g. x86_64) builds when 
> > I
> > build gcc 4.3.1?  I have tried building 4.3.1 in SLES10 with -fPIC option , 
> > and
> > it built OK for me.
> That may well be.

well... when libstdc and other shared libs are built, are they all built
position independent? the whole idea here to make sure that we must build
position independent libstdc.so and other shared libs.  

Moreover, I have tested with the -fPIC options in 4.3.2 pre-release and the
build works OK.

also, I am getting an error from 'ld' that it can't find symbol '-lc'  .  I am
not sure if this gcc related or binutils related.  any ideas?  Please see
comment #18 for more info.

thanks


-- 


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

[Bug c++/36699] New: not compile code, but must

[yeolahim at gmail dot com]

try compile:

#include 

template 
inline
size_t countof ( const T (&) [Count] )
{
  return Count;
}

int main(int argc, char* argv[])
{
  struct { int x1; int x2;} x [100];
  std::cout << countof(x) << std::endl;

  int y [101];
  std::cout << countof(y) << std::endl;

  struct Z { int x1; int x2;} z [102];
  std::cout << countof(z) << std::endl;

  std::cin.get();
  return 0;
}


gcc info(gcc -v):
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)


-- 
   Summary: not compile code, but must
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yeolahim at gmail dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug target/36622] 4.3.1 failed to compile gcse.c file.

[Ralf dot Wildenhues at gmx dot de]

--- Comment #21 from Ralf dot Wildenhues at gmx dot de  2008-07-02 16:46 
---
Subject: Re:  4.3.1 failed to compile gcse.c file.

* imam dot toufique at intel dot com wrote on Wed, Jul 02, 2008 at 06:17:59PM
CEST:
> well... when libstdc and other shared libs are built, are they all built
> position independent?

Yes.

> the whole idea here to make sure that we must build
> position independent libstdc.so and other shared libs.  

But you need not take care of that.  It's done without you passing
-fPIC.  The build machinery will do that for those objects that end up
in shared libraries.

> Moreover, I have tested with the -fPIC options in 4.3.2 pre-release and the
> build works OK.

That doesn't make it recommended practice.

> also, I am getting an error from 'ld' that it can't find symbol '-lc'  .  I am
> not sure if this gcc related or binutils related.  any ideas?  Please see
> comment #18 for more info.

I assume that is an independent issue.  But still you should first try
to build without -fPIC.

Cheers,
Ralf


-- 


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

[Bug fortran/36700] New: ICE on calling a function

[terry at chem dot gu dot se]

I mistakenly called a function, and broke the compiler:

[EMAIL PROTECTED] ~/MD]$ cat diatoms.f90
module Diatoms
implicit none

contains

function InitialDiatomicX() result (v4)
real(kind=8),dimension(4)::v4
v4=1
end function InitialDiatomicX

subroutine FindDiatomicPeriod
call InitialDiatomicX()
end subroutine FindDiatomicPeriod

end module Diatoms

[EMAIL PROTECTED] ~/MD]$ gfortran -c diatoms.f90
diatoms.f90: In function ‘finddiatomicperiod’:
diatoms.f90:6: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2637
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[EMAIL PROTECTED] ~/MD]$ gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.1/configure --disable-multilib
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.1 (GCC)


-- 
   Summary: ICE on calling a function
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug target/36701] New: [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c

[hjl dot tools at gmail dot com]

Revision 137328 generates unaligned access in

gcc.c-torture/execute/complex-7.c

and revision 137304 is OK. Steve, will your patch

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00884.html

cause this? Thanks.


-- 
   Summary: [4.4 Regression] unaligned access in gcc.c-
torture/execute/complex-7.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c

[sje at cup dot hp dot com]

--- Comment #1 from sje at cup dot hp dot com  2008-07-02 17:17 ---
I don't see any reason why my patch would cause this problem.  Looking through
my old test logs I see this test failing before my patch as well as after it. 
The failures go back to version 126651 which is the oldest results file I have
sitting around.


-- 


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

[Bug bootstrap/36702] New: [4.4 Regression] Bootstrap fails at revision 137369 on i686-apple-darwin9

[dominiq at lps dot ens dot fr]

Bootstrap fails at revision 137369 on i686-apple-darwin9 with:

...
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -g -O2 -O2  -g -O2 -DIN_GCC  
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I../../../gcc-4.4-work/libgcc -I../../../gcc-4.4-work/libgcc/.
-I../../../gcc-4.4-work/libgcc/../gcc -I../../../gcc-4.4-work/libgcc/../include
 -DHAVE_CC_TLS -o _floattitf.o -MT _floattitf.o -MD -MP -MF _floattitf.dep
-DL_floatditf -c ../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS \
-DLIBGCC2_UNITS_PER_WORD=8
{standard input}:31:Unknown pseudo-op: .symver
{standard input}:31:Rest of line ignored. 1st junk character valued 95 (_).
{standard input}:32:Unknown pseudo-op: .symver
{standard input}:32:Rest of line ignored. 1st junk character valued 95 (_).
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -g -O2 -O2  -g -O2 -DIN_GCC  
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I../../../gcc-4.4-work/libgcc -I../../../gcc-4.4-work/libgcc/.
-I../../../gcc-4.4-work/libgcc/../gcc -I../../../gcc-4.4-work/libgcc/../include
 -DHAVE_CC_TLS -o _floatuntisf.o -MT _floatuntisf.o -MD -MP -MF
_floatuntisf.dep -DL_floatundisf -c
../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS \
-DLIBGCC2_UNITS_PER_WORD=8
make[5]: *** [getf2_s.o] Error 1
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[3]: *** Waiting for unfinished jobs
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2


-- 
   Summary: [4.4 Regression] Bootstrap fails at revision 137369 on
i686-apple-darwin9
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug bootstrap/36702] [4.4 Regression] Bootstrap fails at revision 137369 on i686-apple-darwin9

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-07-02 17:49 ---
Can you try

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00127.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||07/msg00127.html


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

[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-07-02 18:10 ---
With gfortran 4.1 and 4.2:

Error: FUNCTION attribute conflicts with SUBROUTINE attribute in
'initialdiatomicx' at (1)

The same error is also shown for the following - also 4.3/4.4 do so:
  print *, foo()
  call foo()
  end

If one changes the order between call and function declaration, one gets the
following error message:
"Error: 'initialdiatomicx' at (1) has a type, which is not consistent with the
CALL at (2)"


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-02 18:10:59
   date||
Summary|ICE on calling a function   |[4.3/4.4 Regression] ICE on
   ||calling a function


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

[Bug bootstrap/36702] [4.4 Regression] Bootstrap fails at revision 137369 on i686-apple-darwin9

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2008-07-02 19:32 ---
Subject: Bug 36702

Author: hjl
Date: Wed Jul  2 19:31:53 2008
New Revision: 137380

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137380
Log:
2008-07-02  H.J. Lu  <[EMAIL PROTECTED]>

PR boostrap/36702
* config.host: Only include 32bit t-fprules-softfp for Darwin/x86
and Linux/x86.  Include 64bit t-softfp-compat for Linux/x86.

* config/i386/64/t-fprules-softfp: Moved to ...
* config/i386/64/t-softfp-compat: This.  New.

Added:
trunk/libgcc/config/i386/64/t-softfp-compat
  - copied unchanged from r137369,
trunk/libgcc/config/i386/64/t-fprules-softfp
Removed:
trunk/libgcc/config/i386/64/t-fprules-softfp
Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.host


-- 


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

[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers

[janus at gcc dot gnu dot org]

--- Comment #12 from janus at gcc dot gnu dot org  2008-07-02 19:54 ---
Subject: Bug 32580

Author: janus
Date: Wed Jul  2 19:53:37 2008
New Revision: 137386

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137386
Log:
2008-07-02  Janus Weil  <[EMAIL PROTECTED]>
Tobias Burnus  <[EMAIL PROTECTED]>
Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/32580
* gfortran.h (struct gfc_symbol): New member "proc_pointer".
* check.c (gfc_check_associated,gfc_check_null): Implement
procedure pointers.
* decl.c (match_procedure_decl): Ditto.
* expr.c (gfc_check_pointer_assign,gfc_check_assign_symbol): Ditto.
* interface.c (compare_actual_formal): Ditto.
* match.h: Ditto.
* match.c (gfc_match_pointer_assignment): Ditto.
* parse.c (parse_interface): Ditto.
* primary.c (gfc_match_rvalue,match_variable): Ditto.
* resolve.c (resolve_fl_procedure): Ditto.
* symbol.c (check_conflict,gfc_add_external,gfc_add_pointer,
gfc_copy_attr,gen_fptr_param,build_formal_args): Ditto.
* trans-decl.c (get_proc_pointer_decl,gfc_get_extern_function_decl,
create_function_arglist): Ditto.
* trans-expr.c (gfc_conv_variable,gfc_conv_function_val,
gfc_conv_function_call,gfc_trans_pointer_assignment): Ditto.


2008-07-02  Janus Weil  <[EMAIL PROTECTED]>
Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/32580
* gfortran.dg/c_f_pointer_tests_3.f90: Updated.
* gfortran.dg/proc_decl_1.f90: Updated.
* gfortran.dg/proc_ptr_1.f90: New.
* gfortran.dg/proc_ptr_2.f90: New.
* gfortran.dg/proc_ptr_3.f90: New.
* gfortran.dg/proc_ptr_4.f90: New.
* gfortran.dg/proc_ptr_5.f90: New.
* gfortran.dg/proc_ptr_6.f90: New.
* gfortran.dg/proc_ptr_7.f90: New.
* gfortran.dg/proc_ptr_8.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_1.f90   (with props)
trunk/gcc/testsuite/gfortran.dg/proc_ptr_2.f90   (with props)
trunk/gcc/testsuite/gfortran.dg/proc_ptr_3.f90   (with props)
trunk/gcc/testsuite/gfortran.dg/proc_ptr_4.f90   (with props)
trunk/gcc/testsuite/gfortran.dg/proc_ptr_5.f90   (with props)
trunk/gcc/testsuite/gfortran.dg/proc_ptr_6.f90   (with props)
trunk/gcc/testsuite/gfortran.dg/proc_ptr_7.c
trunk/gcc/testsuite/gfortran.dg/proc_ptr_7.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_8.c
trunk/gcc/testsuite/gfortran.dg/proc_ptr_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/match.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_1.f90

Propchange: trunk/gcc/testsuite/gfortran.dg/proc_ptr_1.f90
('svn:executable' added)

Propchange: trunk/gcc/testsuite/gfortran.dg/proc_ptr_2.f90
('svn:executable' added)

Propchange: trunk/gcc/testsuite/gfortran.dg/proc_ptr_3.f90
('svn:executable' added)

Propchange: trunk/gcc/testsuite/gfortran.dg/proc_ptr_4.f90
('svn:executable' added)

Propchange: trunk/gcc/testsuite/gfortran.dg/proc_ptr_5.f90
('svn:executable' added)

Propchange: trunk/gcc/testsuite/gfortran.dg/proc_ptr_6.f90
('svn:executable' added)


-- 


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

[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers

[janus at gcc dot gnu dot org]

--- Comment #13 from janus at gcc dot gnu dot org  2008-07-02 20:19 ---
Fixed with rev 137386. Btw I have also tried compiling the whole CP2K, which
seems to work fine.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-07-02 14:57:40 |2008-07-02 20:19:25
   date||


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

[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers

[janus at gcc dot gnu dot org]

--- Comment #14 from janus at gcc dot gnu dot org  2008-07-02 20:19 ---
Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2008-07-02 20:20 
---
> The fix would be to not propagate the comparisons if they can throw.

OK, thanks for the tip.  The patch to convert Ada to a canonical boolean type
is written though (and eliminates the ICE as expected), I'm just waiting for
the GDB people to adjust the Ada module.


-- 


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

[Bug fortran/36703] New: ICE (segfault) in reduce_binary0 (arith.c:1778)

[burnus at gcc dot gnu dot org]

http://groups.google.com/group/comp.lang.fortran/msg/b600c081a3654936
compiling attached program causes a segfault.

$ gfortran -c -fcray-pointer aaa.f90
aaa.f90: In function 'fptr':
aaa.f90:89: internal compiler error: Segmentation fault


==4019== Invalid read of size 4
==4019==at 0x40327E: reduce_binary0 (arith.c:1778)
==4019==by 0x40407E: eval_intrinsic_f3 (arith.c:1841)
==4019==by 0x4AA386: gfc_apply_interface_mapping_to_expr
(trans-expr.c:1815)
==4019==by 0x4B157E: gfc_apply_interface_mapping (trans-expr.c:1991)
==4019==by 0x4AB839: gfc_conv_function_call (trans-expr.c:2669)
==4019==by 0x4AC6CB: gfc_conv_function_expr (trans-expr.c:3201)
==4019==by 0x496DB7: gfc_add_loop_ss_code (trans-array.c:1977)
==4019==by 0x497980: gfc_conv_loop_setup (trans-array.c:3496)
==4019==by 0x4BBB6E: gfc_trans_transfer (trans-io.c:2216)
==4019==by 0x48C5C7: gfc_trans_code (trans.c:1118)
==4019==by 0x4BEC48: build_dt (trans-io.c:1805)
==4019==by 0x48C5F7: gfc_trans_code (trans.c:1090)


-- 
   Summary: ICE  (segfault) in reduce_binary0  (arith.c:1778)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  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=36703

[Bug fortran/36703] ICE (segfault) in reduce_binary0 (arith.c:1778)

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-07-02 20:26 ---
Created an attachment (id=15844)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15844&action=view)
Test case


-- 


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

[Bug fortran/36704] New: Procedure pointer as function result

[burnus at gcc dot gnu dot org]

Remaining item since PR 32580 has been fixed.

Procedure pointers as function result are not yet implemented and currently
rejected.

Short example:

function foo() result(bar)
  procedure() :: bar

and

function foo()
  procedure() :: foo

Long example:
http://groups.google.com/group/comp.lang.fortran/msg/7bddd7097fb985a5


-- 
   Summary: Procedure pointer as function result
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  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=36704

[Bug fortran/36705] New: Procedure pointers with attributes statements

[burnus at gcc dot gnu dot org]

save :: p
procedure() :: p
pointer :: p
end

Error: PROCEDURE attribute conflicts with SAVE attribute in 'p' at (1)

Problem: The SAVE + PROCEDURE checking comes too early before the POINTER is
seen. I think this program is valid.

Analogously:

subroutine bar(x)
 procedure(), intent(in) :: x
 pointer :: x
end subroutine bar 

Here, the POINTER comes too late for INTENT


-- 
   Summary: Procedure pointers with attributes statements
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  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=36705

[Bug middle-end/30141] nested function can produce invalid gimple

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-07-02 20:52 ---
I cannot find my patch any more so unassigning.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pinskia 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=30141

[Bug c++/36696] Default constructor instance definition with empty argument list quietly ignored

[dseketel at redhat dot com]

--- Comment #2 from dseketel at redhat dot com  2008-07-02 21:09 ---
Yes, foo bar (); is indeed the declaration of a function bar of type foo that
takes no arguments in parameter.

I believe gcc is right there.


-- 

dseketel at redhat dot com changed:

   What|Removed |Added

 CC||dseketel at redhat dot com


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

[Bug c++/36696] Default constructor instance definition with empty argument list quietly ignored

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-02 21:16 ---
This is an ambiguous in the C++ standard that is resolved via making it a
function declaration.
That is:
Raii raii ();

Is declaring a function, raii, that returns a Raii type.


-- 

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

[Bug c++/13101] incorrect warning on initialized extern const function pointer

[dseketel at redhat dot com]

--- Comment #2 from dseketel at redhat dot com  2008-07-02 22:19 ---
Hello,

I have sent a patch to the list at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00160.html.

Hopefully that patch should fix this issue.


-- 

dseketel at redhat dot com changed:

   What|Removed |Added

 CC||dseketel at redhat dot com


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

[Bug testsuite/36285] gcc.dg/compat/struct-by-value-xxx improper test for AVR target

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #4 from hutchinsonandy at gcc dot gnu dot org  2008-07-02 22:32 
---
Subject: Bug 36285

Author: hutchinsonandy
Date: Wed Jul  2 22:31:11 2008
New Revision: 137396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137396
Log:
PR testsuite/36285
* gcc.dg/compat/struct-by-value-16_x.c: Move some tests to new file to reduce
code size.
* gcc.dg/compat/struct-by-value-16_y.c: Ditto.
* gcc.dg/compat/struct-by-value-16a_main.c: New file.
* gcc.dg/compat/struct-by-value-16a_x.c: Ditto.
* gcc.dg/compat/struct-by-value-16a_y.c: Ditto.
* gcc.dg/compat/struct-by-value-17_x.c: Move some tests to new file to reduce
code size.
* gcc.dg/compat/struct-by-value-17_y.c: Ditto.
* gcc.dg/compat/struct-by-value-17a_main.c: New file.
* gcc.dg/compat/struct-by-value-17a_x.c: Ditto.
* gcc.dg/compat/struct-by-value-17a_y.c: Ditto.
* gcc.dg/compat/struct-by-value-18_x.c: Move some tests to new file to reduce
code size.
* gcc.dg/compat/struct-by-value-18_y.c: Ditto.
* gcc.dg/compat/struct-by-value-18a_main.c: New file.
* gcc.dg/compat/struct-by-value-18a_x.c: Ditto.
* gcc.dg/compat/struct-by-value-18a_y.c: Ditto.

Added:
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-16a_main.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-16a_x.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-16a_y.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-17a_main.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-17a_x.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-17a_y.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-18a_main.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-18a_x.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-18a_y.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-16_x.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-16_y.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-17_x.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-17_y.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-18_x.c
trunk/gcc/testsuite/gcc.dg/compat/struct-by-value-18_y.c


-- 


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

[Bug c/36706] New: [Regression] linux-kernel 2.6.24 doesn't boot for arm

[chris dot steel dot lnx at googlemail dot com]

I've built linux-2.6.24 for arm using gcc-4.3.1 and while it builds fine, the
resulting binary doesn't boot on qemu. If I build the same kernel with
gcc-4.2.4 it boots correctly.

The problem seems to be that the prefetch function
(linux-2.6.24/include/asm-arm/processor.h) causes a crash if it is called with
a NULL pointer argument. But only if it's compiled with gcc-4.3.x.

This patch fixes the problem, but the extra code may cost more than you gain by
having prefetch in the first place

diff -urN linux-2.6.24-clean/include/asm-arm/processor.h
linux-2.6.24/include/asm-arm/processor.h
--- linux-2.6.24-clean/include/asm-arm/processor.h  2008-01-24
22:58:37.0 +
+++ linux-2.6.24/include/asm-arm/processor.h2008-07-02 22:44:26.052525328
+0100
@@ -105,11 +105,14 @@
 #define ARCH_HAS_PREFETCH
 static inline void prefetch(const void *ptr)
 {
-   __asm__ __volatile__(
-   "pld\t%0"
-   :
-   : "o" (*(char *)ptr)
-   : "cc");
+   if (ptr)
+   {
+   __asm__ __volatile__(
+   "pld\t%0"
+   :
+   : "o" (*(char *)ptr)
+   : "cc");
+   }
 }

 #define ARCH_HAS_PREFETCHW


-- 
   Summary: [Regression] linux-kernel 2.6.24 doesn't boot for arm
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot steel dot lnx at googlemail dot com
 GCC build triplet: x86_64-cross-linux-gnu
  GCC host triplet: x86_64-cross-linux-gnu
GCC target triplet: arm-unknown-linux-gnueabi


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

[Bug c/36706] [Regression] linux-kernel 2.6.24 doesn't boot for arm

[chris dot steel dot lnx at googlemail dot com]

--- Comment #1 from chris dot steel dot lnx at googlemail dot com  
2008-07-02 22:36 ---
Created an attachment (id=15845)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15845&action=view)
kernel config to reproduce the problem


-- 


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

[Bug c/36706] [Regression] linux-kernel 2.6.24 doesn't boot for arm

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-07-02 22:44 ---
The use of "o" is most likely wrong here and most likely not a GCC issue as you
are saying you access the memory when in reality you don't.


-- 


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

[Bug inline-asm/36706] [Regression] linux-kernel 2.6.24 doesn't boot for arm

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-02 22:46 ---
Yes o is wrong here.  THis is not a GCC bug.


-- 

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

[Bug inline-asm/36706] [Regression] linux-kernel 2.6.24 doesn't boot for arm

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-07-02 22:47 ---
"o" means any offsetable memory operand so GCC thinks you are accessing memory
that will always be valid.


-- 


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

[Bug c++/36707] New: ICE in build_modify_expr on rvalue reference function template

[sebor at roguewave dot com]

I haven't found anything about this in Bugzilla or tried 4.3.1:

$ cat t.cpp && g++ -std=gnu++0x t.cpp
template  void foo (T&& x) { x = T (); }

int main () {
int i;
foo (i);
}
t.cpp: In function ‘void foo(T&&) [with T = int&]’:
t.cpp:5:   instantiated from here
t.cpp:1: internal compiler error: in build_modify_expr, at cp/typeck.c:5821
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in build_modify_expr on rvalue reference function
template
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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

[Bug c++/9937] [DR 176] Base class template name is not injected properly into derived class

[widman at gimpel dot com]

--- Comment #7 from widman at gimpel dot com  2008-07-03 01:40 ---
(In reply to comment #3)

Hi all,

I happen to be looking at something related to this issue and encountered this
GCC bug, so I thought I'd offer my observations.

>  [EMAIL PROTECTED] wrote:

>  | Something seems indeed inconsistent. Your access in struct Z
>  | is bogus, but this is an extract:
>  
>  I don't think so.
>  
>  ~From ISO/IEC 14882
>  
>  14.6/2a
>  
>  "The injected-class-name of a class template or class template
>  specialization can be used either with or without
>  a template-argument-list wherever it is in scope. [Example:
>  
>  template  struct Base {
>  ~  Base* p;
>  };
>  
>  template  struct Derived: public Base {
>  ~  typename Derived::Base* p; // meaning Derived::Base
>  };
>   end example ]"
>  
>  So if B is in scope B is as well.

True.  I think ISO/IEC 14882:2003, 14.6.1 [temp.local] indicates pretty clearly
what's supposed to happen here:  within Y and Z, 'B' is in scope as the
injected-class-name of the base class.  But that injected-class-name is only
taken as a template-name if it's immediately followed by the '<' token;
otherwise it's an alias to the class of which it's a member.

For what it's worth, I can confirm that the EDG front end appears to have had
this correctly implemented for many years now in "strict mode" (that is, the
mode where they don't try to emulate anyone's bugs).

I ran into this bug with the following test case:

template  
struct B  {
static void j();
};

namespace N {
template  
struct B { 
static void j();
}; 

}

template  
struct A : public N::B { 
static void f1 ( ) { 
A::template B::j(); // ok 
A::B::j(); // ok
} 
static void f2 ( ) { 
B::j(); // ok
} 
}; 


void h() {
A::f1(); // calls ::N::B::j() twice
A::f2(); // calls ::B::j() once
}

With this I currently get:

g++-mp-4.4 (GCC) 4.4.0 20080620 (experimental)
g2.cpp: In static member function 'static void A::f1() [with T = int]':
g2.cpp:27:   instantiated from here
g2.cpp:17: error: no class template named 'B' in 'struct A'
g2.cpp:18: error: no type named 'B' in 'struct A'


-- 

widman at gimpel dot com changed:

   What|Removed |Added

 CC||widman at gimpel dot com


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

[Bug c/36708] New: syntatic warning

[robert dot lore at opensyscon dot com dot au]

I think this code is syntactically correct, but can cause problems in
debugging. If you don't scrutinize the code too carefully you can waste time
here - code was a cut and paste from strcpy to integer assignment with
resultant comma not changed to assignment.

 // this code does nothing !
 f -> font_size, current_font_size;

 // this code does something
 f -> font_size= current_font_size;

should this produce a warning like "statement does nothing" ? its like an
unused variable warning, it is a courtesy thing..


-- 
   Summary: syntatic warning
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: robert dot lore at opensyscon dot com dot au
 GCC build triplet: same
  GCC host triplet: x86 linux (redhat) gcc
GCC target triplet: same


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

[Bug c++/36709] New: Compiler allows namespace and class to have same name and doesn't generate ambiguous reference error when it should result from this.

[rquabili at princeton dot edu]

Since J is already defined, the namespace declaration should generate an error
("int J; namespace J{}" does generate an error). G++ gets confused with the g()
call and instead of generating an error it passes the problem to the assembler.

main.cpp:
struct J {
static void g() {}
};
namespace J {
void g() {}
}
int main() {
J::g();
return 0;
}

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)


$ gcc main.cpp
/tmp/ccgibTUW.s: Assembler messages:
/tmp/ccgibTUW.s:25: Error: symbol `_ZN1J1gEs' is already defined


-- 
   Summary: Compiler allows namespace and class to have same name
and doesn't generate ambiguous reference error when it
should result from this.
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rquabili at princeton dot edu


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

[Bug c/36708] syntatic warning

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-03 02:50 ---
-Wunused-value should warn about this ...


-- 


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

[Bug middle-end/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2008-07-03 06:09 ---
(In reply to comment #8)

> current trunk (actually a few days old) doesn't fail anymore. The script used
> for testing actually has ulimit -s 128000 which is pretty high. I tested with
> ulimit -s 32000 and ulimit -s 64000, but couldn't get a crash.

Closed (again) as WORKSFORME.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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