[Bug tree-optimization/82473] New: [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82473
Bug ID: 82473
Summary: [8 Regression] ICE in vect_get_vec_def_for_stmt_copy,
at tree-vect-stmts.c:1524
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171001 snapshot (r253330) ICEs when compiling the following
snippet w/ -O1 -ftree-vectorize:
void
zz (int x9, short int gt)
{
if (0)
{
while (gt < 1)
{
int pz;
k6:
for (pz = 0; pz < 3; ++pz)
x9 += gt;
++gt;
}
}
if (x9 != 0)
goto k6;
}
gcc-8.0.0-alpha20171001 -O1 -ftree-vectorize -c rkv2nnff.c
during GIMPLE pass: vect
rkv2nnff.c: In function 'zz':
rkv2nnff.c:2:1: internal compiler error: in vect_get_vec_def_for_stmt_copy, at
tree-vect-stmts.c:1524
zz (int x9, short int gt)
^~
[Bug tree-optimization/82472] New: [8 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82472
Bug ID: 82472
Summary: [8 Regression] ICE in generate_code_for_partition, at
tree-loop-distribution.c:1145
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20171001 snapshot (r253330) ICEs when compiling the following
snippet w/ -O3 or -Ofast:
long int xj;
int
cx (long int *ox, short int mk, char tf)
{
int si, f9;
char *p4 = &tf;
short int *rm = (tf != 0) ? (short int *)&f9 : &mk;
for (f9 = 0; f9 < 2; ++f9)
{
*rm = 0;
*p4 = *ox;
si = mk;
xj = 0;
while (p4 < (char *)rm)
++p4;
}
return si;
}
% gcc-8.0.0-alpha20171001 -O3 -c mjliuylm.c
during GIMPLE pass: ldist
mjliuylm.c: In function 'cx':
mjliuylm.c:4:1: internal compiler error: in generate_code_for_partition, at
tree-loop-distribution.c:1145
cx (long int *ox, short int mk, char tf)
^~
[Bug c++/82466] Missing warning for re-declaration of built-in function as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 --- Comment #3 from Paolo Carlini --- Yes. Recycling the warning-name that you added seems fine, but we should probably extend the description to something like: "Warn if a built-in function is declared with the wrong signature or as non-function."
[Bug c++/82466] Missing warning for re-declaration of built-in function as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini --- Yes. Recycling the warning-name that you added seems fine, but we should probably extend the description to something like: "Warn if a built-in function is declared with the wrong signature or as non-function."
[Bug fortran/82471] New: do concurrent is much slower the ordinary do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 Bug ID: 82471 Summary: do concurrent is much slower the ordinary do! Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- in this example do-concurrent is much slower than ordinary-do : PROGRAM TEST_DO_SPEED IMPLICIT NONE REAL, ALLOCATABLE :: A(:,:,:), B(:,:,:), C(:,:,:) REAL :: TIC INTEGER :: T0, T1, T2 INTEGER :: I, J, K INTEGER, PARAMETER :: L = 512, M = 512, N = 512 ALLOCATE( A(L,M,N), B(L,M,N), C(L,M,N) ) CALL RANDOM_NUMBER(A) CALL RANDOM_NUMBER(B) CALL SYSTEM_CLOCK( T0, TIC) DO CONCURRENT( K=1:N, J=1:M, I=1:L) C(I,J,K) = A(I,J,K) +B(I,J,K) END DO CALL SYSTEM_CLOCK(T1) DO K=1,N DO J=1,M DO I=1,L C(I,J,K) = A(I,J,K) +B(I,J,K) END DO END DO END DO CALL SYSTEM_CLOCK(T2) PRINT*,"DO CONCURRENT : ",(T1-T0)/TIC PRINT*,"ORDINARY DO : ",(T2-T1)/TIC END PROGRAM Compiled with : -Ofast it gives Under MinGW-64 7.2.0 : DO CONCURRENT :13.0620003 ORDINARY DO : 0.23397 and under Ubuntu-16.04-64 7.2.0 : DO CONCURRENT :11.604 ORDINARY DO : 0.20804 It looks like with do-concurrent gfortran begin with the first index . I know that there is no obligations in Standard-Fortran. but at least make it act like the ordinary-do construct.
[Bug libstdc++/82470] New: Structured bindings don't work with std::tuple if a type has a get member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470
Bug ID: 82470
Summary: Structured bindings don't work with std::tuple if a
type has a get member function
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: morwenn29 at hotmail dot fr
Target Milestone: ---
Here is a simple example of failing code:
struct foobar
{
template
int get() { return N; }
};
int main()
{
std::tuple tu;
auto [a, b] = tu;
}
The compiler complains about the function foobar::get being unaccessible. This
is caused by the packing behaviour of std::tuple: foobar begin an empty class,
std::tuple will attempt EBCO and eventually privately inherit from foobar.
Structured bindings first look for a get member function in std::tuple, and find foobar::get because it has the correct interface and
std::tuple inherits from foobar. However the private inheritance makes the
function inaccessible and triggers a compiler error accordingly.
I don't know whether it's possible to solve the problem while keeping the full
EBCO capabilities, save for a change in structured bindings lookup rules.
[Bug tree-optimization/82450] loop flattening should be done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82450 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-07 Summary|Consider optimizing |loop flattening should be |multidimensional arrays |done |access without | |-ftree-vectorize| Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- This optimization is called loop flattening. Confirmed, it is not done currently.
[Bug preprocessor/82469] New: ICE in _cpp_process_line_notes, at libcpp/lex.c:1066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82469 Bug ID: 82469 Summary: ICE in _cpp_process_line_notes, at libcpp/lex.c:1066 Product: gcc Version: 6.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: heiko at hexco dot de Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu Build: x86_64-linux-gnu (gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)) Created attachment 42322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42322&action=edit test code to trigger ICE Hi, this code === #define B */ #define A /B #if A A 1 #endif === when run with with "cpp -traditional-cpp -ffreestanding -P issues/ICE.c" gives : internal compiler error: in _cpp_process_line_notes, at libcpp/lex.c:1066 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. In trunk the abort() is now at line 1163 in libcpp/lex.c. BTW: Wouldn't it be useful for bug reporters to have online access to the latest build of the compilers in order to quickly check if their bug test cases are still relevant? Thanks, Heiko
[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #21 from Thomas Koenig --- Jerry, I think you know more about this than I do, so please go ahead.
Re: GCC does not optimize out functions without side effects with asm statements inside loop even if return velue is ignored
On Sat, Oct 7, 2017 at 2:22 PM, Saldyrkine, Mikhail
wrote:
> The " uint64_t test_noasm(uint64_t idx)" has same loop and the function is
> optimized out.
There is a difference there, objects is limited to 1024. Loading past
the array bounds is undefined.
Thanks,
Andrew
> I've changed code to constraint the loop iterations and compiler:
> - unrolled loop
> - did not eliminate the function as it does when asm is not used
> It looks like the " infinite loop" is not root cause.
>
> inline uint64_t test_asm_inside_loop(uint64_t idx) {
> uint64_t result;
> for( int i = 0; i < capacity; ++i )
> {
> asm ("movq (%1,%2,8), %0" : "=r" (result) : "r" (objects), "r" (idx)
> );
> if( result > 128 )
> return result;
> ++idx;
> }
> return 0;
> }
>
> Dump of assembler code for function _Z28compile_test_asm_inside_loopv:
>0x00400b40 <+0>: xor%eax,%eax
>0x00400b42 <+2>: mov$0x602080,%edx
>0x00400b47 <+7>: mov(%rdx,%rax,8),%rcx
>0x00400b4b <+11>:cmp$0x80,%rcx
>0x00400b52 <+18>:ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400b58 <+24>:mov$0x1,%eax
>0x00400b5d <+29>:mov(%rdx,%rax,8),%rsi
>0x00400b61 <+33>:cmp$0x80,%rsi
>0x00400b68 <+40>:ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400b6e <+46>:lea0x1(%rax),%rdi
>0x00400b72 <+50>:mov(%rdx,%rdi,8),%r8
>0x00400b76 <+54>:cmp$0x80,%r8
>0x00400b7d <+61>:ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400b83 <+67>:lea0x2(%rax),%r9
>0x00400b87 <+71>:mov(%rdx,%r9,8),%r10
>0x00400b8b <+75>:cmp$0x80,%r10
>0x00400b92 <+82>:ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400b98 <+88>:lea0x3(%rax),%r11
>0x00400b9c <+92>:mov(%rdx,%r11,8),%rcx
>0x00400ba0 <+96>:cmp$0x80,%rcx
>0x00400ba7 <+103>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400bad <+109>: lea0x4(%rax),%rsi
>0x00400bb1 <+113>: mov(%rdx,%rsi,8),%r8
>0x00400bb5 <+117>: cmp$0x80,%r8
>0x00400bbc <+124>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400bbe <+126>: lea0x5(%rax),%r9
>0x00400bc2 <+130>: mov(%rdx,%r9,8),%r10
>0x00400bc6 <+134>: cmp$0x80,%r10
>0x00400bcd <+141>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400bcf <+143>: lea0x6(%rax),%r11
>0x00400bd3 <+147>: mov(%rdx,%r11,8),%rcx
>0x00400bd7 <+151>: cmp$0x80,%rcx
>0x00400bde <+158>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400be0 <+160>: lea0x7(%rax),%rsi
>0x00400be4 <+164>: mov(%rdx,%rsi,8),%r8
>0x00400be8 <+168>: cmp$0x80,%r8
>0x00400bef <+175>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400bf1 <+177>: lea0x8(%rax),%r9
>0x00400bf5 <+181>: mov(%rdx,%r9,8),%r10
>0x00400bf9 <+185>: cmp$0x80,%r10
>0x00400c00 <+192>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400c02 <+194>: add$0x9,%rax
>0x00400c06 <+198>: mov(%rdx,%rax,8),%rax
>0x00400c0a <+202>: cmp$0x80,%rax
>0x00400c10 <+208>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400c12 <+210>: lea0x9(%rdi),%r11
>0x00400c16 <+214>: mov(%rdx,%r11,8),%rcx
>0x00400c1a <+218>: cmp$0x80,%rcx
>0x00400c21 <+225>: ja 0x400c38
> <_Z28compile_test_asm_inside_loopv+248>
>0x00400c23 <+227>: lea0xa(%rdi),%rax
>0x00400c27 <+231>: cmp$0x400,%rax
>0x00400c2d <+237>: jne0x400b5d
> <_Z28compile_test_asm_inside_loopv+29>
>0x00400c33 <+243>: repz retq
>0x00400c35 <+245>: nopl (%rax)
>0x00400c38 <+248>: repz retq
>
> -Original Message-
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Saturday, October 07, 2017 3:04 PM
> To: Saldyrkine, Mikhail [Sec Div]
> Cc: gcc-bugs@gcc.gnu.org
> Subject: Re: GCC does not optimize out functions without side effects with
> asm statements inside loop even if return velue is ignored
>
> On Sat, Oct 7, 2017 at 8:39 AM, Saldyrkine, Mikhail
> wrote:
>> g++ (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3)
>>
>> In the below case compile_test_asm_inside_loop invokes test_asm_inside_loop
>> and ignores results.
>> The call into test_asm_inside_loop is expected to be eliminated since return
RE: GCC does not optimize out functions without side effects with asm statements inside loop even if return velue is ignored
The " uint64_t test_noasm(uint64_t idx)" has same loop and the function is
optimized out.
I've changed code to constraint the loop iterations and compiler:
- unrolled loop
- did not eliminate the function as it does when asm is not used
It looks like the " infinite loop" is not root cause.
inline uint64_t test_asm_inside_loop(uint64_t idx) {
uint64_t result;
for( int i = 0; i < capacity; ++i )
{
asm ("movq (%1,%2,8), %0" : "=r" (result) : "r" (objects), "r" (idx) );
if( result > 128 )
return result;
++idx;
}
return 0;
}
Dump of assembler code for function _Z28compile_test_asm_inside_loopv:
0x00400b40 <+0>: xor%eax,%eax
0x00400b42 <+2>: mov$0x602080,%edx
0x00400b47 <+7>: mov(%rdx,%rax,8),%rcx
0x00400b4b <+11>:cmp$0x80,%rcx
0x00400b52 <+18>:ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400b58 <+24>:mov$0x1,%eax
0x00400b5d <+29>:mov(%rdx,%rax,8),%rsi
0x00400b61 <+33>:cmp$0x80,%rsi
0x00400b68 <+40>:ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400b6e <+46>:lea0x1(%rax),%rdi
0x00400b72 <+50>:mov(%rdx,%rdi,8),%r8
0x00400b76 <+54>:cmp$0x80,%r8
0x00400b7d <+61>:ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400b83 <+67>:lea0x2(%rax),%r9
0x00400b87 <+71>:mov(%rdx,%r9,8),%r10
0x00400b8b <+75>:cmp$0x80,%r10
0x00400b92 <+82>:ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400b98 <+88>:lea0x3(%rax),%r11
0x00400b9c <+92>:mov(%rdx,%r11,8),%rcx
0x00400ba0 <+96>:cmp$0x80,%rcx
0x00400ba7 <+103>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400bad <+109>: lea0x4(%rax),%rsi
0x00400bb1 <+113>: mov(%rdx,%rsi,8),%r8
0x00400bb5 <+117>: cmp$0x80,%r8
0x00400bbc <+124>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400bbe <+126>: lea0x5(%rax),%r9
0x00400bc2 <+130>: mov(%rdx,%r9,8),%r10
0x00400bc6 <+134>: cmp$0x80,%r10
0x00400bcd <+141>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400bcf <+143>: lea0x6(%rax),%r11
0x00400bd3 <+147>: mov(%rdx,%r11,8),%rcx
0x00400bd7 <+151>: cmp$0x80,%rcx
0x00400bde <+158>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400be0 <+160>: lea0x7(%rax),%rsi
0x00400be4 <+164>: mov(%rdx,%rsi,8),%r8
0x00400be8 <+168>: cmp$0x80,%r8
0x00400bef <+175>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400bf1 <+177>: lea0x8(%rax),%r9
0x00400bf5 <+181>: mov(%rdx,%r9,8),%r10
0x00400bf9 <+185>: cmp$0x80,%r10
0x00400c00 <+192>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400c02 <+194>: add$0x9,%rax
0x00400c06 <+198>: mov(%rdx,%rax,8),%rax
0x00400c0a <+202>: cmp$0x80,%rax
0x00400c10 <+208>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400c12 <+210>: lea0x9(%rdi),%r11
0x00400c16 <+214>: mov(%rdx,%r11,8),%rcx
0x00400c1a <+218>: cmp$0x80,%rcx
0x00400c21 <+225>: ja 0x400c38
<_Z28compile_test_asm_inside_loopv+248>
0x00400c23 <+227>: lea0xa(%rdi),%rax
0x00400c27 <+231>: cmp$0x400,%rax
0x00400c2d <+237>: jne0x400b5d
<_Z28compile_test_asm_inside_loopv+29>
0x00400c33 <+243>: repz retq
0x00400c35 <+245>: nopl (%rax)
0x00400c38 <+248>: repz retq
-Original Message-
From: Andrew Pinski [mailto:pins...@gmail.com]
Sent: Saturday, October 07, 2017 3:04 PM
To: Saldyrkine, Mikhail [Sec Div]
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: GCC does not optimize out functions without side effects with asm
statements inside loop even if return velue is ignored
On Sat, Oct 7, 2017 at 8:39 AM, Saldyrkine, Mikhail
wrote:
> g++ (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3)
>
> In the below case compile_test_asm_inside_loop invokes test_asm_inside_loop
> and ignores results.
> The call into test_asm_inside_loop is expected to be eliminated since return
> value is not used and there is no side effect
> The call elimination works fine without asm and without loop
> It does not work with asm inside loop
Because the loop could be an infinite loop and GCC does not know how
many times the inline-asm is going to be called and if there are other
side effects.
Let's look at the function:
inline uint64_t test_asm_inside_loop(uint
[Bug c++/82468] New: ICE with deduction guide template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82468
Bug ID: 82468
Summary: ICE with deduction guide template
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
If we try to make the template-name of the deduction guide a type-parameter,
courtesy of W.F. on SO (https://stackoverflow.com/q/46624005/2069064):
template
struct Foo {
Foo(T) { }
};
template class TT>
TT(double) -> TT;
int main() {
Foo foo(2.0);
}
yields:
prog.cc:7:15: internal compiler error: Segmentation fault
TT(double) -> TT;
^~~
0xbcb8bf crash_signal
../../source/gcc/toplev.c:326
0x70b892 check_special_function_return_type
../../source/gcc/cp/decl.c:9742
0x70b892 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../source/gcc/cp/decl.c:10319
0x70f126 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../source/gcc/cp/decl.c:4909
0x780e6e cp_parser_init_declarator
../../source/gcc/cp/parser.c:19489
0x785c3a cp_parser_single_declaration
../../source/gcc/cp/parser.c:27073
0x785d6c cp_parser_template_declaration_after_parameters
../../source/gcc/cp/parser.c:26676
0x7863ff cp_parser_explicit_template_declaration
../../source/gcc/cp/parser.c:26912
0x7863ff cp_parser_template_declaration_after_export
../../source/gcc/cp/parser.c:26931
0x78a151 cp_parser_declaration
../../source/gcc/cp/parser.c:12676
0x78a41b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12603
0x78a6de cp_parser_translation_unit
../../source/gcc/cp/parser.c:4391
0x78a6de c_parse_file()
../../source/gcc/cp/parser.c:38915
0x83adc6 c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1113
[Bug fortran/82375] PDT components in PDT declarations fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82375 --- Comment #5 from Paul Thomas --- Author: pault Date: Sat Oct 7 21:14:06 2017 New Revision: 253514 URL: https://gcc.gnu.org/viewcvs?rev=253514&root=gcc&view=rev Log: 2017-10-07 Paul Thomas PR fortran/82375 * class.c (gfc_find_derived_vtab): Return NULL for a passed pdt template to prevent bad procedures from being written. * decl.c (gfc_get_pdt_instance): Do not use the default initializer for pointer and allocatable pdt type components. If the component is allocatbale, set the 'alloc_comp' attribute of 'instance'. * module.c : Add a prototype for 'mio_actual_arglist'. Add a boolean argument 'pdt'. (mio_component): Call it for the parameter list of pdt type components with 'pdt' set to true. (mio_actual_arg): Add the boolean 'pdt' and, if it is set, call mio_integer for the 'spec_type'. (mio_actual_arglist): Add the boolean 'pdt' and use it in the call to mio_actual_arg. (mio_expr, mio_omp_udr_expr): Call mio_actual_arglist with 'pdt' set false. * resolve.c (get_pdt_spec_expr): Add the parameter name to the KIND parameter error. (get_pdt_constructor): Check that cons->expr is non-null. * trans-array.c (structure_alloc_comps): For deallocation of allocatable components, ensure that parameterized components are deallocated first. Likewise, when parameterized components are allocated, nullify allocatable components first. Do not recurse into pointer or allocatable pdt components while allocating or deallocating parameterized components. Test that parameterized arrays or strings are allocated before freeing them. (gfc_trans_pointer_assignment): Call the new function. Tidy up a minor whitespace issue. trans-decl.c (gfc_trans_deferred_vars): Set 'tmp' to NULL_TREE to prevent the expression from being used a second time. 2017-10-07 Paul Thomas PR fortran/82375 * gfortran.dg/pdt_13.f03 : New test. * gfortran.dg/pdt_14.f03 : New test. * gfortran.dg/pdt_15.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/pdt_13.f03 trunk/gcc/testsuite/gfortran.dg/pdt_14.f03 trunk/gcc/testsuite/gfortran.dg/pdt_15.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/78581] Out of memory when preprocessing #include with -traditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78581 Heiko Eißfeldt changed: What|Removed |Added CC||heiko at hexco dot de --- Comment #2 from Heiko Eißfeldt --- I can reproduce this with cpp 6.3.0 on Ubuntu 17.04 amd64. No environment variable setting is necessary. And if I simplify your test case "a" to #include "b" #if 0 #endif cpp does not see the '#if 0': === cpp -traditional-cpp -ffreestanding -P issues/a f issues/a:3:0: error: #endif without #if #endif #if 0 === So, it could have something to do with misparsing at the end of "b". Fascinating...
[Bug c++/82467] New: name mangling error when using constrained an specialized template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82467
Bug ID: 82467
Summary: name mangling error when using constrained an
specialized template functions
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: saphirahemp at yahoo dot de
Target Milestone: ---
Created attachment 42321
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42321&action=edit
the *i* file
It seems that the compiler produces some collisions in case of this special
constellation - template specialization for type T and constrained function
that accepts T.
example for integer:
template<>
void f(int t) {}
template
requires requires(T t){ t + t;}
void f(T t) {}
int main(){
f(1);
}
will result in an error when compiling:
g++-6 -fconcepts int.cpp
/tmp/ccooj1kv.s: Assembler messages:
/tmp/ccooj1kv.s:65: Error: symbol `_Z1fIiEvT_' is already defined
/tmp/ccooj1kv.s: Error: .size expression for _Z1fIiEvT_ does not evaluate to a
constant
The same code with float instead of int will produce the same error message,
with a slightly different symbol: _Z1fIfEvT_ instead of _Z1fIiEvT_.
further informations:
the exact version of GCC and the system type;
gcc version 6.3.0 20170519 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04)
Target: x86_64-linux-gnu
the options given when GCC was configured/built;
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
6.3.0-18ubuntu2~16.04' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
the complete command line that triggers the bug;
g++-6 -fconcepts int.cpp
the compiler output (error messages, warnings, etc.);
/tmp/ccooj1kv.s: Assembler messages:
/tmp/ccooj1kv.s:65: Error: symbol `_Z1fIiEvT_' is already defined
/tmp/ccooj1kv.s: Error: .size expression for _Z1fIiEvT_ does not evaluate to a
constant
[Bug preprocessor/82130] stringification (#) in traditional mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82130 Heiko Eißfeldt changed: What|Removed |Added CC||heiko at hexco dot de --- Comment #1 from Heiko Eißfeldt --- This variant works for me with: #define STRINGIFY(x) "x" #define _ASSERT_(expr) if (.not. (expr)) print *, STRINGIFY(expr) program test logical :: check = .false. _ASSERT_(check) end cpp -traditional-cpp -P -E issues/fortranStringify.f gives program test logical :: check = .false. if (.not. (check)) print *, "check" end This is with cpp 6.3.0 on ubuntu 17.04 amd64.
[Bug target/82420] ICE with -malign-int and -m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420 --- Comment #2 from Mikael Pettersson --- Started with r145586, but that may simply have exposed a latent issue. BTW, the configuration of the reporter's gcc > $ m68k-elf-gcc -v > Using built-in specs. > COLLECT_GCC=m68k-elf-gcc > COLLECT_LTO_WRAPPER=/opt/toolchains/m68k/libexec/gcc/m68k-elf/7.1.0/lto-wrapper > Target: m68k-elf > Configured with: ../gcc-7.1.0/configure --target=m68k-elf > --program-prefix=m68k-elf- --prefix=/opt/toolchains/m68k > --with-local-prefix=/opt/toolchains/m68k --with-newlib > --enable-languages=c,c++ --disabel-nls --disable-werror > --enable-threads=single --disable-libssp --disable-libquadmath > --with-cpu=68000 --with-arch=m68k > Thread model: single > gcc version 7.1.0 (GCC) has a minor typo: it should be '--disable-nls' not '--disabel-nls'.
[Bug c++/82466] Missing warning for re-declaration of built-in function as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 --- Comment #2 from Bernd Edlinger --- Thanks for looking at this. I think your patch is fine. My thought was that it could also be enabled by OPT_Wbuiltin_declaration_mismatch, which is default-enabled but can be disabled in the test case, if needed.
[Bug c++/82466] Missing warning for re-declaration of built-in function as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
--- Comment #1 from Paolo Carlini ---
Thanks. I don't think there is *much* more than the below to it:
Index: decl.c
===
--- decl.c (revision 253509)
+++ decl.c (working copy)
@@ -1431,7 +1431,13 @@
/* Avoid warnings redeclaring built-ins which have not been
explicitly declared. */
if (DECL_ANTICIPATED (olddecl))
- return NULL_TREE;
+ {
+ if (TREE_PUBLIC (newdecl))
+ warning_at (DECL_SOURCE_LOCATION (newdecl),
+ 0, "built-in function %qD declared as
non-function",
+ newdecl);
+ return NULL_TREE;
+ }
/* If you declare a built-in or predefined function name as static,
the old definition is overridden, but optionally warn this was a
however, with the warning unconditionally enabled, as in the C front-end,
g++.dg/parse/builtin2.C fails. Maybe that's ok, maybe we want to give the
warning a name. Bernd, are you willing to work on this issue too, for 8?
Re: GCC does not optimize out functions without side effects with asm statements inside loop even if return velue is ignored
On Sat, Oct 7, 2017 at 8:39 AM, Saldyrkine, Mikhail
wrote:
> g++ (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3)
>
> In the below case compile_test_asm_inside_loop invokes test_asm_inside_loop
> and ignores results.
> The call into test_asm_inside_loop is expected to be eliminated since return
> value is not used and there is no side effect
> The call elimination works fine without asm and without loop
> It does not work with asm inside loop
Because the loop could be an infinite loop and GCC does not know how
many times the inline-asm is going to be called and if there are other
side effects.
Let's look at the function:
inline uint64_t test_asm_inside_loop(uint64_t idx) {
while(true)
{
uint64_t result;
asm ("movq (%1,%2,8), %0" : "=r" (result) : "r" (objects), "r" (idx) );
if( result > 128 )
return result;
++idx;
}
}
The loop is only broken out of when result is > 128. result from the
inline-asm is used as the breakout from the loop.
Thanks,
Andrew
>
> TEST CODE
>
> #include
> #include
>
> using namespace std;
> constexpr static size_t capacity = 1024;
> uint64_t objects[capacity];
>
> // THE FUNCTION IS ELIMINATED BY COMPILER IF OUTPUT IS NOT USED
> inline uint64_t test_noloop(uint64_t idx) {
> uint64_t result;
> asm ("movq (%1,%2,8), %0" : "=r" (result) : "r" (objects), "r" (idx) );
> if( result > 128 )
> return result;
> return 0;
> }
>
> // THE FUNCTION IS ELIMINATED BY COMPILER IF OUTPUT IS NOT USED
> inline uint64_t test_noasm(uint64_t idx) {
> while(true)
> {
> if( objects[idx] > 128 )
> return objects[idx];
> ++idx;
> }
> }
>
> // THE FUNCTION IS KEEPT EVEN WHEN IF RESULT IS NOT USED - ASM INSIDE LOOP
> CAUSING THE ISSUE
> inline uint64_t test_asm_inside_loop(uint64_t idx) {
> while(true)
> {
> uint64_t result;
> asm ("movq (%1,%2,8), %0" : "=r" (result) : "r" (objects), "r" (idx)
> );
> if( result > 128 )
> return result;
> ++idx;
> }
> }
>
> void init() {
> srand(time(nullptr));
> for( size_t i = 0; i < capacity - 1; ++i )
> objects[i] = random() % 256;
> objects[capacity-1] = 255;
> }
>
> // TETS THAT test_noasm AND test_asm_inside_loop PRODUCE SAME RESULT
> void sanity_test() {
> for( size_t i = 0; i < capacity; ++i ) {
> assert( test_noasm(i) == test_asm_inside_loop(i));
> }
> }
>
> void compile_test_noasm() {
> test_noasm(0);
> }
>
> void compile_test_noloop() {
> test_noloop(0);
> }
>
> void compile_test_asm_inside_loop() {
> test_asm_inside_loop(0);
> }
>
> int main( int argc, char* argv[] ) {
> init();
> sanity_test();
> compile_test_noasm();
> compile_test_noloop();
> compile_test_asm_inside_loop();
> }
>
> COMPILATION AND DISASSEMBLER RESULTS:
>
> /opt/rh/devtoolset-6//root/bin/g++ -O3 -funroll-loops
> loop_optimization.cpp; gdb -batch -ex "file a.out" -ex "disas
> compile_test_noasm" -ex "disas compile_test_noloop" -ex "disas
> compile_test_asm_inside_loop"
> Dump of assembler code for function _Z18compile_test_noasmv:
>0x00400970 <+0>: repz retq
> End of assembler dump.
> Dump of assembler code for function _Z19compile_test_noloopv:
>0x00400980 <+0>: repz retq
> End of assembler dump.
> Dump of assembler code for function _Z28compile_test_asm_inside_loopv:
>0x00400990 <+0>: xor%edx,%edx
>0x00400992 <+2>: mov$0x601080,%ecx
>0x00400997 <+7>: xor%eax,%eax
>0x00400999 <+9>: mov(%rcx,%rdx,8),%rsi
>0x0040099d <+13>:cmp$0x80,%rsi
>0x004009a4 <+20>:ja 0x4009c1
> <_Z28compile_test_asm_inside_loopv+49>
>0x004009a6 <+22>:nopw %cs:0x0(%rax,%rax,1)
>0x004009b0 <+32>:add$0x1,%rax
>0x004009b4 <+36>:mov(%rcx,%rax,8),%rdi
>0x004009b8 <+40>:cmp$0x80,%rdi
>0x004009bf <+47>:jbe0x4009b0
> <_Z28compile_test_asm_inside_loopv+32>
>0x004009c1 <+49>:repz retq
> End of assembler dump.
>
>
[Bug c++/82466] Missing warning for re-declaration of built-in function as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-07 Ever confirmed|0 |1
[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #20 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #19) > Created attachment 42320 [details] > patch which failes with dtio_14 and dtio_15, among others > > Well, this one doesn't work yet. Do you want to continue with it or would you like me to pick up from where you are?
[Bug c++/71973] c++ handles built-in functions inconsistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973 --- Comment #10 from Bernd Edlinger --- (In reply to Paolo Carlini from comment #9) > I see, maybe for clarity you could open a separate enhancement-type PR. Done: pr82466
[Bug c++/82466] New: Missing warning for re-declaration of built-in function as variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
Bug ID: 82466
Summary: Missing warning for re-declaration of built-in
function as variable
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
cat test.cc
int printf;
int
main()
{
__builtin_printf("%f\n", 3.14);
}
gcc -Wall -Wextra test.cc
./a.out
Segmentation fault (core dumped)
OTOH:
gcc -x c test.cc
test.cc:1:5: warning: built-in function 'printf' declared as non-function
int printf;
^~
So C++ should print a warning like C.
[Bug target/82465] New: vec_sqrt() for vector double erroneously fails for z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82465
Bug ID: 82465
Summary: vec_sqrt() for vector double erroneously fails for z13
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
The following code:
#include
int main() {
__vector double v = { 2.0, 1.0 };
__vector double prod = vec_sqrt(v);
}
works for z14 as expected, but fails on z13:
$ g++ -march=z13 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:6:35: error: '__vector(4) int
__builtin_s390_vec_sqrt(__vector(4) int)' requires z14 or higher
__vector double prod = vec_sqrt(v);
I think this is a bug.
[Bug c++/71973] c++ handles built-in functions inconsistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973 --- Comment #9 from Paolo Carlini --- I see, maybe for clarity you could open a separate enhancement-type PR.
[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #19 from Thomas Koenig --- Created attachment 42320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42320&action=edit patch which failes with dtio_14 and dtio_15, among others Well, this one doesn't work yet.
[Bug c++/71973] c++ handles built-in functions inconsistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973 --- Comment #8 from Bernd Edlinger --- Yes. fixed in 7.1.0 However, I wonder if I should do something when a variable is declared with the same name as a builtin function. Currently that aborts at runtime, but while C does warn, C++ does not warn.
[Bug c++/71973] c++ handles built-in functions inconsistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #7 from Paolo Carlini --- Then fixed in 7.1.0, right?
[Bug target/82420] ICE with -malign-int and -m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- I can reproduce the ICE with gcc-4.5 up to gcc-8.0, gcc-4.4.7 doesn't ICE.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 67878, which changed state. Bug 67878 Summary: [concepts] when processing a valid concept check, gcc errors trying to expand variadic in unrelated code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67878 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug c++/67878] [concepts] when processing a valid concept check, gcc errors trying to expand variadic in unrelated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67878 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Paolo Carlini --- I can't reproduce the issue with the released 6.1.0, neither with more recent releases.
[Bug target/81614] Should -mtune-ctrl=partial_reg_stall be turned by default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614 --- Comment #8 from Jan Hubicka --- I have tried the attached change at our periodic tester for haswell. It switches codegen to one similar for pentimpro (assuming that renaming happens on register parts as opposed to full registers). Relevant run is Oct 6, 2017 20:00 UTC of Czerny at https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/recent.html and https://gcc.opensuse.org/gcc-old/SPEC/CINT/sb-czerny-head-64-2006/recent.html It seems spec neutral. Because it models more closely what happens, perhaps changing it makes sense? Index: x86-tune.def === --- x86-tune.def(revision 253509) +++ x86-tune.def(working copy) @@ -48,7 +48,7 @@ over partial stores. For example preffer MOVZBL or MOVQ to load 8bit value over movb. */ DEF_TUNE (X86_TUNE_PARTIAL_REG_DEPENDENCY, "partial_reg_dependency", - m_P4_NOCONA | m_CORE_ALL | m_BONNELL | m_SILVERMONT | m_INTEL + m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_KNL | m_KNM | m_AMD_MULTIPLE | m_GENERIC) /* X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY: This knob promotes all store @@ -467,20 +467,20 @@ In current implementation the partial register stalls are not eliminated very well - they can be introduced via subregs synthesized by combine and can happen in caller/callee saving sequences. */ -DEF_TUNE (X86_TUNE_PARTIAL_REG_STALL, "partial_reg_stall", m_PPRO) +DEF_TUNE (X86_TUNE_PARTIAL_REG_STALL, "partial_reg_stall", m_PPRO | m_CORE_ALL | m_INTEL) /* X86_TUNE_PROMOTE_QIMODE: When it is cheap, turn 8bit arithmetic to corresponding 32bit arithmetic. */ DEF_TUNE (X86_TUNE_PROMOTE_QIMODE, "promote_qimode", - ~m_PPRO) + ~(m_PPRO | m_CORE_ALL | m_INTEL)) /* X86_TUNE_PROMOTE_HI_REGS: Same, but for 16bit artihmetic. Again we avoid partial register stalls on PentiumPro targets. */ -DEF_TUNE (X86_TUNE_PROMOTE_HI_REGS, "promote_hi_regs", m_PPRO) +DEF_TUNE (X86_TUNE_PROMOTE_HI_REGS, "promote_hi_regs", m_PPRO | m_CORE_ALL | m_INTEL) /* X86_TUNE_HIMODE_MATH: Enable use of 16bit arithmetic. On PPro this flag is meant to avoid partial register stalls. */ -DEF_TUNE (X86_TUNE_HIMODE_MATH, "himode_math", ~m_PPRO) +DEF_TUNE (X86_TUNE_HIMODE_MATH, "himode_math", ~(m_PPRO | m_CORE_ALL | m_INTEL)) /* X86_TUNE_SPLIT_LONG_MOVES: Avoid instructions moving immediates directly to memory. */
[Bug c++/68628] [concepts] ICE: segmentation fault in crash_signal, toplev.c:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-07 Ever confirmed|0 |1
[Bug c++/71397] array captured as nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71397 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.4 --- Comment #1 from Paolo Carlini --- Fixed a while ago, in 5.4.0.
[Bug c++/80805] ICE in sufficiently complex code with -g (dump_aggr_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80805 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #4 from Paolo Carlini --- Fixed in trunk.
[Bug c++/80805] ICE in sufficiently complex code with -g (dump_aggr_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80805 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Sat Oct 7 16:10:21 2017 New Revision: 253511 URL: https://gcc.gnu.org/viewcvs?rev=253511&root=gcc&view=rev Log: 2017-10-07 Paolo Carlini PR c++/80805 * g++.dg/cpp0x/pr80805.C: New. Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/80805] ICE in sufficiently complex code with -g (dump_aggr_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80805 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Sat Oct 7 16:10:02 2017 New Revision: 253510 URL: https://gcc.gnu.org/viewcvs?rev=253510&root=gcc&view=rev Log: 2017-10-07 Paolo Carlini PR c++/80805 * g++.dg/cpp0x/pr80805.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr80805.C
GCC does not optimize out functions without side effects with asm statements inside loop even if return velue is ignored
g++ (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3)
In the below case compile_test_asm_inside_loop invokes test_asm_inside_loop and
ignores results.
The call into test_asm_inside_loop is expected to be eliminated since return
value is not used and there is no side effect
The call elimination works fine without asm and without loop
It does not work with asm inside loop
TEST CODE
#include
#include
using namespace std;
constexpr static size_t capacity = 1024;
uint64_t objects[capacity];
// THE FUNCTION IS ELIMINATED BY COMPILER IF OUTPUT IS NOT USED
inline uint64_t test_noloop(uint64_t idx) {
uint64_t result;
asm ("movq (%1,%2,8), %0" : "=r" (result) : "r" (objects), "r" (idx) );
if( result > 128 )
return result;
return 0;
}
// THE FUNCTION IS ELIMINATED BY COMPILER IF OUTPUT IS NOT USED
inline uint64_t test_noasm(uint64_t idx) {
while(true)
{
if( objects[idx] > 128 )
return objects[idx];
++idx;
}
}
// THE FUNCTION IS KEEPT EVEN WHEN IF RESULT IS NOT USED - ASM INSIDE LOOP
CAUSING THE ISSUE
inline uint64_t test_asm_inside_loop(uint64_t idx) {
while(true)
{
uint64_t result;
asm ("movq (%1,%2,8), %0" : "=r" (result) : "r" (objects), "r" (idx) );
if( result > 128 )
return result;
++idx;
}
}
void init() {
srand(time(nullptr));
for( size_t i = 0; i < capacity - 1; ++i )
objects[i] = random() % 256;
objects[capacity-1] = 255;
}
// TETS THAT test_noasm AND test_asm_inside_loop PRODUCE SAME RESULT
void sanity_test() {
for( size_t i = 0; i < capacity; ++i ) {
assert( test_noasm(i) == test_asm_inside_loop(i));
}
}
void compile_test_noasm() {
test_noasm(0);
}
void compile_test_noloop() {
test_noloop(0);
}
void compile_test_asm_inside_loop() {
test_asm_inside_loop(0);
}
int main( int argc, char* argv[] ) {
init();
sanity_test();
compile_test_noasm();
compile_test_noloop();
compile_test_asm_inside_loop();
}
COMPILATION AND DISASSEMBLER RESULTS:
/opt/rh/devtoolset-6//root/bin/g++ -O3 -funroll-loops loop_optimization.cpp;
gdb -batch -ex "file a.out" -ex "disas compile_test_noasm" -ex "disas
compile_test_noloop" -ex "disas compile_test_asm_inside_loop"
Dump of assembler code for function _Z18compile_test_noasmv:
0x00400970 <+0>: repz retq
End of assembler dump.
Dump of assembler code for function _Z19compile_test_noloopv:
0x00400980 <+0>: repz retq
End of assembler dump.
Dump of assembler code for function _Z28compile_test_asm_inside_loopv:
0x00400990 <+0>: xor%edx,%edx
0x00400992 <+2>: mov$0x601080,%ecx
0x00400997 <+7>: xor%eax,%eax
0x00400999 <+9>: mov(%rcx,%rdx,8),%rsi
0x0040099d <+13>:cmp$0x80,%rsi
0x004009a4 <+20>:ja 0x4009c1
<_Z28compile_test_asm_inside_loopv+49>
0x004009a6 <+22>:nopw %cs:0x0(%rax,%rax,1)
0x004009b0 <+32>:add$0x1,%rax
0x004009b4 <+36>:mov(%rcx,%rax,8),%rdi
0x004009b8 <+40>:cmp$0x80,%rdi
0x004009bf <+47>:jbe0x4009b0
<_Z28compile_test_asm_inside_loopv+32>
0x004009c1 <+49>:repz retq
End of assembler dump.
[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #18 from Dominique d'Humieres --- I do not see any timing difference between 7.2.1 (r253502) and trunk.
[Bug c++/82461] [7/8 Regression] Temporary required for brace-initializing (non-literal-type) member variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.3 Summary|Temporary required for |[7/8 Regression] Temporary |brace-initializing |required for |(non-literal-type) member |brace-initializing |variable|(non-literal-type) member ||variable --- Comment #1 from Jakub Jelinek --- Started with r240889.
[Bug target/79709] Subobtimal code with -mavx and explicit vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79709 --- Comment #9 from Thomas Koenig --- The generated code for the loop seems to be on par with what clang and icc do, so that part is fixed. Initialization is strange for icc. For clang, it really quite short: foo:# @foo .cfi_startproc # BB#0: vxorps %ymm2, %ymm2, %ymm2 vmovapd .LCPI0_0(%rip), %ymm8 # ymm8 = [4.00e+00,4.00e+00,4.00e+00,4.00e+00] vmovapd %ymm1, %ymm4 vmovapd %ymm0, %ymm5 .p2align4, 0x90 .LBB0_1:# =>This I vs. gcc: foo: .LFB0: .cfi_startproc vmovsd .LC0(%rip), %xmm2 vmovapd %ymm1, %ymm7 vpxor %xmm5, %xmm5, %xmm5 vmovq %xmm2, %xmm9 vmulpd %ymm1, %ymm1, %ymm10 vmovapd %xmm9, %xmm9 vunpcklpd %xmm2, %xmm9, %xmm3 vinsertf128 $0x0, %xmm3, %ymm9, %ymm9 vextractf128$0x1, %ymm9, %xmm3 vmovsd %xmm2, %xmm3, %xmm3 vinsertf128 $0x1, %xmm3, %ymm9, %ymm9 vextractf128$0x1, %ymm9, %xmm3 vunpcklpd %xmm2, %xmm3, %xmm3 vmovsd .LC1(%rip), %xmm2 vmovq %xmm2, %xmm8 vinsertf128 $0x1, %xmm3, %ymm9, %ymm9 vmovapd %xmm8, %xmm8 vunpcklpd %xmm2, %xmm8, %xmm3 vinsertf128 $0x0, %xmm3, %ymm8, %ymm8 vextractf128$0x1, %ymm8, %xmm3 vmovsd %xmm2, %xmm3, %xmm3 vinsertf128 $0x1, %xmm3, %ymm8, %ymm8 vextractf128$0x1, %ymm8, %xmm3 vunpcklpd %xmm2, %xmm3, %xmm3 vinsertf128 $0x1, %xmm3, %ymm8, %ymm8 vmovapd %ymm0, %ymm3 jmp .L3 .p2align 4,,10 .p2align 3 .L13:
[Bug c++/50518] [C++0x] repeated c++11 opaque enum declarations are invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW CC||fabien at gcc dot gnu.org Assignee|fabien at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from fabien at gcc dot gnu.org --- Hi paolo, not for the foreseeable future unfortunately.
[Bug c++/82461] Temporary required for brace-initializing (non-literal-type) member variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-07 Ever confirmed|0 |1
[Bug fortran/68546] passing non-contiguous associated array section garbles results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68546 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #4 from Thomas Koenig --- (In reply to Thomas Koenig from comment #3) > Actually, the problem is in the program. We should warn about > this, but not repack. > > See https://gcc.gnu.org/ml/fortran/2017-08/msg00055.html > (but I didn't do the part with the arguments there). No, it's not, this is in fact an associate problem. Unassigning.
[Bug target/82464] s390x z14: vector float: invalid parameter combination for intrinsic '__builtin_s390_vec_xor'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
I think:
--- gcc/config/s390/s390-builtins.def.jj2017-10-06 11:25:44.0
+0200
+++ gcc/config/s390/s390-builtins.def 2017-10-07 13:47:34.851529686 +0200
@@ -1621,6 +1621,9 @@ OB_DEF_VAR (s390_vec_xor_s64_c,
OB_DEF_VAR (s390_vec_xor_u64_a, s390_vx,B_DEP,
0, BT_OV_UV2DI_BV2DI_UV2DI)
OB_DEF_VAR (s390_vec_xor_u64_b, s390_vx,0,
0, BT_OV_UV2DI_UV2DI_UV2DI)
OB_DEF_VAR (s390_vec_xor_u64_c, s390_vx,B_DEP,
0, BT_OV_UV2DI_UV2DI_BV2DI)
+OB_DEF_VAR (s390_vec_xor_flt_a, s390_vx,B_VXE | B_DEP,
0, BT_OV_V4SF_BV4SI_V4SF)
+OB_DEF_VAR (s390_vec_xor_flt_b, s390_vx,B_VXE,
0, BT_OV_V4SF_V4SF_V4SF)
+OB_DEF_VAR (s390_vec_xor_flt_c, s390_vx,B_VXE | B_DEP,
0, BT_OV_V4SF_V4SF_BV4SI)
OB_DEF_VAR (s390_vec_xor_dbl_a, s390_vx,B_DEP,
0, BT_OV_V2DF_BV2DI_V2DF)
OB_DEF_VAR (s390_vec_xor_dbl_b, s390_vx,0,
0, BT_OV_V2DF_V2DF_V2DF)
OB_DEF_VAR (s390_vec_xor_dbl_c, s390_vx,B_DEP,
0, BT_OV_V2DF_V2DF_BV2DI)
ought to fix it. I'm just don't see any vec_{and,or,xor} tests in the
testsuite, so dunno where to add test for this.
[Bug fortran/49232] Pointer assignment of stride to CONTIGUOUS pointer not diagnosed as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Koenig --- Fixed.
[Bug fortran/49232] Pointer assignment of stride to CONTIGUOUS pointer not diagnosed as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232 --- Comment #3 from Thomas Koenig --- Author: tkoenig Date: Sat Oct 7 11:48:28 2017 New Revision: 253509 URL: https://gcc.gnu.org/viewcvs?rev=253509&root=gcc&view=rev Log: 2017-10-07 Thomas Koenig PR fortran/49232 * expr.c (gfc_check_pointer_assign): Error for non-contiguous rhs. 2017-10-07 Thomas Koenig PR fortran/49232 * gfortran.dg/contiguous_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/contiguous_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #17 from Thomas Koenig --- I mean apart from the fact that this creates a huge memory leak :-)
[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #16 from Thomas Koenig ---
Jerry,
what do you think of this approach? This creates a local copy
of the gfc_unit, without putting it into the tree.
Index: transfer.c
===
--- transfer.c (Revision 253377)
+++ transfer.c (Arbeitskopie)
@@ -4170,6 +4170,9 @@ st_write_done (st_parameter_dt *dtp)
}
unlock_unit (dtp->u.p.current_unit);
}
+ if (is_internal_unit (dtp))
+free (dtp->u.p.current_unit);
+
library_end ();
}
Index: unit.c
===
--- unit.c (Revision 253377)
+++ unit.c (Arbeitskopie)
@@ -225,7 +225,7 @@ insert (gfc_unit *new, gfc_unit *t)
/* insert_unit()-- Create a new node, insert it into the treap. */
static gfc_unit *
-insert_unit (int n)
+insert_unit (int n, int internal)
{
gfc_unit *u = xcalloc (1, sizeof (gfc_unit));
u->unit_number = n;
@@ -238,8 +238,11 @@ static gfc_unit *
__GTHREAD_MUTEX_INIT_FUNCTION (&u->lock);
#endif
__gthread_mutex_lock (&u->lock);
- u->priority = pseudo_random ();
- unit_root = insert (u, unit_root);
+ if (!internal)
+{
+ u->priority = pseudo_random ();
+ unit_root = insert (u, unit_root);
+}
return u;
}
@@ -316,14 +319,21 @@ delete_unit (gfc_unit *old)
/* get_gfc_unit()-- Given an integer, return a pointer to the unit
structure. Returns NULL if the unit does not exist,
- otherwise returns a locked unit. */
+ otherwise returns a locked unit. If internal, do not put it
+ in the unit cache. */
static gfc_unit *
-get_gfc_unit (int n, int do_create)
+get_gfc_unit (int n, int do_create, int internal)
{
gfc_unit *p;
int c, created = 0;
+ if (internal)
+{
+ p = insert_unit (n, 1);
+ return p;
+}
+
__gthread_mutex_lock (&unit_lock);
retry:
for (c = 0; c < CACHE_SIZE; c++)
@@ -347,7 +357,7 @@ retry:
if (p == NULL && do_create)
{
- p = insert_unit (n);
+ p = insert_unit (n, 0);
created = 1;
}
@@ -405,7 +415,7 @@ found:
gfc_unit *
find_unit (int n)
{
- return get_gfc_unit (n, 0);
+ return get_gfc_unit (n, 0, 0);
}
@@ -412,7 +422,7 @@ find_unit (int n)
gfc_unit *
find_or_create_unit (int n)
{
- return get_gfc_unit (n, 1);
+ return get_gfc_unit (n, 1, 0);
}
@@ -548,7 +558,7 @@ get_unit (st_parameter_dt *dtp, int do_create)
dtp->u.p.unit_is_internal = 1;
dtp->common.unit = newunit_alloc ();
- unit = get_gfc_unit (dtp->common.unit, do_create);
+ unit = get_gfc_unit (dtp->common.unit, do_create, 1);
set_internal_unit (dtp, unit, kind);
fbuf_init (unit, 128);
return unit;
@@ -563,9 +573,9 @@ get_unit (st_parameter_dt *dtp, int do_create)
is not allowed, such units must be created with
OPEN(NEWUNIT=...). */
if (dtp->common.unit < 0)
-return get_gfc_unit (dtp->common.unit, 0);
+return get_gfc_unit (dtp->common.unit, 0, 0);
- return get_gfc_unit (dtp->common.unit, do_create);
+ return get_gfc_unit (dtp->common.unit, do_create, 0);
}
@@ -592,7 +602,7 @@ init_units (void)
if (options.stdin_unit >= 0)
{ /* STDIN */
- u = insert_unit (options.stdin_unit);
+ u = insert_unit (options.stdin_unit, 0);
u->s = input_stream ();
u->flags.action = ACTION_READ;
@@ -624,7 +634,7 @@ init_units (void)
if (options.stdout_unit >= 0)
{ /* STDOUT */
- u = insert_unit (options.stdout_unit);
+ u = insert_unit (options.stdout_unit, 0);
u->s = output_stream ();
u->flags.action = ACTION_WRITE;
@@ -655,7 +665,7 @@ init_units (void)
if (options.stderr_unit >= 0)
{ /* STDERR */
- u = insert_unit (options.stderr_unit);
+ u = insert_unit (options.stderr_unit, 0);
u->s = error_stream ();
u->flags.action = ACTION_WRITE;
[Bug target/82462] New: vec_madd does not map to __builtin_s390_vfmasb for z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82462
Bug ID: 82462
Summary: vec_madd does not map to __builtin_s390_vfmasb for z14
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
Trying to compile the simple test case breaks:
#include
typedef __vector float Packet4f;
int main() {
Packet4f v1 = { 1.0, -1.0, -2.0, 2.0 };
Packet4f v2 = { 2.0, 0.5, 0.1, 0.2 };
Packet4f v0 = { 0.0, 0.0, 0.0, 0.0 };
Packet4f prod = vec_madd(v1, v2, v0);
}
g++ -march=z14 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:10:37: error: cannot convert 'Packet4f {aka __vector(4)
float}' to '__vector(2) double' for argument '1' to '__vector(2) double
__builtin_s390_vfmadb(__vector(2) double, __vector(2) double, __vector(2)
double)'
Packet4f prod = vec_madd(v1, v2, v0);
Changing to __builtin_s390_vfmasb explicitly seems to work.
--- Comment #1 from Konstantinos Margaritis ---
*** Bug 82463 has been marked as a duplicate of this bug. ***
[Bug target/82463] vec_madd does not map to __builtin_s390_vfmasb for z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82463 Konstantinos Margaritis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Konstantinos Margaritis --- accidentally pressed submit twice, duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82462 *** This bug has been marked as a duplicate of bug 82462 ***
[Bug target/82464] New: s390x z14: vector float: invalid parameter combination for intrinsic '__builtin_s390_vec_xor'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464
Bug ID: 82464
Summary: s390x z14: vector float: invalid parameter combination
for intrinsic '__builtin_s390_vec_xor'
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
In this small testcase:
#include
typedef __vector float Packet4f;
int main() {
Packet4f v1 = { 1.0, -1.0, -2.0, 2.0 };
Packet4f v2 = { 2.0, 0.5, 0.1, 0.2 };
Packet4f prod = vec_xor(v1, v2);
}
$ g++ -march=z14 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:9:32: error: invalid parameter combination for intrinsic
'__builtin_s390_vec_xor'
Packet4f prod = vec_xor(v1, v2);
However it works with vec_or() intrinsic and others (vec_and, etc), I guess
it's just an ommission.
[Bug target/82463] New: vec_madd does not map to __builtin_s390_vfmasb for z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82463
Bug ID: 82463
Summary: vec_madd does not map to __builtin_s390_vfmasb for z14
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
Trying to compile the simple test case breaks:
#include
typedef __vector float Packet4f;
int main() {
Packet4f v1 = { 1.0, -1.0, -2.0, 2.0 };
Packet4f v2 = { 2.0, 0.5, 0.1, 0.2 };
Packet4f v0 = { 0.0, 0.0, 0.0, 0.0 };
Packet4f prod = vec_madd(v1, v2, v0);
}
g++ -march=z14 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:10:37: error: cannot convert 'Packet4f {aka __vector(4)
float}' to '__vector(2) double' for argument '1' to '__vector(2) double
__builtin_s390_vfmadb(__vector(2) double, __vector(2) double, __vector(2)
double)'
Packet4f prod = vec_madd(v1, v2, v0);
Changing to __builtin_s390_vfmasb explicitly seems to work.
[Bug target/82317] [8 Regression] "'__builtin_s390_vec_min' matching variant requires z14 or higher" for __vector(2) double when it should work on -march=z13 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82317 Konstantinos Margaritis changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Konstantinos Margaritis --- Confirmed that the bug is fixed.
[Bug target/82322] [7/8 Regression] vec_ceil/vec_floor/vec_round intrincics do not work for gcc 8, need __builtin_s390_vfidb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82322 Konstantinos Margaritis changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Konstantinos Margaritis --- Confirmed that the bug is fixed.
[Bug c++/82461] New: Temporary required for brace-initializing (non-literal-type) member variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
Bug ID: 82461
Summary: Temporary required for brace-initializing
(non-literal-type) member variable
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tvb377 at gmx dot de
Target Milestone: ---
class A {
private:
public:
constexpr A() {}
~A() {}
};
class B {
private:
A a;
public:
constexpr B() : a{} {}
// works also with g++ -std=c++17:
// constexpr B() : a() {}
~B() {}
};
When compiling this with -std=c++17 g++ reports:
error: temporary of non-literal type ‘A’ in a constant expression
note: ‘A’ has a non-trivial destructor
With -std=c++11 and 14 g++ accepts this code as do clang 5.0 and MS cl 19.11
