[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
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
That looks like undefined behavior in the testcase. fn1 is KR function with
int argument, like if it was:
void
fn1 (p)
int p;
{
f = 1 ^ e[f ^ (p 1)];
}
but you are calling it with long long argument instead in fn2. If I change
it to void fn1 (p) long long p; { ... } or void fn1 (int p) { ... } or
change fn2 callers to cast the expressions to (int), it works fine.
[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 manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- 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 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 typename struct A;
template bool struct enable_if;
template typename T, T struct B;
template bool... Bools using and_c = ABbool, Bools || true...;
template typename... using Constructible = int;
template typename... Ts struct common_tuple {
template
typename... Us,
typename enable_ifand_c(int)ConstructibleTs, Us()...::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_ifand_c(int)ConstructibleTs, Us()...::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 http://gcc.gnu.org/bugs.html for instructions.
Testcase based on the one from Comment 2 of pr66405.
[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 sch...@linux-m68k.org --- ITYM a ((1 b) - 1)
[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 sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/65719] Link error with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719 Christian Kandeler christian.kandeler at theqtcompany dot com changed: What|Removed |Added CC||christian.kandeler@theqtcom ||pany.com --- Comment #5 from Christian Kandeler christian.kandeler at theqtcompany dot com --- Created attachment 35700 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35700action=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 complex
struct plus {};
struct multiplies {};
// ...
templatetypename T, typename Op
constexpr T identity_element;
template
constexpr int identity_elementint, plus = 0;
templatetypename T
constexpr std::complexT identity_elementstd::complexT, plus = {
identity_elementT, plus,
identity_elementT, plus
};
And here are the generated error messages:
main.cpp:15:23: error: expected primary-expression before ',' token
identity_elementT, plus,
^
main.cpp:15:29: error: expected primary-expression before '' token
identity_elementT, plus,
^
main.cpp:15:30: error: expected primary-expression before ',' token
identity_elementT, plus,
^
main.cpp:16:23: error: expected primary-expression before ',' token
identity_elementT, plus
^
main.cpp:16:29: error: expected primary-expression before '' token
identity_elementT, plus
^
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 (cleanup_point ((int) __atomic_load_1 (_ZGVZ3foovE1x, 2) 1) == 0) if (cleanup_point __cxa_guard_acquire (_ZGVZ3foovE1x) != 0) TARGET_EXPR D.3169, 0;, x = bar ();;, D.3169 = 1;;, __cxa_guard_release (_ZGVZ3foovE1x); ; 0925e39e497b5f218c4979b49afbdabcd3828e88 is the first bad commit commit 0925e39e497b5f218c4979b49afbdabcd3828e88 Author: ramana ramana@138bc75d-0d04-0410-961f-82ee72b054a4 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 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;
bb 2:
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;
bb 2:
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 gcc_email at congenio dot de changed: What|Removed |Added CC||gcc_email at congenio dot de --- Comment #6 from Dr. Uwe Meyer-Gruhl gcc_email at congenio dot de --- 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++/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 redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Version|unknown |4.9.2
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Reduced:
templatetypename... T struct tuple { };
templatetypename... T tupleT... make_tuple(T...) { return {}; }
template typename... Params
void foo(Params... params) {
auto t = make_tuple((int)params...);
}
template typename... Params
void bar(Params... params) {
tupledecltype((int)params)... 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 ‘tupleint, int, int’ to non-scalar type
‘tupleint’ 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 : nil
```
And GCC Go prints following:
```
In the beginning value is : 1
value is changed in closure : 2
final result is : 1
err is : nil
```
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 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 http://gcc.gnu.org/bugs.html for instructions.^M
...
[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 redi at gcc dot gnu.org 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 fortran/65751] Bogus L in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65751 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #2) And I think an English error message that points out the place of the error is more useful than a native-language one which doesn't, so I would favor backporting. When backporting to GCC 5, this is probably gfc_error_1, however, it you remove one of the %L, then you can use gfc_error (and get the colors).
[Bug c++/66427] The compiler rejects too complex variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66427 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Works OK on trunk.
[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 pinskia at gcc dot gnu.org --- (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++/66350] typename should be forbidden in inhering constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66350 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Also, using typename BaseT::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 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 lomov.as at gmail dot com --- Here is more details about this bug: https://code.google.com/p/go/issues/detail?id=8698thanks=8698ts=1410376474
[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 ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Ian Lance Taylor ian at airs dot com --- 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 pinskia at gcc dot gnu.org --- 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 nathan at gcc dot gnu.org --- Author: nathan Date: Fri Jun 5 13:35:30 2015 New Revision: 224152 URL: https://gcc.gnu.org/viewcvs?rev=224152root=gccview=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 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 nathan at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nathan Sidwell nathan at gcc dot gnu.org --- 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 sebastiano.vigna at unimi dot it --- I tried also with -fsanitize=address. No problems reported. Bug not showing up. A classical heisenbug.
[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=224154root=gccview=rev Log: Add transform_to_exit_first_loop_alt 2015-06-05 Tom de Vries t...@codesourcery.com merge from gomp4 branch: 2015-05-28 Tom de Vries t...@codesourcery.com 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 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 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 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 jason at gcc dot gnu.org --- Author: jason Date: Fri Jun 5 19:17:30 2015 New Revision: 224165 URL: https://gcc.gnu.org/viewcvs?rev=224165root=gccview=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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- Fixed for 5.2.
[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 su at cs dot ucdavis.edu --- 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 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 jason at gcc dot gnu.org --- Author: jason Date: Fri Jun 5 19:17:24 2015 New Revision: 224164 URL: https://gcc.gnu.org/viewcvs?rev=224164root=gccview=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 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 aaro.koskinen at iki dot fi --- 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 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=35704action=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
[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 trippels at gcc dot gnu.org 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 trippels at gcc dot gnu.org ---
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 su at cs dot ucdavis.edu --- (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 #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Jun 5 19:13:56 2015 New Revision: 224162 URL: https://gcc.gnu.org/viewcvs?rev=224162root=gccview=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 #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Jun 5 19:14:02 2015 New Revision: 224163 URL: https://gcc.gnu.org/viewcvs?rev=224163root=gccview=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 libstdc++/63860] Ill-formed std::pair::swap implementation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|5.2 |6.0 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- 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 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 jason at gcc dot gnu.org --- Author: jason Date: Fri Jun 5 16:25:26 2015 New Revision: 224157 URL: https://gcc.gnu.org/viewcvs?rev=224157root=gccview=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 jason at gcc dot gnu.org 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 jason at gcc dot gnu.org --- Fixed for 5.2.
[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 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 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/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=224159root=gccview=rev Log: 2015-06-03 Russell Whitesides russell...@gmail.com Steven G. Kargl ka...@gcc.gnu.org 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 ka...@gcc.gnu.org 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=224159root=gccview=rev Log: 2015-06-03 Russell Whitesides russell...@gmail.com Steven G. Kargl ka...@gcc.gnu.org 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 ka...@gcc.gnu.org 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=224159root=gccview=rev Log: 2015-06-03 Russell Whitesides russell...@gmail.com Steven G. Kargl ka...@gcc.gnu.org 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 ka...@gcc.gnu.org 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 jroivas at iki dot fi changed: What|Removed |Added Attachment #35668|0 |1 is obsolete|| --- Comment #9 from Jouni Roivas jroivas at iki dot fi --- Created attachment 35703 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35703action=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 --- 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 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 ubizjak at gmail dot com --- (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 c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/66347] Seg fault (ICE) on compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66347 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu --- 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 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 jakub at gcc dot gnu.org 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 jakub at gcc dot gnu.org ---
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 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 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 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 tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Fri Jun 5 20:51:08 2015 New Revision: 224172 URL: https://gcc.gnu.org/viewcvs?rev=224172root=gccview=rev Log: 2015-06-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/66385 * frontend-passes.c (combine_array_constructor): Return early if inside a FORALL loop. 2015-06-05 Thomas Koenig tkoe...@gcc.gnu.org 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 jason at gcc dot gnu.org 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/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] 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 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 jamrial at gmail dot com ---
FWIW, testcase from Comment 2 of pr66405 unedited:
[jamrial@archVM ~]$ cat pr66405_c2.cpp
template typename struct A;
template bool struct enable_if;
template typename T, T struct B;
template bool... Bools using and_c = ABbool, Bools || true...;
template typename... using Constructible = int;
template typename... Ts struct common_tuple {
template
typename... Us,
typename enable_ifand_c(int)ConstructibleTs, Us()...::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_ifand_c(int)ConstructibleTs, Us()...::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 typename T, T... struct B;
template bool... Bools using and_c = Bbool, +Bools...;
template typename T, typename U using Constructible = int;
template typename... Ts struct common_tuple {
template typename... Us,
typename = and_cConstructibleTs, Us{}...
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_cConstructibleTs, Us{}...
^
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
[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 sebastiano.vigna at unimi dot it --- 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 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 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 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 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 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 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 --- 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=224171root=gccview=rev Log: 2015-06-03 Russell Whitesides russell...@gmail.com Steven G. Kargl ka...@gcc.gnu.org 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 ka...@gcc.gnu.org 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=224171root=gccview=rev Log: 2015-06-03 Russell Whitesides russell...@gmail.com Steven G. Kargl ka...@gcc.gnu.org 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 ka...@gcc.gnu.org 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=224171root=gccview=rev Log: 2015-06-03 Russell Whitesides russell...@gmail.com Steven G. Kargl ka...@gcc.gnu.org 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 ka...@gcc.gnu.org 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/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 c/66348] Simple loop never exits with -O1, exits with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #10 from Mikhail Maltsev miyuki at gcc dot gnu.org --- 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 --- 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=224176root=gccview=rev Log: 2015-06-05 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66347 * resolve.c (apply_default_init_local): Do not dereference a NULL pointer. 2015-06-05 Steven G. Kargl ka...@gcc.gnu.org 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 --- 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=224175root=gccview=rev Log: 2015-06-05 Steven G. Kargl ka...@gcc.gnu.org PR fortran/66347 * resolve.c (apply_default_init_local): Do not dereference a NULL pointer. 2015-06-05 Steven G. Kargl ka...@gcc.gnu.org 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 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 kkojima at gcc dot gnu.org --- Author: kkojima Date: Fri Jun 5 23:36:26 2015 New Revision: 224177 URL: https://gcc.gnu.org/viewcvs?rev=224177root=gccview=rev Log: PR target/6641 * Split Snd constraint into Sid and Ssd. Disparage Sid/z alternative of *movmode insn to avoid spill failure. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/constraints.md trunk/gcc/config/sh/sh.md
[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 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 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 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 kumba at gentoo dot org changed: What|Removed |Added CC||kumba at gentoo dot org --- Comment #23 from Joshua Kinard kumba at gentoo dot org --- 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 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 system_error
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 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 kkojima at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org --- I've committed the patch with a bit more comments as rev. 224177. Fixed on trunk.
[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=35701action=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 y.usishchev at samsung dot com --- Created attachment 35702 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35702action=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.
