[Bug target/25259] bootstrap failures on non-C99 platforms

[bonzini at gnu dot org]

--- Comment #11 from bonzini at gnu dot org  2005-12-21 08:25 ---
Created an attachment (id=10541)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10541&action=view)
fix pasto in int16_t definition

This might be the last one...


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Attachment #10535|0   |1
is obsolete||


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

[Bug rtl-optimization/25432] [4.1/4.2 Regression] Reload ICE in gen_add2_insn

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2005-12-21 09:59 ---
Created an attachment (id=10542)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10542&action=view)
gcc41-pr25432.patch

As Alan is AFAIK on vacation, I'm attaching the almost-patch converted into
a patch form and bootstrapped/regtested on gcc-4_1-branch
{i386,x86_64,ppc,ppc64,s390,s390x,ia64}-linux.


-- 


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

[Bug c/25509] can't voidify __attribute__((warn_unused_result))

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2005-12-21 09:59 ---
The (technical) problem that the void cast does not work is that the warning
is applied after gimplification, which strips the cast to void.  So, this is
another case where warnings from the middle-end show their bad side - not that
it would be easy to move to the frontend(s).

This is at least a bug because the warning cannot be disabled:

  if (lookup_attribute ("warn_unused_result", TYPE_ATTRIBUTES (ftype)))
{
  if (fdecl)
warning (0, "%Hignoring return value of %qD, "
 "declared with attribute warn_unused_result",
 EXPR_LOCUS (t), fdecl);
  else
warning (0, "%Hignoring return value of function "
 "declared with attribute warn_unused_result",
 EXPR_LOCUS (t));
}

so, confirmed.  Suggestions for a proper -Wno-XXX identifier?
-Wno-unused-result?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-21 09:59:43
   date||


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

[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002

[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|NEW |ASSIGNED
   Last reconfirmed|2005-11-23 18:48:32 |2005-12-21 10:12:17
   date||


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

[Bug c/25509] can't voidify __attribute__((warn_unused_result))

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2005-12-21 10:16 
---
This "fixes" it:

*** gimplify.c  (revision 108853)
--- gimplify.c  (working copy)
*** gimplify_expr (tree *expr_p, tree *pre_p
*** 4203,4210 
  break;
}

! if (VOID_TYPE_P (TREE_TYPE (*expr_p))
! || fallback == fb_none)
{
  /* Just strip a conversion to void (or in void context) and
 try again.  */
--- 4203,4211 
  break;
}

! if ((VOID_TYPE_P (TREE_TYPE (*expr_p))
!  || fallback == fb_none)
! && ! TREE_CODE (TREE_OPERAND (*expr_p, 0)) == CALL_EXPR)
{
  /* Just strip a conversion to void (or in void context) and
 try again.  */

it makes the gimplifier output

main ()
{
  int D.1519;
  int D.1520;

  D.1519 = foo ();
  D.1520 = 0;
  return D.1520;
}

instead of (with the (void) cast removed):

main ()
{
  int D.1519;

  foo ();
  D.1519 = 0;
  return D.1519;
}

The question whether this is an appropriate fix or just my astonishing ability 
to find ugly workarounds remains to be answered ;)


-- 


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

[Bug middle-end/25512] New: [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[rguenth at gcc dot gnu dot org]

char *foo(char *p1)
{
  return (p1+0x7fff) > p1 ? (p1+0x7fff) : (char *)-1;
}

We fold the expression to return p1+0x7fff because we think that
the comparison is equal to 0x7fff > 0.  Again a problem of my
array-like-ref comparison folding.

I have a fix.


-- 
   Summary: [4.1/4.2 Regression] Overflow not handled in ptr
arithmetic folding
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[rguenth at gcc dot gnu dot org]

-- 

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 |2005-12-21 10:51:16
   date||


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

[Bug c/25509] can't voidify __attribute__((warn_unused_result))

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2005-12-21 10:59 
---
Hm, we even check in the testsuite that we still warn for (void) foo():

  check1 ();/* { dg-warning "ignoring return value of" } */
  (void) check1 (); /* { dg-warning "ignoring return value of" } */
  check1 (), bar ();/* { dg-warning "ignoring return value of" } */


-- 


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

[Bug fortran/25423] Error with nested where statements

[eedelman at gcc dot gnu dot org]

--- Comment #3 from eedelman at gcc dot gnu dot org  2005-12-21 11:58 
---
Subject: Bug 25423

Author: eedelman
Date: Wed Dec 21 11:58:09 2005
New Revision: 108902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108902
Log:
fortran/
2005-12-21  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25423
* parse.c (parse_where_block): break instead of "fall
 through" after parsing nested WHERE construct.


testsuite/
2005-12-21  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25423
gfortran.dg/where_nested_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/where_nested_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25423] Error with nested where statements

[eedelman at gcc dot gnu dot org]

--- Comment #4 from eedelman at gcc dot gnu dot org  2005-12-21 12:08 
---
Subject: Bug 25423

Author: eedelman
Date: Wed Dec 21 12:07:58 2005
New Revision: 108903

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108903
Log:
fortran/
2005-12-21  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25423
* parse.c (parse_where_block): break instead of "fall
through" after parsing nested WHERE construct.

testsuite/
2005-12-21  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25423
gfortran.dg/where_nested_1.f90: New.


Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/where_nested_1.f90
Modified:
branches/gcc-4_1-branch/gcc/fortran/ChangeLog
branches/gcc-4_1-branch/gcc/fortran/parse.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25423] Error with nested where statements

[eedelman at gcc dot gnu dot org]

--- Comment #5 from eedelman at gcc dot gnu dot org  2005-12-21 12:12 
---
Subject: Bug 25423

Author: eedelman
Date: Wed Dec 21 12:12:52 2005
New Revision: 108904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108904
Log:
fortran/
2005-12-21  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25423
* parse.c (parse_where_block): break instead of "fall
through" after parsing nested WHERE construct.

testsuite/
2005-12-21  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25423
gfortran.dg/where_nested_1.f90: New.


Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/where_nested_1.f90
Modified:
branches/gcc-4_0-branch/gcc/fortran/ChangeLog
branches/gcc-4_0-branch/gcc/fortran/parse.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2005-12-21 12:22 ---
Note that this may be INVALID if we want to treat pointer overflow as
undefined,
as the std doesn't talk about pointer overflow at all.

Using proper (unsigned) integer types for this kind of arithmetic is
recommended anyway.


-- 


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2005-12-21 12:31 ---
Created an attachment (id=10543)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10543&action=view)
patch

The attached patch would fix this and treat unsigned pointer arithmetic
overflow
as defined in this transformation.  Fallout:

FAIL: gcc.dg/tree-ssa/foldaddr-1.c scan-tree-dump-times return 0 1
FAIL: gcc.dg/tree-ssa/pr15791-1.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/pr15791-5.c scan-tree-dump-times i == j 1

language lawyer advice needed.


-- 


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

[Bug c/25509] can't voidify __attribute__((warn_unused_result))

[joseph at codesourcery dot com]

--- Comment #12 from joseph at codesourcery dot com  2005-12-21 13:04 
---
Subject: Re:  can't voidify __attribute__((warn_unused_result))

On Wed, 21 Dec 2005, mueller at kde dot org wrote:

> ok, lets assume that you meant with "can not be ignored" actually "must not be
> ignored". now thats where the definitions in RFC2119 kick in: 

The documentation isn't written in terms of RFC2119.

> The documentation correctly states SHOULD NOT, and thats distinctively
> different from MUST NOT. 

It says "should never", not "should not".

For the sort of functions this is intended for, if you really want to 
ignore the return value then you should probably have a conditional and a 
??? comment in every place you do so.  Not simply a cast to void which as 
the manual notes is visual noise.

  if (error_return()) {
/* ??? For reason X we can't handle this error sensibly.  */
abort();
  }

(I wouldn't recommend omitting the abort there; the comment would need a 
more detailed justification of why in the particular case it's safe to 
carry on if the abort is omitted.)


-- 


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

[Bug fortran/25513] New: ICE tree check using complex numbers and the "-fno-automatic" compiler option

[harald dot vogt at desy dot de]

The following little piece of code produces an ICE if compiled with the
"-fno-automatic" compiler option:

  subroutine test
  implicit none
  complex z
  integer i,j
  do i=1,2
do j=1,2
  z=cmplx(.5,0.)*cmplx(1.,0.)
enddo
  enddo
  end

The compiler output is:

internal compiler error: tree check: expected ssa_name, have var_decl in
gather_mem_refs_stmt, at tree-ssa-loop-im.c:1275
Please submit a full bug report


-- 
   Summary: ICE tree check using complex numbers and the "-fno-
automatic" compiler option
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: harald dot vogt at desy dot de
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2005-12-21 13:34 ---
Invalid as of 6.5.6/8


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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

[Bug c/25509] can't voidify __attribute__((warn_unused_result))

[mueller at kde dot org]

--- Comment #13 from mueller at kde dot org  2005-12-21 14:07 ---
ok, then, lets see if we can get this fixed in glibc. 


-- 

mueller at kde dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug c/25514] New: [m68k] internal consistency failure

[stephen at marenka dot net]

Recent versions of make fail with an error reproducible as follows.

$ gcc -O2 -c -o buggy.o buggy.c
buggy.c: In function 'pop_variable_scope':
buggy.c:62: fatal error: internal consistency failure
compilation terminated.

Workaround: change -O2 to -O1.


-- 
   Summary: [m68k] internal consistency failure
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephen at marenka dot net
 GCC build triplet: m68k-linux-gnu
  GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug c/25514] [m68k] internal consistency failure

[stephen at marenka dot net]

--- Comment #1 from stephen at marenka dot net  2005-12-21 14:12 ---
Created an attachment (id=10544)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10544&action=view)
Test Case


-- 


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

[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code

[rakdver at gcc dot gnu dot org]

--- Comment #8 from rakdver at gcc dot gnu dot org  2005-12-21 14:34 ---
Gimplification lets with_cleanup_exprs escape to gimple.  I am investigating
why that happens.


-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/25121] [4.1/4.2 Regression] libgcj misscompilation?

[aph at gcc dot gnu dot org]

--- Comment #5 from aph at gcc dot gnu dot org  2005-12-21 14:56 ---
Subject: Bug 25121

Author: aph
Date: Wed Dec 21 14:56:00 2005
New Revision: 108905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108905
Log:
2005-12-21  Andrew Haley  <[EMAIL PROTECTED]>

PR middle-end/25121
* recog.c (peephole2_optimize): Don't peephole any
RTX_FRAME_RELATED_P insns.



Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/recog.c


-- 


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

[Bug other/25515] New: broken exceptions with -Os ?

[pluto at agmk dot net]

$ make clean all OPT=-Os
rm -rf *.ii *.o *.s lib.so main
g++ -Os lib.cpp -fPIC -shared -Wl,-soname,lib -o lib.so
g++ -Os main.cpp -o main -ldl
LD_LIBRARY_PATH=./ ./main
Memory fault

works fine with -O[0123].

$ g++ -v
Reading specs from /usr/lib64/gcc/amd64-pld-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib64
--libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-languages=c,c++,f77,objc,ada,java --enable-c99 --enable-long-long
--enable-nls --with-gnu-as --with-gnu-ld --with-system-zlib
--with-slibdir=/lib64 --without-x amd64-pld-linux
Thread model: posix
gcc version 3.4.5 (PLD Linux)


-- 
   Summary: broken exceptions with -Os ?
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
 GCC build triplet: amd64-linux
  GCC host triplet: amd64-linux
GCC target triplet: amd64-linux


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

[Bug other/25515] broken exceptions with -Os ?

[pluto at agmk dot net]

--- Comment #1 from pluto at agmk dot net  2005-12-21 14:57 ---
Created an attachment (id=10545)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10545&action=view)
testcase


-- 


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

[Bug fortran/25516] New: Internal compiler error on compiling nested derived type

[iguchi at coral dot t dot u-tokyo dot ac dot jp]

In cygwin platform, I got following internal compiler error.

$ gfortran --version
GNU Fortran 95 (GCC 4.1.0 20050522 (experimental))
Copyright (C) 2005 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

$ cat ice.f90
module m
  type t1
type(t2), pointer :: p
  end type

  type t2
type(t1) :: a
  end type

  type t3
type(t1) :: p
  end type

contains

  logical function f(a)
type(t3), intent(in) :: a
f=.true.
  end function

end module

$ gfortran ice.f90
ice.f90:16: internal compiler error: in gfc_get_derived_type, at
fortran/trans-t
ypes.c:1458
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: Internal compiler error on compiling nested derived type
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iguchi at coral dot t dot u-tokyo dot ac dot jp


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

[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE

[steven at gcc dot gnu dot org]

--- Comment #13 from steven at gcc dot gnu dot org  2005-12-21 15:28 ---
Subject: Bug 25130

Author: steven
Date: Wed Dec 21 15:28:16 2005
New Revision: 108906

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108906
Log:
patch for PR rtl-optimization/25130

gcc/
* postreload-gcse.c (record_last_set_info): Notice stack pointer
changes in push insns without REG_INC notes.

testsuite/
* gcc.dg/pr25130.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr25130.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload-gcse.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2005-12-21 15:32 ---
Subject: Bug 25130

Author: steven
Date: Wed Dec 21 15:32:09 2005
New Revision: 108907

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108907
Log:
patch for PR rtl-optimization/25130, gcc 4.1 edition.

gcc/
* postreload-gcse.c (record_last_set_info): Notice stack pointer
changes in push insns without REG_INC notes.

testsuite/
* gcc.dg/pr25130.c: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr25130.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/postreload-gcse.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2005-12-21 15:34 ---
Patch posted by Jakub.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||12/msg01610.html


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

[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2005-12-21 15:45 ---
That's what you get for working on different GCSEs at the same time.

Those commits were for Bug 25196 :-(


-- 


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

[Bug rtl-optimization/25196] [4.0 Regression] i386: wrong arguments passed

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2005-12-21 15:46 ---
Fixed on the trunk and on the GCC 4.1 branch.
See http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01177.html and
http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01178.html (I used the wrong bug
number in the commit >:-/)

Will ask for permission for the 4.0 branch in a few days.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1 Regression] i386:  |[4.0 Regression] i386: wrong
   |wrong arguments passed  |arguments passed


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

[Bug tree-optimization/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746

[rakdver at gcc dot gnu dot org]

--- Comment #13 from rakdver at gcc dot gnu dot org  2005-12-21 15:49 
---
Subject: Bug 24793

Author: rakdver
Date: Wed Dec 21 15:49:19 2005
New Revision: 108910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108910
Log:
PR tree-optimization/24793
* tree-ssa-loop-ivopts.c (get_ref_tag): Remember the
original reference if there are subvars.
* tree-ssa-operands.c (get_tmr_operands): Handle subvars.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c
branches/gcc-4_1-branch/gcc/tree-ssa-operands.c


-- 


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

[Bug tree-optimization/23282] [4.0 Regression] wrong results at -O on x86

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #12 from belyshev at depni dot sinp dot msu dot ru  2005-12-21 
15:58 ---
Zdenek, ping!

Please apply patch for this bug to gcc-4_0-branch.


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

   Last reconfirmed|2005-08-08 08:00:14 |2005-12-21 15:58:03
   date||


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

[Bug fortran/25423] Error with nested where statements

[eedelman at gcc dot gnu dot org]

--- Comment #6 from eedelman at gcc dot gnu dot org  2005-12-21 16:17 
---
Fixed on trunk, 4.1 and 4.0


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/25513] [4.1/4.2 Regression] static complex variable and LIM

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-21 16:27 ---
Confirmed, C testcase (compile at -O1):
int f(void)
{
  static _Complex double t;
  int i, j;
  for(i = 0;i<2;i++)
for(j = 0;j<2;j++)
  t = .5 * 1.0;
  return t;
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
  Component|fortran |tree-optimization
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-12-21 16:27:43
   date||
Summary|ICE tree check using complex|[4.1/4.2 Regression] static
   |numbers and the "-fno-  |complex variable and LIM
   |automatic" compiler option  |
   Target Milestone|--- |4.1.0


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

[Bug middle-end/25121] [4.1 Regression] libgcj misscompilation?

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2005-12-21 16:30 ---
Fixed on the mainline at least.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-21 16:30:46
   date||
Summary|[4.1/4.2 Regression] libgcj |[4.1 Regression] libgcj
   |misscompilation?|misscompilation?


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

[Bug debug/25518] New: /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[danglin at gcc dot gnu dot org]

gcc -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED -D_INCLUDE__STDC_A1_SOURCE
-D_INCLUDE
_XOPEN_SOURCE_500   -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-defin
ition -Wmissing-format-attribute-DHAVE_CONFIG_H  -o cc1-dummy c-lang.o
stub-
objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o
c
-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o
cppdefault.
o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o
c-parser
.o  c-gimplify.o tree-mudflap.o c-pretty-print.o dummy-checksum.o \
  main.o  libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a  
../libiberty/libi
berty.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   dwarf2out_switch_text_section (first referenced in libbackend.a(final.o))
(co
de)
collect2: ld returned 1 exit status


-- 
   Summary: /usr/ccs/bin/ld: Unsatisfied symbols:
dwarf2out_switch_text_section
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug debug/25518] /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-21 16:33 ---
Woops, mine.  I think I forgot to move dwarf2out_switch_text_section out of the
#if.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-21 16:33:08
   date||


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

[Bug debug/25518] [4.1 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug debug/25518] [4.1 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-21 16:44 ---
Subject: Bug 25518

Author: pinskia
Date: Wed Dec 21 16:44:09 2005
New Revision: 108912

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108912
Log:
2005-12-21  Andrew Pinski  <[EMAIL PROTECTED]>

PR debug/25518* dwarf2out.c (dwarf2out_switch_text_section):
Declare whenDWARF2_UNWIND_INFO is defined or when DWARF2_DEBUGGING_INFO
is
defined.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/dwarf2out.c


-- 


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

[Bug tree-optimization/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2005-12-21 16:45 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug debug/25518] [4.1 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: dwarf2out_switch_text_section

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-21 16:46 ---
Should be fixed now.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/25121] [4.2 Regression] libgcj misscompilation?

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2005-12-21 16:49 ---
The 4.1 branch I had meant.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.1.0 4.2.0 |4.2.0
  Known to work||4.1.0
Summary|[4.1 Regression] libgcj |[4.2 Regression] libgcj
   |misscompilation?|misscompilation?
   Target Milestone|4.1.0   |4.2.0


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

[Bug middle-end/25121] [4.2 Regression] libgcj misscompilation?

[aph at gcc dot gnu dot org]

--- Comment #8 from aph at gcc dot gnu dot org  2005-12-21 16:52 ---
Subject: Bug 25121

Author: aph
Date: Wed Dec 21 16:52:13 2005
New Revision: 108914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108914
Log:
2005-12-21  Andrew Haley  <[EMAIL PROTECTED]>

PR middle-end/25121
* recog.c (peephole2_optimize): Don't peephole any
RTX_FRAME_RELATED_P insns.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/recog.c


-- 


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

[Bug web/25519] New: Online Documentation: error for addsubps and missing SSE2 instructions

[othojunk at gmail dot com]

In the "GCC online documentation" in the page entitled "5.45.5 X86 Built-in
Functions" the lines documenting the addsubps and addsubpd instructions are
listed as:

v2df __builtin_ia32_addsubpd (v2df, v2df)
v2df __builtin_ia32_addsubps (v2df, v2df)

The first line is correct as can be deduced by the hungarian notation of double
as 'd' as the last letter. However the second line is a float operator yet the
prototype given implies it to be a float operator. This is not the case as
putting a v2df into the function results in an error. For instance take the
following code:


#include 
typedef double v2df __attribute__ ((vector_size (16)));

int main()  {
v2df a, b, c;
c = __builtin_ia32_addsubps (a, b);
return 1;
}

Attempting to compile this will result in the following error:

error: incompatible types in assignment

A simple change to v4sf will allow the code to compile, and I have verified
that it works according to spec. Also all online documentation for the assembly
instruction associated with this call, addsubps, document it as a 4-vector
single precision float operator.

As a side comment I noticed that none of the sse2 instructions were listed on
this page, yet also exist. For instance the instructions 

__builtin_ia32_addpd
__builtin_ia32_subpd
__builtin_ia32_mulpd
__builtin_ia32_divpd

do not exist on this page yet should.

I appreciate the help that this online documentation has provided. I dislike
using asm on code that needs to be created and maintained in my enviornment,
where little or no training on assembly is done or desired. We perform much
work  on datasets of complex numbers and this documentation has allowed a
simple yet fast and efficient way to perform complex multiplications and other
operations. Here is for instance a macro for a complex multiplication:

// using SSE3 instructions
#define v4sf_complex_mult( a, b)__builtin_ia32_addsubps (   \
__builtin_ia32_movsldup (a) * (b),  \
__builtin_ia32_movshdup (a) * __builtin_ia32_shufps (b, b, 0xb1)  )


-- 
   Summary: Online Documentation: error for addsubps and missing
SSE2 instructions
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: othojunk at gmail dot com


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

[Bug tree-optimization/25513] [4.1/4.2 Regression] static complex variable and LIM

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2005-12-21 16:58 ---
lsm needs to special case handling of complex somehow, as we don't take complex
vars to ssa form (appearantly).

(gdb) call debug_generic_expr(stmt)
#   t_lsm.21D.1571 = V_MUST_DEF ;
t_lsm.21D.1571 = __complex__ (5.0e-1, 0.0)

so

  else if (TREE_CODE (*rhs) == SSA_NAME
   || is_gimple_min_invariant (*rhs))

triggers because the RHS is gimple_min_invariant.  And the LHS
is gimple_reg_type because it's not AGGREGATE_TYPE either.

Zdenek, can you have a look?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org


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

[Bug target/25519] Online Documentation: error for addsubps and missing SSE2 instructions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-21 16:59 ---
You should be using the Intel intrinsics by using {x,}mmintrin.h/mm3dnow.h.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|web |target
   Keywords||documentation, ssemmx


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

[Bug c/25509] can't voidify __attribute__((warn_unused_result))

[gdr at integrable-solutions dot net]

--- Comment #14 from gdr at integrable-solutions dot net  2005-12-21 17:05 
---
Subject: Re:  can't voidify __attribute__((warn_unused_result))

"mueller at kde dot org" <[EMAIL PROTECTED]> writes:

| ok, then, lets see if we can get this fixed in glibc. 

good luck.


-- 


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

[Bug middle-end/25121] [4.2 Regression] libgcj misscompilation?

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2005-12-21 17:12 ---
Fixed on the mainline also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/25276] [4.2 regression] testsuite failure: execution gcc.dg/attr-weakref-1.c

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-21 17:20 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[gdr at gcc dot gnu dot org]

--- Comment #4 from gdr at gcc dot gnu dot org  2005-12-21 17:21 ---
(In reply to comment #3)
> Invalid as of 6.5.6/8
> 
I don't think that paragraph explains why this is an
invalid PR.


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug middle-end/25121] [4.2 Regression] libgcj misscompilation?

[aph at gcc dot gnu dot org]

--- Comment #10 from aph at gcc dot gnu dot org  2005-12-21 17:27 ---
I'd like to apply this patch to 4.0, but it's too different.


-- 

aph at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.2.0   |4.1.0


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[gdr at integrable-solutions dot net]

--- Comment #5 from gdr at integrable-solutions dot net  2005-12-21 17:28 
---
Subject: Re:  [4.1/4.2 Regression] Overflow not handled in ptr arithmetic
folding

"gdr at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| --- Comment #4 from gdr at gcc dot gnu dot org  2005-12-21 17:21 ---
| (In reply to comment #3)
| > Invalid as of 6.5.6/8
| > 
| I don't think that paragraph explains why this is an
| invalid PR.

More to the point:  We need to be more precise about our mapping for

   pointer type -> integer type
   integer type -> pointer type
   T* -> U*

This issue should not be resolved in isolation, piece meal looking
only at benchmark numbers.  It is fine to precisely define the
mappings to make the code undefined, or have defined semantics.
Notice also that this relates to the practice 

   (T*)(-1)

which is wiedely used in C programs (including GCC!).

Finally, we don't have a policy that the opener of a PR has "more
rights to close it", nor should we.  We should be closing PRs on
technical grounds.

-- Gaby





-- 


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2005-12-21 17:30 ---
> Finally, we don't have a policy that the opener of a PR has "more
> rights to close it", nor should we.  We should be closing PRs on
> technical grounds.

I agree with that part.


-- 


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

[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf

[joseph at codesourcery dot com]

--- Comment #18 from joseph at codesourcery dot com  2005-12-21 17:39 
---
Subject:  Patch for arm-none-linux-gnueabi build failure

This patch fixes another piece of bug 24998, fallout from adding
__floatun*.  Unlike the problems with missing functions, this is one
with duplicate functions: builds for arm-none-linux-gnueabi fail
because __floatundisf and __floatundidf are multiply defined, once in
libgcc2.c and once in ieee754-[ds]f.S.  Where a target defines its own
version of a function in libgcc2.c, it needs to be listed in
LIB1ASMFUNCS to avoid the libgcc2.c version being compiled.  (In this
case, a group of functions are all included in the same object file so
inclusion in LIB1ASMFUNCS wasn't needed for the ARM version to get
compiled in the first place.)

Tested with cross-compiler to arm-none-linux-gnueabi; it fixes the
build of the compiler.  OK to commit?

2005-12-21  Joseph S. Myers  <[EMAIL PROTECTED]>

PR middle-end/24998
* config/arm/t-arm-elf (LIB1ASMFUNCS): Add _floatundidf and
_floatundisf.

diff -rupN GCC.orig/gcc/config/arm/t-arm-elf GCC/gcc/config/arm/t-arm-elf
--- GCC.orig/gcc/config/arm/t-arm-elf   2005-10-28 23:33:56.0 +
+++ GCC/gcc/config/arm/t-arm-elf2005-12-21 16:40:19.0 +
@@ -4,7 +4,7 @@ LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3
_lshrdi3 _ashrdi3 _ashldi3 \
_negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi _fixunsdfsi \
_truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \
-   _fixsfsi _fixunssfsi _floatdidf _floatdisf
+   _fixsfsi _fixunssfsi _floatdidf _floatdisf _floatundidf _floatundisf

 MULTILIB_OPTIONS = marm/mthumb
 MULTILIB_DIRNAMES= arm thumb


-- 


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

[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf

[paul at codesourcery dot com]

--- Comment #19 from pbrook at gcc dot gnu dot org  2005-12-21 17:43 ---
Subject: Re:  Patch for arm-none-linux-gnueabi build failure

> 2005-12-21  Joseph S. Myers  <[EMAIL PROTECTED]>
>
>   PR middle-end/24998
>   * config/arm/t-arm-elf (LIB1ASMFUNCS): Add _floatundidf and
>   _floatundisf.

Ok.

Paul


-- 


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

[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf

[jsm28 at gcc dot gnu dot org]

--- Comment #20 from jsm28 at gcc dot gnu dot org  2005-12-21 17:48 ---
Subject: Bug 24998

Author: jsm28
Date: Wed Dec 21 17:48:07 2005
New Revision: 108918

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108918
Log:
PR middle-end/24998
* config/arm/t-arm-elf (LIB1ASMFUNCS): Add _floatundidf and
_floatundisf.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/t-arm-elf


-- 


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

[Bug other/25515] broken exceptions with -Os ?

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2005-12-21 18:02 ---
if I change the myexception definition to:

struct myexception : public std::exception {};

then testcase will crashe at all optimization levels on i386/amd64.

Program received signal SIGSEGV, Segmentation fault.
0xb7ef7a06 in ?? ()
(gdb) bt
#0  0xb7ef7a06 in ?? ()
#1  0xb7eb42eb in __cxa_throw () from /usr/lib/libstdc++.so.6
#2  0xb7dde6ed in _Unwind_DeleteException () from /lib/libgcc_s.so.1
#3  0xb7eb34e6 in __cxa_end_catch () from /usr/lib/libstdc++.so.6
#4  0x08048777 in main () at main.cpp:25

this backtrace comes from gcc-4.1/i386.


-- 


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2005-12-21 18:24 ---
One more thing, the comparision will fail with segmented memory targets like
x86 (when using the segment register).


-- 


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

[Bug other/25515] broken exceptions with -Os ?

[pluto at agmk dot net]

--- Comment #3 from pluto at agmk dot net  2005-12-21 18:30 ---
i suppose the lib.so and myexception's typeinfo is unavailable
after unwinding the try{} block (due to ~dll/dlclose) which is
a reason why the program crash. am i rigth?


-- 


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[gdr at integrable-solutions dot net]

--- Comment #8 from gdr at integrable-solutions dot net  2005-12-21 18:40 
---
Subject: Re:  [4.1/4.2 Regression] Overflow not handled in ptr arithmetic
folding

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| One more thing, the comparision will fail with segmented memory targets like
| x86 (when using the segment register).

I don't know whether GCC supports such target (if yes, you've
potentially found a bug in GCC's implementation of total pointer
ordering as required by the C++ standard)

That is more reason for GCC to document what the mapping for the
conversion T* -> integer type.

-- Gaby


-- 


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

[Bug middle-end/25512] [4.1/4.2 Regression] Overflow not handled in ptr arithmetic folding

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2005-12-21 18:48 ---
(In reply to comment #8)
> I don't know whether GCC supports such target (if yes, you've
> potentially found a bug in GCC's implementation of total pointer
> ordering as required by the C++ standard)

My point was more the fact this is used to see if there is a max pointer for an
array (which is at max 2GB long). Well the usage is just wrong as most likely
you get an passed the array which then turns out to be undefined by that
definition.  If you end up with a 2GB on a 64bit target, it will work just
fine.  But not on a 32bit target which is where this is used, even though it
should just use (char*)-1; there.

Also this macro is wrong for some 16bit targets, etc.  Basicially what OOo/ICU
is doing is a mess and really should rethink this part of the code.  


-- 


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

[Bug middle-end/25521] New: change semantics of const volatile variables

[drepper at redhat dot com]

In math code we often have to make sure the compiler does not fold operations
at compile time.  In glibc we use variable declared as

  static const volatile double foo = 42.0;

The problem is that gcc moves such variables into .data.  But we could achieve
that easily by leaving out the 'const'.  What is needed is a method to achieve
volatile behavior while having the variable in .rodata (and .rodata.cst8 etc).

I therefore would like to ask for a change in the compiler which preserves the
'const' in the presence of 'volatile' and place the variable in read-only
memory.


-- 
   Summary: change semantics of const volatile variables
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drepper at redhat dot com


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

[Bug middle-end/25522] New: zero-initialized constants are place in .bss

[drepper at redhat dot com]

Compile this code:

struct foo { int a, b; }
const struct foo f;

The compiler will mark the variable f in .bss instead of, as the const
indicates, into .rodata.  This can be a security problem.  In glibc we
deliberately use const wherever possible (as should everybody) to prevent
anybody from changing the value.  Allowing changes would allw an intruder to
modify the variable and influence the semantics of the program.

Yes, this means that binaries get larger.  But that's what the programmer
requested.


-- 
   Summary: zero-initialized constants are place in .bss
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drepper at redhat dot com


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

[Bug middle-end/25522] zero-initialized constants are place in .bss

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-21 19:09 ---
.comm   f,8,4


Actually no, they are placed in the common section because of ANSI C rules.

This is not a bug.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/25522] zero-initialized constants are place in .bss

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-21 19:11 ---
If you really zero initialize them, you get them in the what you expect:
.section.rodata
.align 4
.type   f, @object
.size   f, 8
f:
.zero   8

-

Removing the const gets them placed into .bss though (which is correct):
.file   "t.c"
.globl f
.bss
.align 4
.type   f, @object
.size   f, 8
f:
.zero   8


-- 


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

[Bug middle-end/25521] change semantics of const volatile variables

[gdr at integrable-solutions dot net]

--- Comment #1 from gdr at integrable-solutions dot net  2005-12-21 19:17 
---
Subject: Re:   New: change semantics of const volatile variables

"drepper at redhat dot com" <[EMAIL PROTECTED]> writes:

| In math code we often have to make sure the compiler does not fold operations
| at compile time.  In glibc we use variable declared as
| 
|   static const volatile double foo = 42.0;
| 
| The problem is that gcc moves such variables into .data.  But we could
achieve
| that easily by leaving out the 'const'.  What is needed is a method to
achieve
| volatile behavior while having the variable in .rodata (and .rodata.cst8
etc).
| 
| I therefore would like to ask for a change in the compiler which preserves
the
| 'const' in the presence of 'volatile' and place the variable in read-only
| memory.

that is tricky because of the general interpretation:

   [#10] EXAMPLE 1 An object declared

   extern const volatile int real_time_clock;

   may  be  modifiable  by hardware, but cannot be assigned to,
   incremented, or decremented.

If it may be modified by hardware or other external means, it can't go
into .rodata section.

-- Gaby


-- 


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

[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O

[dir at lanl dot gov]

--- Comment #14 from dir at lanl dot gov  2005-12-21 19:36 ---
After tracing the errors for a while, it became clean that "active" pointer
into the read/write buffer was not being correctly updated. Adding one line (
s->active=0; ) to the bottom of routine "fd_truncate" in file "unix.c" fixes
these errors. All the examples here run OK with this patch and I built 16 of my
programs and ran their many test problems with no errors. I tried to run the
fortran testsuite with "make check-gfortran", but check-gfortran is not in the
makefile. It would be nice if just fortran testsuite could be run.



*** unix.c  Wed Dec 21 08:11:12 2005
--- unixoriginal.c  Wed Dec 21 08:10:27 2005
***
*** 601,608 
  }

s->physical_offset = s->file_length = s->logical_offset;
-   
-   s->active=0;

return SUCCESS;
  }
--- 601,606 


-- 


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

[Bug middle-end/25521] change semantics of const volatile variables

[drepper at redhat dot com]

--- Comment #2 from drepper at redhat dot com  2005-12-21 19:38 ---
Using gcc's section attributes won't fully work either.

Using __attribute((section(".rodata"))) is OK in the compiler, although the
assembler (correctly) complaints.  But what is really needed is

__attribute((section(".rodata.cst8"))).  This will cause gcc to fail with an
ICE.


-- 


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

[Bug tree-optimization/25513] [4.1/4.2 Regression] static complex variable and LIM

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-21 19:40 ---
I have a patch:
===
--- tree-dfa.c  (revision 108920)
+++ tree-dfa.c  (working copy)
@@ -216,6 +216,9 @@ tree
 make_rename_temp (tree type, const char *prefix)
 {
   tree t = create_tmp_var (type, prefix);
+  if (TREE_CODE (type) == COMPLEX_TYPE)
+DECL_COMPLEX_GIMPLE_REG_P (t) = 1;
+  
   if (referenced_vars)
 {
   add_referenced_tmp_var (t);


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/25522] zero-initialized constants are place in .bss

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2005-12-21 19:46 ---
Subject: Re:  zero-initialized constants are place in
 .bss

On Wed, 21 Dec 2005, pinskia at gcc dot gnu dot org wrote:

> Actually no, they are placed in the common section because of ANSI C rules.

There is no such requirement.

> This is not a bug.

ELF supports having a read-only equivalent of .bss (type SHT_NOBITS, 
attributes SHF_ALLOC without SHF_WRITE).  We could allocate such a section 
name for read-only zero-initialized data and use it on ELF systems.  That 
way the data is read-only but doesn't consume space in the executable 
(presuming the rest of the toolchain handles this case OK).


-- 


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

[Bug target/24076] (vector char){x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x} code gen is not that good

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-21 19:49 ---
Not working on this any more.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/25521] change semantics of const volatile variables

[gdr at integrable-solutions dot net]

--- Comment #3 from gdr at integrable-solutions dot net  2005-12-21 19:54 
---
Subject: Re:  change semantics of const volatile variables

"drepper at redhat dot com" <[EMAIL PROTECTED]> writes:

| __attribute((section(".rodata.cst8"))).  This will cause gcc to fail with an
| ICE.

That is compiler bug.  That is useful piece of data.  I believe the PR
should be retitled and reclassified based on that.

-- Gaby


-- 


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

[Bug target/25350] [4.2 Regression] Can't include mmintrin.h

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2005-12-21 19:54 ---
In addition to the listed C failures, this is probably also responsible for the
C++ regressions

FAIL: g++.dg/opt/mmx2.C (test for excess errors)
FAIL: g++.dg/other/mmintrin.C (test for excess errors)

appearing at the same time.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug c/17555] function visibility attribute in definition misinterpreted

[nomis80 at nomis80 dot org]

--- Comment #3 from nomis80 at nomis80 dot org  2005-12-21 20:07 ---
This is not fixed as of 4.1.0. Can someone with enough karma reopen either this
bug or #17251 ? Thanks!


-- 

nomis80 at nomis80 dot org changed:

   What|Removed |Added

 CC||nomis80 at nomis80 dot org


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

[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O

[kargl at gcc dot gnu dot org]

--- Comment #15 from kargl at gcc dot gnu dot org  2005-12-21 20:21 ---
(In reply to comment #14)
> I tried to run the
> fortran testsuite with "make check-gfortran", but check-gfortran is not
> in the
> makefile. It would be nice if just fortran testsuite could be run.
> 

Dale, move into the gcc/ directory of your build directory and run
the "make check-gfortran" command.  Yes, it's an unexpected PITA,
but it should work.


-- 


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

[Bug target/25259] bootstrap failures on non-C99 platforms

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2005-12-21 20:26 
---
> This might be the last one...

Victory!  sparc-sun-solaris2.5.1 is alive again. :-)  Thanks a lot.


-- 


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

[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O

[dir at lanl dot gov]

--- Comment #16 from dir at lanl dot gov  2005-12-21 21:43 ---
I down loaded gfortran and built it on the Macintosh with -

svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
cd gcc
configure --prefix=/Users/dir/gfortran --enable-languages=c,f95
make -j 4
make install

When, I try the "check-gfortran" in the directory 'gcc' where I did the
configure,make -j 4,make install, I get -

[dranta:~/gfortran/gcc] dir% make check-gfortran
make: *** No rule to make target `check-gfortran'.  Stop.

When I move to the directory 'gcc' below that, I get -

[dranta:~/gfortran/gcc] dir% cd gcc
[dranta:~/gfortran/gcc/gcc] dir% make check-gfortran
make: *** No rule to make target `check-gfortran'.  Stop.
[dranta:~/gfortran/gcc/gcc] dir% 

Is there another directory called gcc or does it need to be build some other
way ?


-- 


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

[BCX-35393]: Re: website

[Technical Support]

== Please reply above this line ==

gcc-bugs@gcc.gnu.org,

Your ticket has been submitted to our Technical Support department, one of the 
staff members will review it and reply accordingly. Listed below are details of 
this ticket, you will need to use the ticket key listed below to update the 
status of this ticket from web.

Ticket ID: BCX-35393
Ticket Key: 2e85bd9c
Subject: Re: website
Department: Technical Support

You can check the status or reply to this ticket online at 
http://support.simplehost.com/index.php?_a=tickets&_m=viewmain&[EMAIL 
PROTECTED]&ticketkeyre=2e85bd9c&_i=BCX-35393



Please let us know if we can assist you any further,

SimpleHost.com

[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O

[fxcoudert at gcc dot gnu dot org]

--- Comment #17 from fxcoudert at gcc dot gnu dot org  2005-12-21 22:14 
---
(In reply to comment #16)
> When, I try the "check-gfortran" in the directory 'gcc' where I did the
> configure,make -j 4,make install, I get

Dale, you should really stop building your compiler inside the source tree.
This isn't very actively supported (actually, it breaks every so often) and it
makes everything harder. For example, I usually create a directory parent
directory build/, including build/gcc which is the source tree and build/ibin
which is the build. Inside build/ibin, do:

../gcc/configure [...] && make && make install

What Steve is saying is that you have to go inside the build/ibin/gcc directory
and run make check-gfortran *there*.

> Is there another directory called gcc or does it need to be build some other
> way ?

I guess with your scheme, you need to go inside gcc/gcc/ and run make
check-gfortran. But please, don't do in-tree builds :)


-- 


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

[Bug c++/25523] New: Compiler segmentation fault

[evald80 at hotmail dot com]

hello !
first of all, this is the source code that make the compiler crash.
www.evald80.altervista.org/bug.rar 
I have try this on win and linux distro and on both i get a internal compiler
error: Segmentation fault.
win so has gcc 3.3.3 and linux distro slackware has gcc 3.3.4
Regards.


-- 
   Summary: Compiler segmentation fault
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: evald80 at hotmail dot com


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

[Bug libstdc++/25524] New: libstdc++ headers should go in multilib directories

[jsm28 at gcc dot gnu dot org]

Some libstdc++ headers are installed in GPLUSPLUS_TOOL_INCLUDE_DIR, i.e.
include/c++/version/target.  These headers are derived from information
configured separately for each multilib, and in general may differ between
multilibs, so should go in a multilib directory (e.g.
include/c++/version/target/multilib).  The precompiled headers installed there,
in particular, should be separately installed for each multilib in all cases,
even if in some cases the actual text headers happen to be the same for each
multilib.

One possible plan for fixing this is to add a flag to struct default_include
meaning "add a multilib suffix to this include directory", then make the driver
pass a -imultilib option to cc1plus which provides the suffix appended to
GPLUSPLUS_TOOL_INCLUDE_DIR.  libstdc++-v3 would then need to be taught to
install the headers in the multilib subdirectory instead of directly in
include/c++/version/target.  (The build directory arrangement can stay the
same, since each multilib gets built in its own directory.)


-- 
   Summary: libstdc++ headers should go in multilib directories
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug c++/25525] New: 'const' modifier is ignored in static_cast specifier

[yuri at tsoft dot com]

The following code produces 'casting away constness' error on 'static_cast'
line. Should be no warning.

- code ---

struct A { };
struct B : A { };

template
const PTR mycast(const A *a) {
  return (static_cast(a));
}

const B* mycast(const A *a) {
  return (mycast(a));
}


-- 
   Summary: 'const' modifier is ignored in static_cast specifier
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/25525] 'const' modifier is ignored in static_cast specifier

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-21 22:54 ---
GCC is correct:
const PTR mycast(const A *a) {
  return (static_cast(a));


a is a pointer to a const A.  While the cast you are trying to use is a
constant pointer to B.  And that is invalid C++ to use static_cast to remove a
const.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/25524] libstdc++ headers should go in multilib directories

[gdr at integrable-solutions dot net]

--- Comment #1 from gdr at integrable-solutions dot net  2005-12-21 23:23 
---
Subject: Re:   New: libstdc++ headers should go in multilib directories

"jsm28 at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| Some libstdc++ headers are installed in GPLUSPLUS_TOOL_INCLUDE_DIR, i.e.
| include/c++/version/target.  These headers are derived from information
| configured separately for each multilib, and in general may differ between
| multilibs, so should go in a multilib directory (e.g.
| include/c++/version/target/multilib).  The precompiled headers installed
there,
| in particular, should be separately installed for each multilib in all cases,
| even if in some cases the actual text headers happen to be the same for each
| multilib.

Most headers are target independents, so should not suffer from
multilib issue.  I would think that a proper plan to fix this is to
install target dependent thingies in some deeper subdirectories.

-- Gaby


-- 


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

[Bug libstdc++/25524] libstdc++ headers should go in multilib directories

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2005-12-21 23:27 ---
Subject: Re:  libstdc++ headers should go in multilib
 directories

On Wed, 21 Dec 2005, gdr at integrable-solutions dot net wrote:

> 
> 
> --- Comment #1 from gdr at integrable-solutions dot net  2005-12-21 23:23 
> ---
> Subject: Re:   New: libstdc++ headers should go in multilib directories
> 
> "jsm28 at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> 
> | Some libstdc++ headers are installed in GPLUSPLUS_TOOL_INCLUDE_DIR, i.e.
> | include/c++/version/target.  These headers are derived from information
> | configured separately for each multilib, and in general may differ between
> | multilibs, so should go in a multilib directory (e.g.
> | include/c++/version/target/multilib).  The precompiled headers installed
> there,
> | in particular, should be separately installed for each multilib in all 
> cases,
> | even if in some cases the actual text headers happen to be the same for each
> | multilib.
> 
> Most headers are target independents, so should not suffer from
> multilib issue.  I would think that a proper plan to fix this is to
> install target dependent thingies in some deeper subdirectories.

This issue is only for the target-dependent headers (in 
GPLUSPLUS_TOOL_INCLUDE_DIR), which can also be multilib-dependent, not for 
the target-independent headers in GPLUSPLUS_INCLUDE_DIR and 
GPLUSPLUS_BACKWARD_INCLUDE_DIR.  Only GPLUSPLUS_TOOL_INCLUDE_DIR would be 
flagged to use a multilib suffix.


-- 


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

[Bug other/25527] New: [gomp] segfault in main.omp_fn.0 with -O2

[dev at stuffit dot at]

code works just fine if compiled with g++-4.2.0 --openmp but dies a horrible
death if you -02

valgrind output:
[EMAIL PROTECTED] ~/tmp $ valgrind ./test
==31611== Memcheck, a memory error detector.
==31611== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==31611== Using LibVEX rev 1471, a library for dynamic binary translation.
==31611== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==31611== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==31611== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==31611== For more details, rerun with: -v
==31611==
OPENMP> Thread 0 finished
RHS 0
vex x86->IR: unhandled instruction bytes: 0x6C 0x3D 0x10 0x4
==31611== Invalid read of size 1
==31611==at 0x40FE91A: (within
/home/dev2/gcc-gomp-save/gomp-gcc-build/lib/libstdc++.so.6.0.7)
==31611==by 0x8049308: main.omp_fn.0 (in /home/dev2/tmp/test)
==31611==by 0x80495C6: main (in /home/dev2/tmp/test)
==31611==  Address 0x8200381 is not stack'd, malloc'd or (recently) free'd
==31611==
==31611== Process terminating with default action of signal 11 (SIGSEGV)
==31611==  Access not within mapped region at address 0x8200381
==31611==at 0x40FE91A: (within
/home/dev2/gcc-gomp-save/gomp-gcc-build/lib/libstdc++.so.6.0.7)
==31611==by 0x8049308: main.omp_fn.0 (in /home/dev2/tmp/test)
==31611==by 0x80495C6: main (in /home/dev2/tmp/test)
x[0]===31611==
==31611== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 25 from 1)
==31611== malloc/free: in use at exit: 16,128 bytes in 4 blocks.
==31611== malloc/free: 7 allocs, 3 frees, 16,838 bytes allocated.
==31611== For counts of detected errors, rerun with: -v
==31611== searching for pointers to 4 not-freed blocks.
==31611== checked 278,488 bytes.
==31611==
==31611== LEAK SUMMARY:
==31611==definitely lost: 0 bytes in 0 blocks.
==31611==  possibly lost: 0 bytes in 0 blocks.
==31611==still reachable: 16,128 bytes in 4 blocks.
==31611== suppressed: 0 bytes in 0 blocks.
==31611== Reachable blocks (those to which a pointer was found) are not shown.
==31611== To see them, rerun with: --show-reachable=yes
Segmentation fault


-- 
   Summary: [gomp] segfault in main.omp_fn.0 with -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dev at stuffit dot at
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug other/25527] [gomp] segfault in main.omp_fn.0 with -O2

[dev at stuffit dot at]

--- Comment #1 from dev at stuffit dot at  2005-12-21 23:55 ---
Created an attachment (id=10547)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10547&action=view)
Sample Code


-- 


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

[Bug other/25527] [gomp] segfault in main.omp_fn.0 with -O2

[dev at stuffit dot at]

--- Comment #2 from dev at stuffit dot at  2005-12-21 23:59 ---
svn revision 108861 of gomp-20050608-branch, i should probably add!


-- 


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

[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O

[jvdelisle at gcc dot gnu dot org]

--- Comment #18 from jvdelisle at gcc dot gnu dot org  2005-12-22 01:18 
---
This is great!  I have regression tested and NIST tested on i686 and all pass. 
I have not tried some of the problem cases yet, but will do later tonight.

I was just getting ready to start working on this one and I am tickled pink
that it appears to be a fix.

Who will approve and who will commit this.  I will be happy to commit with a
test case if needed.


-- 


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

[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O

[jvdelisle at gcc dot gnu dot org]

--- Comment #19 from jvdelisle at gcc dot gnu dot org  2005-12-22 02:08 
---
Ran some test cases.  The second example in Comment #3 fails. With or without
FX patch given in Comment #6

At line 10 of file back3.f
Fortran runtime error: Read past ENDFILE record

Dale, are you getting this?


-- 


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

[Bug libfortran/25307] internal read with end=label aborts

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2005-12-22 02:32 
---
Subject: Bug 25307

Author: jvdelisle
Date: Thu Dec 22 02:32:29 2005
New Revision: 108938

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108938
Log:
2005-12-21  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/25307
* io/list_read.c (next_char): Handle end-of-file conditions for
internal units and add support for internal character array units.

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


-- 


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

[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2005-12-22 03:32 ---
This also blocks building benchs_F95.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug c++/25523] Compiler segmentation fault

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2005-12-22 03:37 
---
Confirmed. Reduced testcase:


template struct A
{
struct X;
};

template struct B : A
{
friend struct X;
struct X {};
};


This causes a segfault with GCC 2.95.3 - GCC 3.3.6.
However, the bug is fixed since GCC 3.4.0.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-on-valid-code
 Resolution||FIXED
   Target Milestone|--- |3.4.0


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

[Bug c++/22149] func pointer non-type template parm invalid access control

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2005-12-22 03:56 
---
The second testcase now crashes (4.0 branch, 4.1 branch, and mainline).
This is due to PR 25364.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug middle-end/23518] some gcc optimizations do not take overflow into account with -fwrapv

[kazu at gcc dot gnu dot org]

--- Comment #5 from kazu at gcc dot gnu dot org  2005-12-22 04:03 ---
Subject: Bug 23518

Author: kazu
Date: Thu Dec 22 04:03:32 2005
New Revision: 108940

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108940
Log:
gcc/
PR tree-optimization/23518
* fold-const.c (make_range): Don't move a constant to the
other side of the comparison if the type is signed and -fwrapv
is given.

gcc/testsuite/
PR tree-optimization/23518
* testsuite/gcc.dg/pr23518.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr23518.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/23518] some gcc optimizations do not take overflow into account with -fwrapv

[kazu at gcc dot gnu dot org]

--- Comment #6 from kazu at gcc dot gnu dot org  2005-12-22 04:04 ---
Just checked in a patch.


-- 

kazu at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.0


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

[Bug middle-end/23518] some gcc optimizations do not take overflow into account with -fwrapv

[kazu at gcc dot gnu dot org]

--- Comment #7 from kazu at gcc dot gnu dot org  2005-12-22 04:06 ---
Oops, I forgot to change resolution to FIXED.


-- 

kazu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-22 04:43 ---
I see this with -fno-automatic in a benchmark.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/25528] New: missed LIM on the tree level (complex types)

[pinskia at gcc dot gnu dot org]

Take the following code:
int f(void)
{
  static _Complex double t;
  int i, j;
  for(i = 0;i<2;i++)
for(j = 0;j<2;j++)
  t *= .5 * 1.0;
  return t;
}

---
At -O1, we get on the tree level for the loop:
:;
  CI.33 = IMAGPART_EXPR  * 5.0e-1;
  REALPART_EXPR  = REALPART_EXPR  * 5.0e-1;
  IMAGPART_EXPR  = CI.33;
  REALPART_EXPR  = REALPART_EXPR  * 5.0e-1;
  IMAGPART_EXPR  = CI.33 * 5.0e-1;
  i = i + 1;
  if (i != 2) goto ; else goto ;

The stores to t is not pulled at all out of the loop.


-- 
   Summary: missed LIM on the tree level (complex types)
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[ghazi at gcc dot gnu dot org]

--- Comment #22 from ghazi at gcc dot gnu dot org  2005-12-22 04:55 ---
Subject: Bug 20772

Author: ghazi
Date: Thu Dec 22 04:55:18 2005
New Revision: 108942

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108942
Log:
PR testsuite/20772
* g++.dg/abi/bitfield3.C, g++.dg/abi/bitfield8.C,
g++.dg/abi/bitfield9.C, g++.dg/abi/dtor1.C, g++.dg/abi/empty10.C,
g++.dg/abi/empty7.C, g++.dg/abi/empty9.C, g++.dg/abi/layout3.C,
g++.dg/abi/layout4.C, g++.dg/abi/thunk1.C, g++.dg/abi/thunk2.C,
g++.dg/abi/vbase11.C, g++.dg/abi/vthunk2.C, g++.dg/abi/vthunk3.C,
g++.dg/eh/simd-1.C, g++.dg/eh/simd-2.C, g++.dg/ext/attrib8.C,
g++.dg/opt/cse2.C, g++.dg/opt/inline9.C, g++.dg/opt/life1.C,
g++.dg/opt/longbranch2.C, g++.dg/opt/mmx1.C,
g++.dg/opt/reg-stack4.C, g++.dg/other/big-struct.C,
g++.old-deja/g++.abi/aggregates.C, g++.old-deja/g++.abi/align.C,
g++.old-deja/g++.abi/bitfields.C, g++.old-deja/g++.eh/tmpl2.C,
g++.old-deja/g++.ext/asmspec1.C, g++.old-deja/g++.ext/attrib1.C,
g++.old-deja/g++.ext/attrib2.C, g++.old-deja/g++.ext/attrib3.C,
g++.old-deja/g++.law/weak.C, g++.old-deja/g++.other/regstack.C,
g++.old-deja/g++.other/store-expr1.C,
g++.old-deja/g++.other/store-expr2.C, g++.old-deja/g++.pt/asm1.C,
g++.old-deja/g++.pt/asm2.C, g77.dg/20010216-1.f,
gcc.c-torture/compile/2804-1.c,
gcc.c-torture/execute/990413-2.x, gcc.dg/2609-1.c,
gcc.dg/2614-1.c, gcc.dg/2720-1.c, gcc.dg/2724-1.c,
gcc.dg/2807-1.c, gcc.dg/2904-1.c, gcc.dg/20001127-1.c,
gcc.dg/20010202-1.c, gcc.dg/20010520-1.c, gcc.dg/20011009-1.c,
gcc.dg/20011029-2.c, gcc.dg/20011107-1.c, gcc.dg/2009-1.c,
gcc.dg/20020108-1.c, gcc.dg/20020122-2.c, gcc.dg/20020122-3.c,
gcc.dg/20020201-3.c, gcc.dg/20020206-1.c, gcc.dg/20020218-1.c,
gcc.dg/20020224-1.c, gcc.dg/20020310-1.c, gcc.dg/20020411-1.c,
gcc.dg/20020418-1.c, gcc.dg/20020418-2.c, gcc.dg/20020426-1.c,
gcc.dg/20020426-2.c, gcc.dg/20020517-1.c, gcc.dg/20020523-1.c,
gcc.dg/20020523-2.c, gcc.dg/20020531-1.c, gcc.dg/20020616-1.c,
gcc.dg/20020729-1.c, gcc.dg/20030204-1.c, gcc.dg/20030826-2.c,
gcc.dg/20030926-1.c, gcc.dg/20031102-1.c, gcc.dg/20031202-1.c,
gcc.dg/980226-1.c, gcc.dg/980312-1.c, gcc.dg/980313-1.c,
gcc.dg/980414-1.c, gcc.dg/980520-1.c, gcc.dg/980709-1.c,
gcc.dg/990117-1.c, gcc.dg/990130-1.c, gcc.dg/990213-2.c,
gcc.dg/990214-1.c, gcc.dg/990424-1.c, gcc.dg/990524-1.c,
gcc.dg/991129-1.c, gcc.dg/991209-1.c, gcc.dg/991214-1.c,
gcc.dg/991230-1.c, gcc.dg/asm-1.c, gcc.dg/clobbers.c,
gcc.dg/i386-387-1.c, gcc.dg/i386-387-2.c, gcc.dg/i386-387-3.c,
gcc.dg/i386-387-4.c, gcc.dg/i386-387-5.c, gcc.dg/i386-387-6.c,
gcc.dg/i386-asm-1.c, gcc.dg/i386-asm-2.c, gcc.dg/i386-bitfield1.c,
gcc.dg/i386-bitfield2.c, gcc.dg/i386-bitfield3.c,
gcc.dg/i386-call-1.c, gcc.dg/i386-local.c, gcc.dg/i386-loop-1.c,
gcc.dg/i386-loop-2.c, gcc.dg/i386-loop-3.c,
gcc.dg/i386-memset-1.c, gcc.dg/i386-pentium4-not-mull.c,
gcc.dg/i386-pic-1.c, gcc.dg/i386-regparm.c,
gcc.dg/i386-signbit-1.c, gcc.dg/i386-signbit-2.c,
gcc.dg/i386-signbit-3.c, gcc.dg/i386-sse-5.c, gcc.dg/i386-sse-8.c,
gcc.dg/i386-ssetype-3.c, gcc.dg/i386-ssetype-5.c,
gcc.dg/i386-unroll-1.c, gcc.dg/i386-volatile-1.c, gcc.dg/loop-3.c,
gcc.dg/pr12092-1.c, gcc.dg/pr14289-1.c, gcc.dg/pr14289-2.c,
gcc.dg/pr14289-3.c, gcc.dg/pr9771-1.c, gcc.dg/setjmp-2.c,
gcc.dg/short-compare-1.c, gcc.dg/short-compare-2.c,
gcc.dg/sibcall-5.c, gcc.dg/sibcall-6.c, gcc.dg/tls/opt-1.c,
gcc.dg/tls/opt-2.c, gcc.dg/tls/opt-3.c,
gcc.dg/torture/pr18582-1.c, gcc.dg/unroll-1.c,
gcc.misc-tests/i386-pf-3dnow-1.c,
gcc.misc-tests/i386-pf-athlon-1.c,
gcc.misc-tests/i386-pf-none-1.c, gcc.misc-tests/i386-pf-sse-1.c:
Backport portions of testcases.


Modified:
branches/gcc-3_4-branch/gcc/testsuite/ChangeLog
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/bitfield3.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/bitfield8.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/bitfield9.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/dtor1.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/empty10.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/empty7.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/empty9.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/layout3.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/layout4.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/thunk1.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/thunk2.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/vbase11.C
branches/gcc-3_4-branch/gcc/testsuite/g++.dg/abi/vthunk2.C
branches/gcc-3_4-b

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu dot org]

Testcase:
int f1(unsigned t)
{
  return (t*2)/2;
}


This is done in combine on the RTL level.


-- 
   Summary: (unsigned * 2)/2 is not changed into unsigned
&0x7FFF
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 19986
 nThis:


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