[Bug target/20337] Unable to run dynamicly linked binaries on ARCH sh3 (hitachi)

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2007-04-25 08:07 ---
Unfortunately, such a failure might happen also with a bad
kernel, an ill-configured glibc or a linker problem.  This
report shows nothing about any compiler problem and other
folks successfully used shared libraries on SH3 with 3.4
compiler.  So I'd like to close this PR as WORKSFORME.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()

[fxcoudert at gcc dot gnu dot org]

--- Comment #19 from fxcoudert at gcc dot gnu dot org  2007-04-25 08:36 
---
Subject: Bug 31299

Author: fxcoudert
Date: Wed Apr 25 08:36:20 2007
New Revision: 124143

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124143
Log:
PR libfortran/31299
* intrinsics/getlog.c: Use getpwuid and geteuid instead of
getlogin if they are available.
* configure.ac: Add checks for getpwuid and geteuid.
* configure: Regenerate.
* config.h.in: Regenerate.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/intrinsics/getlog.c


-- 


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

[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()

[fxcoudert at gcc dot gnu dot org]

--- Comment #20 from fxcoudert at gcc dot gnu dot org  2007-04-25 08:37 
---
Fixed on mainline.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()

[fxcoudert at gcc dot gnu dot org]

--- Comment #21 from fxcoudert at gcc dot gnu dot org  2007-04-25 08:39 
---
Subject: Bug 31299

Author: fxcoudert
Date: Wed Apr 25 08:38:59 2007
New Revision: 124144

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124144
Log:
PR libfortran/31299
* intrinsic.texi (GETLOG): Update documentation to reflect
library changes.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi


-- 


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

[Bug fortran/31668] %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures

[patchapp at dberlin dot org]

--- Comment #2 from patchapp at dberlin dot org  2007-04-25 08:40 ---
Subject: Bug number PR 31668

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01609.html


-- 


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

[Bug driver/31694] New: __GFORTRAN__ preprocessor macro

[fxcoudert at gcc dot gnu dot org]

When preprocessing Fortran code (ie when cc1 is called with -lang-fortran) we
should define a __GFORTRAN__ macro. Here's a patch that does just that:

Index: c-common.h
===
--- c-common.h  (revision 124116)
+++ c-common.h  (working copy)
@@ -254,6 +254,9 @@
 #define c_dialect_cxx()(c_language & clk_cxx)
 #define c_dialect_objc()   (c_language & clk_objc)

+/* FXC */
+extern bool lang_fortran;
+
 /* Information about a statement tree.  */

 struct stmt_tree_s GTY(()) {
Index: c-cppbuiltin.c
===
--- c-cppbuiltin.c  (revision 124116)
+++ c-cppbuiltin.c  (working copy)
@@ -569,6 +569,9 @@
   if (flag_openmp)
 cpp_define (pfile, "_OPENMP=200505");

+  if (lang_fortran)
+cpp_define (pfile, "__GFORTRAN__=1");
+
   builtin_define_type_sizeof ("__SIZEOF_INT__", integer_type_node);
   builtin_define_type_sizeof ("__SIZEOF_LONG__", long_integer_type_node);
   builtin_define_type_sizeof ("__SIZEOF_LONG_LONG__",
Index: c-opts.c
===
--- c-opts.c(revision 124116)
+++ c-opts.c(working copy)
@@ -73,7 +73,7 @@
 static bool verbose;

 /* If -lang-fortran seen.  */
-static bool lang_fortran = false;
+bool lang_fortran = false;

 /* Dependency output file.  */
 static const char *deps_file;


-- 
   Summary: __GFORTRAN__ preprocessor macro
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
AssignedTo: fxcoudert at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug driver/31694] __GFORTRAN__ preprocessor macro

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 08:42:29
   date||


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

[Bug driver/31694] __GFORTRAN__ preprocessor macro

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2007-04-25 08:42:29 |2007-04-25 08:42:45
   date||


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

[Bug c/31695] New: __builtin_ctzll slower than 2*__builtin_ctz

[joerg dot richter at pdv-fs dot de]

int func1( unsigned long long val )
{
  return __builtin_ctzll( val );
}

int func2( unsigned long long val )
{
  unsigned lo = (unsigned)val;
  return lo ? __builtin_ctz(lo) : __builtin_ctz(unsigned(val>>32)) + 32;
}

func1 is more than 2 times slower than func2.  
But it should be at least as fast as func2

__builtin_ctzll is not expanded inline like __builtin_ctz.


-- 
   Summary: __builtin_ctzll slower than 2*__builtin_ctz
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/31668] %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-04-25 09:32 ---
Subject: Bug 31668

Author: burnus
Date: Wed Apr 25 09:32:21 2007
New Revision: 124147

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124147
Log:
fortran/
2007-04-25  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/31668
* error.c (error_print): Fix %% support.
* intrinsic.c (sort_actual): Improve error message.
* resolve.c (resolve_actual_arglist): Allow %VAL for
interfaces defined in the module declaration part.

testsuite/
2007-04-25  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/31668
* gfortran.dg/c_by_val_2.f90: Add rejection test of %VAL with
statement functions.
* gfortran.dg/c_by_val_5.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/c_by_val_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_by_val_2.f90


-- 


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

[Bug fortran/31668] %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-04-25 09:33 
---
Fixed on mainline, closing.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/31668] %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2007-04-25 09:35 ---
Fixed. For completeness, I only support PROC_MODULE (for interfaces to external
routines) and not PROC_INTERNAL as there is no way (except VALUE) to make use
of a call-by-value variable.


-- 


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

[Bug target/20337] Unable to run dynamicly linked binaries on ARCH sh3 (hitachi)

[kristoffer_e1 at hotmail dot com]

--- Comment #4 from kristoffer_e1 at hotmail dot com  2007-04-25 09:36 
---
When this bug was reported I had these issues, it later turned out to be due to
glibc. All versions after 2.3.3 (in other words 2.3.4 ->) works perfectly fine. 

Sorry for not closing this.


-- 


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

[Bug fortran/25708] Module loading is not good at all

[jb at gcc dot gnu dot org]

--- Comment #7 from jb at gcc dot gnu dot org  2007-04-25 09:41 ---
BTW, here's some slides describing NAG:s experience, they use lazy symbol
lookup combined with caching, and claim it is up to 1000 times faster than
non-lazy (which gfortran uses AFAICS).

http://www.fortran.bcs.org/2007/jubilee/f50.pdf


-- 


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

[Bug middle-end/31691] optimized code taking the wrong branch

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-04-25 09:53 ---
Works for me.  Can you attach the FILE.c.t93.optimized file you get if you
build with gcc -O3 -fno-inline -fdump-tree-optimized?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/31680] Cannot create DLL with exported stdcall functions because compiler exports the functions without the @N decoration

[dannysmith at users dot sourceforge dot net]

--- Comment #3 from dannysmith at users dot sourceforge dot net  2007-04-25 
09:57 ---
Testing a patch.
Danny


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dannysmith at users dot
   |dot org |sourceforge dot net
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 09:57:55
   date||


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

[Bug fortran/31696] New: -malign-double trashes fortran format

[KnowlesPJ at Cardiff dot ac dot uk]

The following code goes wrong with gfortran -malign-double (but is OK without
malign-double)

PROGRAM test
 CHARACTER(80) :: buffer
 READ (*,1) buffer
1 FORMAT(a)
END PROGRAM test

$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.9.1
Configured with: ../gcc-4.3-20070316/configure --enable-languages=fortran,c++
Thread model: posix
gcc version 4.3.0 20070316 (experimental)
$ uname -a
Darwin m038.chem.cf.ac.uk 8.9.1 Darwin Kernel Version 8.9.1: Thu Feb 22
20:55:00 PST 2007; root:xnu-792.18.15~1/RELEASE_I386 i386 i386
$ gfortran -malign-double format.f90
$ echo xxx | ./a.out
At line 3 of file format.f90
Fortran runtime error: Missing initial left parenthesis in format
H   å? 
$ gfortran  format.f90
$ echo xxx | ./a.out


-- 
   Summary: -malign-double trashes fortran format
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: KnowlesPJ at Cardiff dot ac dot uk
 GCC build triplet: i386-apple-darwin8.9.1
  GCC host triplet: i386-apple-darwin8.9.1
GCC target triplet: i386-apple-darwin8.9.1


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

[Bug middle-end/31697] New: [Regression 4.3] Crash of gen. prog. when using -funroll-loops -march=opteron

[burnus at gcc dot gnu dot org]

This is with the Polyhedron aermod.f90 test case
(http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html).

The program crashes (in << 1 sec) with
  gfortran -funroll-loops -march=opteron -O2 -g aermod.f90

It does not crash:
 - without: -march=opteron
 - without: -funroll-loops
 - with: -O1

It was working on 2007-04-23 (should be r124055) and started to fail since
2007-04-24 (should be r124093).

gdb shows:
Program received signal SIGSEGV, Segmentation fault.
#0  resini_ () at aermod.f90:23766
#1  0x004c7357 in MAIN__ () at aermod.f90:2189

And valgrind:
==6590== Invalid write of size 4
==6590==at 0x4066D1: resini_ (aermod.f90:23766)
==6590==by 0x4C8BD6: MAIN__ (aermod.f90:2189)
==6590==by 0x4C95AB: main (fmain.c:22)
==6590==  Address 0x1BE65FD0 is not stack'd, malloc'd or (recently) free'd

 23757  DO K = 1 , NUMGRP
 23758 DO J = 1 , NUMREC
 23759AVEVAL(J,K,L,M) = 0.0
 23760DO I = 1 , NHIVAL
 23761   HIVALU(J,I,K,L,M) = 0.0
 23762   NHIDAT(J,I,K,L,M) = 0
 23763   HCLMSG(J,I,K,L,M) = ' '
 23764   HMAX(I,K,L,M) = 0.0
 23765   HMDATE(I,K,L,M) = 0
 23766   HMLOC(I,K,L,M) = 0
 23767   HMCLM(I,K,L,M) = ' '
 23768ENDDO
 23769 ENDDO


-- 
   Summary: [Regression 4.3] Crash of gen. prog. when using -
funroll-loops -march=opteron
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/31691] [4.1 regression] optimized code taking the wrong branch

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2007-04-25 11:14 
---
Confirmed with -O2 -fno-inline too, thanks for the reduced testcase.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   GCC host triplet|sparc-sun-solaris2.8+   |sparc-sun-solaris2.8
 GCC target triplet|sparc-sun-solaris2.8+   |sparc-sun-solaris2.8
  Known to fail||4.1.2
  Known to work||3.4.3 4.2.0 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 11:14:17
   date||
Summary|optimized code taking the   |[4.1 regression] optimized
   |wrong branch|code taking the wrong branch


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

[Bug middle-end/31691] [4.1 regression] optimized code taking the wrong branch

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2007-04-25 11:14 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-04-25 11:14:17 |2007-04-25 11:14:55
   date||


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

[Bug target/31680] Cannot create DLL with exported stdcall functions because compiler exports the functions without the @N decoration

[dannysmith at users dot sourceforge dot net]

--- Comment #4 from dannysmith at users dot sourceforge dot net  2007-04-25 
11:17 ---
Fixed.

Author: dannysmith
Date: Wed Apr 25 11:06:28 2007
New Revision: 124149

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124149
Log:
* config/i386/winnt.c (i386_pe_file_end): Strip only
USER_LABEL_PREFIX when writing export name.

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


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

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


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

[Bug c++/31698] New: ICE in compare_name_with_value, at tree-vrp.c:3272

[thimo dot neubauer at cst dot com]

beachboys++ /tmp> g++ -O2 mytestcase.i 
mytestcase.i: In member function ‘void D::Do(B*, C*)’:
mytestcase.i:36: internal compiler error: in compare_name_with_value, at
tree-vrp.c:3272
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 .
Preprocessed source stored into /tmp/ccwTAH7q.out file, please attach this to
your bugreport.
Exit 1
beachboys++ /tmp> g++ -O0 mytestcase.i
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crt1.o: In function
`_start':
../sysdeps/x86_64/elf/start.S:109: undefined reference to `main'
collect2: ld returned 1 exit status
Exit 1


-- 
   Summary: ICE in compare_name_with_value, at tree-vrp.c:3272
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thimo dot neubauer at cst dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/31698] ICE in compare_name_with_value, at tree-vrp.c:3272

[thimo dot neubauer at cst dot com]

--- Comment #1 from thimo dot neubauer at cst dot com  2007-04-25 12:53 
---
Created an attachment (id=13437)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13437&action=view)
reduced testcase


-- 


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

[Bug java/31622] Segment violation in the “toString” method on a mathematical expression

[eduardo dot iniesta at aquiline dot es]

--- Comment #7 from eduardo dot iniesta at aquiline dot es  2007-04-25 
13:26 ---
Thank you very much, Tom.

I have updated GCC 4.3.0. Everything is well.

(In reply to comment #6)
> Ok.  You are running a version of gcj 4.3 from *before* the gcj-eclipse
> merge.  So, this is correctly marked as a duplicate.
> 
> If you update and rebuild, and follow the new instructions vis a vis ecj1,
> you will get a working gcj.
> 


-- 


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

[Bug middle-end/31699] New: [Regression 4.3] -march=opteron -ftree-vectorize generates wrong code

[burnus at gcc dot gnu dot org]

This is with the Polyhedron rnflow.f90 test case
(http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html)

It was working on 2007-04-23 (should be r124055) and started to fail since
2007-04-24 (should be r124093). (Same with PR 31697)

Crash after 1.5 seconds with
  gfortran -m32 -march=opteron -ftree-vectorize -O2 rnflow.f90

Same crash with -m64.

no crash:
- without: -march=opteron
- without: -ftree-vectorize
- with: -O1

Program received signal SIGSEGV, Segmentation fault.
#0  0x004058a9 in invima (__result=,
a=0x2ac0ff48d010, [EMAIL PROTECTED], k=,
[EMAIL PROTECTED]) at rnflow.f90:2904
#1  0x00407446 in evlrnf_ (ptrs0t=, nclsm=, prnf0t=0xdaf380) at rnflow.f90:2771

  2899elseif (n > 1) then
  2900   allocate (da (1:n,1:n))
  2901   lw = n * m
  2902   allocate (dw (1:lw))
  2903   allocate (ipivt (1:n))
  2904   da (1:n, 1:n) = - a (j:k-1, j:k-1)
  2905   do i = 1, n
  2906  da (i, i) = da (i, i) + 1.0d0
  2907   enddo


-- 
   Summary: [Regression 4.3] -march=opteron -ftree-vectorize
generates wrong code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/31697] [Regression 4.3] Crash of gen. prog. when using -funroll-loops -march=opteron

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-04-25 13:28 ---
Might be related to the similar PR 31699.


-- 


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

[Bug libgcj/31700] New: [JNI] -X options not recognised by JNI_CreateJavaVM

[marcus at better dot se]

JNI_CreateJavaVM fails to recognise -X options such as -Xmx and friends. It
says:
  libgcj: unknown option: -Xmx128M

I tracked it to this code in libjava/prims.cc:

  else if (vm_args->ignoreUnrecognized)
{
  if (option_string[0] == '_')
parse_x_arg (option_string + 1);
  else if (! strncmp (option_string, "-X", 2))
parse_x_arg (option_string + 2);
  else
{
unknown_option:
  fprintf (stderr, "libgcj: unknown option: %s\n", option_string);
  return -1;
}
}
  else
goto unknown_option;

Notice how the -X options are only accepted if vm_args->ignoreUnrecognized is
true. This is contrary to the specification [1] which seems to say that
supported -X options should be recognized in all cases, whereas unknown -X
options should be ignored iff vm_args->ignoreUnrecognized.

[1] http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-12.html


-- 
   Summary: [JNI] -X options not recognised by JNI_CreateJavaVM
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/31701] New: Program giving segmentation fault with '-O2' optimization.

[Ashay dot Jaiswal at kpitcummins dot com]

Hello all,

I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.

I am facing problem while executing the following program.

 --
 #include 
 extern void func();  
 typedef struct abc {   
 char name[16]; 
 }ABC;  
 main()  
 {  
 int i; 
 ABC buffer[20]; 
 for (i=0; i<20; i++) 
 buffer[i].name[0] = 't'; 
   if (buffer[10].name[0] == 't')   
   printf("OK\n"); 
   else   
   printf("NOT OK\n");  
}   
-   

The above program when compiled with '-O0' optimization executes successfully,
but I am getting segmentation fault error while executing the program compiled 
with '-O2' optimization.

Observations:

1. I found differences in the assembly output of the program when compiled
   with '-O0' and '-O2' optimization.
   It seems stack register get corrupted with '-O2' optimization.

   Following code corrupts the stack register
   L10:
mov.w   .L18,r14
mov.l .L19,r1
add   r14,r14
mov  r14,r15

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[rguenth at gcc dot gnu dot org]

--- Comment #26 from rguenth at gcc dot gnu dot org  2007-04-25 14:22 
---
We fail to add the SFTs to the may_alias set of SMT.11, so add_virtual_operand
sees NULL may_aliases and doesn't add SFTs as clobbered.

I believe compute_flow_insensitive_aliasing is the culprit here as one can
easily
see that if we enter the

  for (i = 0; i < ai->num_pointers; i++)
{
  size_t j;
  struct alias_map_d *p_map1 = ai->pointers[i];
  tree tag1 = var_ann (p_map1->var)->symbol_mem_tag;
  bitmap may_aliases1 = p_map1->may_aliases;

  if (PTR_IS_REF_ALL (p_map1->var))
continue;

  for (j = i + 1; j < ai->num_pointers; j++)
{
  struct alias_map_d *p_map2 = ai->pointers[j];
  tree tag2 = var_ann (p_map2->var)->symbol_mem_tag;
  bitmap may_aliases2 = p_map2->may_aliases;


loop with may_aliases2 empty it will stay so.  So as a fix I suggest to
add may aliases symmetrically like with

Index: tree-ssa-alias.c
===
*** tree-ssa-alias.c(revision 124151)
--- tree-ssa-alias.c(working copy)
*** compute_flow_insensitive_aliasing (struc
*** 1287,1292 
--- 1287,1294 
  struct alias_map_d *p_map2 = ai->pointers[j];
  tree tag2 = var_ann (p_map2->var)->symbol_mem_tag;
  bitmap may_aliases2 = p_map2->may_aliases;
+ unsigned int k;
+ bitmap_iterator bi;

  if (PTR_IS_REF_ALL (p_map2->var))
continue;
*** compute_flow_insensitive_aliasing (struc
*** 1301,1323 
continue;

  if (!bitmap_empty_p (may_aliases2))
!   {
! unsigned int k;
! bitmap_iterator bi;
! 
! /* Add all the aliases for TAG2 into TAG1's alias set.
!FIXME, update grouping heuristic counters.  */
! EXECUTE_IF_SET_IN_BITMAP (may_aliases2, 0, k, bi)
!   add_may_alias (tag1, referenced_var (k));
! bitmap_ior_into (may_aliases1, may_aliases2);
!   }
  else
!   {
! /* Since TAG2 does not have any aliases of its own, add
!TAG2 itself to the alias set of TAG1.  */
! add_may_alias (tag1, tag2);
! bitmap_set_bit (may_aliases1, DECL_UID (tag2));
!   }
}
  }

--- 1303,1325 
continue;

  if (!bitmap_empty_p (may_aliases2))
!   /* Add all the aliases for TAG2 into TAG1's alias set.
!  FIXME, update grouping heuristic counters.  */
!   EXECUTE_IF_SET_IN_BITMAP (may_aliases2, 0, k, bi)
! add_may_alias (tag1, referenced_var (k));
! else
!   add_may_alias (tag1, tag2);
! 
! if (!bitmap_empty_p (may_aliases1))
!   /* Add all the aliases for TAG2 into TAG1's alias set.
!  FIXME, update grouping heuristic counters.  */
!   EXECUTE_IF_SET_IN_BITMAP (may_aliases1, 0, k, bi)
! add_may_alias (tag2, referenced_var (k));
  else
!   add_may_alias (tag2, tag1);
! 
! bitmap_ior_into (may_aliases2, may_aliases1);
! bitmap_ior_into (may_aliases1, may_aliases2);
}
  }



but I have no clue what I am doing here.  't looks like big mess.

I prepare the workaround as alternative ;)


-- 


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

[Bug middle-end/31691] [4.1 regression] optimized code taking the wrong branch

[stephaniechc-gccbug at yahoo dot com]

--- Comment #4 from stephaniechc-gccbug at yahoo dot com  2007-04-25 14:26 
---
Created an attachment (id=13438)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13438&action=view)
output of -fdump-tree-optimized


-- 


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

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[rguenth at gcc dot gnu dot org]

--- Comment #27 from rguenth at gcc dot gnu dot org  2007-04-25 14:42 
---
The workaround doesn't work.  I'll test the patch in comment #26, otherwise
I'm out of ideas and clue on how it should work.


-- 


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

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[rguenth at gcc dot gnu dot org]

--- Comment #28 from rguenth at gcc dot gnu dot org  2007-04-25 15:04 
---
Created an attachment (id=13439)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13439&action=view)
prototype patch

I'm testing this one.  It'll make aliasing slower and more conservative, so I
bet it's not the "right" or the "best" fix.


-- 


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

[Bug c/31702] New: Pointer Arithmetic Crash When Optimizing

[r dot slater at freescale dot com]

Compilation *crashes* when -O argument is greater than 0 (i.e. -O1, -O2, or
-O3).
If -O0 is used (or -O is omitted) compilation *passes*.

Note that "a" below needs to be external to the function.  If the line "char*
a;" is placed inside the test() function, compilation *passes*.


REDUCED TEST CASE:

File "test.c":
char*  a;

void test()
{
  a = "0";
  a = a + 1;
  return;

}  /* test() */



OUTPUT:

mcore-elf-gcc -c -O2 test.c
test.c: In function 'test':
test.c:9: error: unrecognizable insn:
(insn 12 11 13 1 (set (reg:SI 26)
(const:SI (plus:SI (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
(const_int 1 [0x1] -1 (nil)
(nil))
test.c:9: internal compiler error: in extract_insn, at recog.c:2084



GCC CONFIGURATION:

% mcore-elf-gcc -v
Using built-in specs.
Target: mcore-elf
Configured with: /tmp/bld/gcc/gcc-4.1.2/configure --target=mcore-elf
--enable-languages=c,c++ --enable-multilib --with-gnu-as --with-gnu-ld
--with-newlib
--prefix=/_TOOLS_/dist/gnu-gcc-4.1.2-binutils-2.17-mcore-elf/i686-pc-linux2.4
Thread model: single
gcc version 4.1.2


OTHER RELEASES:
Test case fails  in 4.1.1
Test case passes in 4.0.4


POSSIBLE DUPLICATES:
25690 -- Symptom is different (bug involves structure deference) but cause
might be the same (points to the same line of code in the compiler source)


-- 
   Summary: Pointer Arithmetic Crash When Optimizing
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: r dot slater at freescale dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mcore-elf


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

[Bug c++/31698] ICE in compare_name_with_value, at tree-vrp.c:3272

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-04-25 15:21 ---
This is related to PR29446, backporting the fix for it should fix this one
also.
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||29446
 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 15:21:34
   date||


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

[Bug tree-optimization/31698] [4.1 Regression] ICE in compare_name_with_value, at tree-vrp.c:3272

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |tree-optimization
Summary|ICE in  |[4.1 Regression] ICE in
   |compare_name_with_value, at |compare_name_with_value, at
   |tree-vrp.c:3272 |tree-vrp.c:3272
   Target Milestone|--- |4.1.3


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

[Bug rtl-optimization/31703] New: [4.3 regression]: Gcc 4.3 revision 124101 failed to compile gcc 3.2

[hjl at lucon dot org]

bash-3.1$ ./xgcc -m32 -B./ -O2 -S /tmp/reload1.i 
reload1.c: In function ‘reload_reg_free_p’:
reload1.c:4420: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4677
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Revision 123850 is OK.


-- 
   Summary: [4.3 regression]: Gcc 4.3 revision 124101 failed to
compile gcc 3.2
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/31703] [4.3 regression]: Gcc 4.3 revision 124101 failed to compile gcc 3.2

[hjl at lucon dot org]

--- Comment #1 from hjl at lucon dot org  2007-04-25 15:25 ---
Created an attachment (id=13440)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13440&action=view)
A testcase


-- 


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

[Bug middle-end/31697] [4.3 Regression] Crash of gen. prog. when using -funroll-loops -march=opteron

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[Regression 4.3] Crash of   |[4.3 Regression] Crash of
   |gen. prog. when using - |gen. prog. when using -
   |funroll-loops -march=opteron|funroll-loops -march=opteron
   Target Milestone|--- |4.3.0


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

[Bug c/31695] __builtin_ctzll slower than 2*__builtin_ctz

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-04-25 15:38 ---
Because it calls into libgcc and that without tail-calling:

_Z5func1y:
.LFB2:
pushl   %ebp
.LCFI2:
movl%esp, %ebp
.LCFI3:
subl$24, %esp
.LCFI4:
movl8(%ebp), %eax
movl12(%ebp), %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
call__ctzdi2
leave
ret

libgcc implements it as

int
__ctzDI2 (UDWtype x)
{
  const DWunion uu = {.ll = x};
  UWtype word;
  Wtype ret, add;

  if (uu.s.low)
word = uu.s.low, add = 0;
  else
word = uu.s.high, add = W_TYPE_SIZE;

  count_trailing_zeros (ret, word);
  return ret + add;
}

(count_trailing_zeros is expanded to asm bsfl on x86, that's ok)

The question remains why we don't tailcall.  And we could expand the
long-long version inline.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 15:38:21
   date||


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

[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions

[schwab at suse dot de]

--- Comment #40 from schwab at suse dot de  2007-04-25 15:46 ---
Closing for now.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/31704] New: x86_64 poor floating point register allocation across function call

[ian at airs dot com]

When I compile this test case with -O2 for x86_64:

extern void g (void);
float
f (float sum, float mult, int *pi)
{
  int i, j;
  for (i = 0; i < 10; ++i)
{
  g ();
  for (j = 0; j < 1000; ++j)
sum += *pi++ * mult;
}
  return sum;
}

I get this result:

f:
.LFB2:
pushq   %rbp
.LCFI0:
movaps  %xmm0, %xmm2
xorl%ebp, %ebp
pushq   %rbx
.LCFI1:
movq%rdi, %rbx
subq$40, %rsp
.LCFI2:
movss   %xmm1, 28(%rsp)
.L2:
movss   %xmm2, (%rsp)
callg
cvtsi2ss(%rbx), %xmm0
leaq4(%rbx), %rax
movl$1, %edx
movss   (%rsp), %xmm2
mulss   28(%rsp), %xmm0
addss   %xmm0, %xmm2
.p2align 4,,7
.L3:
cvtsi2ss(%rax), %xmm1
addl$1, %edx
addq$4, %rax
cmpl$1000, %edx
mulss   28(%rsp), %xmm1
addss   %xmm1, %xmm2
jne .L3
addl$1, %ebp
addq$4000, %rbx
cmpl$10, %ebp
jne .L2
addq$40, %rsp
movaps  %xmm2, %xmm0
popq%rbx
popq%rbp
ret

In the original code, the inner loop is performance critical.  Note that this
compiles into a mulss loading a value from memory.  It would be more efficient
to have the value in a register during the inner loop.  In fact the value was
in a register, but we stored it in the stack because it crossed the function
call, and we load it from the stack once for each inner loop iteration rather
than once for each outer loop iteration.

I don't see a simple approach to fixing this.  Some sort of live range
splitting might work.


-- 
   Summary: x86_64 poor floating point register allocation across
function call
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[rguenth at gcc dot gnu dot org]

--- Comment #29 from rguenth at gcc dot gnu dot org  2007-04-25 16:32 
---
Oh, btw. why the may_aliases bitmap for SMT.11 is empty on entry to the loops
computing the transitive closure (it tries to, right?) is that SFT.0 is not
considered stored to in the first nested loop over pointers and addressable
vars.  Shouldn't we add the vars NMT aliases to ai->written_vars in
compute_flow_sensitive_aliasing?  This also seems to fix the problem:

Index: tree-ssa-alias.c
===
*** tree-ssa-alias.c(revision 124151)
--- tree-ssa-alias.c(working copy)
*** compute_flow_sensitive_aliasing (struct 
*** 1142,1152 
 one).  Note that only pointers that have been dereferenced will
 have a name memory tag.  */
if (pi->name_mem_tag && pi->pt_vars)
!   EXECUTE_IF_SET_IN_BITMAP (pi->pt_vars, 0, j, bi)
! {
!   add_may_alias (pi->name_mem_tag, referenced_var (j));
!   add_may_alias (v_ann->symbol_mem_tag, referenced_var (j));
! }
  }
  }

--- 1142,1159 
 one).  Note that only pointers that have been dereferenced will
 have a name memory tag.  */
if (pi->name_mem_tag && pi->pt_vars)
!   {
! bool stored_to = bitmap_bit_p (ai->dereferenced_ptrs_store,
!DECL_UID (SSA_NAME_VAR (ptr)));
! EXECUTE_IF_SET_IN_BITMAP (pi->pt_vars, 0, j, bi)
!   {
! add_may_alias (pi->name_mem_tag, referenced_var (j));
! if (stored_to)
!   bitmap_set_bit (ai->written_vars,
!   DECL_UID (referenced_var (j)));
! add_may_alias (v_ann->symbol_mem_tag, referenced_var (j));
!   }
!   }
  }
  }



-- 


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

[Bug fortran/31696] -malign-double trashes fortran format

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-04-25 16:34 ---
what do you expect from an abi changing option?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c/31702] Pointer Arithmetic Crash When Optimizing

[eweddington at cso dot atmel dot com]

--- Comment #1 from eweddington at cso dot atmel dot com  2007-04-25 16:34 
---
This is very probably an mcore target issue. The test case passes for the AVR
target for 4.1.1 and 4.1.2 with all -O settings (0,1,2,3,s).


-- 


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

[Bug target/31702] Pointer Arithmetic Crash When Optimizing

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target
   Keywords||ice-on-valid-code


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

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[rguenth at gcc dot gnu dot org]

--- Comment #30 from rguenth at gcc dot gnu dot org  2007-04-25 16:42 
---
Created an attachment (id=13441)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13441&action=view)
a patch I like more

this one attached, bootstrap/testing in progress.


-- 


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

[Bug c++/31439] [4.3 regression] ICE with variadic template and broken specialization

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 16:44:18
   date||


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

[Bug c++/31441] [4.3 regression] ICE with variadic template and specialization

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 16:44:51
   date||


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

[Bug c++/31442] [4.3 regression] ICE with variadic template and default argument

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 16:45:13
   date||


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

[Bug c++/31443] [4.3 regression] ICE with invalid use of parameter pack in member template

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 16:45:46
   date||


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

[Bug c++/31444] [4.3 regression] ICE with invalid use of parameter pack in member template

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 16:46:21
   date||


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

[Bug fortran/31696] -malign-double trashes fortran format

[KnowlesPJ at Cardiff dot ac dot uk]

--- Comment #2 from KnowlesPJ at Cardiff dot ac dot uk  2007-04-25 16:47 
---
I don't understand your response, or the assumptions that might be behind it.
The program is standard fortran that compiles without warning, and I cannot see
why I would not want doubles aligned at 64 bits on x86 hardware, just like all
the other compilers, including the other free one, do. Is it written down
somewhere that there is no intention to support this mode of operation in the
foreseeable future? Google sends me to, for example,
http://gcc.gnu.org/ml/fortran/2007-02/msg00026.html which does not undermine my
assumptions as unreasonable.  If you speak on behalf of the gfortran community
in saying you will not address this, then we will simply once again for a while
walk away from attempting support of gfortran in our large and widely-used
code.


-- 

KnowlesPJ at Cardiff dot ac dot uk changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug c++/30431] failure to check for visible declaration of friend function to template class

[vbraun at physics dot upenn dot edu]

--- Comment #4 from vbraun at physics dot upenn dot edu  2007-04-25 16:51 
---
Super-condensed testcase (gcc 4.1.2):

-- snip on -
template void f() {}
class A
{
  void f() {};
  friend void f();   // line 5
};
-- snip off -

[EMAIL PROTECTED] test]$ c++4 -Wall -pedantic friendtest.cc
friendtest.cc:5: error: variable or field ‘f’ declared void
friendtest.cc:5: error: ‘f’ is neither function nor member function; cannot be
declared friend
friendtest.cc:5: error: expected ‘;’ before ‘<’ token


The following versions all compile correctly (but do different things):

-- snip on -
template void f() {}
class A
{
  void f() {};
  friend void ::f();   // Explicitly name scope
};

template void f() {}
class A
{
  friend void f();   // friend before member
  void f() {};
};

template void f() {}
class A
{
  void f() {};
  template friend void f(); // many-to-many friend
};

void f() {}
class A
{
  void f() {};
  friend void f(); // no template
};
-- snip off 

Something is wrong with the friend lookup after a member of the same name is
encountered. After seeing the class member f (either data member or member
function), gcc forgets that the template function f is in the current
namespace. 

See also: Discussion for friend lookup rules.
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#166
According to this, the code should be valid.

Bug 17122 is a duplicate, but did not see any activity in 1 year.


-- 

vbraun at physics dot upenn dot edu changed:

   What|Removed |Added

 CC||vbraun at physics dot upenn
   ||dot edu


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

[Bug c++/31445] [4.3 regression] type_argument_pack not supported by dump_type

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 16:46:50
   date||


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

[Bug driver/31107] --target-help doesn't say which options are compiler, assembler or linker options

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rsandifo at sources dot
   ||redhat dot com
 AssignedTo|unassigned at gcc dot gnu   |richard at codesourcery dot
   |dot org |com
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[dberlin at dberlin dot org]

--- Comment #31 from dberlin at gcc dot gnu dot org  2007-04-25 17:01 
---
Subject: Re:  [4.2 Regression] -O3 optimizer bug

On 25 Apr 2007 15:32:41 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #29 from rguenth at gcc dot gnu dot org  2007-04-25 16:32 
> ---
> Oh, btw. why the may_aliases bitmap for SMT.11 is empty on entry to the loops
> computing the transitive closure (it tries to, right?) is that SFT.0 is not
> considered stored to in the first nested loop over pointers and addressable
> vars.  Shouldn't we add the vars NMT aliases to ai->written_vars in
> compute_flow_sensitive_aliasing?

This is a better fix.
The other "fix" is just a hack.  Aliasing is not symmetric, so we
shouldn't make the two points-to sets equal.

However, I bet if you look at where we initially add written vars,
you'll discover we are missing it there for some reason, and don't
need to post-add it like you do here.

I think i fixed something like this in 4.3 where we didn't consider
stores to globals or arguments to be written or somesuch when we were
initially generating written vars.


-- 


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

[Bug tree-optimization/29446] [4.2 Regression] VRP ICE in compare_names

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2007-04-25 17:10 
---
Subject: Bug 29446

Author: rguenth
Date: Wed Apr 25 17:10:31 2007
New Revision: 124158

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

PR tree-optimization/31698
* g++.dg/other/pr31698.C: New testcase.

Backport from mainline:
2006-10-13  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/29446
* tree-vrp.c (fix_equivalence_set): Remove.
(extract_range_from_assert): Do not call fix_equivalence_set.
(debug_value_range): Print a newline.
(compare_name_with_value): For equivalence sets with
inconsistent value ranges conservatively bail out.
(compare_names): Likewise.

* gcc.dg/torture/pr29446.c: New testcase.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/pr31698.C
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr29446.c
  - copied unchanged from r117705,
trunk/gcc/testsuite/gcc.dg/torture/pr29446.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/tree-vrp.c


-- 


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

[Bug tree-optimization/31698] [4.1 Regression] ICE in compare_name_with_value, at tree-vrp.c:3272

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-04-25 17:10 ---
Subject: Bug 31698

Author: rguenth
Date: Wed Apr 25 17:10:31 2007
New Revision: 124158

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

PR tree-optimization/31698
* g++.dg/other/pr31698.C: New testcase.

Backport from mainline:
2006-10-13  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/29446
* tree-vrp.c (fix_equivalence_set): Remove.
(extract_range_from_assert): Do not call fix_equivalence_set.
(debug_value_range): Print a newline.
(compare_name_with_value): For equivalence sets with
inconsistent value ranges conservatively bail out.
(compare_names): Likewise.

* gcc.dg/torture/pr29446.c: New testcase.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/pr31698.C
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr29446.c
  - copied unchanged from r117705,
trunk/gcc/testsuite/gcc.dg/torture/pr29446.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/tree-vrp.c


-- 


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

[Bug driver/31694] __GFORTRAN__ preprocessor macro

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[rguenth at gcc dot gnu dot org]

--- Comment #32 from rguenth at gcc dot gnu dot org  2007-04-25 17:13 
---
No idea.  The only place I found was setup_pointers_and_addressables, but that
hits the path only if

  /* Add pointer variables that have been dereferenced to the POINTERS
 array and create a symbol memory tag for them.  */
  if (POINTER_TYPE_P (TREE_TYPE (var)))
{

but we don't have a pointer through which SMT we do store to SFT.0, and we
don't seem to care about NMTs and their aliases in this loop at all.

(I'm lost here now, I'll post the patch and the result of bootstrap & test
tomorrow -- I'd love to see a better approach to fixing this ;)


-- 


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

[Bug rtl-optimization/31703] [4.3 regression]: Gcc 4.3 revision 124101 failed to compile gcc 3.2

[hjl at lucon dot org]

--- Comment #2 from hjl at lucon dot org  2007-04-25 17:24 ---
I have verified that this patch

http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01399.html

causes this regression. On Linux/i686, it fails to compile gcc 3.2. On
Linux/x86-64, it miscompiles gcc 3.2.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Severity|normal  |critical


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

[Bug c++/31431] [4.3 regression] ICE with invalid parameter pack

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 17:57:35
   date||


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

[Bug c++/31432] [4.3 regression] ICE with invalid parameter pack for template struct

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 17:58:26
   date||


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

[Bug c++/31433] [4.3 regression] ICE with invalid parameter pack for template struct

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 17:58:46
   date||


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

[Bug c++/31434] [4.3 regression] ICE with invalid use of parameter pack in function arg

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 17:59:04
   date||


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

[Bug c++/31435] [4.3 regression] ICE with invalid use of parameter pack in function arg

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 17:59:24
   date||


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

[Bug c++/31436] [4.3 regression] ICE with invalid use of parameter pack in function arg

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 17:59:43
   date||


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

[Bug c++/31437] [4.3 regression] ICE with invalid use of parameter pack in member function arg

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 18:00:05
   date||


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

[Bug c++/31438] [4.3 regression] ICE with invalid use of parameter pack in specialization

[dgregor at gcc dot gnu dot org]

-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dgregor at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 18:00:43
   date||


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

[Bug preprocessor/30867] Can we have a new __DATE__ which is sortable, eg YYYY-MM-DD

[eweddington at cso dot atmel dot com]

--- Comment #3 from eweddington at cso dot atmel dot com  2007-04-25 18:04 
---
Note that the -MM-DD date format is ISO standard 8601, which also includes
formats for time as well.



Any new formats for __DATE__ and __TIME__ should probably conform to this
standard.


-- 


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

[Bug target/31701] Program giving segmentation fault with '-O2' optimization.

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target
   Keywords||wrong-code


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

[Bug fortran/31616] testsuite failures in gfortran.dg/open_errors.f90

[ghazi at gcc dot gnu dot org]

--- Comment #7 from ghazi at gcc dot gnu dot org  2007-04-25 18:07 ---
Patch installed


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ghazi at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-04-18 06:35:43 |2007-04-25 18:07:23
   date||


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

[Bug fortran/31616] testsuite failures in gfortran.dg/open_errors.f90

[ghazi at gcc dot gnu dot org]

--- Comment #8 from ghazi at gcc dot gnu dot org  2007-04-25 18:08 ---
Updated testsuite results:

http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01287.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/31696] -malign-double trashes fortran format

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-04-25 18:12 ---
Does not matter, this option changes the ABI, it is like any other ABI changing
option, you should not use it unless you understand what you are doing which is
clearly not the case.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/31615] testsuite failure in gfortran.dg/vect/vect-5.f90

[ghazi at gcc dot gnu dot org]

--- Comment #6 from ghazi at gcc dot gnu dot org  2007-04-25 18:14 ---
(In reply to comment #5)
> ah, ok. so, in that case we probably want to just change the '3' to '2' in the
> above test:
> Index: testsuite/gfortran.dg/vect/vect-5.f90
> ===
> --- testsuite/gfortran.dg/vect/vect-5.f90   (revision 123954)
> +++ testsuite/gfortran.dg/vect/vect-5.f90   (working copy)
> @@ -38,7 +38,7 @@
>  ! { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  } }
>  ! { dg-final { scan-tree-dump-times "Alignment of access forced using 
> peeling"
> 1 "vect" { xfail { vect_no_align } } } }
>  ! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 
> "vect"
> { xfail { vect_no_align } } } }
> -! { dg-final { scan-tree-dump-times "Alignment of access forced using
> versioning." 3 "vect" { target { ilp32 && vect_no_align } } } }
> +! { dg-final { scan-tree-dump-times "Alignment of access forced using
> versioning." 2 "vect" { target { ilp32 && vect_no_align } } } }
>  ! We also expect to vectorize one loop for lp64 targets that support
>  ! misaligned access:

Are you going to submit/install your patch?


-- 


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

[Bug rtl-optimization/31703] [4.3 regression]: Gcc 4.3 revision 124101 failed to compile gcc 3.2

[hjl at lucon dot org]

--- Comment #3 from hjl at lucon dot org  2007-04-25 18:15 ---
rewrite_bittest has

  lhs = GENERIC_TREE_OPERAND (stmt, 0);
  ...

  /* A & (1 << B) */
  t = fold_build2 (BIT_AND_EXPR, TREE_TYPE (a), a, name);
  stmt2 = build_gimple_modify_stmt (lhs, t);

When A & (1 << B) is long long and lhs is int, we may get a problem.


-- 


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

[Bug c++/16625] Discarded Linkonce sections in .rodata

[zhong dot xie at yahoo dot ca]

--- Comment #48 from zhong dot xie at yahoo dot ca  2007-04-25 18:16 ---
Solaris 10 x86  i386
gcc 3.3.6, 
binutils 2.17.50.20070307
has the same issue. 
binutils 2.17.50.20070307 not even compile under this platform. We have to
modify some scripts to make it work.


-- 

zhong dot xie at yahoo dot ca changed:

   What|Removed |Added

 CC||zhong dot xie at yahoo dot
   ||ca


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

[Bug libgcj/31700] [JNI] -X options not recognised by JNI_CreateJavaVM

[tromey at gcc dot gnu dot org]

--- Comment #1 from tromey at gcc dot gnu dot org  2007-04-25 18:38 ---
Yeah, this logic looks bogus.


-- 

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 |2007-04-25 18:38:21
   date||


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

[Bug debug/29202] [4.1/4.2/4.3 Regression] ICE with external template and const data in the template

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2007-04-25 18:55 ---
A regression hunt on powerpc-linux using the reduced testcase from comment #3
with "-g2 -feliminate-dwarf2-dups -finline-functions" identified the following
patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=100802

r100802 | hubicka | 2005-06-09 16:21:36 + (Thu, 09 Jun 2005)

The failure also occurs with current trunk.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug inline-asm/31705] New: inline assembler causes ICE: extract_constrain_insn_cached, at recog.c:2002

[fultonm at ca dot ibm dot com]

The source file:

double helperDoubleTan(double * a, double * b)
{
double tmpA, tmpB;

tmpA = *a;
{
double y[3] = { 0.0, 0.0, 0.0 };
double r;
int lq;

lq = __ieee754_rem_pio2(tmpA, y);
r = y[0];
if (lq & 0x1) {
  __asm__ __volatile__("fptan; fdivp;fchs;":
"=&t"(tmpB):"f"(r));
  tmpB = __kernel_tan(y[0], y[1], 1 - ((lq & 1) << 1));
} else {
tmpB = tan(r);
}
}
*b = tmpB;
return 0;
}

compiled with gcc -O -c testcase.c

results in:

testcase.c: In function ‘helperDoubleTan’:
testcase.c:17: warning: incompatible implicit declaration of built-in function
‘tan’
testcase.c:22: error: unrecognizable insn:
(insn 36 34 96 (parallel [
(set (reg/v:DF 8 st [orig:58 tmpB.26 ] [58])
(asm_operands/v:DF ("fptan; fdivp;fchs;") ("=&t") 0 [
(reg:DF 8 st)
]
 [
(asm_input:DF ("f"))
] ("testcase.c") 14))
(clobber (reg:QI 19 dirflag))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) -1 (nil)
(expr_list:REG_UNUSED (reg:QI 17 flags)
(expr_list:REG_UNUSED (reg:QI 18 fpsr)
(expr_list:REG_UNUSED (reg:QI 19 dirflag)
(expr_list:REG_UNUSED (reg/v:DF 8 st [orig:58 tmpB.26 ] [58])
(nil))

Output from gcc -v:

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)


-- 
   Summary: inline assembler causes ICE:
extract_constrain_insn_cached, at recog.c:2002
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fultonm at ca dot ibm dot com
 GCC build triplet:  i486-linux-gnu
  GCC host triplet:  i486-linux-gnu
GCC target triplet:  i486-linux-gnu


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

[Bug libfortran/31706] New: recl specified for unformatted sequential file does not work

[gcc-bugs at wbfb dot de]

PROGRAM ReclBug

   OPEN (UNIT= 11, FILE= 'bla', ACCESS= 'SEQUENTIAL', &
 FORM= 'UNFORMATTED', RECL= 100, &
 STATUS= 'UNKNOWN', ACTION= 'WRITE', IOSTAT= iostat )

   IF (iostat /= 0) STOP

   WRITE (11) 1,2,3

   CLOSE (11, STATUS= 'KEEP')

 END PROGRAM ReclBug

!! > gfortran recl-bug.f90 -static
!! > ./a.out 
!! At line 10 of file recl-bug.f90
!! Fortran runtime error: I/O past end of record on unformatted file


-- 
   Summary: recl specified for unformatted sequential file does not
work
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugs at wbfb dot de
  GCC host triplet: amd64 Linux


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

[Bug target/18989] A few potentially ominous, and several likely harmless warnings during 4.0 build

[aesok at gcc dot gnu dot org]

--- Comment #3 from aesok at gcc dot gnu dot org  2007-04-25 19:38 ---
Subject: Bug 18989

Author: aesok
Date: Wed Apr 25 19:38:32 2007
New Revision: 124159

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124159
Log:
PR target/18989
* config/avr/avr.h (ASM_OUTPUT_ALIGN): Redefine.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/avr/avr.h


-- 


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

[Bug tree-optimization/30567] [4.2 Regression] -O3 optimizer bug

[dberlin at gcc dot gnu dot org]

--- Comment #33 from dberlin at gcc dot gnu dot org  2007-04-25 19:45 
---
I think richi said on IRC that the following backport from 4.3 will fix it (if
so, it's the correct fix here)

Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c  (revision 122853)
+++ tree-ssa-structalias.c  (working copy)
@@ -3228,7 +3228,8 @@ update_alias_info (tree stmt, struct ali
  /* If the statement makes a function call, assume
 that pointer OP will be dereferenced in a store
 operation inside the called function.  */
- if (get_call_expr_in (stmt))
+ if (get_call_expr_in (stmt)
+  || stmt_escape_type == ESCAPE_STORED_IN_GLOBAL)
{
  bitmap_set_bit (ai->dereferenced_ptrs_store, DECL_UID (var));
  pi->is_dereferenced = 1;


-- 


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

[Bug fortran/31683] bogus warnings with optional arguments

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2007-04-25 19:49 ---
Has anyone any objection if I change the purpose of this PR to:
-
gfortran should detect that the local variable ncoset is never allocated -
as NAG f95 does:
Error: foo.f90, line 45: ALLOCATABLE array NCOSET used but never ALLOCATEd
This includes 
-

Regarding the original problem with CP2k: A dependence on the optimization
options usually indicates a middle-end problem rather than a (Fortran)
front-end problem. As it occurred around the time I got core-dumps for the
Polyhedron test cases, the easiest is probably to wait until PR 31699 and PR
31697 are fixed. If we are lucky, CP2k is then fixed as well. If not, well,
then one can still dig for the problem.


-- 


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

[Bug target/28197] longjmp and alloca cause bus error at -O0

[geoffk at gcc dot gnu dot org]

--- Comment #3 from geoffk at gcc dot gnu dot org  2007-04-25 19:49 ---
I'm fairly sure this is in fact a bug in GCC.  The problem is that in a routine
which uses setjmp, alloca() must ensure that the previous stack backchain is
preserved, which means it needs to allocate enough space for its allocation,
the linkage area, *and* arguments for any called function.  It's not allocating
enough space for called function arguments.  In the routine given, it's only
allocating 32 bytes where it actually needs to allocate 64.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/28197] longjmp and alloca cause bus error at -O0

[geoffk at gcc dot gnu dot org]

-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-25 19:50:13
   date||


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

[Bug target/18989] A few potentially ominous, and several likely harmless warnings during 4.0 build

[aesok at gcc dot gnu dot org]

--- Comment #4 from aesok at gcc dot gnu dot org  2007-04-25 19:52 ---
Subject: Bug 18989

Author: aesok
Date: Wed Apr 25 19:52:21 2007
New Revision: 124162

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124162
Log:
PR target/18989
* config/avr/avr.h (ASM_OUTPUT_ALIGN): Redefine.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/avr/avr.h


-- 


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

[Bug libfortran/31706] recl specified for unformatted sequential file does not work

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-04-25 19:54 ---
What is your gfortran version (gfortran -v)?

I cannot repoduce it with neither -static nor without using
gfortran 4.1.3 20070413 (prerelease)
and 4.3.0 20070425 (experimental)
under x86_64-unknown-linux-gnu


-- 


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

[Bug fortran/31696] -malign-double trashes fortran format

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-04-25 19:58 ---
>From the man page:
"-malign-double
 -mno-align-double
Control whether GCC aligns "double", "long double", and "long long" variables
on a two word boundary or a one word boundary.  Aligning "double" variables on
a two word boundary will produce code that runs somewhat faster on a Pentium at
the expense of more memory. On x86-64, -malign-double is enabled by default."

NOW COMES THE IMPORTANT PART:

"Warning: if you use the -malign-double switch, structures containing the above
types will be aligned differently than the published application binary
interface specifications for the 386 and will not be binary compatible with
structures in code compiled without that switch."


Thus if you want to use -malign-double, you need to compile at least also the
gfortran library with that option. (Maybe other libraries as well.)


-- 


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

[Bug fortran/31645] Error on reading Byte Order Mark

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||04/msg01731.html
   Keywords||patch
   Target Milestone|--- |4.3.0


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

[Bug fortran/31615] testsuite failure in gfortran.dg/vect/vect-5.f90

[dorit at il dot ibm dot com]

--- Comment #7 from dorit at il dot ibm dot com  2007-04-25 21:30 ---
> Are you going to submit/install your patch?

yes, I'll go ahead and submit the patch


-- 


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

[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-04-25 21:31 ---
A regression hunt on powerpc-linux looking for DWARF2 line number information
for lines with gotos identified this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=83385

r83385 | hubicka | 2004-06-19 15:33:06 + (Sat, 19 Jun 2004)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/29000] [4.2/4.3 regression] ICE on invalid use of template in statement-expr

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-04-25 21:50 ---
A regression hunt on powerpc-linux for the changeover from error message to ICE
identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=116311

r116311 | jason | 2006-08-21 20:54:57 + (Mon, 21 Aug 2006)


-- 

janis 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=29000

[Bug target/30052] [4.2 Regression] possible quadratic behaviour.

[pluto at agmk dot net]

--- Comment #15 from pluto at agmk dot net  2007-04-25 21:56 ---
(In reply to comment #14)

> > 4.1.2 uses 56MB.
> I'll backport the changes (this is more or less copying tree-ssa-structalias.c
> from 4.3 to 4.2 and modifying the few things that changed in 4.3 :P)

Daniel, are you working on it?


-- 


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

[Bug tree-optimization/31703] [4.3 regression]: Gcc 4.3 revision 124101 failed to compile gcc 3.2

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
   Keywords||ice-on-valid-code
   Target Milestone|--- |4.3.0


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

[Bug libfortran/31706] recl specified for unformatted sequential file does not work

[gcc-bugs at wbfb dot de]

--- Comment #2 from gcc-bugs at wbfb dot de  2007-04-25 22:16 ---
(In reply to comment #1)
> What is your gfortran version (gfortran -v)?
> 
> I cannot repoduce it with neither -static nor without using
> gfortran 4.1.3 20070413 (prerelease)
> and 4.3.0 20070425 (experimental)
> under x86_64-unknown-linux-gnu
> 

 gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /projects/tob/gcc-4_2-branch/configure
--enable-languages=c,fortran --prefix=/projects/tob/gcc-4.2
Thread model: posix
gcc version 4.2.0 20070301 (prerelease)


-- 


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

[Bug libfortran/31706] recl specified for unformatted sequential file does not work

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2007-04-25 22:39 ---
This is PR 31099, fixed on more recent versions of gfortran.

Closing.

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


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL

[tkoenig at gcc dot gnu dot org]

--- Comment #20 from tkoenig at gcc dot gnu dot org  2007-04-25 22:39 
---
*** Bug 31706 has been marked as a duplicate of this bug. ***


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gcc-bugs at wbfb dot de


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

[Bug fortran/31696] -malign-double trashes fortran format

[KnowlesPJ at Cardiff dot ac dot uk]

--- Comment #5 from KnowlesPJ at Cardiff dot ac dot uk  2007-04-25 22:46 
---
I guess I walk away from you guys at this point. You need to think carefully
about the fortran standard, which does not define any abi whatsoever
(unfortunately). The fortran programmer is not supposed to think about this,
but instead write within the language. It is just different to C and CPP. If
you can not think about the overall system (compiler and supporting libraries
that aim to implement the standard) as a single entity instead of just the
compiler, then you will not win friends in the application code development
community.


-- 


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

[Bug fortran/31696] -malign-double trashes fortran format

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-04-25 22:58 ---
Yes the fortran standard does not define the ABI, the target which you are
compiling for does and if you change it in any way (which is what options like
-malign-double does) you are going to run into problems like this.

GCC is more than a fortran compiler and more than a C compiler, if you use
options in general that warn that they change the ABI (this is documented as
shown by comment #4 ), you should be expected to understand what you are trying
to do might not always work.  There are so many options which change the ABI
(argument passing, struct layout) that it is not the correct thing to warn
about all of them,  though maybe we should not supply them as options in the
first place but that is up to the target maintainers to decide if they want to
have these options.  Also note -malign-double is just an example of the ABI
changing options and it just happens to be the most reported one that "breaks"
code.


-- 


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