[Bug rtl-optimization/36673] IRA -O3 -fno-pic ICE in save_con_fun_n, at caller-save.c:1389

[aldot at gcc dot gnu dot org]

--- Comment #2 from aldot at gcc dot gnu dot org  2008-06-30 08:23 ---
CC'ing Vladimir.


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot
   ||org, vmakarov at redhat dot
   ||com


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

[Bug target/36669] Wrong versioning for __float128

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2008-06-30 09:40 ---
Subject: Re:  Wrong versioning for __float128

On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:

> BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
> That means all __float128 functions are linked in as hidden functions.
> Changing to @GCC_4.3.0 won't make any differences since the ones in
> libgcc_s.so are never used.

They are used if the compiler uses shared libgcc, which is the default for 
C++ compilations, for example.


-- 


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

[Bug middle-end/36671] [4.4 Regression]: gfortran.dg/associated_1.f90

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-06-30 09:51 ---
The problem is that the function x has the MALLOC flag.  Why is this so?  This
causes the use of the argument memory to be missed.

I see in generic trans-decl.c code

/* Get a basic decl for an external function.  */

tree
gfc_get_extern_function_decl (gfc_symbol * sym)
{
...

  /* If the return type is a pointer, avoid alias issues by setting
 DECL_IS_MALLOC to nonzero. This means that the function should be
 treated as if it were a malloc, meaning it returns a pointer that
 is not an alias.  */
  if (POINTER_TYPE_P (type))
DECL_IS_MALLOC (fndecl) = 1;



static void
build_function_decl (gfc_symbol * sym)
{
...

  /* If the return type is a pointer, avoid alias issues by setting
 DECL_IS_MALLOC to nonzero. This means that the function should be
 treated as if it were a malloc, meaning it returns a pointer that
 is not an alias.  */
  if (POINTER_TYPE_P (type))
DECL_IS_MALLOC (fndecl) = 1;


I guess I'll have to re-organize the code to not ignore arguments to
malloc functions.

Anyway, the patch only uncovered this latent problem :(


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-06-30 09:51:50
   date||


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

[Bug c++/36662] [4.3/4.4 Regression] vector vs template

[jakub at gcc dot gnu dot org]

-- 

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 |2008-06-30 11:03:07
   date||


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

[Bug target/36669] Wrong versioning for __float128

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-06-30 11:34 ---
HJ, why do you think they should be @@GCC_4.3.0?  They got introduced with

2001-05-25  Richard Henderson  <[EMAIL PROTECTED]>

   * libgcc-std.ver: Export XFmode and TFmode versions of symbols.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug debug/36668] [4.4 Regression] FAIL: g++.dg/other/PR23205.C scan-assembler .stabs.*foobar:c=i

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-06-30 11:36 ---
I guess this was honza.  I see this as well on x86_64.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-06-30 11:36:16
   date||
Summary|FAIL: g++.dg/other/PR23205.C|[4.4 Regression] FAIL:
   |scan-assembler  |g++.dg/other/PR23205.C scan-
   |.stabs.*foobar:c=i  |assembler .stabs.*foobar:c=i
   Target Milestone|--- |4.4.0


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

[Bug middle-end/36671] [4.4 Regression]: gfortran.dg/associated_1.f90

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-06-30 11:40 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords||alias, wrong-code
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug middle-end/36671] [4.4 Regression]: gfortran.dg/associated_1.f90

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-06-30 11:40 ---
Subject: Bug 36671

Author: rguenth
Date: Mon Jun 30 11:39:53 2008
New Revision: 137271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137271
Log:
2008-06-30  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/36671
* tree-ssa-structalias.c (handle_lhs_call): Add flags argument,
handle calls from ECF_MALLOC functions.
(handle_pure_call): ECF_MALLOC functions do not return
call-used memory.
(find_func_aliases): Handle all calls, adjust calls to handle_lhs_call.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug tree-optimization/36648] [4.3/4.4 Regression] segfault in global constructor with -O3

[irar at gcc dot gnu dot org]

--- Comment #6 from irar at gcc dot gnu dot org  2008-06-30 11:44 ---
Subject: Bug 36648

Author: irar
Date: Mon Jun 30 11:43:55 2008
New Revision: 137272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137272
Log:
PR tree-optimization/36648
* tree-vect-transform.c (vect_do_peeling_for_loop_bound): Divide
number of prolog iterations by step. Fix the comment.


Added:
trunk/gcc/testsuite/g++.dg/vect/pr36648.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug tree-optimization/36648] [4.3/4.4 Regression] segfault in global constructor with -O3

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-06-30 13:29 ---
(In reply to comment #4)
> HJ, why do you think they should be @@GCC_4.3.0?  They got introduced with
> 
> 2001-05-25  Richard Henderson  <[EMAIL PROTECTED]>
> 
>* libgcc-std.ver: Export XFmode and TFmode versions of symbols.
> 

A version should be defined when the symbol was defined, not when
the version map was created. In any case, the problem was introduced
by revision 124775 which failed to include those 3 TF symbols in
libgcc-x86_64-glibc.ver when it was added.


-- 


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-06-30 13:34 ---
(In reply to comment #3)
> Subject: Re:  Wrong versioning for __float128
> 
> On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
> 
> > BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
> > That means all __float128 functions are linked in as hidden functions.
> > Changing to @GCC_4.3.0 won't make any differences since the ones in
> > libgcc_s.so are never used.
> 
> They are used if the compiler uses shared libgcc, which is the default for 
> C++ compilations, for example.

How many C++ applications use __float128 on Linux/x86-64? There is no
complete run-time support for it. FWIW, there is no gdb support for
__float128 either.


-- 


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

[Bug target/36669] Wrong versioning for __float128

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-06-30 13:35 ---
Ok, so if we already shipped the "broken" version we cannot do anything here
(WONTFIX), otherwise we can fix it.


-- 


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2008-06-30 13:38 ---
(In reply to comment #7)
> Ok, so if we already shipped the "broken" version we cannot do anything here
> (WONTFIX), otherwise we can fix it.
> 

That is my opinion.

BTW, I consider __float128 as experimental until we have printf/scanf
and strtoX support.


-- 


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

[Bug target/36669] Wrong versioning for __float128

[joseph at codesourcery dot com]

--- Comment #9 from joseph at codesourcery dot com  2008-06-30 13:39 ---
Subject: Re:  Wrong versioning for __float128

On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:

> > > BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
> > > That means all __float128 functions are linked in as hidden functions.
> > > Changing to @GCC_4.3.0 won't make any differences since the ones in
> > > libgcc_s.so are never used.
> > 
> > They are used if the compiler uses shared libgcc, which is the default for 
> > C++ compilations, for example.
> 
> How many C++ applications use __float128 on Linux/x86-64? There is no
> complete run-time support for it. FWIW, there is no gdb support for
> __float128 either.

They probably aren't used much yet; I was simply answering the "never 
used", as a C++ application built with default options will end up using 
the shared libgcc.


-- 


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

[Bug c/36675] New: va_list argument breaks inlining (ambiguous warning).

[laurent dot deniau at cern dot ch]

If it's not a bug (the code run correctly), I suggest that the first warning
below should say "can never be inlined because it uses va_list argument". But I
do not understand why an argument of type va_list forbid inlining (not observed
in previous version AFAIK) while I understand why ellipsis can forbid it.

gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Target: i486-linux-gnu

gcc -std=c99 -Wall -W -Winline -O3 variadic.c
variadic.c: In function 'fv':
variadic.c:8: warning: function 'fv' can never be inlined because it uses
variable argument lists
variadic.c: In function 'vf':
variadic.c:8: warning: inlining failed in call to 'fv': function not inlinable
variadic.c:21: warning: called from here

cat variadic.c
#include 
#include 

static inline int f(int a, va_list va) {
  return a + va_arg(va,int);
}

static inline int fv(int a, va_list va) {
  int res;
  va_list vac;
  va_copy(vac, va);
  res = f(a, vac);
  va_end(vac);
  return res;
}

static int vf(int a, ...) {
  int ret;
  va_list va;
  va_start(va, a);
  ret = fv(a, va);
  va_end(va);
  return ret;
}

int main(void) {
  printf("%d\n", vf(1,2));
}


-- 
   Summary: va_list argument breaks inlining (ambiguous warning).
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent dot deniau at cern dot ch
  GCC host triplet: Debian etch i486 (x86_32) and x86_64


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

[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

[dfranke at gcc dot gnu dot org]

--- Comment #8 from dfranke at gcc dot gnu dot org  2008-06-30 14:17 ---
In PR35248, Richard wrote:
> libgcc_s goes into slibdir which is set as
>
> AC_ARG_WITH(slibdir,
> [  --with-slibdir=DIR  shared libraries in DIR [[LIBDIR]]],
> slibdir="$with_slibdir",
> if test "${enable_version_specific_runtime_libs+set}" = set; then
>   slibdir='$(libsubdir)'
> elif test "$host" != "$target"; then
>   slibdir='$(build_tooldir)/lib'
> else
>   slibdir='$(libdir)'
> fi)
> AC_SUBST(slibdir)
> 
> and libsubdir is (should be)
> 
> libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
>
> but indeed, the (shared and .so link) libs end up in
> $(libdir)/gcc/$(target_noncanonical)/lib{,64} instead.

In ./gcc/libgcc.mvars, we have

  SHLIB_INSTALL = $(mkinstalldirs) $(DESTDIR)$(slibdir)@shlib_slibdir_qual@;
[...]

where $(DESTDIR)$(libdir) seems to be correct for me. However, the last part
(@shlib_slibdir_qual@) is substituted in libgcc/Makefile.in(install-shared)
with $(MULTIOSSUBDIR) which is based on `$(CC) $(CFLAGS)
-print-multi-os-directory)`, here '../lib64'.


Hope this helps and rings a bell with someone ...?!


-- 


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

[Bug fortran/36676] New: Namelist Comments Problems

[mrnorman at ncsu dot edu]

I'm having a failure on reading in a namelist in gfortran. The version
information is below:

bash-3.2$ gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin9.3.0
Configured with: /var/tmp/gfortran-20080530/ibin/../gcc/configure
--prefix=/usr/local/gfortran --enable-languages=c,fortran
--with-gmp=/var/tmp/gfortran-20080530/gfortran_libs --enable-bootstrap
--with-included-gettext
Thread model: posix
gcc version 4.4.0 20080530 (experimental) [trunk revision 136204] (GCC)


What's happening is I have a namelist which begins with:

&INPUT

!!!
!! DOMAIN AND INITIAL PARAMS !!
!!!

nxc = 100,  !Number of cells




And when it reads in, I get the following error:
bash-3.2$ ./Transport1D
At line 42 of file /Users/rossnorm/NCAR08/1D/src/mem_nml.f90 (unit = 101, file
= 'Transport1D.namelist')
Fortran runtime error: Cannot match namelist object name
!!!nxc




However, if I change the beginning of the namelist to the following:
&INPUT

!!!
!! DOMAIN AND INITIAL PARAMS !!

nxc = 100,  !Number of cells



the whole namelist is read in fine, and the correct values can be printed back
out to stdout internally. So, that last line of "!" is for some reason
causing a failure in the gfortran namelist reading routines when I do not
believe there should be any hinderance according to the standards. Just in case
you want my code to read in the namelist and the entire namelist itself (the
namelist which failed), it is below. In the module mem_nml.f90, the subroutine
readNamelist() is what reads in the values.





mem_nml.f90
!Module to read input parameters for a 1D transport
!simulation. The file must be 'Transport1D.namelist'

module mem_nml
implicit none
integer, save :: nxc
double precision, save :: dleft
double precision, save :: dright
integer, save :: init_type
double precision, save :: dt
double precision, save :: max_courant
double precision, save :: sim_time
integer, save :: time_method
integer, save :: sd_timesolver
integer, save :: subgrid_approx
integer, save :: linear_lim
integer, save :: ppm_filter
logical, save :: pd_filter
character*100,save :: outfile_prefix

contains

subroutine readNamelist()
implicit none

namelist /INPUT/nxc,&
dleft,  &
dright, &
init_type,  &
dt, &
max_courant,&
sim_time,   &
time_method,&
sd_timesolver,  &
subgrid_approx, &
linear_lim, &
ppm_filter, &
pd_filter,  &
outfile_prefix

open(unit = 101, file = 'Transport1D.namelist', action = 'read')
read(unit = 101, nml = INPUT)
close(unit = 101)

endsubroutine

endmodule mem_nml















Transport1D.namelist
&INPUT

!!!
!! DOMAIN AND INITIAL PARAMS !!
!!!

nxc = 100,  !Number of cells

dleft = 0., !Domain left location (meters)

dright = 1.,!Domain right location (meters)
!dright must be < dleft

!Note that the grid spacing is calculated dynamically as:
!(domain length) / nxc   =   (dright - dleft) / nxc

init_type = 1,  !Type of initialization to use
!   1: sine wave
!   2: rectangle wave
!   3: triangle wave
!   4: irregular signal
!   5: "double hump"







!!!
!!! TIME INTEGRATION PARAMS !!!
!!!

dt = 0.000, !Time step (seconds)
!A value <= 0 will invoke automated calculation
!of time step based on max domain wave speed.

max_courant = 2.0,  !This specifies the maximum Courant number desired
!during the simulation.

[Bug c/36675] va_list argument breaks inlining (ambiguous warning).

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-06-30 15:46 ---
The inlining is prohibited by the use of va_start, va_next and va_end, not
by merely passing around va_list.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/36675] va_list argument breaks inlining (ambiguous warning).

[laurent dot deniau at cern dot ch]

--- Comment #2 from laurent dot deniau at cern dot ch  2008-06-30 16:01 
---
Subject: Re:  va_list argument breaks inlining (ambiguous warning).

rguenth at gcc dot gnu dot org wrote:
> 
> --- Comment #1 from rguenth at gcc dot gnu dot org  2008-06-30 15:46 
> ---
> The inlining is prohibited by the use of va_start, va_next and va_end, not
> by merely passing around va_list.

What is va_next, do you mean va_arg?

I understand the position for va_start+va_end. But what about just using 
va_copy+va_end?

Whatever if it's the criteria for prohibiting the inlining, I agree with 
the wording of the warning.

Thanks for your fast reply.

Regards.

ld.


-- 


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

[Bug c++/31816] If a function foo is defined before declaring a template class A, overloaded version of foo defined after the class declaration will not be available within class A.

[jason dot hoos at syclo dot com]

--- Comment #4 from jason dot hoos at syclo dot com  2008-06-30 16:32 
---
(In reply to comment #1)
> Fix:
> 
> Do not overload a function before and after a template class
> using it.
> 

Another workaround (if rearranging the definitions isn't feasible): before any
of the function definitions, define a template function that calls the
function, and then use that template in other template definitions:

template 
void tmplQHash(X x) { qHash(x); }

void qHash(double) {}

template 
struct QSet
{
  void foo()
  {
tmplQHash(T());
  }
};

void qHash(int*) {}

int main()
{
  QSet s;
  s.foo(); // ok

  QSet sp;
  sp.foo(); // ok now
}


-- 


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

[Bug ada/36678] New: GNAT from svn uses up infinite amount of memory on twisty generic+tagged testcase

[baldrick at gcc dot gnu dot org]

$ gcc -c p-c.adb
+===GNAT BUG DETECTED==+
| 4.4.0 20080630 (experimental) (x86_64-unknown-linux-gnu) Storage_Error heap
exhausted|
| Error detected at p-c.adb:1:1|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

p-c.adb
p-c.ads
p.ads
f.ads
g.ads

compilation abandoned

$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc.fsf.master/configure --prefix=/usr/local/gnat-fsf
--enable-languages=ada,c,c++ --disable-bootstrap --disable-multilib
--enable-checking
Thread model: posix
gcc version 4.4.0 20080630 (experimental) (GCC)

gcc built from svn as of this morning.

-- chop here --
with G;
generic
   type T is private;
package F is
   type R (<>) is tagged private;
   function C return R;
private
   package GI is new G (T);
   type R is new GI.R with null record;
end;
generic
  type T is private;
package G is
   type R is tagged null record;
   procedure P (X : R; Y : T);
end;
package P is end;
with F;
package P.C is
private
   type New_Integer is new Integer;
   package FI is new F (New_Integer);
   type R is new FI.R with null record;
   function C return R;
end;
package body P.C is end;


-- 
   Summary: GNAT from svn uses up infinite amount of memory on
twisty generic+tagged testcase
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2008-06-30 17:08 
---
Joseph, my current patch:

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01942.html

changes it to @@GCC_4.3.0 and adds

+%inherit GCC_4.4.0 GCC_4.3.0
+GCC_4.4.0 {
+}

to cc/libgcc-std.ver. I can also close it as WONTFIX. Do you have
a strong opinion? Thanks.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||joseph at codesourcery dot
   ||com


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

[Bug tree-optimization/36679] New: lnstat command dies if built with O1/O2

[shemminger at vyatta dot com]

The GCC optimizer generates code that cause a segmentation violation in
snprintf if the lnstat command from iproute2 utilities is build with -O1 or
-O2.

System: Intel Core Duo (64 bit)
Version: gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)


Backtrace:
]$ gdb ./lnstat
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) run
Starting program: /home/shemminger/src/iproute2/misc/lnstat 

Program received signal SIGSEGV, Segmentation fault.
0x7f81a655c9d4 in vsnprintf () from /lib/libc.so.6
(gdb) where
#0  0x7f81a655c9d4 in vsnprintf () from /lib/libc.so.6
#1  0x7f81a653ef73 in snprintf () from /lib/libc.so.6
#2  0x004015f3 in main ()


-- 
   Summary: lnstat command dies if built with O1/O2
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shemminger at vyatta dot com


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

[Bug tree-optimization/36679] lnstat command dies if built with O1/O2

[shemminger at vyatta dot com]

--- Comment #1 from shemminger at vyatta dot com  2008-06-30 17:16 ---
Created an attachment (id=15834)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15834&action=view)
Compiler tree for lnstat compile


-- 


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

[Bug target/36669] Wrong versioning for __float128

[joseph at codesourcery dot com]

--- Comment #11 from joseph at codesourcery dot com  2008-06-30 17:22 
---
Subject: Re:  Wrong versioning for __float128

On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:

> Joseph, my current patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01942.html
> 
> changes it to @@GCC_4.3.0 and adds
> 
> +%inherit GCC_4.4.0 GCC_4.3.0
> +GCC_4.4.0 {
> +}
> 
> to cc/libgcc-std.ver. I can also close it as WONTFIX. Do you have
> a strong opinion? Thanks.

It would be better for the libgcc maintainer to review the question of 
changing this symbol version.  If it's decided to change it, that should 
be done through a separate patch on its own (which would also go on 4.3 
branch).


-- 


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

[Bug other/31754] Include column number along line in error messages main.cpp:5:38

[dseketel at redhat dot com]

--- Comment #11 from dseketel at redhat dot com  2008-06-30 17:51 ---
Created an attachment (id=15835)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15835&action=view)
better column number in error patch [1/2]

This is a rebase of the patch [1/2] against trunk from 2008-06-30.


-- 

dseketel at redhat dot com changed:

   What|Removed |Added

  Attachment #15817|0   |1
is obsolete||


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

[Bug other/31754] Include column number along line in error messages main.cpp:5:38

[dseketel at redhat dot com]

--- Comment #12 from dseketel at redhat dot com  2008-06-30 17:52 ---
Created an attachment (id=15836)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15836&action=view)
better column number in error patch [2/2]

This is a rebase of the patch [2/2] against trunk of 2008-06-30.
It has been regtested on x86.


-- 

dseketel at redhat dot com changed:

   What|Removed |Added

  Attachment #15821|0   |1
is obsolete||


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

[Bug tree-optimization/36679] lnstat command dies if built with O1/O2

[shemminger at vyatta dot com]

--- Comment #2 from shemminger at vyatta dot com  2008-06-30 17:53 ---
The problem turned out to be an out of bounds array reference.

The number of fields (fps->num) was 71, and on 64 were allocated.
This caused out of bounds reference to corrupt stack variables. Since
stack variables are assigned differently after optimization, that was
the reason for the red herring.


-- 

shemminger at vyatta dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/36680] New: ICE in spill_failure, reload1.c:1995

[dfranke at gcc dot gnu dot org]

The code snippet below compiles on FCFLAGS="-O1" and FCFLAGS="-O2", but gives
an ICE on FCFLAGS="-O1 -fschedule-insns". The additional option is supposed to
be part of -O2, according to [1]. 

The problem seems to be target-related as I could not reproduce it on
i686-pc-linux-gnu.

Code is reduced, but probably not minimal yet. 

$> cat ice.f90
MODULE class_dummy_atom_kdtree_types
  TYPE dummy_atom_kdtree_data
INTEGER :: dummy
  END TYPE

  TYPE :: dummy_atom_kdtree_node
TYPE(dummy_atom_kdtree_node_private), POINTER :: p
  END TYPE

  TYPE :: dummy_atom_kdtree_node_private
TYPE(dummy_atom_kdtree_data)  :: data
  END TYPE

  TYPE :: dummy_atom_kdtree
TYPE(dummy_atom_kdtree_node) :: root
  END TYPE
END MODULE

FUNCTION dummy_atom_kdtree_insert(this, item)
  USE class_dummy_atom_kdtree_types, ONLY: dummy_atom_kdtree,
dummy_atom_kdtree_node, dummy_atom_kdtree_data

  TYPE(dummy_atom_kdtree), INTENT(inout)   :: this
  TYPE(dummy_atom_kdtree_data), INTENT(in) :: item

  TYPE(dummy_atom_kdtree_data) :: dummy_atom_kdtree_insert

  TYPE(dummy_atom_kdtree_node) :: parent, current
  TYPE(dummy_atom_kdtree_node) :: node
  INTEGER :: cmp, level, discriminator

  parent= dummy_atom_kdtree_node(null())
  current   = this%root
  level = 1
  discriminator = 1

  DO WHILE (ASSOCIATED( current%p ))
discriminator = MODULO(level-1, 3) + 1
cmp = dummy_atom_kdtree_data_compare(item, current%p%data, discriminator)
level   = level + 1
  END DO

  dummy_atom_kdtree_insert = item
END FUNCTION

$> gfortran-svn -O1 -fschedule-insns ice.f90
ice.f90: In function 'dummy_atom_kdtree_insert':
ice.f90:42: error: unable to find a register to spill in class 'AREG'
ice.f90:42: error: this is the insn:
(insn 19 31 20 4 ice.f90:37 (parallel [
(set (reg:SI 37 r8 [69])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 37
r8 [68]))
(zero_extend:DI (reg:SI 42 r13 [78])))
(const_int 32 [0x20]
(clobber (scratch:SI))
(clobber (reg:CC 17 flags))
]) 342 {*umulsi3_highpart_insn} (expr_list:REG_DEAD (reg:SI 37 r8 [68])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
ice.f90:42: internal compiler error: in spill_failure, at reload1.c:1995
Please submit a full bug report,

$> gfortran-svn -v
gcc version 4.4.0 20080629 (experimental) (GCC)

The same holds for 4.3.2.

[1] http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options


-- 
   Summary: ICE in spill_failure, reload1.c:1995
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug other/31754] Include column number along line in error messages main.cpp:5:38

[dseketel at redhat dot com]

--- Comment #13 from dseketel at redhat dot com  2008-06-30 17:54 ---
@Jon Grant: thanks for cheering ! :-)


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-06-30 17:56 
---
This may have been fixed with a recent patch.  I will check and report back
this evening.


-- 

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-06-30 17:56:50
   date||


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

[Bug target/36680] ICE in spill_failure, reload1.c:1995

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-30 17:59 ---
No -fschedule-insns is not included for x86 because of register pressure.
See PR 27001 also.  There are many others due to the RA being dumb.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ra


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2008-06-30 18:30 
---
Since config/i386/libgcc-x86_64-glibc.ver will be removed in
gcc 4.4 when __float128 is enabled for ia32, gcc 4.3 branch
will need a different patch if we want to fix it. Otherwise,
we can leave those symbols alone. I will just need to update
quad patch. Ian, can you take a look at this? Thanks.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||ian at airs dot com


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

[Bug target/36669] Wrong versioning for __float128

[ian at airs dot com]

--- Comment #13 from ian at airs dot com  2008-06-30 19:12 ---
The three symbols __gttf2, __lttf2, and __netf2 are part of the standard libgcc
interface at version GCC_3.0.  The fact that they are not supported by all
instances of libgcc on all platforms seems to me to be irrelevant.  When we
provide those symbols, we should provide them at version GCC_3.0.

If we change the interface, then we should change the version.  But if the
symbols are merely not present, then it is not necessary to change the version.
 The program will get an error either way.  If we follow a different procedure,
then we need to create different version scripts for each target.  And that is
unlikely to work effectively.

config/i386/libgcc-x86_64-glibc.ver and config/libgcc-glibc.ver are problematic
 because people fail to update them when libgcc-std.ver is updated.

At least, that is how it seems to me.  I don't know if this answers your
question, because I'm not sure what you are asking.


-- 


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

[Bug target/36669] Wrong versioning for __float128

[joseph at codesourcery dot com]

--- Comment #14 from joseph at codesourcery dot com  2008-06-30 19:30 
---
Subject: Re:  Wrong versioning for __float128

On Mon, 30 Jun 2008, ian at airs dot com wrote:

> The three symbols __gttf2, __lttf2, and __netf2 are part of the standard 
> libgcc
> interface at version GCC_3.0.  The fact that they are not supported by all
> instances of libgcc on all platforms seems to me to be irrelevant.  When we
> provide those symbols, we should provide them at version GCC_3.0.
> 
> If we change the interface, then we should change the version.  But if the
> symbols are merely not present, then it is not necessary to change the 
> version.
>  The program will get an error either way.  If we follow a different 
> procedure,
> then we need to create different version scripts for each target.  And that is
> unlikely to work effectively.
> 
> config/i386/libgcc-x86_64-glibc.ver and config/libgcc-glibc.ver are 
> problematic
>  because people fail to update them when libgcc-std.ver is updated.
> 
> At least, that is how it seems to me.  I don't know if this answers your
> question, because I'm not sure what you are asking.

The way it seems to me is that the practice so far has been that the 
versions do depend on the target - there are lots of target-specific 
version scripts, covering both target-specific symbols and the 
target-specific versions at which target-independent symbols were added.  
For example, the various GNU/Linux targets that underwent a transition in 
long double size have linker scripts to give appropriate versions to their 
TFmode symbols.  This is in accord with the practice followed by glibc: if 
a symbol was accidentally not exported on a given target, it will be given 
the version number of the version in which it was finally exported on that 
target (see the handling of exp2l, for example).

This means that the error tells you what version of libgcc is needed to 
get a particular symbol, and that the set of symbols in a version (for a 
given target) should not be changed once that GCC version is released.

The special version scripts do not need to be updated when libgcc-std.ver 
is updated.  They only need to be updated when the target to which they 
apply gains new symbols that are target-specific or that were added to 
libgcc-std.ver for other targets in an earlier version, which is rarer.

On this basis, the issue is that we have a bug that some TFmode symbols 
were not put in GCC_4.3.0 on x86_64 although they were newly added there, 
and the question is whether we keep them in GCC_3.0 having released with 
them there, or move them to GCC_4.3.0 for consistency with the other 
TFmode symbols (breaking any x86_64 binaries built with 4.3.0 or 4.3.1 
using __float128 and shared libgcc that use one of those symbols).


-- 


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

[Bug java/36618] gcc-4.4-20080620 ICE in gcj/gnu.CORBA.OrbFunctional

[mariah dot lenox at gmail dot com]

--- Comment #2 from mariah dot lenox at gmail dot com  2008-06-30 19:32 
---
Fixed in gcc-4.4-20080627


-- 

mariah dot lenox at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2008-06-30 19:50 
---
(In reply to comment #13)
> The three symbols __gttf2, __lttf2, and __netf2 are part of the standard 
> libgcc
> interface at version GCC_3.0.  The fact that they are not supported by all
> instances of libgcc on all platforms seems to me to be irrelevant.  When we
> provide those symbols, we should provide them at version GCC_3.0.

That is even more interesting. It is certainly different from
glibc where version GLIBC_X.Y.Z is used to describe the first
glibc version X.Y.Z which has the implementation. The same
function can have different X.Y.Z for different architectures
when it was implemented at different glibc versions.

This change

http://gcc.gnu.org/ml/gcc-cvs/2001-05/msg00878.html

puts ALL TF functions in GCC_3.0, not just those 3.

> 
> If we change the interface, then we should change the version.  But if the
> symbols are merely not present, then it is not necessary to change the 
> version.
>  The program will get an error either way.  If we follow a different 
> procedure,
> then we need to create different version scripts for each target.  And that is
> unlikely to work effectively.

Each target may have different versions for the same function.
That is

%exclude {
}

is used for. The problem is those 3 symbols were missing in
config/i386/libgcc-x86_64-glibc.ver.  We can't have it both
ways. All TF symbols should have the same version.

> config/i386/libgcc-x86_64-glibc.ver and config/libgcc-glibc.ver are 
> problematic
>  because people fail to update them when libgcc-std.ver is updated.
> 
> At least, that is how it seems to me.  I don't know if this answers your
> question, because I'm not sure what you are asking.
> 

There are 3 questions:

1. What version should x86-64 TF symbols use?
2. What version should ia32 TF symbols use?
3. Should ALL x86-64 TF symbols have the same version?


-- 


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

[Bug c++/36662] [4.3/4.4 Regression] vector vs template

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-06-30 20:42 ---
Subject: Bug 36662

Author: jakub
Date: Mon Jun 30 20:41:29 2008
New Revision: 137287

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137287
Log:
PR c++/36662
* decl2.c (is_late_template_attribute): If the first attribute
argument is IDENTIFIER_NODE, don't consider it when checking
if arguments are value or type dependent.

* g++.dg/ext/altivec-16.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/altivec-16.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36662] [4.3/4.4 Regression] vector vs template

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-06-30 20:50 ---
Subject: Bug 36662

Author: jakub
Date: Mon Jun 30 20:49:51 2008
New Revision: 137289

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137289
Log:
PR c++/36662
* decl2.c (is_late_template_attribute): If the first attribute
argument is IDENTIFIER_NODE, don't consider it when checking
if arguments are value or type dependent.

* g++.dg/ext/altivec-16.C: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/altivec-16.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/decl2.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36662] [4.3/4.4 Regression] vector vs template

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-06-30 20:52 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/36681] New: compiler error message with gfortran 4.3.1 but not with 4.2.1

[hatz at wuw dot at]

program test
  logical(kind=1),parameter :: t=.true.,f=.false.
  logical(kind=1),dimension(9)  :: hexa,hexb
  data hexa/f,f,t,t,f,f,f,t,f/,hexb/f,t,f,f,f,t,t,f,f/
  isum=count(hexa(1:9).eqv.hexb(1:9))
  print*, isum
end program   

with gfortran from gcc 4.3.1 above code produces:
test.f90:10.11:

end program
  1
Internal Error at (1):
test.f90:6.30:

 isum=count(hexa(1:9).eqv.hexb(1:9))
 1
Can't convert LOGICAL(1) to LOGICAL(1) at (1)

but no error with gfortran 4.2.1


-- 
   Summary: compiler error message with gfortran 4.3.1 but not with
4.2.1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hatz at wuw dot at


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

[Bug middle-end/36598] Failed optimisation of return of struct argment in memcpy-1.c

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #5 from hutchinsonandy at gcc dot gnu dot org  2008-06-30 22:39 
---
Subject: Bug 36598

Author: hutchinsonandy
Date: Mon Jun 30 22:38:34 2008
New Revision: 137298

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137298
Log:
PR target/36598
* gcc.dg/memcpy-1.c: Mark test XFAIL for avr target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/memcpy-1.c


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-06-30 23:50 
---
Bug confirmed on trunk.


-- 


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

[Bug middle-end/36682] New: [4.4 Regression]: fortran.dg/associated_1.f90 execute at -O1

[hp at gcc dot gnu dot org]

With r137251, this test passed.  From r137253 onwards, this test fails as
follows:
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/associated_1.f90  -O1  execution test

with gfortran.log saying:
PASS: gfortran.dg/associated_1.f90  -O1  (test for excess errors)
program stopped with signal 6.^M
FAIL: gfortran.dg/associated_1.f90  -O1  execution test
(i.e. abort was called)

I'll add info from analyzing simulator runs and diff of generated codes.
Author of only relevant change CC:ed.


-- 
   Summary: [4.4 Regression]: fortran.dg/associated_1.f90 execute at
-O1
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug fortran/36681] compiler error message with gfortran 4.3.1 but not with 4.2.1

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-07-01 00:51 
---
Confirmed.


-- 

jvdelisle 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-01 00:51:28
   date||


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

[Bug middle-end/36682] [4.4 Regression]: fortran.dg/associated_1.f90 execute at -O1

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-07-01 01:34 ---
Created an attachment (id=15837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15837&action=view)
somewhat shrunk test-case, the last abort in the program being called, use -O1.

It's the "if (.not.associated(a, x(a))) call abort ()" line that trigs: if I
modify the testcase as per the patch, it still fails; also removing the
mentioned line makes it fail.


-- 


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

[Bug middle-end/36682] [4.4 Regression]: fortran.dg/associated_1.f90 execute at -O1

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-07-01 01:36 ---
(In reply to comment #1)
> mentioned line makes it fail.

Doh: "makes it pass", of course.


-- 

hp 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-01 01:36:09
   date||


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

[Bug middle-end/36682] [4.4 Regression]: fortran.dg/associated_1.f90 execute at -O1

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/36682] [4.4 Regression]: fortran.dg/associated_1.f90 execute at -O1

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-01 01:54 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/36671] [4.4 Regression]: gfortran.dg/associated_1.f90

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-07-01 01:54 ---
*** Bug 36682 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug target/36669] Wrong versioning for __float128

[ian at airs dot com]

--- Comment #16 from ian at airs dot com  2008-07-01 03:31 ---
So the question is whether we should break programs compiled by 4.3.0 and 4.3.1
(acknowledging that there may not be any actual programs that break) in order
to use consistent version numbers?

> 1. What version should x86-64 TF symbols use?

What is the argument for changing them now that they have been released?

> 2. What version should ia32 TF symbols use?

If I understand correctly, these have not been released, so it seems that they
should be GCC_4.4.0.

> 3. Should ALL x86-64 TF symbols have the same version?

I don't see why this is necessary.


-- 


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #17 from hjl dot tools at gmail dot com  2008-07-01 04:07 
---
(In reply to comment #16)
> So the question is whether we should break programs compiled by 4.3.0 and 
> 4.3.1
> (acknowledging that there may not be any actual programs that break) in order
> to use consistent version numbers?
> 
> > 1. What version should x86-64 TF symbols use?
> 
> What is the argument for changing them now that they have been released?

Because GCC_4.3.0 is the first version which implements them?

> 
> > 2. What version should ia32 TF symbols use?
> 
> If I understand correctly, these have not been released, so it seems that they
> should be GCC_4.4.0.
> 
> > 3. Should ALL x86-64 TF symbols have the same version?
> 
> I don't see why this is necessary.
> 

If people think we don't need to set the correct version on
those TF symbols, could someone please close this bug as
WONTFIX? I need a closure to update my ia32 quad patch since
my patch uses a single libgcc-glibc.ver for x86, which currently
defines all x86-64 TF symbols with version GCC_4.3.0. Thanks.


-- 


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

Template type bug

[Etienne Grossmann]

  Hello,

I do not have a login to submit a bug via bugzilla, so I use the
second method in http://gcc.gnu.org/bugs.html#where and attach all the
required info.

In short, compiling w/ g++-4.3
==
template  Comparable max (Comparable x, Comparable y)
{
  return x >= y ? x : y;
}

template  int max (int x, int y); // OK
template  double max (double x, double y); // Fails

int main ()  { return 0;}
===
results in "error: 'double' is not a valid type for a template
constant parameter", which I believe is inappropriate here.

  Is this a known bug? I found similar bugs:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01159.html
http://gcc.gnu.org/ml/gcc-bugs/2007-12/msg02358.html, but they don't
quite match.

Another question: in http://gcc.gnu.org/bugs.html#known, there are
many references, e.g. "see [14.6]", but there is no
  bibliography. What is the refered document? (If it is an online
document, the page bugs.html could contain links, thus avoiding silly
questions like this one)

  Thanking you for making g++ available in the first place,

  Etienne

template  Comparable max (Comparable x, Comparable y)
{
  return x >= y ? x : y;
}

template  int max (int x, int y); // OK
template  double max (double x, double y); // Fails

int main ()
{
  return 0;
}


try_template.ii
Description: Binary data


try_template.s
Description: Binary data
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-2' 
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --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.3 
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-2) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'try_template' 
'-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.1/cc1plus -E -quiet -v -D_GNU_SOURCE 
try_template.cpp -mtune=generic -Wall -fpch-preprocess -o try_template.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory 
"/usr/lib/gcc/i486-linux-gnu/4.3.1/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.3
 /usr/include/c++/4.3/i486-linux-gnu
 /usr/include/c++/4.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.3.1/include
 /usr/lib/gcc/i486-linux-gnu/4.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'try_template' 
'-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.1/cc1plus -fpreprocessed try_template.ii 
-quiet -dumpbase try_template.cpp -mtune=generic -auxbase try_template -Wall 
-version -o try_template.s
GNU C++ (Debian 4.3.1-2) version 4.3.1 (i486-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=62 --param ggc-min-heapsize=60358
Compiler executable checksum: 61e5e0ff4ba061bbc735c00efd721073
try_template.cpp:8: error: 'double' is not a valid type for a template constant 
parameter

[Bug fortran/36683] New: -fbounds-check failure for allocated array and spread

[terry at chem dot gu dot se]

Unconformable array operations are not being picked up in the following:

[EMAIL PROTECTED] Stoopid]$ cat badness.f90 
program fred
implicit none
real,dimension(:,:),allocatable::A
real,dimension(5)::v
allocate(A(5,5))
A=5
v=5
A=A/spread(v,2,3)
write(*,*)A(1,:)
write(*,*)A(2,:)
write(*,*)A(3,:)
write(*,*)A(4,:)
write(*,*)A(5,:)
end
[EMAIL PROTECTED] Stoopid]$ gfortran -Wall -O0 -W -Wtabs -g -fbounds-check -o
badness badness.f90
[EMAIL PROTECTED] Stoopid]$ ./badness 
  1.  1.  1.   5.000   5.000
  1.  1.  1.   5.000   5.000
  1.  1.  1.   5.000   5.000
  1.  1.  1.   5.000   5.000
  1.  1.  1.   5.000   5.000
[EMAIL PROTECTED] Stoopid]$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3-20080522/configure --disable-multilib
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.1 20080522 (prerelease) (GCC) 


Making the spread array too big [spread(v,2,13)] is not detected either.  My
quick attempts to do both in a single code caused glibc to freak out with
"double free or corruption" detection.


-- 
   Summary: -fbounds-check failure for allocated array and spread
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
  GCC host triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/36648] [4.3/4.4 Regression] segfault in global constructor with -O3

[irar at gcc dot gnu dot org]

--- Comment #7 from irar at gcc dot gnu dot org  2008-07-01 05:32 ---
Subject: Bug 36648

Author: irar
Date: Tue Jul  1 05:31:55 2008
New Revision: 137308

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

PR tree-optimization/36648
* tree-vect-transform.c (vect_do_peeling_for_loop_bound): Divide
number of prolog iterations by step. Fix the comment.


Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/vect/pr36648.cc
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-vect-transform.c


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-07-01 05:43 
---
Patch:

Index: list_read.c
===
--- list_read.c (revision 137236)
+++ list_read.c (working copy)
@@ -2922,8 +2922,8 @@ find_nml_name:
   goto find_nml_name;
 }

-  if (c == '!')
-eat_line (dtp);
+  unget_char (dtp, c);
+  eat_separator (dtp);

   /* Ready to read namelist objects.  If there is an error in input
  from stdin, output the error message and continue.  */


-- 


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

[Bug tree-optimization/36648] [4.3/4.4 Regression] segfault in global constructor with -O3

[irar at il dot ibm dot com]

--- Comment #8 from irar at il dot ibm dot com  2008-07-01 06:12 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36648] [4.3/4.4 Regression] segfault in global constructor with -O3

[beckmann dot maik at googlemail dot com]

--- Comment #9 from beckmann dot maik at googlemail dot com  2008-07-01 
06:29 ---
Thank you Ira.


-- 


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