[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[anlauf at gmx dot de]

--- Comment #3 from anlauf at gmx dot de  2007-03-06 08:20 ---
(In reply to comment #2)
> The value 5008 is listed in libgfortran.h as ERROR_ENDFILE.  The
> -1 corresponds to ERROR_END.  So, the return value of 5008 is 
> telling you that you are trying to (initiate a?) read beyond
> the end of the file, which you admit to doing.

I actually do not want to read beyond the end of file,
I want gfortran to stay at the end of the file when trying to
read the next record or namelist.

All other compilers I have checked (xlf, ifort 7.x-9.x, g95)
stay at the end of file.  I find their behavior consistent
with the F2003 standard, section 9.10.4:

Execution of an input/output statement containing the IOSTAT=
specifier causes the scalar-int-variable in the IOSTAT= specifier
to become defined with

(3) The processor-dependent negative integer value of the constant
IOSTAT_END (13.8.2.5) if an end-of-file condition occurs and no
error condition occurs, or (...)

> AFAIK, the IOSTAT values aren't documented in gfortran.texi.
> Someday, someone will get around to documenting them.

The standard separates end-of-file, end-of-record, and
error conditions.  I don't think that EOF is necessarily
an error condition.  It would be nice if gfortran would
conform with these other compilers.


-- 


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[anlauf at gmx dot de]

--- Comment #4 from anlauf at gmx dot de  2007-03-06 08:42 ---
(In reply to comment #3)

> All other compilers I have checked (xlf, ifort 7.x-9.x, g95)
> stay at the end of file.

I stand corrected with regard to xlf.  It returns a
documented "recoverable error" condition.

I have to find out why the code in question that lead to
the problem report does not properly recover with gfortran.


-- 


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

[Bug target/17114] ColdFire ICE with illegal constraints

[rsandifo at gcc dot gnu dot org]

--- Comment #5 from rsandifo at gcc dot gnu dot org  2007-03-06 08:54 
---
Subject: Bug 17114

Author: rsandifo
Date: Tue Mar  6 08:54:31 2007
New Revision: 122604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122604
Log:
gcc/
PR target/23482
PR target/17114
* config/m68k/m68k-protos.h (m68k_legitimate_base_reg_p): Declare.
(m68k_legitimate_index_reg_p, m68k_legitimate_address_p): Likewise.
(m68k_matches_q_p, m68k_matches_u_p): Likewise.
* config/m68k/m68k.h (EXTRA_CONSTRAINT): Use m68k_matches_q_p
and m68k_matches_u_p.
(PCREL_GENERAL_OPERAND_OK, LEGITIMATE_BASE_REG_P): Delete.
(INDIRECTABLE_1_ADDRESS_P, GO_IF_NONINDEXED_ADDRESS): Delete.
(GO_IF_INDEXABLE_BASE, GO_IF_INDEXING, GO_IF_INDEXED_ADDRESS): Delete.
(LEGITIMATE_INDEX_REG_P, LEGITIMATE_INDEX_P): Delete.
(GO_IF_COLDFIRE_FPU_LEGITIMATE_ADDRESS): Delete.
(REG_STRICT_P): New macro.
(LEGITIMATE_PIC_OPERAND_P): Use REG_STRICT_P rather than
PCREL_GENERAL_OPERAND_OK.
(REG_OK_FOR_BASE_P): Merge definitions.  Use REG_STRICT_P and
m68k_legitimate_base_reg_p.
(REG_MODE_OK_FOR_INDEX_P): Likewise m68k_legitimate_index_reg_p.
(GO_IF_LEGITIMATE_ADDRESS): Likewise m68k_legitimate_address_p.
(PIC_CASE_VECTOR_ADDRESS): Update comment.
* config/m68k/m68k.c (m68k_address): New structure.
(m68k_legitimate_base_reg_p, m68k_legitimate_index_reg_p)
(m68k_decompose_index, m68k_legitimate_constant_address_p)
(m68k_jump_table_ref_p, m68k_decompose_address)
(m68k_legitimate_address_p, m68k_legitimate_mem_p, m68k_matches_q_p)
(m68k_matches_u_p): New functions.
(print_operand_address): Rewrite to use m68k_decompose_index.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k-protos.h
trunk/gcc/config/m68k/m68k.c
trunk/gcc/config/m68k/m68k.h


-- 


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

[Bug target/23482] [ColdFire] ICE in in final_scan_insn

[rsandifo at gcc dot gnu dot org]

--- Comment #7 from rsandifo at gcc dot gnu dot org  2007-03-06 08:54 
---
Subject: Bug 23482

Author: rsandifo
Date: Tue Mar  6 08:54:31 2007
New Revision: 122604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122604
Log:
gcc/
PR target/23482
PR target/17114
* config/m68k/m68k-protos.h (m68k_legitimate_base_reg_p): Declare.
(m68k_legitimate_index_reg_p, m68k_legitimate_address_p): Likewise.
(m68k_matches_q_p, m68k_matches_u_p): Likewise.
* config/m68k/m68k.h (EXTRA_CONSTRAINT): Use m68k_matches_q_p
and m68k_matches_u_p.
(PCREL_GENERAL_OPERAND_OK, LEGITIMATE_BASE_REG_P): Delete.
(INDIRECTABLE_1_ADDRESS_P, GO_IF_NONINDEXED_ADDRESS): Delete.
(GO_IF_INDEXABLE_BASE, GO_IF_INDEXING, GO_IF_INDEXED_ADDRESS): Delete.
(LEGITIMATE_INDEX_REG_P, LEGITIMATE_INDEX_P): Delete.
(GO_IF_COLDFIRE_FPU_LEGITIMATE_ADDRESS): Delete.
(REG_STRICT_P): New macro.
(LEGITIMATE_PIC_OPERAND_P): Use REG_STRICT_P rather than
PCREL_GENERAL_OPERAND_OK.
(REG_OK_FOR_BASE_P): Merge definitions.  Use REG_STRICT_P and
m68k_legitimate_base_reg_p.
(REG_MODE_OK_FOR_INDEX_P): Likewise m68k_legitimate_index_reg_p.
(GO_IF_LEGITIMATE_ADDRESS): Likewise m68k_legitimate_address_p.
(PIC_CASE_VECTOR_ADDRESS): Update comment.
* config/m68k/m68k.c (m68k_address): New structure.
(m68k_legitimate_base_reg_p, m68k_legitimate_index_reg_p)
(m68k_decompose_index, m68k_legitimate_constant_address_p)
(m68k_jump_table_ref_p, m68k_decompose_address)
(m68k_legitimate_address_p, m68k_legitimate_mem_p, m68k_matches_q_p)
(m68k_matches_u_p): New functions.
(print_operand_address): Rewrite to use m68k_decompose_index.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k-protos.h
trunk/gcc/config/m68k/m68k.c
trunk/gcc/config/m68k/m68k.h


-- 


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

[Bug target/23482] [ColdFire] ICE in in final_scan_insn

[rsandifo at gcc dot gnu dot org]

--- Comment #8 from rsandifo at gcc dot gnu dot org  2007-03-06 08:57 
---
Fixed in trunk.  This particular form of the patch is too
invasive for 4.1 and 4.2.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
  Known to work||4.3.0


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

[Bug target/28181] [4.0/4.1/4.2/4.3 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k

[rsandifo at gcc dot gnu dot org]

--- Comment #11 from rsandifo at gcc dot gnu dot org  2007-03-06 09:01 
---
Subject: Bug 28181

Author: rsandifo
Date: Tue Mar  6 09:01:07 2007
New Revision: 122609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122609
Log:
gcc/
PR target/28181
* config/m68k/m68k-protos.h (m68k_secondary_reload_class): Declare.
(m68k_preferred_reload_class): Likewise.
* config/m68k/m68k.h (HARD_REGNO_MODE_OK): Remove duplicated comment.
(SECONDARY_RELOAD_CLASS): Define.
(PREFERRED_RELOAD_CLASS): Use m68k_preferred_reload_class.
(LIMIT_RELOAD_CLASS): Delete.
* config/m68k/m68k.c (m68k_regno_mode_ok): Don't prevent address
registers from storing bytes.
(m68k_secondary_reload_class): New function.
(m68k_preferred_reload_class): Likewise.

gcc/testsuite/
* gcc.c-torture/compile/m68k-byte-addr.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/m68k-byte-addr.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k-protos.h
trunk/gcc/config/m68k/m68k.c
trunk/gcc/config/m68k/m68k.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/28181] [4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k

[rsandifo at gcc dot gnu dot org]

--- Comment #12 from rsandifo at gcc dot gnu dot org  2007-03-06 09:02 
---
Now fixed in trunk.  The patch may be too invasive to backport;
I'm not sure.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
  Known to work|3.4.6   |3.4.6 4.3.0
Summary|[4.0/4.1/4.2/4.3 regression]|[4.1/4.2 regression] ICE in
   |ICE in  |reload_cse_simplify_operands
   |reload_cse_simplify_operands|, at postreload.c:393 on
   |, at postreload.c:393 on|m68k
   |m68k|


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

[Bug tree-optimization/31037] [4.3 Regression] ICE: verify_ssa failed - definition in block 23 does not dominate use in block 32

[vladimir dot sysoev at gmail dot com]

--- Comment #6 from vladimir dot sysoev at gmail dot com  2007-03-06 09:17 
---
This issue causes cpu2006/447.dealII ICE too.


-- 


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[anlauf at gmx dot de]

--- Comment #5 from anlauf at gmx dot de  2007-03-06 10:22 ---
(In reply to comment #4)
> I have to find out why the code in question that lead to
> the problem report does not properly recover with gfortran.

It might be an interference with BACKSPACE, as the
full code that lead me to the investigation does a
scan through a namelist file and uses BACKSPACE
here and then.

Removing the BACKSPACE on the unit when the EOF condition
occured helps somewhat, but then I encounter a funny
error on a NAMELIST read:

Fortran runtime error: Missing format for FORMATTED data transfer

I thought that NAMELIST reads are list-directed.
Anyway, I guess I have to produce a better testcase.


-- 


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

[Bug c++/31045] gcc4.1. has problems with pointers

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-03-06 10:31 ---
Fixed in 4.0.4/4.1.2.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||rejects-valid
  Known to fail||4.1.0 4.1.1 4.0.3
  Known to work||4.1.2 4.0.4 3.4.6 4.2.0
   Last reconfirmed|-00-00 00:00:00 |2007-03-06 10:31:30
   date||
   Target Milestone|--- |4.0.4


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

[Bug c++/31045] gcc4.1. has problems with pointers

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2007-03-06 10:31 ---
Err, FIXED!


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/31047] GCC 4.1.1 has template bug

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-03-06 10:42 ---
No, this is a bug, 2nd stage name-lookup should find foo(const int&) as var is
dependent on the template parameter T (14.6/8, /9).
But I bet we have a dup for this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Keywords||wrong-code


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

[Bug c++/31049] G++ 4.1.1 forgets to allocate memory (skips part of user code)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-03-06 10:50 ---
Stock 4.1.1 ICEs for me on the testcase, but 4.1.2 looks fine - can you provide
the wrong assembly you are seeing?


-- 


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

[Bug target/29498] FTZ/DAZ for SSE should be ported to mingw32

[zuxy dot meng at gmail dot com]

--- Comment #2 from zuxy dot meng at gmail dot com  2007-03-06 11:26 ---
Created an attachment (id=13151)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151&action=view)
Proposed patch against 4.1.1


-- 


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

[Bug tree-optimization/18501] [4.1/4.2/4.3 Regression] Missing 'used unintialized' warning

[manu at gcc dot gnu dot org]

--- Comment #13 from manu at gcc dot gnu dot org  2007-03-06 11:41 ---
(In reply to comment #4)
> This is not really fixable.
> 
> Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html

I am really ignorant on this CCP optimisaton but I am willing to learn. I guess
that we merge UNDEFINED and 0 because we can assume that undefined is anything.
I am not so sure that is OK in this particular case. However, even in that
case, we should warn just at that moment, since we are already using an
UNDEFINED value, aren't we?

My point is that this testcase is fundamentally different from:
  int x;
  if (f())
x = 3;
  return x;

where f() is optimised away because it is always true. Some users may not want
to get warnings for the latter case, but any reasonable user wants to get a
warning for this PR.

Please, correct me when I am wrong. Thanks.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

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

[michael dot klein at fazi dot de]

--- Comment #42 from michael dot klein at fazi dot de  2007-03-06 12:07 
---
Created an attachment (id=13152)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13152&action=view)
Testcase (generated assembly files from gcc 4.1.1)


-- 


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

[Bug middle-end/31055] New: missed auto-vectorization optimization, when there is float to int conversion

[tehila at il dot ibm dot com]

On powerpc, current auto-vectorizer does not vectorize loops that have
conversion from float to int statement in it.
For example, in case we have the following program:

#include 

#define N 32

int main1 ()
{
  int i;
  int ib[N]; 
  float fa[N] =
{0.2,3.1,6.7,6.9,9.8,12.3,15.4,18.9,21.0,24,27,30,33,36,39,42,45,0,3,6,9,12,15,18,21,24,27,30,33,36,39,42};

  /* int -> float */
  for (i = 0; i < N; i++)
{
  ib[i] = (int) fa[i];  
}

/* check results:  */
  for (i = 0; i < N; i++)
{
  if (ib[i] != (int)fa[i]) 
abort (); 
}   

  return 0;
}

The vectorizer output is:
"not vectorized: relevant stmt not supported: D.2488_7 = (int) D.2487_6"
since there is no target hook for float to int conversion in rs6000 (altivec).


-- 
   Summary: missed auto-vectorization optimization, when there is
float to int conversion
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tehila at il dot ibm dot com
 GCC build triplet: powerpc-suse-linux
  GCC host triplet: powerpc-suse-linux
GCC target triplet: powerpc-suse-linux


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

[Bug tree-optimization/31037] [4.3 Regression] ICE: verify_ssa failed - definition in block 23 does not dominate use in block 32

[dnovillo at gcc dot gnu dot org]

--- Comment #7 from dnovillo at gcc dot gnu dot org  2007-03-06 12:55 
---

Might as well take this one too.


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dnovillo at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-03-04 20:56:47 |2007-03-06 12:55:29
   date||


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

[Bug objc/31056] New: objc bogus warning when using const

[icicle at cg dot tuwien dot ac dot at]

preprocessed source at:
http://www.cg.tuwien.ac.at/~icicle/gcc/ActionsForPolarisationImages.mi

complete output:

.m.o: ActionsForPolarisationImages
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.2/configure --enable-languages=c,objc
--prefix=/home/icicle/gcc4 --enable-shared --enable-threads=posix
Thread model: posix
gcc version 4.1.2
 /home/icicle/gcc4/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/cc1obj -E -quiet
-v -I/home/icicle/ART/include -DAMS_CONFIG="amd64--linux-gcc"
-D_GNU_OBJC_RUNTIME_ -DLINUX -D_64_BIT_LONG_ -DBROKEN_64BIT_VARARG_TERMINATION
-DAMS_Spectrum16 -DNORMAL -D_ART_WITHOUT_OPENGL_ -D_ART_WITHOUT_JPEGLIB_
/home/icicle/ART/Libs/Image/ActionsForPolarisationImages.m -mtune=k8 -std=gnu99
-Wall -Wwrite-strings -Wno-import -Wno-strict-aliasing -fomit-frame-pointer
-fworking-directory -O3 -fpch-preprocess -o ActionsForPolarisationImages.mi
ignoring nonexistent directory
"/home/icicle/gcc4/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/icicle/ART/include
 /usr/local/include
 /home/icicle/gcc4/include
 /home/icicle/gcc4/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/include
 /usr/include
End of search list.
 /home/icicle/gcc4/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/cc1obj
-fpreprocessed ActionsForPolarisationImages.mi -quiet -dumpbase
ActionsForPolarisationImages.m -mtune=k8 -auxbase-strip
./amd64--linux-gcc/Spectrum16/normal/ActionsForPolarisationImages.o -g -O3
-Wall -Wwrite-strings -Wno-import -Wno-strict-aliasing -std=gnu99 -version
-fomit-frame-pointer -o ActionsForPolarisationImages.s
GNU Objective-C version 4.1.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.1.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2a5baba627e461e0ff2f208acc682c91
/home/icicle/ART/Libs/Image/ActionsForPolarisationImages.m: In function
‘-[ArnARTRAWLinearPolarisingFilter performOn::]’:
/home/icicle/ART/Libs/Image/ActionsForPolarisationImages.m:220: warning:
‘-beginAction::’ not found in protocol(s)
/home/icicle/ART/Libs/Image/ActionsForPolarisationImages.m:221: warning:
‘-endAction’ not found in protocol(s)
/home/icicle/ART/Libs/Image/ActionsForPolarisationImages.m: In function
‘-[ArnARTRAWPolarisationFalseColour performOn::]’:
/home/icicle/ART/Libs/Image/ActionsForPolarisationImages.m:469: warning:
‘-beginAction::’ not found in protocol(s)
/home/icicle/ART/Libs/Image/ActionsForPolarisationImages.m:470: warning:
‘-endAction’ not found in protocol(s)
 as -V -Qy -o
./amd64--linux-gcc/Spectrum16/normal/ActionsForPolarisationImages.o
ActionsForPolarisationImages.s
GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD version
2.16.91.0.2 20050720 (SuSE Linux)


- (void) performOn
: (struct ArNodeTable *) nodeStack
: (const ArExecEnv *) ee
{
[ (*ee).reporter beginAction : 1 : "(polarising filter: non-polarising "
 "engine, skipped)" ];
[ (*ee).reporter endAction ];
}

The "not found in protocol(s)" warnings are bogus, since (*ee).reporter, which
is of type "id ", conforms to the ArpReporter protocol which
defines the methods beginAction and endAction.

If I change

- (void) performOn
: (struct ArNodeTable *) nodeStack
: (const ArExecEnv *) ee

to

- (void) performOn
: (struct ArNodeTable *) nodeStack
: (ArExecEnv *) ee

the warnings vanish.


-- 
   Summary: objc bogus warning when using const
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: icicle at cg dot tuwien dot ac dot at
 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=31056

[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"

[JBoncek at Hunter dot Com]

--- Comment #10 from JBoncek at Hunter dot Com  2007-03-06 14:44 ---
This is just a nuisance at the end of a .c or .cpp file.  It is, however, a
serious error that should always be notified at the end of an included (header)
file.


-- 


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

[Bug tree-optimization/21596] [4.0/4.1/4.2/4.3 Regression] extra temporaries when using global register variables

[amacleod at redhat dot com]

--- Comment #9 from amacleod at redhat dot com  2007-03-06 15:01 ---
actually, mainline isn't working either.  A closer examination shows the code
generated has an extra offset of -4 in the compare that shouldn't be there.
This patch triggers a bug in rtl's fwprop pass. 


-- 


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

[Bug middle-end/24639] [meta-bug] bug to track all uninit variable issues

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2007-03-06 15:09 ---
Another one.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
  BugsThisDependsOn||18501


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-03-06 15:16 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2007-03-06 15:16:17
   date||


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

[Bug middle-end/31058] New: array overflow warning due to incorrect loop unrolling

[mueller at gcc dot gnu dot org]

building this testcase with -O2 -march=athlon -Wall -fprefetch-loop-arrays
gives:

warning: array subscript is above array bounds
[...]

which, according to VRP, seems to be valid. 

testcase is:

=== Cut ===
struct real_value
{
  unsigned int cl:2;
  unsigned int decimal:1;
  unsigned long sig[5];
};
unsigned int uexp;

static void
clear_significand_below (struct real_value *r, unsigned int n)
{
  int i, w = n / 32;
  for (i = 0; i < w; ++i)
r->sig[i] = 0;
}
void
do_fix_trunc (struct real_value *r)
{
  if (uexp < 160)
clear_significand_below (r, 160 - uexp);
}
=== Cut ===


-- 
   Summary: array overflow warning due to incorrect loop unrolling
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org


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

[Bug middle-end/31058] array overflow warning due to incorrect loop unrolling

[mueller at gcc dot gnu dot org]

--- Comment #1 from mueller at gcc dot gnu dot org  2007-03-06 15:22 ---
after prefetch-loop-arrays run, vrp2 looks like this: 

:;
  D.1885_87 = &r_4(D)->sig[i_13];
  D.1886_88 = D.1885_87 + 160B;
  __builtin_prefetch (D.1886_88, 1);
  r_4(D)->sig[i_13] = 0;
  i_8 = i_13 + 1;
  i_26 = i_8;
  r_4(D)->sig[i_26] = 0;
  i_28 = i_26 + 1;
  i_30 = i_28;
  r_4(D)->sig[i_30] = 0;
  i_32 = i_30 + 1;
  i_34 = i_32;
  r_4(D)->sig[i_34] = 0;
  i_36 = i_34 + 1;
  i_38 = i_36;
  r_4(D)->sig[i_38] = 0;
  i_40 = i_38 + 1;
  i_42 = i_40;
  r_4(D)->sig[i_42] = 0;
  i_44 = i_42 + 1;
  i_46 = i_44;
  r_4(D)->sig[i_46] = 0;
  i_48 = i_46 + 1;
  i_50 = i_48;
  r_4(D)->sig[i_50] = 0;
  i_52 = i_50 + 1;
  i_54 = i_52;
  r_4(D)->sig[i_54] = 0;
  i_56 = i_54 + 1;
  i_58 = i_56;
  r_4(D)->sig[i_58] = 0;
  i_60 = i_58 + 1;
  i_62 = i_60;
  r_4(D)->sig[i_62] = 0;
  i_64 = i_62 + 1;
  i_66 = i_64;
  r_4(D)->sig[i_66] = 0;
  i_68 = i_66 + 1;
  i_70 = i_68;
  r_4(D)->sig[i_70] = 0;
  i_72 = i_70 + 1;
  i_74 = i_72;
  r_4(D)->sig[i_74] = 0;
  i_76 = i_74 + 1;
  i_78 = i_76;
  r_4(D)->sig[i_78] = 0;
[...]

and so on. since it definitely writes more than 5 ints, I don't see how it
should *not* overflow the array. 


-- 


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

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

[hjl at lucon dot org]

--- Comment #43 from hjl at lucon dot org  2007-03-06 15:27 ---
(In reply to comment #42)
> Created an attachment (id=13152)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13152&action=view) [edit]
> Testcase (generated assembly files from gcc 4.1.1)
> 

I got

bash-3.1$ readelf -S -N  fzotl.o | grep ZN10otl_streamlsEPKc
  [257] .gnu.linkonce.t._ZN10otl_streamlsEPKc
  [258] .rel.gnu.linkonce.t._ZN10otl_streamlsEPKc
bash-3.1$ readelf -S -N fzconfig.o  | grep ZN10otl_streamlsEPKc
  [338] .gnu.linkonce.t._ZN10otl_streamlsEPKc
  [339] .rel.gnu.linkonce.t._ZN10otl_streamlsEPKc
  [340] .gnu.linkonce.r._ZN10otl_streamlsEPKc
  [341] .rel.gnu.linkonce.r._ZN10otl_streamlsEPKc
bash-3.1$ readelf -g fzotl.o fzconfig.o

File: fzotl.o

There are no section groups in this file.

File: fzconfig.o

There are no section groups in this file.
bash-3.1$ 

It means your gcc 4.1.1 was built with a very old binutils and it doesn't
support COMDAT group, which is needed to fix this bug. You have 2
choices:

1. Rebuild gcc 4.1.1 with the current Linux binutils.
2. Use a different Linux distribution with a proper gcc 4.1. FC6 is
OK.


-- 


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

[Bug middle-end/31058] array overflow warning due to incorrect loop unrolling

[rakdver at gcc dot gnu dot org]

--- Comment #2 from rakdver at gcc dot gnu dot org  2007-03-06 15:31 ---
(In reply to comment #1)
> and so on. since it definitely writes more than 5 ints, I don't see how it
> should *not* overflow the array. 

since the body of the loop is never entered.


-- 


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

[Bug bootstrap/31020] cannot write in

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2007-03-06 15:50 ---
Subject: Bug 31020

Author: jsm28
Date: Tue Mar  6 15:50:28 2007
New Revision: 122620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122620
Log:
fixincludes:
* mkheaders.in: Fix headers for each multilib required.

gcc:
PR bootstrap/31020
* configure.ac (CROSS_SYSTEM_HEADER_DIR, build_system_header_dir):
Define using $${sysroot_headers_suffix}.
* configure: Regenerate.
* cppdefault.c (cpp_include_defaults): Make FIXED_INCLUDE_DIR a
multilib-suffixed directory if SYSROOT_HEADERS_SUFFIX_SPEC
defined.
* doc/invoke.texi (-print-sysroot-headers-suffix): Document.
* gcc.c (print_sysroot_headers_suffix): New.
(option_map): Include --print-sysroot-headers-suffix.
(display_help): Mention -print-sysroot-headers-suffix.
(process_command): Handle -print-sysroot-headers-suffix.
(do_spec_1): Append multilib directory to include-fixed path if
sysroot suffixes in use.
(main): Handle -print-sysroot-headers-suffix.
* Makefile.in (start.encap): Don't depend on xlimits.h
(xlimits.h): Remove.
(stmp-int-hdrs): Don't depend on xlimits.h.  Inline generation of
limits.h for each multilib in fixinc_list.
(fixinc_list, s-fixinc_list): New.
(stmp-fixinc): Depend on fixinc_list.  If not copying headers,
generate them for each multilib in fixinc_list.
(stmp-fixproto): Use include-fixed.  Run fixproto for each
multilib in fixinc_list.
(mostlyclean): Don't remove xlimits.h.
(clean): Remove include-fixed.
(real-install-headers-tar, real-install-headers-cpio,
real-install-headers-cp): Don't copy include, only include-fixed.
(install-mkheaders): Depend on fixinc_list.  Don't depend on
xlimits.h.  Save limits.h files for each multilib in fixinc_list.
Always save mkinstalldirs.  Preserve ${sysroot_headers_suffix} in
SYSTEM_HEADER_DIR setting in mkheaders.conf.


Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/mkheaders.in
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/cppdefault.c
trunk/gcc/doc/invoke.texi
trunk/gcc/gcc.c


-- 


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #6 from sgk at troutmask dot apl dot washington dot edu  
2007-03-06 15:53 ---
Subject: Re:  Bad IOSTAT values when readings NAMELISTs past EOF

On Tue, Mar 06, 2007 at 08:20:23AM -, anlauf at gmx dot de wrote:
> 
> 
> --- Comment #3 from anlauf at gmx dot de  2007-03-06 08:20 ---
> (In reply to comment #2)
> > The value 5008 is listed in libgfortran.h as ERROR_ENDFILE.  The
> > -1 corresponds to ERROR_END.  So, the return value of 5008 is 
> > telling you that you are trying to (initiate a?) read beyond
> > the end of the file, which you admit to doing.
> 
> I actually do not want to read beyond the end of file,
> I want gfortran to stay at the end of the file when trying to
> read the next record or namelist.
> 
> All other compilers I have checked (xlf, ifort 7.x-9.x, g95)
> stay at the end of file.  I find their behavior consistent
> with the F2003 standard, section 9.10.4:
> 
> Execution of an input/output statement containing the IOSTAT=
> specifier causes the scalar-int-variable in the IOSTAT= specifier
> to become defined with
> 
> (3) The processor-dependent negative integer value of the constant
> IOSTAT_END (13.8.2.5) if an end-of-file condition occurs and no
> error condition occurs, or (...)
> 
> > AFAIK, the IOSTAT values aren't documented in gfortran.texi.
> > Someday, someone will get around to documenting them.
> 
> The standard separates end-of-file, end-of-record, and
> error conditions.  I don't think that EOF is necessarily
> an error condition.  It would be nice if gfortran would
> conform with these other compilers.

For whatever reason, you are hitting (2).

(2) A processor-dependent positive integer value if an error condition
occurs.

At a guess, you get a -1 if you start a read from within the
the file, and you hit the EOF.  Once the EOF is hit, the file
is probably positioned at a point beyond the EOF, the next
attempt of a read is considered an error condition, so the
5008 is return.

I saw your other email about BACKSPACE.  I don't know what the
expected behavior is with BACKSPACE and a file position that is
at or exceeds the EOF marker.  At a guess and knowing the vagueness
of the Standard, this is probably processor-dependent.  I think
you're getting hit by 9.10.2(4) for F2003:

(4) If the file specified in the input statement is an external
record file, it is positioned after the endfile record.

and BACKSPACE isn't doing its job with respect to Note 9.54.

This is an area that Jerry knows.  Perhaps, he has an opinion.


-- 


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

[Bug middle-end/30744] [4.2/4.3 Regression] ICE in compare_values, at tree-vrp.c:466

[sayle at gcc dot gnu dot org]

--- Comment #3 from sayle at gcc dot gnu dot org  2007-03-06 16:30 ---
Subject: Bug 30744

Author: sayle
Date: Tue Mar  6 16:30:12 2007
New Revision: 122622

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

PR middle-end/30744
* fold-const.c (fold_binary) : Enforce type consistency
when transforming ~X op C to X op' ~C.

* gcc.dg/pr30744-1.c: New test case.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr30744-1.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/fold-const.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/30744] [4.2/4.3 Regression] ICE in compare_values, at tree-vrp.c:466

[roger at eyesopen dot com]

--- Comment #4 from roger at eyesopen dot com  2007-03-06 16:32 ---
This should now be fixed on both mainline and the 4.2 release branch.


-- 

roger at eyesopen dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.2.0 4.3.0 |
  Known to work|4.1.1   |4.1.1 4.2.0 4.3.0
 Resolution||FIXED


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

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

[michael dot klein at fazi dot de]

--- Comment #44 from michael dot klein at fazi dot de  2007-03-06 16:33 
---
(In reply to comment #43)
> It means your gcc 4.1.1 was built with a very old binutils and it doesn't
> support COMDAT group

Yes, this gcc was build with binutils 2.15 from Debian Sarge.

Thanks


-- 


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

[Bug c++/31047] GCC 4.1.1 has template bug

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-03-06 17:10 ---
(In reply to comment #3)
> No, this is a bug, 2nd stage name-lookup should find foo(const int&) as var is
> dependent on the template parameter T (14.6/8, /9).
> But I bet we have a dup for this.

14.6.4.2/1 says this is invalid code.
For a function call that depends on a template parameter, if the function is an
unqualified-id but not a template-id, the candiate functions are found using
the usual lookup rules (3.4.1, 3.4.2) except that:


Paraphasing since I don't want to type it all in
* non argument dependent lookup (3.4.1: template definition context
* argument dependent lookup (3.4.2):  template definition context and template
instation context

Since the type is a fundamental type, argument dependent lookup does not apply,
therefor this is not a bug.


-- 

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

[Bug fortran/31059] New: Detect nonconforming assignment of allocatable arrays

[vivekrao4 at yahoo dot com]

Gfortran does not report an error if an allocatable array is set to an array of
larger size, for example in the code below.

program xalloc_words
! shows error with nonconformant assignment of an allocatable array
! not caught by most compilers
character (len=1), allocatable :: w(:)
integer, allocatable :: ivec(:)
integer :: jvec(2)
allocate (w(2),ivec(2))
w = ["1","2","3"]
write (*,*) "size(w)=",size(w),"w =",w
ivec = [1,2,3]
write (*,*) "size(ivec)=",size(w),"ivec =",ivec
! error in line below IS caught if not commented
! jvec = [1,2,3]
end program xalloc_words

U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared
--enable-libgomp
Thread model: win32
gcc version 4.3.0 20061021 (experimental)

U:\vrao\fortran>gfortran -W -Wall -pedantic-errors  -std=f2003  -fbounds-check
-Werror xalloc_words.f90
 In file xalloc_words.f90:6

integer :: jvec(2)
 1
Warning: Unused variable jvec declared at (1)

U:\vrao\fortran>a
 size(w)=   2 w =12
 size(ivec)=   2 ivec =   1   2


Vivek Rao


-- 
   Summary: Detect nonconforming assignment of allocatable arrays
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com


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

[Bug ada/31060] New: Error compiling expression with unary minus

[oliver dot kellogg at eads dot com]

-- file: error_compiling_unary_minus.adb

procedure Error_Compiling_Unary_Minus (X : Float) is
   No_Problem : Float := -1.0 * X;
   ERROR  : Float := X * -1.0;  -- this is line 3
begin
   null;
end Error_Compiling_Unary_Minus;

-- end of file

$ gcc -v -c error_compiling_unary_minus.adb
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../SOURCES/gcc-4.2-20061128/configure
--prefix=/opt/gnat/fsf --enable-languages=c,c++,ada,java
Thread model: posix
gcc version 4.2.0 20061128 (prerelease)
 /opt/gnat/fsf/libexec/gcc/i686-pc-linux-gnu/4.2.0/gnat1 -quiet -dumpbase
error_compiling_unary_minus.adb -mtune=generic error_compiling_unary_minus.adb
-o /tmp/cco4ZZo7.s
error_compiling_unary_minus.adb:3:29: missing operand


-- 
   Summary: Error compiling expression with unary minus
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver dot kellogg at eads dot com
  GCC host triplet: same as target
GCC target triplet: i686-pc-linux-gnu


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

[Bug libstdc++/28080] header dependencies

[paolo at gcc dot gnu dot org]

--- Comment #22 from paolo at gcc dot gnu dot org  2007-03-06 17:43 ---
Subject: Bug 28080

Author: paolo
Date: Tue Mar  6 17:43:27 2007
New Revision: 122628

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122628
Log:
2007-03-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/28080 (partial)
* include/bits/stl_algobase.h: Do not include .
* src/localename.cc: Do it here.
* src/ctype.cc: Likewise.
* include/ext/pb_ds/detail/map_debug_base.hpp: Likewise.
* include/ext/pb_ds/exception.hpp: Likewise.
* include/ext/pb_ds/list_update_policy.hpp: Likewise.
* include/bits/stl_algo.h: Likewise.
* include/tr1/random: Likewise.
* testsuite/util/testsuite_hooks.cc: Likewise.
* testsuite/util/testsuite_abi_check.cc: Likewise.
* testsuite/util/testsuite_abi.cc: Likewise.
* testsuite/util/performance/assoc/timing/
tree_order_statistics_test.hpp: Likewise.
* config/locale/darwin/ctype_members.cc: Likewise.
* config/locale/gnu/c++locale_internal.h: Likewise.
* config/locale/generic/ctype_members.cc: Likewise.
* config/locale/generic/time_members.cc: Likewise.

* include/ext/pb_ds/detail/resize_policy/
hash_load_check_resize_trigger_imp.hpp: Qualify abort.
* testsuite/util/performance/assoc/timing/
multimap_find_test.hpp: Likewise.
* include/std/valarray: Do include .
* include/tr1/hashtable: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/locale/darwin/ctype_members.cc
trunk/libstdc++-v3/config/locale/generic/ctype_members.cc
trunk/libstdc++-v3/config/locale/generic/time_members.cc
trunk/libstdc++-v3/config/locale/gnu/c++locale_internal.h
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/bits/stl_algobase.h
trunk/libstdc++-v3/include/ext/pb_ds/detail/map_debug_base.hpp
   
trunk/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp
trunk/libstdc++-v3/include/ext/pb_ds/exception.hpp
trunk/libstdc++-v3/include/ext/pb_ds/list_update_policy.hpp
trunk/libstdc++-v3/include/std/valarray
trunk/libstdc++-v3/include/tr1/hashtable
trunk/libstdc++-v3/include/tr1/random
trunk/libstdc++-v3/src/ctype.cc
trunk/libstdc++-v3/src/localename.cc
   
trunk/libstdc++-v3/testsuite/util/performance/assoc/timing/multimap_find_test.hpp
   
trunk/libstdc++-v3/testsuite/util/performance/assoc/timing/tree_order_statistics_test.hpp
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
trunk/libstdc++-v3/testsuite/util/testsuite_abi_check.cc
trunk/libstdc++-v3/testsuite/util/testsuite_hooks.cc


-- 


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

[Bug ada/31060] Error compiling expression with unary minus

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-03-06 17:52 ---
And this is actually invalid Ada, see PR 19539.

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


-- 

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

[Bug ada/19539] missing operand: B * -A

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-03-06 17:52 ---
*** Bug 31060 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||oliver dot kellogg at eads
   ||dot com


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

[Bug target/30848] [4.1/4.2/4.3 regression] ICE with invalid constraint in asm statement

[rth at gcc dot gnu dot org]

-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-03-06 17:57:51
   date||


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

[Bug libstdc++/31061] New: error with '-D_GLIBCXX_DEBUG'

[ulf at linuxmail dot org]

Compiled this program:
http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html
without -D_GLIBCXX_DEBUG the program works ok, but with -D_GLIBCXX_DEBUG I get 
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/vector:199:
error: attempt to subscript container with out-of-bounds index 20, but 
container only holds 20 elements.

gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)


-- 
   Summary: error with '-D_GLIBCXX_DEBUG'
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ulf at linuxmail dot org


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

[Bug libstdc++/31061] error with '-D_GLIBCXX_DEBUG'

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-03-06 18:14 ---
I actually think this is a bug in the user code. the error message is correct
in that the code is acessing one past the end.


-- 


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

[Bug fortran/31053] print file name when file cannot be opened for writing

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-03-06 19:32 ---
Yes, this would be useful.

Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-03-06 19:32:57
   date||


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

[Bug bootstrap/31020] [4.3 Regression] cannot write in

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|cannot write in |[4.3 Regression] cannot
   |   |
   Target Milestone|--- |4.3.0


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

[Bug libstdc++/31061] error with '-D_GLIBCXX_DEBUG'

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-03-06 20:17 ---
Yes, there isn't much to add, the whole point of debug-mode is catching this
kind of bug: in is_strike the vector rolls is subscripted at index 20.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/31061] error with '-D_GLIBCXX_DEBUG'

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-03-06 20:37 ---
Sorry, I misread the backtrace: the problem happens in accumulate, called by
frame_score(), called by score(). 


-- 


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[anlauf at gmx dot de]

--- Comment #7 from anlauf at gmx dot de  2007-03-06 21:51 ---
Created an attachment (id=13153)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13153&action=view)
Revised demo

Revised demo.  New namelist for this demo follows.

At some place, the input read gets garbled with gfortran,
see the comment before the print statement in "position_nml".
Removing a few lines in the main program will hide this bug.
Somehow the cycle REWIND/READ/BACKSPACE/(READ) confuses the runtime.


-- 

anlauf at gmx dot de changed:

   What|Removed |Added

  Attachment #13148|0   |1
is obsolete||


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[anlauf at gmx dot de]

--- Comment #8 from anlauf at gmx dot de  2007-03-06 21:52 ---
Created an attachment (id=13154)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13154&action=view)
Namelist


-- 


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

[Bug fortran/30950] intrinsic: CPU_TIME

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2007-03-06 21:57 ---
Subject: Bug 30950

Author: dfranke
Date: Tue Mar  6 21:57:02 2007
New Revision: 122640

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122640
Log:
2007-03-06  Daniel Franke  <[EMAIL PROTECTED]>

PR documentation/30950
* intrinsic.texi (AND, CPU_TIME): Fix dummy argument names.
(FREE): Fix call syntax.


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


-- 


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

[Bug fortran/30950] intrinsic: CPU_TIME

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2007-03-06 21:57 ---
Subject: Bug 30950

Author: dfranke
Date: Tue Mar  6 21:57:09 2007
New Revision: 122641

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122641
Log:
2007-03-06  Daniel Franke  <[EMAIL PROTECTED]>

PR documentation/30950
* intrinsic.texi (AND, CPU_TIME): Fix dummy argument names.
(FREE): Fix call syntax.


Modified:
branches/gcc-4_2-branch/gcc/fortran/ChangeLog
branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi


-- 


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

[Bug fortran/30950] intrinsic: CPU_TIME

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2007-03-06 21:58 ---
Fixed in 4.2 and trunk.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[anlauf at gmx dot de]

--- Comment #9 from anlauf at gmx dot de  2007-03-06 22:00 ---
(In reply to comment #8)

In the new example, when I comment out the BACKSPACE
in "position_nml" for ios<0 (EOF condition), the garbled
output goes away.  But in the large program (where this
was extracted) this does not help; it dies later.
(See comment #5).


-- 


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

[Bug c++/31063] New: Spurrious/missing warn_unused_result warnings affected by presence/absense of copy constructor

[fletcherdunn at yahoo dot com]

// Illustrates some bugs related to __attribute__((warn_unused_result)).

struct Vector {
float x, y, z;
inline Vector() {}
inline Vector(float _x,float _y,float _z) : x(_x), y(_y), z(_z) {}

// BUG: Toggling the presence of a copy constructor (doesn't matter
which
// of the ones below you use) will affect the generation of the
warnings.
inline Vector(const Vector &a) { x = a.x; y = a.y; z = a.z; }
//  inline Vector(const Vector &a) : x(a.x), y(a.y), z(a.z) {}

inline Vector operator-(const Vector &a) const
__attribute__((warn_unused_result)) {
return Vector(x - a.x, y - a.y, z - a.z );
}
};

struct Box {
Vector min, max;

// BUG: generates spurrious warning about not using result from
operator-.
// If you remove the copy constructor, the warning goes away
inline Vector size() const { return max - min; }
};

void foo() {
Vector a, b;

// BUG: this *should* generate a warning, but you will only get a
warning
// if you have the copy constructor.  If you remove the copy
constructor,
// the warning goes away
a-b;
}

//
// Output with copy constructor defined:
//
//   $ /c/usr/local/cell/host-win32/ppu/ppu-lv2/bin/gcc -v -save-temps -c -Wall
warn_unused_result_bug_2.cpp
//   Using built-in specs.
//   Target: ppu-lv2
//   Configured with: /export/fukuoka/ps3-svn/toolchain/trunk/gcc/configure
--target=ppu-lv2 --host=i386-pc-mingw32msvc --build=i686-pc-linux-gnu
--prefix=/usr/local/cell/host-win32/ppu
--with-sysroot=/usr/local/cell/target/ppu --with-headers=yes --disable-threads
--disable-shared --disable-hosted-libstdcxx
//   Thread model: single
//   gcc version 4.0.2 (CELL 4.1.19, $Rev: 1341 $)
///usr/local/cell/host-win32/ppu/libexec/gcc/ppu-lv2/4.0.2/cc1plus.exe -E
-quiet -v -iprefix
c:\usr\local\cell\host-win32\ppu\ppu-lv2\bin\../lib/gcc/ppu-lv2/4.0.2/
-D__PPU__ -D__CELLOS_LV2__ warn_unused_result_bug_2.cpp -mabi=altivec -maltivec
-mstrict-align -fstrict-aligned -mvrsave=no -mtraceback=none -Wall
-fpch-preprocess -fno-threadsafe-statics -o warn_unused_result_bug_2.ii
//   ignoring nonexistent directory
"c:/usr/local/cell/host-win32/ppu/ppu-lv2/bin/../lib/gcc/ppu-lv2/4.0.2/include"
//   #include "..." search starts here:
//   #include <...> search starts here:
///usr/local/cell/host-win32/ppu/lib/gcc/ppu-lv2/4.0.2/include
///usr/local/cell/target/ppu/include
///usr/local/cell/target/ppu/include/sys
///usr/local/cell/target/ppu/../common/include
//   End of search list.
///usr/local/cell/host-win32/ppu/libexec/gcc/ppu-lv2/4.0.2/cc1plus.exe
-fpreprocessed warn_unused_result_bug_2.ii -mabi=altivec -maltivec
-mstrict-align -fstrict-aligned -mvrsave=no -mtraceback=none -quiet -dumpbase
warn_unused_result_bug_2.cpp -auxbase warn_unused_result_bug_2 -Wall -version
-fno-threadsafe-statics -o warn_unused_result_bug_2.s
//   GNU C++ version 4.0.2 (CELL 4.1.19, $Rev: 1341 $) (ppu-lv2)
//   compiled by GNU C version 4.0.2 (CELL 4.1.19, $Rev: 1341 $).
//   GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130941
//   warn_unused_result_bug_2.cpp: In member function 'Vector Box::size()
const':
//   warn_unused_result_bug_2.cpp:23: warning: ignoring return value of 'Vector
Vector::operator-(const Vector&) const', declared with attribute
warn_unused_result
//   warn_unused_result_bug_2.cpp: In function 'void foo()':
//   warn_unused_result_bug_2.cpp:32: warning: ignoring return value of 'Vector
Vector::operator-(const Vector&) const', declared with attribute
warn_unused_result
//
// If you comment out the copy constructor, the warnings do not appear.
// Note that I produced this with the Playstation (CELL) version of GCC under
// MinGW/MSys, but I don't think this is a platform specific issues.
//
// gccc --version produces this:
// gcc.exe (GCC) 4.0.2 (CELL 4.1.19, $Rev: 1341 $)
// Copyright (C) 2005 Free Software Foundation, Inc.
// This is free software; see the source for copying conditions.  There is NO
// warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
//
// This might be a dup of either of these issues:
// http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27370
// http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
//
// Cheers,
// fletcherdunn --at-- yahoo.com
//


-- 
   Summary: Spurrious/missing warn_unused_result warnings affected
by presence/absense of copy constructor
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fletcherdunn at yahoo dot com


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

[Bug c++/31063] Spurrious/missing warn_unused_result warnings affected by presence/absense of copy constructor

[fletcherdunn at yahoo dot com]

--- Comment #1 from fletcherdunn at yahoo dot com  2007-03-06 22:26 ---
Created an attachment (id=13155)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13155&action=view)
Repro code with the proper line breaks

Line breaks got messed up when pasting into bug description.


-- 


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

[Bug c++/31063] Spurrious/missing warn_unused_result warnings affected by presence/absense of copy constructor

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-03-06 22:40 ---
// If you comment out the copy constructor, the warnings do not appear.
// Note that I produced this with the Playstation (CELL) version of GCC under
// MinGW/MSys, but I don't think this is a platform specific issues.

You should have filed this first with Sony.  We (Sony) do change the bug
reporting address to the correct one for the PS3 toolchain.

Thanks,
Andrew Pinski
Sony Compiler Engineer


-- 


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

[Bug c++/30797] Failure to build Cinelerra 2.1

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-03-07 00:05 ---
Closing as fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again

[geoffk at gcc dot gnu dot org]

--- Comment #2 from geoffk at gcc dot gnu dot org  2007-03-07 00:16 ---
The change to gccspec.c was made by Franz Sirl on 2001-06-16, revision 43421. 
The mail on gcc-patches is at
.  There's further
discussion at .  I
think it's relying on the property that the GNU runtime is (always?) linked
with the dynamic libgcc.


-- 


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

[Bug objc/31013] [4.3 Regression] objc PCH is broken on powerpc-darwin again

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-03-07 00:26 ---
I should mention that with the GNU runtime, we want the shared libgcc for
exceptions so any patch that breaks the GNU runtime linking with the shared
libgcc should be rejected.


-- 


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

[Bug tree-optimization/30735] [4.3 Regression] 50% slow down due to mem-ssa merge

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|50% slow down due to mem-ssa|[4.3 Regression] 50% slow
   |merge   |down due to mem-ssa merge
   Target Milestone|--- |4.3.0


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

[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##

[ahs3 at fc dot hp dot com]

--- Comment #7 from ahs3 at fc dot hp dot com  2007-03-07 00:49 ---
Is this code snippet related to this bug, or a new one entirely?


#define LABEL(a, b) a##b##:

int main () {
LABEL(all,done)
   return 0;
}


If I compile it:

$ gcc -o foo.o foo.c
foo.c:4:1: error: pasting "alldone" and ":" does not give a valid preprocessing
token

However, if I use -E first, and compile the result, the snippet compiles
properly,


-- 

ahs3 at fc dot hp dot com changed:

   What|Removed |Added

 CC||ahs3 at fc dot hp dot com


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

[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-03-07 00:58 ---
(In reply to comment #7)
> Is this code snippet related to this bug, or a new one entirely?
Actually the error message is fully correct in that case.

> $ gcc -o foo.o foo.c
> foo.c:4:1: error: pasting "alldone" and ":" does not give a valid 
> preprocessing
> token
> 
> However, if I use -E first, and compile the result, the snippet compiles
> properly,

I don't, I get an error even with -E on the mainline, 3.3.5, and 4.0.2:
gcc t.c -E -o t.i
t.c:4:1: error: pasting "alldone" and ":" does not give a valid preprocessing
token


-- 


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

[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining

[geoffk at gcc dot gnu dot org]

--- Comment #9 from geoffk at gcc dot gnu dot org  2007-03-07 01:38 ---
Confirmed.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-03-07 01:38:11
   date||


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

[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining

[geoffk at gcc dot gnu dot org]

--- Comment #10 from geoffk at gcc dot gnu dot org  2007-03-07 01:52 ---
c_types_compatible_p says the two types are compatible, but it never gets
called.  I don't think the back-end is involved.


-- 


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

[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining

[geoffk at gcc dot gnu dot org]

--- Comment #11 from geoffk at gcc dot gnu dot org  2007-03-07 02:01 ---
No, I take it back, the back-end is involved.


-- 


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

[Bug c++/31064] New: Internal Compiler Error when using operator& from template function

[larsand at gmail dot com]

--- Output from "g++ -v -save-temps ice.cc"-:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE ice.cc
-mtune=generic -fpch-preprocess -o ice.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i486-linux-gnu
 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.2/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed ice.ii -quiet
-dumpbase ice.cc -mtune=generic -auxbase ice -version -fstack-protector
-fstack-protector -o ice.s
GNU C++ version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
(i486-linux-gnu)
compiled by GNU C version 4.1.2 20060928 (prerelease) (Ubuntu
4.1.1-13ubuntu5).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129273
Compiler executable checksum: aca0f1fd158b16191964d93038d65dbf
ice.cc: In member function ‘void ICE::aj()’:
ice.cc:27: internal compiler error: in value_dependent_expression_p, at
cp/pt.c:12550
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/cc3765Eq.out file, please attach this to
your bugreport.


--- /tmp/cc3765Eq.out -:

// /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed ice.ii -quiet
-dumpbase ice.cc -mtune=generic 
-auxbase ice -version -fstack-protector -fstack-protector -o - -frandom-seed=0
# 1 "ice.cc"
# 1 ""
# 1 ""
# 1 "ice.cc"

class Dummy
{
public:
int operator&(signed int &) { return 4; }

int test(signed int test) { return 4; }

};


class ICE
{
public:
template 
void aj(void)
{
signed int kalle = 9;





int size = Dummy() & kalle;


char buffer[size];
}
};



--- Original code ---:

class Dummy
{
public:
int operator&(signed int &) { return 4; } 

int test(signed int test) { return 4; }  

};


class ICE
{
public:
template 
void aj(void)
{
signed int kalle = 9;
#if 0
// this compiles fine...
int size = Dummy().operator&(kalle);
#else
// this generates an ICE...
int size = Dummy() & kalle;
#endif
// if commented out, no ICE...
char buffer[size];
}
};


Cheers,

Lars


-- 
   Summary: Internal Compiler Error when using operator& from
template function
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: larsand at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2007-03-07 03:37 
---
Replying to comment #6.  I am forming an opinion. Section 9.7 of the F2003
standard states:

  "Backspacing over records written using list-directed or namelist formatting
is prohibited."

This implies to me that one should not mix BACKSPACE with a namelist file. 
However, I want to study the demo program a bit.  This might be one of those
"correct behavior, outside the standard" problems.

Generally, reading past the last record gives an EOF and trying to read again
is an error. The concept of a "record" with a namelist file does not seem to be
compatible to me though.

I will respond further after I have a chance to explore this a bit more.


-- 


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

[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu

[b33fc0d3 at gmail dot com]

--- Comment #2 from b33fc0d3 at gmail dot com  2007-03-07 03:37 ---
I am having the exact same problem.

I've tried a few things, tried building in a stable chroot with glibc-2.4
(since my box is mainly unstable with glibc-2.5 and hashstyle) but got the
exact same error. gcc-4.2 snapshots all the way to 20070305 build fine on both
boxes.

Does anyone have any ideas?


-- 

b33fc0d3 at gmail dot com changed:

   What|Removed |Added

 CC||b33fc0d3 at gmail dot com


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-03-07 03:38 
---
I will take this one, but I am not confirming its a bug yet.


-- 

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-03-07 03:38:45
   date||


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-03-07 04:45 
---
The garbled text is because gfortran does not default initialize variable as
some compilers do.  The 'line' variable is not getting read because gfortran is
getting an error on the read, so the it is not set to anything.  Put a: line=""
at the top of the subroutine to get around that.

After this you can see that IOS is set to -1, so 'line' is not read.

I am now going to study the REWIND and BACKSPACE and see what we should be
doing differently if anything. 


-- 


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

[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2007-03-07 06:40 
---
AFAICT A backspace is not allowed for namelist files according to 9.7.1

I interpret this to mean this is invalid code.

Further, Note 9.54 states that if the preceding record read is the EOF record,
the BACKSPACE would position the file to "before" the EOF.  You can think of
this as in between the last record and the EOF record.  So subsequent reads
will again read the EOF record.  From the demo program, you can see the
repeated values of ios=-1, or the EOF condition returned by gfortran.  So I
believe the gfortran behavior is correct.

Regardless, I do think REWIND should clear the EOF condition for namelist and I
don't think it is.  I confirm this as a bug.

I am working on it.


-- 


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

[Bug fortran/31053] print file name when file cannot be opened for writing

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-03-07 07:17 ---
> gcc version 4.3.0 20061021 (experimental)

I believe this has been fixed already by PR30005 since December 5.

At least my gfortran prints:

At line 6 of file foo.f90
Fortran runtime error: Permission denied trying to open file 'junk.csv'


-- 


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

[Bug fortran/30802] out of bounds error in allocatable array not picked up with -fbounds-check

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-03-07 07:23 ---
*** Bug 31059 has been marked as a duplicate of this bug. ***


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vivekrao4 at yahoo dot com


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

[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-03-07 07:23 ---
Confirmed, gfortran should print something like:
"Rank 1 of array operand has extent 2 instead of 3"



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


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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