[Bug fortran/36894] question on gfortran character*(*)

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-07-22 06:48 ---
Both
   character*(*) foo
   character(*) foo

are supported by gfortran. At the moment I cannot imagine a program which works
with the latter and fails with the former. If you have a complete (short!)
example, we could look into the problem, though I would not be surprised if the
code is simply invalid Fortran. Note that using either of the two lines is only
valid for dummy arguments of subroutines/functions (though g77 accepts it also
for local variables).

Thus can you provide us a complete example?

For Fortran programming questions, like Daniel, I would suggest to write to the
comp.lang.fortran newsgroup (which is also available via HTTP at
http://groups.google.com/group/comp.lang.fortran/ ).


-- 


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

[Bug fortran/36895] New: Namelist writting to internal files: Control characters wrong?

[burnus at gcc dot gnu dot org]

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/543dbbd5a3cb5fce

Jerry, could you check whether Richard Maine's concerns are correct or not? NAG
f95 and g95 write everything in one line; g95 has also a trailing comma, NAG
does not. (ifort 11beta and sunf95 don't support nml for internal files, yet.)

For external files, g95 prints a newline before /. (ifort and sunf95 print
also in several lines, but without trailing comma.)


- Richard Maine writes: --

 C:\gcc_mingw64a\clf\nakelistnakelist
  STUFF
  N=666,  /

That output showed up in the posting as being on two lines (at least in
my newsreader). I hope that was an artifact of the newsgroup posting. If
the compiler actually does something like put control characters (such
as cr and/or lf) in the internal file, then that would be a bug.

Also, the comma looks wrong to me. I don't think it is allowed. I
suppose I'd need to study more carefully to be 100% sure, but the comma
is a separator - not a terminator. That also looks like a bug, and one
less likely to be a posting artifact.


-- 
   Summary: Namelist writting to internal files:  Control characters
wrong?
   Product: gcc
   Version: 4.4.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=36895

[Bug c/36708] syntatic warning

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-07-22 07:20 ---
Closing as invalid then.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/36830] [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb

[r dot emrich at de dot tecosim dot com]

--- Comment #6 from r dot emrich at de dot tecosim dot com  2008-07-22 
07:53 ---
(In reply to comment #5)
 For me it is working today
 

I don't Know if it's related but today (rev. 138048) I get the following on
x86_64-unknown-linux-gnu:

/SCRATCH/tmp.haKcfD9964/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0/gcc-4.4.0/./prev-gcc/xgcc
-B/SCRATCH/tmp.haKcfD9964/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0/gcc-4.4.0/./prev-gcc/
-B/opt/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0/x86_64-unknown-linux-gnu/bin/
-c -g -O2  -gnatpg -gnata -gnatwns -nostdinc -I- -I. -Iada
-I/opt/gnu/src/gcc/gcc-4.4.0/gcc/ada
/opt/gnu/src/gcc/gcc-4.4.0/gcc/ada/osint.adb -o ada/osint.o 

raised STORAGE_ERROR : stack overflow (or erroneous memory access)
gmake[3]: *** [ada/osint.o] Error 1 


-- 


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

[Bug fortran/36890] libgfortran/io/file_pos.c:55: warning: comparison between signed and unsigned

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-07-22 08:30 ---
This is caused by

static const unsigned int READ_CHUNK = 4096;

and, further down,

  n = (base  READ_CHUNK) ? base : READ_CHUNK;

where base is a gfc_offset (a signed quantity).

The unsigned is unnecessary.  I'll commit a patch removing
this as obvious.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-22 08:30:26
   date||


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

[Bug fortran/36895] Namelist writting to internal files: Control characters wrong?

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-07-22 09:01 ---
10.10.2 Namelist output

The form of the output produced is the same as that required for input, except
for the forms of real, character, and logical values. The name in the output is
in upper case. With the exception of adjacent undelimited character values, the
values are separated by one or more blanks or by a comma, or a semicolon if the
decimal edit mode is COMMA, optionally preceded by one or more blanks and
optionally followed by one or more blanks.

The processor may begin new records as necessary.

 * * *

9.3 Internal files
(2) A record of an internal file is a scalar character variable.
(3) If the file is a scalar character variable, it consists of a single record
whose length is the same as the length of the scalar character variable. If the
file is a character array, it is treated as a sequence of character array
elements.

 * * *

Thus I think Richard is right that having new-line characters is wrong (at
least for scalar variables). At least I believe that new-line characters can be
regarded as starting a new record.


-- 


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

[Bug tree-optimization/36896] New: ICE when gcc 4.4.0-20080722 compiles glibc 2.6.1/stdio-common/printf_size.c

[linuxl4 at sohu dot com]

the command is : 
gcc printf_size.c -c -std=gnu99 -O2 -fgnu89-inline -Winline -Wwrite-strings
-Wstrict-prototypes -mpreferred-stack-boundary=2 -I..

if change -O2 to -O1 , ICE will dispear .

 what's wrong ?


-- 
   Summary: ICE when gcc 4.4.0-20080722 compiles glibc 2.6.1/stdio-
common/printf_size.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: linuxl4 at sohu dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/36896] ICE when gcc 4.4.0-20080722 compiles glibc 2.6.1/stdio-common/printf_size.c

[linuxl4 at sohu dot com]

--- Comment #1 from linuxl4 at sohu dot com  2008-07-22 09:23 ---
Created an attachment (id=15937)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15937action=view)
printf_size.i

gcc printf_size.c -c -std=gnu99 -O2 -fgnu89-inline -Winline -Wwrite-strings
-Wstrict-prototypes ...--save-temp


-- 


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

[Bug middle-end/36896] [4.4 Regression] ICE in insert_save, at caller-save.c:787

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-07-22 09:29 ---
Happens with -O2 -mpreferred-stack-boundary=2 only.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end
   Keywords||ice-on-valid-code
  Known to work||4.3.1
Summary|ICE when gcc 4.4.0-20080722 |[4.4 Regression] ICE in
   |compiles glibc 2.6.1/stdio- |insert_save, at caller-
   |common/printf_size.c|save.c:787
   Target Milestone|--- |4.4.0


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

[Bug preprocessor/28079] #line range not verified without -pedantic

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2008-07-22 09:46 ---
Subject: Bug 28079

Author: manu
Date: Tue Jul 22 09:45:58 2008
New Revision: 138049

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138049
Log:
2008-07-22  Manuel Lopez-Ibanez  [EMAIL PROTECTED]

PR 28079
libcpp/
* directives.c (strtolinenum): Handle overflow.
(do_line): Give a warning if line number overflowed.
(do_linemarker): Update call to strtolinenum.

gcc/testsuite/
* gcc.dg/cpp/line6.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/line6.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/directives.c


-- 


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

[Bug preprocessor/28079] #line range not verified without -pedantic

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-07-22 09:48 ---
Fixed in GCC 4.4


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/24985] caret diagnostics

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-07-22 09:50 ---
Better summary to find duplicates.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  Alias||caret
Summary|Line info in diagnostics is |caret diagnostics
   |very unfriendly |


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

[Bug target/32918] segmentation fault

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-07-22 09:56 ---
No reply for a long time. Old version of GCC. Closing as INVALID.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug other/28322] GCC new warnings and compatibility

[manu at gcc dot gnu dot org]

--- Comment #22 from manu at gcc dot gnu dot org  2008-07-22 09:59 ---
Not working on this.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/36890] libgfortran/io/file_pos.c:55: warning: comparison between signed and unsigned

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-07-22 10:27 ---
Subject: Bug 36890

Author: tkoenig
Date: Tue Jul 22 10:27:10 2008
New Revision: 138050

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138050
Log:
2008-07-22  Thomas Koenig  [EMAIL PROTECTED]

PR libfortran/36890
* io/file_pos.c:  Declare READ_CHUNK as signed to avoid
signed/unsigned comparison warning in formatted_backspace.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/file_pos.c


-- 


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

[Bug fortran/36890] libgfortran/io/file_pos.c:55: warning: comparison between signed and unsigned

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-07-22 10:29 ---
Fixed on trunk.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36844] Vectorizer doesn't support INT-FP conversions with different size

[dorit at gcc dot gnu dot org]

--- Comment #2 from dorit at gcc dot gnu dot org  2008-07-22 10:39 ---
(In reply to comment #1)
 One problem is vectorizable_conversion. Is there a way to support
 V4DF/V4DI - D4SI/V4SF
 V8SI - V8SF 

With the current framework, the only way to support 
V8SI - V8SF
is to implement the TARGET_VECTORIZE_BUILTIN_CONVERSION for these modes. 

There's no way in the current framework to support  
V4DF - V4SI
V4DI - V4SF
because of the single-vector-size assumption. These however would be supported:
V4DF - V8SI
V4DI - V8SF
by modeling the idioms unpack[u/s]_float_[lo/hi] and vec_pack_[u/s]fix_trunc
for the respective modes.

I think that in order to really support AVX the vectorizer would need to be
extended to consider multiple vector sizes (which would probably involve more
than just extending the support for conversions).


-- 


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

[Bug c++/36897] New: Internal compiler error with function pointer template parameter

[kathoum at gmail dot com]

Trying to compile the following program:

typedef void (*fptr)();
fptr zeroptr = 0;
templatetypename T, fptr F struct foo { };
templatetypename T struct fooT,zeroptr { };
void f() { }
fooint,f m_foo;

I get the message:
test.cpp:6: internal compiler error: in unify, at cp/pt.c:13401
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: Internal compiler error with function pointer template
parameter
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kathoum at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/36897] Internal compiler error with function pointer template parameter

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-07-22 11:48 
---
Te be clear, this is ICE on invalid


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code


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

[Bug libfortran/36886] misaligment for cshift of character

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-07-22 11:58 ---
Related to PR 32972 (optimizing cshift the way that other
array intrinsics have been done will cure this).


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-22 11:58:11
   date||


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

[Bug bootstrap/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2008-07-22 12:05 ---
Jan, did you have a chance to take a look?  Your patch breaks Tru64 UNIX
bootstrap
since almost 4 months.

  Rainer


-- 


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

[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-07-22 12:11 ---
Analogously for:
integer foo(size([x]))
real x

As ifort writes:
error #6279: A specification expression object must be a dummy argument, a
COMMON block object, or an object accessible through host or use association


-- 


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

[Bug fortran/36355] matmul argument-check: wrong error messages

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-07-22 12:30 ---
(In reply to comment #1)
 Proposed patch passed regression test on i686-pc-linux-gnu..

Patch is approved (or obvious and simple, whatever you prefer :-)


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-22 12:30:06
   date||


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

[Bug fortran/36894] question on gfortran character*(*)

[jhuddleston at hughes dot net]

--- Comment #3 from jhuddleston at hughes dot net  2008-07-22 13:17 ---
Created an attachment (id=15938)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15938action=view)
zip container with two files: C++ and GFORTRAN

burnus at gcc dot gnu dot org requested a small sample set demonstrating the
issue

My current version from subversion is 138025

Thank you.  I went through four scenarios and documented them in the small
sample set. Of the four, the case that works for both CHARACTER(*) and
CHARACTER*(*) is when an integer is passed in front of the string AND if the
size of the string is passed at the end.

If the C++ code does not pass an integer before the string, the *(*) will fail.
 This only appears in the C++ / GFortran interaction which is why I sent this
to the GCC group.  I keep the most current GCC/G++/GFORTRAN code from
subversion and build nightly under Windows Cygwin.

John


-- 


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

[Bug target/36898] New: Insufficient qp-mutex declarations

[schwab at suse dot de]

The attached test case is causing a spurious dependency violation message from
the assembler.  The problem seems to be that the assembler is clearing all qp
mutex relations after a call, but the compiler does not emit .pred.rel.mutex
after them.

$ gcc -O2 -c -save-temps xdisp.c
xdisp.s: Assembler messages:
xdisp.s:114: Warning: Use of 'mov' may violate WAW dependency 'GR%, % in 1 -
127' (impliedf), specific resource number is 16
xdisp.s:113: Warning: This is the location of the conflicting usage


-- 
   Summary: Insufficient qp-mutex declarations
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: ia64-*-*


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

[Bug target/36898] Insufficient qp-mutex declarations

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-07-22 13:34 ---
Created an attachment (id=15939)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15939action=view)
Testcase


-- 


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

[Bug target/36898] Insufficient qp-mutex declarations

[schwab at suse dot de]

--- Comment #2 from schwab at suse dot de  2008-07-22 13:35 ---
Created an attachment (id=15940)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15940action=view)
Assembler output


-- 


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

[Bug target/36450] [4.4 Regression] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2008-07-22 13:44 
---
*** Bug 36896 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||linuxl4 at sohu dot com


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

[Bug middle-end/36896] [4.4 Regression] ICE in insert_save, at caller-save.c:787

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-07-22 13:44 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/36899] New: Wrong char to wchar_t conversion when putting multibyte strings to wide-character streams

[mironov dot ivan at gmail dot com]

Small example:
==
#include iostream
#include locale

using namespace std;

int main()
{
locale::global(locale());
wcout.imbue(locale());

wcout  Hello world! ðÒÉ×ÅÔ ÍÉÒ!  endl;

return 0;
}
==

Actual output:
Hello world!  !

Expected output:
Hello world! ðÒÉ×ÅÔ ÍÉÒ!

Compilation command and output:
==
$ g++ -v -save-temps cpptest.cpp

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --disable-libmudflap
--disable-libssp --enable-cld --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1'
Thread model: posix
gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.1/cc1plus -E -quiet -v -D_GNU_SOURCE
cpptest.cpp -mtune=generic -fpch-preprocess -o cpptest.ii
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.1/cc1plus -fpreprocessed cpptest.ii
-quiet -dumpbase cpptest.cpp -mtune=generic -auxbase cpptest -version -o
cpptest.s
GNU C++ (Gentoo 4.3.1-r1 p1.1) version 4.3.1 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 70848920b58e0e1c3b1cfc0cd9dd8b3c
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/bin/as
-V -Qy -o cpptest.o cpptest.s
GNU assembler version 2.18 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.18
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.1/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.1/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.1/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.1/collect2 --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/crtbegin.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../.. cpptest.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/crtend.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../lib64/crtn.o
==

System: linux (gentoo), amd64


-- 
   Summary: Wrong char to wchar_t conversion when putting multibyte
strings to wide-character streams
   Product: gcc
   Version: 

[Bug libstdc++/36899] Wrong char to wchar_t conversion when putting multibyte strings to wide-character streams

[mironov dot ivan at gmail dot com]

--- Comment #1 from mironov dot ivan at gmail dot com  2008-07-22 14:55 
---
Created an attachment (id=15941)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15941action=view)
Preprocessed source (utf-8)


-- 


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

[Bug c++/36900] ICE: in propagate_one_insn, at flow.c:1734

[oliver dot regenfelder at gmx dot at]

--- Comment #1 from oliver dot regenfelder at gmx dot at  2008-07-22 15:32 
---
Created an attachment (id=15942)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15942action=view)
preprozessor output for the file triggering the bug


-- 


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

[Bug c++/36900] New: ICE: in propagate_one_insn, at flow.c:1734

[oliver dot regenfelder at gmx dot at]

A small c++ program causes this ICE if optimization level is 1 ore above

[my_computer]$ g++ -v -save-temps -O3 compiler_bug.cpp 
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
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE
compiler_bug.cpp -mtune=generic -O3 -fpch-preprocess -o compiler_bug.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/i486-linux-gnu
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.2.3/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed compiler_bug.ii
-quiet -dumpbase compiler_bug.cpp -mtune=generic -auxbase compiler_bug -O3
-version -fstack-protector -fstack-protector -o compiler_bug.s
GNU C++ version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (i486-linux-gnu)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9cf91ba46d80e564052e4fbab0d6561b
compiler_bug.cpp: In function ‘int main(int, char**)’:
compiler_bug.cpp:67: error: Attempt to delete prologue/epilogue insn:
(insn/f 127 126 128 2 (set (mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -16 [0xfff0])) [0 S4 A8])
(reg:SI 2 cx)) -1 (nil)
(nil))
compiler_bug.cpp:67: internal compiler error: in propagate_one_insn, at
flow.c:1734
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.2/README.Bugs.
[EMAIL 
PROTECTED]:~/GameEngine/eclipse-workspace/GameEngine/performance_evaluation$


-- 
   Summary: ICE:  in propagate_one_insn, at flow.c:1734
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver dot regenfelder at gmx dot at


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

[Bug tree-optimization/21465] autovectorisation conflicts with -ffast-math

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2008-07-22 15:48 ---
i had a patch to expand pow at the tree level, but it conflicted with fold
(which consistently tried to rebuild pow function calls).  the outcome might be
better now that we have PAREN_EXPR, though.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug other/36901] New: pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

[manu at gcc dot gnu dot org]

From PR35637 but this is a general issue of the diagnostic machinery.

The problem is: -pedantic no warning, -pedantic-errors gives an
error. 

Explanation: The pedantic warning is in a system header, so it doesn't get
emitted. When using -pedantic-errors, it is an error, and errors are always
emitted.

Longer explanation: The problem is in
diagnostics.c (diagnostic_report_diagnostic) which checks only for DK_WARNING
if 
they should be inhibited (either because of -w or because location is within
system headers. However, pedwarn() is passing a DK_ERROR when -pedantic-errors
is enabled. 

One possible fix is that pedwarn() always passes a DK_WARNING type, while
-pedantic-errors reclassifies -pedantic warnings to emit errors. In other
words, -pedantic-errors would behave internally like -Werror=pedantic.


-- 
   Summary: pedwarn() + -pedantic-errors + -w (inhibit_warnings)
should not emit errors
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org


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

[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-07-22 16:30 ---
One testcase could use #include_next in a system header and compile with just
-pedantic-errors. This should be silent but it currently emits an error.

Another testcase could be just:

static int sc = INT_MAX + 1; 

compiled with -pedantic-errors -w. This should be silent as well, but it will
give an error.


-- 


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

[Bug fortran/36895] Namelist writting to internal files: Control characters wrong?

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-07-22 16:47 
---
I will check on this later tonight or this week.  I have wondered about that
comma myself.  


-- 

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 |2008-07-22 16:47:52
   date||


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

[Bug fortran/29835] Error message of unknown edit descriptor needs improvement

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2008-07-22 17:06 ---
Subject: Bug 29835

Author: domob
Date: Tue Jul 22 17:05:55 2008
New Revision: 138063

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138063
Log:
2008-07-22  Daniel Kraft  [EMAIL PROTECTED]

PR fortran/29835
* io.c (error_element), (format_locus):  New static globals.
(unexpected_element):  Spelled out this message fully.
(next_char):  Keep track of locus when not MODE_STRING.
(next_char_not_space):  Remember last parsed element in error_element.
(format_lex):  Fix two indentation errors.
(check_format):  Use format_locus and possibly error_element for a
slightly better error message on invalid format.
(check_format_string):  Set format_locus to start of the string
expression used as format.

2008-07-22  Daniel Kraft  [EMAIL PROTECTED]

PR fortran/29835
* io/format.c (struct format_data):  New member error_element.
(unexpected_element):  Added '%c' to message.
(next_char):  Keep track of last parsed character in
fmt-error_element.
(format_error):  If the message is unexpected_element, output the
offending character, too.

2008-07-22  Daniel Kraft  [EMAIL PROTECTED]

PR fortran/29835
* gfortran.dg/fmt_error_3.f90:  New test.
* gfortran.dg/fmt_error_4.f90:  New test.
* gfortran.dg/fmt_error_5.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/fmt_error_3.f90
trunk/gcc/testsuite/gfortran.dg/fmt_error_4.f90
trunk/gcc/testsuite/gfortran.dg/fmt_error_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/format.c


-- 


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

[Bug libstdc++/36899] Wrong char to wchar_t conversion when putting multibyte strings to wide-character streams

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-07-22 17:09 
---
Really, there isn't much we can do here: according to the standard
(27.6.2.5.4/4) each char is widened *individually* (via out.widen), and some of
the chars in the character-literal at issue (not belonging to the basic source
character set) *as represented internally* by the compiler (you can see that in
a debugger, nothing to do with the library of course) cannot be widened
uniquely (via, eg, btowc). Then, the next insertion (equivalent to a series of
putwc in this case in our implementation, see libstdc++/35353, but this is
really an unrelated issue) ends up inserting WEOFs.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/29835] Error message of unknown edit descriptor needs improvement

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2008-07-22 17:11 ---
The message locus for constant-string is not yet perfect, but the effort to
benefit ratio in this case is probably rather bad, so I mark this as fixed.

In my commit, I changed the Unexpected element error to include the offending
character as suggested in the opening comment, changed the locus for
constant-string expressions to the start of this expression rather than the end
of the overall statement and added some tests for both runtime and compile time
format checking.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-07-22 17:29 
---
Thanks a lot Manuel! Maybe I will even be able to come to this, thanks to your
suggestions for a fix.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo at gcc dot gnu dot org


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

[Bug fortran/36895] Namelist writting to internal files: Control characters wrong?

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-07-22 17:47 ---
 I will check on this later tonight or this week.  I have wondered about that
 comma myself.

Thanks! I believe the comma should be valid, even though it is superfluous and
looks wrong. Thus it were nice if one could get rid of it, but only if it is
not too much work and does not slow down the I/O.

Regarding the line breaks: I think they are indeed wrong. At the moment I
cannot come up with a good example how this can cause problems, but I'm sure
one could construct one.

Running the following program using NAG f95 gives the error:
Invalid character '
' in NAMELIST input
Program terminated by I/O error on internal file

Thus NAG f95 does not like the line break. (The program works in g95 and
gfortran.)

--
character(len=255) :: str(2)
integer :: i, j(2)
namelist /nm/i,j
i = 44
j = 45
str(1) = ' NM '//new_line('a')//' I=  1,'
str(2) = ' J= 2*2  ,  /'
read(str,nml=nm)
print *, i, j
end
--


-- 


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

[Bug other/36901] pedwarn() + -pedantic-errors + -w (inhibit_warnings) should not emit errors

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-07-22 18:07 ---
(In reply to comment #2)
 Thanks a lot Manuel! Maybe I will even be able to come to this, thanks to your
 suggestions for a fix.
 

I think there is a problem with my suggestion: -pedantic-errors does not only
affect -pedantic warnings but it also affects pedwarns that are not controlled
by -pedantic. -Werror=pedantic would only affect those warnings controlled by
-pedantic, so it would not be equivalent to -pedantic-errors. :( 

At the moment where diagnostic_report_diagnostic checks
diagnostic_report_warnings_p (location), the machinery does not know that this
is a pedwarn. I guess we could pass a special code DK_PEDWARN, and test for
flag_pedantic_errors within diagnostic_report_diagnostic so we can reclassify
it as DK_ERROR or DK_WARNING; or we could pass a special code DK_PEDERROR and
for that code also check diagnostic_report_warnings_p before reclassifying it
to DK_ERROR; or we could make a call to diagnostic_report_warnings_p (location)
directly in pedwarn before passing down a DK_ERROR. 

Sorry I can't be more precise. This needs more time to think that I have
available.


-- 


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

[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2

[dodji at gcc dot gnu dot org]

--- Comment #6 from dodji at gcc dot gnu dot org  2008-07-22 18:25 ---
@jakub: I confirm that doing:

if (!DECL_CONTEXT (decl))
{ 
  DECL_CONTEXT (decl) = current_function_decl;
}
at the beginning of one_static_initialization_or_destruction() allows the
compilation to not crash.

At that point, the name of current_function_decl is effectively
__static_initialization_and_destruction_0.

I am not sure if setting DECL_CONTEXT (decl) is safe to do, because the
DECL_CONTEXT (decl) being NULL means the variable happened in the global
namespace. Doing DECL_CONTEXT (decl) = current_function_decl makes us loose
that information.

On the other hand, one_static_initialization_or_destruction() is called at the
end of the parsing+semantic analysis phase, so loosing that information might
not be harmful (I am not sure). In which case, this candidate fix might be
enough.


-- 


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

[Bug c/36902] New: [4.3/4.4 Regression]: Bogus array bound warning

[hjl dot tools at gmail dot com]

On Linux/x86-64, gcc 4.3/4.4 give:

[EMAIL PROTECTED] gcc]$ cat /tmp/y.c
/*
 * compile w/:
 * gcc -Wall -Werror -fno-strict-aliasing -O2 -c foo.c
 */

typedef unsigned char __u8;
typedef unsigned short __u16;

static inline void * foo(
void * to, const void * from, int n)
{
switch ( n )
{
case 3:
*(__u16 *)to = *(const __u16 *)from;
break;
case 5:
*((__u8 *)to + 4) = *((const __u8 *)from + 4);
break;
}
return to;
}

int main(int argc, char *argv[])
{
static char buf[64];
struct {
__u16size_of_select;
__u8 pcr_select[4];
} sel;

sel.size_of_select = 3;
foo(buf, sel.pcr_select, sel.size_of_select);

return 1;
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -Wall -Werror -fno-strict-aliasing -O2 -c 
/tmp/y.c
cc1: warnings being treated as errors
/tmp/y.c: In function âmainâ:
/tmp/y.c:18: error: array subscript is above array bounds
[EMAIL PROTECTED] gcc]$

Gcc 4.1 is OK.


-- 
   Summary: [4.3/4.4 Regression]: Bogus array bound warning
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/36902] [4.3/4.4 Regression]: Bogus array bound warning

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-22 20:50 ---
This happens because the warning happens very early in the compiler so it does
not know that the case5 is not going to be used.  I think the warning is
correct and not really bogus if you take that into account.


-- 


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

[Bug middle-end/36902] [4.3/4.4 Regression]: Bogus array bound warning

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-07-22 21:13 ---
This regression is introduced by revision 120898:

http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00603.html

The simplified testcase:

---
typedef unsigned char __u8;
typedef unsigned short __u16;

static inline unsigned char *
foo(unsigned char * to, const unsigned char * from, int n)
{
switch ( n )
{
case 3:
  *to = *from;
break;
case 5:
to[4] = from [4];
break;
}
return to;
}

struct {
intsize_of_select;
unsigned char pcr_select[4];
} sel;

int main(int argc, char *argv[])
{
static unsigned char buf[64];

sel.size_of_select = 3;
foo(buf, sel.pcr_select, sel.size_of_select);

return 1;
}
---

The warning is very fragile:  if the buffer in main() is not static then
there is no failure; is the size is passed as a constant there is no error.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||mueller at gcc dot gnu dot
   ||org, richard dot guenther at
   ||gmail dot com


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-22 21:18 ---
 The warning is very fragile:  if the buffer in main() is not static then
 there is no failure; is the size is passed as a constant there is no error.

Not really, if you read my comment, you will understand why this is not that
fragile after all.  I can make it even worse if you do a couple of things to
trick one optimization pass up enough so we warn in the first VRP but don't
optimize it away until the last VRP pass.  But really this is the normal issue
with optimizers  warnings and is a hard problem to solve in general and I don't
think we can count this as a regression really.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-07-22 21:18:28
   date||
Summary|[4.3/4.4 Regression]: Bogus |Array bound warning with
   |array bound warning |dead code after optimization


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-07-22 21:26 
---
Out of curiosity: if this kind of code appears in a system header, is #pragma
GCC system_header able to suppress the warning? Of course I'm asking because
this is the most annoying feature of PR 36633 (which immediately came to my
mind when I saw this one ;)


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo at gcc dot gnu dot org


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-07-22 21:29 ---
It is a regression since the same correct code no longer compiles
with -Werror -Wall after upgrading from gcc 4.1/4.2 to 4.3.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.3.1 4.4.0
  Known to work||4.1.3 4.2.5


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-07-22 21:30 ---
(In reply to comment #4)
 Out of curiosity: if this kind of code appears in a system header, is #pragma
 GCC system_header able to suppress the warning? Of course I'm asking because
 this is the most annoying feature of PR 36633 (which immediately came to my
 mind when I saw this one ;)
 

It comes from an application.


-- 


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2008-07-22 21:32 
---
(In reply to comment #6)
 It comes from an application.

This doesn't answer my question. 


-- 


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2008-07-22 21:42 ---
(In reply to comment #7)
 (In reply to comment #6)
  It comes from an application.
 
 This doesn't answer my question. 
 

I said It comes from an application. It isn't from system header file.


-- 


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

[Bug tree-optimization/36861] boost's compressed avl confuses GCC

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2008-07-22 21:43 
---
I think someone needs to kick the hell out of boost for making crappy code.  I
am going to remove the regression marker for now because it is definitely a bit
weird what boost is doing and not normal for real code.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3 Regression] code   |boost's compressed avl
   |generation regression with -|confuses GCC
   |O3  |
   Target Milestone|4.3.2   |---


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

[Bug tree-optimization/36861] boost's compressed avl confuses GCC

[lothar at tradescape dot biz]

--- Comment #13 from lothar at tradescape dot biz  2008-07-22 21:48 ---
(In reply to comment #11)
From an application perspective it is still a regression, as it works happily
with gcc 4.2.3


-- 


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

[Bug tree-optimization/36861] boost's compressed avl confuses GCC

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2008-07-22 21:52 
---
(In reply to comment #13)
 (In reply to comment #11)
 From an application perspective it is still a regression, as it works happily
 with gcc 4.2.3

Yes but it is boost's fault that boost tries to be smart about space
optimizations when they should not have.  It really does confuse the hell out
of compilers, doing what they are doing.  C/C++ was not designed the way they
think it was.


-- 


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

[Bug tree-optimization/36861] boost's compressed avl confuses GCC

[lothar at tradescape dot biz]

--- Comment #15 from lothar at tradescape dot biz  2008-07-22 22:01 ---
What I am worried about is that if it is not marked as a regression nobody
cares to fix it although it breaks a real application that works with gcc
4.3.2.

If you have any insights how to improve the boost intrusive library to avoid
confusing gcc I am sure the boost people are happy to hear them and to
incorporate them in the upcoming boost release.


-- 


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2008-07-22 22:53 
---
 I said It comes from an application. It isn't from system header file.

Yes, and that doesn't answer my question. I asked if the pragma is able to
suppress a warning triggered by your kind of snippet, IF, when, it appears in
an header file: I asked about an HYPOTHETICAL situation, not your actual
situation. Is that more clear?


-- 


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

[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object

[fmuldoo at me dot lsu dot edu]

--- Comment #13 from fmuldoo at me dot lsu dot edu  2008-07-22 22:54 ---
Subject: Re:  Namelist I/O error: Bogus Cannot match
namelist object

Great, and thanks very much.  I'm very glad you found it as it is the
only thing preventing me from using gfortran with my code.  This is the
first time I have reported anything here and do not know the procedure
of how fixes such as this make it into packages that one can download.

Thanks again,
Frank


On Tue, 2008-07-22 at 05:02 +, jvdelisle at gcc dot gnu dot org
wrote:
 
 --- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-07-22 05:02 
 ---
 Finally had some quiet time to pick at this.  Yep, a one liner.  This fixes 
 the
 test case and no namelist regressions.
 
 Index: list_read.c
 ===
 --- list_read.c (revision 138020)
 +++ list_read.c (working copy)
 @@ -2791,7 +2791,7 @@ get_name:
 
if (nl-type == GFC_DTYPE_DERIVED)
  nml_touch_nodes (nl);
 -  if (component_flag)
 +  if (component_flag  nl-var_rank  0)
  nl = first_nl;
 
/* Make sure no extraneous qualifiers are there.  */
 
 


-- 


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

[Bug middle-end/36900] ICE: in propagate_one_insn, at flow.c:1734

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-07-22 23:40 ---
This is most likely fixed on the trunk already.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |middle-end
 GCC target triplet||i486-linux-gnu


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

[Bug middle-end/36900] ICE: in propagate_one_insn, at flow.c:1734

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-22 23:42 ---
(In reply to comment #2)
 This is most likely fixed on the trunk already.
4.3.x also. 


-- 


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

[Bug testsuite/36903] New: Generic vectorizarion test failures

[hutchinsonandy at gcc dot gnu dot org]

For AVR the following test fail. Probably since the day they were created.

For AVR there are no vectypes  so they all fail  message test

I don't know if these should be skipped as invalid or there is some significant
issue that warrant XFAIL.


FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect vectorized 1
loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect vectorized 1
loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect vectorized 1
loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-25.c scan-tree-dump-times vect vectorized 2
loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect vectorized 1
loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect Alignment of
access forced using peeling 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect vectorized 1
loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect Alignment of
access forced using peeling 1
FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect vectorized 1
loops 1


-- 
   Summary: Generic vectorizarion test failures
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at gcc dot gnu dot org
GCC target triplet: avr-unknown-none


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2008-07-23 01:04 
---
(In reply to comment #9)
  I said It comes from an application. It isn't from system header file.
 
 Yes, and that doesn't answer my question. I asked if the pragma is able to
 suppress a warning triggered by your kind of snippet, IF, when, it appears in
 an header file: I asked about an HYPOTHETICAL situation, not your actual
 situation. Is that more clear?
 

It doesn't make a difference:

[EMAIL PROTECTED] tmp]$ cat y.h
#pragma GCC system_header
static inline unsigned char *
foo(unsigned char * to, const unsigned char * from, int n)
{
switch ( n )
{
case 3:
  *to = *from;
break;
case 5:
to[4] = from [4];
break;
}
return to;
}
[EMAIL PROTECTED] tmp]$ cat y.c
#include y.h

struct {
intsize_of_select;
unsigned char pcr_select[4];
} sel;

int main(int argc, char *argv[])
{
static unsigned char buf[64];

sel.size_of_select = 3;
foo(buf, sel.pcr_select, sel.size_of_select);

return 1;
}
[EMAIL PROTECTED] tmp]$ gcc -Wall -O2 -c y.c -Werror -I.
cc1: warnings being treated as errors
y.c: In function âmainâ:
./y.h:11: error: array subscript is above array bounds
[EMAIL PROTECTED] tmp]$


-- 


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2008-07-23 01:16 
---
Thanks. Actually, I think the experiment would be more meaningful if you could
put also the equivalent of your main (a calling function, that is) inside the
header, because in your testcase the warning is triggered inside the main, not
in foo.

If you can, in your spare time, of course.


-- 


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2008-07-23 01:23 
---
(In reply to comment #11)
 Thanks. Actually, I think the experiment would be more meaningful if you could
 put also the equivalent of your main (a calling function, that is) inside the
 header, because in your testcase the warning is triggered inside the main, not
 in foo.
 

Same:

[EMAIL PROTECTED] tmp]$ cat y.h
#pragma GCC system_header
static inline unsigned char *
foo(unsigned char * to, const unsigned char * from, int n)
{
switch ( n )
{
case 3:
  *to = *from;
break;
case 5:
to[4] = from [4];
break;
}
return to;
}

struct {
intsize_of_select;
unsigned char pcr_select[4];
} sel;

static int
bar (void)
{
static unsigned char buf[64];

sel.size_of_select = 3;
foo(buf, sel.pcr_select, sel.size_of_select);

return 1;
}
[EMAIL PROTECTED] tmp]$ cat y.c
#include y.h

int
main ()
{
  return bar ();
}
[EMAIL PROTECTED] tmp]$ gcc -Wall -O2 -c y.c -Werror -I.
cc1: warnings being treated as errors
y.c: In function âmainâ:
./y.h:11: error: array subscript is above array bounds
[EMAIL PROTECTED] tmp]$


-- 


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

[Bug middle-end/36902] Array bound warning with dead code after optimization

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2008-07-23 01:28 
---
You see, as I feared: this class of warnings coming from the middle-end is
especially nasty, because cannot be suppressed by any normal means.


-- 


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

[Bug target/36904] New: [4.4 Regression] vector context sensitive keyword vs macros

[pinskia at gcc dot gnu dot org]

Take the following testcase:
#include altivec.h
#define xprint_vec(type)  void x##type(vector type v) { }
xprint_vec(float);

This used to work in 4.3 and before but does not currently.  The problem here
was introduced when the context sensitive keyword support was added.


-- 
   Summary: [4.4 Regression] vector context sensitive keyword vs
macros
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-linux


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

[Bug fortran/36895] Namelist writting to internal files: Control characters wrong?

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-07-23 01:39 
---
I have reviewed our code.

First, we reject the internal unit for namelist when using -std=f95.

$ gfc -std=f95 pr36895.f90 
pr36895.f90:4.8:

  write(line,nml=stuff)
   1
Error: Fortran 2003: Internal file at (1) with namelist

Second, our namelist write function makes its own cr-lf sequences and does not
use next_record so all the checks for end of record are not used.  Normally you
can have multiple records with internal units only if it is a character array,
one record per array element.

I will fix this.


-- 


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

[Bug target/36904] [4.4 Regression] vector context sensitive keyword vs macros

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-23 01:55 ---
Hmm, I think the sign/zero extension is needed.
Even doing:
void fred(unsigned short in, unsigned short *out1)
{
int i;
for (i=0;i100;i++)
out1[i+1] = out1[i]*in;
}
--- CUT ---
We will get a zero extension in the assembly (on Powerpc-linux-gnu).
.L2:
add 9,4,11
addi 11,11,2
mullw 0,3,0
sth 0,2(9)
rldicl 0,0,0,48
bdnz .L2
--- CUT ---
But it is needed.  If we look at -O2 case:
.L2:
lhz 0,0(4)
mullw 0,3,0
sthu 0,2(4)
bdnz .L2
You will see that we load the code as zero extended.

Also I get:
bb 3:
  D.1263 = (short unsigned int) D__lsm0.41 * pretmp.27;
  D__lsm0.41 = (short int) D.1263;
  MEM[base: out1 + ivtmp.49, offset: 2] = D__lsm0.41;
  ivtmp.49 = ivtmp.49 + 2;
  if (ivtmp.49 != 200)

for the loop on the trunk.


-- 


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

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-07-23 02:01 ---
for the loop on the trunk.

I think the trunk improved fold somewhere along the way, because the 4.3 I have
from January has the extra sign extension.

We will get a zero extension in the assembly (on Powerpc-linux-gnu).

Also IV-opts is messing up anyways, it should have done out+1 as the base
instead of out, blah.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization


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

[Bug tree-optimization/36905] New: IV-opts needs a little help with a[i+1]

[pinskia at gcc dot gnu dot org]

Take:
void fred(unsigned short in, unsigned short *out1)
{
__SIZE_TYPE__ i;
for (i=0;i100;i++)
out1[i+1] = in;
}

For PPC we currently generate:
.L2:
addi 9,9,1
slwi 0,9,1
sthx 3,4,0
bdnz .L2

But if change the code just so slightly to:
void fred(unsigned short in, unsigned short *out1)
{
__SIZE_TYPE__ i;
out1 ++;
for (i=0;i100;i++)
  out1[i] = in;
}
--- CUT ---
we get great code:
.L2:
sthu 3,2(4)
bdnz .L2
Even without update we still get:
.L2:
sth 3,2(4)
addi 4,4,2
bdnz .L2

Even if we use the variable out1 afterwards (by a return), we still get the
better code in the second case.


-- 
   Summary: IV-opts needs a little help with a[i+1]
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-linux


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

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-23 02:10 ---
(In reply to comment #2)
 Also IV-opts is messing up anyways, it should have done out+1 as the base
 instead of out, blah.

Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 .


-- 


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

[Bug tree-optimization/36905] [4.2/4.3/4.4 Regression] IV-opts needs a little help with a[i+1]

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-23 02:16 ---
In fact this is one case where the old loop.c gets it correct :(.
4.1.1 with IV-opts off:
.L2:
sth 3,0(9)
addi 9,9,2
bdnz .L2

Which means I can declare this as a regression from 3.4.x.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.0 4.4.0 4.3.0
  Known to work||3.4.0
Summary|IV-opts needs a little help |[4.2/4.3/4.4 Regression] IV-
   |with a[i+1] |opts needs a little help
   ||with a[i+1]
   Target Milestone|--- |4.2.5


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

[Bug tree-optimization/36891] ICE with vector division and -ffast-math and LIM

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-07-23 03:03 ---
I have a patch, I still have to check complex, I think it is ok because we have
expanded the division by the time we ran LIM.


-- 

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 |2008-07-23 03:03:26
   date||


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

[Bug c++/36852] [4.3/4.4 Regression] Two dimensional array in template method argument list incorrectly interpreted.

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-07-23 04:30 
---
Subject: Bug 36852

Author: jvdelisle
Date: Wed Jul 23 04:29:15 2008
New Revision: 138072

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138072
Log:
2008-07-22  Jerry DeLisle  [EMAIL PROTECTED]

PR fortran/36852
* io/list_read.c: If variable rank is zero, do not adjust the found
namelist object pointer.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c


-- 


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

[Bug c++/36852] [4.3/4.4 Regression] Two dimensional array in template method argument list incorrectly interpreted.

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-07-23 04:37 
---
Subject: Bug 36852

Author: jvdelisle
Date: Wed Jul 23 04:36:54 2008
New Revision: 138073

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138073
Log:
2008-07-22  Jerry DeLisle  [EMAIL PROTECTED]

PR libfortran/36852
* gfortran.dg/namelist_52.f90: New test.

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


-- 


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