[Bug tree-optimization/81053] New: ICE on valid code at -O3 on x86_64-linux-gnu: in as_a, at is-a.h:192

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81053

Bug ID: 81053
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in as_a,
at is-a.h:192
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170611 (experimental) [trunk revision 249102] (GCC)
$
$ gcc-trunk -O2 -c small.c
$
$ gcc-trunk -O3 -c small.c
during GIMPLE pass: vect
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: in as_a, at is-a.h:192
 void fn1 ()
  ^~~
0xea8397 as_a
../../gcc-source-trunk/gcc/is-a.h:192
0xeb2469 as_a
../../gcc-source-trunk/gcc/vec.h:860
0xeb2469 gimple_phi_result_ptr
../../gcc-source-trunk/gcc/gimple.h:4322
0xeb2469 vect_is_simple_reduction
../../gcc-source-trunk/gcc/tree-vect-loop.c:2743
0xeb2469 vect_force_simple_reduction(_loop_vec_info*, gimple*, bool*, bool)
../../gcc-source-trunk/gcc/tree-vect-loop.c:3188
0xeb2ddb vect_analyze_scalar_cycles_1
../../gcc-source-trunk/gcc/tree-vect-loop.c:858
0xeb7eea vect_analyze_scalar_cycles
../../gcc-source-trunk/gcc/tree-vect-loop.c:932
0xeb7eea vect_analyze_loop_2
../../gcc-source-trunk/gcc/tree-vect-loop.c:1924
0xeb7eea vect_analyze_loop(loop*, _loop_vec_info*)
../../gcc-source-trunk/gcc/tree-vect-loop.c:2403
0xed0009 vectorize_loops()
../../gcc-source-trunk/gcc/tree-vectorizer.c:614
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


---


int a, b[2], c, d;

void fn1 ()
{ 
  for (; d < 2; d++)
{ 
  b[d] = a;
  a = c;
}
}

[Bug c++/81052] New: ICE in verify_dominators, at dominance.c:1184

[ryan.burn at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81052

Bug ID: 81052
   Summary: ICE in verify_dominators, at dominance.c:1184
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Created attachment 41535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41535=edit
preprocessed code

Using gcc:
g++ (GCC) 8.0.0 20170610 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Running
g++ -std=c++1z -fconcepts -fopenmp-simd ice.cpp
with the attached file produces this ICE:

/Users/rnickb/proj/satyr/include/satyr/serial_for.h:40:6: error: dominator of
10 should be 11, not 2
 bool for_with_cancel(Policy policy, index_t first, index_t last, F f) {
  ^~~
during GIMPLE pass: ompexp
/Users/rnickb/proj/satyr/include/satyr/serial_for.h:40:6: internal compiler
error: in verify_dominators, at dominance.c:1184

during GIMPLE pass: ompexp
/Users/rnickb/proj/satyr/include/satyr/serial_for.h:40:6: internal compiler
error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug other/81041] [8 regression] test case gcc.dg/pr78582.c fails with ICE starting with r249058

[paul.hua.gm at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81041

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #1 from Paul Hua  ---
saw this ICE on mips64el target as well.

[Bug c++/58820] lambda multiple inheritance operator() not ambiguous

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58820

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
This should be closed as invalid. The lookup for `operator()` is indeed
ambiguous, (see [class.member.lookup]/6 - the merge produces an invalid set),
and GCC correctly reports it as such.

In the absence of using-declarations, names from different base classes don't
overload.

[Bug c++/81051] New: lambda capture of this in initialization list with virtual inheritance

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81051

Bug ID: 81051
   Summary: lambda capture of this in initialization list with
virtual inheritance
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

[Reported on Stackoverflow
https://stackoverflow.com/questions/43748646/gcc-bug-with-lambda-capture-of-this-in-initialization-list-with-virtual-inherita]

The following code segfaults under gcc-4.9, 5.4, and 6.3 with std=c++11, but
compiles and runs fine under clang-3.7, and VS2015 Update 3.

C++14 12.7.3 is fairly explicit that this should be allowed.

struct A
{
int Func() { return x++; }
int x = 5;
};

struct B
{
B(int) {}
};

struct Derived : public virtual A, public B
{
Derived()
  : A()
  // , B(this->Func()) // This works!
  , B([this](){ return this->Func(); }()) // But this segfaults.
{
}
};

int main()
{
Derived c;
}

[Bug c/81050] New: ICE with -fexec-charset=utf-16

[gerald at pfeifer dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81050

Bug ID: 81050
   Summary: ICE with -fexec-charset=utf-16
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerald at pfeifer dot com
  Target Milestone: ---

Compiling

 #include 
 int main()
 {
   char a = 'a';
   printf("Size of char : %d\n",sizeof(a));
   printf("Size of char : %d\n",sizeof('a'));
   return 0;
 }

with   gcc x.c -o x -fexec-charset=utf-16   results in

x.c: In function ‘main’:
x.c:4:16: warning: multi-character character constant [-Wmultichar]
   char a = 'a';
^~~
x.c:4:16: warning: overflow in implicit constant conversion [-Woverflow]
x.c:6:43: warning: multi-character character constant [-Wmultichar]
   printf("Size of char : %d\n",sizeof('a'));
   ^~~
x.c:8:0: internal compiler error: character 0xa is not unibyte in execution
character set
 }

This has two issues:

 1. The ICE.

 2. The trailing } on a line of its own.

This is with GCC 7.1.1 on x86_64-suse-linux; similarly was reported with
GCC 5.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

[doug.gilmore at imgtec dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

--- Comment #9 from Doug Gilmore  ---
> I bet this is a bug in reorg.c.  It is the least used code (major
> target usage: MIPS and sparc only) and also one of the more buggy
> code.
You're right, compiling with -fno-delayed-branch doesn't tickle the bug.

Thanks!

[Bug target/25967] Add attribute naked for x86

[anatol.pomozov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25967

Anatol  changed:

   What|Removed |Added

 CC||anatol.pomozov at gmail dot com

--- Comment #11 from Anatol  ---
I need this feature in my project as well. And I was surprised to find this old
feature request that has not been resolved yet. Is there any chance to see
__naked__ implemented for x86?

As it turned out clang supports __naked__ attribute at x86. So we switched from
GCC to CLANG as our main compiler. But I would really love to see GCC as an
option for our project.

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[paul.richard.thomas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640

--- Comment #31 from paul.richard.thomas at gmail dot com  ---
Hi Dominique,

I had suspected that. Thanks for the confirmation!

Cheers

Paul

On 10 June 2017 at 18:46, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
>
> --- Comment #30 from Dominique d'Humieres  ---
>> Le 10 juin 2017 à 19:40, pault at gcc dot gnu.org  
>> a écrit :
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
>>
>> --- Comment #29 from Paul Thomas  ---
>> Created attachment 41534
>>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41534=edit
>> An unpolished patch for the bug
>>
>> Dear All,
>>
>> Since I am not going to have any time to fix the array descriptor reform on
>> fortran-dev anytime soon, I have developed the attached. An extra 'span' 
>> field
>> has been added to the array descriptor, which is used for non-OOP pointer
>> operations.
>>
>> It needs a lot of cleaning up and thorough testing. It passes the regtests
>> except for: goacc/kernels-alias-4.f95; and graphite/pr14741.f90
>
> The failure of graphite/pr14741.f90 is  not related to your patch.
>
> Dominique
>
>> I can see why the former might fail but the latter has me completely 
>> flummoxed.
>>
>> One of the most important parts of the cleanup will be to rework
>> trans.c:gfc_build_array_ref and some of the calls to it.I should include 
>> class
>> pointers in the scheme as well, just for completeness.
>>
>> Any feedback that you can give me would gratefully received. Let's at least
>> finally implement this last missing F95 feature.
>>
>> Cheers
>>
>> Paul
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640

--- Comment #30 from Dominique d'Humieres  ---
> Le 10 juin 2017 à 19:40, pault at gcc dot gnu.org  
> a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
> 
> --- Comment #29 from Paul Thomas  ---
> Created attachment 41534
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41534=edit
> An unpolished patch for the bug
> 
> Dear All,
> 
> Since I am not going to have any time to fix the array descriptor reform on
> fortran-dev anytime soon, I have developed the attached. An extra 'span' field
> has been added to the array descriptor, which is used for non-OOP pointer
> operations.
> 
> It needs a lot of cleaning up and thorough testing. It passes the regtests 
> except for: goacc/kernels-alias-4.f95; and graphite/pr14741.f90

The failure of graphite/pr14741.f90 is  not related to your patch.

Dominique

> I can see why the former might fail but the latter has me completely 
> flummoxed.
> 
> One of the most important parts of the cleanup will be to rework
> trans.c:gfc_build_array_ref and some of the calls to it.I should include class
> pointers in the scheme as well, just for completeness.
> 
> Any feedback that you can give me would gratefully received. Let's at least
> finally implement this last missing F95 feature.
> 
> Cheers
> 
> Paul
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640

--- Comment #29 from Paul Thomas  ---
Created attachment 41534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41534=edit
An unpolished patch for the bug

Dear All,

Since I am not going to have any time to fix the array descriptor reform on
fortran-dev anytime soon, I have developed the attached. An extra 'span' field
has been added to the array descriptor, which is used for non-OOP pointer
operations.

It needs a lot of cleaning up and thorough testing. It passes the regtests 
except for: goacc/kernels-alias-4.f95; and graphite/pr14741.f90

I can see why the former might fail but the latter has me completely flummoxed.

One of the most important parts of the cleanup will be to rework
trans.c:gfc_build_array_ref and some of the calls to it.I should include class
pointers in the scheme as well, just for completeness.

Any feedback that you can give me would gratefully received. Let's at least
finally implement this last missing F95 feature.

Cheers

Paul

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[8 Regression] Bootstrap|[8 Regression] Revision
   |broken on darwin|r249019 breaks bootstrap on
   ||darwin

--- Comment #4 from Dominique d'Humieres  ---
I bootstrap again if I revert revision r249019.

The following patch 

--- ../_clean/gcc/config/darwin.c   2017-01-01 17:39:06.0 +0100
+++ gcc/config/darwin.c 2017-06-10 17:19:31.0 +0200
@@ -3170,6 +3170,16 @@ darwin_override_options (void)
   flag_reorder_blocks = 1;
 }

+  /* Disable -freorder-blocks-and-partition when -fprofile-use is not in
+ effect. Function splitting was not actually being performed in that case,
+ as probably_never_executed_bb_p does not distinguish any basic blocks as
+ being cold vs hot when there is no profile data. Leaving it enabled,
+ however, causes the assembly code generator to create (empty) cold
+ sections and labels, leading to unnecessary size overhead.  */
+  if (global_options_set.x_flag_reorder_blocks_and_partition
+  && !global_options_set.x_flag_profile_use)
+flag_reorder_blocks_and_partition = 0;
+
 /* FIXME: flag_objc_sjlj_exceptions is no longer needed since there is
only
one valid choice of exception scheme for each runtime.  */
 if (!global_options_set.x_flag_objc_sjlj_exceptions)

fixes bootstrap.

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[walt.brainerd at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #12 from Walt Brainerd  ---
I made a misstatement in my previous message.
gfortran 7.0.1 does not accept this.

Sorry, my "test" was not correct.

I am going to post a query to comp-fortran-90 to see what others think.

On Fri, Jun 9, 2017 at 12:08 PM, Walt Brainerd 
wrote:

> I am not sure what you changed your mind from or to :-).
>
> Yes, the assignment is invalid because r is real the the rhs is type
> B_type.
>
> And, yes, the type of the io list item is B_type.
>
> However, the uncommented WRITE statement is valid, and,
> in the absence or a DT edit descriptor, the components (one real) are
> written in order, so 20.0 is written with f4.1 format.
>
> ifort 2017 and gfortran 7.01. both agree with this (maybe the latter
> because of you).
>
> If you disagree with this, I would be happy to solicit opinions from more
> experts.
>
> On Thu, Jun 8, 2017 at 10:05 PM, jvdelisle at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>>
>> --- Comment #10 from Jerry DeLisle  ---
>> After a lot of head scratching I think I am changing my mind on this one.
>>
>> If one tries to assign to a real variable as in:
>>
>> program test_b_write_dt_mod
>>
>>use :: B_write_dt_mod
>>implicit none
>>
>>type(B_type) :: x != B_type(20.0)
>>real :: r
>>
>>r = B_type(20.0)
>>
>>write (unit=*, fmt="(f4.1)") B_type(20.0)
>>!write (unit=*, fmt="(f4.1)") x
>>
>> end program test_b_write_dt_mod
>>
>> The effective item is of type B_type not real and the assignment to r is
>> rejected.
>>
>> So I believe the effective type in the write statement is likewise
>> derived type
>> ad not real.
>>
>> My thinking is this PR is invalid.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>
>
>
>
> --
> Walt Brainerd
>

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80949

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> 
> I'll leave the debug session open; let me know if you need any more info...

Never mind, I closed the debugger, but can reopen it if necessary. Here's an
even fuller backtrace I got before closing it:

(gdb) bt full
#0  0x00135430 in do_warn_duplicated_branches (expr=0x560ba10) at
../../gcc/c-family/c-warn.c:2362
thenb = (tree) 0x0
elseb = (tree) 0x55e7f80
hstate0 = {
  val = 1132540324, 
  bits = 509
}
h0 = 3221187736
hstate1 = {
  val = 233, 
  bits = 439
}
h1 = 342339
#1  0x001355ff in do_warn_duplicated_branches_r (tp=0x55fdaa0) at
../../gcc/c-family/c-warn.c:2401
No locals.
#2  0x01751efd in walk_tree_1 (tp=0x55fdaa0, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11838
code = 479
walk_subtrees = 1
result = (tree) 0x4381320c
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#3  0x017522a2 in walk_tree_1 (tp=0x56149a4, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
i = {
  ptr = 0x55fda98, 
  container = 0x5612a3c
}
code = STATEMENT_LIST
walk_subtrees = 1
result = (tree) 0x0
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#4  0x017522a2 in walk_tree_1 (tp=0x560b960, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
i = {
  ptr = 0x55fda5c, 
  container = 0x561226c
}
code = STATEMENT_LIST
walk_subtrees = 1
result = (tree) 0x0
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#5  0x017522a2 in walk_tree_1 (tp=0x560ba5c, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
i = {
  ptr = 0x55fdab0, 
  container = 0x560c190
}
code = STATEMENT_LIST
walk_subtrees = 1
result = (tree) 0x0
   
_ZZ11walk_tree_1PP9tree_nodePFS0_S1_PiPvES3_P8hash_setIS0_19default_hash_traitsIS0_EEPFS0_S1_S2_S5_S3_SA_EE12__FUNCTION__
= "walk_tree_1"
#6  0x01751b3b in walk_tree_without_duplicates_1 (tp=0x53a7bec, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, lh=0) at
../../gcc/tree.c:12181
result = (tree) 0x437d2490
pset = {
  m_table = {
m_entries = 0x43812e00, 
m_size = 509, 
m_n_elements = 230, 
m_n_deleted = 0, 
m_searches = 361, 
m_collisions = 299, 
m_size_prime_index = 6, 
m_ggc = false, 
m_gather_mem_stats = false
  }
}
#7  0x001091ba in c_genericize (fndecl=0x53a7b80) at
../../gcc/c-family/c-gimplify.c:129
dump_orig = (FILE *) 0x53a7b80
local_dump_flags = 0
cgn = (cgraph_node *) 0x6
#8  0x0003f382 in finish_function () at ../../gcc/c/c-decl.c:9350
fndecl = (tree) 0x53a7b80
#9  0x00081370 in c_parser_declaration_or_fndef (parser=0x436a60a8,
fndef_ok=true, static_assert_ok=true, empty_ok=true, nested=false,
start_attr_ok=true, objc_foreach_object_declaration=0x0,
omp_declare_simd_clauses={m_vec = 0x0}, oacc_routine_data=0x0,
fallthru_attr_p=0x0) at ../../gcc/c/c-parser.c:2147
tv = TV_PARSE_FUNC
fnbody = (tree) 0x560ba48
fndecl = (tree) 0x53a7b80
declarator = (c_declarator *) 0x434b81a0
dummy = true
at = {
  m_timer = 0x0, 
  m_tv = TV_PARSE_FUNC
}
specs = (c_declspecs *) 0x434b8010
prefix_attrs = (tree) 0x0
all_prefix_attrs = (tree) 0x0
diagnosed_no_specs = false
here = 2147688185
auto_type_p = false
#10 0x000ab4fd in c_parser_external_declaration (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1469
ext = 1291845632
_ZZL29c_parser_external_declarationP8c_parserE12__FUNCTION__ =
"c_parser_external_declaration"
#11 0x000ab650 in c_parser_translation_unit (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1349
obstack_position = (void *) 0x434b8010
i = 3221189208
decl = (tree) 0xbfff794c
#12 0x000ab7ca in c_parse_file () at ../../gcc/c/c-parser.c:18112
tparser = {
  tokens = 0xbfff7274, 
  tokens_buf = {{
  type = CPP_KEYWORD, 
  id_kind = C_ID_NONE, 
  keyword = RID_TYPEDEF, 
  pragma_kind = PRAGMA_NONE, 
  location = 57329990, 
  value = 0x43618990, 
  flags = 64 '@'
}, {
  type = CPP_EQ, 
  id_kind = C_ID_ID, 
  keyword = RID_STATIC, 
  pragma_kind = PRAGMA_NONE, 
  location = 0, 
  value = 0x0, 
  flags = 0 '\0'
}, {
  type = 

[Bug web/80941] Broken bookmarks on GCC internals PDF available online

[sebastian.peryt at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80941

Sebastian Peryt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Sebastian Peryt  ---
Looking at the current version of GCC Internals available online, it looks like
the issue has been fixed.

[Bug c++/81045] [7 Regression] return type deduction causes dependent types?

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81045

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
(In reply to Andrew Pinski from comment #1)
> Somehow GCC is deciding that easyObjects->begin() and end() are dependent
> types so you need to use the template keyword for the call to cast.
> 
> That is:
> auto casted = obj.template cast();
> 
> I don't know if GCC is correct here or not.

It looks like a GCC bug to me, because easyObjects is a non-dependent
expression and the specification of the range-for loop doesn't result in a
dependent expression of obj given the participating begin()/end() members.

It should be noted that the demo code is broken, because it incorrectly
attempts to bind an rvalue (The result of vector<>::get) to an lvalue
reference, but that is another story.

[Bug fortran/52473] CSHIFT slow - inline it?

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473

--- Comment #9 from Dominique d'Humieres  ---
> How often or how important is this feature? Would it improve any known
> benchmark or real world application in a significant manner?

Egg and chicken problem! If CSHIFT is slow, nobody will use it. If nobody use
it, nobody will be motivated to make it fast.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759

Daniel Santos  changed:

   What|Removed |Added

  Attachment #41532|0   |1
is obsolete||

--- Comment #32 from Daniel Santos  ---
Created attachment 41533
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41533=edit
41532: proposed fix v5

Slight change, I forgot this little bit:

@@ -66,8 +66,6 @@ if { (![istarget x86_64-*-*] && ![istarget i?86-*-*])
 return
 }

-global GCC_RUNTEST_PARALLELIZE_DIR
-
 proc runtest_ms_sysv { cflags generator_args } {
 global GCC_UNDER_TEST HOSTCXX HOSTCXXFLAGS tmpdir srcdir subdir \
   TEST_ALWAYS_FLAGS runtests

[Bug fortran/52473] CSHIFT slow - inline it?

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473

--- Comment #8 from Thomas Koenig  ---
(In reply to Jerry DeLisle from comment #7)
> (In reply to Thomas Koenig from comment #6)
> > Created attachment 41508 [details]
> > What an unrolled cshift could look like
> > 
> > This is what an unrolled version of cshift could look like,
> > for a simple one-dimensional case.
> > 
> > If the shifts are constants, all the if statements are
> > optimized away at compile-time, so it is quite efficient.
> 
> How often or how important is this feature? Would it improve any known
> benchmark or real world application in a significant manner?

There's protein.f90 - see PR 52934.

Calculating a numerical derivative for a periodic function as

diff = (cshift(a,1) - cshift(a,-1))/(2*h)

seems natural, or the second derivative as

d2 = (cshift(a,1) - 2*a + cshift(a,-1))/(h**2)

Of course, to be really useful, this would also have to be
extended to eoshift...

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759

Daniel Santos  changed:

   What|Removed |Added

  Attachment #41486|0   |1
is obsolete||
  Attachment #41487|0   |1
is obsolete||
  Attachment #41488|0   |1
is obsolete||
  Attachment #41489|0   |1
is obsolete||
  Attachment #41490|0   |1
is obsolete||

--- Comment #31 from Daniel Santos  ---
Created attachment 41532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41532=edit
proposed fix v4

OK, so here goes version 4!  Hopefully we're getting closer.

(In reply to r...@cebitec.uni-bielefeld.de from comment #30)
> Fine.  Imagine your formatting/coding style changes: when they are
> intermixed with functional changes, every reviewer has to check
> thoroughly which part is which.  If you separate them (which is easy for
> you to do) and submit them separately, the formatting stuff will be
> obvious or nearly so, and you save everyone time by having to review
> only the beef of the functional changes, in the end also giving you
> faster review.

Yes.  I had at least split out all of the formatting stuff into the first
patch, but I had attached them from git format-patch and selected the patch
checkbox in Bugzilla, so maybe it wasn't as obvious as it didn't show the
subject or text in the mbox file (it would have probably been better to copy &
paste the subject line of each patch).  I've separated out only what's relevant
to this bug report: what breaks on Solaris, the ugly hard-coded offsets and
replacing the custom parallelization code.  Note that I have included the
changes to split the test jobs into smaller pieces so that potential
RTL-checking timeout issues are resolved.

> > Please also note that I did seek guidance when putting this exp file 
> > together
> > (back in December)  I was following Mike Stump's direction, but you were
> > probably on vacation or something. :) 
> > https://gcc.gnu.org/ml/gcc/2016-12/msg00145.html
> 
> Might be.  However, I've been appointed testsuite maintainer at a time
> when nobody else was around.  Later, Mike stepped up again who's way
> more experienced here than I am.  In the case at hand, I happen to be
> both victim of your patches' fallout and testsuite maintainer ;-)

lol!!  Well I think you're a bit more knowledgeable to some parts of the test
harness as his original direction left all of my tests running one for each
-j!  Once I figured that out, I tried to pester Mike and the mailing list
for a solution, but ended up just hacking out that custom parallelization code.
 But it's all good because I'm learning, and that keeps me happy. :)

> > I've also been motivated to expand the tests by a change somebody else made 
> > to
> > my original patch that I wasn't confident the original tests would fully 
> > check
> > (been worried about it, but it all looks good).  I'll get a cleaned up patch
> > for you soon.
> 
> Excellent, thanks for your patience.  I know the first times through the
> system can be hard and tedious...

HAH! Thanks for YOUR patience! :)  This patch doesn't include those extended
tests, but at least I have run them and feel more confident.  I'll submit those
changes separately.


> Here's the complete output from and amd64-pc-solaris2.12 build with your
> patch included:
> 
> spawn /var/gcc/regression/trunk/12-gcc-64/build/gcc/xgcc
> -B/var/gcc/regression/trunk/12-gcc-64/build/gcc/
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-
> sysv.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2
> -DGEN_ARGS=-p1 -t64
> -I/var/gcc/regression/trunk/12-gcc-64/build/gcc/testsuite/gcc6/ms-sysv
> -I/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv
> -Wall -Wall
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-
> test.S -lm -o ./ms-sysv.exe^M
> In file included from
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-
> sysv.c:158:0:^M
> /var/gcc/regression/trunk/12-gcc-64/build/gcc/testsuite/gcc6/ms-sysv/ms-sysv-
> generated.h: In function 'msabi_02_1':^M
> /var/gcc/regression/trunk/12-gcc-64/build/gcc/testsuite/gcc6/ms-sysv/ms-sysv-
> generated.h:42:1: error: bp cannot be used in asm here^M
> compiler exited with status 1
> 
> I suspect the problem is not explicitly passing -fno-omit-frame-pointer,
> though.  gcc/config/i386/sol2.h has
> 
> #define USE_IX86_FRAME_POINTER 1
> #define USE_X86_64_FRAME_POINTER 1
> 
> which does this implicitly...
> 
>   Rainer

Awesome!  This is what I've done in this patch

 # Detect when hard frame pointers are enabled (or required) so we know not
   

[Bug fortran/80988] [8 Regression] 171_swim fails

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80988

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/80988] [8 Regression] 171_swim fails

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80988

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Jun 10 10:07:13 2017
New Revision: 249092

URL: https://gcc.gnu.org/viewcvs?rev=249092=gcc=rev
Log:
2017-06-10  Thomas Koenig  

PR fortran/80988
* frontend-passes.c (traverse_io_block):  Also
check for variables occurring as indices multiple
time in a single implied DO loop.

2017-06-10  Thomas Koenig  

PR fortran/80988
* gfortran.dg/implied_do_io_3.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/implied_do_io_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

simon at pushface dot org changed:

   What|Removed |Added

  Attachment #41520|0   |1
is obsolete||

--- Comment #41 from simon at pushface dot org ---
Created attachment 41531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41531=edit
Patch (3) to top-level configure.ac, configure

(In reply to r...@cebitec.uni-bielefeld.de from comment #40)
> > --- Comment #39 from simon at pushface dot org ---
> [...]
> > Updated patch posted here; working on gcc-patches@ submission.
> 
> Thanks for the analysis and the patch.  I'll give it a whirl once PR
> bootstrap/81033 is resolved.
> 
> One nit for actual submission: your current patch contains lots of
> unrelated changes, removing trailing whitespace.  While that is fine in
> itself, please move it to a separate patch.

Oops, sorry about that.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||wrong-debug
 Target||Mips
  Component|tree-optimization   |rtl-optimization
   Target Milestone|--- |8.0

--- Comment #8 from Andrew Pinski  ---
I bet this is a bug in reorg.c.  It is the least used code (major target usage:
MIPS and sparc only) and also one of the more buggy code.

[Bug c/81049] no warning for simple uninitialized variables

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81049

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Marc Glisse  ---
Dup.

*** This bug has been marked as a duplicate of bug 18501 ***

[Bug tree-optimization/18501] [5/6/7/8 Regression] Missing 'used uninitialized' warning (CCP)

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

Marc Glisse  changed:

   What|Removed |Added

 CC||luc.vanoostenryck at gmail dot 
com

--- Comment #79 from Marc Glisse  ---
*** Bug 81049 has been marked as a duplicate of this bug. ***

[Bug c++/81047] thread local storage static class members of class type cannot be initialized

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81047

--- Comment #1 from Andrew Pinski  ---
What the error message is saying is if you use thread_local instead of
__thread; it would work (and c++11 or higher).

[Bug tree-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

--- Comment #7 from rguenther at suse dot de  ---
On June 10, 2017 7:55:31 AM GMT+02:00, "doug.gilmore at imgtec dot com"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025
>
>Doug Gilmore  changed:
>
>   What|Removed |Added
>
>Summary|[MIPS] soft-float glibc |[8 Regression] gcc ICE
> |build fails at r248863  |while building glibc for
>||MIPS soft-float multi-lib
>   ||variant
>
>--- Comment #6 from Doug Gilmore  ---
>We are back to having our MIPS nightly ToT toolchain builds all
>working with r247049 reverted.
>
>Given that r247049 exposes another PRE issue, see bug 80620,
>does it make sense to back out until we resolve the problems
>at hand?

This MIPS issue is just a latent issue exposed by said rev.  You should be able
to produce a test case from the .optimized gimple IL not requiring that PRE
change.

[Bug c/81049] New: no warning for simple uninitialized variables

[luc.vanoostenryck at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81049

Bug ID: 81049
   Summary: no warning for simple uninitialized variables
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luc.vanoostenryck at gmail dot com
  Target Milestone: ---

gcc doesn't issue a warning for very simple cases of uninitialized variable.
The options used are '-Wuninitialized -O2' or '-Wmaybe-uninitialized -O2'. It
can be reproduced with gcc 5.4, 6.3 and gcc 7.1 (I didn't tried older
versions).

One example of code to show this is:

int g;
int foo(void)
{
int r = 0;
int u;

if (g)
r = u;
return r;
}

[Bug fortran/81048] [6/7/8 Regression] incorrect derived type initialization

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81048

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||wrong-code
   Last reconfirmed||2017-06-10
 Ever confirmed|0   |1
Summary|incorrect derived type  |[6/7/8 Regression]
   |initialization  |incorrect derived type
   ||initialization
  Known to fail||6.3.0, 7.1.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
The change occurred between revisions r224647 (2015-06-19, OK) and r225925
(2015-07-17, wrong result).

Reduced test

program test
   type f
   integer :: f = -1
   end type
   type(f) :: a, b(3)
   write (*,*) ' a%f = ', a%f
   write (*,*) ' b(1:3)%f =  ', b(1:3)%f
   b = g2(a)
   write (*,*) ' b = g(a) gives b(1:3)%f = ', b(1:3)%f
   b = g2(a)
   write (*,*) ' b = g(a) gives b(1:3)%f = ', b(1:3)%f
contains
   function g2(a)
  type(f) :: a, g2(3)
  write (*,*) ' a%f = ', a%f
  write (*,*) ' g2(1:3)%f = ', g2(1:3)%f
  do j = 1, 3
 if (g2(j)%f == -1) then
 g2(j)%f = a%f - 1
 else
 g2(j)%f = a%f - 12345
 endif
  enddo
   end function g2
end program test

[Bug bootstrap/80897] [8 regression] gnat bootstrap broken on SPARC64/Linux

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80897

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #6 from Eric Botcazou  ---
Investigating.

[Bug bootstrap/80897] [8 regression] gnat bootstrap broken on SPARC64/Linux

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80897

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|gnat bootstrap broken on|[8 regression] gnat
   |sparc64-linux-gnu   |bootstrap broken on
   ||SPARC64/Linux

--- Comment #5 from Eric Botcazou  ---
I can reproduce on a SPARC machine.

[Bug fortran/81048] New: incorrect derived type initialization

[dm577216smith at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81048

Bug ID: 81048
   Summary: incorrect derived type initialization
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dm577216smith at gmail dot com
  Target Milestone: ---

A large program that ran correctly on several previous versions of gfortran
(and other compilers) failed when I installed from gfortran-6.3-Sierra.dmg
and CommandLineToolsforXcode8.3.2.dmg on a new Mac.

Please let me know if this is a gfortran6 bug, or if I have messed up the
installation.

Thanks,

David Smith
dsm...@lmu.edu


---

I will include a small program that seems to show the problem.

I think this is the correct output, from gfortran 5:

~ $ gfortran gfortran6test.f95 -o gfortran6test
~ $ gfortran6test
  a%f =   -1
  b(1:3)%f =-1  -1  -1
  g2(1:3)%f =   -1  -1  -1
  b = g(a) gives b(1:3)%f =   -2  -2   
  -2
  h2(1:3)%f =   -1  -1  -1
  b = h(a) gives b(1:3)%f =   -2  -2   
  -2
~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local/gfortran
--with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin14
Thread model: posix
gcc version 5.2.0 (GCC) 


---


Here is my output from 6.3:

~ $ gfortran gfortran6test.f95 -o gfortran6test
~ $ gfortran6test
  a%f =   -1
  b(1:3)%f =-1  -1  -1
  g2(1:3)%f =   -1  -1  -1
  b = g(a) gives b(1:3)%f =   -2  -2   
  -2
  h2(1:3)%f =   -2  -2  -2
  b = h(a) gives b(1:3)%f =   -12346  -12346 
-12346
~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin16/6.3.0/lto-wrapper
Target: x86_64-apple-darwin16
Configured with: ../gcc-6.3.0/configure --prefix=/usr/local/gfortran
--enable-languages=c,c++,
fortran,objc,obj-c++ --build=x86_64-apple-darwin16
--with-gmp=/Users/fx/devel/gcc/deps-static/x86_64
 --with-mpfr=/Users/fx/devel/gcc/deps-static/x86_64
--with-mpc=/Users/fx/devel/gcc/deps-static/x86_64
 --with-isl=/Users/fx/devel/gcc/deps-static/x86_64
Thread model: posix
gcc version 6.3.0 (GCC) 
~ $ 

---


module m
   type f
   integer :: f = -1
   end type
   interface g
   module procedure g2
   end interface
   contains
   function g2(a)
  type(f) :: a, g2(3)
  write (*,*) ' g2(1:3)%f = ', g2(1:3)%f
  do j = 1, 3
 if (g2(j)%f == -1) then
 g2(j)%f = a%f - 1
 else
 g2(j)%f = a%f - 12345
 endif
  enddo
   end function g2
end module m

module m2
   use m
   interface h
   module procedure h2
   end interface
   contains
   function h2(a)
  type(f) :: a, h2(3)
  write (*,*) ' h2(1:3)%f = ', h2(1:3)%f
  do j = 1, 3
 if (h2(j)%f == -1) then
 h2(j)%f = a%f - 1
 else
 h2(j)%f = a%f - 12345
 endif
  enddo
   end function h2
end module m2

program test
   use m2
   type(f) :: a, b(3)
   write (*,*) ' a%f = ', a%f
   write (*,*) ' b(1:3)%f =  ', b(1:3)%f
   b = g(a)
   write (*,*) ' b = g(a) gives b(1:3)%f = ', b(1:3)%f
   b = h(a)
   write (*,*) ' b = h(a) gives b(1:3)%f = ', b(1:3)%f
end program test

[Bug tree-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

[doug.gilmore at imgtec dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Doug Gilmore  changed:

   What|Removed |Added

Summary|[MIPS] soft-float glibc |[8 Regression] gcc ICE
   |build fails at r248863  |while building glibc for
   ||MIPS soft-float multi-lib
   ||variant

--- Comment #6 from Doug Gilmore  ---
We are back to having our MIPS nightly ToT toolchain builds all
working with r247049 reverted.

Given that r247049 exposes another PRE issue, see bug 80620,
does it make sense to back out until we resolve the problems
at hand?