[Bug bootstrap/36738] [4.4 Regression] Yet another bootstrap failure at rev. 137502 on darwin9

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |blocker
   Keywords||build
   Target Milestone|--- |4.4.0


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

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-07 02:53 ---
This is another sizetype issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|[4.3,4.4 regression] Bogus  |[4.3/4.4 regression] Bogus
   |"large integer implicitly   |"large integer implicitly
   |truncated" passing size_t   |truncated" passing size_t
   |constant to new |constant to new
   Target Milestone|--- |4.3.2


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

[Bug fortran/36725] g0 edit descriptor: Missing compile-time checking for invalid g0.d

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-07-07 02:50 
---
I am on it.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-07 02:50:27
   date||


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

[Bug middle-end/36743] [4.4 Regression] ICE in pow_c4_i4 when compiling snapshot of 07/04/08 under HP-PA Linux

[michael dot a dot richmond at nasa dot gov]

--- Comment #3 from michael dot a dot richmond at nasa dot gov  2008-07-07 
02:19 ---
gfortran appears to run correctly with the patch applied


-- 


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

[Bug target/36583] [4.3/4.4 Regression] ICE on 5282/5206 at -O2

[eric dot norum at usask dot ca]

--- Comment #2 from eric dot norum at usask dot ca  2008-07-07 01:51 ---
Created an attachment (id=15867)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15867&action=view)
Running under GDB reveals a NULL pointer dereference


-- 


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

[Bug target/36720] ia64_split_tmode_move doesn't work on little endian

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-07-07 00:41 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/36720] ia64_split_tmode_move doesn't work on little endian

[hjl at gcc dot gnu dot org]

--- Comment #3 from hjl at gcc dot gnu dot org  2008-07-07 00:34 ---
Subject: Bug 36720

Author: hjl
Date: Mon Jul  7 00:34:16 2008
New Revision: 137547

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137547
Log:
2008-07-06  H.J. Lu  <[EMAIL PROTECTED]>

PR target/36720
* config/ia64/ia64.c (ia64_split_tmode): Fix typo in TImode
constant for little endian.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.c


-- 


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

[Bug middle-end/36743] [4.4 Regression] ICE in pow_c4_i4 when compiling snapshot of 07/04/08 under HP-PA Linux

[michael dot a dot richmond at nasa dot gov]

--- Comment #2 from michael dot a dot richmond at nasa dot gov  2008-07-06 
23:57 ---
(In reply to comment #1)
> Try the patch in http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00259.html .
> 

When I apply the patch I get the message:

patching file function.c
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 2420 with fuzz 1.

The resulting function compiles successfully. I will attempt to complete the
compilation and test gfortran.


-- 


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

[Bug c/21759] Implement warning for codes at the intersection of C and C++

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-07-06 22:26 ---
>Not sure what the exact error message was.

Easy, the decls were not defined :).  Basically the enums get the scope of the
struct they are defined in for C++ but in C, they get the global scope.  A
warning for this is not that useful really if we are going to move to C++ where
we want them in the scope of the struct rather than the global scope.

-- Pinski


-- 


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

[Bug target/36736] [4.3 Regression] gfortran unrecognizable insn on sh4

[kkojima at gcc dot gnu dot org]

-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.3.1
  Known to work||4.2.4 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-07-06 22:26:12
   date||
Summary|gfortran unrecognizable insn|[4.3 Regression] gfortran
   ||unrecognizable insn on sh4


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

[Bug target/36736] gfortran unrecognizable insn

[kkojima at gcc dot gnu dot org]

--- Comment #6 from kkojima at gcc dot gnu dot org  2008-07-06 22:22 ---
Created an attachment (id=15866)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15866&action=view)
a test case

Fortunately I could get a testcase with building cernlib-2006 for x86.
For the attached testcase, 4.3.1 sh4-linux f951 fails:

error: unrecognizable insn:
(insn 10204 7670 6894 605 ../../../src/geant321/ggeom/gnext.F:774 (parallel [
(set (reg:SF 150 fpul)
(const_double:SF 1.0e+10 [0x0.9502f9p+34]))
(clobber (reg:SI 0 r0))
]) -1 (nil))

with -O2 -fno-automatic -mieee.
I've also confirmed that it doesn't fail with 4.4.0 and 4.2.4
f951 and the patch suggested in #4 gets rid of the failure on
4.3-branch.  I'd like to backport it to 4.3 if the usual tests
are ok on the branch.


-- 


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

[Bug c/21759] Implement warning for codes at the intersection of C and C++

[ghazi at gcc dot gnu dot org]

--- Comment #7 from ghazi at gcc dot gnu dot org  2008-07-06 22:22 ---
Another C/C++ conflict (?) that could be possibly implemented in this warning
feature, enum declaration scoping:

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00470.html

Not sure what the exact error message was.


-- 


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

[Bug middle-end/36743] [4.4 Regression] ICE in pow_c4_i4 when compiling snapshot of 07/04/08 under HP-PA Linux

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-06 21:52 ---
Try the patch in http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00259.html .


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|target  |middle-end
   Keywords||build, ice-on-valid-code
Summary|ICE in pow_c4_i4 when   |[4.4 Regression] ICE in
   |compiling snapshot of   |pow_c4_i4 when compiling
   |07/04/08 under HP-PA Linux  |snapshot of 07/04/08 under
   ||HP-PA Linux
   Target Milestone|--- |4.4.0


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

[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-07-06 20:11 ---
I think the problem is in gfc_match_rvalue():

case FL_VARIABLE:
variable:
  if (sym->ts.type == BT_UNKNOWN && gfc_peek_ascii_char () == '%'
  && gfc_get_default_type (sym, sym->ns)->type == BT_DERIVED)
gfc_set_default_type (sym, 0, sym->ns);

Here, the gfc_peek_ascii_char does not work as the array reference precedes the
% sign.


-- 


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

[Bug c++/36744] function modifying argument received by-value affects caller's variable when passed as rvalue

[chris dot fairles at gmail dot com]

--- Comment #3 from chris dot fairles at gmail dot com  2008-07-06 19:51 
---
(In reply to comment #2)
> (In reply to comment #0)
> >   struct S
> >   {
> > S(): i(2) {}
> //S(S const&) {}
> S(S const&);
> The cctor need only be defined as well to get the same behavior (gcc 4.4.0,
> -std=c++0x, -fno-elide-constructors, -O0, -fno-inline).

And by defined I mean declared of course.

Chris


-- 


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

[Bug fortran/36746] Rejects variable which is implictly typed as derived typed with DIMENSION

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-07-06 19:48 ---
The problem is the combination of
   implicit type(t)(x)
with the DIMENSION statement. Reduced test case:

module m
  type t
integer :: i
  end type t
contains
  subroutine s(x)
implicit type(t)(x)
dimension x(:)
print *, x(1)%i
  end subroutine s
end module m
end


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2008-07-06 19:48:56
   date||
Summary|gfortran sytax error on |Rejects variable which is
   |Bailey's multiprecision |implictly typed as derived
   |array module|typed with DIMENSION


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

[Bug c++/36744] function modifying argument received by-value affects caller's variable when passed as rvalue

[chris dot fairles at gmail dot com]

--- Comment #2 from chris dot fairles at gmail dot com  2008-07-06 19:33 
---
(In reply to comment #0)
> Consider:
> 
>   #include 
> 
>   struct S
>   {
> S(): i(2) {}
//S(S const&) {}
S(S const&);
The cctor need only be defined as well to get the same behavior (gcc 4.4.0,
-std=c++0x, -fno-elide-constructors, -O0, -fno-inline).

> int i;
>   };
> 
>   void f(S x) { x.i = 0; }

The argument type of f(S), so far as my very limited understanding of gimple
goes, is the class type S when the cctor is defined (also marks it for copy
construction). Without the def'n, it's transformed to a reference type (struct
S & restrict) which I assume is an rvalue ref and x just gets moved. Been
trying to locate the responsible code w/o luck.

Chris

> 
>   int main()
>   {
> S y;
> f(static_cast(y));
> std::cout << y.i << '\n';
>   }
> 
> Expected output: 2
> Actual output: 0
> 
> Thus, the assignment to the independent local variable x in f somehow modifies
> y. That can't be right, not even with that static_cast to S&&, can it?
> 


-- 

chris dot fairles at gmail dot com changed:

   What|Removed |Added

 CC||chris dot fairles at gmail
   ||dot com


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

[Bug target/32424] [4.3/4.4 Regression] gcc.c-torture/compile/20050303-1.c FAILs

[bunk at stusta dot de]

--- Comment #8 from bunk at stusta dot de  2008-07-06 18:45 ---
See the duplicate #35454:
This is a problem often seen when compiling Linux kernels.


-- 


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

[Bug fortran/36746] gfortran sytax error on Bailey's multiprecision array module

[kris at kuhlmans dot net]

--- Comment #1 from kris at kuhlmans dot net  2008-07-06 18:28 ---
Created an attachment (id=15865)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15865&action=view)
gzipped source code that triggers problem


-- 


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

[Bug fortran/36746] New: gfortran sytax error on Bailey's multiprecision array module

[kris at kuhlmans dot net]

gfortran builds main part of David Bailey's multi-precision F90 library
correctly, but it gives syntax errors when compiling the array modules
extension of this library (mpmod90v.f).  g95 and the online Lahey source
checker both compile this without errors.

The library I am talking about can be found at 
http://crd.lbl.gov/~dhbailey/mpdist/mpfun90.tar.gz

I am using Ubuntu Hardy Heron on x86_64, with the gfortran trunk build from two
days ago (4.4.0 trunk revision 137451).

Since the mpmod90v.f source file is huge, I have cut it down to a program that
triggers the error (test.f90).  The modules in mpfun90.f and mpmod90.f must be
compiled first:

$ gfortran -ffree-form -c mpfun90.f mpmod90.f

this works without any errors, but then compiling the first subroutine from
mpmod90v.f (to be provided in the file test.f90) gives

$ fortran -o test test.f90 
test.f90:20.33:

   call mpeq (jb%mpi, ja(ii1)%mpi, mpnw) 
1
Error: Syntax error in argument list at (1)


-- 
   Summary: gfortran sytax error on Bailey's multiprecision array
module
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kris at kuhlmans dot net


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

[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.4.0


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

[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-07-06 18:24 ---
Created an attachment (id=15864)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15864&action=view)
testcase

Testcase reduced with a cross from x86_64 to s390x.


-- 


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

[Bug target/36745] New: [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868

[rguenth at gcc dot gnu dot org]

Trunk fails to build Qt4 on both s390 and s390x.

./cc1plus -quiet -O2 -fPIC qregexp.3.ii 
qregexp.3.ii: In member function 'void QVector::realloc(int, int) [with T =
QRegExpAutomatonState]':
qregexp.3.ii:99: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868
   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: rguenth at gcc dot gnu dot org
GCC target triplet: s390-*-*, s390x-*-*


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

[Bug c++/36744] function modifying argument received by-value affects caller's variable when passed as rvalue

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net  2008-07-06 
14:48 ---
Forgot to mention: compile with -std=c++0x.


-- 


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

[Bug c++/36744] New: function modifying argument received by-value affects caller's variable when passed as rvalue

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  #include 

  struct S
  {
S(): i(2) {}
S(S const&) {}
int i;
  };

  void f(S x) { x.i = 0; }

  int main()
  {
S y;
f(static_cast(y));
std::cout << y.i << '\n';
  }

Expected output: 2
Actual output: 0

Thus, the assignment to the independent local variable x in f somehow modifies
y. That can't be right, not even with that static_cast to S&&, can it?


-- 
   Summary: function modifying argument received by-value affects
caller's variable when passed as rvalue
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug libstdc++/36742] [4.2 Regression] g++ -O2 produces wrong code

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-07-06 14:14 
---
You can categorize as libstdc++, but I'm afraid nobody is going to do much, for
many reasons: nothing substantive changed, possibly affecting the aliasing, in
 and ; the but cannot be reproduced with current 4_3-branch
and mainline. At least please provide a reduced testcase pointing to the
libstdc++ lines at fault.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug libstdc++/36742] [4.2 Regression] g++ -O2 produces wrong code

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-07-06 13:40 ---
Confirmed.  Works with gcc 4.3.  Aliasing problem, -O2 -fno-strict-aliasing
works.
So eventually a libstdc++ issue?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |libstdc++
 Ever Confirmed|0   |1
   Keywords||alias, wrong-code
  Known to fail|4.2.2   |4.2.2 4.2.4
  Known to work|4.1.2 4.0.2 4.0.1 3.4.6 |4.1.2 4.0.2 4.0.1 3.4.6
   ||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2008-07-06 13:40:43
   date||
Summary|g++ -O2 produces wrong code |[4.2 Regression] g++ -O2
   ||produces wrong code
   Target Milestone|--- |4.2.5


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

[Bug middle-end/31150] [4.2/4.3/4.4 Regression] Not promoting an whole array to be static const

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|eres at il dot ibm dot com  |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug web/36739] Proposal for clarifications in GCC Bugzilla

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-07-06 13:34 ---
I think it is still useful to increase the quality of reported bugs.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug target/36713] [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2008-07-06 13:29 
---
Mine.


-- 

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-07-06 13:29:20
   date||


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

[Bug fortran/36743] New: ICE in pow_c4_i4 when compiling snapshot of 07/04/08 under HP-PA Linux

[michael dot a dot richmond at nasa dot gov]

When I compile the snapshot of 07/04/08 on an HP-PA workstation under Debian
Linux 4.0 I get the following messages:

libtool: compile:  /home/mrichmon/gcc-4.4-20080704/g95/./gcc/xgcc
-B/home/mrichmon/gcc-4.4-20080704/g95/./gcc/
-B/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/bin/
-B/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/lib/ -isystem
/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/include -isystem
/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/home/mrichmon/gcc-4.4-20080704/libgfortran -I.
-iquote/home/mrichmon/gcc-4.4-20080704/libgfortran/io
-I/home/mrichmon/gcc-4.4-20080704/libgfortran/../gcc
-I/home/mrichmon/gcc-4.4-20080704/libgfortran/../gcc/config -I../.././gcc
-D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT
pow_c4_i4.lo -MD -MP -MF .deps/pow_c4_i4.Tpo -c
/home/mrichmon/gcc-4.4-20080704/libgfortran/generated/pow_c4_i4.c  -fPIC -DPIC
-o .libs/pow_c4_i4.o
/home/mrichmon/gcc-4.4-20080704/libgfortran/generated/pow_c4_i4.c: In function
'pow_c4_i4':
/home/mrichmon/gcc-4.4-20080704/libgfortran/generated/pow_c4_i4.c:46: internal
compiler error: in emit_move_insn, at expr.c:3379
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [pow_c4_i4.lo] Error 1
make[3]: Leaving directory
`/home/mrichmon/gcc-4.4-20080704/g95/hppa1.1-unknown-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/mrichmon/gcc-4.4-20080704/g95/hppa1.1-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/home/mrichmon/gcc-4.4-20080704/g95'
make: *** [all] Error 2
Error running make


-- 
   Summary: ICE in pow_c4_i4 when compiling snapshot of 07/04/08
under HP-PA Linux
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-07-06 12:27 
---
I don't think we "used" it before either?  Still the _computing_ of niters
can be easily re-instantiated - it wasn't the expensive thing here.  But I
had the impression SCEV computes niters itself when needed, so the removal
of the upfront computation was just an "optimization".  Note that Zdenek
added it to not do this expensive thing multiple times.


-- 


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

[Bug tree-optimization/19790] equality not noticed when signedness differs.

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-07-06 12:20 ---
So we can optimize

void __attribute__((noinline))
bar (int i)
{
  asm ("");
}

extern void link_error (void);
void
foo (void)
{
  int i;
  for (i = 0; i <= 320; i++)
{
  bar (i);
  if (i > 320)
link_error ();
}
}

but not

void __attribute__((noinline))
bar (int i)
{
  asm ("");
}

extern void link_error (void);
void
foo (void)
{
  int i, j = 2;
  for (i = 0; i <= 320; i++)
{
  j++;
  bar (j);
  if (j > 322)
link_error ();
}
}

even with the niter computation hunk restored from the PR34244 patch.


-- 


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

[Bug tree-optimization/35642] [4.4 Regression] heisenbug in tree vectorizer

[irar at il dot ibm dot com]

--- Comment #16 from irar at il dot ibm dot com  2008-07-06 11:57 ---
(In reply to comment #15)
> (In reply to comment #14)
> > Also Victor tried to reproduced the behavior that Kenny described in
> > comment #3 
> 
> comment #1

Grrr, it was in the problem description not in the comments.

Sorry again,
Ira


-- 


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

[Bug tree-optimization/35642] [4.4 Regression] heisenbug in tree vectorizer

[irar at il dot ibm dot com]

--- Comment #15 from irar at il dot ibm dot com  2008-07-06 11:55 ---
(In reply to comment #14)
> Also Victor tried to reproduced the behavior that Kenny described in
> comment #3 

comment #1

Sorry,
Ira


-- 


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

[Bug tree-optimization/35642] [4.4 Regression] heisenbug in tree vectorizer

[irar at il dot ibm dot com]

--- Comment #14 from irar at il dot ibm dot com  2008-07-06 11:54 ---
All those failures occur because vector multiplication of shorts to shorts is
not supported on power. Paolo's patch changed the order of type conversion and
multiplication, and removed type conversions. 

All those loops contain multiplication either of type short = short * constant
or short = int * constant. For the first case we used to have conversion to
int, multiplication, and conversion to short, and now there are no type
conversions. For the second case, before the patch there was first
multiplication of ints and then the result was converted to short, and now the
conversion to short comes first and then there is multiplication of shorts. In
other words, before Paolo's patch those loops contained multiplications of ints
(supported) and now they contain multiplications of shorts (not supported).

As for the heisenbug, first of all, the failures occur with and without
bootstrap. Also Victor tried to reproduced the behavior that Kenny described in
comment #3 (on the same revision and the same configuration), but he saw the
failures with a bootstrapped version too. I.e., we can't reproduce the random
behavior - the failures are deterministic and well understood.

I suggest to open a missed-optimization PR for vector multiplication of shorts
to shorts (seems easy to fix), to xfail the tests, and to close this PR.

Ira


-- 


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

[Bug c++/36742] g++ -O2 produces wrong code

[michael at jarvis dot net]

--- Comment #2 from michael at jarvis dot net  2008-07-06 11:40 ---
(From update of attachment 15863)
g++ -v outputs:

Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.2.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.2
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --host=i686-apple-darwin9 --with-gmp=/sw
--with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.2.2

My system is a MacBook 2.2 GHz Intel Core 2 Duo running MaxOsX 10.5.4

I am using the fink installation of gcc.


-- 


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

[Bug c++/36742] g++ -O2 produces wrong code

[michael at jarvis dot net]

--- Comment #1 from michael at jarvis dot net  2008-07-06 11:31 ---
Created an attachment (id=15863)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15863&action=view)
preprocessed source code


-- 


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

[Bug c++/36742] New: g++ -O2 produces wrong code

[michael at jarvis dot net]

The following code produces correct output with g++ -O, but wrong output with
g++ -O2:
The basic calculation should be just a product of two complex numbers, each
equal to (1,1), so the output should be (and is with g++ -O):

a = (0,2)

However, on my system, the output with the -O2 flag is:

a = (-1.22015e-313,1.22015e-313)

Furthermore, any one of the following changes "fixes" the problem:

Any one of the following changes "fix" the problem:

- Removing either Assert statement in foo
- Removing the imag(b.val) branch in foo
- Removing the trigraph in foo
- Removing s2 from Error
- Removing base class of A
- Removing junk from A

Here is the code:

#include 
#include 
#include 

class B
{
  public:
virtual size_t one() const = 0;
virtual ~B() {}
};

class A : public B
{
  public:

A(std::complex _val) : itsval(_val), junk(1) {}
~A() {}

std::complex& val() { return itsval; }
size_t one() const { return 1; }

  protected :

std::complex itsval;
const size_t junk;
};

class Error
{
  public :
std::string s1, s2;
inline Error(std::string _s1, std::string _s2="") throw() :
  s1(_s1), s2(_s2) {}
virtual inline ~Error() throw() {}
};

#define Assert(x) do { if(!(x)) { throw Error(#x); } } while(false)

void foo(A& a, std::complex b)
{
  Assert(a.one() == 1);
  Assert(a.one() == 1);

  if (std::imag(b) == double(0))
a.val() *= std::real(b);
  else
a.val() *= (true ? b : std::conj(b));
}

int main()
{
  A a(std::complex(1,1));
  std::complex b(1,1);

  foo(a, b);
  std::cout<<"a = "

[Bug target/36570] segmentation fault

[info at milde dot cz]

--- Comment #5 from info at milde dot cz  2008-07-06 10:16 ---
Subject: Re:  segmentation fault

pinskia at gcc dot gnu dot org napsal(a):
> --- Comment #4 from pinskia at gcc dot gnu dot org  2008-07-05 19:06 
> ---
> You need to provide the preprocessed source as directed by the instructions:
>   
>> with preprocessed source if appropriate.
>> 
>  :).
>
>
>   
Ok, let it be :) I seems that it could be imposed by faulty memory.

-- 
Daniel Milde
Milde.cz
*
U zastávky 1, Modøany
143 00 Praha 4
IÈO: 715 26 374
mob.: +420 777 609 440
tel: +420 241 941 229
*
http://milde.cz
[EMAIL PROTECTED]


--- Comment #6 from info at milde dot cz  2008-07-06 10:16 ---
Created an attachment (id=15862)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15862&action=view)


-- 


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

[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2008-07-06 09:59 ---
It looks like we don't use a known number of loop iterations at all anymore
after this patch.


-- 


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

[Bug target/34780] Bootstrapping libstdc++-v3 failed

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2008-07-06 09:47 ---
Proposed patch at 


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org
 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-06 09:47:31
   date||


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

[Bug tree-optimization/19790] equality not noticed when signedness differs.

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2008-07-06 09:37 ---
Still doesn't work.  You need to replace one line for the test case of comment
#0 though, because the tree optimizers are now smart enough to see that (i/32)
is always 0.  So replace 

   for (i = 0; i <= 10; i++)

with

   for (i = 0; i <= 320; i++)

and you still get the missed optimization.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-05-05 08:36:26 |2008-07-06 09:37:27
   date||


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

[Bug tree-optimization/23455] tree load PRE is not working for global variables

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2008-07-06 08:53 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00430.html

We should re-evaluate the need for gcse.c load-PRE after Daniel's patch goes
in.  The last time I looked at what loads gcse.c load-PRE would move, it only
touched loads from globals, so it may be a redundant pass when tree-ssa-pre
moves them.


-- 


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

[Bug c++/34963] [4.3/4.4 regression] ICE completely broken destructor

[simartin at gcc dot gnu dot org]

--- Comment #3 from simartin at gcc dot gnu dot org  2008-07-06 07:55 
---
Patch submitted here:
  http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00440.html


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||simartin at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |simartin at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-25 09:57:07 |2008-07-06 07:55:51
   date||


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

[Bug c++/36741] New: [4.3,4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[ian at airs dot com]

Compiling this simple C++ program with 4.3 or 4.4:

#include 
const char* foo() { return new char[~static_cast(0)]; }

gives this warning:

foo.cc: In function ‘const char* foo()’:
foo.cc:2: warning: large integer implicitly truncated to unsigned type

The warning is bogus: there is no truncation here.  It would be reasonable to
give a warning that the new would fail, but the warning it actually gives is
simply wrong.  I haven't looked into this much, but it seems to be related to
sizetype.

4.1 gives no warning.  I don't have 4.2 handy.


-- 
   Summary: [4.3,4.4 regression] Bogus "large integer implicitly
truncated" passing size_t constant to new
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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