[Bug optimization/14863] New: [3.4 regression] unit-at-a-time causes miscompilation

[Bug optimization/14863] New: [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

The bctest3 POOMA testcase gets miscompiled by
g++ (GCC) 3.4.0 20040319 (prerelease)
and newer and was fine with
g++ (GCC) 3.4.0 20040302 (prerelease)
and before.

I'm using an unincluded testcase because of libstdc++ compilation issues of
older releases and because using the .ii causes older releases to fail, too.
So this may be a libstdc++ issue (or just bad luck interaction).

Using -O on the testcase makes it pass, using -O -funit-at-a-time makes it
segfault with the exact failure depending on argv[0] length.  Unit at a time may
be just triggering the failure of some optimization pass due to changed inlining
heuristics, but I wasn't able to find an optimization switch that triggers it.

Delta is currently minimizing the large testcase.

-- 
           Summary: [3.4 regression] unit-at-a-time causes miscompilation
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-06 11:44 -------
Created an attachment (id=6042)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6042&action=view)
unreduced testcase (unincluded)


-- 


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
      Known to fail|                            |3.4.0
      Known to work|                            |3.3.3


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.4.1


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[1319 at bot dot ru]

------- Additional Comments From 1319 at bot dot ru  2004-04-06 23:48 -------
I tried gcc-3_4-branch from 20040320 to branchpoint (20040116) with 1/2 month
interval and HEAD-20040403 -- no one compiles this testcase correctly (it hangs
if compiled with -O1 -funit-at-a-time), though tree-ssa is OK.

Are you sure that gcc 3.4.0 ever compiled properly the testcase?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |1319 at bot dot ru


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-07 07:59 -------
Subject: Re:  [3.4 regression] unit-at-a-time causes
 miscompilation

On Wed, 6 Apr 2004, 1319 at bot dot ru wrote:

>
> ------- Additional Comments From 1319 at bot dot ru  2004-04-06 23:48 -------
> I tried gcc-3_4-branch from 20040320 to branchpoint (20040116) with 1/2 month
> interval and HEAD-20040403 -- no one compiles this testcase correctly (it hangs
> if compiled with -O1 -funit-at-a-time), though tree-ssa is OK.

Did it work with just -O1?

> Are you sure that gcc 3.4.0 ever compiled properly the testcase?

Yes, I specifically checked 20040405, 20040331 and 20040319 which don't
work and 20040302, 20040301, 20040212, 20040107 and 20031117 which all
work.

This is on ia32-linux.

But it's certainly interesting that it hangs, as this is the symptom I'm
seeing in my main application.


-- 


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-07 08:00 -------
Created an attachment (id=6049)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6049&action=view)
level 0 reduced testcase


-- 


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-07 08:04 -------
Delta with level 0 topformflat completed after 18h36min, reduced testcase
attached.  Failure is now independent of argv[0] length and always just
segfaults (at -O1 -funit-at-a-time, not -O1).  I've started a level 1 reduction
now, but I assume this will take a long time.  I have manually reduced main() to
reduce compile time, but there was not much to remove - removing more will
either magically fix the testcase or break it compile-wise.

-- 


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[1319 at bot dot ru]

------- Additional Comments From 1319 at bot dot ru  2004-04-07 10:25 -------
(In reply to comment #3)
> Did it work with just -O1?

Yes.

-- 


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[1319 at bot dot ru]

------- Additional Comments From 1319 at bot dot ru  2004-04-07 11:55 -------
I have just found that this bug can be triggered on/off using --param
large-function-insns=<something> option. Default value of this changed from
10000 before gcc-3_4-branch creation to 3000 shortly after.

All versions of 3.4.0 and 3.5.0 I tried (20040116..now) are OK with '-O1
-funit-at-a-time --param large-function-insns=10000' and all failed with '-O1
-funit-at-a-time --param large-function-insns=3000'.

-- 


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

[Bug optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-07 12:04 -------
Subject: Re:  [3.4 regression] unit-at-a-time causes
 miscompilation

On Wed, 7 Apr 2004, 1319 at bot dot ru wrote:

>
> ------- Additional Comments From 1319 at bot dot ru  2004-04-07 11:55 -------
> I have just found that this bug can be triggered on/off using --param
> large-function-insns=<something> option. Default value of this changed from
> 10000 before gcc-3_4-branch creation to 3000 shortly after.
>
> All versions of 3.4.0 and 3.5.0 I tried (20040116..now) are OK with '-O1
> -funit-at-a-time --param large-function-insns=10000' and all failed with '-O1
> -funit-at-a-time --param large-function-insns=3000'.

Yes, it sounds the bug is triggered by (not) inlining some special
function somewhere special.  At least I didn't find an optimization
switch, if disabled, that cures the failure at -O1 -funit-at-a-time.

Testcase is still minimizing (slowly).

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/


-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-07 13:06 -------
Here is the backtrace I get with the mainline at -O1 -g -funit-at-a-time --param large-function-
insns=3000:

#0  0x4207af5c in chunk_free () from /lib/i686/libc.so.6
#1  0x4207acb4 in free () from /lib/i686/libc.so.6
#2  0x400bf761 in operator delete (ptr=0x4212e0f0)
    at /home/gates/pinskia/src/gnu/gcc/src/libstdc++-v3/libsupc++/del_op.cc:39
#3  0x0805faa3 in ~PatchSwapLayout (this=0xbffec080) at pr14863.cc:9943  <-- not right function 
name
#4  0x080539ff in main (argc=1, argv=0xbffec194) at pr14863.cc:52762



I think this is related to some pointer :
 char *tmp = new char[nsize];
 pBeginNew = reinterpret_cast<T *>(tmp);


 char *tmp = reinterpret_cast<char *>(pBegin_m);
 delete [] tmp;  <--- crashing here

I do not understand why the code is doing this though as you should be just using new T[newsize] 
instead.  The other thing is that you could be over running the buffer which could cause this problem.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.4 regression] unit-at-a- |[3.4/3.5 regression] unit-
                   |time causes miscompilation  |at-a-time causes
                   |                            |miscompilation


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-07 13:26 -------
Subject: Re:  [3.4/3.5 regression] unit-at-a-time
 causes miscompilation

On Wed, 7 Apr 2004, pinskia at gcc dot gnu dot org wrote:

>
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-07 13:06 -------
> Here is the backtrace I get with the mainline at -O1 -g -funit-at-a-time --param large-function-
> insns=3000:
>
> #0  0x4207af5c in chunk_free () from /lib/i686/libc.so.6
> #1  0x4207acb4 in free () from /lib/i686/libc.so.6
> #2  0x400bf761 in operator delete (ptr=0x4212e0f0)
>     at /home/gates/pinskia/src/gnu/gcc/src/libstdc++-v3/libsupc++/del_op.cc:39
> #3  0x0805faa3 in ~PatchSwapLayout (this=0xbffec080) at pr14863.cc:9943  <-- not right function
> name
> #4  0x080539ff in main (argc=1, argv=0xbffec194) at pr14863.cc:52762
>
>
>
> I think this is related to some pointer :
>  char *tmp = new char[nsize];
>  pBeginNew = reinterpret_cast<T *>(tmp);
>
>
>  char *tmp = reinterpret_cast<char *>(pBegin_m);
>  delete [] tmp;  <--- crashing here
>
> I do not understand why the code is doing this though as you should be just using new T[newsize]
> instead.  The other thing is that you could be over running the buffer which could cause this problem.

Yes, it looks a bit twisted, but I think the purpose of allocating and
deallocating char[] rather than T[] is to allow manual (default)
constructing the objects, or not, by using placement new to the individual
elements.  This has been done for optimization purposes, I think, but I
may be wrong.

Is anything conceptually wrong with the following?

  T *m = reinterpret_cast<T *>(new char[n*sizeof(T)]);
  for (int i=0; i<n; ++i)
    new (&m[i]) T;
  for (int i=0; i<n; ++i)
    m[i].~T();
  delete [] reinterpret_cast<char *>(m);

if yes, there may be problems within the code.  There is bounds checking
code available, so I'll check if we don't override some here.

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/


-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-07 13:37 -------
Subject: Re:  [3.4/3.5 regression] unit-at-a-time
 causes miscompilation

On Wed, 7 Apr 2004, pinskia at gcc dot gnu dot org wrote:

> The other thing is that you could be over running the buffer which could
> cause this problem.

Enabling bounds-checking code doesn't show any errors.


-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-04-07 13:44 -------
The code is OK, and it's a common idiom in C++ (for instance, STL allocators). 
It's even mentioned in the standard ([expr.new]/10).

-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-07 16:08 -------
I decided to try to debug this without the use of the reduced sources (well I removed the 
mutex stuff though):
hi 0x8086488  <--- address from this in ~RefCounted

Program received signal SIGSEGV, Segmentation fault.
0x4207af5c in chunk_free () from /lib/i686/libc.so.6
(gdb) up
#1  0x4207acb4 in free () from /lib/i686/libc.so.6
(gdb) 
#2  0x400bf761 in operator delete (ptr=0x4212e0f8)

-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-07 20:55 -------
Actually the address in the backtrace is wrong.
I added some printf statements to figure out what is going on:
invalidate: 0x80872a8   <--- the one which it is seg faulting on.
~DataBlockController: 0x80872e0

Breakpoint 1, 0x4207ad06 in chunk_free () from /lib/i686/libc.so.6
#0  0x4207ad06 in chunk_free () from /lib/i686/libc.so.6
#1  0x4207acb4 in free () from /lib/i686/libc.so.6
#2  0x400bf761 in operator delete (ptr=0x4212dfa0)
    at /home/gates/pinskia/src/gnu/gcc/src/libstdc++-v3/libsupc++/del_op.cc:39
#3  0x08061734 in ~PatchSwapLayout (this=0xbffec080) at pr14863.cc:12229
#4  0x080545ff in main (argc=1, argv=0xbffec194) at pr14863.cc:52678
deleteStorage: 0x80872d0

Breakpoint 1, 0x4207ad06 in chunk_free () from /lib/i686/libc.so.6
#0  0x4207ad06 in chunk_free () from /lib/i686/libc.so.6
#1  0x4207acb4 in free () from /lib/i686/libc.so.6
#2  0x400bf761 in operator delete (ptr=0x4212dfa0)
    at /home/gates/pinskia/src/gnu/gcc/src/libstdc++-v3/libsupc++/del_op.cc:39
#3  0x400bf7bd in operator delete[] (ptr=0x4212dfa0)
    at /home/gates/pinskia/src/gnu/gcc/src/libstdc++-v3/libsupc++/del_opv.cc:36
#4  0x08061814 in ~PatchSwapLayout (this=0xbffec080) at pr14863.cc:11578
#5  0x080545ff in main (argc=1, argv=0xbffec194) at pr14863.cc:52678

Breakpoint 1, 0x4207ad06 in chunk_free () from /lib/i686/libc.so.6
#0  0x4207ad06 in chunk_free () from /lib/i686/libc.so.6
#1  0x4207acb4 in free () from /lib/i686/libc.so.6
#2  0x400bf761 in operator delete (ptr=0x4212dfa0)
    at /home/gates/pinskia/src/gnu/gcc/src/libstdc++-v3/libsupc++/del_op.cc:39
#3  0x0806181c in ~PatchSwapLayout (this=0xbffec080) at pr14863.cc:9882
#4  0x080545ff in main (argc=1, argv=0xbffec194) at pr14863.cc:52678

Program received signal SIGSEGV, Segmentation fault.
0x4207af5c in chunk_free () from /lib/i686/libc.so.6

-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-08 11:57 -------
Still reducing...  meanwhile, I attached a patch to deltas topformflat.l to
allow it skipping namespace {} constructs as nesting specifiers, so with level 0
you now get all toplevel classes/functions wether they're inside a namespace or not.

-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-08 11:58 -------
Created an attachment (id=6053)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6053&action=view)
patch to topformflat.l


-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-09 13:09 -------
Here is more prove which delete, it is seg faulting in:
invalidate: 0x80b0588
~DataBlockController: 0x80b05c0
after ~DataBlockController
deleteStorage: 0x80b05b0
After deleteStorage.
<---Seg fault at this point.

-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-09 13:12 -------
Now if I remove the delete I get:
### POOMA Assertion Failure ###
Pooma::pAbort called.
In default abort handler.
And here is the backtrace:
#0  0x420292d1 in kill () from /lib/i686/libc.so.6
#1  0x420290ba in raise () from /lib/i686/libc.so.6
#2  0x4202a862 in abort () from /lib/i686/libc.so.6
#3  0x0804d94c in Pooma::pAbort (msg=0x0) at pr14863.cc:21960
#4  0x0804d965 in Pooma::pAbort (errorcode=0) at pr14863.cc:21931
#5  0x0804d9b8 in Pooma::toss_cookies (msg=0x0,
    file=0x8086b80 "/home/rguenth/src/pooma-mpi3/r2/src/Utilities/Pool.cmpl.cpp", line=
82) at pr14863.cc:23190
#6  0x0804d9e5 in ~Pool (this=0x808d8c8) at pr14863.cc:23235
#7  0x0804da8e in __tcf_9 () at pr14863.cc:4227
#8  0x4202bbfb in exit () from /lib/i686/libc.so.6
#9  0x420174e2 in __libc_start_main () from /lib/i686/libc.so.6
#10 0x080497d1 in _start ()

-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-09 13:35 -------
Commenting out the delete in deleteStorage lets the program run just fine.  I am 
wondering if someone is holding on to the pointer too long, can someone run this 
program with valgrind?

-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-09 21:22 -------
Subject: Re:  [3.4/3.5 regression] unit-at-a-time
 causes miscompilation

pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-09 13:35 -------
> Commenting out the delete in deleteStorage lets the program run just fine.  I am 
> wondering if someone is holding on to the pointer too long, can someone run this 
> program with valgrind?

The -O1 version is ok:

bellatrix:~/tmp/delta/bctest3$ valgrind ./bctest3.ok
==19455== Memcheck, a memory error detector for x86-linux.
==19455== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==19455== Using valgrind-2.1.0, a program supervision framework for 
x86-linux.
==19455== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==19455== Estimated CPU clock rate is 1010 MHz
==19455== For more details, rerun with: -v
==19455==
==19455==
==19455== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==19455== malloc/free: in use at exit: 284 bytes in 10 blocks.
==19455== malloc/free: 14 allocs, 4 frees, 301 bytes allocated.
==19455== For a detailed leak analysis,  rerun with: --leak-check=yes
==19455== For counts of detected errors, rerun with: -v

The -O1 -funit-at-a-time version not:

==19618== Memcheck, a memory error detector for x86-linux.
==19618== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==19618== Using valgrind-2.1.0, a program supervision framework for 
x86-linux.
==19618== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==19618== Estimated CPU clock rate is 1009 MHz
==19618== For more details, rerun with: -v
==19618==
==19618== Conditional jump or move depends on uninitialised value(s)
==19618==    at 0x804A5E4: Engine<1, double, 
DynamicView>::Engine(Engine<1, double, DynamicView> const&, Interval<1> 
const&) (in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A670: Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > >::Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > >, Interval<1> >(Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > > const&, Interval<1> const&) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A814: 
_ZN10ParticleBCI5ArrayILi1Ed13ExpressionTagI10BinaryNodeI5OpAdd9ReferenceIS0_ILi1EdS1_IS2_I10OpMultiplyS4_IS0_ILi1Ed10MultiPatchI10DynamicTag7DynamicEEESB_EEEESF_EEE11MyParticlesI16MPDynamicUniformE6KillBCIdEE22applyBoundaryConditionEi 
(in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x80498E4: 
Particles<MPDynamicUniform>::applyBoundaryConditions(int) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==
==19618== Use of uninitialised value of size 4
==19618==    at 0x804A60A: Engine<1, double, 
DynamicView>::Engine(Engine<1, double, DynamicView> const&, Interval<1> 
const&) (in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A670: Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > >::Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > >, Interval<1> >(Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > > const&, Interval<1> const&) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A814: 
_ZN10ParticleBCI5ArrayILi1Ed13ExpressionTagI10BinaryNodeI5OpAdd9ReferenceIS0_ILi1EdS1_IS2_I10OpMultiplyS4_IS0_ILi1Ed10MultiPatchI10DynamicTag7DynamicEEESB_EEEESF_EEE11MyParticlesI16MPDynamicUniformE6KillBCIdEE22applyBoundaryConditionEi 
(in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x80498E4: 
Particles<MPDynamicUniform>::applyBoundaryConditions(int) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==
==19618== Use of uninitialised value of size 4
==19618==    at 0x804A610: Engine<1, double, 
DynamicView>::Engine(Engine<1, double, DynamicView> const&, Interval<1> 
const&) (in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A670: Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > >::Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > >, Interval<1> >(Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > > const&, Interval<1> const&) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A814: 
_ZN10ParticleBCI5ArrayILi1Ed13ExpressionTagI10BinaryNodeI5OpAdd9ReferenceIS0_ILi1EdS1_IS2_I10OpMultiplyS4_IS0_ILi1Ed10MultiPatchI10DynamicTag7DynamicEEESB_EEEESF_EEE11MyParticlesI16MPDynamicUniformE6KillBCIdEE22applyBoundaryConditionEi 
(in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x80498E4: 
Particles<MPDynamicUniform>::applyBoundaryConditions(int) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==
==19618== Invalid read of size 4
==19618==    at 0x804A613: Engine<1, double, 
DynamicView>::Engine(Engine<1, double, DynamicView> const&, Interval<1> 
const&) (in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A670: Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > >::Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > >, Interval<1> >(Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > > const&, Interval<1> const&) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A814: 
_ZN10ParticleBCI5ArrayILi1Ed13ExpressionTagI10BinaryNodeI5OpAdd9ReferenceIS0_ILi1EdS1_IS2_I10OpMultiplyS4_IS0_ILi1Ed10MultiPatchI10DynamicTag7DynamicEEESB_EEEESF_EEE11MyParticlesI16MPDynamicUniformE6KillBCIdEE22applyBoundaryConditionEi 
(in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x80498E4: 
Particles<MPDynamicUniform>::applyBoundaryConditions(int) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==  Address 0x76005550 is not stack'd, malloc'd or free'd
==19618==
==19618== Use of uninitialised value of size 4
==19618==    at 0x804A620: Engine<1, double, 
DynamicView>::Engine(Engine<1, double, DynamicView> const&, Interval<1> 
const&) (in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A670: Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > >::Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > >, Interval<1> >(Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > > const&, Interval<1> const&) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A814: 
_ZN10ParticleBCI5ArrayILi1Ed13ExpressionTagI10BinaryNodeI5OpAdd9ReferenceIS0_ILi1EdS1_IS2_I10OpMultiplyS4_IS0_ILi1Ed10MultiPatchI10DynamicTag7DynamicEEESB_EEEESF_EEE11MyParticlesI16MPDynamicUniformE6KillBCIdEE22applyBoundaryConditionEi 
(in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x80498E4: 
Particles<MPDynamicUniform>::applyBoundaryConditions(int) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==
==19618== Invalid read of size 4
==19618==    at 0x804A626: Engine<1, double, 
DynamicView>::Engine(Engine<1, double, DynamicView> const&, Interval<1> 
const&) (in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A670: Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > >::Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > >, Interval<1> >(Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > > const&, Interval<1> const&) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A814: 
_ZN10ParticleBCI5ArrayILi1Ed13ExpressionTagI10BinaryNodeI5OpAdd9ReferenceIS0_ILi1EdS1_IS2_I10OpMultiplyS4_IS0_ILi1Ed10MultiPatchI10DynamicTag7DynamicEEESB_EEEESF_EEE11MyParticlesI16MPDynamicUniformE6KillBCIdEE22applyBoundaryConditionEi 
(in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x80498E4: 
Particles<MPDynamicUniform>::applyBoundaryConditions(int) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==  Address 0x0 is not stack'd, malloc'd or free'd
==19618==
==19618== Process terminating with default action of signal 11 
(SIGSEGV): dumping core
==19618==  Address not mapped to object at address 0x0
==19618==    at 0x804A626: Engine<1, double, 
DynamicView>::Engine(Engine<1, double, DynamicView> const&, Interval<1> 
const&) (in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A670: Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > >::Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > >, Interval<1> >(Array<1, double, 
ExpressionTag<BinaryNode<OpMultiply, Array<1, double, DynamicView>, 
Array<1, double, DynamicView> > > > const&, Interval<1> const&) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x804A814: 
_ZN10ParticleBCI5ArrayILi1Ed13ExpressionTagI10BinaryNodeI5OpAdd9ReferenceIS0_ILi1EdS1_IS2_I10OpMultiplyS4_IS0_ILi1Ed10MultiPatchI10DynamicTag7DynamicEEESB_EEEESF_EEE11MyParticlesI16MPDynamicUniformE6KillBCIdEE22applyBoundaryConditionEi 
(in /net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==    by 0x80498E4: 
Particles<MPDynamicUniform>::applyBoundaryConditions(int) (in 
/net/bellatrix/home/rguenth/tmp/delta/bctest3/bctest3.fail)
==19618==
==19618== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0)
==19618== malloc/free: in use at exit: 297 bytes in 13 blocks.
==19618== malloc/free: 14 allocs, 1 frees, 301 bytes allocated.
==19618== For a detailed leak analysis,  rerun with: --leak-check=yes
==19618== For counts of detected errors, rerun with: -v



------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-04-10 14:49 -------
Subject: Re:  [3.4/3.5 regression] unit-at-a-time
 causes miscompilation

The reduction is done, but it didn't leave me with something useful :(
Until someone figures out what is wrong with the original testcase, I'll 
give up on this.  Pooma testcases seem to be useless :(

Anyway, I should have spent the time finding the cause of miscompilation 
on code _I_ wrote...


-- 


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

[Bug optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[1319 at bot dot ru]

------- Additional Comments From 1319 at bot dot ru  2004-04-10 22:16 -------
I have just figured out that delete() segfaults because new() returned wrong
pointer; it can be shown using overloaded operators new() and delete(). This
happens because there is a memory corruption somewhere...

To figure out where I used custom new() and memprotect():
(put this code before main(), and add #include <sys/mman.h>)

void *pool;
int last = 1;
#define NMAX 0x80
#define NSIZ 0x10000

void* operator new(size_t size)
{
	void *p;
	if (!pool) {
		// allocate page aligned NMAX*NSIZ bytes of memory
		// (assume pagesize = 0x1000)
		pool = (void *) (0xFFFFF000 &
				 ((long) calloc (1, NMAX*NSIZ) + 0xFFF));
		mprotect (pool, NMAX*NSIZ, PROT_NONE);
	}
	if (last >= (NMAX-1)) {
		fprintf (stderr, "out of memory");
		abort ();
	}

	// (1) guards access below returned pointer
	//p = (void *) ((long) pool + (last++)*NSIZ);

	// (2) guards access above returned pointer
	p = (void *) ((long) pool + (last++)*NSIZ - ((size + 3) & 0xFFFFFFFC));
	
	mprotect ((void *) ((long) p & 0xFFFFF000), size, PROT_READ|PROT_WRITE);

	// test of (1)
	//*((char *) p - 1) = 0; /* segfault */

	// test of (2)
        //*((char *) p + size + 3) = 0; /* segfault */

	fprintf (stderr, "new: size = %lu, p = %p\n", size, p);
	return p;
	//return calloc (1, size);
}

void operator delete(void* p)
{
 	fprintf (stderr, "delete: %p\n", p);
	//free (p);
}

This new() returns pointer to memory block surrounded by pages with no access.
Alas protection can be set only for entire page, so there is two versions: (1)
places block at beginning of page with rw acces, and (2) at end of it.

(1) does not work, it seems that there is no wrong memory references below
allocated blocks. But (2) works as expected, with -O1 -funit-at-a-time --param
large-function-insns=1000 program gets segfault in new place:

Program received signal SIGSEGV, Segmentation fault.
0x08056d6e in Engine<1, int, Dynamic>::performDestroy<IntervalIterator>
(this=0x4042cfec, killBegin=@0x9, killEnd=@0x9)
    at pr14863.cc:4196
4196            return tmp;
(gdb) where
#0  0x08056d6e in Engine<1, int, Dynamic>::performDestroy<IntervalIterator>
(this=0x4042cfec, killBegin=@0x9, killEnd=@0x9)
    at pr14863.cc:4196
#1  0x08056f35 in Engine<1, int, Dynamic>::performDestroy<Interval<1> >
(this=0x9, killList=@0xbffff530, offsetFlag=false)
    at pr14863.cc:12135
#2  0x08056f71 in Engine<1, int, Dynamic>::destroy<Interval<1> > (this=0x9,
killList=@0x9) at pr14863.cc:4513
#3  0x080571f0 in Particles<MPDynamicUniform>::performDestroy (this=0xbffff7b0,
pid=-1073744704, renum=true) at pr14863.cc:11218
#4  0x0804fb35 in main (argc=1, argv=0xbffff994) at pr14863.cc:14496
(gdb) list
14496           P.performDestroy();
14497           DynamicArray < Vector < 2, int >, MultiPatch < DynamicTag,
Dynamic > >a3;
14498           Interval < 1 > empty;
14499           DynamicLayout layout(empty, 1);
14500           a3.initialize(layout);
14501           a3.create(20);
14502   }
(gdb) list 4196
4191            return tmp;
4192        }
4193        This_t operator--(int) {
4194            This_t tmp(*this);
4195            RCBPtr_t::operator--();
4196            return tmp;
4197        }
4198        This_t operator+(ptrdiff_t i) const {
4199            This_t ret(*this);
4200            ret += i;
(gdb) q

-- 


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

[Bug rtl-optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[belyshev at lubercy dot com]

------- Additional Comments From belyshev at lubercy dot com  2004-06-02 00:08 -------
Created an attachment (id=6448)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6448&action=view)
small testcase (818 bytes)

compile this with '-O1 -funit-at-a-time --param large-function-insns=100' and
see what it prints. It should print three zeroes...


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-02 00:19 -------
Confirmed and here is a test which can go into the testsuite and is slightly smaller:
extern "C" void abort();
struct DomainBase {  ~DomainBase() {} };
struct Interval :public DomainBase {
        Interval () {}
        Interval (const Interval &a) {}
};
struct IntervalIterator
{
        IntervalIterator()
        {  val_m = 1;  }
        const int & operator*() const
        { return val_m;  }
        IntervalIterator & operator--()
        {
                val_m -= 1;
                return *this;
        }
        Interval abrakadabra;
        int val_m;
};
struct reverse_iterator {
        const int &operator*() const
        {
                IntervalIterator tmp = current;
                return *--tmp;
        }
        IntervalIterator current;
};
int main ()
{
        reverse_iterator rk_pos;
        if (*rk_pos)
          abort();
        if (*rk_pos)
          abort();
        if (*rk_pos)
          abort();
}

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
      Known to work|3.3.3                       |3.3.3 3.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2004-06-02 00:19:23
               date|                            |
            Summary|[3.4/3.5 regression] unit-  |[3.4 regression] unit-at-a-
                   |at-a-time causes            |time causes miscompilation
                   |miscompilation              |


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[belyshev at lubercy dot com]

------- Additional Comments From belyshev at lubercy dot com  2004-06-02 06:47 -------
Why gcc does not print 'warning: returning reference to temporary' in
reverse_iterator::operator* () ? 

btw, this is from bits/stl_iterator.h:148:
      reference
      operator*() const
      {
	_Iterator __tmp = current;
	return *--__tmp;
      }


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-06-02 07:38 -------
Subject: Re:  [3.4 regression] unit-at-a-time
 causes miscompilation

> Why gcc does not print 'warning: returning reference to temporary' in
> reverse_iterator::operator* () ?
>
> btw, this is from bits/stl_iterator.h:148:
>       reference
>       operator*() const
>       {
> 	_Iterator __tmp = current;
> 	return *--__tmp;
>       }

Pobably because its in a system header.  Ugh.


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[belyshev at lubercy dot com]

------- Additional Comments From belyshev at lubercy dot com  2004-06-02 08:50 -------
IntervalIterator::operator* () returns reference to member of *this (and '*this'
is temporary automatic variable; IMHO it is not what iterators supposed to do)
to std::reverse_iterator::operator* () which is used after ~IntervalIterator
called. So this bug is in POOMA and then INVALID.


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-02 10:18 -------
It does look invalid, in fact. Richard?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-06-02 10:51 -------
Subject: Re:  [3.4 regression] unit-at-a-time
 causes miscompilation

On Wed, 2 Jun 2004, giovannibajo at libero dot it wrote:

> It does look invalid, in fact. Richard?

The minimized testcase is of course invalid.  I'm currently investigating
the iterators in question in the POOMA library and at least they look
suspicious.  Btw. - why doesn't gcc warn about returning a reference to a
temporary there?

Richard.


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-02 10:57 -------
Subject: Re:  [3.4 regression] unit-at-a-time causes miscompilation

rguenth at tat dot physik dot uni-tuebingen dot de wrote:

> Btw. - why doesn't gcc warn about returning a reference
> to a temporary there?

It's not easy, because IntervalIterator::operator* returns a reference which is
valid for its scope. Then, reverse_iterator::operator* thinks that the
reference it gets is valid and returns it without a warning. EDG doesn't warn
as well on this testcases. I wonder if the tree gurus can find a way to detect
this and similar situations.

Giovanni Bajo




-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-06-02 11:07 -------
Subject: Re:  [3.4 regression] unit-at-a-time
 causes miscompilation

On Wed, 2 Jun 2004, giovannibajo at libero dot it wrote:

>
> ------- Additional Comments From giovannibajo at libero dot it  2004-06-02 10:57 -------
> Subject: Re:  [3.4 regression] unit-at-a-time causes miscompilation
>
> rguenth at tat dot physik dot uni-tuebingen dot de wrote:
>
> > Btw. - why doesn't gcc warn about returning a reference
> > to a temporary there?
>
> It's not easy, because IntervalIterator::operator* returns a reference which is
> valid for its scope. Then, reverse_iterator::operator* thinks that the
> reference it gets is valid and returns it without a warning. EDG doesn't warn
> as well on this testcases. I wonder if the tree gurus can find a way to detect
> this and similar situations.

Hmm, if all is inlined, it should be detectable.  If not it is difficult,
because

struct Foo {
int& foo()
{
  return *(new int);
}
};

int& bar()
{
  Foo f;
  return f.foo();
}

is valid.  Maybe worth a few false positives.  I.e. warn for returned
references to results of methods of local objects.

Btw., just trying to fix the PR by returning a copy in the questionable
places doesn't fix it.  There must be something else (or some more
references...).

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-02 11:14 -------
Subject: Re:  [3.4 regression] unit-at-a-time causes miscompilation

rguenth at tat dot physik dot uni-tuebingen dot de wrote:

> Hmm, if all is inlined, it should be detectable.

Not really. If *all* is correctly inline and optimized, Serge's testcase would
be reduced to "main() { return 0; }". Actually, tree-ssa is pretty close to do
that, we need to fix the C++ frontend lowering things Pinski is working on.

> Maybe worth a few false positives.  I.e. warn for returned
> references to results of methods of local objects.

I think the complete solution must happen at the tree level (not in the
frontend as it is now). Of course, such a situation is detectable only if the
definition of all involved functions are available, etc. After all, it is
undefined behaviour so it is only a QoI issue, we can try harder to help the
user.

Giovanni Bajo




-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[belyshev at lubercy dot com]

------- Additional Comments From belyshev at lubercy dot com  2004-06-02 11:15 -------
>The minimized testcase is of course invalid.  I'm currently investigating

I would not say that. Consider:

pooma/src/Domain/IntervalIterator.h:109:
  //============================================================
  // Accessors
  //============================================================

  // Dereference operator. Returns const ref to internal Loc.

  inline const Value_t &operator*() const { PAssert(!done()); return val_m; }


pooma/src/Utilites/algorithms.h:227:
#if POOMA_NONSTANDARD_ITERATOR
  std::reverse_iterator<KillIterator, const int> rk_pos(kill_end);
  std::reverse_iterator<KillIterator, const int> rk_end(kill_begin);
#else
  std::reverse_iterator<KillIterator>            rk_pos(kill_end);
  std::reverse_iterator<KillIterator>            rk_end(kill_begin);
#endif


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-06-02 11:54 -------
Subject: Re:  [3.4 regression] unit-at-a-time
 causes miscompilation

On Wed, 2 Jun 2004, belyshev at lubercy dot com wrote:

>
> ------- Additional Comments From belyshev at lubercy dot com  2004-06-02 11:15 -------
> >The minimized testcase is of course invalid.  I'm currently investigating
>
> I would not say that. Consider:

While I don't understand what you are hinting at here, looking at the
actual code doesn't reveal any obvious failure in handling invalid data,
still valgrind tells us:

==21613== Invalid read of size 4
==21613==    at 0x804E6EF: void Engine<1, int,
Dynamic>::performDestroy<IntervalIterator>(IntervalIterator const&,
IntervalIterator const&, BackFill const&, bool)
(/home/rguenth/src/pooma-bk/r2/src/Utilities/algorithms.h:233)
==21613==    by 0x804EE9E: void Engine<1, int,
Dynamic>::performDestroy<Interval<1> >(Interval<1> const&, BackFill
const&, bool)
(/home/rguenth/src/pooma-bk/r2/src/Engine/DynamicEngine.cpp:254)
==21613==    by 0x804EF44: void Engine<1, int,
Dynamic>::destroy<Interval<1> >(Interval<1> const&)
(/home/rguenth/src/pooma-bk/r2/src/Layout/DynamicEvents.h:127)
==21613==    by 0x804F11F:
Particles<MPDynamicUniform>::performDestroy(int, bool)
(/home/rguenth/src/pooma-bk/r2/src/Array/Array.h:2201)
==21613==    by 0x8049E1A: main (bctest3.cpp:143)
==21613==  Address 0xBFFFEF3C is just below %esp.  Possibly a bug in
GCC/G++
==21613==   v 2.96 or 3.0.X.  To suppress, use:
--workaround-gcc296-bugs=yes
==21613==
==21613== Invalid write of size 4
==21613==    at 0x804E77E: void Engine<1, int,
Dynamic>::performDestroy<IntervalIterator>(IntervalIterator const&,
IntervalIterator const&, BackFill const&, bool)
(/home/rguenth/src/pooma-bk/r2/src/Utilities/RefCountedBlockPtr.h:635)
==21613==    by 0x804EE9E: void Engine<1, int,
Dynamic>::performDestroy<Interval<1> >(Interval<1> const&, BackFill
const&, bool)
(/home/rguenth/src/pooma-bk/r2/src/Engine/DynamicEngine.cpp:254)
==21613==    by 0x804EF44: void Engine<1, int,
Dynamic>::destroy<Interval<1> >(Interval<1> const&)
(/home/rguenth/src/pooma-bk/r2/src/Layout/DynamicEvents.h:127)
==21613==    by 0x804F11F:
Particles<MPDynamicUniform>::performDestroy(int, bool)
(/home/rguenth/src/pooma-bk/r2/src/Array/Array.h:2201)
==21613==    by 0x8049E1A: main (bctest3.cpp:143)
==21613==  Address 0x60F177E4 is not stack'd, malloc'd or free'd
==21613==
==21613== Process terminating with default action of signal 11 (SIGSEGV):
dumping core

which is at src/Utilities/algorithms.h:233 - I remember looking at this
stuff and was not able to come to the conclusion that this part of
(arguably ugly) code is wrong.  Oh - of course POOMA_NONSTANDARD_ITERATOR
is zero.  The exact signature of the performDestroy is

void Engine<(int)1, int, Dynamic>::performDestroy<IntervalIterator>
  (IntervalIterator const&, IntervalIterator const&, BackFill const&, bool)

we have inlined the delete_backfill method here (probably the key of the
failure, marking the delete_backfill __attribute__((noinline)) "fixes"
the failure).

Maybe we are wrongly re-using some stack slots here?  Or is it possible
for (source) code to become invalid wrt references to temporaries after
inlining?

I'm confused.

Richard.


-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[rguenth at tat dot physik dot uni-tuebingen dot de]

------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de  2004-06-02 12:05 -------
Subject: Re:  [3.4 regression] unit-at-a-time
 causes miscompilation

So we have:

void Engine<(int)1, int, Dynamic>::performDestroy<IntervalIterator>
	(IntervalIterator const&, IntervalIterator const&, BackFill const&, bool)
{
  int koffset = (offsetFlag ? 0 : first_m);

  int killed =
    Pooma::Algorithms::delete_backfill(data_m.begin(), data_m.end(),
                                       killBegin, killEnd, koffset);

  Interval<1> newdom;

  if (killed < domain().size())
    newdom = Interval<1>(domain().first(), domain().last() - killed);

  domain_m = newdom;

  data_m.resize(domain().size(), typename DataBlockPtr<T>::NoInitTag());
}

and inlined, with segfault at the marked place (note I already changed
IntervalIterator::operator*() to return by value, not by reference):

template <class DataIterator, class KillIterator>
inline
typename std::iterator_traits<DataIterator>::difference_type
delete_backfill(DataIterator data_begin, DataIterator data_end,
	        const KillIterator kill_begin, const KillIterator kill_end,
		typename std::iterator_traits<DataIterator>::difference_type offset = 0)
{
  PAssert(data_end >= data_begin);
  PAssert(kill_end >= kill_begin);

  std::reverse_iterator<KillIterator>            rk_pos(kill_end);
  std::reverse_iterator<KillIterator>            rk_end(kill_begin);

  typedef std::iterator_traits<DataIterator>     DataTraits_t;
  typedef typename DataTraits_t::difference_type Diff_t;
  Diff_t last = data_end - data_begin - 1;

  while (!(rk_pos == rk_end))
    {
      if ((*rk_pos - offset) != last) break;
           ^^^^^^^

      --last;
      ++rk_pos;
    }

  DataIterator last_pos = data_begin + last;

  while (!(rk_pos == rk_end))
    {
      *(data_begin + (*rk_pos++ - offset)) = *last_pos--;
    }

  return kill_end - kill_begin;
}



-- 


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

[Bug rtl-optimization/14863] [3.4 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-02 22:30 -------
Invalid as you are passing back a temparory variable by reference so this is not a bug in gcc at all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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

[Bug rtl-optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-03 01:00 -------
No, latest testcase by Serge is valid C++ code and it does crash compiled with 
3.4 and 3.5.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|[3.4 regression] unit-at-a- |[3.4/3.5 regression] unit-
                   |time causes miscompilation  |at-a-time causes
                   |                            |miscompilation


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

[Bug rtl-optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-03 01:08 -------
How can the last one be valid c++:
	const int &operator*()
	{
		IntervalIterator tmp = current;
		return *--tmp;
	}
He is returning an const int reference for tmp.val_m.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID


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

[Bug rtl-optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-03 01:12 -------
Never mind, Giovanni Bajo  is right this is valid as operator * returns an rvalue and not a reference.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


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

[Bug rtl-optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-03 01:25 -------
Gaby, would you mind commenting on this:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=6452&action=view

I thought the code was valid because operator* returns a temporary which is 
then bound to the const reference in the return statement. EDG emits a warning 
on this though.

I found this quote in the standard: "A temporary bound to the returned value in 
a function return statement (6.6.3) persists until the function exits." which 
is cryptic to me, because the return statement does make the function exit, so 
it would make the bind totally useless.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu dot org


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

[Bug rtl-optimization/14863] [3.4/3.5 regression] unit-at-a-time causes miscompilation

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-04 20:47 -------
Ok, I just got the confirmation from Nathan that you cannot return a reference 
to a temporary. So, this bug report is invalid to the best of our knowledge. 
Richard, if you think that GCC is still buggy, you will have to come with a 
different minimization I fear.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID


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