[Bug c++/61182] New: Forming pointer to qualified function type

[Bug c++/61182] New: Forming pointer to qualified function type

[pdaouadi@aldebaran-robotics.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

            Bug ID: 61182
           Summary: Forming pointer to qualified function type
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pdaouadi@aldebaran-robotics.com

Created attachment 32793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32793&action=edit
Minimal test

The attached code does not compile on gcc 4.9 but compiles on clang 3.4 and gcc
< 4.9.

Accessor decompose the type with C = "C" and T = "int () const" in the first
call of make. Then same_type creates a T* and removes the pointer to get back
to the same type. GCC 4.9 complains that we cannot create a pointer to a
qualified pointer type even though we never instanciate it.

[Bug c++/61182] Forming pointer to qualified function type

[pdaouadi@aldebaran-robotics.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

--- Comment #3 from pdaouadi@aldebaran-robotics.com ---
I am no c++ expert but my guess is that it should be allowed to have qualified
function types as long as you don't try to instantiate that type.

The problem in our code is that we use boost::remove_const (which should be a
noop in this case I believe) which uses a trick involving pointers similar to
what I wrote in the attached example and does not compile with 4.9.

Still, if the standard says that it is not allowed we can work around it, but
then should I file a bug to clang?

[Bug c++/61182] Forming pointer to qualified function type

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot com

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
I think we want first to hear from Jason, because over the years Core handled a
number of DRs in this area, eg Core/295.

[Bug c++/61182] Forming pointer to qualified function type

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
8.3.5/6 says,

A function type with a cv-qualifier-seq or a ref-qualifier ... shall appear
only as:
— the function type for a non-static member function,
— the function type to which a pointer to member refers,
— the top-level function type of a function typedef declaration or
alias-declaration,
— the type-id in the default argument of a type-parameter (14.1), or
— the type-id of a template-argument for a type-parameter (14.3.1).

Which I read as meaning no (non-member) pointers to such a type.
>From gcc-bugs-return-451563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 14 05:04:40 2014
Return-Path: <gcc-bugs-return-451563-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2534 invoked by alias); 14 May 2014 05:04:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2454 invoked by uid 48); 14 May 2014 05:04:32 -0000
From: "quantheory at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60928] gfortran issue with allocatable components and OpenMP
Date: Wed, 14 May 2014 05:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: quantheory at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60928-4-IQiRYkDsBx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60928-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60928-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01255.txt.bz2
Content-length: 1949

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`928

--- Comment #3 from Sean Santos <quantheory at gmail dot com> ---
OpenMP 4.0 is strange. Sure, it does refer to "allocatable enhancement" as an
unsupported feature, which is vague. It might refer to the TR unofficially
known as the "Allocatable Enhancements" update, or it might refer to everything
at all that changed between 95 and 2003, or it might just be meant as a
disclaimer that some allocatable changes may not be covered. But at the same
time, OpenMP 4.0 contains an update that specifically discusses in the test
case I gave.

The language in OpenMP 4.0 (page 160):


'For a list item or the subobject of a list item with the ALLOCATABLE
attribute:

- if the allocation status is "not currently allocated", the new list item or
the subobject of the new list item will have an initial allocation status of
"not currently allocated";

- if the allocation status is "currently allocated", the new list item or the
subobject of the new list item will have an initial allocation status of
"currently allocated". If the new list item or the subobject of the new list
item is an array, its bounds will be the same as those of the original list
item or the subobject of the original list item.'


In comparison, the first line of the same section in OpenMP 3.1 (page 97):

'For a list item with the ALLOCATABLE attribute:'


There are other, similar lines that are changed throughout the standard. To me,
this seems like a specific statement of how to handle allocatable components,
which is new in OpenMP 4.0, and is more explicit than the vague statement about
unsupported features at the top of the standard.

However, if you disagree and think that this is not part of the standard, I'd
like to suggest it as a reasonable enhancement anyway, since I would assert
that there is only one reasonable behavior here, and most other Fortran
compilers (notably excepting ifort) act the same way.

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com
            Summary|Forming pointer to          |[4.9/4.10 Regression]
                   |qualified function type     |Forming pointer to
                   |                            |qualified function type

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thanks. I was also going through that section (together with Core/1417
submitted by Daniel, and other issues) and indeed, not having followed this
tangle of issues of the years I was tempted to interpret it the same way. I'm
adding Daniel in CC, maybe he has a something to say. To be safe, I'm also
tentatively marking this as a regression.

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to pdaouadi from comment #3)
> Still, if the standard says that it is not allowed we can work around it,
> but then should I file a bug to clang?

And Boost. I have to wonder why their remove_const is so much more complicated
than ours:

  template<typename _Tp>
    struct remove_const
    { typedef _Tp     type; };

  template<typename _Tp>
    struct remove_const<_Tp const>
    { typedef _Tp     type; };

That doesn't need to form a pointer then remove it again, so works with
function types.

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

--- Comment #8 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Paolo Carlini from comment #6)
> I'm adding Daniel in CC, maybe he has a something to say. To be safe, I'm
> also tentatively marking this as a regression.

I agree with Jason as well for the reasons the quoted CWG issue 1417 had
clarified. This is also one reason, why the current library specification of
std::add_pointer needs to be corrected, see

http://cplusplus.github.io/LWG/lwg-active.html#2101
>From gcc-bugs-return-451591-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 14 11:07:09 2014
Return-Path: <gcc-bugs-return-451591-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23861 invoked by alias); 14 May 2014 11:07:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23809 invoked by uid 48); 14 May 2014 11:07:06 -0000
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
Date: Wed, 14 May 2014 11:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: daniel.kruegler at googlemail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61182-4-1gEQteX3Ha@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61182-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61182-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01283.txt.bz2
Content-length: 957

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

--- Comment #9 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Jonathan Wakely from comment #7)
> And Boost. I have to wonder why their remove_const is so much more
> complicated than ours:
> 
>   template<typename _Tp>
>     struct remove_const
>     { typedef _Tp     type; };
> 
>   template<typename _Tp>
>     struct remove_const<_Tp const>
>     { typedef _Tp     type; };
> 
> That doesn't need to form a pointer then remove it again, so works with
> function types.

I don' think that this specialization can - according to the language - remove
const qualifiers of function types, because there is no const-qualifier to
remove. As far as I remember the core language makes this possible when
rewriting the specialization to be one for a function type, as of core wording
resolution

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#547
>From gcc-bugs-return-451592-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 14 12:09:49 2014
Return-Path: <gcc-bugs-return-451592-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6481 invoked by alias); 14 May 2014 12:09:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6395 invoked by uid 55); 14 May 2014 12:09:39 -0000
From: "abel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60866] [4.7/4.8/4.9/4.10 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
Date: Wed, 14 May 2014 12:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: abel at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: abel at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60866-4-MGR4CmUSGv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60866-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60866-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01284.txt.bz2
Content-length: 1027

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`866

--- Comment #4 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
Author: abel
Date: Wed May 14 12:09:02 2014
New Revision: 210420

URL: http://gcc.gnu.org/viewcvs?rev!0420&root=gcc&view=rev
Log:
        PR rtl-optimization/60866
        * sel-sched-ir (sel_init_new_insn): New parameter old_seqno.
        Default it to -1.  Pass it down to init_simplejump_data.
        (init_simplejump_data): New parameter old_seqno.  Pass it down
        to get_seqno_for_a_jump.
        (get_seqno_for_a_jump): New parameter old_seqno.  Use it for
        initializing new jump seqno as a last resort.  Add comment.
        (sel_redirect_edge_and_branch): Save old seqno of the conditional
        jump and pass it down to sel_init_new_insn.
        (sel_redirect_edge_and_branch_force): Likewise.

    * gcc.dg/pr60866.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr60866.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/sel-sched-ir.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[pdaouadi@aldebaran-robotics.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

--- Comment #10 from pdaouadi@aldebaran-robotics.com ---
(In reply to Daniel Krügler from comment #9)
> I don' think that this specialization can - according to the language -
> remove const qualifiers of function types, because there is no
> const-qualifier to remove.

remove_const does not remove const from functions even in previous function of
gcc and I do not expect it to do that. I expect it to give the same type,
unchanged as it does with gcc < 4.9.
>From gcc-bugs-return-451608-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 14 13:47:45 2014
Return-Path: <gcc-bugs-return-451608-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29386 invoked by alias); 14 May 2014 13:47:44 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29318 invoked by uid 48); 14 May 2014 13:47:41 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
Date: Wed, 14 May 2014 13:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61094-4-63M9eMcQZz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61094-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61094-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01300.txt.bz2
Content-length: 272

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida094

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
Just starting to look at this, but my first thought is to validate the copy in
combine_set_extension.  We can still abort the transformation at that point.

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

--- Comment #11 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to pdaouadi from comment #3)
> Still, if the standard says that it is not allowed we can work around it,
> but then should I file a bug to clang?

I have done so,

http://llvm.org/bugs/show_bug.cgi?id=19742
>From gcc-bugs-return-451635-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 14 18:41:59 2014
Return-Path: <gcc-bugs-return-451635-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13148 invoked by alias); 14 May 2014 18:41:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13114 invoked by uid 48); 14 May 2014 18:41:55 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
Date: Wed, 14 May 2014 18:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ra, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords component
Message-ID: <bug-60969-4-VFmrVIkwCW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60969-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60969-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01327.txt.bz2
Content-length: 1278

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ra
          Component|target                      |rtl-optimization

--- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #13)
> The matching pattern for:
> 
> (insn 26 25 27 4 (set (reg:SF 147 [ D.2421 ])
>         (float:SF (reg/v:SI 154 [ z ]))) 203 {*floatsisf2_i387}
>      (expr_list:REG_DEAD (reg/v:SI 154 [ z ])
>         (nil)))
> 
> was removed by r208587. Without SSE math, MMX is used in *movsf_internal.

This has nothing to do with SSE math, but register preferences.

In i386.md, it is said for the above RTX that:

;; Even though we only accept memory inputs, the backend _really_
;; wants to be able to do this between registers.  Thankfully, LRA
;; will fix this up for us during register allocation.

LRA fixes this in a wrong way and puts the value in %mm register, see also
comment #10.

Reconfirmed on mainline as RA problem using "-O2 -ftree-vectorize
-march=pentium4 -m32" with Jakub's test from Comment #1.
>From gcc-bugs-return-451636-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 14 18:53:52 2014
Return-Path: <gcc-bugs-return-451636-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25131 invoked by alias); 14 May 2014 18:53:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25048 invoked by uid 48); 14 May 2014 18:53:49 -0000
From: "roland at rschulz dot eu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
Date: Wed, 14 May 2014 18:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: roland at rschulz dot eu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55561-4-cUy1zue6A2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55561-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55561-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01328.txt.bz2
Content-length: 347

https://gcc.gnu.org/bugzilla/show_bug.cgi?idU561

--- Comment #47 from Roland Schulz <roland at rschulz dot eu> ---
Using 4.9 and --disable-linux-futex I don't get any false positives. Thus the
problem I saw with 4.8.2 is indeed fixed with 4.9. Thanks!

What is the advantage of a TSAN instrumented libgomp over one with
--disable-linux-futex?

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.1

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> ---
So, not a GCC bug.