[Bug fortran/40576] [4.4, 4.5 Regression] Endless loop in internal write

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
   Target Milestone|4.5.0   |4.4.1


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

[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2009-06-29 07:49 ---
Can this be backported to 4.4? If so, it should happen soonish to be in 4.4.1.
Paul, shall I do it for you?


-- 


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

[Bug c/40579] New: gcc -O2 optimization causes infinite loop and wrong output

[dentongosnell at yahoo dot com]

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /root/gcc-4.4.0/configure --prefix=/opt/gcc-4.4.0
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 (GCC)

Here is a program to reproduce this problem :-

#include 
#include 

#define MinWordStr "-2147483648"
#define MinWord  ((long)0x8000)   /* smallest word */

/* Simple function to convert long to a string */
static char * itos(long num)
{
char *p;
static char buff[64];

p = buff + sizeof(buff) - 1;

*p = '\0';
if (num >= 0L)
do {
*--p = num % 10L + '0';
num /= 10L;
} while (num != 0L);
else {
if (num == MinWord) {  /* max negative value */
p -= strlen (MinWordStr);
strcpy (p, MinWordStr);
}
else {
num = -num;
do {
*--p = '0' + (num % 10L);
num /= 10L;
} while (num != 0L);
*--p = '-';
}
}

return p;
}

int main() {
char *p;
long x = -2147483645;
int i;

for (i = 0; i < 4; ++i) {
p = itos(x);
printf("i=%d p=%s\n",i,p);
--x;
}

return 0;
}


When run with -O1 it runs okay.

$ gcc -O1 prog.c && ./a.out
i=0 p=-2147483645
i=1 p=-2147483646
i=2 p=-2147483647
i=3 p=-2147483648

But with -O2 it goes haywire.
$ gcc -O2 progg.c && ./a.out
i=0 p=-2147483645
i=1 p=-2147483646
i=2 p=-2147483647
i=3 p=-2147483648
i=4 p=-./,),(-*,)
i=5 p=-./,),(-*,*
i=6 p=-./,),(-*,+
i=7 p=-./,),(-*,,
...etc ad infinitum

Note that if the line
if (num == MinWord) {  /* max negative value */
is changed to
if (num == -num) {  /* max negative value */

a different (and also incorrect) result occurs with -O2
$ gcc -O2 prog.c && ./a.out
i=0 p=-2147483645
i=1 p=-2147483646
i=2 p=-2147483647
i=3 p=-./,),(-*,(

Other points:
1) this has something to do with the value of x reaching the most negative
32-bit long (ie: -2147483648, or 0x8000) - if it stays away from that by
initializing x = -2147483644 instead of -2147483645 it is okay.
2) gcc 2.95.3 seems to work okay with -O2


-- 
   Summary: gcc -O2 optimization causes infinite loop and wrong
output
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dentongosnell at yahoo dot com
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug target/31055] missed auto-vectorization optimization, when there is float to int conversion

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-06-29 08:35 ---
(In reply to comment #2)
> Still present in GCC 4.5.0 20090513.

Are you sure?

config/rs6000/rs6000.c has:

static tree
rs6000_builtin_conversion (unsigned int tcode, tree type)

rs6000 target is also a member of vect_intfloat_cvt in target-supports.exp.

Please note, that the testcase in Comment #0 is wrong, relevant cases in the
testsuite are gcc.dg/vect/vect-intfloat-conversion-X.c and
gcc.dg/vec/vect-floatint-conversion-X.c


-- 


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

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2009-06-29 08:47 ---
(In reply to comment #7)

> OTOH, doing integer arithmetics on 64bit _image_ of FP value has questionable
> usability, so the motivation to fix this PR is proportionally low...

So, wontfix.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/40580] New: Add -fcheck=pointer with runtime check for using an unallocated argument

[burnus at gcc dot gnu dot org]

If one passes an ALLOCATABLE variable as actual to a dummy argument which is
not ALLOCATBLE, the should be an optional run-time to check whether the
variable is allocated.

For pointers, one could check whether a pointer is NULL as this means
non-associated. Checking for an uninitialized pointer is more difficult ...

Using NAG f95 -C=pointer, the error is:
  ALLOCATABLE array N is not currently allocated
  Program terminated by fatal error
  In $main$, line 2 of test.f90

Using ifort -check pointers, the result is:
  forrtl: severe (408): fort: (7): Attempt to use pointer N when it is not
  associated with a target
  a.out  00402D2D  BAR 6  test.f90
  a.out  00402C60  MAIN__  2  test.f90

Remark: NAG f95 does the check for the actual argument, ifort does it before
using the dummy argument.

I think I would fiddle it into gfc_conv_procedure_call (-> se.pre) using the
check:
  if (actual->attr.allocatable
  && (!formal || !formal->attr.allocatable)
  && (gfc_option.rtcheck & GFC_RTCHECK_POINTER))
   generateCode: if( not associated(actual) ) then rt-error
  else if (actual->attr.pointer
   && (!formal || !forrmal->attr.pointer)
   && (gfc_option.rtcheck & GFC_RTCHECK_POINTER))
   generateCode: if( actual == NULL ) then rt-error

(The check will fail if the actual argument is an uninitialized pointer; for
this and further pointer checks, see PR .)

integer, allocatable :: n(:)
call bar(n)
contains
  subroutine bar(n)
integer :: n(:)
print *, n
  end subroutine bar
end


-- 
   Summary: Add -fcheck=pointer with runtime check for using an
unallocated argument
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug tree-optimization/40579] [4.3/4.4/4.5 Regression] gcc -O2 optimization causes infinite loop and wrong output

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-29 09:10 ---
The following loop invokes undefined behavior:

long x = -2147483645;
int i;

for (i = 0; i < 4; ++i) {
p = itos(x);
printf("i=%d p=%s\n",i,p);
--x;
}

because at iteration with i == 3 x is decremented and underflows.

This can be avoided as follows, which still shows the bug:

extern void abort (void);
static char * __attribute__((noinline))
itos(int num)
{
  return (char *)0;
}
static void __attribute__((noinline))
foo(int i, const char *x)
{
  if (i >= 4)
abort ();
}
int main()
{
  int x = -__INT_MAX__ + 3;
  int i;

  for (i = 0; i < 4; ++i)
{
  char *p;
  --x;
  p = itos(x);
  foo(i, p);
}

  return 0;
}

Fails when VRP and IVOPTs are enabled.  IVOPTs expresses i in terms of x:

:
  # x_16 = PHI 
  D.1693_15 = (unsigned int) x_16;
  D.1694_14 = 2147483652 - D.1693_15;
  i_13 = (int) D.1694_14;
  i_17 = i_13;
  x_5 = x_16 + -1;
  p_6 = itos (x_5);
  foo (i_17, p_6);
  if (x_5 != -2147483648)
goto ;
  else
goto ;

from which VRP concludes that the test is never true:

Value ranges after VRP:

x_5: [-INF, -2147483645]
...

Folding statement: if (x_5 != -2147483648)
Folding predicate x_5 != -2147483648 to 1

huh.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.3.3 4.4.0 4.5.0
  Known to work||4.2.4
   Last reconfirmed|-00-00 00:00:00 |2009-06-29 09:10:49
   date||
Summary|gcc -O2 optimization causes |[4.3/4.4/4.5 Regression] gcc
   |infinite loop and wrong |-O2 optimization causes
   |output  |infinite loop and wrong
   ||output
   Target Milestone|--- |4.3.4


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

[Bug tree-optimization/40579] [4.3/4.4/4.5 Regression] gcc -O2 optimization causes infinite loop and wrong output

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-06-29 09:12 ---
Mine.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2009-06-29 09:10:49 |2009-06-29 09:12:03
   date||


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

[Bug fortran/40581] New: Missed optimization in scalar operators on arrays

[burnus at gcc dot gnu dot org]

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b232bca9766094cc
which contains several tests:

- NR : Normal Routines
- ER : Elemental Routines
- NF : Normal Functions (scalar operators)
- EF : Elemental functions (vector operators)
- SC : Scalar Computation 

The interesting point is if one compares NF/NR or NF/ER.
Using ifort   11.1 with -O3 -xHostthe result is 1.16 or 1.03.
Using gfortran 4.5 with -O3 -march=native the result is 1.31 or 1.41
   using -funroll-loops -O3 -march=native   1.49 or 1.59
   using -fwhole-file   -O3 -march=native   1.33 or 1.42
   (latest draft patch posted to fortran@)

Expected: The NF version is faster.

In total, the result does not look bad for gfortran, however (AMD64):

gfortran -O3 -march=native -funroll-loops var_dep.f90 test.f90
 NR2.0121260  2.1001320  1.9041190
 ER1.8761170  1.9561219  1.8081129
 NF3.1001940  3.2042003  3.0761924
 EF2.6561656  2.6641660  2.6561661
 SC   2.00023651E-02  2.00023651E-02  1.60007477E-02

ifort -O3 -xHost var_dep.f90 test.f90

 NR2.396150  2.364148  2.324145
 ER2.224138  2.164135  2.172136
 NF2.768173  2.720170  2.736171
 EF2.592162  2.552160  2.560160
 SC   1.6001701E-02  2.458E-02  1.6000748E-02


-- 
   Summary: Missed optimization in scalar operators on arrays
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2009-06-29 09:20 ---
(In reply to comment #6)
> (In reply to comment #5)
> The following fixes the problem.  It needs to be checked to see if it is
> over-restrictive.

Yes it is - there is no need for this when the lhs section is contiguous.

I have modified gfc_full_array_ref_p to return a pointer to a boolean, which
indicates if the reference is contiguous or not. This works correctly with the
testcase and variants.

I will regtest and post to the list tonight.

Cheers

Paul


-- 


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

[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure

[pault at gcc dot gnu dot org]

--- Comment #10 from pault at gcc dot gnu dot org  2009-06-29 09:23 ---
(In reply to comment #9)
> Can this be backported to 4.4? If so, it should happen soonish to be in 4.4.1.
> Paul, shall I do it for you?
>

Thanks for the offer, Tobias - I'll be attending to it tonight.

Did you see that I have a fix for PR40551?

Cheers

Paul 


-- 


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

[Bug tree-optimization/40579] [4.3/4.4/4.5 Regression] gcc -O2 optimization causes infinite loop and wrong output

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-29 09:29 ---
Which is because we run into

static int
compare_values_warnv (tree val1, tree val2, bool *strict_overflow_p)
{
...
  /* We cannot compare overflowed values, except for overflow
 infinities.  */
  if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
{

and IVOPTs made the upper bound in the test TREE_OVERFLOW.

  if (x_5 != -2147483648(OVF))
goto ;


-- 


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

[Bug c/40582] New: ice for non-trivial conversion at assignment with -O2

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package sblim-sfcb-1.3.2-16.15
with the GCC compiler version 4.5 snapshot 20090625.
The compiler said

selectcond.c: In function '__eft_getSubCondAt':
selectcond.c:78:21: error: non-trivial conversion at assignment
struct CMPIInstance *
void *
# .MEM_38 = VDEF <.MEM_29>
D.7022.value.inst = SR.33_37;

selectcond.c:78:21: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source attached. Flag -O2 required.


-- 
   Summary: ice for non-trivial conversion at assignment with -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c/40582] ice for non-trivial conversion at assignment with -O2

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-06-29 10:42 ---
Created an attachment (id=18089)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18089&action=view)
C source code


-- 


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

[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-06-29 11:10 ---
Confirmed.  -fno-tree-sra fixes this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mjambor at suse dot cz
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-29 11:10:17
   date||
Summary|ice for non-trivial |[4.5 Regression] ice for
   |conversion at assignment|non-trivial conversion at
   |with -O2|assignment with -O2
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2

[jamborm at gcc dot gnu dot org]

--- Comment #3 from jamborm at gcc dot gnu dot org  2009-06-29 11:16 ---
OK, I'll have a look at it after I am done with PR 40554.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-06-29 11:10:17 |2009-06-29 11:16:14
   date||


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

[Bug tree-optimization/40570] [4.5 Regression] ice in get_constraint_for_ptr_offset with -O3

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2009-06-29 11:22 ---
I'm quite confident this is a cgraph bug => CCing honza.  (I'll try to keep
this on my radar but there are other issues for which I am certainly
responsible now). 


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jh at suse dot cz


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

[Bug fortran/40583] New: automatic preprocessing for .F90 or .F95 files fails with cc1 error (output filename specified twice)

[thomas dot orgis at awi dot de]

I do observe the behaviour with a gcc/gfortran installed from plain vanilla
upstream in Source Mage GNU/Linux; not with an older gfortran as packaged in
SuSE Linux. So I assume it's either a configuration issue (spec files?) or a
regression from 4.1.2 prerelease.

Anyhow: The automatic preprocessing as specified by the documentation, for
files named with capital "F" in the suffix, does not work.
Specifically this source, named testf95.F95:

program test

write(*,*) 'this code is on line', __LINE__

end program

Fails to compile with that line:

LANG=C gfortran -v -o testf95 testf95.F95 
Driving: gfortran -v -o testf95 testf95.F95 -lgfortranbegin -lgfortran -lm
-shared-libgcc
Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/specs
Target: x86_64-pc-linux-gnu
Configured with: /usr/src/gcc-4.3.3/configure --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix
--with-system-zlib --enable-languages=f95 --disable-multilib
--build=x86_64-pc-linux-gnu
Thread model: posix
gcc version 4.3.3 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' 'testf95' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/cc1 -E -lang-fortran
-traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v testf95.F95 -mtune=generic -o
/tmp/ccHnRPaP.f95 |n f951 /tmp/ccHnRPaP.f95 -quiet -dumpbase testf95.F95
-mtune=generic -auxbase testf95 -version -fpreprocessed -o /tmp/ccifqF7t.s
cc1: error: output filename specified twice
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include-fixed
 /usr/include
End of search list.
cc1: error: too many filenames given.  Type cc1 --help for usage
GNU C (GCC) version 4.3.3 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072


It works fine using the two-step procedure:

shell$ cpp -xf95-cpp-input testf95.F95 > testf95.f95
shell$ LANG=C gfortran -xf95 -o testf95 testf95.f95

Note: The second line _needs_ the -xf95 being specified. It fails otherwise.
But since this is not related to preprocessing, I'll create a separate bug.
I am aware of both issues possibly being caused by some missing bits in the
installation of gcc -- in which case I would like to know what we did wrong in
Source Mage. We tried to follow "the" procedure to install from upstream with
minimal hacking.


-- 
   Summary: automatic preprocessing for .F90 or .F95 files fails
with cc1 error (output filename specified twice)
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thomas dot orgis at awi dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/40584] New: gfortran does not recognize .f95 files

[thomas dot orgis at awi dot de]

Note: This may be related to #40583 (possibly an issue with the installation)

I do observe the behaviour with a gcc/gfortran installed from plain vanilla
upstream in Source Mage GNU/Linux; not with an older gfortran as packaged in
SuSE Linux. So I assume it's either a configuration issue (spec files?) or a
regression from 4.1.2 prerelease.

Simple as that: gfortran does not recognize .f95 files.
Specifically this source, named testf95.f95:

program test

write(*,*) 'this code is on line', 3

end program

Fails to compile with that line:

shell$ LANG=C gfortran -o testf95 testf95.f95 
gfortran: language f95
@c++-header:
%{E|M|MM:cc1plus -E -D_GNU_SOURCE %(cpp_options) %2 %(cpp_debug_options)}
%{!E:%{!M:%{!MM: %{save-temps|no-integrated-cpp:cc1plus -E -D_GNU_SOURCE
%(cpp_options) %2 -o %{save-temps:%b.ii} %{!save-temps:%g.ii} \n} cc1plus
%{save-temps|no-integrated-cpp:-fpreprocessed %{save-temps:%b.ii}
%{!save-temps:%g.ii}}
%{!save-temps:%{!no-integrated-cpp:%(cpp_unique_options)}} %(cc1_options)
-D_GNU_SOURCE %2 %{+e1*} -o %g.s %{!o*:--output-pch=%i.gch}
%W{o*:--output-pch=%*}%V}}} not recognized
gfortran: language f95
@c++-header:
%{E|M|MM:cc1plus -E -D_GNU_SOURCE %(cpp_options) %2 %(cpp_debug_options)}
%{!E:%{!M:%{!MM: %{save-temps|no-integrated-cpp:cc1plus -E -D_GNU_SOURCE
%(cpp_options) %2 -o %{save-temps:%b.ii} %{!save-temps:%g.ii} \n} cc1plus
%{save-temps|no-integrated-cpp:-fpreprocessed %{save-temps:%b.ii}
%{!save-temps:%g.ii}}
%{!save-temps:%{!no-integrated-cpp:%(cpp_unique_options)}} %(cc1_options)
-D_GNU_SOURCE %2 %{+e1*} -o %g.s %{!o*:--output-pch=%i.gch}
%W{o*:--output-pch=%*}%V}}} not recognized
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/ld:testf95.f95:
file format not recognized; treating as linker script
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/bin/ld:testf95.f95:1:
syntax error
collect2: ld returned 1 exit status

It's fine with specifying the type of source:

shell$ LANG=C gfortran -xf95 -o testf95 testf95.f95

The automatism works fine for .f90 files, so I suppose it is supposed to work
for .f95, too?

I guess a fix is simple (making that file suffix known). I am rather wondering
why our install of (as far as possible) vanilla upstream gcc does not contain
that configuration, is this something a distribution is supposed to hack in?


-- 
   Summary: gfortran does not recognize .f95 files
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thomas dot orgis at awi dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/40585] New: [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting EH tree

[rguenth at gcc dot gnu dot org]

From

  if (__p_91 != 0B)
goto ;
  else
goto ;
  # SUCC: 39 [100.0%]  count:931 (true,exec) 40 (false,exec)

  # BLOCK 39 freq:4175 count:931
  # PRED: 38 [100.0%]  count:931 (true,exec)
  operator delete (__p_91);
  # SUCC: 40 [100.0%]  count:931 (fallthru,exec)

  # BLOCK 40 freq:4188 count:934
  # PRED: 38 (false,exec) 39 [100.0%]  count:931 (fallthru,exec)
  <<>> = save_eptr.427_34;
  <<>> = save_filt.428_33;
  resx 3;
  # SUCC:

it generates

  if (__p_91 != 0B)
goto ;
  else
goto ;
  # SUCC: 39 [100.0%]  count:931 (true,exec) 40 (false,exec)

  # BLOCK 39 freq:4175 count:931
  # PRED: 38 [100.0%]  count:931 (true,exec)
  operator delete (__p_91);
  # SUCC: 48 [100.0%]  count:931 (fallthru,exec)

  # BLOCK 48 freq:4175 count:931
  # PRED: 39 [100.0%]  count:931 (fallthru,exec)
  <<>> = save_eptr.427_34;
  <<>> = save_filt.428_33;
  resx 3;
  # SUCC:

  # BLOCK 40 freq:13 count:3
  # PRED: 38 (false,exec)
  <<>> = save_eptr.427_34;
  <<>> = save_filt.428_33;
  resx 3;
  # SUCC:

duplicating the tail.  This causes us to ICE later like

Loop.cpp:75: internal compiler error: in expand_resx_expr, at except.c:573
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o
adjusting EH tree
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58

[ktietz at gcc dot gnu dot org]

--- Comment #1 from ktietz at gcc dot gnu dot org  2009-06-29 11:54 ---
Well, I see. A redefinition issue. Does the following patch fixes your issue?

Index: gcc/gcc/ada/adaint.h
===
--- gcc.orig/gcc/ada/adaint.h   2009-06-22 15:57:24.0 +0200
+++ gcc/gcc/ada/adaint.h2009-06-29 13:52:18.896879700 +0200
@@ -48,6 +48,12 @@
large files. For now we just list the platforms we have manually
tested.  */

+#undef FOPEN
+#undef STAT
+#undef FSTAT
+#undef LSTAT
+#undef STRUCT_STAT
+
 #if defined (__GLIBC__) || defined (sun)  || defined (__sgi)
 #define FOPEN fopen64
 #define STAT stat64


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/40579] [4.3/4.4/4.5 Regression] gcc -O2 optimization causes infinite loop and wrong output

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-06-29 11:57 ---
Subject: Bug 40579

Author: rguenth
Date: Mon Jun 29 11:57:15 2009
New Revision: 149046

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149046
Log:
2009-06-29  Richard Guenther  

PR tree-optimization/40579
* tree-vrp.c (vrp_evaluate_conditional): Bail out early if
the IL to simplify has constants that overflowed.

* gcc.c-torture/execute/pr40579.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr40579.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug tree-optimization/40585] [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting EH tree

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2009-06-29 12:00 ---
Ack. Honza, yours I would guess.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-29 12:00:44
   date||


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

[Bug tree-optimization/40585] [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting EH tree

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-06-29 12:02 ---
Richi, do you have a test case you can share?  I have seen this problem in code
I can't take public...


-- 


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

[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2009-06-29 12:04 
---
Reduced tescase (crashes with "-O"):

=
struct A
{
  void* q;
  int i;
};

union U
{
  char* p;
  struct A a;
};

struct A foo(union U u)
{
  struct A a = { 0, 0 };
  a = u.a;
  return a;
}
=


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/40585] [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting EH tree

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2009-06-29 12:08 ---
Subject: Re:  [4.3/4.4/4.5 Regression] tracer
 duplicates blocks w/o adjusting EH tree

On Mon, 29 Jun 2009, steven at gcc dot gnu dot org wrote:

> --- Comment #2 from steven at gcc dot gnu dot org  2009-06-29 12:02 
> ---
> Richi, do you have a test case you can share?  I have seen this problem in 
> code
> I can't take public...

Likewise me, only reproducible with -fprofile-use and .gcda/.gcno
files from a customer...

Richard.


-- 


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

[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-06-29 12:10 ---
Might be safer to rename to GNAT_FOPEN or something like that? FOPEN is likely
to be taken on more than one platform.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net,
   ||charlet at adacore dot com


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

[Bug middle-end/38212] restrict implementation causes wrong-code

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-06-29 12:20 ---
Subject: Bug 38212

Author: rguenth
Date: Mon Jun 29 12:20:39 2009
New Revision: 149047

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149047
Log:
2009-06-29  Richard Guenther  

PR middle-end/38212
* alias.c (find_base_decl): Remove.
(get_deref_alias_set_1): Remove restrict handling.
* c-common.c (c_apply_type_quals_to_decl): Do not set
DECL_POINTER_ALIAS_SET.
* gimplify.c (find_single_pointer_decl_1): Remove.
(find_single_pointer_decl): Likewise.
(internal_get_tmp_var): Remove restrict handling.
(gimple_regimplify_operands): Likewise.
* omp-low.c (expand_omp_atomic_pipeline): Do not set
DECL_POINTER_ALIAS_SET. Use ref-all pointers.
* print-tree.c (print_node): Do not print DECL_POINTER_ALIAS_SET.
* tree.c (restrict_base_for_decl): Remove.
(init_ttree): Do not allocate it.
(make_node_stat): Do not set DECL_POINTER_ALIAS_SET.  Set
LABEL_DECL_UID for label decls.
(copy_node_stat): Do not copy restrict information.
(decl_restrict_base_lookup): Remove.
(decl_restrict_base_insert): Likewise.
(print_restrict_base_statistics): Likewise.
(dump_tree_statistics): Do not call print_restrict_base_statistics.
* tree.h (DECL_POINTER_ALIAS_SET): Remove.
(DECL_POINTER_ALIAS_SET_KNOWN_P): Likewise.
(struct tree_decl_common): Rename pointer_alias_set to label_decl_uid.
(LABEL_DECL_UID): Adjust.
(DECL_BASED_ON_RESTRICT_P): Remove.
(DECL_GET_RESTRICT_BASE): Likewise.
(SET_DECL_RESTRICT_BASE): Likewise.
(struct tree_decl_with_vis): Remove based_on_restrict_p flag.

* config/i386/i386.c (ix86_gimplify_va_arg): Use ref-all pointers
instead of DECL_POINTER_ALIAS_SET.
* config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Likewise.
* config/s390/s390.c (s390_gimplify_va_arg): Likewise.
* config/spu/spu.c (spu_gimplify_va_arg_expr): Likewise.

* gcc.c-torture/execute/pr38212.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr38212.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/c-common.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/s390/s390.c
trunk/gcc/config/spu/spu.c
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/gcc/print-tree.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h


-- 


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

[Bug middle-end/14187] [tree-ssa] C restricted pointers are not properly implemented

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-06-29 12:23 
---
Subject: Bug 14187

Author: rguenth
Date: Mon Jun 29 12:23:21 2009
New Revision: 149048

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149048
Log:
2009-06-29  Richard Guenther  

PR middle-end/14187
* tree-ssa-alias.h (struct pt_solution): Add vars_contains_restrict
flag.
(pt_solutions_same_restrict_base): Declare.
* tree-ssa-structalias.c (struct variable_info): Add is_restrict_var
flag.
(new_var_info): Initialize is_global_var properly for SSA_NAMEs.
(make_constraint_from, make_copy_constraint): Move earlier.
(make_constraint_from_heapvar): New function.
(make_constraint_from_restrict): Likewise.
(handle_lhs_call): Use it.
(find_func_aliases): Use it to track conversions to restrict
qualified pointers.
(struct fieldoff): Add only_restrict_pointers flag.
(push_fields_onto_fieldstack): Initialize it.
(create_variable_info_for): Track global restrict qualified pointers.
(intra_create_variable_infos): Use make_constraint_from_heapvar.
Track restrict qualified pointer arguments.
(set_uids_in_ptset): Use varinfo is_global_var flag.
(find_what_var_points_to): Set the vars_contains_restrict flag.
Always create the points-to solution for sets including restrict tags.
(pt_solutions_same_restrict_base): New function.
* tree-ssa-alias.c (ptr_derefs_may_alias_p): For two restrict
qualified pointers use pt_solutions_same_restrict_base as
additional source for disambiguation.

* gcc.dg/tree-ssa/restrict-1.c: New testcase.
* gcc.dg/tree-ssa/restrict-2.c: Likewise.
* gcc.dg/tree-ssa/restrict-3.c: Likewise.
* gcc.c-torture/execute/20090623-1.c: Likewise.
* gcc.dg/tree-ssa/ldist-13.c: Likewise.
* gcc.dg/tree-ssa/ldist-14.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20090623-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-13.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-14.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/restrict-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-alias.h
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug middle-end/14187] [tree-ssa] C restricted pointers are not properly implemented

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2009-06-29 12:24 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/38212] restrict implementation causes wrong-code

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-06-29 12:25 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/40583] automatic preprocessing for .F90 or .F95 files fails with cc1 error (output filename specified twice)

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-06-29 12:27 ---
Hmm, the following works here on x86_64-openSUSE (the -4.x are the ones of
openSUSE; the last one is today's vanilla trunk build):

gcc-4.2 -c aa.F90; gcc-4.3 -c aa.F90; gcc-4.4 -c aa.F90; gcc -c aa.F90
gfortran-4.2 aa.F90; gfortran-4.3 aa.F90; gfortran-4.4 aa.F90; gfortran aa.F90

(ditto with .F95 instead of .F90)


> Anyhow: The automatic preprocessing as specified by the documentation, for
> files named with capital "F" in the suffix, does not work.

If you have a case-sensitive filesystem, it should work!


> It works fine using the two-step procedure:
> 
> shell$ cpp -xf95-cpp-input testf95.F95 > testf95.f95
> shell$ LANG=C gfortran -xf95 -o testf95 testf95.f95

It should also work using:

gfortran -xf95-cpp-input -o testf95 testf95.F95
 ^^^
where -xf95-cpp-input can be replaced by "-cpp" in GCC/gfortran 4.4.x/4.5.


-- 


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

[Bug c/40586] New: CROSS COMPILE Badness

[cfriedt at visible-assets dot com]

I'm using OpenEmbedded to cross-compile xf86-input-keyboard-1.2.2 for the
OpenMoko FreeRunner. 

It appears that the cross-compiler is inserting an invalid header location,
with -I/usr/include/xorg .

The exact error message is below.

I would imagine that "cc1: internal compiler error: in add_path, at
c-incpath.c:362" indicates an error with gcc.

Please see the attached config.log file for more details.

configure:11681: ccache arm-angstrom-linux-gnueabi-gcc -march=armv4t
-mtune=arm9
20t -mthumb-interwork -mno-thumb -c
-isystem/home/cfriedt/openmoko/fso-testing/t
mp/staging/armv4t-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations
-
frename-registers -fomit-frame-pointer -O2 -ggdb3
-isystem/home/cfriedt/openmoko
/fso-testing/tmp/staging/armv4t-angstrom-linux-gnueabi/usr/include conftest.c
>&
5
configure:11687: $? = 0
configure:11812: ccache arm-angstrom-linux-gnueabi-gcc -march=armv4t
-mtune=arm9
20t -mthumb-interwork -mno-thumb -c
-isystem/home/cfriedt/openmoko/fso-testing/t
mp/staging/armv4t-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations
-
frename-registers -fomit-frame-pointer -O2 -ggdb3 -I/usr/include/xorg
-isystem/h
ome/cfriedt/openmoko/fso-testing/tmp/staging/armv4t-angstrom-linux-gnueabi/usr/i
nclude conftest.c >&5
CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/xorg
cc1: internal compiler error: in add_path, at c-incpath.c:362
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: CROSS COMPILE Badness
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfriedt at visible-assets dot com
 GCC build triplet: i686-linux-gnu
  GCC host triplet: armv4t-linux-gnueabi
GCC target triplet: armv4t-linux-gnueabi


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

[Bug c/40586] CROSS COMPILE Badness

[cfriedt at visible-assets dot com]

--- Comment #1 from cfriedt at visible-assets dot com  2009-06-29 12:33 
---
Created an attachment (id=18090)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18090&action=view)
config.log


-- 


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

[Bug fortran/40584] gfortran does not recognize .f95 files

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-06-29 12:41 ---
> The automatism works fine for .f90 files, so I suppose it is supposed to
> work for .f95, too?
>
> I guess a fix is simple (making that file suffix known). I am rather wondering
> why our install of (as far as possible) vanilla upstream gcc does not contain
> that configuration, is this something a distribution is supposed to hack in?

In vanilla GCC 4.3 there is at: gcc/fortran/lang-specs.h:

{".F90", "@f95-cpp-input", 0, 0, 0},
{".F95", "@f95-cpp-input", 0, 0, 0},
{".F03", "@f95-cpp-input", 0, 0, 0},
{"@f95-cpp-input",
  "cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN %(cpp_options) \
  %{E|M|MM:%(cpp_debug_options)}\
  %{!M:%{!MM:%{!E: -o %|.f95 |\n\
f951 %|.f95 %{!ffixed-form:-ffree-form} %(cc1_options) %{J*} %{I*}\
  -fpreprocessed %{!nostdinc:-fintrinsic-modules-path finclude%s}
%{!fsyntax-only:%(invoke_as)", 0, 0, 0},
{".f90", "@f95", 0, 0, 0},
{".f95", "@f95", 0, 0, 0},
{".f03", "@f95", 0, 0, 0},
{"@f95", "%{!E:f951 %i %(cc1_options) %{J*} %{I*}\
 %{!nostdinc:-fintrinsic-modules-path finclude%s}
%{!fsyntax-only:%(invoke_as)}}", 0, 0, 0},


Thus .f90 and .f95 but also .F90 and .F95 are handled on equal footing. There
is no (obvious) reason why it works with .f90 but not with .f95.

Seemingly, there are some parsing problems with that file since the error
output looks like an excerpt from that file.


It is extremely unlikely that such a change would go unnoticed. The GCC test
suite contains .f90, .f03 and .f08 and .F90 files. (Admittedly, no .f95/.F95
file.) The testsuite is run on a large range of systems and before the
committal of any patch.

I would recommend to contact your Linux vendor about this problem.

 * * *

You could try one of the files at 
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/
(Maybe avoid the (trunk) builds of last one or two weeks - at least if you have
a GLIBC < 2.7 as seemingly those builds now require such a "new" glibc.)

 * * *

Note: .f90 essentially means free format, there is no real reason to use .f95,
.f03, .f08.  (Well, there is one legitimate case: To have a different -std=
option for, e.g., .f95 than for .f90, but that's really a special case.)


-- 


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

[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58

[ktietz at gcc dot gnu dot org]

--- Comment #3 from ktietz at gcc dot gnu dot org  2009-06-29 12:45 ---
Yeah, this would be the best way to solve this.


-- 


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

[Bug rtl-optimization/40587] New: ICE in emit_swap_insn at reg-stack.c:827

[pmblakely at googlemail dot com]

See attached test-case, test.f:

> gfortran -c test.f -O1
Compiles OK

> gfortran -c test.f -O2
test.f: In function "test":
test.f:13: internal compiler error: in emit_swap_insn, at reg-stack.c:827

> gfortran -v
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--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.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i586
--build=i586-redhat-linux
Thread model: posix
gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) 

> uname -a
Linux pmblakely 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun 16 23:19:53 EDT 2009
i686 i686 i386 GNU/Linux

This looks similar to the test-case for bug 39607 (fixed), in that the ICE
occurs when returned/class variables are only updated if a certain condition
holds, and otherwise a separate function is called, resulting in those
variables not being updated.

Note that the test-case for bug 39607 compiles correctly (i.e. no ICE) for this
version of gcc, so it's not a case of that patch not having gone through for
this compiler version.


-- 
   Summary: ICE in emit_swap_insn at reg-stack.c:827
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pmblakely at googlemail dot com


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

[Bug fortran/40583] automatic preprocessing for .F90 or .F95 files fails with cc1 error (output filename specified twice)

[thomas dot orgis at awi dot de]

--- Comment #2 from thomas dot orgis at awi dot de  2009-06-29 12:51 ---
Thanks for confirming that it _should_ work.
Now the question is: What is wrong with the installation on my system so that
it does not work?

I see that gfortran is apparently trying to preprocess the .F95 files, but that
cc1 call goes wrong.
Is this perhaps a problem with installing gcc, g++ and gfortran in separate
steps? I mean, the preprocessor itself does not have a problem with
f95-cpp-input ... so that does not seem so plausible.

This is essentially our gfortran install script -- is there something wrong
with that?

#!/bin/bash
sed -i -e "s/lib64/lib/" gcc/config/i386/linux64.h &&

if [[ $CROSS_INSTALL == on ]]; then
  OPTS="--host=$HOST $OPTS"
else
  OPTS="--build=$HOST $OPTS"
fi  &&

cd $SOURCE_DIRECTORY.bld   &&
$SOURCE_DIRECTORY/configure\
 --prefix=${INSTALL_ROOT}/usr  \
 --libdir=${INSTALL_ROOT}/usr/lib  \
 --infodir=${INSTALL_ROOT}/usr/share/info  \
 --mandir=${INSTALL_ROOT}/usr/share/man\
 --enable-threads=posix\
 --with-system-zlib\
 --enable-languages=f95\
 $GCC_MULTILIB \
 $OPTS &&

make CFLAGS="$CFLAGS" BOOT_CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" \
 profiledbootstrap-lean

# install part

cd  $SOURCE_DIRECTORY.bld  &&

make -C gcc lang.install-common lang.install-man  &&
install -c gcc/f951 ${INSTALL_ROOT}/usr/libexec/gcc/$HOST/$VERSION/  &&
sedit 's,lib64,lib,' $HOST/libgfortran/Makefile &&
make -C $HOST/libgfortran/ install  &&

# specs file stuff
local SPECSDIR=${INSTALL_ROOT}/usr/lib/gcc/$HOST/$VERSION  &&
mkdir -p $SPECSDIR/specs-local &&
cp $SCRIPT_DIRECTORY/specs_fortran $SPECSDIR/specs-local

rm_source_dir  $SOURCE_DIRECTORY.bld   &&
local SPECSDIR=${INSTALL_ROOT}/usr/lib/gcc/$HOST/$VERSION  &&
cat $SPECSDIR/specs-local/* > $SPECSDIR/specs

# end of script

The specs_fortran file, being incorporated into the common specs file looks
like that (I am wondering: Are we supposed to ship that file -- I did not write
the build script myself)?):

@f77-cpp-input:
cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN %(cpp_options)
%{E|M|MM:%(cpp_debug_options)} %{!M:%{!MM:%{!E: -o %|.f |\n f951 %|.f
%{!ffree-form:-ffixed-form} %(cc1_options) %{J*} %{I*} -fpreprocessed
%{!fsyntax-only:%(invoke_as)

@f95-cpp-input:
cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN %(cpp_options)
%{E|M|MM:%(cpp_debug_options)} %{!M:%{!MM:%{!E: -o %|.f95 |\n f951 %|.f95
%(cc1_options) %{J*} %{I*} -fpreprocessed %{!fsyntax-only:%(invoke_as)

@f77:
%{!E:f951 %i %{!ffree-form:-ffixed-form} %(cc1_options) %{J*} %{I*}
%{!fsyntax-only:%(invoke_as)}}

@f95:
%{!E:f951 %i %(cc1_options) %{J*} %{I*} %{!fsyntax-only:%(invoke_as)}}

.F:
@f77-cpp-input

.fpp:
@f77-cpp-input

.FPP:
@f77-cpp-input

.F90:
@f95-cpp-input

.F95:
@f95-cpp-input

.f:
@f77

.for:
@f77

.FOR:
@f77

.f90:
@f95

.f95:
@f95


-- 


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

[Bug rtl-optimization/40587] ICE in emit_swap_insn at reg-stack.c:827

[pmblakely at googlemail dot com]

--- Comment #1 from pmblakely at googlemail dot com  2009-06-29 12:51 
---
Created an attachment (id=18091)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18091&action=view)
Minimal test-case


-- 


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

[Bug fortran/40584] gfortran does not recognize .f95 files

[thomas dot orgis at awi dot de]

--- Comment #2 from thomas dot orgis at awi dot de  2009-06-29 12:54 ---
Well, then, I have to assume that the Source Mage gcc install screws up.
As to "contact the vendor": I change that to "fix that install process", as I
am sort of part of said GNU/Linux vendor, the Source Mage distribution;-)

If you have a hint from looking at the install script I posted to bug 40583 ...
I'd be thankful. Apart from that, I guess these two bugs really can be
closed... the problem may very well be on our side.


-- 


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

[Bug fortran/40588] New: Small bug in match_charkind_name

[philippe dot marguinaud at meteo dot fr]

Looking at the code, I think that the following lines from match_charkind_name
(primary.c:830):

  if (!ISALNUM (c)
  && c != '_'
  && (gfc_option.flag_dollar_ok && c != '$'))
break;

should be changed to:

  if (!ISALNUM (c)
  && c != '_'
  && !(gfc_option.flag_dollar_ok && c == '$'))
break;


-- 
   Summary: Small bug in match_charkind_name
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot marguinaud at meteo dot fr
 GCC build triplet: any
  GCC host triplet: any
GCC target triplet: any


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

[Bug fortran/40584] gfortran does not recognize .f95 files

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2009-06-29 14:25 ---
(In reply to comment #1)
> 
> It is extremely unlikely that such a change would go unnoticed. The GCC test
> suite contains .f90, .f03 and .f08 and .F90 files. (Admittedly, no .f95/.F95
> file.) The testsuite is run on a large range of systems and before the
> committal of any patch.
> 
REMOVE:kargl[207] ls ~/gcc/gcc4x/gcc/testsuite/gfortran.dg/*f95
/usr/home/kargl/gcc/gcc4x/gcc/testsuite/gfortran.dg/include_3.f95
REMOVE:kargl[208] ls ~/gcc/gcc4x/gcc/testsuite/gfortran.dg/*F95

Checking gfortran.log

Executing on host:
/usr/home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran
-B/usr/home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../
/usr/home/kargl/gcc/gcc4x/gcc/testsuite/gfortran.dg/include_3.f95   -O 
-fpreprocessed -g3 -S  -o include_3.s(timeout = 300)
PASS: gfortran.dg/include_3.f95  -O  (test for excess errors)


-- 


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

[Bug target/40587] ICE in emit_swap_insn at reg-stack.c:827

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-06-29 14:25 ---
Didn't GCC say report the bug to http://bugzilla.redhat.com/bugzilla ?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|rtl-optimization|target
 GCC target triplet||i586-redhat-linux


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

[Bug target/40587] ICE in emit_swap_insn at reg-stack.c:827

[pmblakely at googlemail dot com]

--- Comment #3 from pmblakely at googlemail dot com  2009-06-29 14:28 
---
(In reply to comment #2)
> Didn't GCC say report the bug to http://bugzilla.redhat.com/bugzilla ?
> 

Oh, yes. Sorry. I'll post it there.


-- 


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

[Bug target/40587] [4.4/4.5 Regression] ICE in emit_swap_insn at reg-stack.c:827

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-06-29 14:36 ---
The test also fails with FSF 4.4.1 and 4.5.0, but not with 4.3.4, which makes
for 4.4 regression.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.4.1 4.5.0
  Known to work||4.3.4
   Last reconfirmed|-00-00 00:00:00 |2009-06-29 14:36:37
   date||
Summary|ICE in emit_swap_insn at|[4.4/4.5 Regression] ICE in
   |reg-stack.c:827 |emit_swap_insn at reg-
   ||stack.c:827
   Target Milestone|--- |4.4.1


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

[Bug fortran/40583] automatic preprocessing for .F90 or .F95 files fails with cc1 error (output filename specified twice)

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2009-06-29 14:39 ---
(In reply to comment #2)
> 
> # install part
> 
> cd  $SOURCE_DIRECTORY.bld  &&
> 
> make -C gcc lang.install-common lang.install-man  &&
> install -c gcc/f951 ${INSTALL_ROOT}/usr/libexec/gcc/$HOST/$VERSION/  &&
> sedit 's,lib64,lib,' $HOST/libgfortran/Makefile &&
> make -C $HOST/libgfortran/ install  &&
> 

Your script doesn't install the driver program 'gfortran'.
You've only installed the f951 compiler program, and some
mangled spec file.  Your 'gfortran' driver program is 
probably some older, out-of-date, version.

Please see http://gcc.gnu.org/install/ for the proper
method of installing gcc.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/40584] gfortran does not recognize .f95 files

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-06-29 14:40 ---
See PR 40583 for a possible explanation.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/40585] [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting EH tree

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.4


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

[Bug tree-optimization/40579] [4.3/4.4/4.5 Regression] gcc -O2 optimization causes infinite loop and wrong output

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-06-29 14:48 ---
Subject: Bug 40579

Author: rguenth
Date: Mon Jun 29 14:48:15 2009
New Revision: 149051

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149051
Log:
2009-06-29  Richard Guenther  

PR tree-optimization/40579
* tree-vrp.c (vrp_evaluate_conditional): Bail out early if
the IL to simplify has constants that overflowed.

* gcc.c-torture/execute/pr40579.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr40579.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-vrp.c


-- 


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

[Bug tree-optimization/40579] [4.3/4.4/4.5 Regression] gcc -O2 optimization causes infinite loop and wrong output

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-06-29 14:52 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.2.4   |4.2.4 4.3.4 4.4.1 4.5.0
 Resolution||FIXED


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

[Bug tree-optimization/40579] [4.3/4.4/4.5 Regression] gcc -O2 optimization causes infinite loop and wrong output

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-06-29 14:52 ---
Subject: Bug 40579

Author: rguenth
Date: Mon Jun 29 14:52:20 2009
New Revision: 149052

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149052
Log:
2009-06-29  Richard Guenther  

PR tree-optimization/40579
* tree-vrp.c (vrp_evaluate_conditional_warnv): Bail out early if
the IL to simplify has constants that overflowed.

* gcc.c-torture/execute/pr40579.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr40579.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-vrp.c


-- 


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

[Bug middle-end/40589] New: efficiency problem with V2HI add

[Tom dot de dot Vries at Nxp dot com]

I am working on a port for the TriMedia processor family, and I was playing
around with the following example (extracted from
gcc.c-torture/execute/simd-2.c) to see how well our port takes advantage of the
addv2hi3 operator of our tm3271 processor.

test.c:
...
typedef short __attribute__((vector_size (N))) vecint;
vecint i, j, k;
void f () {  k = i + j; }
...

test.c.016veclower, N=4. This looks good, the addv2hi3 has been used once.
...
  vector short int k.2;
  vector short int j.1;
  vector short int i.0;
  i.0 = i;
  j.1 = j;
  k.2 = i.0 + j.1;
  k = k.2;
}
...

test.c.016veclower, N=32. This also looks good, the addv2hi3 has been used 8x.
...
  vector short unsigned int D.1445;
  vector short unsigned int D.1444;
  vector short unsigned int D.1443;
  vector short unsigned int D.1442;
  vector short unsigned int D.1441;
  vector short unsigned int D.1440;
  vector short unsigned int D.1439;
  vector short unsigned int D.1438;
  vector short unsigned int D.1437;
  vector short unsigned int D.1436;
  vector short unsigned int D.1435;
  vector short unsigned int D.1434;
  vector short unsigned int D.1433;
  vector short unsigned int D.1432;
  vector short unsigned int D.1431;
  vector short unsigned int D.1430;
  vector short unsigned int D.1429;
  vector short unsigned int D.1428;
  vector short unsigned int D.1427;
  vector short unsigned int D.1426;
  vector short unsigned int D.1425;
  vector short unsigned int D.1424;
  vector short unsigned int D.1423;
  vector short unsigned int D.1422;
  vector short int k.2;
  vector short int j.1;
  vector short int i.0;
  i.0 = i;
  j.1 = j;
  D.1422 = BIT_FIELD_REF ;
  D.1423 = BIT_FIELD_REF ;
  D.1424 = D.1422 + D.1423;
  D.1425 = BIT_FIELD_REF ;
  D.1426 = BIT_FIELD_REF ;
  D.1427 = D.1425 + D.1426;
  D.1428 = BIT_FIELD_REF ;
  D.1429 = BIT_FIELD_REF ;
  D.1430 = D.1428 + D.1429;
  D.1431 = BIT_FIELD_REF ;
  D.1432 = BIT_FIELD_REF ;
  D.1433 = D.1431 + D.1432;
  D.1434 = BIT_FIELD_REF ;
  D.1435 = BIT_FIELD_REF ;
  D.1436 = D.1434 + D.1435;
  D.1437 = BIT_FIELD_REF ;
  D.1438 = BIT_FIELD_REF ;
  D.1439 = D.1437 + D.1438;
  D.1440 = BIT_FIELD_REF ;
  D.1441 = BIT_FIELD_REF ;
  D.1442 = D.1440 + D.1441;
  D.1443 = BIT_FIELD_REF ;
  D.1444 = BIT_FIELD_REF ;
  D.1445 = D.1443 + D.1444;
  k.2 = {D.1424, D.1427, D.1430, D.1433, D.1436, D.1439, D.1442, D.1445};
  k = k.2;
...

test.c.016veclower, N=8. This does not look good. The addv2hi3 has not been
used. The addsi3 has been used 4 times, while the addv2hi3 could have been used
only 2 times.
...
  short int D.1431;
  short int D.1430;
  short int D.1429;
  short int D.1428;
  short int D.1427;
  short int D.1426;
  short int D.1425;
  short int D.1424;
  short int D.1423;
  short int D.1422;
  short int D.1421;
  short int D.1420;
  vector short int k.2;
  vector short int j.1;
  vector short int i.0;
  i.0 = i;
  j.1 = j;
  D.1420 = BIT_FIELD_REF ;
  D.1421 = BIT_FIELD_REF ;
  D.1422 = D.1420 + D.1421;
  D.1423 = BIT_FIELD_REF ;
  D.1424 = BIT_FIELD_REF ;
  D.1425 = D.1423 + D.1424;
  D.1426 = BIT_FIELD_REF ;
  D.1427 = BIT_FIELD_REF ;
  D.1428 = D.1426 + D.1427;
  D.1429 = BIT_FIELD_REF ;
  D.1430 = BIT_FIELD_REF ;
  D.1431 = D.1429 + D.1430;
  k.2 = {D.1422, D.1425, D.1428, D.1431};
  k = k.2;
...

This grep illustrates that the problem only occurs for N=8/16:
...
$ for N in 4 8 16 32 64; do \
  rm -f *.c.* ; \
  cc1 test.c -quiet -march=tm3271 -O2 -DN=${N} \
  -fdump-rtl-all -fdump-tree-all \
  && grep -c '+' test.c.016t.veclower ; \
done
1
4
8
8
16
...

So why does the problem occur? Lets look at the TYPE_MODE (type) in
expand_vector_operations_1() for different values of N:
...
N=4  V2HI
N=8  DImode
N=16 TImode
N=32 BLKmode
N=64 BLKmode
...

For the DImode and TImode, we don't generate efficient code, due to the test on
BLKmode:
...
  /* For very wide vectors, try using a smaller vector mode.  */
  compute_type = type;
  if (TYPE_MODE (type) == BLKmode && op)
...
in expand_vector_operations_1(). For my target, which has a native addv2hi3
operator, also DImode/TImode can be considered a 'wide vector'.

Using this patch, I also generate addv2hi3 for N=8/N=16: 
...
Index: tree-vect-generic.c
===
--- tree-vect-generic.c (revision 14)
+++ tree-vect-generic.c (working copy)
@@ -462,7 +462,7 @@

   /* For very wide vectors, try using a smaller vector mode.  */
   compute_type = type;
-  if (TYPE_MODE (type) == BLKmode && op)
+  if (op)
 {
   tree vector_compute_type
 = type_for_widest_vector_mode (TYPE_MODE (TREE_TYPE (type)), op,
...


Furthermore, I think this patch (in the style of
expmed.c:extract_bit_field_1()) could be useful:
...
Index: tree-vect-generic.c
===
--- tree-vect-generic.c (revision 14)
+++ tree-vect-generic.c (working copy)
@@ -35,6 +35,7 @@
 #include "tree-pass.h"
 #include "flags.h"
 #include "ggc.h"
+#include "target.h"


 /* Build a constant of 

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

[dave dot korn dot cygwin at gmail dot com]

--- Comment #20 from dave dot korn dot cygwin at gmail dot com  2009-06-29 
15:12 ---
I think the best solution to this problem is to enable libstdc++ as a DLL, and
export _S_empty_rep from it.  Then every C++ DLL and EXE will link against
libstdc++ and they'll all import the exact same instance.  Problem solved *and*
we get to keep the optimisation.  The more difficult problem of windows
shared-libraries not allowing undefined references (and how this interacts with
RTTI and COMDATs in particular) is a larger issue which will need to be tackled
separately.

I'm about to test a patch based on this approach.


-- 


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

[Bug fortran/40588] Small bug in match_charkind_name

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-06-29 15:17 ---
I agree that
  && (gfc_option.flag_dollar_ok && c != '$'))
is wrong and is should either be
  && !(gfc_option.flag_dollar_ok && c == '$'))
^^^   ^^
or equivalently
  && (!gfc_option.flag_dollar_ok || c != '$'))
 ^^^ ^^

The current version accepts with -fno-dollar-ok all characters '$', '@" etc.
while for -fdollar-ok only '$' is allowed. However, those lines are in
match_charkind_name. As the   variable_"string"  is parsed before (in
gfc_match_name), the invalid character is noted before correctly.

Thus
  if (!ISALNUM (c) && c != '_' && c != '$')
is equivalent, taking the previous gfc_match_name into account.


-- 


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

[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2009-06-29 15:18 ---
Created an attachment (id=18092)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18092&action=view)
Provisional fix for the PR

This is not yet regtested but will be in an hour or two.

I must also run through the references to gfc_full_array_ref_p to see if any of
them could use the 'contiguous' output.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug middle-end/40589] efficiency problem with V2HI add

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-29 15:40 ---
Good observations.  Patches should be sent to gcc-patc...@gcc.gnu.org together
with a changelog entry following existing practice and a note how you tested
the patch.  See gcc.gnu.org/contribute.html.


-- 


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

[Bug java/40590] New: namespace namespace broken in CNI

[aph at gcc dot gnu dot org]

gcj does not mangle names correctly.

In particular, when a member name is a C++ keyword, "$" is appended to the
name.  However, this is results in an illegal mangled name so it is not
possible to refer to the member from CNI code.

Also, the set of C++ keywords in gjavah is different from the set in gcj.

Also, types are not checked for C++ keywords, so javax.xml.namespace.* cannot
be referenced from CNI code.


-- 
   Summary: namespace namespace broken in CNI
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: aph at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org


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

[Bug java/40590] namespace namespace broken in CNI

[aph at gcc dot gnu dot org]

--- Comment #1 from aph at gcc dot gnu dot org  2009-06-29 16:12 ---
See the thread at http://gcc.gnu.org/ml/java/2009-06/msg00066.html


-- 


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

[Bug c/40586] CROSS COMPILE Badness

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-06-29 16:14 ---
Try with a newer version of the compiler. The cross compiler shouldn't be
inserting a -I/usr/include/xorg . It must be a function of your environment.

Also we no longer support 4.1.2. Try using a more recent version of the
compiler.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/40587] [4.4/4.5 Regression] ICE in emit_swap_insn at reg-stack.c:827

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-06-29 16:18 ---
Revision 139590 (IRA):

http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html

is very likely the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com, vmakarov at redhat dot
   ||com


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

[Bug fortran/40580] Add -fcheck=pointer with runtime check for using an unallocated argument

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-06-29 16:23 ---
Mine. I have a patch.

PR 29616 is related, but goes beyond by checking also assignments to pointers
and undefined pointers (not only for unassociated pointers). (For -std=f95 one
can also check assignments to allocatables, for f2003 one reallocates on
assignment.) For RHS expressions, one could also add checks. The question is at
some point whether all the checks become too slow and whether one then needs an
pointer_expensive option or similarly.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||29616
  nThis||
 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-29 16:23:21
   date||


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

[Bug java/40590] namespace namespace broken in CNI

[aph at gcc dot gnu dot org]

--- Comment #2 from aph at gcc dot gnu dot org  2009-06-29 16:26 ---
Created an attachment (id=18093)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18093&action=view)
Test case


-- 


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

[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2009-06-29 16:45 ---
Subject: Bug 40443

Author: pault
Date: Mon Jun 29 16:44:49 2009
New Revision: 149056

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149056
Log:
2009-06-29  Paul Thomas  

PR fortran/40443
* interface.c (gfc_search_interface): Hold back a match to an
elementary procedure until all other possibilities are
exhausted.

2009-06-29  Paul Thomas  

PR fortran/40443
* gfortran.dg/generic_18.f90: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/generic_18.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/interface.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2009-06-29 16:46 ---
Fixed on trunk and 4.4

Thanks for the report

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/40587] [4.4/4.5 Regression] Revision 139590 caused ICE in emit_swap_insn at reg-stack.c:827

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-06-29 16:57 ---
Revision 139590 is the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.4/4.5 Regression] ICE in |[4.4/4.5 Regression]
   |emit_swap_insn at reg-  |Revision 139590 caused ICE
   |stack.c:827 |in emit_swap_insn at reg-
   ||stack.c:827


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

[Bug fortran/40591] New: Procedure(interface): Rejected if interface is indirectly hostassociated

[burnus at gcc dot gnu dot org]

The following program fails with:

procedure(sub), pointer :: pptr2
1
Error: Interface 'sub' of procedure 'pptr2' at (1) must be explicit


The question is whether it is valid or not. As both NAG f95 and ifort reject it
(g95 accepts it), it might be invalid.


However, if one uncomments pptr1: gfortran, NAG f95 and g95 accept pptr1 and
pptr2 -- while ifort continues to reject pptr2 only. Thus it might be valid at
the end.


program main
!  procedure(sub), pointer :: pptr1
!  nullify (pptr1)
contains
  subroutine test()
procedure(sub), pointer :: pptr2
nullify (pptr2)
  end subroutine test
  subroutine sub()
  end subroutine sub
end program main


-- 
   Summary: Procedure(interface): Rejected if interface is
indirectly hostassociated
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c/40592] New: Toolchain build error

[amengonu12 at gmail dot com]

I have been trying to build blackfin toolchain.
The command line that trigger the bug is:
$ ~/blackfin-sources/toolchain/buildscript/BuildToolChain -b
~/blackfin-sources/build -k
~/blackfin-sources/uClinux-dist-2008R1.5-RC3/linux-2.6.x -s
~/blackfin-sources/toolchain -u ~/blackfin-sources/u-boot-1.1.6-2008R1.5

and the error message is shown below

Please report an error to http://blackfin.uclinux.org/gf/project/toolchain
 Build error Fri Jun 26 18:40:56 CDT 2009
  occurred 30m21s into script
tar: Removing leading `/' from member names
Since the build was done in parallel, I'm not sure where the error
happened.

Thank you guys
Yawo


-- 
   Summary: Toolchain build error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amengonu12 at gmail dot com
 GCC build triplet: toolchain
  GCC host triplet: linux-2.6
GCC target triplet: bf537-EZLite


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

[Bug tree-optimization/40582] [4.5 Regression] ice for non-trivial conversion at assignment with -O2

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2009-06-29 17:11 ---
Created an attachment (id=18094)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18094&action=view)
Fix

It turns  out that build_ref_for_offset apparently needs  to check for
full type compatibility and  node just for useless_conversions.  It is
used  more generally but  also in  much stricter  same-type conditions
than I have originally intended to.

I will test this fix (alongside with another one) overnight and submit
it tomorrow if everything goes fine.


-- 


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

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

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2009-06-29 17:13 ---
Subject: Bug 39902

Author: janis
Date: Mon Jun 29 17:13:33 2009
New Revision: 149058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149058
Log:
PR c/39902
* tree.c (real_zerop, real_onep, real_twop, real_minus_onep):
Special-case decimal float constants.

PR c/39902
* gcc.dg/dfp/pr39902.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/dfp/pr39902.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree.c


-- 


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

[Bug bootstrap/40592] Toolchain build error

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
  Component|c   |bootstrap


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

[Bug bootstrap/40592] Toolchain build error

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-06-29 17:20 ---
> Please report an error to http://blackfin.uclinux.org/gf/project/toolchain

Did you read that part of the message?


-- 

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

[Bug fortran/40593] New: Proc-pointer returning function as actual argument

[burnus at gcc dot gnu dot org]

Here, the proc-pointer result is passed as actual argument to a procedure which
does not want to have the pointer but the pointer target.

There are two problems: The first program shows wrong code:
  sub (void (*) (integer(kind=4) &) f)
but passed is:
void (*) (integer(kind=4) &) D.1559;
D.1559 = getptr ();
sub (&D.1559);
Result: A segmentation fault.

The second program shows that the argument conformance checking goes wrong:
  call sub(getPtr())
   1
Error: Type mismatch in argument 'f' at (1); passed UNKNOWN to INTEGER(4)


Problem found when writing a test case for PR 40580. Please add also an
-fcheck=pointer test (assuming that PR 40580 gets checked in earlier) - I have
a test there, but it needs to be enabled


! ONE ---
module m
contains
  subroutine func(a)
integer :: a
a = 42
  end subroutine func
end module m

program test
  use m
  implicit none
  call sub(getPtr())
contains
  subroutine sub(f)
procedure(func) :: f
integer :: a
call f(a)
if (a /= 42)  call abort()
print *, a
  end subroutine sub
  function getPtr()
procedure(func), pointer :: getPtr
getPtr => func
  end function getPtr
end program test


! TWO ---
module m
contains
  function func()
integer :: func
func = 42
  end function func
end module m

program test
  use m
  implicit none
  procedure(integer), pointer :: ptr
  call sub(getPtr())
contains
  subroutine sub(f)
procedure(integer) :: f
if (f() /= 42)  call abort()
print *, f()
  end subroutine sub
  function getPtr()
procedure(func), pointer :: getPtr
getPtr => func
  end function getPtr
end program test


-- 
   Summary: Proc-pointer returning function as actual argument
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/40593] Proc-pointer returning function as actual argument

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-06-29 17:40 ---
Hmm, something else goes wrong, too, my fix for PR 40580 does not generate a
check (for procpointer results), it does for pointer function results and it
does for normal proc pointers. Thus, it either gets fixed automatically with
this bug, or one needs to spend some time on finding out why it does not work.


-- 


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

[Bug bootstrap/40511] Bootstrap Failure in stage3: c++locale - Recent SVN

[mckelvey at maskull dot com]

--- Comment #10 from mckelvey at maskull dot com  2009-06-29 17:46 ---
(In reply to comment #9)
> Ok, then for now let's close it as WONTFIX...
> 

Problem. With --enable-clocale=generic even the most basic locale support has
vanished.

try
{
us_locale = std::locale("en_US");
}
catch (const std::exception& e)
{
std::cout << "Unable to get en_US locale: "
  << e.what()
  << std::endl;
return 0;
}

Prints: Unable to get en_US locale: locale::facet::_S_create_c_locale name not
valid


-- 


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

[Bug java/40590] namespace namespace broken in CNI

[aph at gcc dot gnu dot org]

--- Comment #3 from aph at gcc dot gnu dot org  2009-06-29 17:51 ---
Subject: Bug 40590

Author: aph
Date: Mon Jun 29 17:50:59 2009
New Revision: 149059

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149059
Log:
2009-06-29  Andrew Haley  

PR java/40590   
* tools/gnu/classpath/tools/javah/FieldHelper.java (print):
Use printName().
* tools/gnu/classpath/tools/javah/MethodHelper.java (print):
Use printName().
* tools/gnu/classpath/tools/javah/CniStubPrinter.java (printDecl):
Use printName().
* tools/gnu/classpath/tools/javah/Keywords.java (words): Replace
with keywords list from  gcc/java/mangle.c.
* tools/gnu/classpath/tools/javah/ClassWrapper.java (printMethods):
Don't pre-convert a C++ keyword.
(print(CniPrintStream)): Call CniPrintStream.printName().
(printContents): Likewise.
* tools/gnu/classpath/tools/javah/CniPrintStream.java
(getClassName): Don't call replaceAll("/", "::").
(print(Type)): Add ""::" befor name, " *" after.  Use printName(), not
print.
(printName(PrintStream, String), printName(String), printlnName):
New methods.
(moveToPackage): Use printName().

2009-06-29  Andrew Haley  

PR java/40590
* java-tree.h (cxx_keyword_p): New declaration.
* mangle_name.c (utf8_cmp): Move here from mangle.c.
(cxx_keywords): Likewise.
(cxx_keyword_p): Likewise.
(MANGLE_CXX_KEYWORDS): New macro.
(append_gpp_mangled_name): Use MANGLE_CXX_KEYWORDS.
(append_gpp_mangled_name): Likewise.
* mangle.c: Move code to mangle_name.c.
(mangle_member_name): Don't call cxx_keyword_p.


Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/java-tree.h
trunk/gcc/java/mangle.c
trunk/gcc/java/mangle_name.c
trunk/libjava/classpath/ChangeLog
   
trunk/libjava/classpath/tools/classes/gnu/classpath/tools/javah/ClassWrapper.class
   
trunk/libjava/classpath/tools/classes/gnu/classpath/tools/javah/CniPrintStream.class
   
trunk/libjava/classpath/tools/classes/gnu/classpath/tools/javah/CniStubPrinter.class
   
trunk/libjava/classpath/tools/classes/gnu/classpath/tools/javah/FieldHelper.class
   
trunk/libjava/classpath/tools/classes/gnu/classpath/tools/javah/Keywords.class
   
trunk/libjava/classpath/tools/classes/gnu/classpath/tools/javah/MethodHelper.class
trunk/libjava/classpath/tools/gnu/classpath/tools/javah/ClassWrapper.java
trunk/libjava/classpath/tools/gnu/classpath/tools/javah/CniPrintStream.java
trunk/libjava/classpath/tools/gnu/classpath/tools/javah/CniStubPrinter.java
trunk/libjava/classpath/tools/gnu/classpath/tools/javah/FieldHelper.java
trunk/libjava/classpath/tools/gnu/classpath/tools/javah/Keywords.java
trunk/libjava/classpath/tools/gnu/classpath/tools/javah/MethodHelper.java
trunk/libjava/gnu/xml/stream/AttributeImpl.h
trunk/libjava/gnu/xml/stream/EndElementImpl.h
trunk/libjava/gnu/xml/stream/StartElementImpl.h
trunk/libjava/gnu/xml/stream/XIncludeFilter.h
trunk/libjava/gnu/xml/stream/XMLEventFactoryImpl.h
trunk/libjava/gnu/xml/stream/XMLEventImpl.h
trunk/libjava/gnu/xml/stream/XMLEventWriterImpl.h
trunk/libjava/gnu/xml/stream/XMLParser.h
trunk/libjava/gnu/xml/stream/XMLStreamWriterImpl.h
trunk/libjava/gnu/xml/transform/AbstractNumberNode.h
trunk/libjava/gnu/xml/transform/ApplyImportsNode.h
trunk/libjava/gnu/xml/transform/ApplyTemplatesNode.h
trunk/libjava/gnu/xml/transform/AttributeNode.h
trunk/libjava/gnu/xml/transform/Bindings.h
trunk/libjava/gnu/xml/transform/CallTemplateNode.h
trunk/libjava/gnu/xml/transform/ChooseNode.h
trunk/libjava/gnu/xml/transform/CommentNode.h
trunk/libjava/gnu/xml/transform/CopyNode.h
trunk/libjava/gnu/xml/transform/CopyOfNode.h
trunk/libjava/gnu/xml/transform/CurrentFunction.h
trunk/libjava/gnu/xml/transform/DocumentFunction.h
trunk/libjava/gnu/xml/transform/ElementAvailableFunction.h
trunk/libjava/gnu/xml/transform/ElementNode.h
trunk/libjava/gnu/xml/transform/ForEachNode.h
trunk/libjava/gnu/xml/transform/FormatNumberFunction.h
trunk/libjava/gnu/xml/transform/FunctionAvailableFunction.h
trunk/libjava/gnu/xml/transform/GenerateIdFunction.h
trunk/libjava/gnu/xml/transform/IfNode.h
trunk/libjava/gnu/xml/transform/Key.h
trunk/libjava/gnu/xml/transform/KeyFunction.h
trunk/libjava/gnu/xml/transform/LiteralNode.h
trunk/libjava/gnu/xml/transform/MessageNode.h
trunk/libjava/gnu/xml/transform/OtherwiseNode.h
trunk/libjava/gnu/xml/transform/ParameterNode.h
trunk/libjava/gnu/xml/transform/ProcessingInstructionNode.h
trunk/libjava/gnu/xml/transform/SortKey.h
trunk/libjava/gnu/xml/transform/Stylesheet.h
trunk/libjava/gnu/xml/transform/SystemPropertyFunction.h
trunk/libjava/gnu/xml/transform/Template.h
trunk/libjava/gnu/xml/transform/TemplateNode.h
 

[Bug fortran/40594] New: [4.5 Regression] wrong-code

[dfranke at gcc dot gnu dot org]

The code I'm going to attach shows strange results with trunk, but works as
expected with 4.4. 

In short, within a TYPE, a LOGICAL component is initialized to .FALSE.
(dummy_atom_init). The calling procedure (dummy_atom_model_init) that checks
the same LOGICAL component sees it as .TRUE. immediately afterwards:

 dummy_atom_init F
 dummy_atom_model_init T
 dummy_atom_init F
 dummy_atom_model_init T

Obviously, the component should be .FALSE. in the calling procedure as well.
The application this was extracted from fails with this kind of error since
r147206.

It is interesting to note that valgrind does not report any issues?!


-- 
   Summary: [4.5 Regression] wrong-code
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org


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

[Bug bootstrap/40511] Bootstrap Failure in stage3: c++locale - Recent SVN

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2009-06-29 17:55 
---
Of course, that's expected. Really, it's time to update your glibc.


-- 


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

[Bug fortran/40594] [4.5 Regression] wrong-code

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-06-29 17:57 ---
Created an attachment (id=18095)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18095&action=view)
Smallish testcase.

The testcase. Probably not minimal yet, but as close as I can get it now.

Compiled as:
$> rm -f *.mod a.out; gfortran-svn -g -fimplicit-none pr40594.f90 && ./a.out

Fails with:
gcc version 4.5.0 20090628 (experimental) (GCC)

Works with:
gcc version 4.4.1 20090531 (prerelease) (GCC)


-- 


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

[Bug rtl-optimization/40519] ICE with -O2 -ftracer __builtin_unreachable()

[daney at gcc dot gnu dot org]

--- Comment #1 from daney at gcc dot gnu dot org  2009-06-29 18:36 ---
Do either of these patches fix the problem?

http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01267.html
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01978.html


-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||daney at gcc dot gnu dot org
  Component|tree-optimization   |rtl-optimization


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

[Bug c++/40595] New: ICE trying to use sfinae with variadic template pack expansion

[jwakely dot gcc at gmail dot com]

template
struct S
{
typedef int type;
};

template
struct Get
{
static T get();
};

#ifdef BUG
# define ELLIPSIS ...
#else
# define ELLIPSIS
#endif

template
struct B
{
template
typename S::get() (Get::get() ELLIPSIS) )>::type
f(Args&& ELLIPSIS a);
};

struct X
{
bool operator()(int) const;
};

int main()
{
B b;
b.f(1);
} 

jwak...@gcc16:~/src/tests$ g++ -std=c++0x  -c pr.cc 
jwak...@gcc16:~/src/tests$ g++ -std=c++0x  -c pr.cc  -DBUG
pr.cc: In instantiation of ‘B’:
pr.cc:35:10:   instantiated from here
pr.cc:25:9: internal compiler error: in tsubst, at cp/pt.c:9733
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The code compiles fine with a single template parameter, but not with a
parameter pack of size one.

I'm trying to use SFINAE to disable overloads when a function call expression
is invalid, which is needed to implement std::bind for C++0x


-- 
   Summary: ICE trying to use sfinae with variadic template pack
expansion
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com


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

[Bug target/37488] register allocation spills floats needlessly

[vmakarov at redhat dot com]

--- Comment #7 from vmakarov at redhat dot com  2009-06-29 19:44 ---
Paolo, Steven, thanks for looking into this problem.  Using the mips approach
is a good idea.  Although the costs of FLOAT_REGS and SSE_REGS are the same in
ira-costs.c, IRA should prefer SSE_REGS or FLOAT_REGS depending on -fpmath=
option.

The implementation will take some time because choosing a cover class depends
not only on order of them in IRA_COVER_CLASSES macro but also on order of them
in enum reg_class.  I hope I'll have a patch on this week.



-- 


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

[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables

[ppluzhnikov at google dot com]

--- Comment #14 from ppluzhnikov at google dot com  2009-06-29 20:11 ---
I verified that @146817 is not causing the current 32-bit breakage; I'll open a
separate PR.


-- 


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

[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy

[pault at gcc dot gnu dot org]

--- Comment #9 from pault at gcc dot gnu dot org  2009-06-29 20:39 ---
Subject: Bug 40551

Author: pault
Date: Mon Jun 29 20:38:59 2009
New Revision: 149062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149062
Log:
2009-06-29  Paul Thomas  

PR fortran/40551
* dependency.h : Add second bool* argument to prototype of
gfc_full_array_ref_p.
* dependency.c (gfc_full_array_ref_p): If second argument is
present, return true if last dimension of reference is an
element or has unity stride.
* trans-array.c : Add NULL second argument to references to
gfc_full_array_ref_p.
* trans-expr.c : The same, except for;
(gfc_trans_arrayfunc_assign): Return fail if lhs reference
is not a full array or a contiguous section.

2009-06-29  Paul Thomas  

PR fortran/40551
* gfortran.dg/func_assign_2.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/func_assign_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/dependency.h
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/29616] Run-time check using nullified pointers and deallocated variables

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-06-29 21:00 ---
PR 40580 added an argument checking for pointer/proc-pointer/allocatable, i.e.
the example "call foo(r)" of comment 0 is now detected via -fcheck=pointer.

TODO:

a) call sub( uninit_alloc_returning_function() )
does not work as the _gfortran_internal_pack comes too early, see comment in
gfortran.dg/pointer_check_5.f90

b) Assignments are not checked, e.g.
   r = 5.0   (see comment 0)

c) One can add checks for uninitialized pointers - by automatically
initializing them to a special value - and checking for that value.

d) There are still issues with proc-pointer returning functions; tracked at PR
40593


-- 


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

[Bug fortran/40593] Proc-pointer returning function as actual argument

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-06-29 21:00 ---
-fcheck=pointer (remaining issues/features) is now tracked at PR 40593


-- 


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

[Bug debug/40596] New: [4.5 regression] Bad debug info for local variables on i386.

[ppluzhnikov at google dot com]

The test case from bug 40012 still fails in current mainline @149059 in 32-bit
mode:

--- cut ---
struct list_s {
  struct list_s* next;
};

typedef struct list_s list;

void f1(void*, list*);
int
f0(void* a,
   void* b,
   void* c,
   list* d)
{
list* problem;
for(problem = d; problem; problem = problem->next) {
  int variable = 0;
  f1(c, problem);
}
return (0);
}

int main()
{
  list a3 = { 0 };
  f0(0, 0, 0, &a3);
  return 0;
}

void f1(void*a, list*b) { }
--- cut ---

gcc-svn-install-149059/bin/gcc -g gcc-pr40012-test.c -m32

gdb -q a.out
(gdb) b main
Breakpoint 1 at 0x80483d9: file gcc-pr40012-test.c, line 24.
(gdb) r

Breakpoint 1, main () at gcc-pr40012-test.c:24
24list a3 = { 0 };
(gdb) n
25f0(0, 0, 0, &a3);
(gdb) p &a3
$1 = (list *) 0xccb4
(gdb) s
f0 (a=0x0, b=0x0, c=0x0, d=0xcc8c) at gcc-pr40012-test.c:15
15  for(problem = d; problem; problem = problem->next) {

Note mismatch between where GDB thinks &a3 is and the actual address.
[AFAICT, this is currently causing 300+ failures in the GDB test suite.]


-- 
   Summary: [4.5 regression] Bad debug info for local variables on
i386.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/40580] Add -fcheck=pointer with runtime check for using an unallocated argument

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-06-29 21:02 ---
Subject: Bug 40580

Author: burnus
Date: Mon Jun 29 21:02:17 2009
New Revision: 149063

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149063
Log:
2009-06-29  Tobias Burnus  

PR fortran/40580
* trans-expr.c  (gfc_conv_procedure_call): Add -fcheck=pointer
* check.
* libgfortran.h: Add GFC_RTCHECK_POINTER.
* invoke.texi (-fcheck): Document new pointer option.
* options.c (gfc_handle_runtime_check_option): Handle pointer
* option.

* gfortran.texi (C Binding): Improve wording.
* iso-c-binding.def: Remove obsolete comment.


2009-06-29  Tobias Burnus  

PR fortran/40580
* pointer_check_1.f90: New test.
* pointer_check_2.f90: New test.
* pointer_check_3.f90: New test.
* pointer_check_4.f90: New test.
* pointer_check_5.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pointer_check_1.f90
trunk/gcc/testsuite/gfortran.dg/pointer_check_2.f90
trunk/gcc/testsuite/gfortran.dg/pointer_check_3.f90
trunk/gcc/testsuite/gfortran.dg/pointer_check_4.f90
trunk/gcc/testsuite/gfortran.dg/pointer_check_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/iso-c-binding.def
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/options.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40580] Add -fcheck=pointer with runtime check for using an unallocated argument

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-06-29 21:02 ---
FIXED on the trunk (4.5). Follow up is PR 29616


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/40597] New: Powerpc bootstrap is broken due to changes in expmed.c

[meissner at gcc dot gnu dot org]

On June 28th, the powerpc bootstrap was broken due to changes to expmed.c.  The
bootstrap dies when compiling libgcc.a as mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02180.html

emit_store_flag gets a GT test that it tries to convert to LE.  Inside the
recursive call, it then tries to convert the LE back to a GT test.  Eventually
the compiler runs out of stack space and dies.


-- 
   Summary: Powerpc bootstrap is broken due to changes in expmed.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-06-29 21:32 ---
Mine of course.  I was going to post the patch to the mailing list after it was
well into my x86_64-linux bootstrap, I'll add it here.

Thanks for the testcase BTW.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-29 21:32:47
   date||


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2009-06-29 21:34 ---
Created an attachment (id=18096)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18096&action=view)
patch currently in stage2

Here it is.  A bit early for posting to gcc-patches, but if you want to approve
it I'll commit it tomorrow morning, after making sure the bootstrap/regtest
passes.


-- 


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[meissner at gcc dot gnu dot org]

--- Comment #3 from meissner at gcc dot gnu dot org  2009-06-29 21:36 
---
Created an attachment (id=18097)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18097&action=view)
Proposed patch to fix the problem

This patch allows the powerpc64-gnu-linux system to boostrap once again.


-- 


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[meissner at linux dot vnet dot ibm dot com]

--- Comment #4 from meissner at linux dot vnet dot ibm dot com  2009-06-29 
21:46 ---
Subject: Re:  Powerpc bootstrap is broken due to changes in expmed.c

On Mon, Jun 29, 2009 at 09:34:02PM -, bonzini at gnu dot org wrote:
> 
> 
> --- Comment #2 from bonzini at gnu dot org  2009-06-29 21:34 ---
> Created an attachment (id=18096)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18096&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18096&action=view)
> patch currently in stage2
> 
> Here it is.  A bit early for posting to gcc-patches, but if you want to 
> approve
> it I'll commit it tomorrow morning, after making sure the bootstrap/regtest
> passes.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.

Approved assuming it passes bootstrap/regtest.


-- 


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

[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-06-29 21:51 ---
This is caused by revision 147995:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-29 21:51:45
   date||


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

[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-06-29 21:54 ---
This is related to PR 40304.


-- 


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

[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.

[ppluzhnikov at google dot com]

--- Comment #3 from ppluzhnikov at google dot com  2009-06-29 22:36 ---
Confirmed working correctly @147994.


-- 


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

[Bug rtl-optimization/40519] ICE with -O2 -ftracer __builtin_unreachable()

[daney at gcc dot gnu dot org]

--- Comment #2 from daney at gcc dot gnu dot org  2009-06-29 22:50 ---
Well the trunk at r149061 with both the afore mentioned patches applied does
not exhibit the ICE for me on x86_64-pc-linux-gnu.  Without the patches I
obtain the ICE.


-- 


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

[Bug c++/40274] [4.5 Regression] Revision 145566 caused ICE in tsubst, at cp/pt.c:9289

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-06-29 23:16 ---
Subject: Bug 40274

Author: jason
Date: Mon Jun 29 23:15:43 2009
New Revision: 149066

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149066
Log:
PR c++/40274
* error.c (dump_template_parms): Pass all args to
count_non_default_template_args.
(count_non_default_template_args): Pull out the inner ones.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c


-- 


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

[Bug c++/40274] [4.5 Regression] Revision 145566 caused ICE in tsubst, at cp/pt.c:9289

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-06-29 23:18 ---
Subject: Bug 40274

Author: jason
Date: Mon Jun 29 23:18:46 2009
New Revision: 149067

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149067
Log:
PR c++/40274
* error.c (dump_template_parms): Pass all args to
count_non_default_template_args.
(count_non_default_template_args): Pull out the inner ones.

Added:
trunk/gcc/testsuite/g++.dg/template/debug1.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-06-29 23:43 ---
The problem seems to be in based_loc_descriptor:
  /* If drap register is used to align stack, use frame
 pointer + offset to access stack variables.  If stack
 is aligned without drap, use stack pointer + offset to
 access stack variables.  */
  if (crtl->stack_realign_tried
  && cfa.reg == HARD_FRAME_POINTER_REGNUM
  && reg == frame_pointer_rtx)
{
  int base_reg
= DWARF_FRAME_REGNUM (cfa.indirect
  ? HARD_FRAME_POINTER_REGNUM
  : STACK_POINTER_REGNUM);
  return new_reg_loc_descr (base_reg, offset);
}
I don't see how it can be correct to look at cfa variable content in here, when
scanning through the function is well over and thus cfa contains whatever was
the CFA on the last emitted instruction.  Before epilogue unwinding this
happened to work, because cfa happened to stay at what was in the middle of the
function.


-- 


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