[Bug tree-optimization/29145] unsafe use of restrict qualifier

[dberlin at gcc dot gnu dot org]

--- Comment #5 from dberlin at gcc dot gnu dot org  2006-11-04 04:15 ---
This was something that slipped in, IIRC. I was of Ian's viewpoint, that
may_alias_p should handle it, and it shouldn't be special to data-references.
But it can't, at least in it's current state, because it somehow gets stripped.

I forget the exact details, but diego has explained this to me before :).

Diego, what was the deal with restrict and stripping qualifications that caused
us to not see restrict when it comes time for may_alias_p? 

Anyway, what exactly does "based on" mean?

is the following legal?

int *whee(int *__restrict a)
{
return a - 2;
}
void with_restrict(int * __restrict p)
{
  int i;
  int *q = whee(p);

  for (i = 0; i < 1000; ++i) {
p[i] = q[i];
  }


If so, we'll never be able to get restrict right on a intraprocedural basis,
and it makes restrict completely useless for almost all cases that restricted
pointers escape :)


-- 

dberlin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org


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

[Bug target/29250] [4.0/4.1 Regression] internal compiler error: in extract_insn, at recog.c:2084

[dje at gcc dot gnu dot org]

--- Comment #13 from dje at gcc dot gnu dot org  2006-11-04 04:07 ---
Fixed on mainline, 4.2.0, and 4.1.2.  Won't fix on 4.0 branch.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work|3.4.6 4.2.0 |3.4.6 4.2.0 4.1.2
 Resolution||FIXED
   Target Milestone|4.0.4   |4.1.2


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

[Bug ada/29707] s-osinte.adb:86:13: warning: function "To_Target_Priority" is not referenced

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2006-11-04 00:42 ---
> ll s-osinte.adb
lrwxrwxrwx 1 dave dave 53 Nov  3 02:33 s-osinte.adb ->
/home/dave/gnu/gcc-4.3/gcc/gcc/ada/s-osinte-posix.adb


-- 


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

[Bug ada/29707] New: s-osinte.adb:86:13: warning: function "To_Target_Priority" is not referenced

[danglin at gcc dot gnu dot org]

home/dave/gnu/gcc-4.3/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.3.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include -c -g -O2
-f
PIC -DELF=1 -DLINUX=1  -W -Wall -gnatpg  s-intman.adb -o s-intman.o
/home/dave/gnu/gcc-4.3/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.3.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include -c -g -O2
-f
PIC -DELF=1 -DLINUX=1  -W -Wall -gnatpg  s-osinte.adb -o s-osinte.o
s-osinte.adb:86:04: (style) subprogram body has no previous spec
s-osinte.adb:86:13: warning: function "To_Target_Priority" is not referenced
make[7]: *** [s-osinte.o] Error 1
make[7]: Leaving directory `/home/dave/gnu/gcc-4.3/objdir/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2


-- 
   Summary: s-osinte.adb:86:13: warning: function
"To_Target_Priority" is not referenced
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug other/29700] check requires autogen

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2006-11-03 23:36 
---
> Sorry for not indicating that.  Always specified `-k' in all `make'
> runs.  They yield the results as described.

'make check' and 'make -k check' are certainly not equivalent.  The former
will stop if you don't have autogen, the latter will not.  So autogen is
not required to run 'make -k check'.


-- 


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

[Bug fortran/29699] ICE in trans-decl.c

[eedelman at gcc dot gnu dot org]

--- Comment #1 from eedelman at gcc dot gnu dot org  2006-11-03 23:20 
---
Confirmed.


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||eedelman at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-03 23:20:50
   date||


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

[Bug c++/29706] rejects-valid: missing mem-initializer for virtual base class

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-03 23:20 ---
I think is really a dup of bug 19249.
Though the problem here is slightly different as B() is fully defined and calls
the default constructor which is not defined.

Comeau C/C++ 4.3.8 (Aug 19 2006 13:36:48) for  ONLINE_EVALUATION_Alpha1
Copyright 1988-2006 Comeau Computing.  All rights reserved.
MODE:strict errors C++

"ComeauTest.c", line 7: error: no default constructor exists for class "V"
B() { }   // does not mention constructor of V
^

That is what comeau online gives.


-- 


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

[Bug c++/29706] New: rejects-valid: missing mem-initializer for virtual base class

[jens dot maurer at gmx dot net]

This code snippet

struct V {
  V(int) { }
};

struct B : virtual V
{
  B() { }   // does not mention constructor of V
};

struct D : B
{
  D() : V(0) { }
};

D d; // most derived object of type D

should be valid according to the C++ standard 12.6.2 paragraph 6 (note that B
is not a most derived class).  However, gcc complains about the definition of
the constructor for B, which is wrong, because the constructor for B is not
used to initialize a most derived object (it only initializes the B subobject
of D):

257-demo.cc: In constructor 'B::B()':
257-demo.cc:7: error: no matching function for call to 'V::V()'
257-demo.cc:2: note: candidates are: V::V(int)
257-demo.cc:1: note: V::V(const V&)


-- 
   Summary: rejects-valid: missing mem-initializer for virtual base
class
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jens dot maurer at gmx dot net
 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=29706

[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )

[r_ovidius at eml dot cc]

--- Comment #15 from r_ovidius at eml dot cc  2006-11-03 22:58 ---
Updated summary.  (Happy 2 year birthday, stupid stubborn bug.)


-- 

r_ovidius at eml dot cc changed:

   What|Removed |Added

Summary|SIGSEGV in  |GCJ: Using references drops
   |GC_register_finalizer_inner |finalizers causing all apps
   |()  |to eventually crash  (
   ||SIGSEGV in
   ||GC_register_finalizer_inner
   ||() )


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

[Bug target/19116] -funsafe-math-optimizations make nan compares equal to one another (-finite-math-only should be doing that)

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2006-11-03 22:35 
---
*** Bug 29705 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||james dot me at gmail dot
   ||com


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

[Bug target/29705] gcc optimizes necessary checks for isnan out of existence

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-03 22:35 ---
This is a dup of bug 19116 which was fixed in 4.3.0.

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


-- 

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

[Bug c/29705] New: gcc optimizes necessary checks for isnan out of existence

[james dot me at gmail dot com]

This bug applies at least to gcc version 4.0.3 and the current CVS 4.2.0
20061103. The assembly extracts included below were produced by gcc 4.2.0; the
gcc 4.0.3 extracts are analogous with respect to this problem but are different
in some respects. My particular host is an intel pentium4 xenon.

With certain math optimizations enabled, gcc assumes that a test for isnan will
always fail. This assumption is not correct, and results in the undesired
propagation of NANs into other computations and altered control flow.

This bug is exemplified by the following code which can be compiled without
including any header files. For brevity in the test case, instead of include
files I have used only the prototypes needed to silence gcc's warnings. The
code compiles the same, when  and  are included instead of the
prototypes, or when the prototypes are simply left out all together.

float logf(float);
int printf(const char *fmt, ...);
int isnan();

double test(int i0, int n, double a) {
 double sum = 0.0;
 int i;

 for(i=i0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=29705

[Bug c++/29704] New: ICE: default non-type template argument of pointer-to-member type

[jens dot maurer at gmx dot net]

This little program:

class C;

template 
struct S { };

S<> s;

yields this little ICE:

440-gcc-crash.cc:6: internal compiler error: in uses_template_parms, at
cp/pt.c:5024
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

(I believe the program should be valid, see section 14.3.2p1 in the C++
standard.)


-- 
   Summary: ICE: default non-type template argument of pointer-to-
member type
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jens dot maurer at gmx dot net
 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=29704

[Bug fortran/29702] New: RFE: Column number in error messages.

[brooks dot moses at codesourcery dot com]

In the discussion of PR 29689, the following came up, and seems like a
reasonable request:

 Original Message (excerpted) 
Subject: Re: Emacs and GFortran
Date: Sat, 4 Nov 2006 07:59:04 +1300
From: Nick Roberts <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], emacs-devel@gnu.org
Newsgroups: gmane.emacs.devel,gmane.comp.gcc.fortran

Brooks Moses writes:
> The attached only-slightly-less-trivial patch should fix the 
> regressions, although I have not yet tested it to confirm that.

I guess I'm pushing my luck with current feelings, but would it be
possible to add the column number?

[Previously I wrote:

  The original error message you posted had column number information in the
  error output too:

 gfortran hello.F
  In file hello.F:3

   write(*,) 'Hello!'
1
 Error: Syntax error in WRITE statement at (1)

  it would be nice to be able to use this too.  I think gcc outputs kind of
  information as something like:

  hello.c:3:13: error: blah, blah, blah...

  Emacs can then place the cursor in the relevant column when visiting an error
  (and Vim probably does something similar too).]

-- 
Nick   http://www.inet.net.nz/~nickrob


-- 
   Summary: RFE: Column number in error messages.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brooks dot moses at codesourcery dot com


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

[Bug c++/29701] mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus overload ambiguity

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-03 20:08 ---
I think this is a dup of bug 29518 but since I have not looked to double check
I am going to mark it as a dup just yet.


-- 


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

[Bug other/29700] check requires autogen

[gin at mo dot msk dot ru]

--- Comment #4 from gin at mo dot msk dot ru  2006-11-03 20:03 ---
Subject: Re:  check requires autogen

Sorry for not indicating that.  Always specified `-k' in all `make'
runs.  They yield the results as described.

The gist is that currently the only way to obtain actual test script,
`check.sh', is running `autogen'.  Being unable to make tests in some
subdirectories for that reason certainly may be worked around with
`-k', and that is not a fix.


-- 


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

[Bug c++/29701] mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus overload ambiguity

[eric dot niebler at gmail dot com]

--- Comment #1 from eric dot niebler at gmail dot com  2006-11-03 20:01 
---
Created an attachment (id=12543)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12543&action=view)
preprocessed input file

preprocessed C++ source code.


-- 


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

[Bug c++/29701] New: mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus overload ambiguity

[eric dot niebler at gmail dot com]

Attached preprocessed code compiles with gcc 3.4.4 and gcc 4.0.3, fails with
4.1.1. Compiler is not preferring a function template over a vararg function.


-- 
   Summary: mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus
overload ambiguity
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
GCC target triplet: i686-pc-cygwin


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

[Bug fortran/28004] Warn if intent(out) dummy variable is not set

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2006-11-03 19:59 ---
> I think we should issue a warning but not an error, because you can write code
> that is [...]
Note that you should use "contains" for the code otherwise "foo" is regarded as
real function and the program does not compile.

g95 actually gives only a warning if the variable is not set at all, it does
not give a warning, if it is only set in the if branch. So does ifort. (NAG f95
and sunf95 don't give any warning neither with assigning it in the if branch or
not assigning it at all.)

Using -Wall gfortran states that the variable "x" is not used, but a default
warning that "A dummy argument with an explicit INTENT(OUT) declaration is not
given an explicit value." is more helpful.


-- 


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

[Bug other/29700] check requires autogen

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2006-11-03 19:52 
---
> Certainly ran `make check' in top level build directory,

Your mistake.  Only 'make -k check' is supported.


-- 


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

[Bug other/29700] check requires autogen

[gin at mo dot msk dot ru]

--- Comment #2 from gin at mo dot msk dot ru  2006-11-03 19:43 ---
Subject: Re:  check requires autogen

Certainly ran `make check' in top level build directory, and indicated
that by including parts of `make -w' output, printout of directories
entered and left by `make'.


-- 


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

[Bug other/29700] check requires autogen

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2006-11-03 19:32 
---
> That this package is required to run tests is not even said in
> .  Neither 
> says so.  If it indeed has to be required, this is documentation bug.

It is not, the documentation says:

Finally, you can run the testsuite (which may take a long time):

  cd objdir; make -k check


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug other/29700] New: check requires autogen

[gcc-bugzilla at gcc dot gnu dot org]

Changed nothing in sources, build just from unpacked
`gcc-4.1.1.tar.bz2'.  Still tests try to run `autogen'.

make: Entering directory `gcc-4.1.1-rhysling'
make[1]: Entering directory `gcc-4.1.1-rhysling'
make[2]: Entering directory `gcc-4.1.1-rhysling/fastjar'
make[2]: Leaving directory `gcc-4.1.1-rhysling/fastjar'
make[2]: Entering directory `gcc-4.1.1-rhysling/fixincludes'
autogen -T ../../share/src/gcc-4.1.1/fixincludes/check.tpl
../../share/src/gcc-4.1.1/fixincludes/inclhack.def
make[2]: autogen: Command not found
make[2]: *** [check] Error 127

That this package is required to run tests is not even said in
.  Neither 
says so.  If it indeed has to be required, this is documentation bug.

OTOH, that `check.sh' can not be generated once for all build
configurations, even some minimally featured backup version, also
seems strange.

Environment:
System: Linux 2.2.19-7.1.asp.2.gin #1 Tue Jun 15 16:42:13 MSD 2004 i686 unknown
Architecture: i686

Observed the same on sparc-sun-solaris.
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.1.1/configure --prefix=/home2/gin/usr1
--enable-languages=c,c++,java,objc --with-as=/home2/gin/usr/bin/as
--with-ld=/home2/gin/usr/bin/ld

How-To-Repeat:
make check


-- 
   Summary: check requires autogen
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
 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=29700

[Bug fortran/29699] New: ICE in trans-decl.c

[burnus at gcc dot gnu dot org]

The following program gives an ICE with todays 4.2-branch gfortran.
(I have to find out why gcc-trunk doesn't compile at the moment, then I will
check also gcc-trunk.)

I found the error with: ftp://ftp.nag.co.uk/sc22wg5/ISO_VARYING_STRING/


PROGRAM vocabulary_word_count
  IMPLICIT NONE
  TYPE VARYING_STRING
CHARACTER,DIMENSION(:),ALLOCATABLE :: chars
  ENDTYPE VARYING_STRING

  INTEGER :: list_size=200
CONTAINS
  SUBROUTINE extend_lists
type(VARYING_STRING),DIMENSION(list_size) :: vocab_swap
  ENDSUBROUTINE extend_lists
ENDPROGRAM vocabulary_word_count


vocab.f95: In function 'extend_lists':
vocab.f95:9: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:861


-- 
   Summary: ICE in trans-decl.c
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  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=29699

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[pluto at agmk dot net]

--- Comment #8 from pluto at agmk dot net  2006-11-03 18:56 ---
(In reply to comment #2)
> Indeed, we badly need details. The correct output (which indeed I can see on
> any machine I have at hand, any version of gcc) is:
> 0 9 8 7 6 5 4 3 2 1 1 2 3 1 2 3
> 3 2 1 3 2 1 1 2 3 4 5 6 7 8 9 0

[EMAIL PROTECTED] /tmp]$ g++ -v
Reading specs from /usr/lib/gcc/alpha-pld-linux/4.1.1/specs
Target: alpha-pld-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info
--mandir=/usr/share/man --x-libraries=/usr/lib --enable-shared
--enable-threads=posix --enable-languages=c,c++,fortran,ada --enable-c99
--enable-long-long --disable-multilib --enable-nls --disable-werror
--with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib
--with-slibdir=/lib --without-system-libunwind --without-x --enable-cmath
--with-long-double-128 --with-gxx-include-dir=/usr/include/c++/4.1.1
--disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
alpha-pld-linux
Thread model: posix
gcc version 4.1.1 20060308 (prerelease) (PLD-Linux)

[EMAIL PROTECTED] /tmp]$ uname -a
Linux fly 2.6.2 #3 Wed Feb 11 10:19:22 CET 2004 alpha EV56 unknown PLD Linux

[EMAIL PROTECTED] /tmp]$ ./tmp
0 9 8 7 6 5 4 3 2 1 1 2 3 1 2 3
3 2 1 3 2 1 1 2 3 4 5 6 7 8 9 0


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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

[Bug c++/29435] [4.1 Regression] seg fault with sizeof and templates

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2006-11-03 18:29 
---
*** Bug 29698 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||skalaren_alpinist at abv dot
   ||bg


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

[Bug c++/29698] ICE on sizeof() inside a template func

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-03 18:29 ---
template
 struct pair{};
template 
int foo(INT m)
{
return sizeof(pair);
}


This was never broken in 4.1.1, this was only broken on the 4.1 branch and only
for two weeks at that.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Version|4.1.1   |4.1.2


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

[Bug c++/29698] New: ICE on sizeof() inside a template func

[skalaren_alpinist at abv dot bg]

My OS is Fedora Core 6 - I'm using the compiler, that ships with it.

It crashes on this code:

===
#include 
#include 

template 
int foo(INT m)
{
return sizeof(std::pair);
}

int main(void)
{
std::cout << foo((int)0) << std::endl;
return 0;
}
=

The crash occurs on the return of foo(). In fact, it occurs anytime where
sizeof(std::pair); is used for whatever reason.

The crash says:

ice1.cpp: In function ‘int foo(INT)’:
ice1.cpp:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate...


It's OK when foo() is non-template.
It's OK when you generate an instance of this type and sizeof() the instance
instead. ("std::pair dummy; sizeof(dummy);" works)
It's OK under g++ 3.4 and 3.3 (32-bit though - don't have other x86_64 to
test).

Ouput of g++ -v:
=
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)
===


-- 
   Summary: ICE on sizeof() inside a template func
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skalaren_alpinist at abv dot bg
  GCC host triplet: x86_64-redhat-linux


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

[Bug middle-end/29695] [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ? 0x80 : 0 for unsigned char or unsigned short a

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-11-03 18:03 ---
For arguments, you missed that flag_argument_noalias is set to 2 (or is it 3
now).

It also changes debugging info which is needed in this case to get the correct
debuging info.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||24546
  nThis||
   Severity|enhancement |normal


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

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[pcarlini at suse dot de]

--- Comment #7 from pcarlini at suse dot de  2006-11-03 17:44 ---
Ok, thanks. Ideally, in case the problem unfortunately persists with current
GCC, it would be also useful if you could provide outputs from a debugging
session, because right now what happens after the output of the "forward"
string is a complete mystery... But this kind of "long distance" debugging is
hopeless, in general :( in case the problem persists we need someone able to
reproduce the problem on his machine and looking closely into it...


-- 


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

[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2006-11-03 17:26 ---
Andy pointed out that TYPE_QUAL_VOLATILE only changes the dumped string,
nonetheless it makes checking things easier, I think.


-- 


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

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[lebedev at zhtw dot org dot ru]

--- Comment #6 from lebedev at zhtw dot org dot ru  2006-11-03 17:19 ---
(In reply to comment #5)
> (In reply to comment #4)
> > All in all, I'm afraid we are going to need the help of a target maintainer.
> 
> ...to be sure, would you please post the output of 'gcc -v'? Thanks. 
> 

$ gcc -v
Reading specs from
/opt/pkg/gcc34/bin/../lib/gcc/alphaev56-dec-osf5.1/3.4.6/specs
Configured with: /usr/pkgsrc/lang/gcc34/work/gcc-3.4.6/configure
--enable-languages='c' 'c++' --with-system-zlib --enable-shared
--enable-__cxa_atexit --enable-long-long --with-local-prefix=/usr/pkg/gcc34
--with-libiconv-prefix=/usr/pkg --prefix=/usr/pkg/gcc34
Thread model: posix
gcc version 3.4.6

I'm trying to bootstrap the 4.1.1 version right now. I'll tell you if the but
still present in it.


-- 


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

[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2006-11-03 17:03 ---
A good introduction into restricted can be found at
http://developers.sun.com/sunstudio/articles/cc_restrict.html

Maybe this is something for the array implementation in gfortran?
I don't fully understand how the data part of arrays are used, but I would
assume they are pointers where the "restricted" part is not given.
As Fortran requires "target" for arrays to which a pointer may point, it should
be easy to add "restricted" in the non-target case; according to the article it
helps the compiler quit a bit to optimize - as "const" does.


-- 


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

[Bug fortran/29697] New: gfortran should use TYPE_QUAL_CONST etc.

[burnus at gcc dot gnu dot org]

I came accross this when implementing the volatile statement/attribute
(PR29601), where I used:
> + if (sym->attr.volatile_)
> +   TREE_THIS_VOLATILE (decl) = 1;

Ian Lance Taylor noted that:
"I think you will also want to give DECL a type which is
volatile-qualified:
build_qualified_type (original_type, TYPE_QUAL_VOLATILE)"

tree.h offers:
- TYPE_QUAL_CONST
- TYPE_QUAL_VOLATILE
- TYPE_QUAL_RESTRICT

whereas fortran only "uses":
DEF_PRIMITIVE_TYPE (BT_VOLATILE_PTR,
build_pointer_type
 (build_qualified_type (void_type_node,
TYPE_QUAL_VOLATILE)))

I think TYPE_QUAL_CONST should be used for all PARAMETERs (unless I miss
something), maybe also for intent(in) pointers etc.

Currently, using "const int" in C gives in (-dump-tree-original) "const int"
whereas "integer, parameter ::" in Fortran only gives "int".

  * * *

The meaning can be found in the C99 standard (6.7.3):

"An object that has volatile-qualified type may be modified in ways unknown to
the implementation or have other unknown side effects. Therefore any expression
referring to such an object shall be evaluated strictly according to the rules
of the abstract machine, as described in 5.1.2.3. Furthermore, at every
sequence point the value last stored in the object shall agree with that
prescribed by the abstract machine, except as modified by the unknown factors
mentioned previously.114) What constitutes an access to an object that
has volatile-qualified type is implementation-defined."

"An object that is accessed through a restrict-qualified pointer has a special
association with that pointer. This association, defined in 6.7.3.1 below,
requires that all accesses to that object use, directly or indirectly, the
value of that particular pointer.115) The intended use of the restrict
qualifier (like the register storage class) is to promote optimization, and
deleting all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning (i.e.,
observable
behavior)." (And more detailed and formal in the paragraphs below.)


-- 
   Summary: gfortran should use TYPE_QUAL_CONST etc.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  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=29697

[Bug fortran/25057] default initialization and DATA statement conflict

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2006-11-03 16:30 
---
This is probably a duplicate of 24978.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||24978


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

[Bug fortran/29689] gfortran should use g77-compatible format for error message

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2006-11-03 16:12 
---
I agree and already tested for Brooks on 4.2 last night.


-- 


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

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2006-11-03 15:39 ---
(In reply to comment #4)
> All in all, I'm afraid we are going to need the help of a target maintainer.

...to be sure, would you please post the output of 'gcc -v'? Thanks. 


-- 


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

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2006-11-03 15:36 ---
Oh well, something seems seriously broken, certainly not in the
target-independent parts of the library proper, however. Did this ever work
with previous GCCs? Also, I would ask you to test a current compiler (4.1.1,
for example), before anything else, because the 3.4.x branch is not maintained
anymore.

All in all, I'm afraid we are going to need the help of a target maintainer.


-- 


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

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[lebedev at zhtw dot org dot ru]

--- Comment #3 from lebedev at zhtw dot org dot ru  2006-11-03 15:29 ---

(In reply to comment #2)
> Indeed, we badly need details. The correct output (which indeed I can see on
> any machine I have at hand, any version of gcc) is:
> 0 9 8 7 6 5 4 3 2 1 1 2 3 1 2 3
> 3 2 1 3 2 1 1 2 3 4 5 6 7 8 9 0
> 

This works well for me too on i386 freebsd-6.2-prerelease.
But this happens under Tru64:

[EMAIL PROTECTED]:~$ uname -a
OSF1 axp3.umc8.mai.ru V5.1 2650 alpha
[EMAIL PROTECTED]:~$ g++ --version
g++ (GCC) 3.4.6
Copyright (C) 2006 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.

[EMAIL PROTECTED]:~$ cat demo.cpp
#include 
#include 
#include 
#include 

int main()
{
  std::string s = "0123456789";
  std::copy(s.begin(), s.end(), std::ostream_iterator(std::cout, " "));
  std::cout << std::endl;
  std::copy(s.rbegin(), s.rend(), std::ostream_iterator(std::cout, " "));
  std::cout << std::endl;
}
[EMAIL PROTECTED]:~$ g++ demo.cpp 
[EMAIL PROTECTED]:~$ ./a.out 
0 1 2 3 4 5 6 7 8 9 

[EMAIL PROTECTED]:~$ ./a.out | od -h
000  2030 2031 2032 2033 2034 2035 2036 2037
020  2038 2039 0a0a
026


-- 


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

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2006-11-03 15:08 ---
Indeed, we badly need details. The correct output (which indeed I can see on
any machine I have at hand, any version of gcc) is:
0 9 8 7 6 5 4 3 2 1 1 2 3 1 2 3
3 2 1 3 2 1 1 2 3 4 5 6 7 8 9 0


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

BUG report : Internal compiler error

[R.J.Sivakumar]

hi
  this is the error iam getting when i try to cross compile ltib BSP of linux 
2.6.10 for arm11 platfrom from SUSE10 host 

 arm-none-linux-gnueabi-ranlib ./libgcov.a
arm-none-linux-gnueabi-gcc -O2  -DIN_GCC-W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include  -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc -I../../gcc/. 
-I../../gcc/../include  -fexceptions -c ../../gcc/unwind-dw2.c -o 
libgcc/./unwind-dw2.o
../../gcc/unwind-dw2.c: In function 'extract_cie_info':
../../gcc/unwind-dw2.c:328: warning: pointer targets in passing argument 1 of 
'strlen' differ in signedness
../../gcc/unwind-dw2.c:381: warning: dereferencing type-punned pointer will 
break strict-aliasing rules
../../gcc/unwind-dw2.c: In function 'execute_cfa_program':
../../gcc/unwind-dw2.c:844: warning: dereferencing type-punned pointer will 
break strict-aliasing rules
../../gcc/unwind-dw2.c: In function 'uw_frame_state_for':
../../gcc/unwind-dw2.c:1060: warning: dereferencing type-punned pointer will 
break strict-aliasing rules
../../gcc/unwind-dw2.c: In function 'init_dwarf_reg_size_table':
../../gcc/unwind-dw2.c:1272: internal compiler error: in 
arm_dbx_register_number, at config/arm/arm.c:15183

Please suggest me to overcome this,

Best regards
sivakumar.R.J

[Bug libstdc++/29696] std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[chris at bubblescope dot net]

--- Comment #1 from chris at bubblescope dot net  2006-11-03 15:00 ---
What exactly is the problem? It doesn't compile? It doesn't produce the right
output? It crashes?


-- 

chris at bubblescope dot net changed:

   What|Removed |Added

 CC||chris at bubblescope dot net


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

[Bug target/29201] [4.2/4.3 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3

[tbm at cyrius dot com]

--- Comment #3 from tbm at cyrius dot com  2006-11-03 14:29 ---
(In reply to comment #2)
> I posted the patch for this bug at:
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00023.html

So I guess we're waiting for Ian (or someone) to approve the new patch in
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00869.html
Right?


-- 


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

[Bug fortran/29067] gfc_resolve_expr(): Bad expression type

[fxcoudert at gcc dot gnu dot org]

--- Comment #21 from fxcoudert at gcc dot gnu dot org  2006-11-03 14:28 
---
Fixed on all active branches.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[4.1/4.2 only]  |gfc_resolve_expr(): Bad
   |gfc_resolve_expr(): Bad |expression type
   |expression type |
   Target Milestone|--- |4.1.2


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

[Bug fortran/29067] [4.1/4.2 only] gfc_resolve_expr(): Bad expression type

[fxcoudert at gcc dot gnu dot org]

--- Comment #20 from fxcoudert at gcc dot gnu dot org  2006-11-03 14:26 
---
Subject: Bug 29067

Author: fxcoudert
Date: Fri Nov  3 14:25:56 2006
New Revision: 118457

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

* decl.c (gfc_set_constant_character_len): NULL-terminate the
character constant string.
* data.c (create_character_intializer): Likewise.
* expr.c (gfc_simplify_expr): NULL-terminate the substring
character constant.
* primary.c (match_hollerith_constant): NULL-terminate the
character constant string.

* gfortran.dg/pr29067.f: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pr29067.f
  - copied unchanged from r118456,
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/pr29067.f
Modified:
branches/gcc-4_1-branch/gcc/fortran/ChangeLog
branches/gcc-4_1-branch/gcc/fortran/data.c
branches/gcc-4_1-branch/gcc/fortran/decl.c
branches/gcc-4_1-branch/gcc/fortran/expr.c
branches/gcc-4_1-branch/gcc/fortran/primary.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/29689] gfortran should use g77-compatible format for error message

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2006-11-03 14:14 
---
Commited to mainline as revision 118450. Maybe we want to include this into 4.2
before 4.2.0 is released? I think that would be the best thing to do; opinions?


-- 

fxcoudert 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|NEW |ASSIGNED
   Keywords||patch
  Known to fail||4.1.2 4.2.0
  Known to work||4.3.0


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

[Bug libstdc++/29696] New: std::string::reverse_iterator doesn't work at all on Tru64 UNIX

[lebedev at zhtw dot org dot ru]

std::copy with reverse_iterator in this example doesn't work correctly on alpha
under Tru64 UNIX 5.1b

#include 
#include 
#include 
#include 

class trans
{
public:
  int operator()(char c) { std::clog << c << std::endl; return c - '0'; };
};

int main()
{
  std::string s = "0987654321123123";
  std::copy(s.begin(), s.end(), std::ostream_iterator(std::cout, " "));
  std::cout << std::endl;
  std::copy(s.rbegin(), s.rend(), std::ostream_iterator(std::cout, " "));
  std::cout << std::endl;
}


-- 
   Summary: std::string::reverse_iterator doesn't work at all on
Tru64 UNIX
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lebedev at zhtw dot org dot ru
 GCC build triplet: alphaev56-dec-osf5.1
  GCC host triplet: alphaev56-dec-osf5.1
GCC target triplet: alphaev56-dec-osf5.1


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

[Bug fortran/23060] %VAL, %REF and %DESCR constructs not implemented

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2006-11-03 14:11 
---
Adding %REF and %DESCR to the summary. Documentation available here:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Functions-and-Subroutines.html


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-09-28 07:58:23 |2006-11-03 14:11:48
   date||
Summary|%VAL construct not  |%VAL, %REF and %DESCR
   |implemented |constructs not implemented


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

[Bug target/16350] gcc only understands little endian ARM systems

[mkl at pengutronix dot de]

--- Comment #12 from mkl at pengutronix dot de  2006-11-03 13:49 ---
Created an attachment (id=12542)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12542&action=view)
fix target linker emulation for arm elf and eabi (take 2)

If you try to build a big-endian eabi toolchain, you need another fix (see
patch of gcc/config/arm/linux-eabi.h)


-- 

mkl at pengutronix dot de changed:

   What|Removed |Added

  Attachment #12042|0   |1
is obsolete||


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

[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code

[rsandifo at gcc dot gnu dot org]

--- Comment #18 from rsandifo at gcc dot gnu dot org  2006-11-03 13:30 
---
OK, I step up to the guillotine...


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-06-14 15:09:09 |2006-11-03 13:30:24
   date||


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

[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code

[hp at gcc dot gnu dot org]

--- Comment #17 from hp at gcc dot gnu dot org  2006-11-03 13:27 ---
(Re: comment #16)
Thank you, be my guest! :-)
Actually, it's a mistake that I'm still assigned; I should've unassigned myself
after a week with no activity from my side.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|hp 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=27528

[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code

[rsandifo at gcc dot gnu dot org]

--- Comment #16 from rsandifo at gcc dot gnu dot org  2006-11-03 13:23 
---
I'm testing a possible patch.  I didn't want to reassign the bug
to myself in case H-P is still looking at it too.

At this stage I have no idea how successful the patch will be.
It seems to me that, as with most other gcc extensions, the "right"
behaviour isn't really defined here.  The warning and error don't
seem unreasonable from a gcc hacker's perspective, but I can see why
users would expect it to work.  My main fear is that, even if the
patch survives the normal testing (and a kernel build, which I
intend to try too), it could easily break another unstated
assumption in other user code.

Richard


-- 


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

[Bug fortran/29067] [4.1/4.2 only] gfc_resolve_expr(): Bad expression type

[fxcoudert at gcc dot gnu dot org]

--- Comment #19 from fxcoudert at gcc dot gnu dot org  2006-11-03 12:29 
---
Subject: Bug 29067

Author: fxcoudert
Date: Fri Nov  3 12:28:57 2006
New Revision: 118456

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

* decl.c (gfc_set_constant_character_len): NULL-terminate the
character constant string.
* data.c (create_character_intializer): Likewise.
* expr.c (gfc_simplify_expr): NULL-terminate the substring
character constant.
* primary.c (match_hollerith_constant): NULL-terminate the
character constant string.

* gfortran.dg/pr29067.f: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/pr29067.f
  - copied unchanged from r118338,
trunk/gcc/testsuite/gfortran.dg/pr29067.f
Modified:
branches/gcc-4_2-branch/gcc/fortran/ChangeLog
branches/gcc-4_2-branch/gcc/fortran/data.c
branches/gcc-4_2-branch/gcc/fortran/decl.c
branches/gcc-4_2-branch/gcc/fortran/expr.c
branches/gcc-4_2-branch/gcc/fortran/primary.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/27895] [4.1/4.2 only] problem with RESHAPE and zero-sized arrays

[fxcoudert at gcc dot gnu dot org]

--- Comment #13 from fxcoudert at gcc dot gnu dot org  2006-11-03 12:24 
---
The patch in comments 10 and 12 will need to be backported to 4.2 and 4.1.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.2.0 4.1.2 4.3.0   |4.2.0 4.1.2
  Known to work||4.3.0
Summary|problem with RESHAPE and|[4.1/4.2 only] problem with
   |zero-sized arrays   |RESHAPE and zero-sized
   ||arrays


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

[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

[ebotcazou at gcc dot gnu dot org]

--- Comment #21 from ebotcazou at gcc dot gnu dot org  2006-11-03 11:58 
---
> Is this actually fixed?

It is on my system, either x86_64-suse-linux -m64/-m32 or i586-suse-linux,
with binutils 2.17.

> Here are my current testresults:
> http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00094.html

Ouch!

> Still shows breakage on FC6.

Which version of binutils?


-- 


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

[Bug libfortran/27895] problem with RESHAPE and zero-sized arrays

[fxcoudert at gcc dot gnu dot org]

--- Comment #12 from fxcoudert at gcc dot gnu dot org  2006-11-03 11:51 
---
Subject: Bug 27895

Author: fxcoudert
Date: Fri Nov  3 11:51:09 2006
New Revision: 118455

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118455
Log:
PR libfortran/27895

* intrinsics/reshape_generic.c (reshape_internal): Fix so that it
works correctly for zero-sized arrays.
* m4/reshape.m4: Likewise.
* generated/reshape_r16.c: Regenerate.
* generated/reshape_c4.c: Regenerate.
* generated/reshape_i4.c: Regenerate.
* generated/reshape_c16.c: Regenerate.
* generated/reshape_r10.c: Regenerate.
* generated/reshape_r8.c: Regenerate.
* generated/reshape_c10.c: Regenerate.
* generated/reshape_c8.c: Regenerate.
* generated/reshape_i8.c: Regenerate.
* generated/reshape_i16.c: Regenerate.
* generated/reshape_r4.c: Regenerate.

* gcc/testsuite/gfortran.dg/zero_sized_1.f90: Uncomment checks
for RESHAPE.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/zero_sized_1.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/reshape_c10.c
trunk/libgfortran/generated/reshape_c16.c
trunk/libgfortran/generated/reshape_c4.c
trunk/libgfortran/generated/reshape_c8.c
trunk/libgfortran/generated/reshape_i16.c
trunk/libgfortran/generated/reshape_i4.c
trunk/libgfortran/generated/reshape_i8.c
trunk/libgfortran/generated/reshape_r10.c
trunk/libgfortran/generated/reshape_r16.c
trunk/libgfortran/generated/reshape_r4.c
trunk/libgfortran/generated/reshape_r8.c
trunk/libgfortran/intrinsics/reshape_generic.c
trunk/libgfortran/m4/reshape.m4


-- 


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

[Bug libfortran/29627] [4.1 only] partial unformatted reads shouldn't succeed

[tkoenig at gcc dot gnu dot org]

--- Comment #9 from tkoenig at gcc dot gnu dot org  2006-11-03 11:30 ---
Fixed on 4.2 too; will need to regtest for backporting
to 4.1.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2
  Known to work||4.3.0 4.2.0
Summary|[4.2/4.1 only] partial  |[4.1 only] partial
   |unformatted reads shouldn't |unformatted reads shouldn't
   |succeed |succeed


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

[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

[pcarlini at suse dot de]

--- Comment #20 from pcarlini at suse dot de  2006-11-03 11:28 ---
I can confirm that this specific regression disappeared for me. But I suspect
something also depends on the binutils version and other details, I'm using a
stock 2.17 on this machine...


-- 


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

[Bug middle-end/29695] [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ? 0x80 : 0 for unsigned char or unsigned short a

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2006-11-03 11:24 ---
Testing a patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-11-03 11:24:28
   date||


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

[Bug middle-end/29695] New: [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ? 0x80 : 0 for unsigned char or unsigned short a

[jakub at gcc dot gnu dot org]

extern void abort (void);

int
f1 (void)
{
  int a = 128;
  return (a & 0x80) ? 0x80 : 0;
}

int
f2 (void)
{
  unsigned char a = 128;
  return (a & 0x80) ? 0x80 : 0;
}

int
main (void)
{
  if (f1 () != 128)
abort ();
  if (f2 () != 128)
abort ();
  return 0;
}

f2 () is miscompiled with -O2 (on x86-64 and ppc at least), returns -128 rather
than 128.


-- 
   Summary: [4.1/4.2/4.3 Regression] Folding breaks (a & 0x80) ?
0x80 : 0 for unsigned char or unsigned short a
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug libfortran/29627] [4.2/4.1 only] partial unformatted reads shouldn't succeed

[tkoenig at gcc dot gnu dot org]

--- Comment #8 from tkoenig at gcc dot gnu dot org  2006-11-03 11:22 ---
Subject: Bug 29627

Author: tkoenig
Date: Fri Nov  3 11:22:27 2006
New Revision: 118453

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118453
Log:
2006-11-03  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/29627
Backport from trunk
* libgfortran.h: Add ERROR_SHORT_RECORD
* runtime/error.c (translate_error): Add case
for ERROR_SHORT_RECORD.
* io/transfer.c (read_block_direct):  Separate codepaths
for stream and record unformatted I/O.  Remove unneeded
tests for standard input, padding and formatted I/O.
If the record is short, read in as much data as possible,
then raise the error.

2006-11-03  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/29627
Backport from trunk
* gfortran.dg/unf_short_record_1.f90:  New test.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/unf_short_record_1.f90
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
branches/gcc-4_2-branch/libgfortran/ChangeLog
branches/gcc-4_2-branch/libgfortran/io/transfer.c
branches/gcc-4_2-branch/libgfortran/libgfortran.h
branches/gcc-4_2-branch/libgfortran/runtime/error.c


-- 


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

[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test

[bkoz at gcc dot gnu dot org]

--- Comment #19 from bkoz at gcc dot gnu dot org  2006-11-03 10:46 ---

Is this actually fixed?

Here are my current testresults:
http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00094.html

Still shows breakage on FC6. Sorry, hardware constrained at the moment and
don't have other linuxes around as per usual. Backtraces now of the form:

Program received signal SIGABRT, Aborted.
0x007e8402 in __kernel_vsyscall ()
(gdb) where
#0  0x007e8402 in __kernel_vsyscall ()
#1  0x00befd40 in raise () from /lib/libc.so.6
#2  0x00bf1591 in abort () from /lib/libc.so.6
#3  0x001c2d57 in base_of_encoded_value (encoding=, 
context=0x6) at /mnt/share/src/gcc/libstdc++-v3/../gcc/unwind-pe.h:122
#4  0x001c2ded in parse_lsda_header (context=0xbfa272f4, 
p=0x110001 "ELF\001\001\001", info=0xbfa271d0)
at /mnt/share/src/gcc/libstdc++-v3/../gcc/unwind-pe.h:286
#5  0x001c30f2 in __gxx_personality_v0 (version=1, actions=1, 
exception_class=5138137972254386944, ue_header=0x8504038, 
context=0xbfa272f4)
at /mnt/share/src/gcc/libstdc++-v3/libsupc++/eh_personality.cc:435
#6  0x00d90b51 in _Unwind_RaiseException (exc=0x8504038)
at /mnt/share/src/gcc/gcc/unwind.inc:117
#7  0x001c362d in __cxa_throw (obj=0x8504058, tinfo=0x804a990, dest=0)
at /mnt/share/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:71
#8  0x08049186 in Buf::overflow (this=0xbfa2756c)
at
/mnt/share/src/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/write/char/1.cc:40
#9  0x0019cfdb in std::basic_streambuf >::xsputn
(this=0xbfa2756c, __s=0x804957c "a", __n=1)
at
/mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/bits/streambuf.tcc:102
#10 0x00193ad1 in std::ostream::write (this=0xbfa274e0, __s=0x804957c "a", 
__n=1)
at /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/streambuf:447
#11 0x08049272 in test01 ()
at
/mnt/share/src/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/write/char/1.cc:52
#12 0x08049426 in main ()
at
/mnt/share/src/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/write/char/1.cc:72


-- 


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

[Bug other/29694] missed warnings about comparisons which are always true/false.

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2006-11-03 10:44 ---
(In reply to comment #1)
> Adding -W/-Wextra and we get a warning:
> t.c: In function �foo�:
> t.c:3: warning: comparison of unsigned expression < 0 is always false
> t.c:5: warning: comparison of unsigned expression >= 0 is always true
> 
> 
> I always forget what -Wextra is for.

what about -Walways-true ?



-Walways-true

   Warn about comparisons which are always true such as testing if
   unsigned values are greater than or equal to zero. This warning
   is enabled by -Wall.




-- 


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

[Bug other/29694] missed warnings about comparisons which are always true/false.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-11-03 10:39 ---
Adding -W/-Wextra and we get a warning:
t.c: In function ‘foo’:
t.c:3: warning: comparison of unsigned expression < 0 is always false
t.c:5: warning: comparison of unsigned expression >= 0 is always true


I always forget what -Wextra is for.


-- 


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

[Bug other/29694] New: missed warnings about comparisons which are always true/false.

[pluto at agmk dot net]

unsigned foo( unsigned i )
{
if ( i < 0 )
i++;
if ( i >= 0 )
i++;
return i;
}

g++ 412svn/420svn with `-O2 -Wall' reports no errors.


-- 
   Summary: missed warnings about comparisons which are always
true/false.
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: ix86-linux


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