[Bug fortran/41113] spurious _gfortran_internal_pack

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2009-08-21 06:15 ---
(In reply to comment #3)
> I have another example, I will file it as a different PR, but make a
> 'cross-link'

PR 41137



-- 


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

[Bug fortran/41137] New: inefficient zeroing of an array

[jv244 at cam dot ac dot uk]

triggered by some discussion in PR41113

SUBROUTINE S(a,n)
INTEGER :: n
REAL :: a(n,n,n,n)
a(:,:,:,:)=0.0
END SUBROUTINE

generates a four-fold look to do the zeroing, while it would be more efficient
to zero n**4 elements starting from a(1,1,1,1). I.e. since a is contiguous in
memory a memset or similar can be done (properly guarded for zero-sized
arrays).

Note that the case with compile time constant bounds is already captured i.e. 

.LFB2:
movl$4, %edx
xorl%esi, %esi
jmp memset
.LFE2:

is generated for 

SUBROUTINE S(a)
REAL :: a(10,10,10,10)
a(:,:,:,:)=0.0
END SUBROUTINE


-- 
   Summary: inefficient zeroing of an array
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug fortran/41113] spurious _gfortran_internal_pack

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2009-08-21 06:09 ---
(In reply to comment #2)
> which returns "false". It gets quite complicated if we want to handle:
>foo(1)%bar(1:1)%variable(:)(sub:string)

AFAICT this is already handled fine:
write(6,*) foo(1)%bar(1:1)%variable(:)(2:4)
 1
Error: Two or more part references with nonzero rank must not be specified at
(1)

> Attached patch does the first steps, but it needs some improvements to handle 
> "sym" and "comp" correctly. "sym->" appears all over the place in the rest of
> the function and it needs to be properly handled.  (NOTE: The attached patch
> will not work!)

I believe that some function which can find if an expression is really  a
contiguous array in memory is pretty useful. In the end, many optimization
(also vectorization) relies on that.

I have another example, I will file it as a different PR, but make a
'cross-link'


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

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


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

[Bug boehm-gc/34232] bootstrap fails when libgcj enabled due to undefined reference in libgcjgc (boehm-gc)

[davek at gcc dot gnu dot org]

--- Comment #1 from davek at gcc dot gnu dot org  2009-08-21 02:26 ---
Was fixed in 

http://gcc.gnu.org/viewcvs?view=revision&revision=147641


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...

[davek at gcc dot gnu dot org]

--- Comment #11 from davek at gcc dot gnu dot org  2009-08-21 02:23 ---
This has been fixed now since these two revisions were applied:

http://gcc.gnu.org/viewcvs?view=revision&revision=146627
http://gcc.gnu.org/viewcvs?view=revision&revision=146869

These days libjava builds fine with --enable-libgcj-debug.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libgcj/30570] Word "DEBUG" used as a variable in VMAccessController.java breaks build

[davek at gcc dot gnu dot org]

--- Comment #9 from davek at gcc dot gnu dot org  2009-08-21 02:20 ---


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


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...

[davek at gcc dot gnu dot org]

--- Comment #10 from davek at gcc dot gnu dot org  2009-08-21 02:20 ---
*** Bug 30570 has been marked as a duplicate of this bug. ***


-- 


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

[Bug bootstrap/41136] New: ld picks up multiple definitions of *fstat*

[t66667 at gmail dot com]

x86_64-w64-mingw32-gcc  -fomit-frame-pointer -D__USE_MINGW_ACCESS -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-s -o cc1-dummy.exe c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o
c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o
c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o
c-pch.o c-parser.o i386-c.o msformat-c.o c-gimplify.o tree-mudflap.o
c-pretty-print.o c-omp.o dummy-checksum.o \
  main.o  libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -L/home/linux/usr/win64/lib -lcloog
-L/home/linux/usr/win64/lib -lppl_c -lppl -lgmpxx -lstdc++
-L/home/linux/usr/win64/lib -L/home/linux/usr/win64/lib -lmpfr -lgmp
/home/linux/local/gcc-4.4.1-w64/mingw/lib64/libmingwex.a(lib64_libmingwex_a-_fstat64i32.o):_fstat64i32.c:(.text+0xb0):
multiple definition of `__fstat64i32'
/home/linux/local/gcc-4.4.1-w64/lib/gcc/x86_64-w64-mingw32/4.4.1/libstdc++.a(basic_file.o):basic_file.cc:(.text$_fstat64i32[__fstat64i32]+0x0):
first defined here
/home/linux/local/gcc-4.4.1-w64/mingw/lib64/libmingwex.a(lib64_libmingwex_a-_fstat64i32.o):_fstat64i32.c:(.text+0x130):
multiple definition of `_fstat'
/home/linux/local/gcc-4.4.1-w64/lib/gcc/x86_64-w64-mingw32/4.4.1/libstdc++.a(basic_file.o):basic_file.cc:(.text$fstat[_fstat]+0x0):
first defined here
collect2: ld returned 1 exit status
make: *** [cc1-dummy.exe] Error 1

Trying to cross compile a gcc-4.4.1 release, win64 native compiler from Linux.
The bootstrap process failed here while trying to build a win64 native compiler
from a x86_64-w64-mingw32 cross compiler under Linux.


-- 
   Summary: ld picks up multiple definitions of *fstat*
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t7 at gmail dot com
 GCC build triplet: i486-slackware-linux
  GCC host triplet: x86_64-w64-mingw32
GCC target triplet: x86_64-w64-mingw32


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

[Bug c++/41135] Uninitialized variable usage warning broken

[bgamari at gmail dot com]

--- Comment #1 from bgamari at gmail dot com  2009-08-20 23:26 ---
Created an attachment (id=18408)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18408&action=view)
Warning test case


-- 


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

[Bug c++/41135] New: Uninitialized variable usage warning broken

[bgamari at gmail dot com]

Compiling the attached testcase should produce a warning, as it does with g++
4.3.2 (at least with -O or above),

$ g++-4.3 -Wall -Wextra -pedantic -ansi -O3 hi.cpp
/usr/include/bits/stdio2.h: In function ‘int main()’:
/usr/include/bits/stdio2.h:105: warning: ‘hi.array::a[1]’ is used
uninitialized in this function
hi.cpp:29: note: ‘hi.array::a[1]’ was declared here
$ 

On g++ 4.4.2, however, the compiler produces no warning,

$ g++ -Wall -Wextra -pedantic -ansi -O3 hi.cpp
$ 



$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-1ubuntu3'
--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 --enable-linker-build-id --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
--disable-werror --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.1 (Ubuntu 4.4.1-1ubuntu3)


-- 
   Summary: Uninitialized variable usage warning broken
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bgamari at gmail dot com
GCC target triplet: x86_64-linux-gnu


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

[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2009-08-20 22:40 
---
Hi Torleif,

Please check more recent versions such as 4.3.2, 4.3.3, or 4.4.0. There are
.debug_frame sections in there, but I don't know if it contains the information
that you're looking for.

Thanks,
Eric Weddington


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-20 22:40:26
   date||


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

[Bug target/35936] Cannot compile libgcc.S on avr

[eric dot weddington at atmel dot com]

--- Comment #4 from eric dot weddington at atmel dot com  2009-08-20 22:33 
---
Seems to be fixed now. Closing as WONTFIX.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug inline-asm/41133] Inline Assembler: Constraint A expected different behavior

[rth at gcc dot gnu dot org]

--- Comment #1 from rth at gcc dot gnu dot org  2009-08-20 22:28 ---
This is expected.  The "A" constraint supposed to be used for a PAIR.
This means 64-bit values in 32-bit code or 128-bit values in 64-bit code.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer

[eric dot weddington at atmel dot com]

--- Comment #9 from eric dot weddington at atmel dot com  2009-08-20 22:13 
---
According to comment #8, the problem no longer exists in gcc 4.3.2. Closing bug
as WONTFIX.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
  Known to work||4.3.2
 Resolution||WONTFIX


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

[Bug c++/41131] [4.3/4.4/4.5 Regression] non-lvalue in unary `&' wrongly accepted

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-08-20 22:04 ---
(In reply to comment #4)
> Pinski: You made TREE_STATIC CONST_DECLs? Why?

The Fortran front-end did that before I did it ... (RTH did that).


-- 


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

[Bug c++/41131] [4.3/4.4/4.5 Regression] non-lvalue in unary `&' wrongly accepted

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-08-20 22:03 ---
Pinski: You made TREE_STATIC CONST_DECLs? Why?


-- 


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

[Bug c++/41134] [4.5 regression] Variable flagged unused if only used in template function

[bangerth at gmail dot com]

--- Comment #6 from bangerth at gmail dot com  2009-08-20 21:20 ---
(In reply to comment #5)
> Why is this a regression?  Which compiler version didn't warn here?

4.3.2. Current mainline warns.


> The question is really whether we want unused variables just in the case
> where we can remove it and without further changes the program is still
> valid or if we want to detect more elaborate cases where the programmer
> can remove a variable with some extra work.

Right, and I don't have the answer. All I'm saying is: this is, in a nutshell,
one of the header files of the threading building blocks. I used to be able
to compile my program with that file included with -W -Wunused and not get
a warning, but now I do get a warning if I happen to not use the template
function that is defined in the header file.

W.


-- 


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

[Bug c++/41134] [4.5 regression] Variable flagged unused if only used in template function

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-08-20 21:11 ---
Why is this a regression?  Which compiler version didn't warn here?

The question is really whether we want unused variables just in the case
where we can remove it and without further changes the program is still
valid or if we want to detect more elaborate cases where the programmer
can remove a variable with some extra work.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug fortran/40962] Conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

[tkoenig at gcc dot gnu dot org]

--- Comment #9 from tkoenig at gcc dot gnu dot org  2009-08-20 20:56 ---
Fixed on trunk and 4.4, closing.

If anybody wants to backport the fix to 4.3, be my guest :-)


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/41134] [4.5 regression] Variable flagged unused if only used in template function

[bangerth at gmail dot com]

--- Comment #4 from bangerth at gmail dot com  2009-08-20 20:54 ---
(In reply to comment #3)
> You cannot use a static variable in a template :).

I would be unaware of that restriction. It's true that you can't use objects
with internal linkage (such as static variables) as *template arguments* but
I would be surprised if you couldn't use them in the body of a template
function. That said, this point is tangential to what I wanted to say with
this PR, and your little programs makes my point as eloquently as my original
one ;-)

W.


-- 


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

[Bug c++/41134] [4.5 regression] Variable flagged unused if only used in template function

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-08-20 20:49 ---
You cannot use a static variable in a template :).
Note the following is valid though:
namespace { int i; }
template  int f() { return i; }

And still invokes the warning:
t4.cc:1:17: warning: '::i' defined but not used


-- 


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

[Bug c++/41134] [4.5 regression] Variable flagged unused if only used in template function

[bangerth at gmail dot com]

--- Comment #2 from bangerth at gmail dot com  2009-08-20 20:47 ---
(In reply to comment #1)
> Well this is invalid code that is accepted by GCC anyways 

How so??


-- 


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

[Bug c++/41134] [4.5 regression] Variable flagges unused if only used in template function

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-08-20 20:44 ---
Well this is invalid code that is accepted by GCC anyways 


-- 


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

[Bug c++/41134] New: [4.5 regression] Variable flagges unused if only used in template function

[bangerth at gmail dot com]

Here's yet another case of a variable that is flagged as unused when it is
actually referenced. I agree that this is a corner case: the variable 
really *is* unused, the template function is not instantiated after all.
That said, this is not an uncommon idiom, the code is extracted from the
Threading Building Blocks library.

---
static int i;
template  int f() { return i; }
--

deal.II> c++ -W -Wunused -c x.cc
x.cc:1:12: warning: 'i' defined but not used


W.


-- 
   Summary: [4.5 regression] Variable flagges unused if only used in
template function
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com


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

[Bug fortran/40962] Conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2009-08-20 20:42 ---
Subject: Bug 40962

Author: tkoenig
Date: Thu Aug 20 20:42:38 2009
New Revision: 150975

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150975
Log:
2009-08-20  Thomas Koenig  

PR libfortran/40962
* iso_c_binding.c (c_f_pointer_u0):  Multiply stride by
previous stride.

2009-08-20  Thomas Koenig  

PR libfortran/40962
* c_f_pointer_tests_4.f90:  New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/c_f_pointer_tests_4.f90
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/libgfortran/ChangeLog
branches/gcc-4_4-branch/libgfortran/intrinsics/iso_c_binding.c


-- 


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

[Bug c++/41109] [4.5 regression] Argument flagged as unused despite use in sizeof()

[bangerth at gmail dot com]

--- Comment #1 from bangerth at gmail dot com  2009-08-20 20:41 ---
Jason, might this be a result of your changes to used/unused variables?
W.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug c++/41110] [4.5 regression] Wrong "unused variable" warning

[bangerth at gmail dot com]

--- Comment #1 from bangerth at gmail dot com  2009-08-20 20:40 ---
Jason, might this be a result of your changes to used/unused variables?
W.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug fortran/40962] Conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

[tkoenig at gcc dot gnu dot org]

--- Comment #7 from tkoenig at gcc dot gnu dot org  2009-08-20 20:16 ---
Subject: Bug 40962

Author: tkoenig
Date: Thu Aug 20 20:16:15 2009
New Revision: 150974

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150974
Log:
2009-08-20  Thomas Koenig  

PR libfortran/40962
* iso_c_binding.c (c_f_pointer_u0):  Multiply stride by
previous stride.

2009-08-20  Thomas Koenig  

PR libfortran/40962
* c_f_pointer_tests_4.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/iso_c_binding.c


-- 


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

[Bug inline-asm/41133] New: Inline Assembler: Constraint A expected different behavior

[andreas dot freimuth at united-bits dot de]

The documentation of the constraint A says:

"The a and d registers, as a pair (for instructions that return half the result
in one and half in the other)."

So I expect:
asm("/*  dx = 0,  ax = 1 */" :: "A" ((int32_t)1) );
asm("/* edx = 0, eax = 1 */" :: "A" ((int64_t)1) );
//asm("/* rdx = 0, rax = 1 */" :: "A" ((int128_t)1));

but the behavior of gcc is different:
with -m32 switch:
asm("/* eDX = undef, eax = 1 */" :: "A" ((int32_t)1) );
asm("/* edx = 0, eax = 1 */" :: "A" ((int64_t)1) );

with -m64 switch:
asm("/* rDX = undef, eax = 1 */" :: "A" ((int32_t)1) );
asm("/* rDX = undef, rax = 1 */" :: "A" ((int64_t)1) );

so for -m64 there is no difference between a and A


-- 
   Summary: Inline Assembler: Constraint A expected different
behavior
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andreas dot freimuth at united-bits dot de
 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=41133

[Bug c++/41131] [4.3/4.4/4.5 Regression] non-lvalue in unary `&' wrongly accepted

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-08-20 19:26 ---
Created an attachment (id=18407)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18407&action=view)
gcc45-pr41131.patch

I guess objc_build_string_object is the reason, except for that function
CONST_DECLs are only used for enumeration values in C/C++/ObjC/ObjC++.  And
that function creates a CONST_DECL and builds ADDR_EXPR on it, thus without
that lvalue_p_1 change I guess it would die with error.
Fortunately this CONST_DECL has TREE_STATIC set, while enumeration vals don't.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug c++/41131] [4.3/4.4/4.5 Regression] non-lvalue in unary `&' wrongly accepted

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-08-20 19:09 ---
(In reply to comment #1)
> This got broken by
> http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02640.html
> (the lvalue_p_1 change to handle CONST_DECL).  Unfortunately the patch didn't
> have any comments why has that been necessary.

Hmm, most likely because @"" strings are CONST_DECLS ... Which case this might
be my issue as I changed them but ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||accepts-invalid
  Known to fail||4.3.0 4.4.0 4.5.0
  Known to work||3.4.6
Summary|non-lvalue in unary `&' |[4.3/4.4/4.5 Regression]
   |wrongly accepted|non-lvalue in unary `&'
   ||wrongly accepted
   Target Milestone|--- |4.3.5


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

[Bug c++/41131] non-lvalue in unary `&' wrongly accepted

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-08-20 19:07 ---
This got broken by
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02640.html
(the lvalue_p_1 change to handle CONST_DECL).  Unfortunately the patch didn't
have any comments why has that been necessary.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/41132] internal compiler error: Segmentation fault

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-08-20 17:32 
---
This is a prerelease GCC delivered by Debian, as such problems should be
reported to Debian, in the first place. Moreover, FSF 4.1.x is not maintained
anymore.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/40962] Conversion problem for f-allocatable -> cptr -> fptr -> f-allocatable

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2009-08-20 17:16 ---
I have a patch.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-04 16:09:45 |2009-08-20 17:16:12
   date||


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

[Bug c++/41132] internal compiler error: Segmentation fault

[mathieu dot malaterre at gmail dot com]

--- Comment #1 from mathieu dot malaterre at gmail dot com  2009-08-20 
17:15 ---
Created an attachment (id=18406)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18406&action=view)
-save-temps


-- 


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

[Bug c++/41132] New: internal compiler error: Segmentation fault

[mathieu dot malaterre at gmail dot com]

I cannot compile gdcm using gcc 4.1.0 (at least the one shipped in etch:
pentium-builder).

Step to reproduce (on debian testing system):

1. sudo apt-get install pentium-builder
2. Get GDCM source (SVN)
3. Compile line is:

 /usr/bin/c++ -DgdcmDSED_EXPORTS -g -O0 -fprofile-arcs -ftest-coverage
-Wno-deprecated -W -Wall  -g -fPIC
-I/home/mmalater/Projects/Dashboards/gdcm-gcc/Source/Common
-I/home/mmalater/Projects/Dashboards/gdcm/Source/Common
-I/home/mmalater/Projects/Dashboards/gdcm/Source/DataDictionary
-I/home/mmalater/Projects/Dashboards/gdcm/Source/DataStructureAndEncodingDefinition
-I/home/mmalater/Projects/Dashboards/gdcm/Utilities
-I/home/mmalater/Projects/Dashboards/gdcm-gcc/Utilities/gdcmzlib   -o
Source/DataStructureAndEncodingDefinition/CMakeFiles/gdcmDSED.dir/gdcmItem.o -c
/home/mmalater/Projects/Dashboards/gdcm/Source/DataStructureAndEncodingDefinition/gdcmItem.cxx
/home/mmalater/Projects/Dashboards/gdcm/Source/DataStructureAndEncodingDefinition/gdcmItem.cxx:
In function ‘(static initializers for
/home/mmalater/Projects/Dashboards/gdcm/Source/DataStructureAndEncodingDefinition/gdcmItem.cxx)’:
/home/mmalater/Projects/Dashboards/gdcm/Source/DataStructureAndEncodingDefinition/gdcmItem.cxx:24:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
The bug is not reproducible, so it is likely a hardware or OS problem.

Info:
/usr/bin/c++ --version
g++.real (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ apt-cache policy pentium-builder
pentium-builder:
  Installed: 0.19
  Candidate: 0.19
  Version table:
 *** 0.19 0
500 http://ftp.fr.debian.org etch/main Packages
100 /var/lib/dpkg/status


-- 
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mathieu dot malaterre at gmail dot com


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

[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-08-20 16:26 ---
You nee to provide all the *.h, *.incnc, and *.inc needed files also.


-- 


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

[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827

[gkandhakumar at gmail dot com]

--- Comment #3 from gkandhakumar at gmail dot com  2009-08-20 15:40 ---
Created an attachment (id=18405)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18405&action=view)
it is a routine where i got the error

 Thanks for considered my problem and sorry for late reply. while running
(compiling) the program, it check all routines using the following line 
 gfortran -c -fdefault-real-8 -O2 -fcray-pointer
 and finally it produce an executable file for that particular routine.
This is failed for the routine ./util_p.f. Here util_p.o is an executable file
which i expect to produce by the program from the routine ./util_p.f. Now the
error is 

   gfortran -c -fdefault-real-8 -O2 -fcray-pointer ./util_p.f -o ./util_p.o

./util_p.f: In function ‘dot_ga’:

./util_p.f:204: internal compiler error: in emit_swap_insn, at reg-stack.c:827

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

make: *** [util_p.o] Error 1

with this i attach the routine which i got the error. If it is not enough
please contact me sir.
thank you 
kandhakumar


-- 


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[matz at gcc dot gnu dot org]

--- Comment #11 from matz at gcc dot gnu dot org  2009-08-20 15:35 ---
Fixed in r150964.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/41131] New: non-lvalue in unary `&' wrongly accepted

[sergei_lus at yahoo dot com]

According to the iso 14882:1998 5.2.5 Class member access, the following code:

class X {
public:
enum enumX { a=100 };
};
int main(void)
{
X x;
(void) &x.a;// should not compile
return  1;
}

should not compile, but with the following version of g++:
g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix
--prefix=/prj/dsp/qdsp6_aus/users/slarin/x86_gcc_4.4/bin
--enable-languages=c,c++ --disable-checking
Thread model: posix
gcc version 4.4.0 (GCC)

... it does. Also failing in 4.3.2. In 3.3.3 and 3.4.6 for example it correctly
reports the following:

g++ reduced.c
reduced.c: In function `int main()':
reduced.c:11: error: non-lvalue in unary `&'


Thank you.


-- 
   Summary: non-lvalue in unary `&' wrongly accepted
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei_lus at yahoo dot com


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

[Bug fortran/41106] [F03] Procedure Pointers with CHARACTER results

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-20 15:12:01
   date||


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

[Bug fortran/41062] [4.4 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.c:3438

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug debug/41130] GCC should emit an index of publicly named entities

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2009-08-20 14:42 ---
Created an attachment (id=18404)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18404&action=view)
First shot implementation

Implements the .debug_gnu_index section. It fully implements the proposal,
modulo the possible bugs.
For now, .debug_pubtypes and .debug_pubnames are kept around.
It patch doesn't contain any test yet. I'll update it soon with some tests.


-- 


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

[Bug ada/41122] libada multilib string parsing error

[joel at gcc dot gnu dot org]

--- Comment #4 from joel at gcc dot gnu dot org  2009-08-20 13:57 ---
Will you be applying it to 4.4 and the head?

And a thank you.  If we ever manage to meet in person, I owe you a beer, wine
or a nice dessert.  Your choice. :)


-- 


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[matz at gcc dot gnu dot org]

--- Comment #10 from matz at gcc dot gnu dot org  2009-08-20 13:48 ---
Mine.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-19 23:00:26 |2009-08-20 13:48:26
   date||


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

[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug ada/41122] libada multilib string parsing error

[bonzini at gnu dot org]

-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-20 13:22:46
   date||


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2009-08-20 13:11 ---

> Maybe r150934?

Indeed: I just verified that r150934 is the source of this regression.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||matz at suse dot de


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

[Bug ada/41122] libada multilib string parsing error

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2009-08-20 13:00 ---
Does AWK need to be set in libada/Makefile.in?  Since this works for C/C++, it
must be OK in other places.

In gcc/config/m68k/t-mlibs...

M68K_AWK = $(strip $(shell $(AWK) 'BEGIN { FS="[ \t]*[,()][ \t]*"; ORS=" " }; \
/^M68K_DEVICE/ { CPU=$$3; FLAGS=$$8; \
CPU_NAME=substr($$2,2,length($$2)-2); \
MLIB=substr($$5,2,length($$5)-2); \
if ($1) print $2 }' $(srcdir)/config/m68k/m68k-devices.def))


-- 


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[janus at gcc dot gnu dot org]

--- Comment #8 from janus at gcc dot gnu dot org  2009-08-20 12:53 ---
(In reply to comment #5)
> r150856 | domob | 2009-08-17 20:55:30 +0200 (Mon, 17 Aug 2009) | 14 lines
> r150858 | pault | 2009-08-17 22:17:12 +0200 (Mon, 17 Aug 2009) | 13 lines
> r150875 | janus | 2009-08-18 16:23:35 +0200 (Tue, 18 Aug 2009) | 16 lines

I just tried r150875, which also works on my machine (unless I messed something
up). This means that the three guys above are all fine.

Maybe r150934?


-- 


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

[Bug debug/41130] GCC should emit an index of publicly named entities

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-08-20 12:45:00
   date||


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

[Bug debug/41130] GCC should emit an index of publicly named entities

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug debug/41130] New: GCC should emit an index of publicly named entities

[dodji at gcc dot gnu dot org]

A somewhat detailed explanation of the needs and possible solution is available
at http://gcc.gnu.org/wiki/DebugGNUIndexSection .

It was posted for discussion to
http://sourceware.org/ml/archer/2009-q3/msg00105.html .


-- 
   Summary: GCC should emit an index of publicly named entities
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: dodji at gcc dot gnu dot org
ReportedBy: dodji at gcc dot gnu dot org


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-08-20 12:23 ---
(In reply to comment #5)
> but I don't dare to guess this time :-)

Awww, come on, don't be shy ;)

Seriously, though, I'd bet that r150875 is not the culprit. Not because it's
mine, but because it is completely unrelated to CHARACTER.


-- 


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2009-08-20 12:15 ---
> However, I don't see why r150825 fails for Dominique then (r150824/25 are both
> Ada-related).

The revision numbers are those recorded when I did the update, they are only an
upper bound for the relevant changes (and I don't have more precise ones).


-- 


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2009-08-20 12:07 ---
I went checking my logs in more detail. I believe revision 150854 is fine (so
sorry, my previous guess was wrong), while 150940 fails for me. That would
leave three more revs from the FE:

r150856 | domob | 2009-08-17 20:55:30 +0200 (Mon, 17 Aug 2009) | 14 lines

2009-08-17  Daniel Kraft  

r150858 | pault | 2009-08-17 22:17:12 +0200 (Mon, 17 Aug 2009) | 13 lines

2008-08-17  Paul Thomas  

r150875 | janus | 2009-08-18 16:23:35 +0200 (Tue, 18 Aug 2009) | 16 lines

2009-08-18  Janus Weil  
Paul Thomas  

but I don't dare to guess this time :-)


-- 


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

[Bug ada/41122] libada multilib string parsing error

[ludovic at ludovic-brenta dot org]

--- Comment #2 from ludovic at ludovic-brenta dot org  2009-08-20 12:04 
---
Actually, the whole awk program, which is presumably between single quotes in
the makefile, is the command which is not found.  The command should be awk.


-- 


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

[Bug target/35936] Cannot compile libgcc.S on avr

[abnikant dot singh at atmel dot com]

--- Comment #3 from abnikant dot singh at atmel dot com  2009-08-20 12:03 
---
No error observed in gcc-4.4.0,libgcc.S compiles fine for -mmcu=avr31 with the
same command line as reported in the bug


-- 


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

[Bug ada/41122] libada multilib string parsing error

[ludovic at ludovic-brenta dot org]

--- Comment #1 from ludovic at ludovic-brenta dot org  2009-08-20 12:02 
---
At first glance: the makefile seems not to be calling awk at all; the first
word is BEGIN; obviously the command BEGIN is not found.


-- 


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

[Bug fortran/41126] [4.5 Regression] internal compiler error: in gfc_conv_string_tmp

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-08-20 11:54 ---
(In reply to comment #1)
> guessing:
> 
> 2009-08-17  Janus Weil  
> 
> PR fortran/40877

This was r150823, which seems to be working for me. 

However, I don't see why r150825 fails for Dominique then (r150824/25 are both
Ada-related).


-- 


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

[Bug target/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer

[anitha dot boyapati at atmel dot com]

--- Comment #8 from anitha dot boyapati at atmel dot com  2009-08-20 09:46 
---
Created an attachment (id=18403)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18403&action=view)
Images display the contents of rx_tel_in_ptr before and after the assignment

This issue does not arise with avr-studio 4.17 (win-avr 4.3.2). The memory
contents of rx_tel_in_ptr before assignment and after increment are observed.
The contents of RXtemp got copied to the address pointed by rx_tel_in_ptr as
well as the pointer is post-incremented. Screenshots attached.


-- 


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

[Bug fortran/41121] [4.5 Regression] compile-time error when building BLAS with -fimplicit-none

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-08-20 09:36 ---
Fixed with r150957. 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=41121

[Bug fortran/41121] [4.5 Regression] compile-time error when building BLAS with -fimplicit-none

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-08-20 09:33 ---
Subject: Bug 41121

Author: janus
Date: Thu Aug 20 09:33:01 2009
New Revision: 150957

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150957
Log:
2009-08-20  Janus Weil  

PR fortran/41121
* resolve.c (resolve_symbol): Don't resolve formal_ns of intrinsic
procedures.

2009-08-20  Janus Weil  

PR fortran/41121
* gfortran.dg/intrinsic_5.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/41121] [4.5 Regression] compile-time error when building BLAS with -fimplicit-none

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-08-20 08:59 ---
(In reply to comment #4)
> does it fully fix the original, i.e. a1 and a2 shouldn't be warned for either.

It does.

Btw these 'a1' and 'a2' don't appear anywhere in dgbmv.f. I think they are the
formal arguements of MIN or MAX.


-- 


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

[Bug libstdc++/39107] Building an i686-pc-linux-gnu -> i686-pc-mingw32 crosscompiler fails on libstdc++ configure

[t66667 at gmail dot com]

--- Comment #10 from t7 at gmail dot com  2009-08-20 08:53 ---
Hi, I try to build a gcc-4.4.1 cross compiler target x86_64-w64-mingw32 from
slackware linux 12.2 (i486-slackware-linux) and is getting the same error as
this report.

Checking multilib configuration for libstdc++-v3...
Configuring in x86_64-w64-mingw32/libstdc++-v3
configure: loading cache ./config.cache
checking build system type... i686-pc-linux-gnu
checking host system type... x86_64-w64-mingw32
checking target system type... x86_64-w64-mingw32
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
...
checking for unistd.h... (cached) yes
checking for wchar.h... (cached) yes
checking for wctype.h... (cached) yes
checking for ld version... 21901
checking for ld that supports -Wl,--gc-sections... configure: error: Link tests
are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1

Tried attached patch "gcc-4.3.3-crosscompile-libstdc++.patch". Without success.

checking for ld version... 21901
checking for ld that supports --gc-sections... yes
checking for ld that supports -Wl,-z,relro... no
checking for sin in -lm... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1


-- 


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

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

[lessen42+gcc at gmail dot com]

--- Comment #18 from lessen42+gcc at gmail dot com  2009-08-20 08:49 ---
This still doesn't work on ARM either (tested with 4.4.0). The EABI only
mandates the stack be 8 byte aligned, and gcc silently clips any alignment
request above 8 bytes to 8 (so even if the stack were 16-byte aligned by
accident the variables still wouldn't be.)

Even a simple sp -= sp & (align-1) for every function with variables needing
more alignment would be faster than unaligned NEON loads/stores.


-- 

lessen42+gcc at gmail dot com changed:

   What|Removed |Added

 CC||lessen42+gcc at gmail dot
   ||com


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

[Bug fortran/41121] [4.5 Regression] compile-time error when building BLAS with -fimplicit-none

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2009-08-20 08:25 ---
(In reply to comment #3)
> Here's the fix:

does it fully fix the original, i.e. a1 and a2 shouldn't be warned for either.


-- 


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

[Bug fortran/41121] [4.5 Regression] compile-time error when building BLAS with -fimplicit-none

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-08-20 08:04 ---
Here's the fix:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 150933)
+++ gcc/fortran/resolve.c   (working copy)
@@ -10280,7 +10280,7 @@ resolve_symbol (gfc_symbol *sym)

   /* Resolve formal namespaces.  */
   if (sym->formal_ns && sym->formal_ns != gfc_current_ns
-  && !sym->attr.contained)
+  && !sym->attr.contained && !sym->attr.intrinsic)
 gfc_resolve (sym->formal_ns);

   /* Make sure the formal namespace is present.  */

Will commit as obvious after performing a regtest.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-19 15:26:19 |2009-08-20 08:04:37
   date||


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

[Bug fortran/41121] [4.5 Regression] compile-time error when building BLAS with -fimplicit-none

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-08-20 07:45 ---
Curiously, this does not happen when using the IMPLICIT NONE statement, instead
of -fimplicit-none:

  IMPLICIT NONE
  INTRINSIC MIN
  INTEGER :: I,J
  print *,MIN(I,J)
END


-- 


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

[Bug c++/13682] Compile error with cstdio: fgetpos not declared on AIX

[oliver at FreeBSD dot org]

--- Comment #8 from oliver at FreeBSD dot org  2009-08-20 07:31 ---
I fixed this on my AIX system by changing
/opt/pkg/gcc34/include/c++/3.4.6/cstdio.

I uncommented the undef's:


// Get rid of those macros defined in  in lieu of real functions.
#undef clearerr
#undef fclose
#undef feof
#undef ferror
#undef fflush
#undef fgetc
/* get db4 to compile #undef fgetpos */
#undef fgets
/* get db4 to compile #undef fopen */
#undef fprintf
#undef fputc
#undef fputs
#undef fread
/* get db4 to compile #undef freopen */
#undef fscanf
#undef fseek
/* get db4 to compile #undef fsetpos */
#undef ftell
#undef fwrite


This made db4 compile. So I guess this is of course a gcc problem because
this headers are supplied by gcc!
As in #7 stated, on AIX the functions are redefined to use the 64-Bit functions
for large-file support. #undef'ing them later removes the definition to the
64-Bit functions but only them are declared on aix when large file support is
defined.


-- 


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

[Bug fortran/41121] [4.5 Regression] compile-time error when building BLAS with -fimplicit-none

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug fortran/41129] unassociated pointers are reported as associated by associated function in types

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-08-20 07:12 ---
(In reply to comment #0)
>   type S0
>  real, dimension(:), pointer :: P   ! NLEV
>   end type S0
> 
>   type (S0) :: x0
>   write (*,*)  'x0%P', associated(x0%P)

You have never initialized the pointer x0%P. Contrary to allocatables, pointers
have three states: associated, disassociated, or undefined. And your pointer is
in the "undefined" state.

Solutions:

a) If you want to stick to Fortran 90:
Add a "NULLIFY(x0%P)" after "type(S0) :: x0"

b) Using the Fortran 95, add a default initializer to the type declaration
   type S0
  real, dimension(:), pointer :: P => NULL()
   end type S0

c) Using a post-Fortran 95 compiler, which supports technical report TR 15581
or that part of Fortran 2003:

   type S0
  real, dimension(:), ALLOCATABLE :: P
   end type S0

   if (.not. ALLOCATED (X0%P)) allocate(X0%P(...))

Using (c) has the advantage that allocatables are nicer and faster.
(Allocatables can never leak memory and have only two states - allocated and
not allocated; and as they cannot not share the memory address with another
variable, the compiler can do better optimizations and generate thus faster
code.)

While most Fortran 95 compilers offer allocatable components, I think Absoft
does not do so (yet?).

> The textbook "Fortran 90 programing,  Ellis et al" says that the absoft
> compiler is producing the correct answer

Well, the authoritative source is the Fortran standard with all the corrigenda
(and answered interpretation requests), see 
http://gcc.gnu.org/wiki/GFortranStandards for links.

I am not sure whether Ellias et al. got it wrong, described it misleadingly or
whether you have just misreading it.

(For the relevant quotes from the standard, see comment 2.)


Can we close the bug as INVALID or do you still see something which gfortran
seems to do wrongly?


-- 


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

[Bug fortran/41129] unassociated pointers are reported as associated by associated function in types

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2009-08-20 07:09 ---
the pointers are undefined and thus it is not standard conforming to ask for
their state. This is like asking if an uninitialized integer is 0 or not.

you can use

  type S0
 real, dimension(:), pointer :: P  => NULL() ! NLEV
  end type S0

to provide an 'initial value'.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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