* [Bug fortran/65751] Bogus &L in error message
2015-04-13 9:12 [Bug fortran/65751] New: Bogus &L in error message burnus at gcc dot gnu.org
2015-04-13 13:46 ` [Bug fortran/65751] " dominiq at lps dot ens.fr
@ 2015-06-04 19:14 ` tkoenig at gcc dot gnu.org
2015-06-05 9:58 ` manu at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2015-06-04 19:14 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 4+ messages in thread* [Bug fortran/65751] Bogus &L in error message
2015-04-13 9:12 [Bug fortran/65751] New: Bogus &L in error message burnus at gcc dot gnu.org
2015-04-13 13:46 ` [Bug fortran/65751] " dominiq at lps dot ens.fr
2015-06-04 19:14 ` tkoenig at gcc dot gnu.org
@ 2015-06-05 9:58 ` manu at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: manu at gcc dot gnu.org @ 2015-06-05 9:58 UTC (permalink / raw)
To: gcc-bugs
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
...
^ permalink raw reply [flat|nested] 4+ messages in thread