public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "o.mangold at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/53436] New: Volatile behaves strange with OpenMP
Date: Mon, 21 May 2012 12:44:00 -0000	[thread overview]
Message-ID: <bug-53436-4@http.gcc.gnu.org/bugzilla/> (raw)

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

             Bug #: 53436
           Summary: Volatile behaves strange with OpenMP
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: o.mangold@googlemail.com


When I compile the program below (gcc 4.7.0)

> gcc -g -O3 -std=c99 -fopenmp volatile.c

I find, that the volatile is ignored (when optimizing with -O or higher) for
the statement

  while(!x);

>From objdump I see that x is not reread for each loop

> objdump -S a.out
...
      while(!x);
      sleep(1);
      printf("b finished\n");
  4007bf:    bf 9c 08 40 00           mov    $0x40089c,%edi
  4007c4:    e9 37 fe ff ff           jmpq   400600 <puts@plt>
  4007c9:    eb fe                    jmp    4007c9 <main._omp_fn.0+0x29>
  4007cb:    0f 1f 44 00 00           nopl   0x0(%rax,%rax,1)
  volatile bool x=false;
  #pragma omp parallel num_threads(2) shared(x)
  {
    if (omp_get_thread_num()==0)
    {
      sleep(1);
  4007d0:    bf 01 00 00 00           mov    $0x1,%edi
  4007d5:    e8 66 fe ff ff           callq  400640 <sleep@plt>
...

At 4007c9 an unconditional (endless) loop is generated. I don't know if it is
valid to use volatile this way in combination with OpenMP (maybe the standard
doesn't cover it), but I guess that kind of optimization is at least a
dangerous thing to do.

--- volatile.c ---
#include <stdio.h>
#include <unistd.h>
#include <stdbool.h>
#include <omp.h>

int main()
{
  volatile bool x=false;
  #pragma omp parallel num_threads(2)
  {
    if (omp_get_thread_num()==0)
    {
      sleep(1);
      x=true;
      printf("a finished\n");
    }
    else
    {
      while(!x);
      sleep(1);
      printf("b finished\n");
    }
  }
}


             reply	other threads:[~2012-05-21 12:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 12:44 o.mangold at googlemail dot com [this message]
2012-05-21 21:07 ` [Bug tree-optimization/53436] " jakub at gcc dot gnu.org
2012-05-21 21:19 ` jakub at gcc dot gnu.org
2012-05-22  7:40 ` jakub at gcc dot gnu.org
2012-05-22  7:59 ` o.mangold at googlemail dot com
2012-05-22  9:55 ` jakub at gcc dot gnu.org
2012-05-22  9:59 ` o.mangold at googlemail dot com
2012-05-22 10:19 ` jakub at gcc dot gnu.org
2012-05-24 22:34 ` ebotcazou at gcc dot gnu.org
2012-05-24 22:37 ` pinskia at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-53436-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).