[Bug fortran/39893] gfortran ICE on invalid program

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #5 from sgk at troutmask dot apl dot washington dot edu  
2009-04-26 03:29 ---
Subject: Re:  gfortran ICE on invalid program

On Sat, Apr 25, 2009 at 08:47:19PM -, kargl at gcc dot gnu dot org wrote:
> 
> 
> --- Comment #4 from kargl at gcc dot gnu dot org  2009-04-25 20:47 ---
> I have a patch.
> 


I've come up with 2 different patches.  Unfortunately,
both have a few regressions. :(


-- 


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

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2009-04-26 
01:35 ---
I forgot to add that the compiler is built as...

Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=x86_64-apple-darwin10
--host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
Thread model: posix
gcc version 4.4.0 (GCC) 

The issue isn't seen with the i686-apple-darwin9 target using -m64 so it seems
to be specific to the 64-bit native compiler when generating 64-bit code.


-- 


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

[Bug c++/39905] static downcast through protectedly inherited base class rejected

[fang at csl dot cornell dot edu]

--- Comment #2 from fang at csl dot cornell dot edu  2009-04-26 00:52 
---
Subject: Re:  static downcast through protectedly inherited
 base class rejected

> --- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-26 00:42 
> ---
> Comment #1 in Bug 12265, explains exactly why this code is invalid. 
> Protected base classes are non accessible in other clases besides in 
> derived and derived classes of derived.

Ok, I get it.  "not accessible to classes besides ..." excludes the 
base class itself.

I see your reflex time has not slowed, pinski.  :)

Fang


-- 


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

[Bug c++/39905] static downcast through protectedly inherited base class rejected

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-26 00:42 ---
Comment #1 in Bug 12265, explains exactly why this code is invalid.  Protected
base classes are non accessible in other clases besides in  derived and derived
classes of derived.


-- 

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

[Bug c++/39905] New: static downcast through protectedly inherited base class rejected

[fang at csl dot cornell dot edu]

The following test case was accepted in g++-4.3.x and earlier, but rejected by
4.4.0.  
Code is possibly invalid, can any standard-fluent experts comment?  

// prNEW.cc -- test case
class base {
protected:
void
foo(void) const;
};

class derived : protected base {
public:
void
bar(void) const {
base::foo();
}
};

void
base::foo(void) const {
static_cast(*this);
}

% g++-4 -ansi -pedantic-errors -Wold-style-cast -Woverloaded-virtual -W -Wextra
-Wall -Wundef -Wshadow -Wno-unused-parameter -Wpointer-arith -Wcast-qual
-Wcast-align -Wconversion -Werror -std=c++0x -Wno-error=conversion -g -O3
-Wno-long-long -c prNEW.cc -o prNEW.o

prNEW.cc: In member function 'void base::foo() const':
prNEW.cc:17: error: 'base' is an inaccessible base of 'derived'

VERY closely related to pr12265, the only real change is from private to
protected inherited base.


-- 
   Summary: static downcast through protectedly inherited base class
rejected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fang at csl dot cornell dot edu


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

[Bug middle-end/39904] Loop is completely skipped

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c++ |middle-end


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

[Bug c++/39904] New: Loop is completely skipped

[neal at mailinator dot com]

The following simple program produces some very unusual results in gcc 4.3.2:

#include 

int n = 5;

int main ()
{
int m = 0;

for (int i = 0; i < n; i++)
{
m++;
m++;
}

printf ("m is %d.\n", m);

for (int i = 0; i < m; i++)
printf ("i is %d.\n", i);

printf ("where is the output?\n");
return 0;
}

When I run the program using "g++ -O2 a.cpp; ./a.out" I obtain the following
output:

m is 10.
where is the output?

Without "-O2" the output is as follows:

m is 10.
i is 0.
i is 1.
i is 2.
i is 3.
i is 4.
i is 5.
i is 6.
i is 7.
i is 8.
i is 9.
where is the output?

"gcc -v" gives the following:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--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.3
--program-suffix=-4.3 --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.3.2 (Ubuntu 4.3.2-1ubuntu12) 

Lastly, here is a.ii:

# 1 "a.cpp"
# 1 ""
# 1 ""
# 1 "a.cpp"
# 1 "/usr/include/c++/4.3/cstdio" 1 3
# 46 "/usr/include/c++/4.3/cstdio" 3

# 47 "/usr/include/c++/4.3/cstdio" 3

# 1 "/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h" 1 3
# 40 "/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h" 3
# 1 "/usr/include/c++/4.3/i486-linux-gnu/bits/os_defines.h" 1 3
# 44 "/usr/include/c++/4.3/i486-linux-gnu/bits/os_defines.h" 3
# 1 "/usr/include/features.h" 1 3 4
# 330 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 348 "/usr/include/sys/cdefs.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 349 "/usr/include/sys/cdefs.h" 2 3 4
# 331 "/usr/include/features.h" 2 3 4
# 354 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4



# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 5 "/usr/include/gnu/stubs.h" 2 3 4


# 1 "/usr/include/gnu/stubs-32.h" 1 3 4
# 8 "/usr/include/gnu/stubs.h" 2 3 4
# 355 "/usr/include/features.h" 2 3 4
# 45 "/usr/include/c++/4.3/i486-linux-gnu/bits/os_defines.h" 2 3
# 41 "/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h" 2 3


# 1 "/usr/include/c++/4.3/i486-linux-gnu/bits/cpu_defines.h" 1 3
# 44 "/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h" 2 3
# 233 "/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h" 3
namespace std __attribute__ ((__visibility__ ("default"))) {
# 245 "/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h" 3
}
# 49 "/usr/include/c++/4.3/cstdio" 2 3
# 1 "/usr/include/c++/4.3/cstddef" 1 3
# 45 "/usr/include/c++/4.3/cstddef" 3

# 46 "/usr/include/c++/4.3/cstddef" 3


# 1 "/usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h" 1 3 4
# 152 "/usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h" 3 4
typedef int ptrdiff_t;
# 214 "/usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h" 3 4
typedef unsigned int size_t;
# 49 "/usr/include/c++/4.3/cstddef" 2 3




namespace std __attribute__ ((__visibility__ ("default"))) {

  using ::ptrdiff_t;
  using ::size_t;

}
# 50 "/usr/include/c++/4.3/cstdio" 2 3
# 1 "/usr/include/stdio.h" 1 3 4
# 30 "/usr/include/stdio.h" 3 4
extern "C" {



# 1 "/usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h" 1 3 4
# 35 "/usr/include/stdio.h" 2 3 4

# 1 "/usr/include/bits/types.h" 1 3 4
# 28 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/bits/types.h" 2 3 4


typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;


typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;




__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;







__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 131 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 132 "/usr/include/bits/types.h" 2 3 4


__extension__ typedef __u_quad_t __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef __u_quad_t __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef __quad_t __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef __u_quad_t __rlim64_t;
__extension__ 

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-04-25 
23:40 ---
Created an attachment (id=17697)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17697&action=view)
assembly code generated from t026_y.c


-- 


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

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-04-25 
23:39 ---
Created an attachment (id=17696)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17696&action=view)
preprocessed source for t026_y.c


-- 


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

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-04-25 
23:38 ---
Created an attachment (id=17695)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17695&action=view)
assembly code generated from t026_x.c


-- 


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

[Bug c/39903] ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-04-25 
23:38 ---
Created an attachment (id=17694)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17694&action=view)
preprocessed source for t026_x.c


-- 


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

[Bug c/39903] New: ICE in tmpdir-gcc.dg-struct-layout-1/t026 c_compat_(x,y)_tst.o compile at -m64

[howarth at nitro dot med dot uc dot edu]

The tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o compile and
tmpdir-gcc.dg-struct-layout-1/t026 c_compat_y_tst.o compile test on
x86_64-apple-darwin10 produces internal compiler errors of the form...

Executing on host: /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/  -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-mno-mmx -fno-common -Wno-abi -DSKIP_DECIMAL_FLOAT -DSKIP_DECIMAL_FLOAT -c  -o
c_compat_x_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_x.c
   (timeout = 300)
In file included from
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_x.c:9:
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_test.h:
In function 'test2456':
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_test.h:57:
internal compiler error: in emit_move_insn, at expr.c:3405

and 

Executing on host: /sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/  -w
-I/sw/src/fink.build/gcc44-4.4.0-1000/gcc-4.4.0/gcc/testsuite/gcc.dg/compat
-mno-mmx -fno-common -Wno-abi -DSKIP_DECIMAL_FLOAT -DSKIP_DECIMAL_FLOAT -c  -o
c_compat_y_tst.o
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_y.c
   (timeout = 300)
In file included from
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_y.c:9:
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_test.h:
In function 'check2456':
/sw/src/fink.build/gcc44-4.4.0-1000/darwin_objdir/gcc/testsuite/gcc/gcc.dg-struct-layout-1//t026_test.h:57:
internal compiler error: in emit_move_insn, at expr.c:3405

This error is triggered by only a single line in t026_test.h

T(2456,double a;struct{int * c;}b[];,F(2456,a,-85022.609375,131929.593750))

I am attaching preprocessed source and assembly for each test in the hope that
this can be reproduced on a cross-compiler for this target.


-- 
   Summary: ICE in tmpdir-gcc.dg-struct-layout-1/t026
c_compat_(x,y)_tst.o compile at -m64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2009-04-25 22:57 
---
> Does this work too?

Yes, it does, thanks.


-- 


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

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2009-04-25 22:47 ---
Created an attachment (id=17693)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17693&action=view)
gcc45-pr39807.patch

Does this work too?


-- 


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

[Bug tree-optimization/39612] [4.4/4.5 Regression] Incorrect warning issued Re variable *is* used uninitialized in this function

[rakdver at gcc dot gnu dot org]

--- Comment #3 from rakdver at gcc dot gnu dot org  2009-04-25 22:44 ---
I cannot reproduce this in 4.5; all the unnecessary loads are removed.

> The fix is to avoid the load part of load-store-motion of course.

I've considered this, but it seems much easier to just let the unnecessary
loads be dce'd (detecting the unnecessary loads in lsm would basically
duplicate the work done by ssa update for the new variables.  I thought about
doing the ssa update and then removing the loads that are unused, but since
that seems to happen anyway, there is not much point).


-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rakdver 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=39612

[Bug c/39902] New: x * 1.0DF gets wrong value

[tydeman at tybor dot com]

Multiplication by a decimal floating-point (DFP) value of one appears to be
"optimized" away, thereby producing the wrong value.  In DFP, the value one has
many representations.  Only one of them (1.DF) results in no change to values
for multiplication; the others change the quantum exponent.

/* DFP TR 24732 == WG14 / N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */

#include   /* printf() */
#include  /* memcmp() */

int main(void){
  _Decimal32 f1 = 1.0DF;
  _Decimal32 f2 = 2.0DF;
  _Decimal32 f3;

  f3 = f2 * f1; /* should change quantum exponent */
  if( 0 == memcmp( &f3, &f2, sizeof(f3) ) ){
(void)printf("Fail 1\n");
  }

  f3 = f2 * 1.0DF;  /* should change quantum exponent */
  if( 0 == memcmp( &f3, &f2, sizeof(f3) ) ){
(void)printf("Fail 2\n");
  }
  return 0;
}

gets: Fail 2


-- 
   Summary: x * 1.0DF gets wrong value
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
 GCC build triplet: 4.3.2


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

[Bug c++/39901] [C++0x] Initializer list not allowed in []

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-04-25 22:30 
---
Jason, can you have a look? Thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug tree-optimization/36188] missed CCP

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2009-04-25 22:24 ---
Re. comment #5 -- what doesn't work very well, i.e. what massive breakage does
your patch cause?

Maybe you can treat static locals optimistically if they are only stored to
once?


-- 


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

[Bug c++/39901] New: [C++0x] Initializer list not allowed in []

[tom dot prince at ualberta dot net]

According to n2531, the new C++0x initializer-list is allowed in []. 

Test Case:

#include 

void test(void)
{
std::map,int> the_map;
the_map[{0,1}] = 5;
}

Error:
/tmp/test.cc: In function ‘void test()’:
/tmp/test.cc:6: error: expected primary-expression before ‘{’ token
/tmp/test.cc:6: error: expected ‘]’ before ‘{’ token
/tmp/test.cc:6: error: expected ‘;’ before ‘{’ token
/tmp/test.cc:6: error: expected primary-expression before ‘]’ token
/tmp/test.cc:6: error: expected ‘;’ before ‘]’ token

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-multilib
--disable-bootstrap --prefix /Users/cougar/local/gcc45 : (reconfigured)
./config
ure --enable-shared --enable-threads=posix --enable-__cxa_atexit
--disable-multilib --disable-bootstrap --prefix /Users/cougar/local/gcc45
--enable-languages=c,c++ --no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20090425 (experimental) (GCC)


-- 
   Summary: [C++0x] Initializer list not allowed in []
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot prince at ualberta dot net
  GCC host triplet: x86_64-linux-gnu


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

[Bug c/39582] bad errors for some uses of [*] arrays

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2009-04-25 21:21 ---
Fixed for 4.5.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug c/39582] bad errors for some uses of [*] arrays

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-04-25 21:19 ---
Subject: Bug 39582

Author: jsm28
Date: Sat Apr 25 21:19:09 2009
New Revision: 146787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146787
Log:
PR c/39582
* c-typeck.c (c_expr_sizeof_type): Create a C_MAYBE_CONST_EXPR
with non-null C_MAYBE_CONST_EXPR_PRE if size of a variable-length
type is an integer constant.

testsuite:
* gcc.dg/vla-20.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vla-20.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39893] gfortran ICE on invalid program

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-04-25 20:47 ---
I have a patch.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-25 20:47:18
   date||


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

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2009-04-25 20:27 
---
> Anyway, can you try
> sed -i -e 's,/==,/.=,' contrib/dg-extract-results.sh
> or
> sed -i -e 's,/==,/[=]=,' contrib/dg-extract-results.sh
> or
> sed -i -e 's,/==,/^.*==,' contrib/dg-extract-results.sh
> ?  I guess the last one would be best.

Thanks, the last one works.  But then nawk chokes on

  print > "${TMP}/chapter-"chapter

so I additionally need:

/^Running chapter / {
  if (chapter) close ("${TMP}/chapter-"chapter)
  chapter=\$3
  file="${TMP}/chapter-"chapter
  print >> file
  next
}

and

{
  if (print_prologue) { print; next }
  if (chapter) {
file="${TMP}/chapter-"chapter
print >> file
  }
}

With all the changes I get a correct ACATS log file (at least manually).


-- 


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

[Bug target/39897] [4.5 Regression] Revision 146761 caused libgomp.fortran/omp_atomic1.f90

[uros at gcc dot gnu dot org]

--- Comment #2 from uros at gcc dot gnu dot org  2009-04-25 20:11 ---
Subject: Bug 39897

Author: uros
Date: Sat Apr 25 20:11:01 2009
New Revision: 146784

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146784
Log:
PR target/39897
* config/i386/i386.c (print_operand) ['z']: Revert handling of
HImode operands.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c


-- 


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

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2009-04-25 19:22 ---
Very useful awk implementation.  Not.
Anyway, can you try
sed -i -e 's,/==,/.=,' contrib/dg-extract-results.sh
or
sed -i -e 's,/==,/[=]=,' contrib/dg-extract-results.sh
or
sed -i -e 's,/==,/^.*==,' contrib/dg-extract-results.sh
?  I guess the last one would be best.


-- 


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

[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails

[paolo dot carlini at oracle dot com]

--- Comment #19 from paolo dot carlini at oracle dot com  2009-04-25 19:16 
---
Sorry, but at this point in history, it's unlikely that we are going to do much
to the current std::string, given all the ABI implications. When we'll break
the ABI, for C++1x, a completely different implementation will be used, neither
affected by this issue nor by many others (ext/vstring is close, and already
available).


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|ASSIGNED|NEW


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

[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails

[ktietz at gcc dot gnu dot org]

--- Comment #18 from ktietz at gcc dot gnu dot org  2009-04-25 19:10 ---
(In reply to comment #16)
> Ok. Hopefully, before the end of this week I can tell you something 
> trustworthy
> about binary compatibility.
> 

Have you found a solution for it? On w64 target 4.4 (and 4.5) the problem seems
to exist still. At least the patch you sent solved it (I had to adjust it a
bit).

Cheers,
Kai


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.0 4.5.0


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

[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2009-04-25 19:02 
---
Another nit on Solaris 9:

=== acats Summary ===
# of expected passes773
# of unexpected failures0
gmake[1]: Leaving directory
`/nfs/nile/nile.build/botcazou/gcc-head/sparc-sun-solaris2.9/gcc'
nawk: syntax error at source line 5
 context is
 >>> /= <<<
nawk: bailing out at source line 5
nawk: syntax error at source line 5
 context is
 >>> /= <<<
nawk: bailing out at source line 5

so no results are reported for ACATS.


-- 


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

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2009-04-25 19:02 ---
Subject: Bug 39882

Author: paolo
Date: Sat Apr 25 19:02:17 2009
New Revision: 146781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146781
Log:
2009-04-25  Paolo Carlini  

PR libstdc++/39880
PR libstdc++/39881
PR libstdc++/39882
* include/std/system_error (is_error_code_enum): Remove.
(error_condition<>::error_condition(_ErrorCodeEnum,)
error_condition<>::operator=(_ErrorCodeEnum)): Use
make_error_condition.
(error_code<>::error_code(_ErrorCodeEnum,),
error_code<>::operator=(_ErrorCodeEnum)): Use make_error_code.
* testsuite/19_diagnostics/system_error/39880.cc: New.
* testsuite/19_diagnostics/error_condition/modifiers/39881.cc:
Likewise.
* testsuite/19_diagnostics/error_condition/cons/39881.cc: Likewise.
* testsuite/19_diagnostics/error_code/modifiers/39882.cc: Likewise.
* testsuite/19_diagnostics/error_code/cons/39882.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
Adjust.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc:
Likewise.
* testsuite/19_diagnostics/error_code/cons/1.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/bool.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc:
Likewise.
* testsuite/19_diagnostics/error_category/cons/copy_neg.cc: Likewise.
* testsuite/19_diagnostics/system_error/cons-1.cc: Likewise.
* testsuite/19_diagnostics/system_error/what-4.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/2.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog


-- 


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

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2009-04-25 19:02 ---
Subject: Bug 39881

Author: paolo
Date: Sat Apr 25 19:02:17 2009
New Revision: 146781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146781
Log:
2009-04-25  Paolo Carlini  

PR libstdc++/39880
PR libstdc++/39881
PR libstdc++/39882
* include/std/system_error (is_error_code_enum): Remove.
(error_condition<>::error_condition(_ErrorCodeEnum,)
error_condition<>::operator=(_ErrorCodeEnum)): Use
make_error_condition.
(error_code<>::error_code(_ErrorCodeEnum,),
error_code<>::operator=(_ErrorCodeEnum)): Use make_error_code.
* testsuite/19_diagnostics/system_error/39880.cc: New.
* testsuite/19_diagnostics/error_condition/modifiers/39881.cc:
Likewise.
* testsuite/19_diagnostics/error_condition/cons/39881.cc: Likewise.
* testsuite/19_diagnostics/error_code/modifiers/39882.cc: Likewise.
* testsuite/19_diagnostics/error_code/cons/39882.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
Adjust.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc:
Likewise.
* testsuite/19_diagnostics/error_code/cons/1.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/bool.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc:
Likewise.
* testsuite/19_diagnostics/error_category/cons/copy_neg.cc: Likewise.
* testsuite/19_diagnostics/system_error/cons-1.cc: Likewise.
* testsuite/19_diagnostics/system_error/what-4.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/2.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog


-- 


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

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

[paolo at gcc dot gnu dot org]

--- Comment #6 from paolo at gcc dot gnu dot org  2009-04-25 19:02 ---
Subject: Bug 39880

Author: paolo
Date: Sat Apr 25 19:02:17 2009
New Revision: 146781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146781
Log:
2009-04-25  Paolo Carlini  

PR libstdc++/39880
PR libstdc++/39881
PR libstdc++/39882
* include/std/system_error (is_error_code_enum): Remove.
(error_condition<>::error_condition(_ErrorCodeEnum,)
error_condition<>::operator=(_ErrorCodeEnum)): Use
make_error_condition.
(error_code<>::error_code(_ErrorCodeEnum,),
error_code<>::operator=(_ErrorCodeEnum)): Use make_error_code.
* testsuite/19_diagnostics/system_error/39880.cc: New.
* testsuite/19_diagnostics/error_condition/modifiers/39881.cc:
Likewise.
* testsuite/19_diagnostics/error_condition/cons/39881.cc: Likewise.
* testsuite/19_diagnostics/error_code/modifiers/39882.cc: Likewise.
* testsuite/19_diagnostics/error_code/cons/39882.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
Adjust.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc:
Likewise.
* testsuite/19_diagnostics/error_code/cons/1.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/bool.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc:
Likewise.
* testsuite/19_diagnostics/error_category/cons/copy_neg.cc: Likewise.
* testsuite/19_diagnostics/system_error/cons-1.cc: Likewise.
* testsuite/19_diagnostics/system_error/what-4.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/2.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog


-- 


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

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2009-04-25 19:01 ---
Subject: Bug 39880

Author: paolo
Date: Sat Apr 25 19:00:52 2009
New Revision: 146780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146780
Log:
2009-04-25  Paolo Carlini  

PR libstdc++/39880
PR libstdc++/39881
PR libstdc++/39882
* include/std/system_error (is_error_code_enum): Remove.
(error_condition<>::error_condition(_ErrorCodeEnum,)
error_condition<>::operator=(_ErrorCodeEnum)): Use
make_error_condition.
(error_code<>::error_code(_ErrorCodeEnum,),
error_code<>::operator=(_ErrorCodeEnum)): Use make_error_code.
* testsuite/19_diagnostics/system_error/39880.cc: New.
* testsuite/19_diagnostics/error_condition/modifiers/39881.cc:
Likewise.
* testsuite/19_diagnostics/error_condition/cons/39881.cc: Likewise.
* testsuite/19_diagnostics/error_code/modifiers/39882.cc: Likewise.
* testsuite/19_diagnostics/error_code/cons/39882.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
Adjust.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc:
Likewise.
* testsuite/19_diagnostics/error_code/cons/1.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/bool.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc:
Likewise.
* testsuite/19_diagnostics/error_category/cons/copy_neg.cc: Likewise.
* testsuite/19_diagnostics/system_error/cons-1.cc: Likewise.
* testsuite/19_diagnostics/system_error/what-4.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/2.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/39882.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/modifiers/
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/modifiers/39882.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/39881.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/modifiers/
   
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/modifiers/39881.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/39880.cc
Modified:
trunk/libstdc++-v3/include/std/system_error
trunk/libstdc++-v3/testsuite/19_diagnostics/error_category/cons/copy_neg.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/1.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/bool.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/equal.cc
   
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/not_equal.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/cons-1.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/what-4.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc
trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/2.cc


-- 


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

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2009-04-25 19:01 ---
Subject: Bug 39881

Author: paolo
Date: Sat Apr 25 19:00:52 2009
New Revision: 146780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146780
Log:
2009-04-25  Paolo Carlini  

PR libstdc++/39880
PR libstdc++/39881
PR libstdc++/39882
* include/std/system_error (is_error_code_enum): Remove.
(error_condition<>::error_condition(_ErrorCodeEnum,)
error_condition<>::operator=(_ErrorCodeEnum)): Use
make_error_condition.
(error_code<>::error_code(_ErrorCodeEnum,),
error_code<>::operator=(_ErrorCodeEnum)): Use make_error_code.
* testsuite/19_diagnostics/system_error/39880.cc: New.
* testsuite/19_diagnostics/error_condition/modifiers/39881.cc:
Likewise.
* testsuite/19_diagnostics/error_condition/cons/39881.cc: Likewise.
* testsuite/19_diagnostics/error_code/modifiers/39882.cc: Likewise.
* testsuite/19_diagnostics/error_code/cons/39882.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
Adjust.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc:
Likewise.
* testsuite/19_diagnostics/error_code/cons/1.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/bool.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc:
Likewise.
* testsuite/19_diagnostics/error_category/cons/copy_neg.cc: Likewise.
* testsuite/19_diagnostics/system_error/cons-1.cc: Likewise.
* testsuite/19_diagnostics/system_error/what-4.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/2.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/39882.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/modifiers/
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/modifiers/39882.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/39881.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/modifiers/
   
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/modifiers/39881.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/39880.cc
Modified:
trunk/libstdc++-v3/include/std/system_error
trunk/libstdc++-v3/testsuite/19_diagnostics/error_category/cons/copy_neg.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/1.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/bool.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/equal.cc
   
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/not_equal.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/cons-1.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/what-4.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc
trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/2.cc


-- 


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

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2009-04-25 19:01 ---
Subject: Bug 39882

Author: paolo
Date: Sat Apr 25 19:00:52 2009
New Revision: 146780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146780
Log:
2009-04-25  Paolo Carlini  

PR libstdc++/39880
PR libstdc++/39881
PR libstdc++/39882
* include/std/system_error (is_error_code_enum): Remove.
(error_condition<>::error_condition(_ErrorCodeEnum,)
error_condition<>::operator=(_ErrorCodeEnum)): Use
make_error_condition.
(error_code<>::error_code(_ErrorCodeEnum,),
error_code<>::operator=(_ErrorCodeEnum)): Use make_error_code.
* testsuite/19_diagnostics/system_error/39880.cc: New.
* testsuite/19_diagnostics/error_condition/modifiers/39881.cc:
Likewise.
* testsuite/19_diagnostics/error_condition/cons/39881.cc: Likewise.
* testsuite/19_diagnostics/error_code/modifiers/39882.cc: Likewise.
* testsuite/19_diagnostics/error_code/cons/39882.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc:
Adjust.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc:
Likewise.
* testsuite/19_diagnostics/error_code/cons/1.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/bool.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Likewise.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc:
Likewise.
* testsuite/19_diagnostics/error_category/cons/copy_neg.cc: Likewise.
* testsuite/19_diagnostics/system_error/cons-1.cc: Likewise.
* testsuite/19_diagnostics/system_error/what-4.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/2.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/39882.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/modifiers/
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/modifiers/39882.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/cons/39881.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/modifiers/
   
trunk/libstdc++-v3/testsuite/19_diagnostics/error_condition/modifiers/39881.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/39880.cc
Modified:
trunk/libstdc++-v3/include/std/system_error
trunk/libstdc++-v3/testsuite/19_diagnostics/error_category/cons/copy_neg.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/cons/1.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/bool.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/equal.cc
   
trunk/libstdc++-v3/testsuite/19_diagnostics/error_code/operators/not_equal.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/cons-1.cc
trunk/libstdc++-v3/testsuite/19_diagnostics/system_error/what-4.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/error_code.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/error_code.cc
trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/2.cc


-- 


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

[Bug c/39564] variably modified function return types not always diagnosed

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2009-04-25 18:56 ---
Fixed for 4.5.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug c/39564] variably modified function return types not always diagnosed

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-04-25 18:56 ---
Subject: Bug 39564

Author: jsm28
Date: Sat Apr 25 18:55:50 2009
New Revision: 146778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146778
Log:
PR c/39564
* c-decl.c (grokdeclarator): Diagnose declarations of functions
with variably modified return type and no storage class
specifiers, except for the case of nested functions.  Distinguish
extern declarations of functions with variably modified return
types from those of objects with variably modified types.

testsuite:
* gcc.dg/vla-19.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vla-19.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug preprocessor/39559] constants too large for intmax_t need pedwarns

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2009-04-25 18:52 ---
Fixed for 4.5.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug preprocessor/39559] constants too large for intmax_t need pedwarns

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-04-25 18:46 ---
Subject: Bug 39559

Author: jsm28
Date: Sat Apr 25 18:46:03 2009
New Revision: 146777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146777
Log:
libcpp:
PR preprocessor/39559
* expr.c (cpp_interpret_integer): Use a pedwarn for decimal
constants larger than intmax_t in C99 mode.

gcc/testsuite:
* gcc.dg/c99-intconst-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/c99-intconst-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/expr.c


-- 


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

[Bug fortran/39879] [4.3/4.4/4.5 Regression] double free or corruption abort with gfortran

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2009-04-25 18:06 ---
(In reply to comment #6)

With the pointer initialization, the assignment   u%model = u%design
is translated to:

  {
struct tao_lattice_struct D.1667;

D.1667 = *u->design;
tao_lat_equal_tao_lat (u->model, &D.1667);
if (D.1667.bunch_params.data != 0B)
  {
__builtin_free (D.1667.bunch_params.data);
  }
D.1667.bunch_params.data = 0B;
if (D.1667.bunch_params2.data != 0B)
  {
__builtin_free (D.1667.bunch_params2.data);
  }
D.1667.bunch_params2.data = 0B;
  }

Thus the data pointers are doubly freed because they are not nullified in
u->design

Once the initialization is gone, the assignment becomes

  tao_lat_equal_tao_lat (u->model, u->design);

and the cause of the problem has vanaished.

Paul


-- 


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

[Bug c/39900] New: ICE on nested function returning pointer to VLA

[jsm28 at gcc dot gnu dot org]

int a;
void
f (void)
{
  int (*g (void))[a] { return 0; }
}

gets an ICE:

t.c: In function 'f':
t.c:5: internal compiler error: in put_pending_sizes, at stor-layout.c:108
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Unlike bug 21374, this is returning a pointer to a VLA rather than
a variable-size type itself.

If a typedef is used for the VLA, it does not ICE.

int a;
void
f (void)
{
  typedef int T[a];
  T *g (void) { return 0; }
}


-- 
   Summary: ICE on nested function returning pointer to VLA
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition

[craig dot powers at gmail dot com]

--- Comment #5 from craig dot powers at gmail dot com  2009-04-25 17:23 
---
(In reply to comment #4)
> > Also, I omitted the link invocation:
> > gfortran -O3 -o (exe_name) (big honkin' list of object files)
> 
> Can you double check that in the "big honkin' list of object files" the file
> "nucleation.o" is listed only once?
> 

Oops, that was it.  The object file was twice in the list.  I should have
checked that.


-- 

craig dot powers at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/39896] ICE with -fwhole-file

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-04-25 17:20 ---
This may also be related to some failures I have seen with the polyhedron
tests, see:

http://gcc.gnu.org/ml/fortran/2009-04/msg00031.html

I particular for

[ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'eos':
gas_dyn.f90:360: internal compiler error: Bus error   <-- now 406
[ibook-dhum] lin/test% gfc -O2 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'readin':
gas_dyn.f90:1572: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -O3 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'nozzle':
gas_dyn.f90:896: internal compiler error: Bus error

where 1572 is a GOTO and 406 and 896 are IFs.


-- 


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

[Bug fortran/39896] ICE with -fwhole-file

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2009-04-25 17:16 ---
Here's a testcase (doesn't "work" without the extra subroutine): 

$> cat goto.for
  i = 1
  DO
CALL inc(i)
IF (i == 5) GOTO 100
  END DO
100   PRINT *, "done"
  END

  SUBROUTINE inc(n)
INTEGER n
n = n + 1
  END SUBROUTINE

$> gfortran-svn -Wall -W goto.for
[no warning]

$> gfortran-svn -Wall -W warning.for -fwhole-file
goto.for:6.3:

100   PRINT *, "done"
   1
goto.for:4.72:

IF (i == 5) GOTO 100
2
Warning: Label at (1) is not in the same block as the GOTO statement at (2)


If this case is related to the ICE, I don't know, however, I observed both
together.


-- 


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

[Bug fortran/39896] ICE with -fwhole-file

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-04-25 17:02 ---
It may be worth noting that there are no warnings in the application about
labels not being in the same block as the corresponding GOTO if compiled
without -fwhole-file, but if compiled with -fwhole-file some of these warnings
appear.

If these warnings are missed without -fwhole-file or spurious with
-fwhole-file, I can not say yet. I'll try to get a testcase ...


-- 


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

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2009-04-25 16:37 ---
The Fortran 95 standard states:

  7.5.1.4Intrinsic assignment conformance rules

  For an intrinsic assignment statement, variable and expr shall conform in
  shape, and if expr is an array, variable shall also be an array. The types
  of variable and expr shall conform with the rules of Table 7.9.

This is not a constraint, so a compiler is not required to generate a
warning or an error.  It can do anything, including corrupt memory.
As Dominique suggested, one should use the -fbounds-check option while
developing code.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-04-25 16:30 ---
> But bounds checking on the other compilers I have access to doesn't show any 
> problem

Are you sure about that? If you use bound-checking on any compiler supporting
it, you should get an error (at least a warning).

> I was hoping gfortran can be smarter in
> this situations like this, and use just the first portion of the array on the
> right side that fits the shape of the array section on the left of the
> assignment statement.

Again, I don't think any compiler is smart with this respect. If one is, it
should emit a warning about the use of the extension. Now as I said in comment
#2, on i686-apple-darwin9 the invalid and valid codes give the same output, but
it is not because gfortran is smarter on this platform than on yours, but only
because the memory layouts are different and that the extra data are written on
i686-apple-darwin9 in a place that does not cause a problem.

Final note, you should close this pr as invalid, TIA.


-- 


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

[Bug target/39897] [4.5 Regression] Revision 146762 caused libgomp.fortran/omp_atomic1.f90

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-04-25 15:52 ---
> Revision 146762 caused:

You probably mean 146761:

Author: uros
Date:   Sat Apr 25 08:10:51 2009 UTC (7 hours, 40 minutes ago)
Log Message:
PR target/39590
* configure.ac (HAVE_AS_IX86_FILDQ): On x86 targets check whether
the configured assembler supports fildq and fistpq mnemonics.
(HAVE_AS_IX86_FILDS): Rename from HAVE_GAS_FILDS_FISTS.
* configure: Regenerated.
* config.in: Ditto.

* config/i386/i386.c (print_operand): Handle 'Z'.
['z']: Remove handling of special fild/fist suffixes.
(output_fix_trunc): Use '%Z' to output suffix of fist{,p,tp} insn.
* config/i386/i386.md (*floathi2_i387): Use '%Z' to output
suffix of fild insn.
(*floatsi2_vector_mixed): Ditto.
(*float2_mixed_interunit): Ditto.
(*float2_mixed_nointerunit): Ditto.
(*float2_i387_with_temp): Ditto.
(*float2_i387): Ditto.
* config/i386/gas.h (GAS_MNEMONICS): Remove.


-- 


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

[Bug libgcj/39899] New: gjdoc in 4.4.0 fails to build the libgcj documentation

[doko at ubuntu dot com]

gjdoc in 4.4.0 fails to build the libgcj documentation.

WARNING: System.setProperty("java.class.path",
"/usr/share/java/antlr.jar");

How do we pass the classpath to the VM?

gjdoc \
-use \
-classpath "/usr/share/java/antlr.jar" \
-sourcepath
"/scratch/packages/gcc/4.4/java/gcj-4.4-4.4.0/build/java-src" \
-encoding UTF-8 \
-breakiterator \
-licensetext \
-linksource \
-splitindex \
-subpackages gnu:java:javax:org
WARNING: -classpath option could not be passed to the VM.  Faking it with 
WARNING: System.setProperty("java.class.path",
"/usr/share/java/antlr.jar");
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target({TYPE, FIELD, METHOD, PARAMETER,
CONSTRUCTOR, LOCAL_VARIABLE})'
WARNING: unknown modifier '@Retention(SOURCE)'
WARNING: unknown modifier '@Target(METHOD)'
WARNING: unknown modifier '@Documented'
WARNING: unknown modifier '@Retention(RUNTIME)'
Loading classes for package gnu.javax.crypto...
Loading classes for package gnu.javax.crypto.pad...
[...]
Resolving references in package comments...
Running doclet...
WARNING: Option -validhtml hasn't been specified. Generated HTML will not
validate.
Building cross-reference information...
Writing overview files...
Writing full tree...
Writing index...
java.lang.reflect.InvocationTargetException
   at java.lang.reflect.Method.invoke(natMethod.cc:205)
   at gnu.classpath.tools.gjdoc.Main.startDoclet(Main.java:629)
   at gnu.classpath.tools.gjdoc.Main.start(Main.java:1159)
   at gnu.classpath.tools.gjdoc.Main.main(Main.java:883)
Caused by: java.lang.NoClassDefFoundError:
gnu.classpath.tools.gjdoc.expr.Evaluator
   at java.lang.Class.initializeClass(natClass.cc:727)
   at
gnu.classpath.tools.gjdoc.FieldDocImpl.constantValue(FieldDocImpl.java:303)
   at
gnu.classpath.tools.gjdoc.FieldDocImpl.constantValue(FieldDocImpl.java:281)
   at
gnu.classpath.tools.gjdoc.FieldDocImpl.constantValueExpression(FieldDocImpl.java:344)
   at
gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.printSerializationPage(HtmlDoclet.java:1444)
   at
gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.run(HtmlDoclet.java:3113)
   at
gnu.classpath.tools.doclets.AbstractDoclet.startInstance(AbstractDoclet.java:200)
   at gnu.classpath.tools.doclets.AbstractDoclet.start(AbstractDoclet.java:131)
   at java.lang.reflect.Method.invoke(natMethod.cc:205)
   ...3 more
Caused by: java.lang.NoClassDefFoundError: antlr.CharScanner
   at java.lang.VMClassLoader.loadClass(natVMClassLoader.cc:239)
   at java.lang.Class.initializeClass(natClass.cc:717)
   ...11 more


called as


-- 
   Summary: gjdoc in 4.4.0 fails to build the libgcj documentation
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

[deji_aking at yahoo dot ca]

--- Comment #3 from deji_aking at yahoo dot ca  2009-04-25 15:32 ---
(In reply to comment #2)
> If you compile the code in comment #1 with '-fbounds-check', you get:
> 
> At line 32 of file pr39894.f90
> Fortran runtime error: Array bound mismatch, size mismatch for dimension 2 of
> array 'listgeonm' (18/999)
>
Thanks, I've seen that too. But bounds checking on the other compilers I have
access to doesn't show any problem. I was hoping gfortran can be smarter in
this situations like this, and use just the first portion of the array on the
right side that fits the shape of the array section on the left of the
assignment statement.


-- 


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

[Bug middle-end/39898] New: [4.5 regression] Revision 146763 caused g++.dg/tree-ssa/ehcleanup-1.C

[hjl dot tools at gmail dot com]

Revision 146763:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01405.html

caused:

FAIL: g++.dg/tree-ssa/ehcleanup-1.C scan-tree-dump-times ehcleanup1 "Empty EH
handler" 1

on x86.


-- 
   Summary: [4.5 regression] Revision 146763 caused g++.dg/tree-
ssa/ehcleanup-1.C
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug target/39897] New: [4.5 Regression] Revision 146762 caused libgomp.fortran/omp_atomic1.f90

[hjl dot tools at gmail dot com]

Revision 146762 caused:

Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/gcc/libgomp/testsuite/libgomp.fortran/omp_atomic1.f90 
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/
-I/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp
-I/export/gnu/import/gcc/libgomp/testsuite/.. -march=i486 -fmessage-length=0
-fopenmp  -O1  
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs
 
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/.libs
-lgomp
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgomp/../libgfortran/.libs
-lgfortranbegin -lgfortran -lm   -m32 -o ./omp_atomic1.exe(timeout = 300)
/tmp/ccCCtX3d.s: Assembler messages:^M
/tmp/ccCCtX3d.s:95: Error: suffix or operands invalid for `fisubr'^M
/tmp/ccCCtX3d.s:145: Error: suffix or operands invalid for `fisub'^M
/tmp/ccCCtX3d.s:174: Error: suffix or operands invalid for `fisub'^M
compiler exited with status 1


-- 
   Summary: [4.5 Regression] Revision 146762 caused
libgomp.fortran/omp_atomic1.f90
   Product: gcc
   Version: 4.5.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


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

--- Comment #12 from rguenther at suse dot de  2009-04-25 14:29 ---
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, pinskia at gmail dot com wrote:

> --- Comment #10 from pinskia at gmail dot com  2009-04-25 14:25 ---
> Subject: Re:  gcc-4.4 -Wstrict-aliasing and 
> -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
> 
> On Sat, Apr 25, 2009 at 7:22 AM, edwintorok at gmail dot com
>  wrote:
> 
> > Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
> > (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
> > Either that or add a configure rule to add -fno-strict-aliasing.
> 
> GCC has been able to optimize memcpy since at least 3.0.0 so using:
> #if (__GNUC__ >=3)
>
> Should be good enough (undefined macros are substituted with 0 in #if's).

Not on the tree level though.  At least 4.3 doesn't optimize it there
which may indeed pessimize optimization.

Richard.


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2009-04-25 14:28 ---
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> --- Comment #9 from edwintorok at gmail dot com  2009-04-25 14:22 ---
> (In reply to comment #6)
> > No, not if it is inlined (and if not you can as well use memcpy).
> > 
> > You can also do (GCC extension)
> > 
> > union union_t {
> > unsigned un;
> > char c[4];
> > };
> > 
> > unsigned bar(char *x)
> > {
> >   union union_t u;
> >   u.c[0] = x[0];
> >   u.c[1] = x[1];
> >   u.c[2] = x[2];
> >   u.c[3] = x[3];
> >   return u.un;
> > }
> > 
> > but that will even generate worse code with GCC than the
> > memcpy (it's even horrible code).
> 
> Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
> (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
> Either that or add a configure rule to add -fno-strict-aliasing.

Another GCC extension is the following (this is what GCC 4.4 makes
out of the memcpy very early during optimization)

typedef unsigned __attribute__((may_alias,aligned(1))) my_unsigned;

unsigned bar(char *x)
{
return *(my_unsigned *)x;
}

That should work with even ancient GCC (I checked 3.3)

Richard.


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[pinskia at gmail dot com]

--- Comment #10 from pinskia at gmail dot com  2009-04-25 14:25 ---
Subject: Re:  gcc-4.4 -Wstrict-aliasing and 
-Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, Apr 25, 2009 at 7:22 AM, edwintorok at gmail dot com
 wrote:

> Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
> (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
> Either that or add a configure rule to add -fno-strict-aliasing.

GCC has been able to optimize memcpy since at least 3.0.0 so using:
#if (__GNUC__ >=3)

Should be good enough (undefined macros are substituted with 0 in #if's).

-- Pinski


-- 


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

Re: [Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[Andrew Pinski]

On Sat, Apr 25, 2009 at 7:22 AM, edwintorok at gmail dot com
 wrote:

> Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
> (__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
> Either that or add a configure rule to add -fno-strict-aliasing.

GCC has been able to optimize memcpy since at least 3.0.0 so using:
#if (__GNUC__ >=3)

Should be good enough (undefined macros are substituted with 0 in #if's).

-- Pinski

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

--- Comment #9 from edwintorok at gmail dot com  2009-04-25 14:22 ---
(In reply to comment #6)
> No, not if it is inlined (and if not you can as well use memcpy).
> 
> You can also do (GCC extension)
> 
> union union_t {
> unsigned un;
> char c[4];
> };
> 
> unsigned bar(char *x)
> {
>   union union_t u;
>   u.c[0] = x[0];
>   u.c[1] = x[1];
>   u.c[2] = x[2];
>   u.c[3] = x[3];
>   return u.un;
> }
> 
> but that will even generate worse code with GCC than the
> memcpy (it's even horrible code).

Hmm, looks like the only way out is for me to put #if defined(__GNUC__) &&
(__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) and use memcpy.
Either that or add a configure rule to add -fno-strict-aliasing.


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2009-04-25 14:20 ---
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> > > > * an aggregate or union type that includes one of the 
> > > > aforementioned types
> > > > among its members (including, recursively, a member of a subaggregate or
> > > > contained union), or
> > > > * a character type."
> > > > 
> > > > I'm casting to a union that has both types as members, why doesn't that 
> > > > fit
> > > > under the 5th case in the above quote?
> > > 
> > > Because it is certainly backwards.
> > 
> > Or rather, this refers to a compatible type to the type that was used
> > to store the value, so it doesn't apply to type-punning.
> > 
> 
> Yes, the union has a compatibly type to the one used to store the value (it 
> has
> a char member), hence the union can be used to access the value. I use a
> different member to access the value, but isn't that what unions are for? :)

No, unions are for what in modula or ada are discriminated records, not
for type-punning.  "Manual OO", like the GCC tree union.

Richard.


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

--- Comment #7 from edwintorok at gmail dot com  2009-04-25 14:18 ---
(In reply to comment #5)
> > > "An object shall have its stored value accessed only by an lvalue 
> > > expression
> > > that has one of the following types:
> > > 
> > > * a type compatible with the effective type of the object,
> > > * a qualified version of a type compatible with the effective type of 
> > > the
> > > object,
> > > * a type that is the signed or unsigned type corresponding to the 
> > > effective
> > > type of the object,
> > > * a type that is the signed or unsigned type corresponding to a 
> > > qualified
> > > version of the effective type of the object,
> > > * an aggregate or union type that includes one of the aforementioned 
> > > types
> > > among its members (including, recursively, a member of a subaggregate or
> > > contained union), or
> > > * a character type."
> > > 
> > > I'm casting to a union that has both types as members, why doesn't that 
> > > fit
> > > under the 5th case in the above quote?
> > 
> > Because it is certainly backwards.
> 
> Or rather, this refers to a compatible type to the type that was used
> to store the value, so it doesn't apply to type-punning.
> 

Yes, the union has a compatibly type to the one used to store the value (it has
a char member), hence the union can be used to access the value. I use a
different member to access the value, but isn't that what unions are for? :)


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2009-04-25 14:17 ---
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> --- Comment #4 from edwintorok at gmail dot com  2009-04-25 14:12 ---
> (In reply to comment #3)
> > 
> > The above is properly optimized.  Why do you think that an inline
> > function taking void * would fix anything?
> 
> I can't know if memcpy will be inlined, it may just be a function call on
> certain systems, with certain compilers.
> The inline function should be a more portable way of expressing what I need,
> and it shouldn't cause any bugs with -fstrict-aliasing, since gcc already 
> knows
> I gave my pointer to a function taking void*, so anything could happen with 
> it,
> right?

No, not if it is inlined (and if not you can as well use memcpy).

You can also do (GCC extension)

union union_t {
unsigned un;
char c[4];
};

unsigned bar(char *x)
{
  union union_t u;
  u.c[0] = x[0];
  u.c[1] = x[1];
  u.c[2] = x[2];
  u.c[3] = x[3];
  return u.un;
}

but that will even generate worse code with GCC than the
memcpy (it's even horrible code).

Richard.


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

--- Comment #5 from rguenther at suse dot de  2009-04-25 14:12 ---
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, Richard Guenther wrote:

> On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:
> 
> > 
> > 
> > --- Comment #2 from edwintorok at gmail dot com  2009-04-25 13:49 
> > ---
> > (In reply to comment #1)
> > > Casting through a union (2)
> > > 
> > > describes an invalid way of doing type-punning.
> > 
> > There is also a citation from C99 on that page:
> > "An object shall have its stored value accessed only by an lvalue expression
> > that has one of the following types:
> > 
> > * a type compatible with the effective type of the object,
> > * a qualified version of a type compatible with the effective type of 
> > the
> > object,
> > * a type that is the signed or unsigned type corresponding to the 
> > effective
> > type of the object,
> > * a type that is the signed or unsigned type corresponding to a 
> > qualified
> > version of the effective type of the object,
> > * an aggregate or union type that includes one of the aforementioned 
> > types
> > among its members (including, recursively, a member of a subaggregate or
> > contained union), or
> > * a character type."
> > 
> > I'm casting to a union that has both types as members, why doesn't that fit
> > under the 5th case in the above quote?
> 
> Because it is certainly backwards.

Or rather, this refers to a compatible type to the type that was used
to store the value, so it doesn't apply to type-punning.

Richard.


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

--- Comment #4 from edwintorok at gmail dot com  2009-04-25 14:12 ---
(In reply to comment #3)
> 
> The above is properly optimized.  Why do you think that an inline
> function taking void * would fix anything?

I can't know if memcpy will be inlined, it may just be a function call on
certain systems, with certain compilers.
The inline function should be a more portable way of expressing what I need,
and it shouldn't cause any bugs with -fstrict-aliasing, since gcc already knows
I gave my pointer to a function taking void*, so anything could happen with it,
right?


-- 


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

[Bug fortran/39896] ICE with -fwhole-file

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-04-25 14:10 ---
Confirmed. You don't need the infinite loop to get the bus error, the following
block triggers it also:

 456  CONTINUE
  go to 500
  GO TO 456
 500  continue


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2009-04-25 14:06 ---
Subject: Re:  gcc-4.4 -Wstrict-aliasing and
 -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

On Sat, 25 Apr 2009, edwintorok at gmail dot com wrote:

> 
> 
> --- Comment #2 from edwintorok at gmail dot com  2009-04-25 13:49 ---
> (In reply to comment #1)
> > Casting through a union (2)
> > 
> > describes an invalid way of doing type-punning.
> 
> There is also a citation from C99 on that page:
> "An object shall have its stored value accessed only by an lvalue expression
> that has one of the following types:
> 
> * a type compatible with the effective type of the object,
> * a qualified version of a type compatible with the effective type of the
> object,
> * a type that is the signed or unsigned type corresponding to the 
> effective
> type of the object,
> * a type that is the signed or unsigned type corresponding to a qualified
> version of the effective type of the object,
> * an aggregate or union type that includes one of the aforementioned types
> among its members (including, recursively, a member of a subaggregate or
> contained union), or
> * a character type."
> 
> I'm casting to a union that has both types as members, why doesn't that fit
> under the 5th case in the above quote?

Because it is certainly backwards.

> Also there is a warning for foo(), but there is no warning for bar(), but I
> think they are exactly the same things wrt to violating or not the aliasing
> rules.
> 
> > 
> > The only conforming and portable way is
> > 
> > unsigned bar(char *x)
> > {
> > unsigned un;
> > memcpy (&un, x, sizeof (un));
> > return un;
> > }
> 
> That may be too slow for me, I'll go with a static inline function that takes 
> a
> void* instead of a macro that does the cast.

The above is properly optimized.  Why do you think that an inline
function taking void * would fix anything?

Richard.


-- 


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

[Bug fortran/39893] gfortran ICE on invalid program

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-04-25 13:57 ---
Reduced test case:

  SUBROUTINE XAUTOGET()
  CHARACTER*(*) DICBA
  DATA DICBA /"CLIP" /
  RETURN
  END

The line "DATA DICBA /"CLIP" /" is needed to get the ICE.


-- 


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

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

--- Comment #2 from edwintorok at gmail dot com  2009-04-25 13:49 ---
(In reply to comment #1)
> Casting through a union (2)
> 
> describes an invalid way of doing type-punning.

There is also a citation from C99 on that page:
"An object shall have its stored value accessed only by an lvalue expression
that has one of the following types:

* a type compatible with the effective type of the object,
* a qualified version of a type compatible with the effective type of the
object,
* a type that is the signed or unsigned type corresponding to the effective
type of the object,
* a type that is the signed or unsigned type corresponding to a qualified
version of the effective type of the object,
* an aggregate or union type that includes one of the aforementioned types
among its members (including, recursively, a member of a subaggregate or
contained union), or
* a character type."

I'm casting to a union that has both types as members, why doesn't that fit
under the 5th case in the above quote?

Also there is a warning for foo(), but there is no warning for bar(), but I
think they are exactly the same things wrt to violating or not the aliasing
rules.

> 
> The only conforming and portable way is
> 
> unsigned bar(char *x)
> {
> unsigned un;
> memcpy (&un, x, sizeof (un));
> return un;
> }

That may be too slow for me, I'll go with a static inline function that takes a
void* instead of a macro that does the cast.

> 
> I have no opinion on the different levels of warnings (I think this case
> should be unconditionally).
> 


-- 


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

[Bug fortran/39893] gfortran ICE on invalid program

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-04-25 13:45 ---
Confirmed for gfortran 4.2.3, 4.3.3, 4.4.0, and trunk:

pr39893.f:13.25:

  CHARACTER*(*) DICBA   
 1
Error: Entity with assumed character length at (1) must be a dummy argument or
a PARAMETER
pr39893.f:16.42:

  CHARACTER*(*) ERRBAR,SSYM,SSIZ,EPAIS,FONC 
  1
Error: Entity with assumed character length at (1) must be a dummy argument or
a PARAMETER
pr39893.f:16.26:

  CHARACTER*(*) ERRBAR,SSYM,SSIZ,EPAIS,FONC 
  1
Error: Entity with assumed character length at (1) must be a dummy argument or
a PARAMETER
pr39893.f:16.47:

  CHARACTER*(*) ERRBAR,SSYM,SSIZ,EPAIS,FONC 
   1
Error: Entity with assumed character length at (1) must be a dummy argument or
a PARAMETER
pr39893.f:16.36:

  CHARACTER*(*) ERRBAR,SSYM,SSIZ,EPAIS,FONC 
1
Error: Entity with assumed character length at (1) must be a dummy argument or
a PARAMETER
pr39893.f:16.31:

  CHARACTER*(*) ERRBAR,SSYM,SSIZ,EPAIS,FONC 
   1
Error: Entity with assumed character length at (1) must be a dummy argument or
a PARAMETER
pr39893.f:23.26:

  DATA CLIP  , ERRBAR,   JOIN  ,  SSYM  ,  SSIZ  ,  EPAIS  ,
  1
Error: Incompatible types in DATA statement at (1); attempted conversion of
INTEGER(4) to CHARACTER(1)
pr39893.f:6: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

Summary|gfortran ICE on invalid |gfortran ICE on invalid
   |program |program


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

[Bug bootstrap/39877] stage2 error in sparc.c

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2009-04-25 13:39 
---
2009-04-20  Ian Lance Taylor  

Fix enum conversions which are invalid in C++:
* auto-inc-dec.c (attempt_change): Change 0 to SET in function call.
* calls.c (store_one_arg): Change 0 to EXPAND_NORMAL in function call.
* cse.c (hash_rtx_cb): Change 0 to VOIDmode in function call.
* dbgcnt.c (dbg_cnt_set_limit_by_name): Add cast to enum type.
* dbxout.c (dbxout_symbol): Change 0 to VOIDmode in function call.
(dbxout_parms): Likewise.
* df-core.c (df_set_flags): Change changeable_flags parameter to int.
(df_clear_flags): Likewise.
* df-problems.c (df_rd_bb_local_compute_process_def): Change
top_flag parameter to int.
(df_chain_create_bb_process_use): Likewise.
(df_chain_add_problem): Change chain_flags parameter to unsigned int.
Remove cast.
* df-scan.c (df_ref_create): Change ref_flags parameter to int.
(df_ref_create_structure, df_def_record_1): Likewise.
(df_defs_record, df_uses_record, df_get_call_refs): Likewise.
(df_notes_rescan): Change 0 to VOIDmode in function call.
(df_get_call_refs, df_insn_refs_collect): Likewise.
(df_bb_regs_collect): Likewise.
(df_entry_block_defs_collect): Likewise.
(df_exit_block_uses_collect): Likewise.
* df.h: Update declarations.
* double-int.c (double_int_divmod): Add cast to enum type.
* dse.c (replace_inc_dec): Reverse parameters to gen_int_mode.
* dwarf2out.c (new_reg_loc_descr): Add casts to enum type.
(based_loc_descr): Likewise.
(loc_descriptor_from_tree_1): Change first_op and second_op to
enum dwarf_location_atom.  Add cast to enum type.
* expmed.c (init_expmed): Change 0 to SET in function call.
* expr.c (init_expr_target): Change 0 to VOIDmode in function call.
(expand_expr_real_1): Change 0 to EXPAND_NORMAL in function call.
(do_store_flag): Likewise.
* fixed-value.h (struct fixed_value): Change mode to enum
machine_mode.
* function.c (assign_parms): Change 0 to VOIDmode in function call.
* genautomata.c (insert_automaton_decl): Change 1 to INSERT in
function call.
(insert_insn_decl, insert_decl, insert_state): Likewise.
(automata_list_finish): Likewise.
* genrecog.c (process_define_predicate): Add cast to enum type.
* gensupport.c (init_predicate_table): Add cast to enum type.
* gimple.c (gimple_build_return): Change 0 to ERROR_MARK in
function call.
(gimple_build_call_1, gimple_build_label): Likewise.
(gimple_build_goto, gimple_build_asm_1): Likewise.
(gimple_build_switch_1, gimple_build_cdt): Likewise.
* gimple.h (GIMPLE_CHECK): Change 0 to ERROR_MARK in function call.
(enum fallback): Rename from enum fallback_t.
(fallback_t): Typedef as int.
* gimple-low.c (lower_builtin_setjmp): Change TSI_SAME_STMT to
GSI_SAME_STMT in function call.
* ira.c (setup_class_subset_and_memory_move_costs): Add casts to
enum type.
(setup_reg_class_relations): Likewise.
(setup_reg_class_nregs): Change cl to int.  Add casts to enum type.
(setup_prohibited_class_mode_regs): Add cast to enum type.
(setup_prohibited_mode_move_regs): Likewise.
* ira-costs.c (record_reg_classes): Change rclass to enum reg_class.
(record_address_regs): Change i to enum reg_class.
* lists.c (alloc_EXPR_LIST): Add cast to enum type.
* machmode.h (GET_MODE_CLASS): Cast value to enum mode_class.
(GET_MODE_WIDER_MODE): Cast value to enum machine_mode.
(GET_MODE_2XWIDER_MODE): Likewise.
(GET_CLASS_NARROWEST_MODE): Likewise.
* omp-low.c (expand_omp_for): Add cast to enum type.
* optabs.c (debug_optab_libfuncs): Add casts to enum type.
* opts.c (enable_warning_as_error): Change kind to diagostic_t.
* postreload.c (reload_cse_simplify_operands): Change rclass local
to enum reg_class.
* predict.c (combine_predictions_for_insn): Change best_predictor
and predictor to enum br_predictor.
(combine_predictions_for_bb): Likewise.
(build_predict_expr): Change assignment to PREDICT_EXPR_OUTCOME to
use SET_PREDICT_EXPR_OUTCOME.
* real.c (real_arithmetic): Change icode to code in function call.
* reginfo.c (init_move_cost): Add casts to enum type.
(init_reg_sets_1, init_fake_stack_mems): Likewise.
* regmove.c (regclass_compatible_p): Change class0 and class1 to
enum reg_class.
* reload.c (find_valid_class): Add casts to enum type.
(push_reload): Change 0 to NO_REGS in function call.
(find_reloads): Change this_alternative to array of enum
reg_class.  Remove some now-unnecessary 

[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-04-25 13:38 ---
Casting through a union (2)

describes an invalid way of doing type-punning.

The only conforming and portable way is

unsigned bar(char *x)
{
unsigned un;
memcpy (&un, x, sizeof (un));
return un;
}

I have no opinion on the different levels of warnings (I think this case
should be unconditionally).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2009-04-25 13:38:51
   date||


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

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-04-25 13:38 ---
If you compile the code in comment #1 with '-fbounds-check', you get:

At line 32 of file pr39894.f90
Fortran runtime error: Array bound mismatch, size mismatch for dimension 2 of
array 'listgeonm' (18/999)

(off by one, see pr39872). So the code is invalid and have to be fixed as
noticed in comment #1. Note that I don't see the "memory corruption" on
i686-apple-darwin9, but this is pure luck.


-- 


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

[Bug bootstrap/39645] uninitialized variable in genattrtab.c

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2009-04-25 13:36 
---
This should compile now.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||04/msg01984.html
 Status|ASSIGNED|RESOLVED
  GCC build triplet|sparc-unknown-linux-gnu |sparc*-*-*
   GCC host triplet|sparc-unknown-linux-gnu |sparc*-*-*
 GCC target triplet|sparc-unknown-linux-gnu |sparc*-*-*
 Resolution||FIXED
Summary|genattrtab.c does not   |uninitialized variable in
   |compile under sparc Linux   |genattrtab.c
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2009-04-25 13:32 
---
Subject: Bug 39645

Author: ebotcazou
Date: Sat Apr 25 13:32:43 2009
New Revision: 146772

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146772
Log:
PR bootstrap/39645
* config/sparc/sparc.c (sparc_gimplify_va_arg): Set TREE_ADDRESSABLE
on the destination of memcpy.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c


-- 


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

[Bug fortran/39896] New: ICE with -fwhole-file

[dfranke at gcc dot gnu dot org]

The code below (extracted from a large application) gives an ICE if compiled
with -fwhole-file. 

$> cat ice.for
  PROGRAM xxx
  implicit Real*8 (a-h,o-z)

  PARAMETER   ( NU= 512*101 + 10*101 + 2*512 )

  DIMENSIONAJ(2048)
  DIMENSIONAIS(512), ER1(512)
  DIMENSIONU(NU), U2(NU)

  CALL PTIC10(U,U2,ER1,NR0,N,AJ,AIS)
 456  CONTINUE
  GO TO 456
  END

  SUBROUTINE PTIC10(A,A1,ER,N,M,AJ,AIS)
  implicit real*8 (a-h,o-z)
  DIMENSION ER(M),A(M,N),A1(M,N),AJ(M),AIS(M)
  END

$> gfortran-svn -c -fwhole-file ice.for
f951: internal compiler error: Segmentation fault

$> gfortran-svn -v
gcc version 4.5.0 20090424


-- 
   Summary: ICE with -fwhole-file
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org


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

[Bug middle-end/39887] g++ incorrectly reports type error when calling spu_promote()

[jadamcze at utas dot edu dot au]

--- Comment #2 from jadamcze at utas dot edu dot au  2009-04-25 13:31 
---
So it was - and it was me that reported it in bug 36837.  (in this case, I'm
building with a Gentoo 4.3.3 compiler)

As you can see (amongst the noise) in the other bug, I was able to reproduce
the bug using fsf gcc-4.3.1 to build a mainline compiler (and I've confirmed
that it still happens with the head of the gcc-4.4 branch and mainline).

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


-- 

jadamcze at utas dot edu dot au changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/36837] x86_64 linux-gnu gcc miscompiles spu-elf gcc (4.4)

[jadamcze at utas dot edu dot au]

--- Comment #11 from jadamcze at utas dot edu dot au  2009-04-25 13:31 
---
*** Bug 39887 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/39895] New: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3

[edwintorok at gmail dot com]

Considering this code:
void dummy(void *x);
union union_t {
unsigned un;
char c;
} __attribute__((packed));

unsigned foo()
{
char x[4];
dummy(x);
return ((union union_t*)x)->un;
}

unsigned bar(char *x)
{
return ((union union_t*)x)->un;
}

With gcc-4.4 -Wstrict-aliasing=1 is the only one that does *not* give a
warning, levels 2 and 3 do give warnings:
$ gcc-4.4 -Wstrict-aliasing p.c -O2 -c
p.c: In function ‘foo’:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing 
rules
$ gcc-4.4 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function ‘foo’:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ gcc-4.4 -Wstrict-aliasing=1 p.c -O2 -c

However in the case of gcc-4.3, -Wstrict-aliasing=2 is the only one that gives
warnings, levels 1 and 3 give no warning:
$ gcc-4.3 -Wstrict-aliasing p.c -O2 -c
$ gcc-4.3 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function ‘foo’:
p.c:11: warning: dereferencing type-punned pointer might break strict-aliasing
rules
$ gcc-4.3 -Wstrict-aliasing=1 p.c -O2 -c


According to the gcc manpage -Wstrict-aliasing=3 should have the fewest false
positives and false negatives, yet with gcc-4.4 -Wstrict-aliasing=3 gives a
warning that is not given at -Wstrict-aliasing=1 (the one that is supposed to
have many false positives).

This only happens if 'x' is allocated on the stack, gcc-4.4 is perfectly happy
if it is a char* argument to the function.

I've also tried the 'Casting through a union (1)' described at
http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
but that too gives warnings by default.

Conclusion is that with gcc-4.4 -O2 -Wall there is no way to read/store from a
stack allocated variable through a union, using a different type member of the
union without raising a warning. 

Is there another recommended way in gcc-4.4 to cast from uint8_t* to uint32_t*?


-- 
   Summary: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3
behaves like -Wstrict-aliasing=2 in gcc-4.3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-04-25 13:13 
---
Testing a fix.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|laurent at guerby dot net   |ebotcazou at gcc dot gnu dot
   ||org


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

[Bug fortran/39894] memory corruption with array section assignment of arrays with different shape

[deji_aking at yahoo dot ca]

--- Comment #1 from deji_aking at yahoo dot ca  2009-04-25 12:32 ---
Created an attachment (id=17692)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17692&action=view)
Test program

gfortran work fine if I change the line;
'listgeonm(1,:) = geonm(:,1)'

to
'listgeonm(1,:) = geonm(1:p_bgeo_top,1)'


-- 


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

[Bug objc/35165] Massive failures of objc on i686-apple-darwin9

[developer at sandoe-acoustics dot co dot uk]

--- Comment #5 from developer at sandoe-acoustics dot co dot uk  2009-04-25 
12:32 ---
AFAICT there are a number of factors causing this and darwin8 is also affected.

A (certainly non-comprehensive) list of issues:

Darwin 8  (OSX 10.4.11)
(Objc)
There is no 64 bit NeXT runtime.
(Obj-c++) 
local symbol label issue (radar: 5202926)
There is no 64 bit NeXT runtime.

Darwin 9 (OSX10.5.6)
ObjC
-m32
The darwin 9 NeXT headers assume the availability of language enhancements
present in Apple's 4.2 local release, but not in currently in gcc.
specifically, __attribute__ extensions. (OBJC2_UNAVAILABLE expands to use this)

Some interfaces are declared deprecated - which causes test failures owing to
unexpected warnings.

a few tests require -mdynamic-no-pic

-m64
all the m32 issues +
no 64 bit "Object" class implementation.
also some of the "deprecated" interfaces m32 are "not available" at m64

ObjC++
all the ObjC issues +
local symbol label issue (radar: 5202926)

---

Part 0 of some work to deal with this is about to be posted to gcc-patches.

- don't try to execute NeXT m64 on darwin 5..8 (whilst retaining the ability to
test -fgnu-runtime)
- fix the local label issue.

Iain.


-- 

developer at sandoe-acoustics dot co dot uk changed:

   What|Removed |Added

 CC||developer at sandoe-
   ||acoustics dot co dot uk


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

[Bug fortran/39894] New: memory corruption with array section assignment of arrays with different shape

[deji_aking at yahoo dot ca]

The attached program produce memory corruption at runtime because of an
expression between 2 arrays of different shape using array section. I'm not
sure if it is standard conforming or not, so I'm reporting it as a bug; the
program executes OK with pgf90 and ifort (on Linux) and xlf90 (on AIX).


-- 
   Summary: memory corruption with array section assignment of
arrays with different shape
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deji_aking at yahoo dot ca


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

[Bug c/39892] -fno-function-cse not working

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-04-25 12:22 ---
MOUSE.function.print_field is not a constant function.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|-fno-function-cse not   |-fno-function-cse not
   |working |working


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

[Bug fortran/39893] gfortran ICE on invalid program

[deji_aking at yahoo dot ca]

--- Comment #1 from deji_aking at yahoo dot ca  2009-04-25 12:16 ---
Created an attachment (id=17691)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17691&action=view)
invalid program


-- 


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

[Bug fortran/39893] New: gfortran ICE on invalid program

[deji_aking at yahoo dot ca]

The attached program produce an internal compiler error when compiled with
gfortran-4.4.0.


-- 
   Summary: gfortran ICE on invalid program
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deji_aking at yahoo dot ca


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

[Bug c/39892] New: -fno-function-cse not working

[etienne_lorrain at yahoo dot fr]

The function MOUSE.function.print_field() is not always called directly
but its pointer is copied in a register and a call to the content of
the register is done. The register is not reused at all.
 Causes problems with an assembler post-processor.

$ /home/etienne/projet/toolchain/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c --with-gmp=/home/etienne/projet/toolchain
Thread model: posix
gcc version 4.4.0 (GCC) 
$ /home/etienne/projet/toolchain/bin/gcc -fno-builtin -fverbose-asm
-fno-function-cse -Os -Wall -S -o m.S m1.c
$ grep "MOUSE.function.print_field" m.S
call*MOUSE+32   # MOUSE.function.print_field
movlMOUSE+32, %esi  # MOUSE.function.print_field, D.2606
$ grep "call.*\*%esi" m.S
call*%esi   # D.2606
$ cat m1.c
typedef struct {
unsigned char jmpinstruction[2];
unsigned char EBIOSaccess;
unsigned char String[8];
unsigned short Bytepersector;
unsigned char Sectorpercluster;
unsigned short Reservedsector;
unsigned char NbFAT;
unsigned short NbRootdirentry;
unsigned short NbTotalsector;
unsigned char Mediadescriptor;
unsigned short NbSectorperFAT;
unsigned short NbSectorpertrack;
unsigned short NbHead;
unsigned NbHiddensector;
unsigned NbTotalsector2;
} __attribute__ ((packed, aligned(1))) FAT_bootsect1_t;

typedef struct {
unsigned NbSectorperFAT2;
struct FAT32_flags_str {
 unsigned short active_fat : 4;
 unsigned short reserved1 : 3;
 unsigned short one_fat_active : 1;
 unsigned short reserved2 : 8;
 } __attribute__ ((packed)) flags;
unsigned short version;
unsigned root_cluster;
unsigned short FSinfosector;
unsigned short save_bootrecord;
unsigned char reserved[12];
} __attribute__ ((packed, aligned(1))) FAT32_bootsect_t;

typedef struct {
unsigned char PhysicaldriveNb;
unsigned char dirty_flag : 1;
unsigned char surface_scan : 1;
unsigned char FATreserved : 6;
unsigned char Signaturebyte0x29;
unsigned VolumeserialNb;
unsigned char Volumelabel[11];
unsigned char FileSysName[8];
} __attribute__ ((packed, aligned(1))) FAT_bootsect2_t;

typedef struct {
FAT_bootsect1_t part1;
FAT_bootsect2_t part2;
} __attribute__ ((packed, aligned(1))) bootbefore_t;

typedef struct {
FAT_bootsect1_t part1;
FAT32_bootsect_t partFAT32;
FAT_bootsect2_t part2;
} __attribute__ ((packed, aligned(1))) bootbefore_FAT32_t;

typedef struct {
struct {
 unsigned short next;
 unsigned short checksum;
 unsigned short nbword;
 } __attribute__ ((packed)) header;

union diskcmd {
 struct diskcmd_bios {
 unsigned short reg_dx;
 unsigned short reg_ax;
 unsigned short reg_cx;
 unsigned short dummy;
 unsigned long will_be_set_to_esbx;
 } __attribute__ ((packed)) int1302;
 struct diskcmd_ebios {
 unsigned short reg_dx;
 unsigned short reg_ax;
 unsigned char cst_16;
 unsigned char cst_0;
 unsigned char nb_block;
 unsigned char cst2_0;
 unsigned short offset, segment;
 unsigned long long lba;
 } __attribute__ ((packed)) int1342;
 struct diskcmd_hard {
 unsigned short ide_dcr_address;
 unsigned short reg_ax;
 unsigned short base_ide_plus7;
 unsigned char lba_head;
 unsigned char lba48_cylinder_high;
 unsigned char lba48_cylinder_low;
 unsigned char lba48_sector;
 unsigned char lba48_nb_sect;
 unsigned char cylinder_high;
 unsigned char cylinder_low;
 unsigned char sector;
 unsigned char nb_sect;
 unsigned char ide_command;
 unsigned short nb_sect_read;
 unsigned short sector_size_div2;
 } __attribute__ ((packed)) hardide;
 } bootloader2_cmd;
} __attribute__ ((packed, aligned(1))) bootloader2_t;

enum gujin_param_attrib_enum {
enum_verbose, enum_lock_bpp, enum_lock_text_graphic, enum_menu_with_disk,
enum_menu_with_parttype, enum_menu_with_partition, enum_menu_with_initrd,
enum_force_textmode, enum_ATA_protect_partition, enum_force_probe_root,
enum_IDE_in_BIOS_order, enum_ignore_kernel_option, enum_disk_write_enable,
enum_hide_unhide_partitions, enum_VGA_interface, enum_download_ansi_font,
enum_VESA_interface, enum_enable_VESA_hardwin, enum_VESA2_interface,
enum_enable_joystick, enum_search_disk_mbr, enum_search_part_mbr,
enum_keep_all_part_mbr, enum_search_el_torito, enum_search_topdir_files,
enum_search_subdir_files, enum_probe_bios_floppy_disk,
enum_probe_bios_hard_disk, enum_probe_ide_disk, enum_probe_cdrom,
enum_probe_dos_disk,
enum_gujin_param_attrib_end
};

typedef struct {
unsigned magic;
unsigned short version;
struct gujin_param_compilation_attrib {
 unsigned short vga_support : 1;
 unsigned short big_malloc : 1;
 unsigned short bios_only : 1;
 unsigned short initrd_loader : 1;
 unsigned short vmlinuz_loader : 1;
 unsigned short elf_loader : 1;
 unsigned short multiboot_loader : 1;

[Bug fortran/39890] Link of a large application fails with spurious multiple symbol definition

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-04-25 11:18 ---
> Also, I omitted the link invocation:
> gfortran -O3 -o (exe_name) (big honkin' list of object files)

Can you double check that in the "big honkin' list of object files" the file
"nucleation.o" is listed only once?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug libstdc++/39882] error_code constructor and assignment postconditions not met

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-04-25 11:14 
---
On it.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-25 11:14:27
   date||


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

[Bug libstdc++/39881] error_condition constructor and assignment postconditions not met

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-04-25 11:14 
---
On it.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-25 11:14:04
   date||


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

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-04-25 11:13 ---
The location is also "correct" in the sense that we try to warn with the
location
of the _dereference_.  And that is indeed in APSInt& APSInt::operator=(const
APSInt&):

 (void) (((struct APSInt *) this)->D.1723 = *(const struct APInt &) &((const
struct APSInt *) RHS)->D.1723)

the pointer initialization point is that of the call - we dereference a
type-pun of the this pointer in Val.getInt().

I have some improvements though - trying to get rid of '' most
of the time.  The improved version would look like

t.ii: In function 'bool foo()':
t.ii:8: warning: dereferencing type-punned pointer '& Val.APValue::Data' does
break strict-aliasing rules
t.ii:26: note: initialized from here

I don't know if that is more useful though - the &Val.APValue::Data expression
does not appear literally in the program either.

Note that getInt is completely inlined and there is no location involving
that function available anymore :/  The difficulties of C++ and late
diagnostics ...


-- 


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

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-04-25 11:13 
---
Ok, then it's easy.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED


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

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

[chris_kohlhoff at internet-mail dot org]

--- Comment #3 from chris_kohlhoff at internet-mail dot org  2009-04-25 
11:03 ---
It's the intended behaviour that the conversion constructor and assignment
operator be disabled. That is, the std::errc type should not be implicitly
convertible to error_code, only to error_condition.

If users want to create an error_code from a std::errc then they can use
make_error_code():

  error_code ec = make_error_code(errc::not_supported);

In a nutshell, ErrorConditionEnum concept means implicitly convertible to
error_condition but no implicit conversion to error_code. Likewise
ErrorCodeEnum means implicitly convertible to error_code but not to
error_condition.

(N.B. bugs 39881 and 39882 also have to be fixed to make this conversion work.)


-- 

chris_kohlhoff at internet-mail dot org changed:

   What|Removed |Added

 Status|WAITING |NEW


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

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-04-25 10:41 ---
Thanks for the short testcase.  I'll try to improve the location information.

The compiler at the point of the warning sees

  D.1756_5 = (struct APSInt &) &Val.Data;
  AdditionalOffset.D.1723 = D.1756_5->D.1723;

and complains about dereferencing D.1756_5 which is of type APSInt * but
the object that is accessed is of type void *.  So yes, this is an alias
violation.

What you probably want to do is sth like

class APValue {
private:
  char Data[sizeof(APSInt)];
public:
  APSInt &getInt() {
return *(new (Data) APSInt);
  }
};

to be conforming.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2009-04-25 10:41:02
   date||


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

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-04-25 09:52 
---
If we do this, I don't see how the error_code constructor and assignment
operator taking an ErrorCodeEnum can be made to work, that this how they can
actually accept a std::errc (I'm referring to n2723 and n2798, basically).


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

[edwintorok at gmail dot com]

--- Comment #1 from edwintorok at gmail dot com  2009-04-25 09:39 ---
Created an attachment (id=17690)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17690&action=view)
testcase


-- 


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

[Bug middle-end/39891] New: Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules

[edwintorok at gmail dot com]

Compile attached testcase using:
$ g++-4.4 -c -O1 -fstrict-aliasing -Wstrict-aliasing foo.i
foo.i: In function ‘bool foo()’:
foo.i:8: warning: dereferencing pointer ‘’ does break
strict-aliasing rules
foo.i:26: note: initialized from here

Line 8 has this:
7: APSInt &operator=(const APSInt &RHS) {
8:APInt::operator=(RHS);

Line 26 has this:
26: AdditionalOffset = Val.getInt();

None of these violate the strict aliasing rules.
The only place that could violate the strict aliasing rules in the testcase is 
at line 17:
14: void *Data[sizeof(APSInt)];
15: public:
16: APSInt &getInt() {
17:return *(APSInt*)(void*)Data;

g++ 4.3.3 doesn't give any warning, neither does g++ 4.2.4.

I think this is a bug because:
- the warning is not given at the place that (possibly) violates the strict
aliasing rules, but at the place where the pointer obtained by violating the
rules is dereferenced.
- removing line 26 silences the warning, and no warning given for getInt or
operator= anymore

Also does the construct at line 17 really violate the aliasing rules?

$ g++-4.4 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.0-1~exp1'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.0 (Debian 4.4.0-1~exp1)


-- 
   Summary: Bogus location given for warning, no warning at real
location: dereferencing pointer ‘’ does break
strict-aliasing rules
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug middle-end/39887] g++ incorrectly reports type error when calling spu_promote()

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-25 09:27 ---
What compiler is running on x86-64?  The last time I looked into a bug like
this, it was a bug in the native compiler.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |middle-end


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

[Bug libstdc++/39880] Specialisation is_error_code_enum should not exist

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-04-25 09:13 
---
Agreed. This is going to change a lot with concepts, of course, but in the old
n2521 for instance the specialization doesn't exist indeed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-25 09:13:53
   date||


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

[Bug inline-asm/39590] inline asm %z on amd64 says "ll" instead of "q"

[ubizjak at gmail dot com]

--- Comment #13 from ubizjak at gmail dot com  2009-04-25 08:23 ---
Fixed for 4.5.0.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug fortran/39688] IMPORT of derived type fails

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-04-25 08:13 ---
Fixed in r146762. 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=39688

[Bug fortran/39688] IMPORT of derived type fails

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-04-25 08:12 ---
Subject: Bug 39688

Author: janus
Date: Sat Apr 25 08:11:48 2009
New Revision: 146762

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146762
Log:
2009-04-25  Janus Weil  

PR fortran/39688
* decl.c (gfc_match_import): Use 'sym->name' instead of 'name'.
They differ if the symbol has been use-renamed.


2009-04-25  Janus Weil  

PR fortran/39688
* gfortran.dg/import7.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/import7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug inline-asm/39590] inline asm %z on amd64 says "ll" instead of "q"

[uros at gcc dot gnu dot org]

--- Comment #12 from uros at gcc dot gnu dot org  2009-04-25 08:11 ---
Subject: Bug 39590

Author: uros
Date: Sat Apr 25 08:10:51 2009
New Revision: 146761

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146761
Log:
PR target/39590
* configure.ac (HAVE_AS_IX86_FILDQ): On x86 targets check whether
the configured assembler supports fildq and fistpq mnemonics.
(HAVE_AS_IX86_FILDS): Rename from HAVE_GAS_FILDS_FISTS.
* configure: Regenerated.
* config.in: Ditto.

* config/i386/i386.c (print_operand): Handle 'Z'.
['z']: Remove handling of special fild/fist suffixes.
(output_fix_trunc): Use '%Z' to output suffix of fist{,p,tp} insn.
* config/i386/i386.md (*floathi2_i387): Use '%Z' to output
suffix of fild insn.
(*floatsi2_vector_mixed): Ditto.
(*float2_mixed_interunit): Ditto.
(*float2_mixed_nointerunit): Ditto.
(*float2_i387_with_temp): Ditto.
(*float2_i387): Ditto.
* config/i386/gas.h (GAS_MNEMONICS): Remove.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/i386/gas.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/configure
trunk/gcc/configure.ac


-- 


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