Created attachment 10740 [details]
fails with -fopenmp and -O2


contains two

#pragama omp parallel for 

loops

This is a GC failure:
#0  ggc_set_mark (p=0xafafafafafafafaf) at /home/pinskia/src/checkin/trunk/gcc/ggc-page.c:588
#1  0x0000000000620268 in gt_ggc_mx_basic_block_def (x_p=Variable "x_p" is not available.
) at gtype-desc.c:462
#2  0x000000000062060f in gt_ggc_mx_VEC_basic_block_gc (x_p=Variable "x_p" is not available.
) at gtype-desc.c:193
#3  0x0000000000620673 in gt_ggc_mx_control_flow_graph (x_p=Variable "x_p" is not available.
) at gtype-desc.c:624
#4  0x000000000062072f in gt_ggc_mx_function (x_p=Variable "x_p" is not available.
) at gtype-desc.c:639
#5  0x0000000000409622 in gt_ggc_mx_lang_tree_node (x_p=Variable "x_p" is not available.
) at gt-c-decl.h:315
#6  0x0000000000619df7 in gt_ggc_mx_cgraph_node (x_p=Variable "x_p" is not available.
) at gtype-desc.c:166
#7  0x0000000000619f16 in gt_ggc_m_P11cgraph_node4htab (x_p=Variable "x_p" is not available.
) at gtype-desc.c:1694

You can reproduce this with -std=c99 -fopenmp --param ggc-min-expand=0 --param ggc-min-heapsize=0

Reducing.

Reduced testcase:
__strcspn_c2 (__const char *__s, int __reject1, int __reject2)
{
  int m = 1,n = 1,s = 1;
  int DD,EE,num_s;
  int m_max = 99;
  int n_max = 00;
  for ( n = 1 ; n <= 99 ; n++ )
    for ( m = 1 ; m <= 99 ; m++ )
      for ( m = 1 ; m <= m_max ; m++)
        for ( s = 1 ; s <= num_s ; s++)
        {
          int liter ;
#pragma omp parallel for private(m,liter,s)
           for ( n = 1 ; n <= n_max ; n++) {}
        }
}

Even simpler testcase:

==============================================
void foo()
{
  int i;
  for ( i=0; i<1; i++ ) ;
  for ( i=0; i<1; i++ ) ;
  for ( i=0; i<1; i++ ) ;
  for ( i=0; i<1; i++ ) ;
  for ( i=0; i<1; i++ ) ;
#pragma omp parallel
  ;
}
==============================================

Hi Diego,

did you have a look at this one?
This makes -fopenmp almost unusable for the C++ frontend.
PR 26032 is probably a duplicate of this one.
I stumbled over the bug independently, too.

Mine.

And you can add PR 25983 on top of it :)

I can't reproduced this with trunk@110474 nor gomp@110467.  Could you please try again?

I still get a segfault for the testcase in comment #6.
This is revision 110467 on x86_64-unknown-linux-gnu.
Note, that this is with the C frontend:

gcc -fopenmp --param ggc-min-expand=0 --param ggc-min-heapsize=0 -c PR25990.c

I can still confirm it too.

(In reply to comment #11)
> I still get a segfault for the testcase in comment #6.
> This is revision 110467 on x86_64-unknown-linux-gnu.
>
Ah, yes.  I had failed to notice the failure is on x86_64.  Sorry about that.

Subject: Bug 25990

Author: dnovillo
Date: Thu Feb  2 12:27:02 2006
New Revision: 110511

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110511
Log:

	PR 25990
	* tree-cfg.c (move_block_to_fn): Clear out the basic block
	array after growing it.

testsuite/

	PR 25990
	* gcc.dg/gomp/pr25990.c: New test.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-cfg.c

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00121.html