[Bug ada/18302] ACATS test c953002 (and others) hangs

[ebotcazou at gcc dot gnu dot org]

--- Comment #17 from ebotcazou at gcc dot gnu dot org  2008-04-05 05:48 
---
> Yes, but it's still possible they might hang from time to time as bugs are
> introduced, which is fairly bad for automated testing etc.

OK, but sweeping the problem under the rug is not the solution on mainline.

> Normal dejagnu tests have a time limit; why should the ACATS testsuite be 
> different?

Probably no reason.


-- 


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

[Bug ada/18302] ACATS test c953002 (and others) hangs

[aaronavay62 at aaronwl dot com]

--- Comment #16 from aaronavay62 at aaronwl dot com  2008-04-05 05:39 
---
Yes, but it's still possible they might hang from time to time as bugs are
introduced, which is fairly bad for automated testing etc.  Normal dejagnu
tests have a time limit; why should the ACATS testsuite be different?


-- 


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

[Bug ada/18302] ACATS test c953002 (and others) hangs

[ebotcazou at gcc dot gnu dot org]

--- Comment #15 from ebotcazou at gcc dot gnu dot org  2008-04-05 05:17 
---
> Is there some reason that the proposed timeout fix that was applied to the RH
> branch can't be applied to trunk?

They work fine on other platforms than MinGW32.


-- 


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

[Bug ada/18302] ACATS test c953002 (and others) hangs

[aaronavay62 at aaronwl dot com]

--- Comment #14 from aaronavay62 at aaronwl dot com  2008-04-05 05:09 
---
A bunch of tests hang for me, some with 0% cpu, some with 100% cpu, on
i386-pc-mingw32 of 4.3.0.

Among the 0% CPU hangers is c960004

Among the 100% CPU hangers is c974013

Is there some reason that the proposed timeout fix that was applied to the RH
branch can't be applied to trunk?


-- 

aaronavay62 at aaronwl dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug target/35788] MIPS stack overflow caused by addui instruction

[brian at dessent dot net]

--- Comment #8 from brian at dessent dot net  2008-04-05 00:54 ---
Subject: Re:  MIPS stack overflow caused by addui instruction

derrick_chi at msn dot com wrote:

>I've already attached the source code I'm using, and I'm not sure of the
> version of GCC but I just recently downloaded cygwin so its got to be a fairly
> up to date version.  If there is a command I can enter to find out for sure
> please let me know, and I'll get it to you. You'll have to forgive my 
> ignorance
> I'm not an expert in using GCC.

The examples you attached are not preprocessed, and the gcc that is
included with Cygwin is a native compiler -- it produces only Cygwin
(i.e. x86 Win32) binaries.  You are using a MIPS cross compiler so the
version of the Cygwin host compiler is not relevant as it's not in use. 
What's needed is the version of the cross compiler.

Please read .


-- 


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

[Bug web/35777] no DFP announcement, no example text, very vague documentation

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-04-05 00:07 ---
(In reply to comment #4)
> > I don't see OpenMP documented there at all.
> 
> What about ?

Still not part of the C/C++ Language Extension section of the documentation.  I
filed a bug about this too, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154 I had to reopen it too.


-- 


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

[Bug web/35777] no DFP announcement, no example text, very vague documentation

[brian at dessent dot net]

--- Comment #4 from brian at dessent dot net  2008-04-04 23:53 ---
Subject: Re:  no DFP announcement, no example text, very vague 
 documentation

pinskia at gcc dot gnu dot org wrote:

> I can tell you that OpenMP has similar issues and nobody complained about that
> except for me.  DFP is actually already documented in the correctly place:
> http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Decimal-Float.html
> 
> Fixed point extension is also documented the same place:
> http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Fixed_002dPoint.html
> 
> I don't see OpenMP documented there at all.

What about ?


-- 


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

[Bug middle-end/35519] COMBINE repeating same matches and can SEG fault

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #5 from hutchinsonandy at gcc dot gnu dot org  2008-04-04 23:46 
---
Subject: Bug 35519

Author: hutchinsonandy
Date: Fri Apr  4 23:45:46 2008
New Revision: 133920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133920
Log:
PR rtl-optimization/34916
PR middle-end/35519
* combine.c (create_log_links): Do not create duplicate LOG_LINKS
between instruction pairs

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c


-- 


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

[Bug target/34916] [4.3/4.4 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #9 from hutchinsonandy at gcc dot gnu dot org  2008-04-04 23:46 
---
Subject: Bug 34916

Author: hutchinsonandy
Date: Fri Apr  4 23:45:46 2008
New Revision: 133920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133920
Log:
PR rtl-optimization/34916
PR middle-end/35519
* combine.c (create_log_links): Do not create duplicate LOG_LINKS
between instruction pairs

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c


-- 


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

[Bug ada/35829] Please add support for mips and mipsel in gnat

[ludovic at ludovic-brenta dot org]

--- Comment #3 from ludovic at ludovic-brenta dot org  2008-04-04 23:44 
---
This is the same patch that Aurelien Jarno submitted here:

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00026.html

I suggest closing this bug, as the patch has been committed to trunk.  (I don't
have permission to do so myself).


-- 


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

[Bug ada/35829] Please add support for mips and mipsel in gnat

[xavier dot grave at lovelace dot fr]

--- Comment #2 from xavier dot grave at lovelace dot fr  2008-04-04 22:56 
---
Created an attachment (id=15432)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15432&action=view)
first patch for mipsel support


-- 


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

[Bug ada/35829] Please add support for mips and mipsel in gnat

[xavier dot grave at lovelace dot fr]

--- Comment #1 from xavier dot grave at lovelace dot fr  2008-04-04 22:56 
---
Created an attachment (id=15431)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15431&action=view)
first patch for mips support


-- 


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

[Bug ada/35829] New: Please add support for mips and mipsel in gnat

[xavier dot grave at lovelace dot fr]

Here are two patches that enable mips and mipsel build with sjlj and tasking
support.

ada-mips.dpatch should be applied before ada-mipsel.dpatch

Cordially, xavier


ada-mips.dpatch

#! /bin/sh -e

# DP: add support (tasking, sjlj, ...) for mips architecture

dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdir="-d $3"
dir="$3/"
elif [ $# -ne 1 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
fi
case "$1" in
-patch)
patch $pdir -f --no-backup-if-mismatch -p0 < $0
;;
-unpatch)
patch $pdir -f --no-backup-if-mismatch -R -p0 < $0
;;
*)
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
esac
exit 0


Index: gcc/ada/Makefile.in
===
--- gcc/ada/Makefile.in.orig2008-04-04 11:17:38.721366234 +0200
+++ gcc/ada/Makefile.in 2008-04-04 11:20:47.530513605 +0200
@@ -1362,6 +1362,28 @@
   LIBRARY_VERSION := $(LIB_VERSION)
 endif

+ifeq ($(strip $(filter-out mips linux%,$(arch) $(osys))),)
+  LIBGNAT_TARGET_PAIRS = \
+  a-intnam.adshttp://www.gelato.unsw.edu.au/lxr/source/include/asm-mips/socket.h
+--  in order to find differents values
+--  This file is generated automatically, do not modify it by hand! Instead,
+--  make changes to gen-soccon.c and re-run it on each target.
+
+package GNAT.Sockets.Constants is
+
+   --
+   -- Families --
+   --
+
+   AF_INET: constant :=2; --  IPv4 address family
+   AF_INET6   : constant :=   10; --  IPv6 address family
+
+   ---
+   -- Modes --
+   ---
+
+   SOCK_STREAM: constant :=1; --  Stream socket
+   SOCK_DGRAM : constant :=2; --  Datagram socket
+
+   ---
+   -- Socket errors --
+   ---
+
+   EACCES : constant :=   13; --  Permission denied
+   EADDRINUSE : constant :=   98; --  Address already in use
+   EADDRNOTAVAIL  : constant :=   99; --  Cannot assign address
+   EAFNOSUPPORT   : constant :=   97; --  Addr family not
supported
+   EALREADY   : constant :=  114; --  Operation in progress
+   EBADF  : constant :=9; --  Bad file descriptor
+   ECONNABORTED   : constant :=  103; --  Connection aborted
+   ECONNREFUSED   : constant :=  111; --  Connection refused
+   ECONNRESET : constant :=  104; --  Connection reset by peer
+   EDESTADDRREQ   : constant :=   89; --  Destination addr
required
+   EFAULT : constant :=   14; --  Bad address
+   EHOSTDOWN  : constant :=  112; --  Host is down
+   EHOSTUNREACH   : constant :=  113; --  No route to host
+   EINPROGRESS: constant :=  115; --  Operation now in
progress
+   EINTR  : constant :=4; --  Interrupted system call
+   EINVAL : constant :=   22; --  Invalid argument
+   EIO: constant :=5; --  Input output error
+   EISCONN: constant :=  106; --  Socket already connected
+   ELOOP  : constant :=   40; --  Too many symbolic lynks
+   EMFILE : constant :=   24; --  Too many open files
+   EMSGSIZE   : constant :=   90; --  Message too long
+   ENAMETOOLONG   : constant :=   36; --  Name too long
+   ENETDOWN   : constant :=  100; --  Network is down
+   ENETRESET  : constant :=  102; --  Disconn. on network
reset
+   ENETUNREACH: constant :=  101; --  Network is unreachable
+   ENOBUFS: constant :=  105; --  No buffer space
available
+   ENOPROTOOPT: constant :=   92; --  Protocol not available
+   ENOTCONN   : constant :=  107; --  Socket not connected
+   ENOTSOCK   : constant :=   88; --  Operation on non socket
+   EOPNOTSUPP : constant :=   95; --  Operation not supported
+   EPFNOSUPPORT   : constant :=   96; --  Unknown protocol family
+   EPROTONOSUPPORT: constant :=   93; --  Unknown protocol
+   EPROTOTYPE : constant :=   91; --  Unknown protocol type
+   ESHUTDOWN  : constant :=  108; --  Cannot send once
shutdown
+   ESOCKTNOSUPPORT: constant :=   94; --  Socket type not
supported
+   ETIMEDOUT  : constant :=  110; --  Connection timed out
+   ETOOMANYREFS   : constant :=  109; --  Too many references
+   EWOULDBLOCK: constant :=   11; --  Operation would block
+
+   -
+   -- Host errors --
+   -
+
+   HOST_NOT_FOUND : constant :=1; --  Unknown host
+   T

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[burnus at gcc dot gnu dot org]

--- Comment #20 from burnus at gcc dot gnu dot org  2008-04-04 22:43 ---
> Implements dynamic string length
Great!

But you also need the handle -fbounds-check. Compile the test case of comment
11 with -fbounds-check. The result is:

Fortran runtime error: Different CHARACTER lengths (4/5) in array constructor

Without type spec the error is correct, however, with the type spec the
elements are allowed to have different lengths.

For the test cases: How about adding one test case for -std=f95, which rejects
this Fortran 2003 feature?


-- 


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

[Bug target/34916] [4.3/4.4 Regression] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os

[eric dot weddington at atmel dot com]

-- 

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 |2008-04-04 22:34:34
   date||


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

[Bug c++/35678] [4.3/4.4 Regression] partial template specialization ICE in dependent_type_p, at cp/pt.c:15539

[sultansharem at gmx dot ch]

--- Comment #2 from sultansharem at gmx dot ch  2008-04-04 22:33 ---
i think i have a fix:

in pt.c
just remove lines 15671-15678 in dependent_type_p. I'm not sure though wether
this breaks something else...


-- 


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

[Bug target/34932] [avr] ICE in reload

[eric dot weddington at atmel dot com]

-- 

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 |2008-04-04 22:31:36
   date||


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

[Bug c++/35828] ICE on template-heavy C++ code, reported in innocent source line

[gcc at cohi dot at]

--- Comment #2 from gcc at cohi dot at  2008-04-04 21:44 ---
Looking for a workaround I noticed that the ICE might actually be in connection
with the template template arguments of the overloaded functions pegtl::parse()
... it's the only place where template template arguments were used, I had
introduced them shortly before the ICE, and the ICE only went away after I
removed them...


-- 


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

[Bug target/21080] Excecution test failure for avr for pr17377 test case.

[eric dot weddington at atmel dot com]

-- 

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 |2008-04-04 21:43:08
   date||


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

[Bug target/34879] __builtin_setjmp / __builtin_longjmp fails stack frame address with O2, O3 and Os

[eric dot weddington at atmel dot com]

-- 

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 |2008-04-04 21:40:52
   date||


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

[Bug target/34789] [avr] sometimes the compiler keeps addresses in registers unnecessarily

[eric dot weddington at atmel dot com]

-- 

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 |2008-04-04 21:31:23
   date||


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

[Bug c++/35828] ICE on template-heavy C++ code, reported in innocent source line

[gcc at cohi dot at]

--- Comment #1 from gcc at cohi dot at  2008-04-04 21:30 ---
Created an attachment (id=15430)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15430&action=view)
The file that triggered the ICE (preprocessed).


-- 


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

[Bug c++/35828] New: ICE on template-heavy C++ code, reported in innocent source line

[gcc at cohi dot at]

Just got an ICE while compiling some template-heavy C++ code; as shown below,
the error is reported in parse_debug.hh, however the last change to the code,
the one that triggered the ICE, was in parse_printer.hh (I split class printer
into two classes, printer and printer_impl). I'll add the preprocessed file in
a separate comment/file.

> uname -a
Darwin tigger.local 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar  4 21:17:34 PST
2008; root:xnu-1228.4.31~1/RELEASE_I386 i386 i386 MacBookPro3,1 Darwin

> g++-mp-4.3 -v
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with: ../gcc-4.3.0/configure --prefix=/opt/macports-1.6.0
--enable-languages=c,c++,objc,obj-c++,java,fortran
--libdir=/opt/macports-1.6.0/lib/gcc43
--includedir=/opt/macports-1.6.0/include/gcc43
--infodir=/opt/macports-1.6.0/share/info --mandir=/opt/macports-1.6.0/share/man
--with-local-prefix=/opt/macports-1.6.0 --with-system-zlib --disable-nls
--program-suffix=-mp-4.3
--with-gxx-include-dir=/opt/macports-1.6.0/include/gcc43/c++/
--with-gmp=/opt/macports-1.6.0 --with-mpfr=/opt/macports-1.6.0
Thread model: posix
gcc version 4.3.0 (GCC) 

> g++-mp-4.3 -I. -std=gnu++0x -D_REENTRANT -pipe -O3 -Wall -Wextra -Wimplicit 
> -Wconversion -Wcast-align -Woverloaded-virtual -Wold-style-cast -Wformat=2 
> -Wswitch-enum -Wswitch-default -Wredundant-decls -fno-enforce-eh-specs 
> -fno-strict-overflow -lpthread calculator.cc -o calculator
./parse_debug.hh: In function 'int main(int, char**)':
./parse_debug.hh:101: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE on template-heavy C++ code, reported in innocent
source line
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at cohi dot at
  GCC host triplet: i386-apple-darwin9.2.0


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

[Bug target/34790] [avr] no sibling call optimisation

[eric dot weddington at atmel dot com]

-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/33512] Simple bitwise simplification missed

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-04-04 21:22 ---
(In reply to comment #4)
> Test gcc.dg/and-1.c, added as a fix for this PR, fails on powerpc64-linux.  
> The
> code generated for "-m64 -O2" is:

The issue is we see (and X (ior Y (not X) ) ), I will add this extra check
later this weekend.  In GCC 4.1.1, we saw what I had expected but for some
reasons GCC 4.3.0 has a different order of arguments.


-- 


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

[Bug tree-optimization/33512] Simple bitwise simplification missed

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2008-04-04 21:19 ---
Test gcc.dg/and-1.c, added as a fix for this PR, fails on powerpc64-linux.  The
code generated for "-m64 -O2" is:

f:
mr 0,3
neg 3,3
nand 3,3,0
and 3,3,0
blr


-- 


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[d at domob dot eu]

--- Comment #19 from d at domob dot eu  2008-04-04 20:27 ---
Created an attachment (id=15429)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15429&action=view)
Implements dynamic string length

Finally, I managed to get dynamic string length working; however, this was more
an experimentation thing for some parts.  For instance, the generation of the
tree-expression in gfc_trans_array_constructor was pure guessing and getting
lucky, so I fear it is not quite done the right way; however, so far it works
and I hope it is nearly correct now.

This patch makes all my tests for constructor with typespec work, but it
introduces two regression failures I'll still have to look at.  And finally, I
fear the style is yet to become perfect ;)


-- 

d at domob dot eu changed:

   What|Removed |Added

  Attachment #15374|0   |1
is obsolete||


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

[Bug target/35620] ICE passing dereferenced pointer to _Decimal32

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2008-04-04 20:19 ---
Subject: Bug 35620

Author: janis
Date: Fri Apr  4 20:18:52 2008
New Revision: 133909

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133909
Log:
gcc/
PR target/35620
* config/rs6000/rs6000.c (rs6000_check_sdmode): Handle indirect ref
and view convert expression.

testsuite/
PR target/35620
* gcc.dg/dfp/pr35620.c: New test.
* gcc.dg/dfp/func-pointer.c: New test.
* gcc.dg/dfp/func-deref.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/func-deref.c
trunk/gcc/testsuite/gcc.dg/dfp/func-pointer.c
trunk/gcc/testsuite/gcc.dg/dfp/pr35620.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35826] some (erroneous) code produces: internal compiler error

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-04-04 19:29 ---
Works for me with gfortran 4.4.0, 4.3.0, 4.2.2, 4.1.3 on x86-64-linux, even
with valgrind.


-- 


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

[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2008-04-04 19:02 
---
Hmm, for some reason __spu_vector__ works correctly for my testcase but not
__altivec__; I have not looked into why though.


-- 


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

[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2008-04-04 18:18 
---
We also need to make sure the target specific attribute __altivec__ (powerPC)
and __spu_vector__ (SPU) works correctly just as vector_size works.


-- 


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

[Bug middle-end/35827] -fvisibility only works for C/C++/Objective-C/Objective-C++

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-04 18:12 ---
-fvisibility should be only a C/C++ option as you cannot change the visibility
in any other language.  Also it is only implemented for
C/C++/Objective-C/Objective-C++:
[dhcp-10-98-10-23:local/gcc/gcc] apinski% grep default_visibility */*.c
cp/decl.c:default_visibility = VISIBILITY_HIDDEN;
cp/decl2.c:   DECL_VISIBILITY (decl) = default_visibility;
[dhcp-10-98-10-23:local/gcc/gcc] apinski% grep default_visibility *.c
c-common.c:  DECL_VISIBILITY (decl) = default_visibility;
c-pragma.c:  default_visibility);
c-pragma.c:default_visibility = VISIBILITY_DEFAULT;
c-pragma.c:default_visibility = VISIBILITY_INTERNAL;
c-pragma.c:default_visibility = VISIBILITY_HIDDEN;
c-pragma.c:default_visibility = VISIBILITY_PROTECTED;
c-pragma.c:  default_visibility = VEC_pop (visibility, visstack);
opts.c:enum symbol_visibility default_visibility = VISIBILITY_DEFAULT;
opts.c:  default_visibility = VISIBILITY_DEFAULT;
opts.c:  default_visibility = VISIBILITY_INTERNAL;
opts.c:  default_visibility = VISIBILITY_HIDDEN;
opts.c:  default_visibility = VISIBILITY_PROTECTED;


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|fortran |middle-end
Summary|gfortran doesn't respect -  |-fvisibility only works for
   |fvisibility |C/C++/Objective-C/Objective-
   ||C++


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

[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates

[jason at redhat dot com]

--- Comment #12 from jason at redhat dot com  2008-04-04 18:10 ---
Subject: Re:  [4.3/4.4 Regression] vector_size attribute lost
 in function arguments for templates

jakub at gcc dot gnu dot org wrote:
> Actually, to clarify #c10, attributes on parameter packs just make things
> harder on the compiler side, but even in C++98 the same issue is present:
> #define vector __attribute__((__vector_size__ (16)))
> 
> template  void foo (int x, vector T y) { }
> void bar (vector long a, vector double b)
> {
>   foo (5, a);
>   foo (5, b);
> }

This functionality seems desirable, but cannot be considered a regression.

> Are there any attributes other than vector_size which affect the decls
> similarly?

I don't think so.

> If not, I'd say that the C++ FE should hardcode some knowledge about this
> attribute, e.g. know that it applies to the type, so if
> processing_template_decl
> move them from DECL_ATTRIBUTES to corresponding type's TYPE_ATTRIBUTES (either
> the parameter type such that it would be in TYPE_ARG_TYPES too, or for
> FUNCTION_TYPE/METHOD_TYPE stick it into return type's TYPE_ATTRIBUTES).
> And in type_unification_real take it into account.

This makes sense to me.  Though I think that if we just push the 
attribute down to the type that it actually modifies, we don't have to 
think about TYPE_ARG_TYPES.  That should also avoid the need for 
reconstruct_complex_type.

Jason


-- 


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

[Bug fortran/35827] New: gfortran doesn't respect -fvisibility

[3dw4rd at verizon dot net]

I am having trouble with symbol visibility with gfortran on Linux x86_64.
It looks like -fvisibility=hidden doesn't work.

[EMAIL PROTECTED] tirem-3.2]$ gfortran -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)


So I copied and translated a gcc.dg/visibility-9.c to Fortran for a small test
case.

I compiled with gfortran to a shared library (x86_64 ELF Linux etc.).

visibility-1.f90

! Test that -fvisibility works.
! { dg-do compile }
! { dg-require-visibility "" }
! { dg-options "-fvisibility=hidden" }
! { dg-final { scan-hidden "foo" } }


subroutine foo
end subroutine


[EMAIL PROTECTED] ~]$ gfortran -shared  -fvisibility=default -fPIC -o 
visibility-1.so
visibility-1.f90
[EMAIL PROTECTED] ~]$ nm -C -D visibility-1.so
 w _Jv_RegisterClasses
002007c8 A __bss_start
 w __cxa_finalize
 w __gmon_start__
002007c8 A _edata
002007d8 A _end
0548 T _fini
03f0 T _init
04fc T foo_

The "foo_" at the end is teh bad thing.

I haven't checked a gfortran less than 4.1 but g77 as of gcc-3.4 supports
visibility.
I've checked with an almost release gcc-4.3 and visibility still didn't work.

Is anyone else seeing a problem?

I'll check PPC MacOS and i32 Cygwin when I get home.

Ed Smith-Rowland

---

I just verified this on PPC MacOSX:

MacOSX:~ ed$ bin-4.3/bin/gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc/configure --prefix=/Users/ed/bin-4.3
--enable-languages=c,c++,objc,obj-c++,fortran,treelang
Thread model: posix
gcc version 4.3.0 20071116 (experimental) (GCC)


The results of nm:

MacOSX:~ ed$ bin-4.3/bin/gfortran -dynamiclib  -fvisibility=default -fPIC -o
visibility-1.dylib visibility-1.f90
MacOSX:~ ed$ nm visibility-1.dylib
...

visibility-1.dylib(ccsE7pf3.o):
1db0 T _foo_

...
So foo is visible on PPC MacOSX too.


-- 
   Summary: gfortran doesn't respect -fvisibility
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 3dw4rd at verizon dot net
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug target/35364] ICE on ia64 with vector declaration inside #pragma omp parallel

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-04-04 18:01 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35364] ICE on ia64 with vector declaration inside #pragma omp parallel

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-04-04 18:01 ---
Subject: Bug 35364

Author: jakub
Date: Fri Apr  4 18:00:25 2008
New Revision: 133906

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133906
Log:
PR target/35364
* tree-cfg.c (remove_useless_stmts_1): Handle OMP_* containers.

* g++.dg/gomp/pr35364.C: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/gomp/pr35364.C
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-cfg.c


-- 


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

[Bug target/35364] ICE on ia64 with vector declaration inside #pragma omp parallel

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-04-04 17:49 ---
Subject: Bug 35364

Author: jakub
Date: Fri Apr  4 17:48:45 2008
New Revision: 133905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133905
Log:
PR target/35364
* tree-cfg.c (remove_useless_stmts_1): Handle OMP_* containers.

* g++.dg/gomp/pr35364.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr35364.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c


-- 


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

[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments

[tromey at gcc dot gnu dot org]

--- Comment #6 from tromey at gcc dot gnu dot org  2008-04-04 16:39 ---
It is no trouble.  Thanks.


-- 


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

[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments

[mec at google dot com]

--- Comment #5 from mec at google dot com  2008-04-04 16:36 ---
Doh!  You are right, I was confused when I read "z1.cc:2:4" as an error on line
4. Both errors are in line 2, inside the #if block.  Sorry for the noise.


-- 

mec at google dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug preprocessor/33143] preprocess should ignore trigraphs in /* */ comments

[tromey at gcc dot gnu dot org]

--- Comment #4 from tromey at gcc dot gnu dot org  2008-04-04 16:28 ---
I tried this test case and as far as I can tell it works as expected.
Can you say what you think is wrong?

I thought perhaps you were misreading the error output.  The errors
from the initial report are:

z1.cc:2:1: warning: trigraph ??- ignored, use -trigraphs to enable
z1.cc:2:4: warning: trigraph ??- ignored, use -trigraphs to enable

These are both on line 2.  So, we aren't emitting a warning for
the trigraph in the comment.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/35826] some (erroneous) code produces: internal compiler error

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-04-04 15:33 ---
Works with 4.3-branch and trunk.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2 4.2.4
  Known to work||4.3.0 4.4.0


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #37 from joel at gcc dot gnu dot org  2008-04-04 15:11 ---
Forgot we are up to 4.4... it applies to 4.2 and 4.3 branches.  


-- 


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

[Bug fortran/35826] New: some (erroneous) code produces: internal compiler error

[oivulf at gmail dot com]

Tested with:
gfortran
4.2.0 OpenBSD
4.1.1 Gentoo
4.2.3 Gentoo
write(18,0) 'trtot= ',trtot
produces internal compiler error => seg fault


-- 
   Summary: some (erroneous) code produces: internal compiler error
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oivulf at gmail dot com


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

[Bug ada/35825] Update g-soccon-rtems.ads

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-04-04 14:57 ---
Created an attachment (id=15428)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15428&action=view)
Patch to add IP_PKTINFO

Add patch -- only applicable to SVN trunk.


-- 


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

[Bug ada/35825] New: Update g-soccon-rtems.ads

[joel at gcc dot gnu dot org]

Attached will be a patch to update g-soccon-rtems.ads on the trunk to reflect
the new constant IP_PKTINFO.

2008-04-04  Joel Sherrill <[EMAIL PROTECTED]>

* g-soccon-rtems.ads: Add IP_PKTINFO.


-- 
   Summary: Update g-soccon-rtems.ads
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: *-rtems*


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

[Bug target/35364] ICE on ia64 with vector declaration inside #pragma omp parallel

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-04-04 14:38 ---
optimize_double_finally relies here on the useless pass doing its job.
But on the trunk/4.3 the useless pass doesn't dive into OpenMP constructs.
This is fixed on the gomp-3_0-branch, see the remove_useless_stmts_1 hunk
in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00261.html
At that point I didn't know of any testcase that would be affected on the
trunk/4.3 too, so I've committed that just to gomp-3_0-branch, but will
backport it now to the trunk/4.3.


-- 

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
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-04 14:38:51
   date||


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

[Bug preprocessor/35697] -MF should create dependency file atomically

[tromey at gcc dot gnu dot org]

--- Comment #6 from tromey at gcc dot gnu dot org  2008-04-04 14:33 ---
Confirmed.

I think the best behavior is a bit unclear.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-04 14:33:08
   date||


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

[Bug ada/35576] Ada HW Interrupt Task Enhancement

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-04-04 14:32 ---
Patch is still valid against 3 April SVN trunk.  Confirmed on SPARC.

sparc-rtems4.9-gcc (GCC) 4.4.0 20080403 (experimental) [trunk revision 133868]


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #36 from joel at gcc dot gnu dot org  2008-04-04 14:30 ---
Test results running with osinte.diff have been posted to gcc-testresults for
i386, mips, sparc, and powerpc.  They look very good.  Most failures are
cross-target or FPU exceptions now.

This needs to be applied to the 4.2 branch as well. 

2008-04-04  Joel Sherrill <[EMAIL PROTECTED]>

* s-osinte-rtems.ads: Correct type of ss_low_priority field in struct 
sched_param. Add missing process_shared field to pthread_condattr_t.


-- 


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

[Bug fortran/35824] Overloading problems with derived type with allocatable array

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-04-04 14:14 ---
> Confirmed on powerpc-apple-darwin9 (but not on i686-apple-darwin9). The bus
> error comes from the statement 'b%b=-a%b' in function 'neg_at'. If I insert
> 'print *, allocated(a%b)' in the function, I get .false. on powerpc (but 
> .true.
> for i686) for 't1=-t1'.

Also confirmed on x86-64-linux. I always get non allocated before and allocated
after the allocation statement, which looks OK.

I have to admit, I did not quickly see in the dump (-fdump-tree-original) why
it is failing; at a glance, both calling "neg_at" in MAIN__ and the assignment
in "neg_at" itself look ok; and "t2 = -t1" also works.

Side question: Why do we initialize b.b.data with NULL 3 times?

  b.b.data = 0B;
  b.b.data = 0B;
  {
struct alltype alltype.0;
alltype.0.b.data = 0B;
b = alltype.0;
  }


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-04 14:14:38
   date||


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

[Bug c/35440] [4.1/4.2/4.3/4.4 regression] ICE resulting in completely broken diagnostic

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-04 13:14 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/35440] [4.1/4.2/4.3/4.4 regression] ICE resulting in completely broken diagnostic

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-04-04 13:13 ---
Subject: Bug 35440

Author: jakub
Date: Fri Apr  4 13:12:58 2008
New Revision: 133899

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133899
Log:
PR c/35440
* c-pretty-print.c (pp_c_initializer_list): Handle CONSTRUCTOR
for all types.

* gcc.dg/pr35440.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr35440.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/c-pretty-print.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/35440] [4.1/4.2/4.3/4.4 regression] ICE resulting in completely broken diagnostic

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-04 13:08 ---
Subject: Bug 35440

Author: jakub
Date: Fri Apr  4 13:07:27 2008
New Revision: 133897

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133897
Log:
PR c/35440
* c-pretty-print.c (pp_c_initializer_list): Handle CONSTRUCTOR
for all types.

* gcc.dg/pr35440.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr35440.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-pretty-print.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/4334] Flow control insn inside a basic block, arm/netbsd, gcc 3.1

[nickc at gcc dot gnu dot org]

--- Comment #3 from nickc at gcc dot gnu dot org  2008-04-04 11:40 ---
Subject: Bug 4334

Author: nickc
Date: Fri Apr  4 11:39:20 2008
New Revision: 133894

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133894
Log:
PR binutils/4334
* acx.m4 (ACX_CHECK_CYGWIN_CAT_WORKS): New macro to check that
cygwin builds are not running in textmode.

* configure.ac: Run ACX_XHEXK_CYGWIN_CAT_WORKS for cygwin hosted
builds.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/config/ChangeLog
trunk/config/acx.m4
trunk/configure
trunk/configure.ac


-- 


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

[Bug middle-end/35823] verify_gimple fails on taking 'Size of a String subprogram parameter

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-04 11:29 ---
Subject: Bug 35823

Author: rguenth
Date: Fri Apr  4 11:29:11 2008
New Revision: 133893

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133893
Log:
2008-04-04  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/35823
* fold-const.c (optimize_minmax_comparison): Use the correct
type for the constant in the simplified comparison.

* gnat.dg/pr35823.adb: New testcase.

Added:
trunk/gcc/testsuite/gnat.dg/pr35823.adb
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/35823] verify_gimple fails on taking 'Size of a String subprogram parameter

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-04 11:29 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug other/35151] mingw64 is an invalid name

[nickc at gcc dot gnu dot org]

--- Comment #3 from nickc at gcc dot gnu dot org  2008-04-04 11:16 ---
Subject: Bug 35151

Author: nickc
Date: Fri Apr  4 11:16:10 2008
New Revision: 133892

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133892
Log:
PR other/35151
* configure.ac: Combine rules for mingw32 and mingw64.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac


-- 


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

[Bug fortran/35824] Overloading problems with derived type with allocatable array

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-04-04 10:09 ---
Confirmed on powerpc-apple-darwin9 (but not on i686-apple-darwin9). The bus
error comes from the statement 'b%b=-a%b' in function 'neg_at'. If I insert
'print *, allocated(a%b)' in the function, I get .false. on powerpc (but .true.
for i686) for 't1=-t1'.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

Summary|Overloading problems with   |Overloading problems with
   |derived type with   |derived type with
   |allocatable array   |allocatable array


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

[Bug fortran/35820] internal compiler error with nested FORALL

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-04-04 09:40 ---
I think the problem are related to nested FORALLs. The following is enough to  
   cause the valgrind error (add the needed definitions from comment
0). If I comment either the RDA(J1) assignment in the outer FORALL or the inner
FORALL, valgrind finds no error.

  FORALL (J1 = 1:10)
RDA(J1) = RCA(J1) + 1.0_R1_KV
FORALL (J2 = 1:9)
  IDA(J1,J2) = ICA(J1,J2) + 1
END FORALL
  ENDFORALL

The line shown by valgrind is:
==629==at 0x463A23: resolve_code (resolve.c:5902)

If I go to the source, this is:
  /* Record the current FORALL index.  */
  var_expr[nvar] = gfc_copy_expr (fa->var);

where of the function gfc_resolve_forall (i.e. the function has been inlined in
 resolve_code).

I have somehow the feeling that total_var is too small as for forall_save != 0
the size is not properly set. I think the problem is that it is that
forall_save has a nonzero value as soon as "RDA(J1) =" is encountered and thus
the size is not properly increased when the inner FORALL is encountered. If one
swaps the order of "RDA(J1) =" and the inner FOREACH loop, valgrind finds not
error.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|internal compiler error with|internal compiler error with
   |forall  |nested FORALL


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

[Bug middle-end/35823] verify_gimple fails on taking 'Size of a String subprogram parameter

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-04 09:31 ---
Works with x86_64, fails with -m32.  Bug in optimize_minmax_comparison, I have
a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
  Component|ada |middle-end
 Ever Confirmed|0   |1
 GCC target triplet||i?86-*-*
   Last reconfirmed|-00-00 00:00:00 |2008-04-04 09:31:23
   date||


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

[Bug fortran/35824] New: Overloading problems with derived type with allocatable array

[everyo at gmx dot net]

I have a derived type with an allocatable array and have overloaded some
operations. Unfortunately assignments like a=-a don't work.

Code in the Module, where I definde the type:

  type alltype
 double precision :: a
 double precision,allocatable :: b(:)
  end type

  interface assignment(=)
  module procedure at_from_at
  end interface

  interface operator(-)
  module procedure  neg_at
  end interface

  contains

subroutine at_from_at(b,a)
  type(alltype), intent(in) :: a
  type(alltype), intent(out) :: b

  b%a=a%a
  allocate(b%b(2))
  b%b=a%b

end subroutine at_from_at

function neg_at(a) result(b)
  type(alltype), intent(in) :: a
  type(alltype) :: b

  b%a=-a%a
  allocate(b%b(2))
  b%b=-a%b

end function neg_at

The allocatable array has an dimension of 2 in this example...

Now the code:

 use typemodule

 type(alltype) t1,t2,t3

 allocate(t1%b(2))
 t1%a=0.5d0
 t1%b(1)=1d0
 t1%b(2)=2d0


 t2=-t1
 write(*,*) t2%a, t2%b

 t1=-t1
 write(*,*) t1%a, t1%b

Prints: 
 -0.5  -1.0   -2.
Segmentation fault

It seems that in the Module, the allocatated array of t1 doesn't get passed
properly in the t1=-t1 part. I have also seg. faults in situations like a=a+b
(where + is overloaded simiarly)

The same code works correctly with ifort.


-- 
   Summary: Overloading problems with derived type with allocatable
array
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: everyo at gmx dot net
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/34112] Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2008-04-04 08:35 
---
(In reply to comment #8)
> It would be useful if one could support also
> 
>!$GNU attributes align:16 :: variable name
> 
> or alike for calls to libraries which need alignment such as FFTW.

Yep, I think I mentioned that in my last c.l.f post about GNU attributes in
gfortran. And I also had the very same thought when I read this morning's c.l.f
thread :)


-- 


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

[Bug fortran/34112] Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2008-04-04 07:49 ---
It would be useful if one could support also

   !$GNU attributes align:16 :: variable name

or alike for calls to libraries which need alignment such as FFTW.


-- 


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

[Bug c/35822] Internal compiler error: segmentation fault

[rbertran at ac dot upc dot edu]

--- Comment #7 from rbertran at ac dot upc dot edu  2008-04-04 07:25 ---


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


-- 

rbertran at ac dot upc dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/35821] Internal compiler error: segmentation fault

[rbertran at ac dot upc dot edu]

--- Comment #6 from rbertran at ac dot upc dot edu  2008-04-04 07:25 ---
*** Bug 35822 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/35821] Internal compiler error: segmentation fault

[rbertran at ac dot upc dot edu]

--- Comment #5 from rbertran at ac dot upc dot edu  2008-04-04 07:18 ---
Created an attachment (id=15427)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15427&action=view)
File generated using the flag -fdump-tree-vect and
-ftree-vectorizer-verbose=


-- 


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

[Bug tree-optimization/35821] Internal compiler error: segmentation fault

[rbertran at ac dot upc dot edu]

--- Comment #4 from rbertran at ac dot upc dot edu  2008-04-04 07:17 ---
Created an attachment (id=15426)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15426&action=view)
File generated using the flag -fdump-tree-vect


-- 


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

[Bug tree-optimization/35821] Internal compiler error: segmentation fault

[rbertran at ac dot upc dot edu]

--- Comment #3 from rbertran at ac dot upc dot edu  2008-04-04 07:17 ---
Created an attachment (id=15425)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15425&action=view)
Temp file generated when -save-temp flag is set


-- 


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

[Bug c/35822] Internal compiler error: segmentation fault

[rbertran at ac dot upc dot edu]

--- Comment #6 from rbertran at ac dot upc dot edu  2008-04-04 07:10 ---
Created an attachment (id=15424)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15424&action=view)
File generated using the flag -fdump-tree-vect and
-ftree-vectorizer-verbose=


-- 


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

[Bug c/35822] Internal compiler error: segmentation fault

[rbertran at ac dot upc dot edu]

--- Comment #5 from rbertran at ac dot upc dot edu  2008-04-04 07:09 ---
Created an attachment (id=15423)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15423&action=view)
File generated using the flag -fdump-tree-vect

As it seems that error comes from the vectorizer (see the gdb output), I
thought that this information is useful.


-- 


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