[Bug tree-optimization/83320] New: Mismatched free() / delete / delete [] in gimple-loop-interchange.cc:948

[trippels at gcc dot gnu.org]

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

Bug ID: 83320
   Summary: Mismatched free() / delete / delete []  in
gimple-loop-interchange.cc:948
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---

Building libgfortran with -O3 shows:

==20156== Mismatched free() / delete / delete []   
   
   ==20156==at 0x402E246: free (vg_replace_malloc.c:530)   
   
  ==20156==by 0x129DB9F:
free_data_refs_with_aux (gimple-loop-interchange.cc:948)   
   
==20156==by 0x129DB9F: (anonymous
namespace)::pass_linterchange::execute(function*)
(gimple-loop-interchange.cc:2023)  
   ==20156==by 0xAE0761: execute_one_pass(opt_pass*)
(passes.c:2497) 
==20156==by 0xAE13F4: execute_pass_list_1 (passes.c:2586)   
==20156==by 0xAE13F4: execute_pass_list_1 (passes.c:2587)  
   
   ==20156==by 0xAE13F4: execute_pass_list_1
(passes.c:2587)
 ==20156==by 0xAE13F4:
execute_pass_list(function*, opt_pass*) (passes.c:2597)

==20156==by 0x8179F4: cgraph_node::expand() (cgraphunit.c:2139)
   
   ==20156==by 0x818AA2: expand_all_functions
(cgraphunit.c:2275)
==20156==by 0x818AA2:
symbol_table::compile() [clone .part.71] (cgraphunit.c:2623)   

==20156==by 0x81AEA1: compile (cgraphunit.c:2537)  
   
   ==20156==by 0x81AEA1:
symbol_table::finalize_compilation_unit() (cgraphunit.c:2716)   
==20156==by 0xBC5D67: compile_file() (toplev.c:480)
   
   ==20156==by 0x6C4692: do_compile (toplev.c:2059)
   
  ==20156==by 0x6C4692:
toplev::main(int, char**) (toplev.c:2194)  

==20156==by 0x6C61DA: main (main.c:39) 
   
   ==20156==  Address 0x5d4a8a0 is 0 bytes inside a block of
size 8 alloc'd 
 ==20156==at 0x402D6F8: operator
new(unsigned long) (vg_replace_malloc.c:334)   
   ==20156==by
0x129DD64: compute_access_stride (gimple-loop-interchange.cc:1283)  
==20156==by 0x129DD64: compute_access_strides
(gimple-loop-interchange.cc:1341)  
 ==20156==by 0x129DD64:
prepare_perfect_loop_nest (gimple-loop-interchange.cc:1958)
   
==20156==by 0x129DD64: (anonymous
namespace)::pass_linterchange::execute(function*)
(gimple-loop-interchange.cc:2017)  
   ==20156==by 0xAE0761: execute_one_pass(opt_pass*)
(passes.c:2497)
 ==20156==by 0xAE13F4:
execute_pass_list_1 (passes.c:2586)

==20156==by 0xAE13F4: execute_pass_list_1 (passes.c:2587)  

[Bug fortran/83316] ICE: minval/maxval and characters

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Blocks||45689
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #2 from Thomas Koenig  ---
Yep, that's still missing.

I'll take a look.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
[Bug 45689] [F03] Missing transformational intrinsic in the trans_func_f2003
list

[Bug tree-optimization/83312] [8 regression] bogus -Warray-bounds warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #4 from Jeffrey A. Law  ---
It's actually not jump threading that figures things out here.   VRP uses SCEV
to identify J as an induction variable.  So during substitute_and_fold it
transforms the controlling conditional from:

Folding statement: if (j_9 < 0)
Folding predicate j_9 < 0 to 0
Folded into: if (0 != 0)


Which makes the path with the problem code unreachable before we even look at
jump threading.  But the problem block still in the IL and it's considered
reachable.

I think we can avoid the warning by simply clearing EDGE_EXECUTABLE on the
appropriate edge when we simplify the conditional.  That won't capture
secondary effects though.  We could go further and have a step that propagates
EDGE_EXECUTABLE just before we do the array bounds warnings.  I'm not sure if
it's worth the effort.  Thoughts?

[Bug target/55023] hppa: wrong code generated with tail call optimisation

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #16 from Jeffrey A. Law  ---
Fixed eons ago.

[Bug target/69888] ICE: SIGSEGV in decide_alg (i386.c:26169) due to infinite (?) recursion with -minline-all-stringops -mmemset-strategy=no_stringop:-1:noalign

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #10 from Jeffrey A. Law  ---
Per c#9.

[Bug tree-optimization/80397] missing -Wformat-overflow with arguments of enum types

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed months ago with Martin's change on the trunk.

[Bug middle-end/81483] spurious -Wformat-overflow warning for limited types

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
This was fixed by introducing the EVRP analysis module and using it within DOM
and will no longer give the false positive with gcc-8.

In VRP1 the key statement is:

  _1 = (int) zone_2;

The key ranges:

_1: [0, +INF]
zone_2: VARYING


Not useful at all.  A few passes run after VRP and make a variety of changes to
the IL.  Then DOM fires up.  THe key statement has changed slightly into:

  _1 = (int) zone_11;

zone_11 is a new object (created by loop header copying).   DOM derives a range
of [0, 254] for _1.

That tighter range survives through to the printf warning code and (of course)
with the tighter range the false positive warning is gone.

[Bug fortran/83319] New: [7/8 Regression] ICE on use of allocatable component in derived type coarray defined in module

[damian at sourceryinstitute dot org]

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

Bug ID: 83319
   Summary: [7/8 Regression] ICE on use of allocatable component
in derived type coarray defined in module
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

Presumably the internal compiler error (ICE) demonstrated below is somehow
related to the known regression in support for allocatable components in
derived type coarrays, which is issue 422 on the OpenCoarrays repository.
OpenCoarrays issue 422, however, generates a runtime error message inside the
coarray ABI, whereas this issue generates a compile-time error message so it's
a compiler-side problem.  Also, OpenCoarrays issue 422 involves communication;
whereas this is much more basic: the ICE appears when I do anything with the
allocatable component so this is an even more serious regression on top of the
already very serious regression described in issue 422.  (Besides allocating
the component as shown below, I also tried a source allocation and an
assignment to it.)  The ICE disappears if the derived type definition is moved
into the main program.

This is somewhat similar to PR 78935, but 78935 was fixed 11 months ago and
this seems sufficiently different to warrant a separate PR rather than
reopening 78935.

This ICE occurs with today's 7 branch, with 7.2.0, and with the trunk dated
20170921.  The code compiles cleanly with GCC 6.4.0.

$ cat allocatable-component-of-dt-coarray.f90 

module foo_module
  implicit none
  type foo
integer, allocatable :: i(:)
  end type
end module

  use foo_module
  implicit none
  type(foo), save :: bar[*]
  allocate(bar%i(1))
end

$ gfortran -fcoarray=lib -c allocatable-component-of-dt-coarray.f90 
allocatable-component-of-dt-coarray.f90:8:0:

   use foo_module

internal compiler error: in gfc_conv_descriptor_token, at
fortran/trans-array.c:305
0x6a9130 gfc_conv_descriptor_token(tree_node*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/trans-array.c:303
0x6d6858 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/trans-expr.c:7567
0x6d0b47 gfc_conv_structure(gfc_se*, gfc_expr*, int)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/trans-expr.c:7686
0x6df17e gfc_trans_assignment_1
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/trans-expr.c:9984
0x6be5ff generate_coarray_sym_init
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/trans-decl.c:5188
0x68dc72 do_traverse_symtree
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/symbol.c:4009
0x6bdc95 generate_coarray_init
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/trans-decl.c:5238
0x6c9954 gfc_generate_function_code(gfc_namespace*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/trans-decl.c:6273
0x65b736 translate_all_program_units
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/parse.c:6074
0x65b736 gfc_parse_file()
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/parse.c:6274
0x69ff5f gfc_be_parse_file
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-7-branch/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gfortran --version
GNU Fortran (GCC) 7.2.1 20171208

[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-08
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Aldy Hernandez  ---
Confirmed on trunk.

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-08
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Aldy Hernandez  ---
Confirmed.  Any update on this amker?

Started with:

commit a9b41911523c1db8042f1f38d1ed814326ef
Author: amker 
Date:   Thu May 11 09:31:18 2017 +

* tree-ssa-loop-ivopts.c (get_loop_invariant_expr): Simplify.
(adjust_setup_cost): New parameter supporting round up adjustment.
(struct address_cost_data): Delete.
(force_expr_to_var_cost): Don't bound cost with spill_cost.
(split_address_cost, ptr_difference_cost): Delete.
(difference_cost, compare_aff_trees, record_inv_expr): Delete.
(struct ainc_cost_data): New struct.
(get_address_cost_ainc): New function.
(get_address_cost, get_computation_cost): Reimplement.
(determine_group_iv_cost_address): Record inv_expr for all uses of
a group.
(determine_group_iv_cost_cond): Call get_loop_invariant_expr.
(iv_ca_has_deps): Reimplemented to ...
(iv_ca_more_deps): ... this.  Check if NEW_CP introduces more deps
than OLD_CP.
(iv_ca_extend): Call iv_ca_more_deps.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@247885
138bc75d-0d04-0410-96
1f-82ee72b054a4

[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-08
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Confirmed.

Started with r254707:

commit 86136db8efde2401b066fee95c546365b75dce2e
Author: tromey 
Date:   Mon Nov 13 20:17:42 2017 +

Implement __VA_OPT__

This implements __VA_OPT__, a new preprocessor feature added in C++2A.
The paper can be found here:


Can even be reproduced with a simple ./cc1plus:

$ ./cc1plus.254707 ~/a.c -quiet
/home/cygnus/aldyh/a.c:2:1: internal compiler error: Segmentation fault
 a ()
 ^
0x119f9eb crash_signal
../../gcc/toplev.c:325
0x1e2a1bf paste_all_tokens
../../libcpp/macro.c:889
0x1e2a1bf cpp_get_token_1
../../libcpp/macro.c:2636
0xb2b4d5 c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/c-family/c-lex.c:399
0x959121 cp_lexer_get_preprocessor_token
../../gcc/cp/parser.c:793
0x9b0141 cp_parser_initial_pragma
../../gcc/cp/parser.c:38613
0x958d91 cp_lexer_new_main
../../gcc/cp/parser.c:647
0x95cd0d cp_parser_new
../../gcc/cp/parser.c:3859
0x9b0bc3 c_parse_file()
../../gcc/cp/parser.c:39018
0xb3870a c_common_parse_file()
../../gcc/c-family/c-opts.c:1127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/77493] [6/7/8 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||aldyh at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #19 from Aldy Hernandez  ---
Nobody can reproduce this, and I've been asking for more information on this
for over a year.  If someone can reproduce this or provide more information we
could consider re-opening it.

[Bug tree-optimization/81126] [6/7/8 Regression] ICE in df_compact_blocks, at df-core.c:1743

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2017-06-19 00:00:00 |2017-12-08
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Aldy Hernandez  ---
I can't reproduce this with neither current trunk nor the aforementioned
r228318 that allegedly started this:

tor:~/bld/tainted-trunk/gcc$ ./cc1 a.c -O1 -freorder-blocks-and-partition
--param iv-max-considered-uses=0 -fprofile-use  -quiet
tor:~/bld/tainted-trunk/gcc$ ./cc1 a.c -O1 -freorder-blocks-and-partition
--param iv-max-considered-uses=0   -quiet

tor:~/bld/tainted-trunk/gcc$ (cd ~/src/gcc/gcc; git show)
commit e57ef194b2cbbc8f178bdb6259e3bf3d2d4512e3
Author: segher 
Date:   Thu Oct 1 06:38:24 2015 +

bb-reorder: Add -freorder-blocks-algorithm= and wire it up
...

Same goes for current trunk.

Can the original reporter still reproduce this?

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Fri, Dec 08, 2017 at 01:14:44AM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> I don't know how I missed F2008:C631
> 
> C631 (R626) A type-param-value in a type-spec shall be an asterisk if
>and only if each allocate-object is a dummy argument for which the
>corresponding type parameter is assumed.
> 
> This is going to make the fix for 83318 real ugly.
> 
   character(len=42), allocatable :: foo
   character(len=22), allocatable :: foofoo

   call alloc( foo , foofoo)

   if (len(foo) .ne. 42) call abort
   if (len(foofoo) .ne. 22) call abort

contains

   subroutine alloc( bar, barbar )
  character(len=*), allocatable  :: bar
  character(len=22), allocatable :: barbar
  allocate(character(len=*) :: bar , barbar) ! <= Here!
   end subroutine

end

gfcx  z a.f90
f951: internal compiler error: Segmentation fault
0xb5af0f crash_signal
../../gcc/gcc/toplev.c:325
0x75eb9a gfc_dep_compare_expr(gfc_expr*, gfc_expr*)
../../gcc/gcc/fortran/dependency.c:363
0x741636 resolve_allocate_expr
../../gcc/gcc/fortran/resolve.c:7487
0x741636 resolve_allocate_deallocate
../../gcc/gcc/fortran/resolve.c:7879
0x733115 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/gcc/fortran/resolve.c:11314
0x735b4f resolve_codes
../../gcc/gcc/fortran/resolve.c:16433

[Bug fortran/83318] Illegal program causes internal compiler error with tags gfc_trans_allocate, at fortran/trans-stmt.c:5646 and Aborted (program f951)

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
I don't know how I missed F2008:C631

C631 (R626) A type-param-value in a type-spec shall be an asterisk if
   and only if each allocate-object is a dummy argument for which the
   corresponding type parameter is assumed.

This is going to make the fix real ugly.  Each alloc-object needs
to be checked that it is assumed length.

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Fri, Dec 08, 2017 at 12:52:31AM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82934
> 
> --- Comment #8 from Steve Kargl  ---
> On Fri, Dec 08, 2017 at 12:29:50AM +, kargl at gcc dot gnu.org wrote:
> > 
> >   allocate( character(len=*) :: bar )
> > 
> > However, the type-spec in the allocate statement does coincide with
> 
> s/does/does not
> 
> > the declaration of a dummy argument, or appear in SELECT TYPE, or
> > in the declaration of a named constant.  The * cannot appear here.
> > 
> >end subroutine
> 

Is it the weekend yet?  :(

I don't know how I missed F2008:C631

C631 (R626) A type-param-value in a type-spec shall be an asterisk if
   and only if each allocate-object is a dummy argument for which the
   corresponding type parameter is assumed.

This is going to make the fix for 83318 real ugly.

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Fri, Dec 08, 2017 at 12:29:50AM +, kargl at gcc dot gnu.org wrote:
> 
>   allocate( character(len=*) :: bar )
> 
> However, the type-spec in the allocate statement does coincide with

s/does/does not

> the declaration of a dummy argument, or appear in SELECT TYPE, or
> in the declaration of a named constant.  The * cannot appear here.
> 
>end subroutine

[Bug fortran/82934] [6/7/8 Regression] Segfault on assumed character length in allocate

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |
 Status|RESOLVED|REOPENED
 CC||kargl at gcc dot gnu.org
 Depends on||83318
 Resolution|FIXED   |---

--- Comment #7 from kargl at gcc dot gnu.org ---
I believe that this code is invalid Fortran.  Fortran 2008 states

An asterisk as a type-param-value specifies that a length type
parameter is an assumed type parameter.  It is used for a dummy
argument to assume the type parameter value from the effective
argument, for an associate name in a SELECT TYPE construct to
assume the type parameter value from the corresponding selector,
and for a named constant of type character to assume the character
length from the constant-expr .

In this code,

   subroutine alloc( bar )

  character(len=*), allocatable :: bar

bar is the dummy argument, so a type-spec with * can appear
here.

  allocate( character(len=*) :: bar )

However, the type-spec in the allocate statement does coincide with
the declaration of a dummy argument, or appear in SELECT TYPE, or
in the declaration of a named constant.  The * cannot appear here.

   end subroutine

The correct subroutine is simply

   subroutine alloc( bar )
  character(len=*), allocatable :: bar
  allocate( bar )
   end subroutine

It's not clear to me if Paul's patch needs to be removed
as it appears to set a possibly dangling pointer to NULL


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83318
[Bug 83318] Illegal program causes internal compiler error with tags
gfc_trans_allocate, at fortran/trans-stmt.c:5646  and  Aborted (program f951)

[Bug fortran/83318] Illegal program causes internal compiler error with tags gfc_trans_allocate, at fortran/trans-stmt.c:5646 and Aborted (program f951)

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Thu, Dec 07, 2017 at 11:42:53PM +, kargl at gcc dot gnu.org wrote:
> + if (!ts.u.cl->length)

Whoops.

  if (ts.type == BT_CHARACTER && !ts.u.cl->length)

[Bug target/83252] [8 Regression] Wrong code with "-march=skylake-avx512 -O3"

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec  8 00:03:28 2017
New Revision: 255487

URL: https://gcc.gnu.org/viewcvs?rev=255487=gcc=rev
Log:
PR target/83252
* gcc.target/i386/i386.exp (check_effective_target_bmi2): Moved to ...
* lib/target-supports.exp (check_effective_target_bmi2): ... here. 
Guard with
i?86-*-* x86_64-*-*.
* g++.dg/opt/pr83252.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr83252.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/i386.exp
trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/81906] [7 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] Calls to   |[7 Regression] Calls to
   |rint() wrongly optimized|rint() wrongly optimized
   |away starting in g++ 6  |away starting in g++ 6

--- Comment #15 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec  7 23:56:34 2017
New Revision: 255486

URL: https://gcc.gnu.org/viewcvs?rev=255486=gcc=rev
Log:
PR target/81906
* config/i386/i386.c (ix86_expand_rint): Handle flag_rounding_math.

* gcc.target/i386/pr81906.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81906.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83075] [8 Regression] Invalid strncpy optimization

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec  7 23:55:18 2017
New Revision: 255485

URL: https://gcc.gnu.org/viewcvs?rev=255485=gcc=rev
Log:
PR tree-optimization/83075
* gcc.dg/tree-ssa/strncpy-2.c: Use size_t instead of unsigned, add
separate function with noipa attribute to also verify behavior when
optimizers don't know the sizes and aliasing, verify resulting sizes
and array content.  Add -Wstringop-overflow to dg-options.
* gcc.dg/tree-ssa/strncat.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/strncat.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/strncpy-2.c

[Bug middle-end/82016] [8 regression] test case gcc.target/powerpc/float128-type-1.c fails after r251260

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #7 from Michael Meissner  ---
Yes, change 251814 should have fixed the issue.  Change 251814 was where I
changed the underlying code to enable the _Float128 support by default on
64-bit Linux PowerPC systems if they were configured with an assembler that
understands VSX instructions.

I'm not sure why the wide int changes seemed to trigger the test.

[Bug fortran/83318] Illegal program causes internal compiler error with tags gfc_trans_allocate, at fortran/trans-stmt.c:5646 and Aborted (program f951)

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
 gfcx -c a.f90
a.f90:5:13:

 allocate(character(len=*) :: string_array(2))
 1
Error: Type-spec at (1) must contain a scalar integer expression


Index: match.c
===
--- match.c (revision 255348)
+++ match.c (working copy)
@@ -4006,18 +4006,15 @@ gfc_match_allocate (void)
  goto cleanup;
}

- if (ts.type == BT_CHARACTER)
-   ts.u.cl->length_from_typespec = true;
-
- /* TODO understand why this error does not appear but, instead,
-the derived type is caught as a variable in primary.c.  */
- if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT)
+ if (!ts.u.cl->length)
{
- gfc_error ("The type parameter spec list in the type-spec at "
-"%L cannot contain ASSUMED or DEFERRED parameters",
-_locus);
+ gfc_error ("Type-spec at %L must contain a scalar integer "
+"expression", _locus);
  goto cleanup;
}
+
+ if (ts.type == BT_CHARACTER)
+   ts.u.cl->length_from_typespec = true;
}
   else
{

[Bug fortran/83318] Illegal program causes internal compiler error with tags gfc_trans_allocate, at fortran/trans-stmt.c:5646 and Aborted (program f951)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
 Blocks|68241   |

--- Comment #2 from kargl at gcc dot gnu.org ---
Remove the reference to 68241.  len=* is not a deferred character length.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug fortran/83318] Illegal program causes internal compiler error with tags gfc_trans_allocate, at fortran/trans-stmt.c:5646 and Aborted (program f951)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-07
 Blocks||68241
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 5.5.0 up to trunk (8.0).

The code is invalid, but an error would be better than an ICE.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug fortran/83316] ICE: minval/maxval and characters

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-07
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
AFAICS gfc_convert_constant does not handle BT_CHARACTER. The problem comes
from the comparison 'minval(s) /= b' and 'maxval(s) /= e'. Note that the
following variant works:

program tminmaxval
  implicit none

  character(len=*), parameter :: b = "a"
  character(len=*), parameter :: e = "c"
  character(len=*), parameter :: s(3) = (/"a", "b", "c"/)
  character(:), allocatable :: c

  c = minval(s)
  if (c /= b) then
 write(*,*) "minval(s) = ", minval(s)
  end if

  c = maxval(s)
  if (c /= e) then
 write(*,*) "maxval(s) = ", maxval(s)
  end if

end program tminmaxval

Backtrace

  * frame #0: 0x0001000cc64e
f951`gfc_convert_constant(e=0x000143819af0, type=BT_CHARACTER, kind=1) at
simplify.c:7068
frame #1: 0x00010004b3f3
f951`::do_simplify(specific=0x000142dd5c80, e=0x000145000bf0) at
intrinsic.c:4412
frame #2: 0x000100056319
f951`gfc_intrinsic_func_interface(expr=0x000145000bf0,
error_flag=) at intrinsic.c:4666
frame #3: 0x00010003c8b4 f951`gfc_simplify_expr(p=0x000145000bf0,
type=0) at expr.c:1867
frame #4: 0x00010003c773 f951`gfc_simplify_expr(gfc_expr*, int) at
expr.c:1053
frame #5: 0x00010003c750 f951`gfc_simplify_expr(p=0x0001450007a0,
type=0)
frame #6: 0x0001000b2a2a f951`gfc_resolve_expr(e=0x0001450007a0) at
resolve.c:4203
frame #7: 0x0001000ba549 f951`gfc_resolve_blocks(b=0x000145000560,
ns=0x00014406f400) at resolve.c:10044
frame #8: 0x0001000a9b3a f951`gfc_resolve_code(code=,
ns=) at resolve.c:0
frame #9: 0x0001000acea5 f951`::resolve_codes(ns=0x00014406f400) at
resolve.c:16496
frame #10: 0x0001000acf81 f951`gfc_resolve(ns=0x00014406f400) at
resolve.c:16531
frame #11: 0x000100099980 f951`gfc_parse_file() [inlined]
resolve_all_program_units(gfc_global_ns_list=0x00014406f400) at
parse.c:6031
frame #12: 0x000100099933 f951`gfc_parse_file()
frame #13: 0x0001000e31ec f951`::gfc_be_parse_file() at f95-lang.c:204
frame #14: 0x000100b7a61a f951`::compile_file() at toplev.c:455
frame #15: 0x0001011fc5a4 f951`toplev::main(int, char**) at
toplev.c:2059
frame #16: 0x0001011fc0b2 f951`toplev::main(this=0x7ffeefbff24e,
argc=, argv=)
frame #17: 0x0001011fe0ae f951`main(argc=2, argv=0x7ffeefbff288) at
main.c:39

[Bug fortran/83318] New: Illegal program causes internal compiler error with tags gfc_trans_allocate, at fortran/trans-stmt.c:5646 and Aborted (program f951)

[dmh at ucar dot edu]

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

Bug ID: 83318
   Summary: Illegal program causes internal compiler error with
tags gfc_trans_allocate, at fortran/trans-stmt.c:5646
and  Aborted (program f951)
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmh at ucar dot edu
  Target Milestone: ---

Created attachment 42812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42812=edit
Stackdump from gfortran crash

the exact version of GCC: 5.4.0
the system type: cygwin 32 bit on Windows 7
the options given when GCC was configured/built: unkoown
the complete command line that triggers the bug: gfortran -g -O0 -o t.exe t.f90
the compiler output (error messages, warnings, etc.)
-
t.f90:5:0:

 allocate(character(len=*) :: string_array(2))
 1
internal compiler error: in gfc_trans_allocate, at fortran/trans-stmt.c:5646

t.f90:5:0: internal compiler error: Aborted
gfortran: internal compiler error: Aborted (program f951)
--

the preprocessed file: crash apparently prevents this from being constructed.

I have attached the stackdump for what that is worth.

Failing program:
--
program fail
implicit none

character(len=:), allocatable :: string_array(:)
allocate(character(len=*) :: string_array(2))
end program fail

[Bug c/81568] attribute always_inline honored even after attribute noinline

[dave.pagan at oracle dot com]

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

--- Comment #5 from Dave Pagan  ---
Thanks for the update, Martin.

[Bug rtl-optimization/83317] New: ICE in lra_eliminate_reg_if_possible compiling Python with -mfpmath=sse on x86 Linux, possible 7 regression

[makosoft at gmail dot com]

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

Bug ID: 83317
   Summary: ICE in lra_eliminate_reg_if_possible compiling Python
with -mfpmath=sse on x86 Linux, possible 7 regression
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: makosoft at gmail dot com
  Target Milestone: ---

When compiling Python 3.5.4 or 3.6.3 with -mfpmath=sse on x86 Linux using gcc
7.2.0, I get an ICE/segfault in lra_eliminate_reg_if_possible while compiling
cmathmodule.c:

building 'cmath' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3
-Wall -Wstrict-prototypes -O2 -march=native 
-pipe -fomit-frame-pointer -mfpmath=sse -O2 -march=native -pipe
-fomit-frame-pointer -mfpmath=sse 
-Werror=declaration-after-statement -I./Include -I.
-I/home/aidan/src/Python-3.5.4/Include 
-I/home/aidan/src/Python-3.5.4 -c
/home/aidan/src/Python-3.5.4/Modules/cmathmodule.c -o 
build/temp.linux-i686-3.5/home/aidan/src/Python-3.5.4/Modules/cmathmodule.o
In file included from /home/aidan/src/Python-3.5.4/Modules/cmathmodule.c:11:0:
/home/aidan/src/Python-3.5.4/Modules/clinic/cmathmodule.c.h: In function
‘cmath_acos’:
/home/aidan/src/Python-3.5.4/Modules/clinic/cmathmodule.c.h:44:1: internal
compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

C-Reduce produced the following reduced test case which triggers the same
ICE/segfault:

typedef struct {
  double a
} b;
b c;
d, e;
f() {
  _setjmp();
  b g;
  if (d)
g.a = copysign(e, d);
  c = g;
}

A suitable set of compile options to reproduce this using the above test case
is:

gcc -fPIC -O1 -march=prescott -mfpmath=sse -c cmathmodule-reduced.i

The ICE does not appear to occur with gcc 6.4.0, nor does it occur if either of
-mfpmath=sse or -fPIC are disabled. It is, however, still present in the gcc 7
branch as of at least r255440. Backtrace is as follows:

Program received signal SIGSEGV, Segmentation fault.
0x084cb7f4 in lra_eliminate_reg_if_possible (loc=0xb772ad38) at
../.././gcc/lra-eliminations.c:1385
1385  || ! TEST_HARD_REG_BIT (lra_no_alloc_regs, regno))
(gdb) bt
#0  0x084cb7f4 in lra_eliminate_reg_if_possible (loc=0xb772ad38) at
../.././gcc/lra-eliminations.c:1385
#1  0x084bc1f0 in (anonymous namespace)::address_eliminator::address_eliminator
(this=0xbfffdb90, ad=)
at ../.././gcc/lra-constraints.c:362
#2  0x084bc320 in satisfies_memory_constraint_p (op=op@entry=0xb772ad40,
constraint=CONSTRAINT_m)
at ../.././gcc/lra-constraints.c:401
#3  0x084c2b3a in process_alt_operands (only_alternative=) at
../.././gcc/lra-constraints.c:2252
#4  curr_insn_transform (check_only_p=check_only_p@entry=false) at
../.././gcc/lra-constraints.c:3848
#5  0x084c5880 in lra_constraints (first_p=false) at
../.././gcc/lra-constraints.c:4863
#6  0x084b620e in lra (f=0x0) at ../.././gcc/lra.c:2392
#7  0x08477648 in do_reload () at ../.././gcc/ira.c:5478
#8  (anonymous namespace)::pass_reload::execute (this=0x96ec4d0) at
../.././gcc/ira.c:5662
#9  0x0853a145 in execute_one_pass (pass=0x96ec4d0) at
../.././gcc/passes.c:2465
#10 0x0853a94f in execute_pass_list_1 (pass=0x96ec4d0) at
../.././gcc/passes.c:2554
#11 0x0853a962 in execute_pass_list_1 (pass=0x96eb950, pass@entry=0x96e9280) at
../.././gcc/passes.c:2555
#12 0x0853a9a9 in execute_pass_list (fn=0xb772, pass=0x96e9280) at
../.././gcc/passes.c:2565
#13 0x082c18cc in cgraph_node::expand (this=0xb7726000) at
../.././gcc/cgraphunit.c:2042
#14 0x082c2c08 in expand_all_functions () at ../.././gcc/cgraphunit.c:2178
#15 symbol_table::compile (this=this@entry=0xb76680c4) at
../.././gcc/cgraphunit.c:2535
#16 0x082c48e9 in symbol_table::compile (this=0xb76680c4) at
../.././gcc/cgraphunit.c:2595
#17 symbol_table::finalize_compilation_unit (this=0xb76680c4) at
../.././gcc/cgraphunit.c:2625
#18 0x085f417a in compile_file () at ../.././gcc/toplev.c:492
#19 0x081a14e3 in do_compile () at ../.././gcc/toplev.c:2003
#20 toplev::main (this=0xbfffe8fe, argc=, argv=)
at ../.././gcc/toplev.c:2138
#21 0x081a3741 in main (argc=10, argv=0xbfffe9c4) at ../.././gcc/main.c:39

[Bug c/81568] attribute always_inline honored even after attribute noinline

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81544

--- Comment #4 from Martin Sebor  ---
Fixed in r255469.

[Bug c/81568] attribute always_inline honored even after attribute noinline

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||5.4.0, 6.4.0, 7.2.0

--- Comment #3 from Martin Sebor  ---
Thanks for the ping!  I just committed a fix for pr81544 (and pr81566) that
makes attribute validation more consistent.  With the patch applied, the output
for the test case in comment #0 is as follows.  There's just one warning and no
error because (as the warning says) the conflicting attribute is dropped.

I think with that this bug can be resolved as fixed as well (I forgot about it
and so didn't mention it in the commit).  Let me go ahead and do that, but
please feel free to take the freshly committed patch for a spin and open new
bugs if/when you find them or if you have suggestions for further refinements
or enhancements in this area.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic z.c
int __attribute__ ((noinline)) f (int);
int __attribute__ ((always_inline)) f (int);

int f (int i) { return i > 1 ? i * f (i - 1) * f (i - 2) : i > 0 ? i * f (i -
1) : 1; }

int f1 (void)
{
  return f (123);
}
z.c:2:1: warning: ignoring attribute ‘always_inline’ because it conflicts with
attribute ‘noinline’ [-Wattributes]
 int __attribute__ ((always_inline)) f (int);
 ^~~
z.c:1:32: note: previous declaration here
 int __attribute__ ((noinline)) f (int);
^

[Bug c/81568] attribute always_inline honored even after attribute noinline

[dave.pagan at oracle dot com]

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

Dave Pagan  changed:

   What|Removed |Added

 CC||dave.pagan at oracle dot com

--- Comment #2 from Dave Pagan  ---
Martin, have you (or has anyone else) spent time on this, or have a fix
already? I was thinking about looking into it further but don't want to
duplicate effort.

[Bug fortran/83316] New: ICE: minval/maxval and characters

[physiker at toast2 dot net]

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

Bug ID: 83316
   Summary: ICE: minval/maxval and characters
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Compiling the source file a.f90 causes an internal compiler error. I believe
the code is legal. 

program tminmaxval
  implicit none

  character(len=*), parameter :: b = "a"
  character(len=*), parameter :: e = "c"
  character(len=*), parameter :: s(3) = (/"a", "b", "c"/)

  if (minval(s) /= b) then
 write(*,*) "minval(s) =", minval(s)
  end if

  if (maxval(s) /= e) then
 write(*,*) "maxval(s) =", maxval(s)
  end if

end program tminmaxval

LANG=C gfortran-8 -W -Wall a.f90 -v 
Driving: gfortran-8 -W -Wall a.f90 -v -mmacosx-version-min=10.11.0
-asm_macosx_version_min=10.11 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-8
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/8.0.0/lto-wrapper
Target: x86_64-apple-darwin15.6.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-8
Thread model: posix
gcc version 8.0.0 20171203 (experimental) [trunk revision 255368] (GCC) 
COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-v' '-mmacosx-version-min=10.11.0'
'-asm_macosx_version_min=10.11' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/8.0.0/f951 a.f90 -fPIC -quiet
-dumpbase a.f90 -mmacosx-version-min=10.11.0 -mtune=core2 -auxbase a -Wextra
-Wall -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/8.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccL7uiWM.s
GNU Fortran (GCC) version 8.0.0 20171203 (experimental) [trunk revision 255368]
(x86_64-apple-darwin15.6.0)
compiled by GNU C version 8.0.0 20171203 (experimental) [trunk revision
255368], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version
isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 8.0.0 20171203 (experimental) [trunk revision
255368] (x86_64-apple-darwin15.6.0)
compiled by GNU C version 8.0.0 20171203 (experimental) [trunk revision
255368], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version
isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
f951: internal compiler error: gfc_convert_constant(): Unexpected type
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/83120] [8 Regression] ext/special_functions/hyperg failure on AIX

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #6 from David Edelsohn  ---
Fixed.

[Bug libstdc++/83120] [8 Regression] ext/special_functions/hyperg failure on AIX

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
Author: dje
Date: Thu Dec  7 20:05:59 2017
New Revision: 255483

URL: https://gcc.gnu.org/viewcvs?rev=255483=gcc=rev
Log:
PR libstdc++/83120
* testsuite/ext/special_functions/hyperg/check_value.cc: Add
-ffp-contract=off. Add -ffloat-store for m68* and ia32.
*
testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc:
Same.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/ext/special_functions/hyperg/check_value.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #13 from Jeffrey A. Law  ---
Fixed by Vlad commit on the trunk.

[Bug target/83252] [8 Regression] Wrong code with "-march=skylake-avx512 -O3"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #15 from Jeffrey A. Law  ---
Fixed by Vlad's change on the trunk.  Hopefully for good this time :-)

[Bug testsuite/82006] [8 Regression] ERROR: torture-init: torture_without_loops is not empty as expected

[rai...@emrich-ebersheim.de]

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

--- Comment #7 from Rainer Emrich  ---
(In reply to Jakub Jelinek from comment #5)
> Any progress on this?

Yeah, I have no exact analysis yet, but the issue is caused by Richards commit
r251220. I wonder how this can cause the tcl errors.
I will provide some more details of the issue later when the testsuite run is
finished.

[Bug tree-optimization/83253] -ftree-slsr causes performance regression

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Apologies for not responding sooner -- I've been out of pocket for the last
week.  I'll have a look when I get unburied (probably next week).

Bill

[Bug tree-optimization/81303] [8 Regression] 410.bwaves regression caused by r249919

[amker at gcc dot gnu.org]

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

--- Comment #11 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Dec  7 18:03:53 2017
New Revision: 255472

URL: https://gcc.gnu.org/viewcvs?rev=255472=gcc=rev
Log:
PR tree-optimization/81303
* Makefile.in (gimple-loop-interchange.o): New object file.
* common.opt (floop-interchange): Reuse the option from graphite.
* doc/invoke.texi (-floop-interchange): Ditto.  New document for
-floop-interchange and mention it for -O3.
* opts.c (default_options_table): Enable -floop-interchange at -O3.
* gimple-loop-interchange.cc: New file.
* params.def (PARAM_LOOP_INTERCHANGE_MAX_NUM_STMTS): New parameter.
(PARAM_LOOP_INTERCHANGE_STRIDE_RATIO): New parameter.
* passes.def (pass_linterchange): New pass.
* timevar.def (TV_LINTERCHANGE): New time var.
* tree-pass.h (make_pass_linterchange): New declaration.
* tree-ssa-loop-ivcanon.c (create_canonical_iv): Change to external
interchange.  Record IV before/after increment in new parameters.
* tree-ssa-loop-ivopts.h (create_canonical_iv): New declaration.
* tree-vect-loop.c (vect_is_simple_reduction): Factor out reduction
path check into...
(check_reduction_path): ...New function here.
* tree-vectorizer.h (check_reduction_path): New declaration.

gcc/testsuite
* gcc.dg/tree-ssa/loop-interchange-1.c: New test.
* gcc.dg/tree-ssa/loop-interchange-1b.c: New test.
* gcc.dg/tree-ssa/loop-interchange-2.c: New test.
* gcc.dg/tree-ssa/loop-interchange-3.c: New test.
* gcc.dg/tree-ssa/loop-interchange-4.c: New test.
* gcc.dg/tree-ssa/loop-interchange-5.c: New test.
* gcc.dg/tree-ssa/loop-interchange-6.c: New test.
* gcc.dg/tree-ssa/loop-interchange-7.c: New test.
* gcc.dg/tree-ssa/loop-interchange-8.c: New test.
* gcc.dg/tree-ssa/loop-interchange-9.c: New test.
* gcc.dg/tree-ssa/loop-interchange-10.c: New test.
* gcc.dg/tree-ssa/loop-interchange-11.c: New test.
* gcc.dg/tree-ssa/loop-interchange-12.c: New test.
* gcc.dg/tree-ssa/loop-interchange-13.c: New test.

Added:
trunk/gcc/gimple-loop-interchange.cc
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-10.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-12.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-13.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-1b.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/opts.c
trunk/gcc/params.def
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/timevar.def
trunk/gcc/tree-pass.h
trunk/gcc/tree-ssa-loop-ivcanon.c
trunk/gcc/tree-ssa-loop-ivopts.h
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vectorizer.h

[Bug go/83308] Missing platform definitions for SH in libgo

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Ian Lance Taylor from comment #4)
> gccgo does work on a number of targets that do not have split stack support.
> The downsides are that each goroutine has a much larger stack, and if you
> have too much recursion you can run out of stack space and crash.  But most
> programs work fine.

I'll give it a try and if it works, I'll send a patch :).

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[vmakarov at gcc dot gnu.org]

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

--- Comment #12 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Dec  7 17:50:54 2017
New Revision: 255471

URL: https://gcc.gnu.org/viewcvs?rev=255471=gcc=rev
Log:
2017-12-07  Vladimir Makarov  

PR target/83252
PR rtl-optimization/80818
* lra.c (add_regs_to_insn_regno_info): Make a hard reg in CLOBBER
always early clobbered.
* lra-lives.c (process_bb_lives): Check input hard regs for early
clobbered non-operand hard reg.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c
trunk/gcc/lra.c

[Bug target/83252] [8 Regression] Wrong code with "-march=skylake-avx512 -O3"

[vmakarov at gcc dot gnu.org]

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

--- Comment #14 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Dec  7 17:50:54 2017
New Revision: 255471

URL: https://gcc.gnu.org/viewcvs?rev=255471=gcc=rev
Log:
2017-12-07  Vladimir Makarov  

PR target/83252
PR rtl-optimization/80818
* lra.c (add_regs_to_insn_regno_info): Make a hard reg in CLOBBER
always early clobbered.
* lra-lives.c (process_bb_lives): Check input hard regs for early
clobbered non-operand hard reg.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c
trunk/gcc/lra.c

[Bug go/83314] gccgo: Compiled binaries panic with "mmap errno 9" on m68k

[jrtc27 at jrtc27 dot com]

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

--- Comment #5 from James Clarke  ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> Ok, I should have actually tested this on real hardware right away.
> 
> Here's on my Amiga 4000:
> 
> root@elgar:~> ./hello 
> 5662
> fatal error: memstats.heap_live not aligned to 8 bytes

heap_live is a uint64, which is only 2-byte aligned on m68k. Either m68k needs
to force stronger alignment here, or the assertion needs dropping for m68k.

> 
> goroutine 16 [running, locked to thread]:
> runtime.dopanic
> ../../../src/libgo/go/runtime/panic.go:832
> runtime.throw
> ../../../src/libgo/go/runtime/panic.go:758
> futexwakeup addr=0xc111aa0e returned -1

Futexes must always be 4-byte aligned (kernel requirement), but on m68k ints
only need 2-byte alignment.

> fatal error: unexpected signal during runtime execution
> panic during panic
> [signal SIGSEGV: segmentation violation code=1 addr=4102 pc=3233247334]
> futexwakeup addr=0xc111aa0e returned -1
> fatal error: unexpected signal during runtime execution
> stack trace unavailable
> root@elgar:~>
> 
> On a sidenote: That's probably the first time Go is running on an Amiga!

[Bug go/83314] gccgo: Compiled binaries panic with "mmap errno 9" on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
Ok, I should have actually tested this on real hardware right away.

Here's on my Amiga 4000:

root@elgar:~> ./hello 
5662
fatal error: memstats.heap_live not aligned to 8 bytes

goroutine 16 [running, locked to thread]:
runtime.dopanic
../../../src/libgo/go/runtime/panic.go:832
runtime.throw
../../../src/libgo/go/runtime/panic.go:758
futexwakeup addr=0xc111aa0e returned -1
fatal error: unexpected signal during runtime execution
panic during panic
[signal SIGSEGV: segmentation violation code=1 addr=4102 pc=3233247334]
futexwakeup addr=0xc111aa0e returned -1
fatal error: unexpected signal during runtime execution
stack trace unavailable
root@elgar:~>

On a sidenote: That's probably the first time Go is running on an Amiga!

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Fixed.

[Bug go/83314] gccgo: Compiled binaries panic with "mmap errno 9" on m68k

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Ah, of course.  Thanks.  In that case mmap is being called with a descriptor
that is the executable itself, as opened by fileline_initialize in
libbacktrace/fileline.c.  I wonder why mmap fails on that?  Can you debug?

[Bug go/83314] gccgo: Compiled binaries panic with "mmap errno 9" on m68k

[jrtc27 at jrtc27 dot com]

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

--- Comment #2 from James Clarke  ---
My guess is libbacktrace/mmapio.c (perhaps mmap.c), which calls mmap with
MAP_PRIVATE, and calls `error_callback (data, "mmap", errno)` on failure.
That's a function pointer, which I would assume is error_callback in
libgo/runtime/go-caller{,s}.c, both of which call backtrace things.

[Bug middle-end/83164] [8 regression] internal compiler error: verify_gimple failed

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec  7 17:06:08 2017
New Revision: 255470

URL: https://gcc.gnu.org/viewcvs?rev=255470=gcc=rev
Log:
PR middle-end/83164
* tree-cfg.c (verify_gimple_assign_binary): Don't require
types_compatible_p, just that TYPE_MODE is the same.

* gcc.c-torture/compile/pr83164.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr83164.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug c++/80135] [6/7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:4968

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Untested WIP patch attached to PR81922.

[Bug c++/81922] [6/7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:5030

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 42811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42811=edit
gcc8-pr81922.patch

WIP patch that attempts to handle it like the C FE, will work on testcases
tomorrow.

[Bug go/83314] gccgo: Compiled binaries panic with "mmap errno 9" on m68k

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
errno 9 is EBADF, which doesn't make much sense since libgo only ever calls
mmap with MAP_ANONYMOUS.  And I'm not even sure where those messages are coming
from.  I don't see any place where the GCC 7 libgo will print "mmap errno" or
"fatal error: mmap".

[Bug go/83308] Missing platform definitions for SH in libgo

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
gccgo does work on a number of targets that do not have split stack support. 
The downsides are that each goroutine has a much larger stack, and if you have
too much recursion you can run out of stack space and crash.  But most programs
work fine.

[Bug c/81566] [6/7 Regression] invalid attribute aligned accepted on functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
Summary|[6/7/8 Regression] invalid  |[6/7 Regression] invalid
   |attribute aligned accepted  |attribute aligned accepted
   |on functions|on functions

--- Comment #8 from Martin Sebor  ---
Fixed in 8.0 via r255469.  GCC 8 issues the warnings below.  Removing the 8
regression.

The patch seems too big to backport to older branches though it may be possible
to extract just the subset of the patch that fixes this issue and backport it. 
I don't expect to have the cycles to work on in in stage 3/4 so I'll unassign
myself from the bug for now.

pr81566.c:3:1: warning: ignoring attribute ‘aligned (4)’ because it conflicts
with attribute ‘aligned (16)’ [-Wattributes]
 int __attribute__ ((aligned (4))) f (void);
 ^~~
pr81566.c:1:31: note: previous declaration here
 int __attribute__ ((aligned)) f (void);
   ^
pr81566.c:4:1: warning: ignoring attribute ‘aligned (2)’ because it conflicts
with attribute ‘aligned (16)’ [-Wattributes]
 int __attribute__ ((aligned (2))) f (void);
 ^~~
pr81566.c:3:35: note: previous declaration here
 int __attribute__ ((aligned (4))) f (void);
   ^
pr81566.c:5:1: warning: ignoring attribute ‘aligned (1)’ because it conflicts
with attribute ‘aligned (16)’ [-Wattributes]
 int __attribute__ ((aligned (1))) f (void);
 ^~~
pr81566.c:4:35: note: previous declaration here
 int __attribute__ ((aligned (2))) f (void);
   ^
pr81566.c:11:1: warning: ignoring attribute ‘aligned (1)’ because it conflicts
with attribute ‘aligned (2)’ [-Wattributes]
 int __attribute__ ((aligned (1))) g (void);
 ^~~
pr81566.c:10:35: note: previous declaration here
 int __attribute__ ((aligned (2))) g (void);
   ^

[Bug c/81544] attribute noreturn and warn_unused_result on the same function accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|mpolacek at gcc dot gnu.org|msebor at gcc dot 
gnu.org

--- Comment #4 from Martin Sebor  ---
Fixed via 255469.

[Bug c/81544] attribute noreturn and warn_unused_result on the same function accepted

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  7 16:32:03 2017
New Revision: 255469

URL: https://gcc.gnu.org/viewcvs?rev=255469=gcc=rev
Log:
PR c/81544 - attribute noreturn and warn_unused_result on the same function
accepted
PR c/81566 - invalid attribute aligned accepted on functions

gcc/ada/ChangeLog:

PR c/81544
* gcc-interface/utils.c (gnat_internal_attribute_table): Initialize
new member of struct attribute_spec.

gcc/c/ChangeLog:

PR c/81544
* c-decl.c (c_decl_attributes): Look up existing declaration and
pass it to decl_attributes.

gcc/c-family/ChangeLog:

PR c/81544
PR c/81566
* c-attribs.c (attr_aligned_exclusions): New array.
(attr_alloc_exclusions, attr_cold_hot_exclusions): Same.
(attr_common_exclusions, attr_const_pure_exclusions): Same.
(attr_gnu_inline_exclusions, attr_inline_exclusions): Same.
(attr_noreturn_exclusions, attr_returns_twice_exclusions): Same.
(attr_warn_unused_result_exclusions): Same.
(handle_hot_attribute, handle_cold_attribute): Simplify.
(handle_const_attribute): Warn on function returning void.
(handle_pure_attribute): Same.
(handle_aligned_attribute): Diagnose conflicting attribute
specifications.
* c-warn.c (diagnose_mismatched_attributes): Simplify.

gcc/cp/ChangeLog:

PR c/81544
* cp-tree.h (decls_match): Add default argument.
* decl.c (decls_match): Avoid calling into the target back end
and triggering an error.
* decl2.c (cplus_decl_attributes): Look up existing declaration and
pass it to decl_attributes.
* tree.c (cxx_attribute_table): Initialize new member of struct
attribute_spec.

gcc/fortran/ChangeLog:

PR c/81544
* f95-lang.c (gfc_attribute_table): Initialize new member of struct
attribute_spec.

gcc/lto/ChangeLog:

PR c/81544
* lto-lang.c (lto_attribute_table): Initialize new member of struct
attribute_spec.

gcc/ChangeLog:

PR c/81544
* attribs.c (empty_attribute_table): Initialize new member of
struct attribute_spec.
(decl_attributes): Add argument.  Handle mutually exclusive
combinations of attributes.
(selftests::test_attribute_exclusions): New function.
(selftests::attribute_c_tests): Ditto.
* attribs.h (decl_attributes): Add default argument.
* selftest.h (attribute_c_tests): Declare.
* selftest-run-tests.c (selftest::run_tests): Call attribute_c_tests.
* tree-core.h (attribute_spec::exclusions, exclude): New type and
member.
* doc/extend.texi (Common Function Attributes): Update const and pure.

gcc/testsuite/ChangeLog:

PR c/81544
* c-c++-common/Wattributes-2.c: New test.
* c-c++-common/Wattributes.c: New test.
* c-c++-common/attributes-3.c: Adjust.
* gcc.dg/Wattributes-6.c: New test.
* gcc.dg/Wattributes-7.c: New test.
* gcc.dg/attr-noinline.c
* gcc.dg/pr44964.c: Same.
* gcc.dg/torture/pr42363.c: Same.
* gcc.dg/tree-ssa/ssa-ccp-2.c: Same.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/utils.c
trunk/gcc/attribs.c
trunk/gcc/attribs.h
trunk/gcc/brig/brig-lang.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/c-family/c-warn.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/config/alpha/alpha.c
trunk/gcc/config/arc/arc.c
trunk/gcc/config/arm/arm.c
trunk/gcc/config/avr/avr.c
trunk/gcc/config/bfin/bfin.c
trunk/gcc/config/cr16/cr16.c
trunk/gcc/config/epiphany/epiphany.c
trunk/gcc/config/h8300/h8300.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/m32c/m32c.c
trunk/gcc/config/m32r/m32r.c
trunk/gcc/config/m68k/m68k.c
trunk/gcc/config/mcore/mcore.c
trunk/gcc/config/microblaze/microblaze.c
trunk/gcc/config/mips/mips.c
trunk/gcc/config/msp430/msp430.c
trunk/gcc/config/nds32/nds32.c
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/config/powerpcspe/powerpcspe.c
trunk/gcc/config/rl78/rl78.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rx/rx.c
trunk/gcc/config/s390/s390.c
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/spu/spu.c
trunk/gcc/config/stormy16/stormy16.c
trunk/gcc/config/v850/v850.c
trunk/gcc/config/visium/visium.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
trunk/gcc/selftest-run-tests.c
trunk/gcc/selftest.h

[Bug c/81566] [6/7/8 Regression] invalid attribute aligned accepted on functions

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  7 16:32:03 2017
New Revision: 255469

URL: https://gcc.gnu.org/viewcvs?rev=255469=gcc=rev
Log:
PR c/81544 - attribute noreturn and warn_unused_result on the same function
accepted
PR c/81566 - invalid attribute aligned accepted on functions

gcc/ada/ChangeLog:

PR c/81544
* gcc-interface/utils.c (gnat_internal_attribute_table): Initialize
new member of struct attribute_spec.

gcc/c/ChangeLog:

PR c/81544
* c-decl.c (c_decl_attributes): Look up existing declaration and
pass it to decl_attributes.

gcc/c-family/ChangeLog:

PR c/81544
PR c/81566
* c-attribs.c (attr_aligned_exclusions): New array.
(attr_alloc_exclusions, attr_cold_hot_exclusions): Same.
(attr_common_exclusions, attr_const_pure_exclusions): Same.
(attr_gnu_inline_exclusions, attr_inline_exclusions): Same.
(attr_noreturn_exclusions, attr_returns_twice_exclusions): Same.
(attr_warn_unused_result_exclusions): Same.
(handle_hot_attribute, handle_cold_attribute): Simplify.
(handle_const_attribute): Warn on function returning void.
(handle_pure_attribute): Same.
(handle_aligned_attribute): Diagnose conflicting attribute
specifications.
* c-warn.c (diagnose_mismatched_attributes): Simplify.

gcc/cp/ChangeLog:

PR c/81544
* cp-tree.h (decls_match): Add default argument.
* decl.c (decls_match): Avoid calling into the target back end
and triggering an error.
* decl2.c (cplus_decl_attributes): Look up existing declaration and
pass it to decl_attributes.
* tree.c (cxx_attribute_table): Initialize new member of struct
attribute_spec.

gcc/fortran/ChangeLog:

PR c/81544
* f95-lang.c (gfc_attribute_table): Initialize new member of struct
attribute_spec.

gcc/lto/ChangeLog:

PR c/81544
* lto-lang.c (lto_attribute_table): Initialize new member of struct
attribute_spec.

gcc/ChangeLog:

PR c/81544
* attribs.c (empty_attribute_table): Initialize new member of
struct attribute_spec.
(decl_attributes): Add argument.  Handle mutually exclusive
combinations of attributes.
(selftests::test_attribute_exclusions): New function.
(selftests::attribute_c_tests): Ditto.
* attribs.h (decl_attributes): Add default argument.
* selftest.h (attribute_c_tests): Declare.
* selftest-run-tests.c (selftest::run_tests): Call attribute_c_tests.
* tree-core.h (attribute_spec::exclusions, exclude): New type and
member.
* doc/extend.texi (Common Function Attributes): Update const and pure.

gcc/testsuite/ChangeLog:

PR c/81544
* c-c++-common/Wattributes-2.c: New test.
* c-c++-common/Wattributes.c: New test.
* c-c++-common/attributes-3.c: Adjust.
* gcc.dg/Wattributes-6.c: New test.
* gcc.dg/Wattributes-7.c: New test.
* gcc.dg/attr-noinline.c
* gcc.dg/pr44964.c: Same.
* gcc.dg/torture/pr42363.c: Same.
* gcc.dg/tree-ssa/ssa-ccp-2.c: Same.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/utils.c
trunk/gcc/attribs.c
trunk/gcc/attribs.h
trunk/gcc/brig/brig-lang.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/c-family/c-warn.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/config/alpha/alpha.c
trunk/gcc/config/arc/arc.c
trunk/gcc/config/arm/arm.c
trunk/gcc/config/avr/avr.c
trunk/gcc/config/bfin/bfin.c
trunk/gcc/config/cr16/cr16.c
trunk/gcc/config/epiphany/epiphany.c
trunk/gcc/config/h8300/h8300.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/m32c/m32c.c
trunk/gcc/config/m32r/m32r.c
trunk/gcc/config/m68k/m68k.c
trunk/gcc/config/mcore/mcore.c
trunk/gcc/config/microblaze/microblaze.c
trunk/gcc/config/mips/mips.c
trunk/gcc/config/msp430/msp430.c
trunk/gcc/config/nds32/nds32.c
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/config/powerpcspe/powerpcspe.c
trunk/gcc/config/rl78/rl78.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rx/rx.c
trunk/gcc/config/s390/s390.c
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/spu/spu.c
trunk/gcc/config/stormy16/stormy16.c
trunk/gcc/config/v850/v850.c
trunk/gcc/config/visium/visium.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
trunk/gcc/selftest-run-tests.c
trunk/gcc/selftest.h

[Bug target/83315] PowerPC xmmintrin.h emulation for _mm_{min,max}_ps not semantically equivalent

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-07
 CC||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug target/83315] New: PowerPC xmmintrin.h emulation for _mm_{min,max}_ps not semantically equivalent

[dje at gcc dot gnu.org]

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

Bug ID: 83315
   Summary: PowerPC xmmintrin.h emulation for _mm_{min,max}_ps not
semantically equivalent
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

PowerPC port xmmintrin.h _mm_min_ps invokes Power vec_min instrinsic and
_mm_max_ps invokes Power vec_max instrinsic.  vec_min corresponds to the
xsminsp instruction and vec_max corresponds to the xsmaxsp instruction.  The
Power instructions implement different semantics for NaN than the Intel
equivalents.  The Power ISA 3.0 (Power9) xsmincsp and xsmaxcsp instructions
correspond to the Intel semantics.

[Bug target/81356] __builtin_strcpy is not good for copying an empty string on aarch64

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #9 from Wilco  ---
I presume this can be closed now?

[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

Summary|--with-dwarf2 is not|--with-dwarf2 should be
   |propagated correctly, will  |documented as meaning
   |always create dwarf4 by |"DWARF 2 or later" instead
   |default |of just "DWARF 2"

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to jos...@codesourcery.com from comment #1)
> > This is a documentation bug - the installation manual should make clear 
> > that "DWARF 2" in the description of this option means DWARF 2 or later, 
> > as appropriate for the target, as opposed to (for example) STABS.
> 
> Confirmed, the documentation for --with-dwarf2 is still just:
> 
> --with-dwarf2
> 
> Specify that the compiler should use DWARF 2 debugging information as
> the default.

Updating title to reflect the actual issue

[Bug boehm-gc/57761] USE_PROC_FOR_LIBRARIES does not work correctly

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-12-07
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
WAITING on a link to an upstream bug so I can close this as RESOLVED MOVED,
otherwise I'll close it as RESOLVED WONTFIX in 3 months.

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[andrey.y.guskov at intel dot com]

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

--- Comment #10 from Andrey Guskov  ---
32-bit SPEC CPU2006::436 also affected.

[Bug go/83314] New: gccgo: Compiled binaries panic with "mmap errno 9" on m68k

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 83314
   Summary: gccgo: Compiled binaries panic with "mmap errno 9" on
m68k
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: glaubitz at physik dot fu-berlin.de
CC: cmang at google dot com, doko at gcc dot gnu.org, ian at 
airs dot com,
jrtc27 at jrtc27 dot com, schwab at gcc dot gnu.org
  Target Milestone: ---

Trying to run a natively compiled Go program with gccgo-7 (SVN r255408) on m68k
fails with "mmap errno 9":

(sid-m68k-sbuild)root@nofan:/# cat hello.go 
package main 

import "fmt"



func main() {
fmt.Println("hello world")
}

(sid-m68k-sbuild)root@nofan:/# gccgo-7 hello.go -o hello
(sid-m68k-sbuild)root@nofan:/# ./hello 
mmap errno 9
fatal error: mmap

runtime stack:
mmap errno 9
fatal error: mmap
panic during panic

runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
(sid-m68k-sbuild)root@nofan:/#

[Bug c++/64867] warning for passing non-POD to varargs function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |egallager at gcc dot 
gnu.org

--- Comment #22 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #21)
> No, because it doesn't have any tests.
> 
> It should probably adjust:
> 
> ../gcc/testsuite/g++.dg/overload/ellipsis1.C
> ../gcc/testsuite/g++.dg/overload/ellipsis2.C
> ../gcc/testsuite/g++.old-deja/g++.pt/vaarg3.C
> 
> to use the new flag, and add a test that the new flag is enabled by
> -Wconditionally-supported

OK, I think I can do this.

[Bug go/79281] gccgo: Binaries using goroutines crash on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #15 from John Paul Adrian Glaubitz  ---
(In reply to Ian Lance Taylor from comment #11)
> Thanks.  I committed the patch to the GCC 6 branch.
> 
> GCC 7 will require a different fix, as the code has moved from C to Go.  I'm
> not sure what the best approach is.

Just as a heads-up: I just successfully built gcc-7 with the Go frontend
enabled on m68k without any issues (gcc-7_7.2.0 - SVN r255408). It did not work
when I tested a gcc-7 snapshot from 20170221.

I did not perform any extended tests yet though, so I don't know whether there
are other issues left.

[Bug c++/81922] [6/7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:5030

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
We have a bunch of other PRs for the lack of diagnostics of invalid
initialization of flexible array members inside of arrays to non-empty array.
We just should diagnose it as invalid.

[Bug middle-end/82016] [8 regression] test case gcc.target/powerpc/float128-type-1.c fails after r251260

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
This doesn't FAIL since ~ Sep 6/7th, my rough guess is r251814.  Has it been
fixed or is it just latent?

[Bug middle-end/83239] Improve (or eliminate) diagnostics related to loop distribution

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Assignee|msebor at gcc dot gnu.org  |law at redhat dot com
Summary|False positive from |Improve (or eliminate)
   |-Wstringop-overflow on  |diagnostics related to loop
   |simple std::vector code |distribution

--- Comment #12 from Jeffrey A. Law  ---
I was looking at this again tonight, and I clearly missed the interaction
between known ranges and the overflow check.

If we look at the .vrp1 dump we see this overflow check in bb16:

23 = ASSERT_EXPR <_13, _13 > 2>;
_1 = _23 + 18446744073709551614;
if (_1 > _23)
  goto ; [33.00%]
else
  goto ; [67.00%]

This is a controlling condition for the clearing loop which ldist will turn
into a memset.

The range for _23 is:

(gdb) p debug_value_range (get_value_range (gimple_cond_rhs (stmt)))
[3, +INF]  EQUIVALENCES: { _13 } (1 elements)

Exactly what we'd expect given the ASSERT_EXPR.  So far so good.

The condition can be rewritten as _23 - 2 > _23, which is only going to be true
if _23 has the value 0 or 1.  So we can deduce that the condition is always
false.

We're correctly identifying the test as an overflow check in VRP, but we're not
optimizing it.  I think we just need to extend
vr_values::vrp_evaluate_conditional_warnv_with_ops and the right things should
just happen.

[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #5 from Richard Biener  ---
I think this one should be WONTFIX.  OTOH it might be handled by

  /* Do not warn if the access is fully outside of the
 variable.  */
  if (DECL_P (base)
  && ref.size != -1
  && ref.max_size == ref.size
  && (ref.offset + ref.size <= 0
  || (ref.offset >= 0
  && DECL_SIZE (base)
  && TREE_CODE (DECL_SIZE (base)) == INTEGER_CST
  && compare_tree_int (DECL_SIZE (base),
   ref.offset) <= 0)))
continue;

which for whatever reason doesn't handle it?

Will have a look.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Tamar Christina  ---
That should do it.

[Bug c++/81675] [6/7 Regression] attribute(noreturn) of destructor in :? not honored

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[6/7/8 Regression]  |[6/7 Regression]
   |attribute(noreturn) of  |attribute(noreturn) of
   |destructor in :? not|destructor in :? not
   |honored |honored

[Bug target/81613] [7 regression] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O3 -g execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/81613] [7 regression] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O3 -g execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P2  |P4

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/81575] [7/8 Regression] ICE on C++ code: in cp_build_addr_expr_1, at cp/typeck.c:5793

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[tnfchris at gcc dot gnu.org]

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

--- Comment #11 from Tamar Christina  ---
Author: tnfchris
Date: Thu Dec  7 14:54:22 2017
New Revision: 255468

URL: https://gcc.gnu.org/viewcvs?rev=255468=gcc=rev
Log:
2017-12-07  Tamar Christina  

PR target/82641
* config/arm/arm.c (INCLUDE_STRING): Define.
(arm_last_printed_arch_string, arm_last_printed_fpu_string): New.
(arm_declare_function_name): Conservatively emit .arch,
.arch_extensions
and .fpu.

gcc/testsuite/
2017-12-07  Tamar Christina  

PR target/82641
* gcc.target/arm/pragma_arch_attribute_2.c: New.
* gcc.target/arm/pragma_arch_attribute_2.c: New.
* gcc.target/arm/pragma_arch_attribute_3.c: New.
* gcc.target/arm/pragma_fpu_attribute.c: New.
* gcc.target/arm/pragma_fpu_attribute_2.c: New.


Added:
trunk/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_2.c
trunk/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_3.c
trunk/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute.c
trunk/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute_2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81572] [7/8 Regression] gcc-7 regression: unnecessary vector regmove on compare

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||6.4.0
Version|unknown |7.2.0

[Bug c/81566] [6/7/8 Regression] invalid attribute aligned accepted on functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #6 from Richard Biener  ---
> gcc-6 t.c -S
t.c:6:1: error: requested alignment is not a positive power of 2
 int __attribute__ ((aligned (0))) f (void);
 ^~~
t.c:12:1: error: requested alignment is not a positive power of 2
 int __attribute__ ((aligned (0))) g (void);
 ^~~

> gcc-7 t.c -S

so GCC 6 works for the accepts-invalid.  Splitting the bug might help.

I guess it's reasonable to fix the accepts-invalid even for GCC 7.3.

[Bug target/81481] [7 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #7 from Richard Biener  ---
Patch has been applied to our GCC 7 with no issues sofar (but fixing the
reported issues).

[Bug fortran/81304] [6/7 Regression] Bogus warning with -Wsurprising and -fopenmp: Type specified for intrinsic function 'min' / 'max'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/81197] [7/8 Regression] ICE with structured binding and lifetime-extended temporaries

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/80947] [6/7 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/80907] [6/7 Regression] False positive: "warning: array subscript is above array bounds"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/80026] [6/7/8 Regression] passing unresolved function pointer to variadic function template yields "too many arguments" error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/83302] i386 stack_probe has side effects

[fw at gcc dot gnu.org]

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

--- Comment #5 from Florian Weimer  ---
FWIW, -fstack-clash-protection avoids these issues.

[Bug sanitizer/82046] [7/8 Regression] Bogus -fsanitize=undefined error with -O2 -Wall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Jakub Jelinek  ---
Wontfix then.

[Bug tree-optimization/83312] [8 regression] bogus -Warray-bounds warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r254830.

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Bisected to pauls r254427, the fix for PR81447 and PR82783.

Test adjustments suggest that we'll create even more malloc/free calls.

[Bug target/83297] Internal Compiler Error

[suhubdyd at iro dot umontreal.ca]

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

Dendi Suhubdy  changed:

   What|Removed |Added

 Resolution|INVALID |MOVED

--- Comment #3 from Dendi Suhubdy  ---
Sure thanks, it happened to be specific on Intell Haswell machines, weirdly.

[Bug demangler/83313] New: A whole lot of symbols cannot be demangled

[jeanmichael.celerier at gmail dot com]

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

Bug ID: 83313
   Summary: A whole lot of symbols cannot be demangled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

From my software ; I've got them by running nm -a | c++filt | grep _Z.


_ZN5Nodes5Chord4Node13dispatchChordIZNS1_3runERKN5ossia9midi_portERKN5boost9container8flat_mapIliSt4lessIlENS8_13new_allocatorISt4pairIliERKNS9_IlNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESB_NSC_ISD_IlSO_ERS4_RNS1_5StateENS3_10time_valueENS3_13token_requestERNS3_15execution_stateEEUlDpOT_E0_EEviRKN2mm11MidiMessageEiSU_OT_
_ZN5Nodes5Chord4Node13dispatchChordIZNS1_3runERKN5ossia9midi_portERKN5boost9container8flat_mapIliSt4lessIlENS8_13new_allocatorISt4pairIliERKNS9_IlNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESB_NSC_ISD_IlSO_ERS4_RNS1_5StateENS3_10time_valueENS3_13token_requestERNS3_15execution_stateEEUlDpOT_E_EEviRKN2mm11MidiMessageEiSU_OT_

etc etc... whole list here: https://paste.debian.net/999651/

[Bug target/83302] i386 stack_probe has side effects

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Richard Biener  ---
Invalid.

[Bug target/83302] i386 stack_probe has side effects

[matz at gcc dot gnu.org]

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

--- Comment #3 from Michael Matz  ---
In any case, this is not something that GCC could do anything about.  A probe
necessarily has to be a write, and writing to something not belonging to own
stack (or guard page) will always have this problem of seemingly destroying
other data.  The non-atomicness of this particular read-mod-write instruction
doesn't enter the picture.

[Bug target/83302] i386 stack_probe has side effects

[matz at gcc dot gnu.org]

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

--- Comment #2 from Michael Matz  ---
I guess the problem described in https://lkml.org/lkml/2017/11/10/188 is, that
the stack probe itself accesses a page which _doesn't_ belong to this threads
stack, but to something else.  golang seems to use tiny stacks without guard
page, and the very idea of -fstack-check is that those probe instructions
either
access the own stack, or the guard page, but never anything else.

So, it's mismatching assumptions between golang and gcc's idea of stack layout,
they are simply incompatible.  I think not using guard pages in golang is not a
very good idea.

[Bug tree-optimization/83312] [8 regression] bogus -Warray-bounds warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-07
 CC||msebor at gcc dot gnu.org
  Component|middle-end  |tree-optimization
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Only jump threading figures it out, VRP has issues with encoding the branches
in ranges (as usual).

GCC 7 has the same range info but for some reason doesn't warn.  Possibly
array-at-struct-end handling improvements exposed this false positive.

[Bug tree-optimization/67769] [6 Regression] VRP pass does wrong optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  7 13:21:51 2017
New Revision: 255466

URL: https://gcc.gnu.org/viewcvs?rev=255466=gcc=rev
Log:
2017-12-07  Richard Biener  

PR tree-optimization/83296
PR tree-optimization/67769
* tree-ssa-phiopt.c (conditional_replacement): Do not reset
flow sensitive info in an unrelated BB.
(value_replacement): Use reset_flow_sensitive_info.
(minmax_replacement): Reset flow sensitive info on the def
we move.  Do not reset flow sensitive info in the whole BB
we move the stmt to.
(abs_replacement): Likewise.

* g++.dg/warn/Wstringop-overflow-1.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wstringop-overflow-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/83296] missing -Wstringop-overflow due to missing range info for MAX_EXPR

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  7 13:21:51 2017
New Revision: 255466

URL: https://gcc.gnu.org/viewcvs?rev=255466=gcc=rev
Log:
2017-12-07  Richard Biener  

PR tree-optimization/83296
PR tree-optimization/67769
* tree-ssa-phiopt.c (conditional_replacement): Do not reset
flow sensitive info in an unrelated BB.
(value_replacement): Use reset_flow_sensitive_info.
(minmax_replacement): Reset flow sensitive info on the def
we move.  Do not reset flow sensitive info in the whole BB
we move the stmt to.
(abs_replacement): Likewise.

* g++.dg/warn/Wstringop-overflow-1.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wstringop-overflow-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/83296] missing -Wstringop-overflow due to missing range info for MAX_EXPR

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.