Bug 32177 - g++ crashes on some valid OpenMP code
Summary: g++ crashes on some valid OpenMP code
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Jakub Jelinek
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: openmp
Depends on:
Blocks:
 
Reported: 2007-06-01 10:21 UTC by Theodore.Papadopoulo
Modified: 2007-06-11 21:59 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2007-06-06 18:02:44


Attachments
The source code showing the potential bug.... (245 bytes, text/x-c++src)
2007-06-01 10:22 UTC, Theodore.Papadopoulo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Theodore.Papadopoulo 2007-06-01 10:21:37 UTC
This is with gcc version 4.3.0 20070528 (experimental) and gcc-4.1.1 (redhat FC5 version). I suspect it is also true for all intermediate versions...
The attached program when compiled with g++ and the flags -fopenmp gives the
following diagnostic and aborts compilation:

futuna-> /usr/local/gcc-4.3/bin/g++ -fopenmp BugOMP1.C
BugOMP1.C: In function ‘void f()’:
BugOMP1.C:14: internal compiler error: in lower_stmt, at gimple-low.c:282
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

There is an obvious workaround in this case: remove the A().s() call from the loop. This is related to the destructor in class A (suppress it and the problem disappears). The problem is that lower_stmt is presented with a WITH_CLEANUP_EXPR node which it is not prepared to handle. I suspect that with -fopenmp g++ does not create a valid gimple code in this case...

I tried the dubious "make lower_stmt do nothing with this code" and, of course, something else fails afterwards.
Comment 1 Theodore.Papadopoulo 2007-06-01 10:22:40 UTC
Created attachment 13644 [details]
The source code showing the potential bug....
Comment 2 Richard Biener 2007-06-01 11:28:02 UTC
We have a

 <with_cleanup_expr 0x2aadb4071380
    type <void_type 0x2aadb3ecf240 void VOID
        align 8 symtab 0 alias set -1 canonical type 0x2aadb3ecf240
        pointer_to_this <pointer_type 0x2aadb3ecf300>>
    side-effects
    arg 0 <call_expr 0x2aadb3eb0a50 type <void_type 0x2aadb3ecf240 void>
        side-effects nothrow
        fn <addr_expr 0x2aadb4071140 type <pointer_type 0x2aadb406a900>
            constant invariant arg 0 <function_decl 0x2aadb4069000 __comp_dtor >>
        arg 0 <addr_expr 0x2aadb4071100 type <pointer_type 0x2aadb4061780>
            invariant arg 0 <var_decl 0x2aadb406f160 D.2557>>
        t.ii:8>>

that we don't handle in lower_stmt ().  The complete fn looks like

{
  try
    {
      __comp_ctor  (&D.2557);
      <<< Unknown tree: with_cleanup_expr
  __comp_dtor  (&D.2557) >>>
;
      D.2559 = s (&D.2557);
      D.2565 = D.2559;
      #pragma omp for nowait
      for (i = 1; i <= D.2565; i = i + 1)
      OMP_CONTINUE
    }
  catch
    {
      <<<eh_filter ()>>>
        {
          terminate ();
        }
    }
  OMP_RETURN [nowait]
}
Comment 3 Richard Biener 2007-06-01 11:28:27 UTC
Confirmed.
Comment 4 Jakub Jelinek 2007-06-07 23:11:33 UTC
Subject: Bug 32177

Author: jakub
Date: Thu Jun  7 23:11:23 2007
New Revision: 125544

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125544
Log:
	PR c++/32177
	* semantics.c (finish_omp_for): Call fold_build_cleanup_point_expr
	on init, the non-decl cond operand and increment value.

	* g++.dg/gomp/pr32177.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/gomp/pr32177.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/semantics.c
    trunk/gcc/testsuite/ChangeLog

Comment 5 Andrew Pinski 2007-06-11 21:59:57 UTC
Fixed.