Bug 28139 - alias information for EH is wrong
alias information for EH is wrong
Product: gcc
Classification: Unclassified
Component: c++
: P3 normal
: 4.2.0
Assigned To: Not yet assigned to anyone
: alias, EH, patch, wrong-code
Depends on:
  Show dependency treegraph
Reported: 2006-06-22 15:46 UTC by Jorn Wolfgang Rennecke
Modified: 2007-10-04 10:11 UTC (History)
3 users (show)

See Also:
Target: sh-elf
Known to work: 4.3.0 4.2.0
Known to fail: 4.1.0
Last reconfirmed: 2006-06-22 16:34:21

test case (554 bytes, text/plain)
2006-06-22 15:52 UTC, Jorn Wolfgang Rennecke
patch (2.04 KB, patch)
2006-06-22 22:16 UTC, Jorn Wolfgang Rennecke
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2006-06-22 15:46:34 UTC
The store at the beginning of a catch block can use an alias set that is
allegedly disjoint from the one used to load that value.  When scheduling,
this can cause the load to be moved before the store.
Comment 1 Jorn Wolfgang Rennecke 2006-06-22 15:52:19 UTC
Created attachment 11730 [details]
test case

This test case should go in testsuite/g++.dg/eh .
Comment 2 Andrew Pinski 2006-06-22 16:28:14 UTC
Hmm, I just get an error on a 64bit target so the testcase is at least invalid for them:
t.c:19: error: cast from 'int*' to 'int' loses precision
Comment 3 Andrew Pinski 2006-06-22 16:34:21 UTC
Though it is obviously wrong from the front-end:
register void * D.2002;
(int * * const &) &D.2002
Comment 4 Jorn Wolfgang Rennecke 2006-06-22 16:55:25 UTC
(In reply to comment #2)
> Hmm, I just get an error on a 64bit target so the testcase is at least invalid
> for them:
> t.c:19: error: cast from 'int*' to 'int' loses precision
You can write this as:
exit ((int)(long long) &i);
I have verified that this also reproduces the problem on sh-elf.

(In reply to comment #3)
> Though it is obviously wrong from the front-end:
> register void * D.2002;
> (int * * const &) &D.2002

As far as I can tell, this code in cp/except.c:expand_start_catch_block:
  /* Otherwise the type uses a bitwise copy, and we don't have to worry
     about the value of std::uncaught_exception and therefore can do the
     copy with the return value of __cxa_end_catch instead.  */
      tree init = do_begin_catch ();
      exp = create_temporary_var (ptr_type_node);
      DECL_REGISTER (exp) = 1;
      cp_finish_decl (exp, init, /*init_const_expr=*/false,
                      NULL_TREE, LOOKUP_ONLYCONVERTING);
      initialize_handler_parm (decl, exp);

is wrong.  exp has the wrong type, hence the store emitted by cp_finish_decl
will end up with the wrong alias set.
I'm not sure yet what the right type is, though. would that be the type of decl
for pointers, and a pointer to that type for non-pointers?  Or a reference?
Comment 5 Jorn Wolfgang Rennecke 2006-06-22 22:16:36 UTC
Created attachment 11732 [details]

I'm currently testing this patch.
Comment 6 patchapp@dberlin.org 2006-06-29 21:42:28 UTC
Subject: Bug number PR 28139

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01295.html
Comment 7 Jorn Wolfgang Rennecke 2006-07-03 16:39:17 UTC
The keyword description says that the "alias" keyword is specific to missed optimizations due to aliasing issues.
If that is true, than adding this keyword here was incorrect.  If that isn't
true, then the keyword description should be corrected.
Comment 8 Mike Stump 2006-08-25 22:27:00 UTC
Date: Fri, 25 Aug 2006 16:03:00 -0400
From: Jason Merrill <jason@redhat.com>
Subject: Re: RFA: Fix PR 28139
Message-id: <44EF5774.5050601@redhat.com>

This is OK.

:REVIEWURL http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01295.html:
Comment 9 Jorn Wolfgang Rennecke 2006-08-29 14:34:48 UTC
Subject: Bug 28139

Author: amylaar
Date: Tue Aug 29 14:34:36 2006
New Revision: 116561

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116561
	PR c++/28139
	* except.c (expand_start_catch_block): Use correct types for bitwise
	PR c++/28139
	* g++.dg/eh/alias1.C: New test.


Comment 10 Jorn Wolfgang Rennecke 2006-08-29 15:02:31 UTC
Fixed on mainline; however, the problem was already present in 4.1, so we need to decide if we want the patch in the 4.1 branch.
Comment 11 Andrew Pinski 2007-10-04 10:11:15 UTC
Fixed so closing.