[Bug libstdc++/32908] Miss lexicographical_compare random access override

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-07-28 07:38 ---
Hi Chris. Sure, I can work on this, no big deal, otherwise, I'll let you know,
thanks. Before starting on that, however, I would be curious to hear from
Zdenek: is there something that could be done in the loop optimizer dealing
generally with this common patterns?


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||rakdver at kam dot mff dot
   ||cuni dot cz


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

[Bug fortran/31818] Wrongly accepts namelists with assumed-shape arrays

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2007-07-28 08:51 ---
Subject: Bug 31818

Author: dfranke
Date: Sat Jul 28 08:51:06 2007
New Revision: 127014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127014
Log:
gcc/fortran:
2007-07-28  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/31818
PR fortran/32876
PR fortran/32905
* gfortran.h (symbol_attribute): Added bits for pointer_comp,
private_comp.
* parse.c (parse_derived): Set pointer_comp/private_comp bits if the
derived
type ultimately contains pointer components or private components.
* module.c (ab_attribute): New values AB_POINTER_COMP, AB_PRIVATE_COMP.
(attr_bits): Added names for new ab_attributes.
(mio_symbol_attribute): Save/restore new attribute bits in modules.
* match.c (gfc_match_namelist): Removed check for namelist objects of
assumed
shape.
* resolve.c (resolve_fl_namelist): Added check for pointer or private
components in nested types. Added check for namelist objects of assumed
shape.

gcc/testsuite:
2007-07-28  Daniel Franke  <[EMAIL PROTECTED]>

* gfortran.dg/namelist_5.f90: Adjusted error message.
* gfortran.dg/assumed_shape_nml.f90: Renamed to ...
* gfortran.dg/namelist_31.f90: ... this. Removed dg-warning directive.
* gfortran.dg/assumed_size_nml.f90: Renamed to ...
* gfortran.dg/namelist_32.f90: ... this.

PR fortran/32876
* gfortran.dg/namelist_33.f90: New test.

PR fortran/32905
* gfortran.dg/namelist_34.f90: New test.

PR fortran/31818
* gfortran.dg/namelist_35.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_31.f90
  - copied, changed from r126930,
trunk/gcc/testsuite/gfortran.dg/assumed_shape_nml.f90
trunk/gcc/testsuite/gfortran.dg/namelist_32.f90
  - copied unchanged from r126930,
trunk/gcc/testsuite/gfortran.dg/assumed_size_nml.f90
trunk/gcc/testsuite/gfortran.dg/namelist_33.f90
trunk/gcc/testsuite/gfortran.dg/namelist_34.f90
trunk/gcc/testsuite/gfortran.dg/namelist_35.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/assumed_shape_nml.f90
trunk/gcc/testsuite/gfortran.dg/assumed_size_nml.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_5.f90


-- 


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

[Bug fortran/32905] NAMELIST accepts types with ultimate POINTER components

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2007-07-28 08:51 ---
Subject: Bug 32905

Author: dfranke
Date: Sat Jul 28 08:51:06 2007
New Revision: 127014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127014
Log:
gcc/fortran:
2007-07-28  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/31818
PR fortran/32876
PR fortran/32905
* gfortran.h (symbol_attribute): Added bits for pointer_comp,
private_comp.
* parse.c (parse_derived): Set pointer_comp/private_comp bits if the
derived
type ultimately contains pointer components or private components.
* module.c (ab_attribute): New values AB_POINTER_COMP, AB_PRIVATE_COMP.
(attr_bits): Added names for new ab_attributes.
(mio_symbol_attribute): Save/restore new attribute bits in modules.
* match.c (gfc_match_namelist): Removed check for namelist objects of
assumed
shape.
* resolve.c (resolve_fl_namelist): Added check for pointer or private
components in nested types. Added check for namelist objects of assumed
shape.

gcc/testsuite:
2007-07-28  Daniel Franke  <[EMAIL PROTECTED]>

* gfortran.dg/namelist_5.f90: Adjusted error message.
* gfortran.dg/assumed_shape_nml.f90: Renamed to ...
* gfortran.dg/namelist_31.f90: ... this. Removed dg-warning directive.
* gfortran.dg/assumed_size_nml.f90: Renamed to ...
* gfortran.dg/namelist_32.f90: ... this.

PR fortran/32876
* gfortran.dg/namelist_33.f90: New test.

PR fortran/32905
* gfortran.dg/namelist_34.f90: New test.

PR fortran/31818
* gfortran.dg/namelist_35.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_31.f90
  - copied, changed from r126930,
trunk/gcc/testsuite/gfortran.dg/assumed_shape_nml.f90
trunk/gcc/testsuite/gfortran.dg/namelist_32.f90
  - copied unchanged from r126930,
trunk/gcc/testsuite/gfortran.dg/assumed_size_nml.f90
trunk/gcc/testsuite/gfortran.dg/namelist_33.f90
trunk/gcc/testsuite/gfortran.dg/namelist_34.f90
trunk/gcc/testsuite/gfortran.dg/namelist_35.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/assumed_shape_nml.f90
trunk/gcc/testsuite/gfortran.dg/assumed_size_nml.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_5.f90


-- 


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

[Bug fortran/32876] Wrongly accepts private items in public NAMELISTs

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2007-07-28 08:51 ---
Subject: Bug 32876

Author: dfranke
Date: Sat Jul 28 08:51:06 2007
New Revision: 127014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127014
Log:
gcc/fortran:
2007-07-28  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/31818
PR fortran/32876
PR fortran/32905
* gfortran.h (symbol_attribute): Added bits for pointer_comp,
private_comp.
* parse.c (parse_derived): Set pointer_comp/private_comp bits if the
derived
type ultimately contains pointer components or private components.
* module.c (ab_attribute): New values AB_POINTER_COMP, AB_PRIVATE_COMP.
(attr_bits): Added names for new ab_attributes.
(mio_symbol_attribute): Save/restore new attribute bits in modules.
* match.c (gfc_match_namelist): Removed check for namelist objects of
assumed
shape.
* resolve.c (resolve_fl_namelist): Added check for pointer or private
components in nested types. Added check for namelist objects of assumed
shape.

gcc/testsuite:
2007-07-28  Daniel Franke  <[EMAIL PROTECTED]>

* gfortran.dg/namelist_5.f90: Adjusted error message.
* gfortran.dg/assumed_shape_nml.f90: Renamed to ...
* gfortran.dg/namelist_31.f90: ... this. Removed dg-warning directive.
* gfortran.dg/assumed_size_nml.f90: Renamed to ...
* gfortran.dg/namelist_32.f90: ... this.

PR fortran/32876
* gfortran.dg/namelist_33.f90: New test.

PR fortran/32905
* gfortran.dg/namelist_34.f90: New test.

PR fortran/31818
* gfortran.dg/namelist_35.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_31.f90
  - copied, changed from r126930,
trunk/gcc/testsuite/gfortran.dg/assumed_shape_nml.f90
trunk/gcc/testsuite/gfortran.dg/namelist_32.f90
  - copied unchanged from r126930,
trunk/gcc/testsuite/gfortran.dg/assumed_size_nml.f90
trunk/gcc/testsuite/gfortran.dg/namelist_33.f90
trunk/gcc/testsuite/gfortran.dg/namelist_34.f90
trunk/gcc/testsuite/gfortran.dg/namelist_35.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/assumed_shape_nml.f90
trunk/gcc/testsuite/gfortran.dg/assumed_size_nml.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_5.f90


-- 


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

[Bug fortran/31818] Wrongly accepts namelists with assumed-shape arrays

[dfranke at gcc dot gnu dot org]

--- Comment #7 from dfranke at gcc dot gnu dot org  2007-07-28 08:52 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||07/msg02016.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug fortran/32876] Wrongly accepts private items in public NAMELISTs

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2007-07-28 08:53 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||07/msg02016.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug fortran/32905] NAMELIST accepts types with ultimate POINTER components

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2007-07-28 08:54 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||07/msg02016.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug c/32923] [4.3.0 Regression] too many memory references for `lea'

[rask at sygehus dot dk]

--- Comment #4 from rask at sygehus dot dk  2007-07-28 09:00 ---
This is not a GCC bug. The part that fails is broken, inline asm:

#APP
# 173 "include/asm/string.h" 1
movb %al,%ah
1:  lodsb
cmpb %ah,%al
jne 2f
leal -1(%esi),20(%esp)
2:  testb %al,%al
jne 1b
# 0 "" 2
#NO_APP

Please take this up with whoever supplied you with include/asm/string.h.


-- 


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

[Bug target/32923] [4.3 Regression] too many memory references for `lea'

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c   |target
Summary|[4.3.0 Regression] too many |[4.3 Regression] too many
   |memory references for `lea' |memory references for `lea'
   Target Milestone|--- |4.3.0


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

[Bug target/32923] [4.3 Regression] too many memory references for `lea'

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-07-28 09:13 ---
static inline __attribute__((always_inline)) int strncmp(const char * cs,const
char * ct,size_t count)
{
register int __res;
int d0, d1, d2;
__asm__ __volatile__(
 "1:\tdecl %3\n\t"
 "js 2f\n\t"
 "lodsb\n\t"
 "scasb\n\t"
 "jne 3f\n\t"
 "testb %%al,%%al\n\t"
 "jne 1b\n"
 "2:\txorl %%eax,%%eax\n\t"
 "jmp 4f\n"
 "3:\tsbbl %%eax,%%eax\n\t"
 "orb $1,%%al\n"
 "4:"
 :"=a" (__res), "=&S" (d0), "=&D" (d1), "=&c" (d2)
 :"1" (cs),"2" (ct),"3" (count)
 :"memory");
return __res;
}


`g'
Any register, memory or immediate integer operand is allowed, except for
registers that are not general registers.

Please report this to glibc as they have bad inline-asm.  (note this is the
first time).


-- 

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

[Bug fortran/32879] Document algorithm used for random generator

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2007-07-28 09:45 ---
Subject: Bug number PR32879

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


-- 


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

[Bug fortran/32924] New: "Conditional jump depends on uninitialised value": gfortran.dg/large_unit_1.f90

[burnus at gcc dot gnu dot org]

compiling testsuite/gfortran.dg/large_unit_1.f90
and running valgrind ./a.out shows the following error message. The error
message shown is:
  At line 8 of file large_unit_1.f90
  Fortran runtime error: Unit number in I/O statement too large

==20895== Conditional jump or move depends on uninitialised value(s)
==20895==at 0x4E3D9B1: _gfortrani_show_locus (error.c:256)
==20895==by 0x4E3DFB4: _gfortran_generate_error (error.c:502)
==20895==by 0x400A88: MAIN__ (large_unit_1.f90:8)
==20895==by 0x400D1B: main (fmain.c:22)
At line 8 of file large_unit_1.f90
Fortran runtime error: Unit number in I/O statement too large


-- 
   Summary: "Conditional jump depends on uninitialised value":
gfortran.dg/large_unit_1.f90
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  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=32924

[Bug fortran/32925] New: "Syscall param write(buf) points to uninitialised value": unf_io_convert_3.f90

[burnus at gcc dot gnu dot org]

Compiling testsuite/gfortran.dg/unf_io_convert_3.f90 and running valgrind a.out
shows the following diagnostic:

==2411== Syscall param write(buf) points to uninitialised byte(s)
==2411==at 0x5606730: write (in /lib64/libc-2.6.so)
==2411==by 0x4EBEFB0: do_write (unix.c:365)
==2411==by 0x4EBF054: fd_flush (unix.c:415)
==2411==by 0x4EB2480: _gfortran_st_backspace (file_pos.c:230)
==2411==by 0x400AF5: MAIN__ (unf_io_convert_3.f90:9)
==2411==by 0x400D7B: main (fmain.c:22)
==2411==  Address 0x40508B4 is 156 bytes inside a block of size 8,344 alloc'd
==2411==at 0x4C21D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==2411==by 0x4E3E518: _gfortrani_get_mem (memory.c:53)
==2411==by 0x4EBFA79: fd_to_stream (unix.c:1072)
==2411==by 0x4EB8A20: _gfortrani_new_unit (open.c:381)
==2411==by 0x4EB90B9: _gfortran_st_open (open.c:566)
==2411==by 0x400A6A: MAIN__ (unf_io_convert_3.f90:7)
==2411==by 0x400D7B: main (fmain.c:22)


-- 
   Summary: "Syscall param write(buf) points to uninitialised
value": unf_io_convert_3.f90
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  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=32925

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2007-07-28 10:02 ---
It might be a missed optimization, so it would be nice to see where the
slowdown is and what changed there wrt trees we get.  (note I will not have
time to
investigate this for the next three weeks as I'm on vacation)


-- 


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

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-07-28 10:32 ---
Confirmed.  A bug in fold.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-28 10:32:49
   date||


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

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-07-28 10:33 ---
Created an attachment (id=13993)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13993&action=view)
patch

This patch fixes it.  It's ok for mainline if it passes a bootstrap & regtest.
It would be nice if someone could give it the cycles as I'm on vacation for the
next 3 weeks.  Thx.


-- 


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

[Bug c++/30917] [4.1/4.2/4.3 Regression] ICE with friend in local class (to a function)

[simartin at gcc dot gnu dot org]

--- Comment #6 from simartin at gcc dot gnu dot org  2007-07-28 10:48 
---
Subject: Bug 30917

Author: simartin
Date: Sat Jul 28 10:48:30 2007
New Revision: 127016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127016
Log:
gcc/cp/

2007-07-28  Simon Martin  <[EMAIL PROTECTED]>
Mark Mitchell  <[EMAIL PROTECTED]>

PR c++/30917
* name-lookup.c (lookup_name_real): Non namespace-scope bindings can be
hidden due to friend declarations in local classes.

gcc/testsuite/

2007-07-28  Simon Martin  <[EMAIL PROTECTED]>

PR c++/30917
* g++.dg/lookup/friend11.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lookup/friend11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/32926] New: Internal compiler error in the middle of a sizeable package build

[rbk at louisiana dot edu]

This bug occurred during a build of a version of "GlobSol" that builds
correctly with the g95 compiler.  It happens with the "unofficial" build
of gfortran for native Windows that I downloaded from
http://gcc.gnu.org/wiki/GFortranBinaries#Windows from the link: 
mingw build, or "native Windows": download the latest installer (dated
2007-07-06). 

The compiler output is:

gfortran bug report:

gfortran -c -Ic:\GlobSol_gfort c:\GlobSol_gfort\iterate\dogleg_opt.f90
c:\GlobSol_gfort\iterate\dogleg_opt.f90: In function 'search_dogleg':
c:\GlobSol_gfort\iterate\dogleg_opt.f90:144: internal compiler error: in
gfc_get_symbol_decl, at fortran/trans-decl.c:876
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [c:\GlobSol_gfort\dogleg_opt.o] Error 1


I am not sure what else you need.  I could send the entire package source,
along
with the makefile, but the bug reporting instructions seemed to say
that it is not desired.  However, the source file that won't compile
uses two modules that are part of a hierarchy that must be compiled first.
I'm at a bit of a loss at present to isolate the problem further.  Please
communicate with me as appropriate.

Baker


-- 
   Summary: Internal compiler error in the middle of a sizeable
package build
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbk at louisiana dot edu


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

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-07-28 11:57 ---
Possibly a duplicate of PR 31213.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
   Target Milestone|--- |4.3.0


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

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-07-28 12:33 
---
Hi Ralph,

Thanks for the bug report. Can you please email the sources to me privately
([EMAIL PROTECTED]). I will work out whether this is a duplicate of PR31213,
or a different bug (and will make a short testcase out of it).

Thanks,
François-Xavier


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug libfortran/32770] -fdefault-integer-8 and the library

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-07-28 12:42 
---
I fixed the same kind of problems with MVBITS (it was PR32357). Maybe we should
ask to Dominique Dhumières to test on ppc-darwin? (like, running the testsuite
with -fdefault-integer-8)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-28 12:42:05
   date||


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

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-07-28 12:52 
---
I'll take care of that.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-07-28 12:51:45 |2007-07-28 12:52:05
   date||


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

[Bug web/32927] New: Online installation instructions only for mainline

[ammonton at cc dot helsinki dot fi]

The GCC installation instructions at  only cover
the mainline version. If the instructions were kept per-version as the GCC
manual it would make configuring and installing release versions easier. See
the thread starting at .


-- 
   Summary: Online installation instructions only for mainline
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ammonton at cc dot helsinki dot fi


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

[Bug fortran/24965] Wrong file name in error message

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-07-28 12:55 
---
Closing, unless Erik can tell us more about how the files were prepared.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug fortran/32487] no 8-bit type when compiling a cross-compiler for mips

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-07-28 12:57 
---
No news... closing as INVALID. Please reopen with additional information (like
the C library you used, whether you do a combined build, etc.) if you want us
to investigate further.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|minor   |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-28 12:51:45
   date||
   Target Milestone|--- |4.3.0


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

[Bug libfortran/32812] random_seed and date_and_time

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-07-28 13:07 
---
(In reply to comment #0)
> <[EMAIL PROTECTED]>,

This Usenet post can be found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0b60cf25162534bf/2e8d2775f455a33f


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-28 13:07:22
   date||


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

[Bug fortran/32928] New: DATA statement with array element as initializer is rejected

[burnus at gcc dot gnu dot org]

Found while debugging PR32315.

program chkdata
character(len=1), parameter,dimension(4) :: string = 'A'
character :: a
data a /string(4)/
end program chkdata

Is rejected:
data a /string(4)/
 1
Error: Syntax error in DATA statement at (1)

However, g95, NAG f95, ifort, openf95 accept it.

Note that
   data a /string(5)/
should be rejected:
   First subscript (5) is greater than upper bound (4) for array STRING


-- 
   Summary: DATA statement with array element as initializer is
rejected
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid, accepts-invalid
  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=32928

[Bug libfortran/32770] -fdefault-integer-8 and the library

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-07-28 13:27 ---
> I fixed the same kind of problems with MVBITS (it was PR32357). Maybe we 
> should
> ask to Dominique Dhumières to test on ppc-darwin? (like, running the testsuite
> with -fdefault-integer-8)

I have looked for the way to run the testsuite on gfortran only, but did not
find a way to
do it. Could someone give me the right pointer? Also I'll need the directive to
do the
run with -fdefault-integer-8.

I am currently rebuilding the gcc-4.3-20070727 snapshot (takes more than half a
day on my
machine and I have started around 11AM French time).  So I'll be able to send
the results 
tomorrow only.


-- 


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

[Bug fortran/32928] DATA statement with array element as initializer is rejected

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-07-28 13:29 ---
The problem seems to be that in decl.c the var_element() function assumes that
it only has to match a variable and not also, e.g., an array element.


-- 


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

[Bug libfortran/32770] -fdefault-integer-8 and the library

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-07-28 13:37 
---
(In reply to comment #2)
> I have looked for the way to run the testsuite on gfortran only, but did not
> find a way to
> do it. Could someone give me the right pointer? Also I'll need the directive 
> to
> do the
> run with -fdefault-integer-8.

To run only the gfortran testsuite, cd inside the ${builddir}/gcc directory,
and run "make check-gfortran".

To run this testsuite with -fdefault-integer-8, cd inside this same directory,
and run:

   make check-gfortran RUNTESTFLAGS="--target_board=unix/-fdefault-integer-8"

(Full doc is available at http://gcc.gnu.org/install/test.html)


-- 


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

[Bug fortran/32048] max / min and NaN

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-07-28 13:49 
---
Here's a patch that yields results according to IEEE:

Index: f95-lang.c
===
--- f95-lang.c  (revision 126997)
+++ f95-lang.c  (working copy)
@@ -1004,6 +1004,11 @@ gfc_init_builtin_functions (void)
  "malloc", false);
   DECL_IS_MALLOC (built_in_decls[BUILT_IN_MALLOC]) = 1;

+  tmp = tree_cons (NULL_TREE, void_type_node, void_list_node);
+  ftype = build_function_type (integer_type_node, tmp);
+  gfc_define_builtin ("__builtin_isnan", ftype, BUILT_IN_ISNAN,
+ "__builtin_isnan", true);
+
 #define DEF_PRIMITIVE_TYPE(ENUM, VALUE) \
   builtin_types[(int) ENUM] = VALUE;
 #define DEF_FUNCTION_TYPE_0(ENUM, RETURN)  \
Index: trans-intrinsic.c
===
--- trans-intrinsic.c   (revision 126997)
+++ trans-intrinsic.c   (working copy)
@@ -1407,11 +1407,11 @@ gfc_conv_intrinsic_ttynam (gfc_se * se, 
 /* Get the minimum/maximum value of all the parameters.
 minmax (a1, a2, a3, ...)
 {
-  if (a2 .op. a1)
+  if (a2 .op. a1 || isnan(a1))
 mvar = a2;
   else
 mvar = a1;
-  if (a3 .op. mvar)
+  if (a3 .op. mvar || isnan(mvar))
 mvar = a3;
   ...
   return mvar
@@ -1487,7 +1487,7 @@ gfc_conv_intrinsic_minmax (gfc_se * se, 
   elsecase = build2_v (MODIFY_EXPR, mvar, limit);
   for (i = 1, argexpr = argexpr->next; i < nargs; i++)
 {
-  tree cond;
+  tree cond, isnan;

   val = args[i]; 

@@ -1509,6 +1509,11 @@ gfc_conv_intrinsic_minmax (gfc_se * se, 
   thencase = build2_v (MODIFY_EXPR, mvar, convert (type, val));

   tmp = build2 (op, boolean_type_node, convert (type, val), limit);
+  if (FLOAT_TYPE_P (TREE_TYPE (limit)))
+   {
+ isnan = build_call_expr (built_in_decls[BUILT_IN_ISNAN], 1, limit);
+ tmp = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, tmp, isnan);
+   }
   tmp = build3_v (COND_EXPR, tmp, thencase, elsecase);

   if (cond != NULL_TREE)


With this, we generate calls to __builtin_isnan, which probably means slower
code is generated. Thus, we might want to make this dependent on whether
IEEE_ARITHMETIC is loaded or not, when we have this module implemented.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2007-07-28 13:49:41
   date||


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

[Bug fortran/32048] max/min and NaN

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-07-28 13:49:41 |2007-07-28 13:50:30
   date||
Summary|max / min and NaN   |max/min and NaN


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

[Bug fortran/32928] DATA statement with array element as initializer is rejected

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-07-28 14:00 ---
R532 data-stmt-constant is scalar-constant
or scalar-constant-subobject
or signed-int-literal-constant
or signed-real-literal-constant
or null-init
or structure-constructor

I think this also allows for substrings.


-- 


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

[Bug libfortran/32770] -fdefault-integer-8 and the library

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2007-07-28 14:18 ---
> (Full doc is available at http://gcc.gnu.org/install/test.html)

I have read it, but I got confused by:

"In order to run sets of tests selectively, there are targets `make check-gcc'
and `make check-g++' in the gcc subdirectory of the object directory. You can
also just run `make check' in a subdirectory of the object directory."

and did not picked the right subdirectory from the above illuminating wording!

Apparently, the 'make check-gfortran' I tried seems to work. I'll run the full
run tonight.


-- 


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

[Bug fortran/32048] max/min and NaN

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-07-28 15:23 
---
Subject: Bug 32048

Author: fxcoudert
Date: Sat Jul 28 15:23:11 2007
New Revision: 127019

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127019
Log:
PR fortran/32048

* f95-lang.c (gfc_init_builtin_functions): Add declaration for
__builtin_isnan.
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Handled NaNs.

* gfortran.dg/nan_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/nan_1.f90
Modified:
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/trans-intrinsic.c


-- 


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

[Bug fortran/32048] max/min and NaN

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-07-28 15:23 
---
Fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/31609] module that calls a contained function with an ENTRY point

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2007-07-28 15:29 
---
Created an attachment (id=13994)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13994&action=view)
Example of bad translation

This attached example of tree-dump-original shows that we are getting a
translation error.  See the k=2B .  It should be k.1 = 2.  So the error is
after my initial patch with test case in #8:

pr31609-2.f90:11: internal compiler error: gimplification failed

Getting closer I hope


-- 


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

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2007-07-28 15:37 
---
I will mention that pr31213 has multiple problems.  We have a partial fix that
appears to take care of one of these.  So if you get a reduced case here, we
can try it.


-- 


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

[Bug fortran/32924] "Conditional jump depends on uninitialised value": gfortran.dg/large_unit_1.f90

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-07-28 15:56 
---
I will take care of this one


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-28 15:56:16
   date||


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

[Bug fortran/32925] "Syscall param write(buf) points to uninitialised value": unf_io_convert_3.f90

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-07-28 15:57 
---
This is most likely mine.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-28 15:57:05
   date||


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

[Bug fortran/32924] "Conditional jump depends on uninitialised value": gfortran.dg/large_unit_1.f90

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-07-28 16:13 
---
I believe that valgrind is showing this because the st_parameter_common
structure "cmp" is set at compile time.  The options.locus parameter is
initialized to zero in environ.c


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

[cato at df dot lth dot se]

--- Comment #3 from cato at df dot lth dot se  2007-07-28 16:13 ---
Subject: Re:  [4.3 Regression] error: type mismatch in
 binary expression


On Sat, 28 Jul 2007, rguenth at gcc dot gnu dot org wrote:

> This patch fixes it.  It's ok for mainline if it passes a bootstrap & regtest.
> It would be nice if someone could give it the cycles as I'm on vacation for 
> the
> next 3 weeks.  Thx.

Bootstrapped and regtested on i386-unknown-netbsdelf3.1.

I'll commit it.

/Krister


-- 


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

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

[kristerw at gcc dot gnu dot org]

--- Comment #4 from kristerw at gcc dot gnu dot org  2007-07-28 16:26 
---
Subject: Bug 32920

Author: kristerw
Date: Sat Jul 28 16:26:44 2007
New Revision: 127021

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

PR middle-end/32920
* fold-const.c (fold_cond_expr_with_comparison): Convert
operand zero of MIN/MAX_EXPR to correct type.

* gcc.c-torture/compile/pr32920.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr32920.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/32920] [4.3 Regression] error: type mismatch in binary expression

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2007-07-28 16:33 ---
Thx!


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug web/32927] Online installation instructions only for mainline

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-07-28 17:11 ---
This one purpose, you should have looked into the install directory which has
an index.html already in the tar file you downloaded.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.0   |---


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

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-07-28 18:17 
---
Hum, first problem: we can't make a function like _gfortran_selected_real_kind
bind(c) because it has optional arguments:

function selected_real_kind (p, r) &
   bind(c,name="_gfortran_selected_real_kind")
  implicit none
  integer, optional, intent (in) :: p, r

Error: Variable 'p' at (1) cannot have the OPTIONAL attribute because procedure
'selected_real_kind' is BIND(C)

Is there a way around this issue?


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[dorit at gcc dot gnu dot org]

--- Comment #8 from dorit at gcc dot gnu dot org  2007-07-28 19:20 ---
> v0 (and v10 are scratch registers and not saved.

so does it look like a register allocation bug then? 


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #9 from rakdver at kam dot mff dot cuni dot cz  2007-07-28 
19:27 ---
Subject: Re:  Bootstrap with vectorization enabled fails with ICE on PPC

> > v0 (and v10 are scratch registers and not saved.
> 
> so does it look like a register allocation bug then? 

not really; it seems like a md problem (the registers v0-v19
are not marked as call clobbered); the patch below should
fix the problem.

Index: testsuite/gcc.dg/pr32582.c
===
*** testsuite/gcc.dg/pr32582.c  (revision 0)
--- testsuite/gcc.dg/pr32582.c  (revision 0)
***
*** 0 
--- 1,32 
+ /* { dg-do run { target { powerpc*-*-* && powerpc_altivec_ok } } } */
+ /* { dg-options "-O2 -ftree-vectorize -maltivec" } */
+ 
+ #include 
+ #include 
+ 
+ char a[64];
+ 
+ void set (void)
+ {
+   int i;
+ 
+   for (i = 0; i < 64; i++)
+ a[i] = 'x';
+ }
+ 
+ void check (void)
+ {
+   int i;
+ 
+   for (i = 0; i < 64; i++)
+ if (a[i] != 0)
+   abort ();
+ }
+ 
+ int main (void)
+ {
+   set ();
+   memset (a, 0, sizeof a);
+   check ();
+   return 0;
+ }
Index: config/rs6000/rs6000.h
===
*** config/rs6000/rs6000.h  (revision 126932)
--- config/rs6000/rs6000.h  (working copy)
*** extern enum rs6000_nop_insertion rs6000_
*** 699,706 
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1,\
 /* AltiVec registers.  */ \
!0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
!0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 1, 1  \
 , 1, 1, 1   \
  }
--- 699,706 
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1,\
 /* AltiVec registers.  */ \
!1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
!1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 1, 1  \
 , 1, 1, 1   \
  }
*** extern enum rs6000_nop_insertion rs6000_
*** 718,725 
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1,\
 /* AltiVec registers.  */ \
!0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
!0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 0, 0  \
 , 0, 0, 0   \
  }
--- 718,725 
 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1,\
 /* AltiVec registers.  */ \
!1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
!1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
 0, 0  \
 , 0, 0, 0   \
  }


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[dje at watson dot ibm dot com]

--- Comment #10 from dje at watson dot ibm dot com  2007-07-28 19:40 ---
Subject: Re:  Bootstrap with vectorization enabled fails with ICE on PPC 

Should this test be using -mabi=altivec or is there a general
assumption of -mabi=altivec when using autovec?  That conditionally sets
the call clobbered registers correctly.  I don't think the MD should
change for -maltivec.

David


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2007-07-28 19:45 
---
This code in  rs6000_conditional_register_usage should have done the same thing
as the patch posted:
  if (TARGET_ALTIVEC_ABI)
for (i = FIRST_ALTIVEC_REGNO; i < FIRST_ALTIVEC_REGNO + 20; ++i)
  call_used_regs[i] = call_really_used_regs[i] = 1;


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[dje at watson dot ibm dot com]

--- Comment #12 from dje at watson dot ibm dot com  2007-07-28 19:48 ---
Subject: Re:  Bootstrap with vectorization enabled fails with ICE on PPC 

And we default to ALTIVEC ABI for powerpc-linux:

  /* Set Altivec ABI as default for powerpc64 linux.  */
  if (TARGET_ELF && TARGET_64BIT)
{
  rs6000_altivec_abi = 1;
  TARGET_ALTIVEC_VRSAVE = 1;
}

So something else is wrong.

David


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2007-07-28 19:49 
---
What happens if you add -mabi=altivec to the command line, does it work then? 
If not, then that loop I pointed out is being miscompiled :).


-- 


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

[Bug libfortran/32736] Replace -fallow-leading-underscore by Bind(C)

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-07-28 20:12 
---
Another problem is that some of these routines take CHARACTER(LEN=*) arguments,
which make them incompatible with BIND(C):

../../../../trunk/libgfortran/generated/misc_specifics.F90:225.37:

elemental function index_1_i16 (parm1, parm2) result(res) &
1
Error: Character argument 'parm1' at (1) must be length 1 because procedure
'index_1_i16' is BIND(C)


I'm dropping this PR, as I don't think there actually is a solution. If noone
can think of something, I might close it in the near future...


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/30917] [4.1/4.2/4.3 Regression] ICE with friend in local class (to a function)

[simartin at gcc dot gnu dot org]

--- Comment #7 from simartin at gcc dot gnu dot org  2007-07-28 20:12 
---
Subject: Bug 30917

Author: simartin
Date: Sat Jul 28 20:12:42 2007
New Revision: 127023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127023
Log:
gcc/cp/

2007-07-28  Simon Martin  <[EMAIL PROTECTED]>
Mark Mitchell  <[EMAIL PROTECTED]>

PR c++/30917
* name-lookup.c (lookup_name_real): Non namespace-scope bindings can be
hidden due to friend declarations in local classes.

gcc/testsuite/

2007-07-28  Simon Martin  <[EMAIL PROTECTED]>

PR c++/30917
* g++.dg/lookup/friend11.C: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/friend11.C
Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/name-lookup.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25297] Support for STRUCTURE/END STRUCTURE and RECORD

[jb at gcc dot gnu dot org]

--- Comment #4 from jb at gcc dot gnu dot org  2007-07-28 20:13 ---
Closing as WONTFIX, since nobody seems interested in a) implementing this
feature b) maintaining it.

As already mentioned, gfortran supports Fortran derived types which can be used
for similar purposes as these proposed old proprietary legacy extensions.


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/30917] [4.1 Regression] ICE with friend in local class (to a function)

[simartin at gcc dot gnu dot org]

--- Comment #8 from simartin at gcc dot gnu dot org  2007-07-28 20:14 
---
Fixed in 4.2 and 4.3.


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 Regression] ICE|[4.1 Regression] ICE with
   |with friend in local class  |friend in local class (to a
   |(to a function) |function)


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

[Bug fortran/13939] Does not accept missing subroutine arguments like g77

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-07-28 20:18 
---
After some talk among gfortran developers on IRC, it seems that there is
consensus that we won't be implementing this particular g77 feature. I'm thus
closing this bug as WONTFIX.

Of course, if anyone is interested in adding support for it in gfortran, please
feel free to reopen it and make plans to add the feature!


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'

[pavel dot petrovic at gmail dot com]

--- Comment #4 from pavel dot petrovic at gmail dot com  2007-07-28 20:24 
---
This bug is quite cruel. I have similar application, also for atmega168 and
WinAVR (avr-gcc (GCC) 4.1.2 (WinAVR 20070525)), and the following lines do not
compile giving the same error. Even worse, if the code is with for-loop, it
compiles, but it crashes when the variable is accessed, or it overwrites
it with a value of a different variable (that is not very neighboring one).

  //load calibrated values from eeprom  
  left_ir_min = eeprom_read_word((uint16_t*)0);
  left_ir_center = eeprom_read_word((uint16_t*)2);
  left_ir_max = eeprom_read_word((uint16_t*)4);
  right_ir_min = eeprom_read_word((uint16_t*)6);
  right_ir_center = eeprom_read_word((uint16_t*)8);
  right_ir_max = eeprom_read_word((uint16_t*)10);

  left_rot[0] = eeprom_read_word((uint16_t*)12);
  right_rot[0] = eeprom_read_word((uint16_t*)14);
  left_rot[1] = eeprom_read_word((uint16_t*)16);
  right_rot[1] = eeprom_read_word((uint16_t*)18);
  left_rot[2] = eeprom_read_word((uint16_t*)20); 
  /* any of the following lines, if present, cause compiler to fail */
  right_rot[2] = eeprom_read_word((uint16_t*)22); 
  left_rot[3] = eeprom_read_word((uint16_t*)24); 
  right_rot[3] = eeprom_read_word((uint16_t*)26); 


-- 

pavel dot petrovic at gmail dot com changed:

   What|Removed |Added

 CC||pavel dot petrovic at gmail
   ||dot com


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

[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-07-28 20:47 
---
(In reply to comment #3)
> Index: gcc/fortran/trans-array.c
> ===
> *** gcc/fortran/trans-array.c   (revision 126461)
> --- gcc/fortran/trans-array.c   (working copy)
> *** gfc_trans_array_constructor (gfc_loopinf
> *** 1656,1661 
> --- 1656,1673 
> 
> /* See if the constructor determines the loop bounds.  */
> dynamic = false;
> +
> +   if (ss->expr->shape && loop->to[0] == NULL_TREE)
> + {
> +   int n;
> +   for (n = 0; n < ss->expr->rank; n++)
> +   {
> + loop->to[n] = gfc_conv_mpz_to_tree (ss->expr->shape [n],
> + gfc_index_integer_kind);
> + loop->from[n] = gfc_index_zero_node;
> +   }
> + }
> +
> if (loop->to[0] == NULL_TREE)
>   {
> mpz_t size;

This is OK to commit.


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[hjl at lucon dot org]

--- Comment #6 from hjl at lucon dot org  2007-07-28 20:51 ---
This part of the patch:

Index: tree-ssa.c
===
--- tree-ssa.c  (revision 126326)
+++ tree-ssa.c  (working copy)
@@ -979,11 +979,9 @@ useless_type_conversion_p (tree outer_ty
return false;

   /* Do not lose casts between pointers with different
-TYPE_REF_CAN_ALIAS_ALL setting or alias sets.  */
-  if ((TYPE_REF_CAN_ALIAS_ALL (inner_type)
-  != TYPE_REF_CAN_ALIAS_ALL (outer_type))
- || (get_alias_set (TREE_TYPE (inner_type))
- != get_alias_set (TREE_TYPE (outer_type
+TYPE_REF_CAN_ALIAS_ALL setting.  */
+  if (TYPE_REF_CAN_ALIAS_ALL (inner_type)
+ != TYPE_REF_CAN_ALIAS_ALL (outer_type))
return false;

   /* Do not lose casts from const qualified to non-const

causes this performance regression.

437.leslie3d is a big file with 19 functions. If I put each function in
a separate file, there is no regression. If I put 2 particular functions
in one file, there are 10-30% regressions depending on input file. Those
2 functions work on several global arrays.

I tried " --param max-aliased-vops=100 --param avg-aliased-vops=7".
It doesn't make a difference.


-- 


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

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-07-28 20:51 
---
I do understand that it would be easier for you to "tweak" the kind numbers
used by gfortran to accomodate old code, but there really is a problem with
doing so: it will, for example, clash with the prospected use of real(kind=16)
for software floating-points, which we plan to incorporate into gfortran.

After some discussion on IRC, I'm closing this as WONTFIX, unless something
thinks of a way to avoid the clash and step forward to actually implement this
enhancement. In that later case, please REOPEN the bug.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2007-07-28 20:52 ---
(In reply to comment #3)

Could somebody test the patch below, please?

Paul

Index: gcc/fortran/trans-stmt.c
===
*** gcc/fortran/trans-stmt.c(revision 127010)
--- gcc/fortran/trans-stmt.c(working copy)
*** generate_loop_for_temp_to_lhs (gfc_expr
*** 1714,1719 
--- 1714,1720 
stmtblock_t block, body;
gfc_loopinfo loop1;
tree tmp;
+   tree falselhs;
tree wheremaskexpr;

/* Walk the lhs.  */
*** generate_loop_for_temp_to_lhs (gfc_expr
*** 1732,1737 
--- 1733,1741 
tmp = gfc_build_array_ref (tmp1, count1);

/* Use the scalar assignment as is.  */
+   falselhs = gfc_evaluate_now (lse.expr, &lse.pre);
+   falselhs = gfc_deallocate_alloc_comp (expr->ts.derived, falselhs, 0);
+   gfc_add_expr_to_block (&lse.post, falselhs);
gfc_add_block_to_block (&block, &lse.pre);
gfc_add_modify_expr (&block, lse.expr, tmp);
gfc_add_block_to_block (&block, &lse.post);
*** gfc_trans_where_assign (gfc_expr *expr1,
*** 2978,2984 
/* Use the scalar assignment as is.  */
if (sym == NULL)
  tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
!  loop.temp_ss != NULL, false);
else
  tmp = gfc_conv_operator_assign (&lse, &rse, sym);

--- 2982,2989 
/* Use the scalar assignment as is.  */
if (sym == NULL)
  tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
!  loop.temp_ss != NULL,
!  expr2->expr_type == EXPR_VARIABLE);
else
  tmp = gfc_conv_operator_assign (&lse, &rse, sym);


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2007-07-28 20:59 ---
Subject: Re:  [4.3 Regression]  Revision 126326
 causes 12% slowdown

On Sat, 28 Jul 2007, hjl at lucon dot org wrote:

> causes this performance regression.
> 
> 437.leslie3d is a big file with 19 functions. If I put each function in
> a separate file, there is no regression. If I put 2 particular functions
> in one file, there are 10-30% regressions depending on input file. Those
> 2 functions work on several global arrays.
> 
> I tried " --param max-aliased-vops=100 --param avg-aliased-vops=7".
> It doesn't make a difference.

This sounds strange and maybe relates this to PR32624.

Richard.


-- 


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

[Bug fortran/10220] attribute DW_AT_calling_convention not correct for fortran

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-07-28 21:01 
---
There's a thread about it starting at
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01501.html and with a summary of
the consensus at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01572.html
(although no further action was actually taken).


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org, woodzltc at cn dot ibm
   ||dot com, drow at gcc dot gnu
   ||dot org
   Last reconfirmed|2005-12-30 18:42:22 |2007-07-28 21:01:58
   date||


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

[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[dorit at gcc dot gnu dot org]

--- Comment #3 from dorit at gcc dot gnu dot org  2007-07-28 21:03 ---
(In reply to comment #2)
> > Andrew, makes sense to you?
> I think my patch only checks PREFERRED_STACK_BOUNDARY and not STACK_BOUNDARY
> which is why it does not work but I have not looked into it at all.

I see references in the patch to both PREFERRED_STACK_BOUNDARY and
STACK_BOUNDARY. Could you please check which of these needs to be fixed? (cause
I think your fix is the more desirable one). (just for the record, the link to
the patch in question is here: 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413#c21)


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #14 from rakdver at kam dot mff dot cuni dot cz  2007-07-28 
21:11 ---
Subject: Re:  Bootstrap with vectorization enabled fails with ICE on PPC

> What happens if you add -mabi=altivec to the command line, does it work then? 
> If not, then that loop I pointed out is being miscompiled :).

that seems unlikely (I will check on Monday, I do not have access to a
ppc machine till then).  Probably the problem is that -maltivec does not
imply -mabi=altivec, or some similar omission.


-- 


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

[Bug fortran/31609] module that calls a contained function with an ENTRY point

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-07-28 21:17 
---
Subject: Bug 31609

Author: jvdelisle
Date: Sat Jul 28 21:17:20 2007
New Revision: 127026

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127026
Log:
2007-07-28  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/31609
* resolve.c (generic_sym): Check for a same symbol and if so, return to
avoid infinite recursion.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[dje at watson dot ibm dot com]

--- Comment #15 from dje at watson dot ibm dot com  2007-07-28 21:48 ---
Subject: Re:  Bootstrap with vectorization enabled fails with ICE on PPC 

> rakdver at kam dot mff dot cuni dot cz writes:

rakdver> Probably the problem is that -maltivec does not
rakdver> imply -mabi=altivec, or some similar omission.

-maltivec does not imply -mabi=altivec, which is intended.

The Bugzilla PR says the target is powerpc64-linux, which
implicitly should enable -mabi=altivec.  If this is some other target,
then the BOOT_CFLAGS should include -mabi=altivec.  Either something is
wrong with GCC enabling ALTIVEC_ABI or this is cockpit error in the
options used to bootstrap GCC that has been hidden until now.

David


-- 


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

[Bug libfortran/32858] printf-capabilities for runtime_error()

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2007-07-28 21:59 ---
Created an attachment (id=13995)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13995&action=view)
a patch.  Unfortunately, it doesn't print out any error messages right now.


-- 


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

[Bug libfortran/32858] printf-capabilities for runtime_error()

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2007-07-28 22:04 ---
There are also a few other issues with the incomplete patch.
vsnprintf can be replaced by __builtin_vsnprintf
on systems where it isn't available.  I'll iron that out
when I have the main functionality working.


-- 


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

[Bug fortran/31609] module that calls a contained function with an ENTRY point

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-07-28 22:02 
---
Subject: Bug 31609

Author: jvdelisle
Date: Sat Jul 28 22:02:42 2007
New Revision: 127028

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127028
Log:
2007-07-29  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/31609
* gfortran.dg/entry_11.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_11.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

[rosana07a at gmail dot com]

--- Comment #6 from rosana07a at gmail dot com  2007-07-28 22:10 ---
As a mathematician and logician the handling os this PR and my previous PR32720
make no sense. A fellow worker told me about fortan 90/95 under gcc-4.3. the
only thing in common with both PR's was a change from gcc-4.2.x to 4.3.
Everything else remained constant. Consequently the change in behavior is most
logically due to that change. 

I am not a C language programmer and much less versed in assembly and CPU
architectures. I got error messages with invitations to file reports, which I
did according to instructions.

To my knowledge the C library is part of the C compiler. Both gcc and glibc are
part of the Free Software Foundation. Hence, it is up to whoever handled this
report to pass it on to the glibc people. 

Based on my experience and the material in the supposed duplicate to PR32720 I
will advise my employer to stay away from anything emanating from the Free
Software Foundation.


-- 

rosana07a at gmail dot com changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|RESOLVED|UNCONFIRMED
  Component|target  |other
 Resolution|INVALID |


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

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-07-28 22:41 
---
(In reply to comment #6)
> To my knowledge the C library is part of the C compiler.

Well, this is not true. The C library and C compiler are distinct projects. The
GCC compiler can be used with multiple C libraries, the most used one being the
glibc, but others are used e.g. on Windows or embedded targets.

> Both gcc and glibc are
> part of the Free Software Foundation. Hence, it is up to whoever handled this
> report to pass it on to the glibc people. 

And it will be done if you indicate that you don't intend to do it, but as you
found it, it's more natural that you report it (if only, to be kept informed of
progress in its resolution).

> the supposed duplicate to PR32720

I don't think there's anything to "suppose" about PR32720 being a duplicate (in
the sense that is in use in this bug database), and I don't see either what
complaint you can have against the handling of this PR. You had a Fortran code
that triggered a bug in GCC. This bug was fixed in 16 days (could have been
less, but I was away on vacation). However, I noted that although the Fortran
code couldn't lead to this bug any more, it could still be exposed by some
other codes, and thus asked to keep the PR open to keep track the other half of
the problem (which, I know, might not even be an issue to you, *we* do need to
keep track of it). It was then noticed by Andrew that this problem had already
been reported elsewhere, with a C source that triggers it; thus, PR32720 was
closed as a DUPLICATE.

I'll be glad to help clear this misunderstanding of how the bug database works,
but please keep in mind that the best way to get people help you is not by
using a harsh tone.

Now, I'm removing myself from the CC list of this bug, because it's not at all
in my area of competence (I'm a gfortran maintainer), and will refrain from
other generic comments about our bugzilla on particular PRs.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|fxcoudert at gcc dot gnu dot|
   |org |


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

[Bug fortran/32925] "Syscall param write(buf) points to uninitialised value": unf_io_convert_3.f90

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-07-28 22:33 
---
I think this is ignorable.  We allocate a buffer of 8192 bytes.  We only use a
portion of it, so the pointer to that block is being flagged as pointing to
uninitialized memory.  We don't want to take the performance penalty of setting
all that unused memory during an IO operation.

However, if this valgrind error is unique to just this test case, then further
digging is warranted.  So I keep looking.  :)


-- 


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

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-07-28 23:24 ---
Again glibc is a seperate project from GCC.  THis is a bug in glibc's headers
and should reported to them.


-- 

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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[hjl at lucon dot org]

--- Comment #8 from hjl at lucon dot org  2007-07-28 23:25 ---
(In reply to comment #7)

> This sounds strange and maybe relates this to PR32624.
> 

I tried the patch in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624#c4

It doesn't make a difference in this case. But both are related to
useless_type_conversion_p.


-- 


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

[Bug java/32929] New: [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

[hjl at lucon dot org]

revision 127028 failed to bootstrap on Linux/x86-64:

configure: error: `CXX' has changed since the previous run:
...

It may be caused by

http://gcc.gnu.org/ml/java-patches/2007-q3/msg00022.html


-- 
   Summary: [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX'
has changed since the previous run:
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org


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

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2007-07-29 00:46 
---
> Not my problem as I clearly can use earlier versions of gcc or other 
> compilers.
lets put it this way, glibc's headers are broken for the version you are using.
 And it just happens that newer GCC's break bad inline-asm.


-- 


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

[Bug other/32923] [4.3 Regression] too many memory references for `lea'

[rosana07a at gmail dot com]

--- Comment #9 from rosana07a at gmail dot com  2007-07-29 00:43 ---

> And it will be done if you indicate that you don't intend to do it, but as you
> found it, it's more natural that you report it (if only, to be kept informed .
> 
Not my problem as I clearly can use earlier versions of gcc or other compilers.

Also please unsubscribe me as I could not find any pertinent information.


-- 


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

[Bug bootstrap/32930] New: Bootstrap ICE in build2_stat

[mckelvey at maskull dot com]

Recent CVS

/home/mckelvey/software/gcc-obj/./gcc/xgcc
-B/home/mckelvey/software/gcc-obj/./gcc/
-B/usr/local/alphaev56-unknown-linux-gnu/bin/
-B/usr/local/alphaev56-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev56-unknown-linux-gnu/include -isystem
/usr/local/alphaev56-unknown-linux-gnu/sys-include -g -fkeep-inline-functions
-O2  -O2   -mieee -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -mieee
-g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include   -o
_gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep -DL_gcov_execl -c
../../../gcc/libgcc/../gcc/libgcov.c
../../../gcc/libgcc/../gcc/libgcov.c: In function '__gcov_execl':
../../../gcc/libgcc/../gcc/libgcov.c:838: internal compiler error: in
build2_stat, at tree.c:3076
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Linux alpha1 2.4.9-40 #1 Mon Sep 23 08:14:02 EDT 2002 alpha unknown

Using built-in specs.
Target: alphaev56-unknown-linux-gnu
Configured with: ../gcc/configure --verbose --enable-languages=c++
--disable-linux-futex --disable-nls --disable-tls
Thread model: posix
gcc version 4.3.0 20070527 (experimental)

alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++
--disable-linux-futex --disable-nls --disable-tls >clog 2>&1 &'

alias BUILD='nice gmake CFLAGS='\'''\'' BOOT_CFLAGS='\'''\''
LIBCFLAGS='\''-g'\'' LIBCXXFLAGS='\''-g'\'' bootstrap >log 2>&1 &'


-- 
   Summary: Bootstrap ICE in build2_stat
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
 GCC build triplet: alphaev56-unknown-linux-gnu
  GCC host triplet: alphaev56-unknown-linux-gnu
GCC target triplet: alphaev56-unknown-linux-gnu


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

[Bug bootstrap/32930] Bootstrap ICE in build2_stat

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-07-29 02:00 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2007-07-29 02:00 
---
*** Bug 32930 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mckelvey at maskull dot com


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

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.0


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

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-07-29 03:49 ---
I could reproduce this on i386-darwin:
configure: error: `CXX' has changed since the previous run:
configure:   former value:  /Users/apinski/src/local/gcc/objdir/./gcc/xgcc
-shared-libgcc -B/Users/apinski/src/local/gcc/objdir/./gcc -nostdinc++
-L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.9.4/x86_64/libstdc++-v3/src
-L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.9.4/x86_64/libstdc++-v3/src/.libs
-B/Users/apinski/local-gcc//i386-apple-darwin8.9.4/bin/
-B/Users/apinski/local-gcc//i386-apple-darwin8.9.4/lib/ -isystem
/Users/apinski/local-gcc//i386-apple-darwin8.9.4/include -isystem
/Users/apinski/local-gcc//i386-apple-darwin8.9.4/sys-include  -m64
configure:   current value: /Users/apinski/src/local/gcc/objdir/./gcc/xgcc
-shared-libgcc -B/Users/apinski/src/local/gcc/objdir/./gcc -nostdinc++
-L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.9.4/x86_64/libstdc++-v3/src
-L/Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.9.4/x86_64/libstdc++-v3/src/.libs
-B/Users/apinski/local-gcc//i386-apple-darwin8.9.4/bin/
-B/Users/apinski/local-gcc//i386-apple-darwin8.9.4/lib/ -isystem
/Users/apinski/local-gcc//i386-apple-darwin8.9.4/include -isystem
/Users/apinski/local-gcc//i386-apple-darwin8.9.4/sys-include -m64
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm .././config.cache' and start
over
configure: error: /bin/sh
'/Users/apinski/src/local/gcc/libjava/classpath/configure' failed for classpath
make[1]: *** [configure-target-libjava] Error 1
make: *** [bootstrap] Error 2
gcc_build: error: Could not bootstrap the compiler


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-29 03:49:03
   date||


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

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-07-29 03:51 ---
I think configure was regenerated wrongly.


-- 


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

[Bug libgcj/32929] [4.3 Regression] Make FAILURE in 4.3.0 - error: `CXX' has changed since the previous run:

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-07-29 03:52 ---
Yes it was:
-# CONFIG_SUBDIRS section, as fixed in confsubdir.m4.
+# CONFIG_SUBDIRS section.


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #16 from rakdver at kam dot mff dot cuni dot cz  2007-07-29 
06:33 ---
Subject: Re:  Bootstrap with vectorization enabled fails with ICE on PPC

> > rakdver at kam dot mff dot cuni dot cz writes:
> 
> rakdver> Probably the problem is that -maltivec does not
> rakdver> imply -mabi=altivec, or some similar omission.
> 
> -maltivec does not imply -mabi=altivec, which is intended.
> 
> The Bugzilla PR says the target is powerpc64-linux, which
> implicitly should enable -mabi=altivec.  If this is some other target,
> then the BOOT_CFLAGS should include -mabi=altivec.

it's on ppc-linux.  Nevertheless, it is suspicious that we allow a
fairly natural combination of flags (-O2 -maltivec -ftree-vectorize)
to cause misscompilation.


-- 


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