[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- I am not the one who decides, but the conclusion of the previous discussion was that users of _wur (which are the API maintainers adding it) do want to get a warning even with (void) and GCC's testsuite explicitly tests for it. It is fairly easy to use -Wno-unused-result or "#pragma GCC diagnostics" if you want more fine-tuning. The location info in GCC has improved to the point that it is possible to ignore individual warnings using #pragmas. That seems far clearer to a reader and makes obvious which warning is ignored on purpose. Of course, we are happy to get as much help as we can, but I would not want you to waste your time on something that is likely not going to get approved.
[Bug tree-optimization/66423] [6 Regression] a % (1 << b) no longer gets folded to a & (1 << b) for unsigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66423 --- Comment #2 from Andreas Schwab --- ITYM a & ((1 << b) - 1)
[Bug c++/66426] New: ICE: unexpected expression ‘int(Constructible())...’ of kind expr_pack_expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66426
Bug ID: 66426
Summary: ICE: unexpected expression ‘int(Constructible())...’
of kind expr_pack_expansion
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamrial at gmail dot com
Target Milestone: ---
[jamrial@archVM ~]$ cat zip.c
template struct A;
template struct enable_if;
template struct B;
template using and_c = A>;
template using Constructible = int;
template struct common_tuple {
template <
typename... Us,
typename enable_if()...>::value>::type>
};
[jamrial@archVM ~]$ g++-trunk -O2 -std=c++11 -c zip2.c
zip2.c:10:1: error: expected unqualified-id before ‘}’ token
};
^
[jamrial@archVM ~]$ g++-5.1 -O2 -std=c++11 -c zip2.c
zip2.c:10:1: error: expected unqualified-id before ‘}’ token
};
^
[jamrial@archVM ~]$ g++-4.9 -O2 -std=c++11 -c zip.c
zip.c:9:63: internal compiler error: unexpected expression
‘int(Constructible())...’ of kind expr_pack_expansion
typename enable_if()...>::value>::type>
^
0x61cbd6 cxx_eval_constant_expression
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9833
0x61e5b6 cxx_eval_outermost_constant_expr
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9853
0x585cb0 convert_nontype_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:5698
0x585cb0 convert_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6590
0x582252 coerce_template_parameter_pack
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6713
0x582252 coerce_template_parms
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6922
0x586c70 lookup_template_class_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7594
0x586c70 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7895
0x6149b2 finish_template_type(tree_node*, tree_node*, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:2969
0x5d63fa cp_parser_template_id
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13464
0x5d6613 cp_parser_class_name
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:19195
0x5cc673 cp_parser_qualifying_entity
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5538
0x5cc673 cp_parser_nested_name_specifier_opt
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5263
0x5e0ee2 cp_parser_simple_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14666
0x5c3ebd cp_parser_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14412
0x5c65cb cp_parser_type_specifier_seq
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18137
0x5d4ee2 cp_parser_type_id_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18010
0x5d4fde cp_parser_template_type_arg
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18059
0x5d51d8 cp_parser_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13840
0x5d51d8 cp_parser_template_argument_list
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13750
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Testcase based on the one from Comment 2 of pr66405.
[Bug c++/65719] Link error with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719 Christian Kandeler changed: What|Removed |Added CC||christian.kandeler@theqtcom ||pany.com --- Comment #5 from Christian Kandeler --- Created attachment 35700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35700&action=edit test case I have attached a different test case for what is likely the same bug. Note that the code builds fine if f is changed to take T by value instead of const ref.
[Bug c++/66427] New: The compiler rejects too complex variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66427
Bug ID: 66427
Summary: The compiler rejects too complex variable templates
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: morwenn29 at hotmail dot fr
Target Milestone: ---
I was trying to replace structures with a single value member by variable
templates but it seems that their support still isn't complete enough to
support my use case. I couldn't find a reasonable "minimal" example, so here is
the code that triggered the error:
#include
struct plus {};
struct multiplies {};
// ...
template
constexpr T identity_element;
template<>
constexpr int identity_element = 0;
template
constexpr std::complex identity_element, plus> = {
identity_element,
identity_element
};
And here are the generated error messages:
main.cpp:15:23: error: expected primary-expression before ',' token
identity_element,
^
main.cpp:15:29: error: expected primary-expression before '>' token
identity_element,
^
main.cpp:15:30: error: expected primary-expression before ',' token
identity_element,
^
main.cpp:16:23: error: expected primary-expression before ',' token
identity_element
^
main.cpp:16:29: error: expected primary-expression before '>' token
identity_element
^
main.cpp:17:1: error: expected primary-expression before '}' token
};
^
[Bug target/66428] New: [6 regression] FAIL: g++.dg/abi/aarch64_guard1.C -std=gnu++98 scan-tree-dump original "_ZGVZ3foovE1x & 1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66428 Bug ID: 66428 Summary: [6 regression] FAIL: g++.dg/abi/aarch64_guard1.C -std=gnu++98 scan-tree-dump original "_ZGVZ3foovE1x & 1" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: ramana at gcc dot gnu.org Target Milestone: --- Target: aarch64-*-* $ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/abi/aarch64_guard1.C -O -fdump-tree-original -S -o aarch64_guard1.s $ grep _ZGVZ3foovE1x aarch64_guard1.C.003t.original if (<>) if (<>) TARGET_EXPR ;, x = bar ();;, D.3169 = 1;;, __cxa_guard_release (&_ZGVZ3foovE1x); >; 0925e39e497b5f218c4979b49afbdabcd3828e88 is the first bad commit commit 0925e39e497b5f218c4979b49afbdabcd3828e88 Author: ramana Date: Thu Jun 4 09:19:51 2015 + git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@224118 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/66428] [6 regression] FAIL: g++.dg/abi/aarch64_guard1.C -std=gnu++98 scan-tree-dump original "_ZGVZ3foovE1x & 1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66428 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/65751] Bogus &L in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65751 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- (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).
[Bug libgomp/66429] New: ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429
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 for instructions.^M
...
[Bug libgomp/66429] ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429
--- Comment #1 from vries at gcc dot gnu.org ---
ICE still reproduces with command line:
...
$ gcc for-2.c -fopenmp -O2 -S
..
and pruned for-2.c:
...
float b[10][15][10];
__attribute__((noreturn)) void
noreturn (void)
{
for (;;);
}
__attribute__((noinline, noclone)) void
f12_pf_simd_static32 (int n)
{
int i;
#pragma omp parallel for simd schedule(static, 32) collapse(3)
for (i = 0; i < 10; i++)
for (int j = n; j < 8; j++)
for (long k = -10; k < 10; k++)
{
b[i][j][k] += 16;
noreturn ();
b[i][j][k] -= 32;
}
}
...
[Bug ipa/66430] New: IPA CP alignment information is not used for expression simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66430
Bug ID: 66430
Summary: IPA CP alignment information is not used for
expression simplification
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: miyuki at gcc dot gnu.org
Target Milestone: ---
Consider the following example:
static int __attribute__((noinline)) foo(char *p)
{
return (unsigned long)p % 8;
}
int bar()
{
char *data = __builtin_malloc(64);
return foo(data + 5) + ((unsigned long)(data + 5) % 8);
}
When this code is compiled at -O3, alignment of "data" is propagated to foo:
$ cat align_test.c.060i.cp
[...snip...]
IPA lattices after all propagation:
Lattices:
Node: bar/1:
Node: foo/0:
param [0]: VARIABLE
ctxs: VARIABLE
Alignment 8, misalignment 5
AGGS VARIABLE
[...snip...]
Modification phase of node foo/0
Adjusting alignment of param 0 to 8, misalignment to 5
[...snip...]
But it is not used:
$ cat align_test.c.191t.optimized
;; Function foo (foo, funcdef_no=0, decl_uid=1831, cgraph_uid=0,
symbol_order=0)
foo (char * p)
{
long int p.0_2;
int _3;
int _4;
:
p.0_2 = (long int) p_1(D);
_3 = (int) p.0_2;
_4 = _3 & 7;
return _4;
}
;; Function bar (bar, funcdef_no=1, decl_uid=1833, cgraph_uid=1,
symbol_order=1)
bar ()
{
char * data;
char * _4;
int _5;
unsigned int _6;
unsigned int _7;
int _8;
:
data_3 = __builtin_malloc (64);
_4 = data_3 + 5;
_5 = foo (_4);
_6 = (unsigned int) _5;
_7 = _6 + 5;
_8 = (int) _7;
return _8;
}
Notice, that in function bar the same expression is folded into constant.
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 Dr. Uwe Meyer-Gruhl changed: What|Removed |Added CC||gcc_email at congenio dot de --- Comment #6 from Dr. Uwe Meyer-Gruhl --- Just a feedback for another target platform (arm-none-eabi): I also had problems with a kernel 4.0.4 on an iConnect (Kirkwood variant) when I used gcc 5.1.0. Using KCFLAGS='-fno-ipa-sra' helped immediately. I did not look into the generated code, though, but I assume this is the same problem.
[Bug c++/66427] The compiler rejects too complex variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66427 Jonathan Wakely changed: What|Removed |Added Known to work||6.0 --- Comment #1 from Jonathan Wakely --- Works OK on trunk.
[Bug c++/66421] G++ fails compilation when assigning tuple created with variadic template to auto variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66421 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-05 Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.2, 5.1.0, 6.0
[Bug c++/66421] G++ fails compilation when assigning tuple created with variadic template to auto variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66421
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Version|unknown |4.9.2
--- Comment #1 from Jonathan Wakely ---
Reduced:
template struct tuple { };
template tuple make_tuple(T&&...) { return {}; }
template
void foo(Params... params) {
auto t = make_tuple((int)params...);
}
template
void bar(Params... params) {
tuple t = make_tuple((int)params...);
}
int main() {
foo(1,2,3); // Fails, clang++ compiles it
bar(1,2,3); // Compiles correctly
}
t.cc: In instantiation of ‘void foo(Params ...) [with Params = {int, int,
int}]’:
t.cc:16:14: required from here
t.cc:7:39: error: conversion from ‘tuple’ to non-scalar type
‘tuple’ requested
auto t = make_tuple((int)params...);
^
[Bug go/66431] New: [go] Unexpected function return value after it is redefined in closure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66431
Bug ID: 66431
Summary: [go] Unexpected function return value after it is
redefined in closure
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: lomov.as at gmail dot com
CC: cmang at google dot com
Target Milestone: ---
I'm not sure about where is bug: in gccgo or in go. I couldn't find this case
in go specs and I decided to write here.
This code has different behaviour in golang (tested on 1.3.1-1.4.2) and gccgo
(5.1.0):
```
package main
import "fmt"
func testFunction() (value int, err error) {
value = 1
fmt.Println("In the beginning value is : ", value)
closure := func() (error) {
value = 2
fmt.Println("value is changed in closure : ", value)
return nil
}
return value, closure()
}
func main() {
result, err := testFunction()
fmt.Println("final result is : ", result)
fmt.Println("err is : ", err)
}
```
Go lang 1.4.2 returns following result:
```
In the beginning value is : 1
value is changed in closure : 2
final result is : 2
err is :
```
And GCC Go prints following:
```
In the beginning value is : 1
value is changed in closure : 2
final result is : 1
err is :
```
The thing is that in GCC Go a value is returned unchanged by closure.
I use following flags to configure gcc 5.1.0 go before build:
```
../src/configure --enable-threads=posix --enable-shared --enable-__cxa_atexit \
--enable-languages=c,c++,go --enable-secureplt --enable-checking=yes
--with-long-double-128 \
--enable-decimal-float --disable-bootstrap --disable-alsa
--disable-multilib \
--prefix=/usr/local/gccgo
```
I run Linux on power architecture:
```
uname -a
Linux jumpbox 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:15:29 UTC 2015
ppc64le ppc64le ppc64le GNU/Linux
```
[Bug go/66431] [go] Unexpected function return value after it is redefined in closure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66431 --- Comment #1 from Alexander Lomov --- Here is more details about this bug: https://code.google.com/p/go/issues/detail?id=8698&thanks=8698&ts=1410376474
[Bug c++/66350] typename should be forbidden in inhering constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66350 --- Comment #5 from Jonathan Wakely --- Also, "using typename Base::name;" would usually re-declare a type name in the derived class' scope, but that's not what's happening here. It's introducing inheriting constructors, not a type. 7.3.3 [namespace.udecl]/19 says: If a using-declaration uses the keyword typename and specifies a dependent name (14.6.2), the name introduced by the using-declaration is treated as a typedef-name (7.1.3). and we definitely don't want it to be treated as a typedef-name, so "typename" must not be used for an inheriting constructor.
[Bug libgomp/66432] New: libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66432 Bug ID: 66432 Summary: libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol Product: gcc Version: unknown 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: --- Run src/libgomp/testsuite/libgomp.c/appendix-a/a.29.1.c with '--target_board unix/-O2/-g': ... FAIL: libgomp.c/appendix-a/a.29.1.c (test for excess errors) Excess errors: src/libgomp/testsuite/libgomp.c/appendix-a/a.29.1.c:6:1: error: type mismatch between an SSA_NAME and its symbol UNRESOLVED: libgomp.c/appendix-a/a.29.1.c compilation failed to produce executable ... Without -g, the testcase passes.
[Bug go/66431] [go] Unexpected function return value after it is redefined in closure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66431 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Ian Lance Taylor --- This is not a bug in either toolchain. The Go language does not fully specify the order of evaluation. In the line return value, closure() it is not specified whether value is read before after closure is called. The two toolchains are making different choices. Both are correct. The program is indeterminate. This is already explained at the code.google.com link that you attached.
[Bug go/66431] [go] Unexpected function return value after it is redefined in closure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66431 --- Comment #3 from Andrew Pinski --- I should note c and c++ also specify the order. Java does though.
[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595 --- Comment #10 from Nathan Sidwell --- Author: nathan Date: Fri Jun 5 13:35:30 2015 New Revision: 224152 URL: https://gcc.gnu.org/viewcvs?rev=224152&root=gcc&view=rev Log: cp/ PR c++/52595 * parser.c (cp_parser_cache_defarg): Continue looking for declarators when scanning a potential template argument list of an NSDMI. testsuite/ PR c++/52595 * g++,dg/cpp0x/nsdmi-defer5.C: Add template case. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer5.C
[Bug go/66431] [go] Unexpected function return value after it is redefined in closure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66431 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > I should note c and c++ also specify the order. Java does though. I mean C and C++ does not specify the order while Java does.
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 52595, which changed state. Bug 52595 Summary: [DR 325] commas and non-static data member initializers don't mix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nathan Sidwell --- patch committed https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02582.html
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #7 from Sebastiano Vigna --- I tried also with -fsanitize=address. No problems reported. Bug not showing up. A classical heisenbug.
[Bug target/66433] New: Arm NEON postincrement optimization missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66433
Bug ID: 66433
Summary: Arm NEON postincrement optimization missed
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: y.usishchev at samsung dot com
Target Milestone: ---
Created attachment 35701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35701&action=edit
test with vld and vst
GCC from trunk, configured with --target=armv7l-tizen-linux-gnueabi with
options "-O2 -mfpu=neon" on attached testcase does not generate autoincrement
for vld/vst instructions.
auto-inc-dec pass ignores possibilities of optimization vld/vst instructions:
for code
for () { //some loop
s0_32x4 = vld1q_u32(s);
s1_32x4 = vld1q_u32(s+4);
s+=8;
...
}
gcc generates
vld1.32 {d6-d7}, [r1]
add.w r4, r1, #16
addsr1, #32
vld1.32 {d28-d29}, [r4]
instead of
vld1.32 {d6-d7}, [r1]!
vld1.32 {d28-d29}, [r1]!
This is caused by presumably wrong cost estimation:
vld1.32 instruction without increment costs 4, but with increment its cost is
16 (gcc/config/arm/arm.c:9415):
case MEM:
if (REG_P (XEXP (x, 0)))
*cost = COSTS_N_INSNS (1);
...
else
*cost = COSTS_N_INSNS (ARM_NUM_REGS (mode));
[Bug target/66433] Arm NEON postincrement optimization missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66433 --- Comment #1 from Usishchev Yury --- Created attachment 35702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35702&action=edit patch with fix Attached patch that, in my opinion, fixes the issue
[Bug target/66433] Arm NEON postincrement optimization missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66433 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||arm* Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-05 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed. With your patch, does the codegen actually use the postincrement forms? Please post the patch to gcc-patc...@gcc.gnu.org for review.
[Bug c/66348] Simple loop has only lower half of the 64-bit counter initialized correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #8 from Uroš Bizjak --- (In reply to Sebastiano Vigna from comment #0) > The loop commented as "problematic loop" is compiled (with -O3) as > > xorl%eax, %eax # i > > That is, the loop index i is in %rax, but only the lower half is zeroed at > the start of the loop. When we enter the loop with a large (>32-bit) value, > the loop never ends. This happens already with -O1. We had to #pragma the > function to -O0 to make it work. If you are referring to the xorl insn above, then rest assured that it zeroes the whole 64bit register. Your bug is elsewhere.
[Bug libstdc++/63860] Ill-formed std::pair::swap implementation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|5.2 |6.0 --- Comment #8 from Jonathan Wakely --- Should be fixed on trunk by r224153 I don't see any point fixing it for 5.2 since G++ and Clang already accept the ill-formed code, and aren't going to suddenly stop doing so.
[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443 --- Comment #18 from vries at gcc dot gnu.org --- Author: vries Date: Fri Jun 5 15:57:34 2015 New Revision: 224154 URL: https://gcc.gnu.org/viewcvs?rev=224154&root=gcc&view=rev Log: Add transform_to_exit_first_loop_alt 2015-06-05 Tom de Vries merge from gomp4 branch: 2015-05-28 Tom de Vries PR tree-optimization/65443 * tree-parloops.c (replace_imm_uses, replace_uses_in_bb_by) (replace_uses_in_bbs_by, transform_to_exit_first_loop_alt) (try_transform_to_exit_first_loop_alt): New function. (transform_to_exit_first_loop): Use try_transform_to_exit_first_loop_alt. * gcc.dg/parloops-exit-first-loop-alt-2.c: New test. * gcc.dg/parloops-exit-first-loop-alt-3.c: New test. * gcc.dg/parloops-exit-first-loop-alt.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt-2.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt.c: New test. Added: trunk/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-2.c trunk/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-3.c trunk/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt.c trunk/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-2.c trunk/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c trunk/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c trunk/libgomp/ChangeLog
[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from vries at gcc dot gnu.org --- Patch with test-cases committed to trunk, marking resolved-fixed.
[Bug libstdc++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #15 from Jason Merrill --- Author: jason Date: Fri Jun 5 16:25:26 2015 New Revision: 224157 URL: https://gcc.gnu.org/viewcvs?rev=224157&root=gcc&view=rev Log: PR c++/65942 * decl2.c (mark_used): Don't always instantiate constexpr fns. * constexpr.c (cxx_eval_call_expression): Instantiate them here. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-decltype2.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c branches/gcc-5-branch/gcc/cp/decl2.c
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jason at gcc dot gnu.org Component|libstdc++ |c++ Resolution|--- |FIXED Assignee|redi at gcc dot gnu.org|jason at gcc dot gnu.org Target Milestone|--- |5.2 --- Comment #16 from Jason Merrill --- Fixed for 5.2.
[Bug fortran/40958] module files too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #19 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 16:54:53 2015 New Revision: 224159 URL: https://gcc.gnu.org/viewcvs?rev=224159&root=gcc&view=rev Log: 2015-06-03 Russell Whitesides Steven G. Kargl PR fortran/40958 PR fortran/60780 PR fortran/66377 * module.c (load_equiv): Add check for loading duplicate EQUIVALENCEs from different modules. Eliminate the pruning of unused equivalence-objects 2015-06-03 Steven G. Kargl PR fortran/66377 gfortran.dg/equiv_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/equiv_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 --- Comment #10 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 16:54:53 2015 New Revision: 224159 URL: https://gcc.gnu.org/viewcvs?rev=224159&root=gcc&view=rev Log: 2015-06-03 Russell Whitesides Steven G. Kargl PR fortran/40958 PR fortran/60780 PR fortran/66377 * module.c (load_equiv): Add check for loading duplicate EQUIVALENCEs from different modules. Eliminate the pruning of unused equivalence-objects 2015-06-03 Steven G. Kargl PR fortran/66377 gfortran.dg/equiv_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/equiv_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #9 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 16:54:53 2015 New Revision: 224159 URL: https://gcc.gnu.org/viewcvs?rev=224159&root=gcc&view=rev Log: 2015-06-03 Russell Whitesides Steven G. Kargl PR fortran/40958 PR fortran/60780 PR fortran/66377 * module.c (load_equiv): Add check for loading duplicate EQUIVALENCEs from different modules. Eliminate the pruning of unused equivalence-objects 2015-06-03 Steven G. Kargl PR fortran/66377 gfortran.dg/equiv_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/equiv_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 Jouni Roivas changed: What|Removed |Added Attachment #35668|0 |1 is obsolete|| --- Comment #9 from Jouni Roivas --- Created attachment 35703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35703&action=edit Patch to fix further problems With this patch I was able to cross compile boost library properly.
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-05 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Walter Brisken from comment #0) > > gfortran -save-temps -finit-local-zero -fno-automatic -fno-underscoring -C > -w -g -O2 -c -o crash.o crash3.f > The problem is related to the -finit-local-zero option. The obvious workaround is to not use that option. I'll also recommend not using the -fno-underscoring option as the documentation warns about its use.
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #1) > (In reply to Walter Brisken from comment #0) > > > > gfortran -save-temps -finit-local-zero -fno-automatic -fno-underscoring -C > > -w -g -O2 -c -o crash.o crash3.f > > > > The problem is related to the -finit-local-zero option. > The obvious workaround is to not use that option. I'll > also recommend not using the -fno-underscoring option > as the documentation warns about its use. Dang misread my terminal output. -fno-automatic is the guilty option. Drop that option and things compile.
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 kargl at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > (In reply to kargl from comment #1) > > (In reply to Walter Brisken from comment #0) > > > > > > gfortran -save-temps -finit-local-zero -fno-automatic -fno-underscoring > > > -C > > > -w -g -O2 -c -o crash.o crash3.f > > > > > > > The problem is related to the -finit-local-zero option. > > The obvious workaround is to not use that option. I'll > > also recommend not using the -fno-underscoring option > > as the documentation warns about its use. > > Dang misread my terminal output. -fno-automatic is the > guilty option. Drop that option and things compile. Clearly not my day! One needs both -finit-local-zero and -fno-automatic to cause the ICE. Time for more coffee!
[Bug c++/66434] New: cc1plus: internal compiler error: in gimplify_modify_expr, at gimplify.c:4616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66434 Bug ID: 66434 Summary: cc1plus: internal compiler error: in gimplify_modify_expr, at gimplify.c:4616 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: george.d.petit.ctr at mail dot mil Target Milestone: --- Created attachment 35704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35704&action=edit ii file associated with failed compile command As this error is from a vendor code I cannot supply a sample source file that can duplicate the error. CC -O2 -Wall -g -Wextra -frounding-math -fsignaling-nans -march=native -ftrapv -fexceptions -v -save-temps -DLAMMPS_GZIP -DLAMMPS_JPEG -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX=1 -DFFT_FFTW3-c ../pair_hybrid.cpp Using built-in specs. COLLECT_GCC=/opt/gcc/4.9.2/bin/../snos/bin/g++ Target: x86_64-suse-linux Configured with: ../cray-gcc-4.9.2/configure --prefix=/opt/gcc/4.9.2/snos --disable-nls --libdir=/opt/gcc/4.9.2/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/4.9.2/snos/include/g++ --with-slibdir=/opt/gcc/4.9.2/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog Thread model: posix gcc version 4.9.2 20141030 (Cray Inc.) (GCC) COLLECT_GCC_OPTIONS='-march=core-avx2' '-static' '-D' '__CRAYXC' '-D' '__CRAY_HASWELL' '-D' '__CRAYXT_COMPUTE_LINUX_TARGET' '-u' 'pthread_mutex_trylock' '-u' 'pthread_mutex_destroy' '-u' 'pthread_create' '-D' '__TARGET_LINUX__' '-I' '/opt/cray/perftools/default/include' '-D' 'CRAYPAT' '-g' '-gpubnames' '-O1' '-B' '/opt/cray/perftools/default/libexec64' '-L/opt/cray/perftools/default/lib64' '-O2' '-Wall' '-g' '-Wextra' '-frounding-math' '-fsignaling-nans' '-march=native' '-ftrapv' '-fexceptions' '-v' '-save-temps' '-D' 'LAMMPS_GZIP' '-D' 'LAMMPS_JPEG' '-D' 'MPICH_SKIP_MPICXX' '-D' 'OMPI_SKIP_MPICXX=1' '-D' 'FFT_FFTW3' '-c' '-I' '/opt/cray/fftw/3.3.4.1/haswell/include' '-I' '/opt/cray/libsci/13.0.1/GNU/49/haswell/include' '-I' '/opt/cray/mpt/7.1.0/gni/mpich2-gnu/49/include' '-I' '/opt/cray/rca/1.0.0-2.0502.53711.3.127.ari/include' '-I' '/opt/cray/alps/5.2.1-2.0502.9041.11.6.ari/include' '-I' '/opt/cray/xpmem/0.1-2.0502.55507.3.2.ari/include' '-I' '/opt/cray/gni-headers/3.0-1.0502.9684.5.2.ari/include' '-I' '/opt/cray/pmi/5.0.6-1..10439.140.2.ari/include' '-I' '/opt/cray/ugni/5.0-1.0502.9685.4.24.ari/include' '-I' '/opt/cray/udreg/2.3.2-1.0502.9275.1.12.ari/include' '-I' '/opt/cray/wlm_detect/1.0-1.0502.53341.1.1.ari/include' '-I' '/opt/cray/krca/1.0.0-2.0502.53880.4.104.ari/include' '-I' '/opt/cray-hss-devel/7.2.0/include' /opt/gcc/4.9.2/snos/libexec/gcc/x86_64-suse-linux/4.9.2/cc1plus -E -quiet -v -I /opt/cray/perftools/default/include -I /opt/cray/fftw/3.3.4.1/haswell/include -I /opt/cray/libsci/13.0.1/GNU/49/haswell/include -I /opt/cray/mpt/7.1.0/gni/mpich2-gnu/49/include -I /opt/cray/rca/1.0.0-2.0502.53711.3.127.ari/include -I /opt/cray/alps/5.2.1-2.0502.9041.11.6.ari/include -I /opt/cray/xpmem/0.1-2.0502.55507.3.2.ari/include -I /opt/cray/gni-headers/3.0-1.0502.9684.5.2.ari/include -I /opt/cray/pmi/5.0.6-1..10439.140.2.ari/include -I /opt/cray/ugni/5.0-1.0502.9685.4.24.ari/include -I /opt/cray/udreg/2.3.2-1.0502.9275.1.12.ari/include -I /opt/cray/wlm_detect/1.0-1.0502.53341.1.1.ari/include -I /opt/cray/krca/1.0.0-2.0502.53880.4.104.ari/include -I /opt/cray-hss-devel/7.2.0/include -D_GNU_SOURCE -D __CRAYXC -D __CRAY_HASWELL -D __CRAYXT_COMPUTE_LINUX_TARGET -D __TARGET_LINUX__ -D CRAYPAT -D LAMMPS_GZIP -D LAMMPS_JPEG -D MPICH_SKIP_MPICXX -D OMPI_SKIP_MPICXX=1 -D FFT_FFTW3 ../pair_hybrid.cpp -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=40960 -mtune=generic -march=core-avx2 -Wall -Wextra -frounding-math -fsignaling-nans -ftrapv -fexceptions -g -gpubnames -g -fworking-directory -O1 -O2 -fpch-preprocess -o pair_hybrid.ii ignoring nonexistent directory "/opt/gcc/4.9.2/snos/lib/gcc/x86_64-suse-linux/4.9.2/../../../../x86_64-suse-linux/include" #include "..." search starts here: #include <...> search starts here: /opt/cray/perftools/default/include /opt/cray/fftw/3.3.4.1/haswell/include /opt/cray/libsci/13.0.1/GNU/49/haswell/include /opt/cray/mpt/7.1.0/gni/mpich2-gnu/49/include /opt/cray/rca/1.0.0-2.0502.53711.3.127.ari/include /opt/cray/alps/5.2.1-2.0502.9041.11.6.ari/include /opt/cray/xpmem/0.1-2.0502.55507.3.2.ari/include /opt/cray/gni
[Bug ipa/66424] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424 --- Comment #2 from Zhendong Su --- Jakub, I'm not sure that the code is invalid. First, the type of p in fn1 is defaulted to int. Second, all the invocations of fn1 from fn2 are with the same argument 0LL, which int can represent. Also, none of ubsan, Frama-C, and CompCert's reference interpreter complains about the code.
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 --- Comment #4 from kargl at gcc dot gnu.org --- Reduced testcase. block data integer n parameter (n=1) character*2 s1(n) character*8 s2(n) data (s1(i),s2(i),i=1,n)/"ab","12345678"/ end % gfc6 -c -fno-automatic -finit-local-zero block.f f951: internal compiler error: Segmentation fault 0xb4971f crash_signal ../../gcc6/gcc/toplev.c:380 0x62abf3 apply_default_init_local ../../gcc6/gcc/fortran/resolve.c:10952 0x62abf3 resolve_fl_variable ../../gcc6/gcc/fortran/resolve.c:11214 0x62abf3 resolve_symbol ../../gcc6/gcc/fortran/resolve.c:13757 0x64155b do_traverse_symtree ../../gcc6/gcc/fortran/symbol.c:3646 0x62c002 resolve_types ../../gcc6/gcc/fortran/resolve.c:14978 0x627cc0 gfc_resolve(gfc_namespace*) ../../gcc6/gcc/fortran/resolve.c:15082 0x613889 gfc_parse_file() ../../gcc6/gcc/fortran/parse.c:5475 0x6536a5 gfc_be_parse_file ../../gcc6/gcc/fortran/f95-lang.c:225
[Bug ipa/66424] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424 --- Comment #3 from joseph at codesourcery dot com --- See C11 6.5.2.2#6 regarding when calls to unprototyped functions involve undefined behavior. Being able to represent the value is only relevant where the case is a mismatch of corresponding signed/unsigned types.
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 --- Comment #7 from Aaro Koskinen --- The issue is also present when compiling kernels for OMAP1/2 platforms. Also looks like -Os is needed to trigger this. Kernels compiled with -O2 seem to work.
[Bug middle-end/66434] cc1plus: internal compiler error: in gimplify_modify_expr, at gimplify.c:4616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66434
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-06-05
CC||trippels at gcc dot gnu.org
Component|c++ |middle-end
Ever confirmed|0 |1
Known to fail||4.8.4, 4.9.2, 5.1.0, 6.0
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 tmp % cat pair_hybrid.ii
class Memory *a;
class Memory
{
public:
int create_j;
int *create_data;
int **create_plane;
int create_n3;
void
m_fn1 (int, int p2, int p3, char *)
{
long n;
for (; 0 < p2;)
{
create_j = 0;
for (; create_j < p3; create_j++)
{
create_plane[create_j] = &create_data[n];
n += create_n3;
}
}
}
};
void
fn1 ()
{
int n;
for (;;)
a->m_fn1 (0, n + 1, n + 1, "");
}
markus@x4 tmp % g++ -w -c -O2 -ftrapv pair_hybrid.ii
In function ‘void fn1()’:
cc1plus: internal compiler error: in gimplify_modify_expr, at gimplify.c:4753
All supported gcc versions ICE.
[Bug ipa/66424] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424 --- Comment #4 from Zhendong Su --- (In reply to jos...@codesourcery.com from comment #3) > See C11 6.5.2.2#6 regarding when calls to unprototyped functions involve > undefined behavior. Being able to represent the value is only relevant > where the case is a mismatch of corresponding signed/unsigned types. Joseph, thank you for the clarification. I assume that you were referring to the following passage of C11 6.5.2.2 #6: "If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases ... " Since int and long long are incompatible, thus the test case's behavior is undefined. Correct? If I may ask a follow-up question: How GCC treats the test case seems to have changed from 4.9 to 5.1. What might have prompted the change as the 4.9 behavior to me seems more natural and user-friendly (and is also how clang behaves)? Thank you.
[Bug c++/66405] [5/6 Regression] ICE: in tsubst, at cp/pt.c:11984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66405 --- Comment #7 from Jason Merrill --- Author: jason Date: Fri Jun 5 19:14:02 2015 New Revision: 224163 URL: https://gcc.gnu.org/viewcvs?rev=224163&root=gcc&view=rev Log: PR c++/66405 * pt.c (argument_pack_element_is_expansion_p): Return 2 if the expansion has extra args. (use_pack_expansion_extra_args_p): Return true in that case. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic-alias1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/66405] [5/6 Regression] ICE: in tsubst, at cp/pt.c:11984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66405 --- Comment #6 from Jason Merrill --- Author: jason Date: Fri Jun 5 19:13:56 2015 New Revision: 224162 URL: https://gcc.gnu.org/viewcvs?rev=224162&root=gcc&view=rev Log: PR c++/66405 * pt.c (type_dependent_expression_p): EXPR_PACK_EXPANSION is dependent even if it has a type. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/66405] [5/6 Regression] ICE: in tsubst, at cp/pt.c:11984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66405 --- Comment #8 from Jason Merrill --- Author: jason Date: Fri Jun 5 19:17:24 2015 New Revision: 224164 URL: https://gcc.gnu.org/viewcvs?rev=224164&root=gcc&view=rev Log: PR c++/66405 * pt.c (type_dependent_expression_p): EXPR_PACK_EXPANSION is dependent even if it has a type. Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/66405] [5/6 Regression] ICE: in tsubst, at cp/pt.c:11984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66405 --- Comment #9 from Jason Merrill --- Author: jason Date: Fri Jun 5 19:17:30 2015 New Revision: 224165 URL: https://gcc.gnu.org/viewcvs?rev=224165&root=gcc&view=rev Log: PR c++/66405 * pt.c (argument_pack_element_is_expansion_p): Return 2 if the expansion has extra args. (use_pack_expansion_extra_args_p): Return true in that case. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic-alias1.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/pt.c
[Bug c++/66405] [5/6 Regression] ICE: in tsubst, at cp/pt.c:11984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66405 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #10 from Jason Merrill --- Fixed for 5.2.
[Bug ipa/66424] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed||2015-06-05
CC||vmakarov at gcc dot gnu.org
Resolution|INVALID |---
Target Milestone|--- |5.2
Summary|wrong code at -O2 and -O3 |[5/6 Regression] wrong code
|on x86_64-linux-gnu in |at -O2 and -O3 on
|32-bit mode |x86_64-linux-gnu in 32-bit
||mode
Ever confirmed|0 |1
--- Comment #5 from Jakub Jelinek ---
Apparently it reproduces also with following, which doesn't have at least this
kind of undefined behavior in it. Started with r217588, thus most likely a
register allocation issue.
int a, b, c, d, e[2], f, l, m, n, o;
long long g = 1, j;
static unsigned int h;
static int i, k;
void
fn1 (long long p)
{
int q = p;
f = 1 ^ e[f ^ (q & 1)];
}
static void
fn2 (long long p)
{
f = 1 ^ e[(f ^ 1) & 1];
fn1 (p >> 1 & 1);
fn1 (p >> 32 & 1);
}
void
fn3 (int p)
{
g |= j = p;
}
int
main ()
{
e[0] = 1;
char p = l;
h = --g;
i = o = c;
m = d ? 1 / d : 0;
fn3 (l || 0);
b = a;
n = j++;
k--;
fn2 (g);
fn2 (h);
fn2 (i);
if (k + f)
__builtin_abort ();
return 0;
}
[Bug c++/66426] ICE: unexpected expression ‘int(Constructible())...’ of kind expr_pack_expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66426
--- Comment #1 from James Almer ---
FWIW, testcase from Comment 2 of pr66405 unedited:
[jamrial@archVM ~]$ cat pr66405_c2.cpp
template struct A;
template struct enable_if;
template struct B;
template using and_c = A>;
template using Constructible = int;
template struct common_tuple {
template <
typename... Us,
typename enable_if()...>::value>::type>
common_tuple();
void foo();
};
template <> void common_tuple<>::foo(){};
[jamrial@archVM ~]$ g++-4.9 -O2 -std=c++11 -c pr66405_c2.cpp
pr66405_c2.cpp:9:63: internal compiler error: unexpected expression
‘int(Constructible())...’ of kind expr_pack_expansion
typename enable_if()...>::value>::type>
^
0x61cbd6 cxx_eval_constant_expression
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9833
0x61e5b6 cxx_eval_outermost_constant_expr
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9853
0x585cb0 convert_nontype_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:5698
0x585cb0 convert_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6590
0x582252 coerce_template_parameter_pack
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6713
0x582252 coerce_template_parms
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6922
0x586c70 lookup_template_class_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7594
0x586c70 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7895
0x6149b2 finish_template_type(tree_node*, tree_node*, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:2969
0x5d63fa cp_parser_template_id
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13464
0x5d6613 cp_parser_class_name
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:19195
0x5cc673 cp_parser_qualifying_entity
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5538
0x5cc673 cp_parser_nested_name_specifier_opt
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5263
0x5e0ee2 cp_parser_simple_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14666
0x5c3ebd cp_parser_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14412
0x5c65cb cp_parser_type_specifier_seq
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18137
0x5d4ee2 cp_parser_type_id_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18010
0x5d4fde cp_parser_template_type_arg
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:18059
0x5d51d8 cp_parser_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13840
0x5d51d8 cp_parser_template_argument_list
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13750
And testcase taken from gcc/testsuite/g++.dg/cpp0x/variadic-alias1.C (added in
svn 224163)
[jamrial@archVM ~]$ cat Varidic-alias1.C
template struct B;
template using and_c = B;
template using Constructible = int;
template struct common_tuple {
template {}...> >
common_tuple();
void foo();
};
template <> void common_tuple<>::foo(){}
[jamrial@archVM ~]$ g++-4.9 -O2 -std=c++11 -c Varidic-alias1.C
Varidic-alias1.C:6:55: internal compiler error: unexpected expression ‘{}...’
of kind expr_pack_expansion
typename = and_c{}...> >
^
0x61cbd6 cxx_eval_constant_expression
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9833
0x61e5b6 cxx_eval_outermost_constant_expr
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:9853
0x585cb0 convert_nontype_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:5698
0x585cb0 convert_template_argument
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6590
0x582252 coerce_template_parameter_pack
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6713
0x582252 coerce_template_parms
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:6922
0x586c70 lookup_template_class_1
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7594
0x586c70 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/pt.c:7895
0x6149b2 finish_template_type(tree_node*, tree_node*, int)
/home/jamrial/gcc-4.9-20150603/gcc/cp/semantics.c:2969
0x5d63fa cp_parser_template_id
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:13464
0x5d6613 cp_parser_class_name
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:19195
0x5cc673 cp_parser_qualifying_entity
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5538
0x5cc673 cp_parser_nested_name_specifier_opt
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:5263
0x5e0ee2 cp_parser_simple_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14666
0x5c3ebd cp_parser_type_specifier
/home/jamrial/gcc-4.9-20150603/gcc/cp/parser.c:14412
0x5c65cb cp_parser_type_specifier_seq
/home/jamrial/gcc-4.9-20150603/gcc/c
[Bug middle-end/63434] builtins.c has incorrect parameters for GEN_CALL_VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63434 --- Comment #3 from steve at hearnden dot org.uk --- How do I get this bug confirmed?
[Bug ipa/66424] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424 --- Comment #6 from joseph at codesourcery dot com --- On Fri, 5 Jun 2015, su at cs dot ucdavis.edu wrote: > Since int and long long are incompatible, thus the test case's behavior is > undefined. Correct? Yes. Such cases have never been intended or expected to work with GCC.
[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #10 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 20:40:35 2015 New Revision: 224171 URL: https://gcc.gnu.org/viewcvs?rev=224171&root=gcc&view=rev Log: 2015-06-03 Russell Whitesides Steven G. Kargl PR fortran/40958 PR fortran/60780 PR fortran/66377 * module.c (load_equiv): Add check for loading duplicate EQUIVALENCEs from different modules. Eliminate the pruning of unused equivalence-objects 2015-06-03 Steven G. Kargl PR fortran/66377 gfortran.dg/equiv_9.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/equiv_9.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/module.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 --- Comment #11 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 20:40:35 2015 New Revision: 224171 URL: https://gcc.gnu.org/viewcvs?rev=224171&root=gcc&view=rev Log: 2015-06-03 Russell Whitesides Steven G. Kargl PR fortran/40958 PR fortran/60780 PR fortran/66377 * module.c (load_equiv): Add check for loading duplicate EQUIVALENCEs from different modules. Eliminate the pruning of unused equivalence-objects 2015-06-03 Steven G. Kargl PR fortran/66377 gfortran.dg/equiv_9.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/equiv_9.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/module.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/40958] module files too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #20 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 20:40:35 2015 New Revision: 224171 URL: https://gcc.gnu.org/viewcvs?rev=224171&root=gcc&view=rev Log: 2015-06-03 Russell Whitesides Steven G. Kargl PR fortran/40958 PR fortran/60780 PR fortran/66377 * module.c (load_equiv): Add check for loading duplicate EQUIVALENCEs from different modules. Eliminate the pruning of unused equivalence-objects 2015-06-03 Steven G. Kargl PR fortran/66377 gfortran.dg/equiv_9.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/equiv_9.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/module.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch.
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #11 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the PR and patch.
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 Bug 32834 depends on bug 66377, which changed state. Bug 66377 Summary: [F95] Wrong-code with equivalenced array in module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/66348] Simple loop never exit with -O1, exits with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 --- Comment #9 from Sebastiano Vigna --- As I said, I was trying (a bit naively, admittedly) a diagnosis. I agree fully--I'm no expert in x86 assembly. But it is a fact that the problematic loop never exits with -O1, and exits normally with -O0. The loop does not write any memory except for the local variable ld, so if the list of pointers was broken we should get a segment violation. Instead, it simply never exits (keeping 100% CPU load).
[Bug fortran/66385] [4.9/5/6 Regression] ICE: FORALL writing multiple elements of one array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66385 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Fri Jun 5 20:51:08 2015 New Revision: 224172 URL: https://gcc.gnu.org/viewcvs?rev=224172&root=gcc&view=rev Log: 2015-06-05 Thomas Koenig PR fortran/66385 * frontend-passes.c (combine_array_constructor): Return early if inside a FORALL loop. 2015-06-05 Thomas Koenig PR fortran/66385 * gfortran.dg/forall_17.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/forall_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66383] [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66383 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/66435] New: Add debug msg to dump_file in add_new_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66435 Bug ID: 66435 Summary: Add debug msg to dump_file in add_new_function Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- When a new function is created by spitting off some code from an existing function in ompexpand, we get no message about it in the dump file: ... ;; Function main0 (main0, funcdef_no=11, decl_uid=2342, cgraph_uid=11, symbol_order=11) Pass statistics: OMP region tree bb 2: gimple_omp_parallel bb 3: gimple_omp_for bb 4: GIMPLE_OMP_CONTINUE bb 5: GIMPLE_OMP_RETURN bb 6: GIMPLE_OMP_RETURN Applying pattern match.pd:114, generic-match.c:7303 Applying pattern match.pd:49, generic-match.c:3223 Applying pattern match.pd:114, generic-match.c:7303 Applying pattern match.pd:49, generic-match.c:3223 Introduced new external node (__builtin_omp_get_num_threads/13). Introduced new external node (__builtin_omp_get_thread_num/14). Merging blocks 2 and 12 Merging blocks 2 and 7 fix_loop_structure: fixing up loops for function ...
[Bug tree-optimization/66435] Add debug msg to dump_file in add_new_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66435 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #1 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00416.html
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 --- Comment #5 from Steve Kargl --- On Fri, Jun 05, 2015 at 05:53:24PM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 > > --- Comment #4 from kargl at gcc dot gnu.org --- > Reduced testcase. > > block data > integer n > parameter (n=1) > character*2 s1(n) > character*8 s2(n) common /foo/ s1, s2 > > data (s1(i),s2(i),i=1,n)/"ab","12345678"/ > end 4.8.x and 4.9.x flag the missing common statement.
[Bug tree-optimization/66436] New: Don't dump low gimple functions in gimple dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66436 Bug ID: 66436 Summary: Don't dump low gimple functions in gimple dump Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- When a new function is created by spitting off some code from an existing function in ompexpand, the new function is dumped into the gimple dump file, independent of whether it's in high gimple, low gimple or ssa gimple format. As a consequence, the function appears to go 'missing' after the gimple dump until a pass appropriate for the format processes it.
[Bug tree-optimization/66436] Don't dump low gimple functions in gimple dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66436 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch CC||tschwinge at gcc dot gnu.org --- Comment #1 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00417.html
[Bug tree-optimization/66436] Don't dump low gimple functions in gimple dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66436 --- Comment #2 from vries at gcc dot gnu.org --- FTR, x86_64 bootstrap and reg-test on patch passes.
[Bug tree-optimization/66435] Add debug msg to dump_file in add_new_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66435 --- Comment #2 from vries at gcc dot gnu.org --- FTR, x86_64 bootstrap and reg-test on patch passes.
[Bug libgomp/66429] ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429 --- Comment #2 from vries at gcc dot gnu.org --- submitted patches for superfluous std and fopenmp options: - https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00486.html - https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00487.html
[Bug c/66348] Simple loop never exits with -O1, exits with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 Mikhail Maltsev changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #10 from Mikhail Maltsev --- You should probably provide a reproducer: 1. Modify your program in such way that it does not require any user's action and/or command line switches to exhibit the problem (i.e. it should either hang or exit normally with code 0, depending on compiler flags used) 2. If your program requires some libraries (ncurses, or something like that), try to comment-out library calls or write some simple stubs insead of them. 3. It should not require any external files. If it does, try to hardcode all data into the program (e.g., if your text editor requires a file to be opened, use a static char array, which will contain that file). 4. It sould compile without any external headers. To achive this, just run each of your sources through preprocessor, like this: gcc -std=c99 -D_GNU_SOURCE -D__USE_GNU -DSTDC_HEADERS -Dinline=__inline__ -O1 -DNDEBUG -E buffer.c > buffer.i 5. Just in case, ensure that the bug still persists: compile the preprocessed sources and check that behavior did not change. 6. Compress all preprocessed sources and attach the archive.
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Known to work||4.8.4, 4.9.2 Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Known to fail||5.1.1, 6.0 --- Comment #6 from kargl at gcc dot gnu.org --- I have a patch
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 Joshua Kinard changed: What|Removed |Added CC||kumba at gentoo dot org --- Comment #23 from Joshua Kinard --- I ran into this on a Linux/mips64 (MIPS-IV ISA) build as well, running N32 ABI. mips64-unknown-linux-gnu-g++ -c -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc -I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/build -I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/../include -I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/../libcpp/include \ -o build/gcov-iov.o /usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/gcov-iov.c build/genmatch --gimple /usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/match.pd \ > tmp-gimple-match.c /bin/bash: line 1: 835 Segmentation fault build/genmatch --gimple /usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/match.pd > tmp-gimple-match.c Makefile:2318: recipe for target 's-match' failed make[3]: *** [s-match] Error 139 make[3]: *** Waiting for unfinished jobs This is in the 'all-stage1-gcc' stage from 'stage1-bubble'. I did not see any 'ld' warnings prior to that, but I have this in dmesg: [47163.043326] do_page_fault(): sending SIGSEGV to genmatch for invalid read access from [47163.043354] epc = in [47163.043402] genmatch[1000+9] [47163.043412] ra = 1000b960 in [47163.043436] genmatch[1000+9] Running a 64KB PAGE_SIZE, too, if that matters. I'll try to reverse commit r218976 from Comment #11 to see if that resolves the issue for me as well and update later.
[Bug ada/66437] New: False Positive warning "Variable is not modified in loop body"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66437 Bug ID: 66437 Summary: False Positive warning "Variable is not modified in loop body" Product: gcc Version: 4.7.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: tod_04 at syncorsystems dot com Target Milestone: --- In Ada when calling a function in a while loop and the function takes a parameter of mode "in out" the warning is generated that the passed variable is not modified. Specifically given : while Next_Stone(Value) loop null; end loop; Where Next_Stone is declared as function Next_Stone (Value : in out Positive) return Boolean is Will generate the following two warnings warning: variable "Value" is not modified in loop body" warning : possible infinite loop I would suggest that the warning should not be issued when the parameter mode is "out" or "in out".
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 --- Comment #7 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 23:01:22 2015 New Revision: 224175 URL: https://gcc.gnu.org/viewcvs?rev=224175&root=gcc&view=rev Log: 2015-06-05 Steven G. Kargl PR fortran/66347 * resolve.c (apply_default_init_local): Do not dereference a NULL pointer. 2015-06-05 Steven G. Kargl PR fortran/66347 * gfortran.dg/blockdata_9.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/blockdata_9.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/66438] New: libstdc++ 5.1 broke binary compat with old code using std::error_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66438
Bug ID: 66438
Summary: libstdc++ 5.1 broke binary compat with old code using
std::error_category
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
If you compile this program with GCC 4.9, but you have libstdc++ version 5.1
installed on your system. (E.g., this is the case for me because I'm using
Debian unstable).
#include
int main() {
std::error_code x = make_error_code(std::errc::no_such_file_or_directory);
std::error_condition e = std::errc::no_such_file_or_directory;
return x == e;
}
Then running it will return 0 instead of 1, like it should, (and did, with
libstdc++ 4.9 installed).
So, the thing to note, is that both "x" and "e" here have a category() of
_ZSt16generic_categoryv() as their category instance -- NOT
_ZNSt3_V216generic_categoryEv(), because it was built against the old headers.
(This seems to be as intended.)
Going through the calls, first we have this from
libstdc++-v3/include/std/system_error:
inline bool
operator==(const error_code& __lhs, const error_condition& __rhs) noexcept
{
return (__lhs.category().equivalent(__lhs.value(), __rhs)
|| __rhs.category().equivalent(__lhs, __rhs.value()));
}
which calls, from libstdc++-v3/src/c++11/compatibility-c++0x.cc:
bool
error_category::equivalent(int __i,
const error_condition& __cond) const noexcept
{ return default_error_condition(__i) == __cond; }
which calls, from the same file:
error_condition
error_category::default_error_condition(int __i) const noexcept
{
if (*this == system_category())
return error_condition(__i, _V2::system_category());
return error_condition(__i, _V2::generic_category());
}
which returns a _V2::generic_category() object. Oops. Now we're in big trouble!
Then, back to error_category::equivalent, where it calls, from
libstdc++-v3/include/std/system_error:
inline bool
operator==(const error_condition& __lhs,
const error_condition& __rhs) noexcept
{
return (__lhs.category() == __rhs.category()
&& __lhs.value() == __rhs.value());
}
Which fails, because __lhs.category() is the V2 generic_category, and
__rhs.category() is the "V1" generic_category.
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 5 23:16:57 2015 New Revision: 224176 URL: https://gcc.gnu.org/viewcvs?rev=224176&root=gcc&view=rev Log: 2015-06-05 Steven G. Kargl PR fortran/66347 * resolve.c (apply_default_init_local): Do not dereference a NULL pointer. 2015-06-05 Steven G. Kargl PR fortran/66347 * gfortran.dg/blockdata_9.f: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/blockdata_9.f Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/resolve.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #9 from kargl at gcc dot gnu.org --- Fixed on trunk and 5-branch. Thanks for the bug report.
[Bug fortran/66245] ICE on select type with empty type spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66245 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-05 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- I have a patch brewing.
[Bug libstdc++/6641] -D__USE_MALLOC doesn't link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6641 --- Comment #3 from Kazumoto Kojima --- Author: kkojima Date: Fri Jun 5 23:36:26 2015 New Revision: 224177 URL: https://gcc.gnu.org/viewcvs?rev=224177&root=gcc&view=rev Log: PR target/6641 * Split Snd constraint into Sid and Ssd. Disparage Sid/z alternative of *mov insn to avoid spill failure. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/constraints.md trunk/gcc/config/sh/sh.md
[Bug target/66410] [SH] ICE: in assign_by_spills, at lra-assigns.c:1428 with -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66410 Kazumoto Kojima changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Kazumoto Kojima --- I've committed the patch with a bit more comments as rev. 224177. Fixed on trunk.
[Bug c++/66439] New: Diagnostic on failed function template lookup is missing a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66439 Bug ID: 66439 Summary: Diagnostic on failed function template lookup is missing a line Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unmobile at gmail dot com Target Milestone: --- Created attachment 35705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35705&action=edit Test input When compiling the attached code, I get a pretty messed-up diagnostic that is both less than fully informative and suggests there's supposed to be more output, but doesn't print any: >$ g++-5 -c adltest.cpp >adltest.cpp: In function ‘void g(A::B)’: >adltest.cpp:11:12: error: no matching function for call to ‘f(A::B&)’ > C::f<3>(b); //ill-formed; argument dependent lookup >^ >adltest.cpp:6:26: note: candidate: template void C::f(T) > template void f(T t); > ^ >adltest.cpp:6:26: note: template argument deduction/substitution failed: (note the trailing colon ':' on the last line) This came to light when I tried to compile the code from http://stackoverflow.com/questions/2953684/why-doesnt-adl-find-function-templates and saw this trailed-off report. Really, the diagnostic should report more explicitly what's going on, that C::f isn't a valid binding because the template parameter '3' doesn't match up with the class parameter C::f expects.
[Bug c++/66440] New: Diagnostic on "'foo' was not declared in this scope" offers an invalid suggestion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66440 Bug ID: 66440 Summary: Diagnostic on "'foo' was not declared in this scope" offers an invalid suggestion Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unmobile at gmail dot com Target Milestone: --- Created attachment 35706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35706&action=edit Test input When I try to compile the attached source with g++ 5.1.1, I get a suggestion to use C::f. However, an explicit qualified call to C::f with the given template and function arguments would be invalid, as shown in the later statement. Perhaps the compiler should evaluate the candidates before enumerating them for the user, and either drop them or distinguish that they wouldn't actually match?
[Bug c++/66439] Diagnostic on failed function template lookup is missing a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66439 --- Comment #1 from Phil Miller --- Note that clang (from at least 3.5, possibly earlier) gets this right: > $ clang++-3.5 -c adltest.cpp > adltest.cpp:11:3: error: no matching function for call to 'f' > C::f<3>(b); //ill-formed; argument dependent lookup > ^~~ > adltest.cpp:6:26: note: candidate template ignored: invalid > explicitly-specified argument for template parameter 'T' > template void f(T t); > ^
[Bug libstdc++/66441] New: wstring_convert not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66441 Bug ID: 66441 Summary: wstring_convert not working correctly Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lcarreon at bigpond dot net.au Target Milestone: --- Created attachment 35707 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35707&action=edit Test program which demonstrates the issue In my opinion, there is a problem with the way wstring_convert behaves. I use Fedora 22 32-bit and 64-bit which includes GCC 5.1.1. Attached is a test program which demonstrates the problem. This test program converts a UTF-8 string which does not have a BOM into a UCS-4 string. The UCS-4 string is then converted to a UTF-16LE string. The test program is composed of two parts: 1) performs the conversion using the codecvt facets directly and 2) performs the conversion using wstring_convert. I compiled the test program using the following command: g++ -std=c++14 -o test_convert test_convert.cpp This test program generates the following result: UTF-8 string=Provençal UTF-8 string length=10 Test conversion using codecvt facets directly: UCS-4 string=50 72 6f 76 65 6e e7 61 6c UCS-4 string length=9 UTF-16LE string=ff fe 50 0 72 0 6f 0 76 0 65 0 6e 0 e7 0 61 0 6c 0 UTF-16LE string length=20 Test conversion using wstring_convert: UCS-4 string=50 72 6f 76 65 6e e7 61 6c UCS-4 string length=9 UTF-16LE string=ff fe 50 0 72 0 6f 0 76 0 65 0 ff fe 6e 0 e7 0 ff fe 61 0 6c 0 UTF-16LE string length=24 In my opinion, the result generated by the codecvt facets is the correct result. Notice that the UTF-16LE result generated by wstring_convert contains three occurrences of the BOM which is incorrect. I hope I have given enough information concerning this issue.
