[Bug fortran/65751] New: Bogus &L in error message

[Bug fortran/65751] New: Bogus &L in error message

[burnus at gcc dot gnu.org]

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

            Bug ID: 65751
           Summary: Bogus &L in error message
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org

Wrong since r194622.

I am not sure whether it should be backported or not; backporting kind of
breaks the translation work - but otherwise, it is trivial.

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index ab6f7a5..58e4cab 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3632,7 +3632,7 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue)
               || (lvalue->ts.type == BT_DERIVED
                   && (lvalue->ts.u.derived->attr.is_bind_c
                       || lvalue->ts.u.derived->attr.sequence))))
-       gfc_error ("Data-pointer-object &L must be unlimited "
+       gfc_error ("Data-pointer-object must be unlimited "
                   "polymorphic, a sequence derived type or of a "
                   "type with the BIND attribute assignment at %L "
                   "to be compatible with an unlimited polymorphic "

[Bug fortran/65751] Bogus &L in error message

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-13
                 CC|                            |pault at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Shouldn't it be rather

@@ -3632,9 +3632,9 @@ gfc_check_pointer_assign (gfc_expr *lval
            || (lvalue->ts.type == BT_DERIVED
            && (lvalue->ts.u.derived->attr.is_bind_c
                || lvalue->ts.u.derived->attr.sequence))))
-    gfc_error ("Data-pointer-object &L must be unlimited "
+    gfc_error ("Data-pointer-object at %L must be unlimited "
            "polymorphic, a sequence derived type or of a "
-           "type with the BIND attribute assignment at %L "
+           "type with the BIND attribute assignment "
            "to be compatible with an unlimited polymorphic "
            "target", &lvalue->where);
       else

?

[Bug fortran/65751] Bogus &L in error message

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #1)
> Shouldn't it be rather
> 
> @@ -3632,9 +3632,9 @@ gfc_check_pointer_assign (gfc_expr *lval
>  	       || (lvalue->ts.type == BT_DERIVED
>  		   && (lvalue->ts.u.derived->attr.is_bind_c
>  		       || lvalue->ts.u.derived->attr.sequence))))
> -	gfc_error ("Data-pointer-object &L must be unlimited "
> +	gfc_error ("Data-pointer-object at %L must be unlimited "
>  		   "polymorphic, a sequence derived type or of a "
> -		   "type with the BIND attribute assignment at %L "
> +		   "type with the BIND attribute assignment "
>  		   "to be compatible with an unlimited polymorphic "
>  		   "target", &lvalue->where);
>        else
> 
> ?

Yes, I think so too.

Dominique, this patch is obvious; if you care to commit this, please go ahead.

And I think an English error message that points out the place of the error is
more useful than a native-language one which doesn't, so I would favor 
backporting.
>From gcc-bugs-return-488121-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 04 20:42:22 2015
Return-Path: <gcc-bugs-return-488121-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 112732 invoked by alias); 4 Jun 2015 20:42:21 -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 112704 invoked by uid 48); 4 Jun 2015 20:42:18 -0000
From: "svalorzen at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66421] New: G++ fails compilation when assigning tuple created with variadic template to auto variable
Date: Thu, 04 Jun 2015 20:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: svalorzen at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created
Message-ID: <bug-66421-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: 2015-06/txt/msg00453.txt.bz2
Content-length: 3861

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

            Bug ID: 66421
           Summary: G++ fails compilation when assigning tuple created
                    with variadic template to auto variable
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: svalorzen at gmail dot com
  Target Milestone: ---

Created attachment 35697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35697&action=edit
File generated with -save-temps

The following code contains two equivalent functions, one declaring a variable
with auto and the other specifying the variable type explicitly. The function
using auto fails to compile, although the two functions provided are
equivalent. clang++ successfully compiles the code:

    #include <tuple>

    template <size_t N, typename T, typename... Args>
    struct DimTupleImpl {
        using type = typename DimTupleImpl<N-1, T, Args..., T>::type;
    };

    template <typename T, typename... Args>
    struct DimTupleImpl<0, T, Args...> {
        using type = std::tuple<Args...>;
    };

    // Tuple with N elements all of type T
    template <size_t N, typename T>
    struct DimTuple {
        using type = typename DimTupleImpl<N, T>::type;
    };

    template <typename... Params>
    void foo(Params... params) {
        auto tuple = std::make_tuple((size_t)params...);
    }

    template <typename... Params>
    void bar(Params... params) {
        typename DimTuple<sizeof...(Params), size_t>::type tuple =
std::make_tuple((size_t)params...);
    }

    int main() {
        foo(1,2,3); // Fails, clang++ compiles it
        bar(1,2,3); // Compiles correctly
        return 0;
    }

# Compiled as: 

g++ -std=c++11 main.cpp

# Compiler output:

main.cpp: In instantiation of ‘void foo(Params ...) [with Params = {int, int,
int}]’:
main.cpp:30:14:   required from here
main.cpp:21:51: error: conversion from ‘std::tuple<long unsigned int, long
unsigned int, long unsigned int>’ to non-scalar type ‘std::tuple<long unsigned
int>’ requested
     auto tuple = std::make_tuple((size_t)params...);
                                                   ^
# System:

Lubuntu 15.04

# Compiler info:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-10ubuntu13' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)
>From gcc-bugs-return-488122-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 04 20:57:49 2015
Return-Path: <gcc-bugs-return-488122-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14549 invoked by alias); 4 Jun 2015 20:57:49 -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 14514 invoked by uid 48); 4 Jun 2015 20:57:45 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66418] Optimize set_intersection when one list is much smaller and the other has random access
Date: Thu, 04 Jun 2015 20:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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-66418-4-hmHRGX40Gm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66418-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66418-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: 2015-06/txt/msg00454.txt.bz2
Content-length: 365

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Two relevant links to optimize set_intersection (they consider the intersection
of k sets, but the case k=2 is still interesting)

http://erikdemaine.org/papers/SODA2000/
http://erikdemaine.org/papers/ALENEX2001/

(I am sure there are many others)

[Bug fortran/65751] Bogus &L in error message

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #2)
> And I think an English error message that points out the place of the error
> is
> more useful than a native-language one which doesn't, so I would favor 
> backporting.

When backporting to GCC 5, this is probably gfc_error_1, however, it you remove
one of the %L, then you can use gfc_error (and get the colors).
>From gcc-bugs-return-488148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 05 10:17:30 2015
Return-Path: <gcc-bugs-return-488148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 70858 invoked by alias); 5 Jun 2015 10:17:29 -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 70798 invoked by uid 48); 5 Jun 2015 10:17:26 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgomp/66429] New: ICE in expand_GOMP_SIMD_LAST_LANE
Date: Fri, 05 Jun 2015 10:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgomp
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-66429-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: 2015-06/txt/msg00480.txt.bz2
Content-length: 2738

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

            Bug ID: 66429
           Summary: ICE in expand_GOMP_SIMD_LAST_LANE
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Consider testcase libgomp/testsuite/libgomp.c/for-2.c. It starts with:
...
/* { dg-options "-std=gnu99 -fopenmp" } */
...


I.

When running the testcase, we see in the compilation line:
...
 -fopenmp -std=gnu99 -fopenmp
...

The -fopenmp in dg-options is superfluous, because -fopenmp is forced in c.exp:
...
# Turn on OpenMP.
lappend ALWAYS_CFLAGS "additional_flags=-fopenmp"
...

Removing the -fopenmp from dg-options gives us:
...
-fopenmp  -std=gnu99
...


II.

The std=gnu99 is to support loop initial declarations, such as this one from
for-2.h:
...
  for (unsigned int i = __INT_MAX__; i < 3000U + __INT_MAX__; i += 2)
...

But the default C mode has changed from gnu89 to gnu11, so that setting is no
longer needed. Using empty dg-options, the test still passes:
...
PASS: libgomp.c/for-2.c (test for excess errors)
PASS: libgomp.c/for-2.c execution test
...


III.

Removing the empty dg-options, brings the change that it's compiled with
default option -O2, and we get an internal compiler error:
...
FAIL: libgomp.c/for-2.c (internal compiler error)
FAIL: libgomp.c/for-2.c (test for excess errors)
UNRESOLVED: libgomp.c/for-2.c compilation failed to produce executable
...

In more detail
...
In file included from src/libgomp/testsuite/libgomp.c/for-1.h:8:0,^M
                 from src/libgomp/testsuite/libgomp.c/for-2.c:18:^M
src/libgomp/testsuite/libgomp.c/for-2.h: In function
'f12_pf_simd_static32._omp_fn.27':^M
src/libgomp/testsuite/libgomp.c/for-2.h:153:9: internal compiler error: in
expand_GOMP_SIMD_LAST_LANE, at internal-fn.c:190^M
0xbb4308 expand_GOMP_SIMD_LAST_LANE^M
        src/gcc/internal-fn.c:190^M
0xbbaeec expand_internal_call(gcall*)^M
        src/gcc/internal-fn.c:1996^M
0x864305 expand_call_stmt^M
        src/gcc/cfgexpand.c:2322^M
0x868656 expand_gimple_stmt_1^M
        src/gcc/cfgexpand.c:3266^M
0x868d98 expand_gimple_stmt^M
        src/gcc/cfgexpand.c:3420^M
0x872002 expand_gimple_basic_block^M
        src/gcc/cfgexpand.c:5432^M
0x873d1b execute^M
        src/gcc/cfgexpand.c:6051^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See <http://gcc.gnu.org/bugs.html> for instructions.^M
...