[Bug fortran/60110] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60110
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org ---
The problem is that there is no backend_decl for l, the argument to the power
function in the interface:
(gdb) b fancy_abort
Breakpoint 1 at 0xfedb20: file ../../trunk/gcc/diagnostic.c, line 1189.
(gdb) r
Starting program: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/f951
foo.f90
MAIN__ check
Breakpoint 1, fancy_abort (file=file@entry=0x1085770
../../trunk/gcc/fortran/trans-decl.c,
line=line@entry=1313,
function=function@entry=0x1086c20
gfc_get_symbol_decl(gfc_symbol*)::__FUNCTION__ gfc_get_symbol_decl) at
../../trunk/gcc/diagnostic.c:1189
warning: Source file is more recent than executable.
1189}
(gdb) up
#1 0x00623f16 in gfc_get_symbol_decl (sym=sym@entry=0x1920200)
at ../../trunk/gcc/fortran/trans-decl.c:1313
warning: Source file is more recent than executable.
1313 gcc_assert (sym-backend_decl);
(gdb) p sym
$1 = (gfc_symbol *) 0x1920200
(gdb) p *sym
$2 = {name = 0x76d7b008 l, module = 0x0, declared_at = {nextc =
0x191ac54, lb = 0x191abe0}, ts = {
type = BT_CHARACTER, kind = 1, u = {derived = 0x18c9b00, cl = 0x18c9b00,
pad = 25991936},
interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN,
deferred = false}, attr = {
allocatable = 0, dimension = 0, codimension = 0, external = 0, intrinsic =
0, optional = 0,
pointer = 0, target = 0, value = 0, volatile_ = 0, temporary = 0, dummy =
1, result = 0, assign = 0,
threadprivate = 0, not_always_present = 0, implied_index = 0,
subref_array_pointer = 0,
proc_pointer = 0, asynchronous = 0, contiguous = 0, fe_temp = 0,
class_pointer = 0,
save = SAVE_NONE, data = 0, is_protected = 0, use_assoc = 0, use_only = 0,
use_rename = 0,
imported = 0, host_assoc = 0, in_namelist = 0, in_common = 0,
in_equivalence = 0, function = 0,
subroutine = 0, procedure = 0, generic = 0, generic_copy = 0, implicit_type
= 0, untyped = 0,
is_bind_c = 0, extension = 0, is_class = 0, class_ok = 0, vtab = 0, vtype =
0, is_c_interop = 0,
is_iso_c = 0, sequence = 0, elemental = 0, pure = 0, recursive = 0,
unmaskable = 0, masked = 0,
contained = 0, mod_proc = 0, abstract = 0, public_used = 0, implicit_pure =
0, noreturn = 0,
entry = 0, entry_master = 0, mixed_entry_master = 0, always_explicit = 0,
artificial = 0,
referenced = 1, is_main_program = 0, access = ACCESS_UNKNOWN, intent =
INTENT_IN,
flavor = FL_VARIABLE, if_source = IFSRC_UNKNOWN, proc = PROC_UNKNOWN,
cray_pointer = 0,
cray_pointee = 0, alloc_comp = 0, pointer_comp = 0, proc_pointer_comp = 0,
private_comp = 0,
zero_comp = 0, coarray_comp = 0, lock_comp = 0, defined_assign_comp = 0,
unlimited_polymorphic = 0,
select_type_temporary = 0, associate_var = 0, omp_udr_artificial_var = 0,
omp_declare_target = 0,
ext_attr = 0, deferred_parameter = 0, volatile_ns = 0x0, asynchronous_ns =
0x0}, generic = 0x0,
component_access = ACCESS_UNKNOWN, formal = 0x0, formal_ns = 0x0, f2k_derived
= 0x0, value = 0x0,
as = 0x0, result = 0x0, components = 0x0, cp_pointer = 0x0, entry_id = 0,
hash_value = 0,
common_next = 0x0, common_head = 0x0, dummy_order = 1, namelist = 0x0,
namelist_tail = 0x0,
old_symbol = 0x0, tlink = 0x0, mark = 1, gfc_new = 0, equiv_built = 0,
forall_index = 0, resolved = 1,
refs = 1, ns = 0x191f690, backend_decl = 0x0, from_intmod = INTMOD_NONE,
intmod_sym_id = 0,
binding_label = 0x0, common_block = 0x0, assoc = 0x0}
(gdb) p sym-backend_decl
$3 = (tree) 0x0
[Bug libstdc++/62237] New: ostream single character printing is slower than fprintf with %c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62237 Bug ID: 62237 Summary: ostream single character printing is slower than fprintf with %c. Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mickey.veksler at gmail dot com Created attachment 33383 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33383action=edit ostream vs. fprintf I have tried to write a micro-benchmark to compare the performance of the ostream and FILE interfaces. It turns out that GCC's ostream is performing quite well except in one case: out ch; It takes almost 2.5 times the wall-time of the fprintf(out, %c, ch) version (Please see the attached files). This does not make sense to me. Even worse, the fprintf version takes only 60% CPU instead of the 99% of the fprintf version. In order not to make you follow my analysis, which is possibly wrong, I do not add more of my results. I would say that from my analysis it seems that it should be relatively easy to speed-up this case, significantly.
[Bug fortran/60550] [OOP] ICE on factory design pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- This works with current trunk. Confirmed. I don't get any ICE with the 4.9 releases (4.9.0, 4.9.1, and prerelease 4.9.2, r214296). I get the ICE for 4.9 r208775 (2014-03-23), but not for 4.10 r209838 (2014-04-27). This PR could have been fixed by r208879 (first patch for pr58880). Resolve as FIXED and put the test case into the testsuite? The original test should probably be reduced (I can do it).
[Bug fortran/60550] [OOP] ICE on factory design pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Reduced test (ICE with r208775)
! { dg-do compile }
MODULE m_benchmark_function
IMPLICIT NONE
INTEGER, PARAMETER :: wpr = 8
TYPE, ABSTRACT :: problem
INTEGER, PUBLIC :: problem_dimension=0, problemID=0, fevals=0
END TYPE problem
TYPE, EXTENDS(problem) :: benchmark_function
REAL(wpr), DIMENSION(:), ALLOCATABLE :: translation
CONTAINS
FINAL :: bmf_dtor
END TYPE benchmark_function
CONTAINS
SUBROUTINE bmf_dtor(self)
TYPE(benchmark_function), INTENT(INOUT) :: self
END SUBROUTINE bmf_dtor
END MODULE m_benchmark_function
MODULE m_rosenbrock
USE m_benchmark_function, ONLY : benchmark_function
IMPLICIT NONE
TYPE, EXTENDS(benchmark_function) :: rosenbrock
END TYPE rosenbrock
INTERFACE rosenbrock
MODULE PROCEDURE rosen_ctor_def
END INTERFACE rosenbrock
CONTAINS
FUNCTION rosen_ctor_def(id, dim, name) RESULT(self)
INTEGER, INTENT(IN) :: id, dim
CHARACTER(LEN=*), INTENT(IN) :: name
TYPE(rosenbrock) :: self
END FUNCTION rosen_ctor_def
END MODULE m_rosenbrock
MODULE m_problem_factory
USE m_benchmark_function, ONLY : problem, benchmark_function
USE m_rosenbrock, ONLY : frosenbrock = rosenbrock
IMPLICIT NONE
TYPE :: problem_factory
INTEGER :: problemID = 0
CHARACTER(LEN=:), ALLOCATABLE :: problemName
CLASS(problem), POINTER :: problemPtr = NULL()
CONTAINS
PROCEDURE :: create = create_problem
END TYPE problem_factory
CONTAINS
FUNCTION create_problem(self, ndim) RESULT(ptr)
CLASS(problem_factory):: self
INTEGER, INTENT(IN) :: ndim
CLASS(problem), POINTER :: ptr
ALLOCATE(self%problemPtr, SOURCE=FRosenbrock(self%problemID, ndim,
self%problemName))
END FUNCTION create_problem
END MODULE m_problem_factory
[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- ISTR that building with CFLAGS_FOR_TARGET=-g -O2 -flto -ffat-lto-objects, same for CXXFLAGS_FOR_TARGET, and --disable-bootstrap used to complete, but now it fails during the link of .libs/libstdc++.so.6.0.21: lto1: fatal error: /tmp/ccRgW0QI.ltrans5.o: section _ZTVSd.localalias.316.lto_priv.752 is missing compilation terminated. lto-wrapper: fatal error: /tmp/gcc-lto/build/./gcc/xgcc returned 1 exit status compilation terminated. /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status I don't remember ever seeing that section ... is missing error before. Exact line I used: /data/repos/gcc/trunk/configure --prefix=/tmp/gcc-lto/inst --enable-languages=c,c++ --with-system-zlib --disable-nls --enable-libstdcxx-time=yes --disable-bootstrap --disable-libgomp --disable-libitm --disable-libquadmath --disable-libatomic --disable-libssp --disable-multilib --disable-libsanitizer --disable-libvtv --disable-libcilkrts
[Bug tree-optimization/62238] New: ICE with LTO on valid code on x86_64-linux-gnu in verify_ssa (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62238
Bug ID: 62238
Summary: ICE with LTO on valid code on x86_64-linux-gnu in
verify_ssa (in 64-bit mode)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk (as
well as 4.9.x) with LTO on x86_64-linux-gnu in 64-bit mode (but not in 32-bit
mode).
It is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20140823 (experimental) [trunk revision 214394] (GCC)
$
$ gcc-trunk -O0 -c fn1.c
$ gcc-trunk -O0 -c main.c
$ gcc-trunk -O3 *.o
$ ./a.out
$
$ gcc-4.8 -flto -O0 -c fn1.c
$ gcc-4.8 -flto -O0 -c main.c
$ gcc-4.8 -flto -O3 *.o
$ ./a.out
$
$ gcc-trunk -flto -O0 -c fn1.c
$ gcc-trunk -flto -O0 -c main.c
$ gcc-trunk -flto -O3 *.o
fn1.c: In function ‘fn1’:
fn1.c:4:1: error: missing definition
fn1 (int p)
^
for SSA_NAME: _73 in statement:
_32 = (unsigned int) _73;
fn1.c:4:1: internal compiler error: verify_ssa failed
0xab6be1 verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.c:1055
0x830f4b execute_function_todo
../../gcc-trunk/gcc/passes.c:1758
0x831a23 execute_todo
../../gcc-trunk/gcc/passes.c:1808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: fatal error: gcc-trunk returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$
$ cat fn1.c
int a[4], b, c, d;
int
fn1 (int p)
{
for (; d; d++)
{
unsigned int h;
for (h = 0; h 3; h++)
{
if (a[c+c+h])
{
if (p)
break;
return 0;
}
b = 0;
}
}
return 0;
}
$ cat main.c
extern int fn1 (int);
int
main ()
{
fn1 (0);
return 0;
}
$
[Bug lto/62239] New: [5 Regression] ICE: in execute_todo, at passes.c:1795 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62239
Bug ID: 62239
Summary: [5 Regression] ICE: in execute_todo, at passes.c:1795
with LTO
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: d.g.gorbachev at gmail dot com
cat foo.c
char *foo(unsigned n)
{
char *s = __builtin_calloc(1, n);
return __builtin___strcat_chk(s, , __builtin_object_size(s, 0));
}
^D
$ gcc -O -flto -shared foo.c
foo.c: In function 'foo':
foo.c:1:7: internal compiler error: in execute_todo, at passes.c:1795
char *foo(unsigned n)
^
0x84e3f13 execute_todo
../../gcc-5/gcc/passes.c:1795
Please submit a full bug report,
[...]
[Bug lto/62239] [5 Regression] ICE: in execute_todo, at passes.c:1795 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62239 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Keywords||ice-on-valid-code, lto Known to work||4.9.2 Known to fail||5.0 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Appeared in rev. (213526, 213794].
[Bug c++/62240] New: A using-declaration within a class can publish a public base of a private base.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62240 Bug ID: 62240 Summary: A using-declaration within a class can publish a public base of a private base. Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rohan at rohanlean dot de Created attachment 33384 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33384action=edit small testcase Suppose that three classes are related by inheritance (B --- A : B inherits from A) as follows: C ---private-- B ---public-- A Then C can publish A via using B::A; I think that the correct behaviour is to reject such a program.
[Bug bootstrap/60160] Building with -flto in CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added Attachment #32115|0 |1 is obsolete|| --- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Created attachment 33385 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33385action=edit Updated patch I have no problems with static libstdc++ (--disable-shared). But there were some issues with libgcov and profiledbootstrap. Perhaps it should be compiled without LTO.
[Bug fortran/61669] Error recovery ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61669 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||steven at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |steven at gcc dot gnu.org --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org --- We need to roll back parsed DATA or DATA SPEC if we reject the statement. https://gcc.gnu.org/ml/fortran/2014-08/msg00092.html
[Bug target/62038] Out of range branch target in thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038 --- Comment #6 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Sat Aug 23 15:56:07 2014 New Revision: 214397 URL: https://gcc.gnu.org/viewcvs?rev=214397root=gccview=rev Log: PR target/62038 * config/pa/pa.c (pa_output_function_epilogue): Don't set last_address when the current function is a thunk. (pa_asm_output_mi_thunk): When we don't have named sections or they are not being used, check that thunk can reach the stub table with a short branch. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c
[Bug target/62038] Out of range branch target in thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038 --- Comment #7 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Sat Aug 23 15:57:57 2014 New Revision: 214398 URL: https://gcc.gnu.org/viewcvs?rev=214398root=gccview=rev Log: PR target/62038 * config/pa/pa.c (pa_output_function_epilogue): Don't set last_address when the current function is a thunk. (pa_asm_output_mi_thunk): When we don't have named sections or they are not being used, check that thunk can reach the stub table with a short branch. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/pa/pa.c
[Bug target/62038] Out of range branch target in thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Sat Aug 23 16:00:46 2014 New Revision: 214399 URL: https://gcc.gnu.org/viewcvs?rev=214399root=gccview=rev Log: PR target/62038 * config/pa/pa.c (pa_output_function_epilogue): Don't set last_address when the current function is a thunk. (pa_asm_output_mi_thunk): When we don't have named sections or they are not being used, check that thunk can reach the stub table with a short branch. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/pa/pa.c
[Bug target/62038] Out of range branch target in thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from John David Anglin danglin at gcc dot gnu.org --- Should be fixed.
[Bug middle-end/61858] GNAT BUG: in store_field, at expr.c:6591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61858 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) Host|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) Build|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Similar issue seen with pack20.adb on both hpux and linux: Executing on host: /home/dave/gnu/gcc/objdir/gcc/gnatclean -c -q -n pack20 (ti meout = 300) spawn /home/dave/gnu/gcc/objdir/gcc/gnatclean -c -q -n pack20 ./pack20.ali ./pack20.s FAIL: gnat.dg/pack20.adb (test for excess errors) Excess errors: +===GNAT BUG DETECTED==+ | 5.0.0 20140821 (experimental) [trunk revision 214253] (hppa-linux-gnu) GCC err or:| | in store_field, at expr.c:6570 | | Error detected around /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/pack20.adb: 6:7| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Also include sources listed below in gnatchop format || (concatenated together with no headers between files). |+==+ Please include these source files with error reportNote that list may not be accurate in some cases,so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/system.ads /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/pack20.adb /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/pack20.ads /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/pack20_pkg.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:428
[Bug ada/62019] [5 Regression] FAIL: gnat.dg/weak2.adb (test for excess errors) on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #4 from John David Anglin danglin at gcc dot gnu.org --- I see similar error on hppa-unknown-linux-gnu: /xgcc --GNATBIND=/home/dave/gnu/gcc/objdir/gcc/gnatbind --GNATLINK=/home/dave/gn u/gcc/objdir/gcc/gnatlink -cargs -B/home/dave/gnu/gcc/objdir/gcc -largs --GCC=/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc -margs --RTS=/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada -q -f /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/weak2.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -c -u -S -o weak2.sraised STORAGE_ERROR : stack overflow or erroneous memory access gnatmake: /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/weak2.adb compilation error
[Bug tree-optimization/50374] Support vectorization of min/max location pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
vincenzo Innocente vincenzo.innocente at cern dot ch changed:
What|Removed |Added
Known to fail||4.9.1
--- Comment #27 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
coming back to this old issue.
Any chance to see it implemented in the auto-vectorizer soon?
using extended vectors I manage to vectorize min_element as below.
In principle the auto-vectorizer should be able to do the same starting from
the loop in comment 3
typedef float __attribute__( ( vector_size( 16 ) ) ) float32x4_t;
typedef float __attribute__( ( vector_size( 16 ) , aligned(4) ) )
float32x4a4_t;
typedef int __attribute__( ( vector_size( 16 ) ) ) int32x4_t;
inline
float32x4_t load(float const * x) {
return *(float32x4a4_t const *)(x);
}
int minloc(float const * x, int N) {
float32x4_t v0;
int32x4_t index;
auto M = 4*(N/4);
for (int i=M; iN; ++i) {
v0[i-M] = x[i];
index[i]=i;
}
for (int i=N; iM+4;++i) {
v0[i-M] = x[0];
index[i]=0;
}
int32x4_t j = {0,1,2,3};
for (int i=0; iM; i+=4) {
decltype(auto) v = load(x+i);
index = (vv0) ? j : index;
v0 = (vv0) ? v : v0;
j+=4;
}
auto k = 0;
for (int i=1;i4; ++i) if (v0[i]v0[k]) k=i;
return index[k];
}
#includeiostream
#includealgorithm
#include x86intrin.h
unsigned int taux=0;
inline unsigned long long rdtscp() {
return __rdtscp(taux);
}
int main() {
float x[1024];
for (int i=0; i1024; ++i) x[i]= i%2 ? i : -i;
for (int i = 0; i10; ++i) {
std::random_shuffle(x,x+1024);
long long ts = -rdtscp();
int l1 = std::min_element(x+i,x+1024) - (x+i);
ts +=rdtscp();
long long tv = -rdtscp();
int l2 = minloc(x+i,1024-i);
tv +=rdtscp();
std::cout min is at l1 ' ' ts std::endl;
std::cout minloc l2 ' ' tv std::endl;
}
return 0;
}
which result in a pretty good speed up
c++ -std=c++1y -Ofast minloc.cc -march=nehalem
./a.out
./a.out
min is at 959 13780
minloc 959 2380
min is at 536 13680
minloc 536 4972
min is at 513 13648
minloc 513 1848
min is at 825 13640
minloc 825 1924
min is at 885 13628
minloc 885 1644
min is at 636 11252
minloc 636 1536
min is at 982 11240
minloc 982 1416
min is at 382 11228
minloc 382 1392
min is at 271 11216
minloc 271 1340
min is at 50 11204
minloc 50 1384
[Bug c++/62241] New: C++14 generalized lambda capture doesn't work with uniform initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241 Bug ID: 62241 Summary: C++14 generalized lambda capture doesn't work with uniform initialization syntax. Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: 0xd34df00d at gmail dot com Created attachment 33386 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33386action=edit Failing code Passing a lambda copying a value in its capture clause in a braced-init-list causes the compiler to issue `error: 'foo' was not declared in this scope`, where `foo` is the name of the copy. Important part is the error only happens if using the uniform initialization syntax. If the lambda is passed to a class ctor invoked via the standard '()' syntax, everything works fine. This is reproducible on 4.9.0 and 4.9.1 for me. I haven't had a chance to test 4.9.2 though.
[Bug c++/62241] C++14 generalized lambda capture doesn't work with uniform initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241 --- Comment #1 from Georg Rudoy 0xd34df00d at gmail dot com --- Created attachment 33387 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33387action=edit Successfully compiling code.
[Bug c++/62241] C++14 generalized lambda capture doesn't work with uniform initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Have you tried 5.x yet?
[Bug c++/62241] C++14 generalized lambda capture doesn't work with uniform initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241 --- Comment #3 from Georg Rudoy 0xd34df00d at gmail dot com --- Not yet. Should I?
[Bug c++/62241] C++14 generalized lambda capture doesn't work with uniform initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241 --- Comment #4 from Georg Rudoy 0xd34df00d at gmail dot com --- Also, while experimenting I've found that adding a non-initializing capture element to the list somewhat mitigates the issue. That is, if the capture list looks like `[smth, foo = bar]`, then everything builds fine.
[Bug c++/62223] error: there are no arguments to ‘static_asssert’ that depend on a template parameter, so a declaration of ‘static_asssert’ must be available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62223 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to tower120 from comment #6) Because there are no arguments to 'static_asssert' that depend on a template parameter means that there IS such a function, but it does not accept current parameters set (IMHO). No. A declaration must be available does not mean a declaration is available but it is not usable
[Bug c++/62229] Broken uniform initialization when using std::string ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62229 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- GCC is doing exactly what the standard requires, this is a well known feature of initializer-list constructors.
[Bug c++/62227] Templated move not elided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62227 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- A template cannot be a move constructor and so it is not legal to elide it. Removing line (1) means there is a move constructor implicitly declared, which will be used and can be elided. Removing line (2) means there is a move constructor, which will be used and elided.
[Bug c++/60433] auto-fn24.C:7:8: ICE: in dbxout_type, at dbxout.c:2371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60433 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Component|debug |c++ --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- Breakpoint 1, _ZL11dbxout_typeP9tree_nodei (type=0x7aed8b40, full=0) at ../../gcc/gcc/dbxout.c:2371 2371 gcc_unreachable (); (gdb) p debug_tree (type) template_type_parm 7aed8b40 decltype(auto) type_5 VOID align 8 symtab 30 alias set -1 canonical type 7aed8960 index 0 level 1 orig_level 1 chain type_decl 7ae45f50 decltype(auto) $5 = 10
[Bug c++/62189] Different result between 4.6 and 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62189 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Old releases had a bug in std::function, it got fixed.
[Bug c++/62172] Operand to a throw expression is moved when it should be copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62172 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- I think this is a DUP of an existing report
[Bug c++/62172] Operand to a throw expression is moved when it should be copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62172 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com --- Dup, the testcases are almost identical. *** This bug has been marked as a duplicate of bug 57533 ***
[Bug c++/57533] When throwing local variable, it's being move-constructed even if not going out of scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57533 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added CC||tsimpson at ubuntu dot com --- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com --- *** Bug 62172 has been marked as a duplicate of this bug. ***
[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- The standard allows iterators of different containers to be different, your program is not portable of it assumes they will (or will not) be the same type. I don't consider this a bug, and am not very motivated to even document it, but will accept a documentation patch.
[Bug c++/62206] Gcc doesn't optimize methods in template class, even when they don't depend on the template variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62206 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Yes
[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169 --- Comment #5 from M Welinder terra at gnome dot org --- I agree that anyone depending on map and multimap iterators to mix deserves whatever happens as a result. It would, however, be nice g++ would reject such programs outright. Currently this is accepted: std::mapint,int foo; std::multimapint,int::iterator = foo.end(); You get this kind of code when someone changes the container type and uses the compiler to point out where further fixes are needed. Is it an option to make the iterators different for the non-debug case too? Would that be an ABI change?
[Bug fortran/62242] New: ICE with character function in expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242 Bug ID: 62242 Summary: ICE with character function in expression Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com Hi, When trying to compile the following code: module gfbug implicit none save contains pure function UpperCase(string) result(upper) character(*), intent(IN) :: string character(LEN(string)) :: upper integer :: i, j upper = string do i = 1, LEN_TRIM(upper) j = IACHAR(upper(i:i)) select case (j) case (97:122) upper(i:i) = ACHAR(j - 32) case default end select enddo end function pure function isNotElementOf(scalar, array) result(status) logical :: status character(*), intent(IN) :: scalar, array(:) integer :: i status = .NOT. ANY(UpperCase(scalar) == [(UpperCase(array(i)), i = 1, SIZE(array))]) end function end module gfbug I get the following output: $ /usr/lib/gcc-snapshot/bin/gfortran -c ./gfbug.f90 ./gfbug.f90: In function 'uppercase': ./gfbug.f90:10:0: internal compiler error: in expand_expr_real_1, at expr.c:9492 upper = string ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. The UpperCase function is not really the issue, but its usage within the isNotElementOf function. Removing the PURE attribute does not affect the outcome. The ifort and sunf95 compilers handle the code just fine. Tested with both gfortran 4.9 and the 20140814 GCC snapshot: $ lsb_release -rd Description:Debian GNU/Linux testing (jessie) Release:testing $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran 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='Debian 4.9.1-4' --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 --with-arch-32=i586 --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.1 (Debian 4.9.1-4) $ /usr/lib/gcc-snapshot/bin/gfortran -v Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20140814-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-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.10-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.10-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.10-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.10.0 20140814 (experimental) [trunk revision 213954] (Debian 20140814-1)
