From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2565 invoked by alias); 9 May 2007 02:19:47 -0000 Received: (qmail 2485 invoked by uid 48); 9 May 2007 02:19:27 -0000 Date: Wed, 09 May 2007 02:19:00 -0000 Message-ID: <20070509021927.2484.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pinskia at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg00658.txt.bz2 ------- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-09 03:19 ------- > That's why I think we should have a generic option that disables optimizations > which are safe only in sequential programs (and -fopenmp would imply that > option). So it sounds like you don't any thing about threading programming. People have to use mutexes and such to get safe code storing/accessing in globals no matter what, even if it looks like it is thread safe or not because of the way threads act. I don't see how this is different from knowning when programs access memory in some random way. -- pinskia at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862