[Bug c++/84281] Heap grows indefinitely

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 12 07:31:56 2018
New Revision: 257580

URL: https://gcc.gnu.org/viewcvs?rev=257580=gcc=rev
Log:
2018-02-12  Richard Biener  

PR c++/84281
* constexpr.c (cxx_eval_vec_init_1): Use a RANGE_EXPR to compact
uniform constructors and delay allocating them fully.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug target/83760] [8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-12
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #7 from Eric Gallager  ---
(In reply to Marat Zakirov from comment #6)
> Created attachment 33446 [details]
> Proposed patch
> 
> According to https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00061.html I
> think this bug should be closed as invalid. If you want libsanitizer to
> assert when meet -fexceptions you may use attached patch.

OK closing as INVALID then

[Bug target/78459] [7/8 Regression] [SH] ICE in maybe_record_trace_start building glibc string tests

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
More likely this is an RTX_FRAME_RELATED_P insn in a delay slot.

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #12 from Jeffrey A. Law  ---
I'm really starting to think we ought to just handle RTX_FRAME_RELATED_P for
delay slots in a generic way rather than forcing each backend to do it.  I'm
pretty sure that's the problem here as well as with at least one of the SH
bugs.

[Bug debug/59051] DW_tag_restrict_type not used

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

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

--- Comment #4 from Mark Wielaard  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Mark Wielaard from comment #2)
> > Author: mark
> > Date: Tue Aug 19 11:50:55 2014
> > New Revision: 214143
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=214143=gcc=rev
> > Log:
> > Emit DW_tag_restrict_type for restrict-qualified pointers.
> > 
> > gcc/ChangeLog
> > 
> > PR debug/59051
> > * dwarf2out.c (modified_type_die): Handle TYPE_QUAL_RESTRICT.
> > 
> > gcc/testsuite/ChangeLog
> > 
> > PR debug/59051
> > * gcc.dg/guality/restrict.c: New test.
> 
> Did this fix this?

Yes, it did indeed.

[Bug target/83785] sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Almost certainly a problem with frame related insns in delay slots.  While in
the past some ports have handled this in their define_delay descriptions.  I
really wonder if it belongs in generic bits created by genattrtab.

[Bug c++/84325] New: internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740

[ababakhar at gmail dot com]

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

Bug ID: 84325
   Summary: internal compiler error, in
cxx_eval_constant_expression gcc/cp/constexpr.c:4740
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ababakhar at gmail dot com
  Target Milestone: ---

~/tests/c++/bug2$ cat test.ii
struct seconds { int i_{0}; };
template  constexpr seconds operator""_s() {
  return seconds(0);
}
constexpr seconds operator""_s(long double i) {
  return seconds();
}
template
struct Param {
  constexpr static seconds time_to_wait{10_s};
};
struct Empty {};
Param p;

~/tests/c++/bug2$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/spare/local/suzutrade/opt/gcc/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/spare/local/suzutrade/opt/gcc
--with-mpfr=/spare/local/suzutrade/opt/mpfr
--with-mpc=/spare/local/suzutrade/opt/mpc
--with-gmp=/spare/local/suzutrade/opt/gmp
Thread model: posix
gcc version 8.0.1 20180210 (experimental) (GCC) 

~/tests/c++/bug2$ g++ test.ii
test.ii:10:45: internal compiler error: unexpected expression ‘(const
seconds)operator""_s<'1', '0'>()’ of kind implicit_conv_expr
   constexpr static seconds time_to_wait{10_s};
 ^
0x821cb0 cxx_eval_constant_expression
../.././gcc/cp/constexpr.c:4740
0x8244e7 cxx_eval_outermost_constant_expr
../.././gcc/cp/constexpr.c:4800
0x9b93f2 store_init_value(tree_node*, tree_node*, vec**, int)
../.././gcc/cp/typeck2.c:833
0x84f2da check_initializer
../.././gcc/cp/decl.c:6378
0x8671a0 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../.././gcc/cp/decl.c:6931
0x87d88c grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../.././gcc/cp/decl2.c:993
0x8f3d0e cp_parser_member_declaration
../.././gcc/cp/parser.c:23871
0x8f4c9a cp_parser_member_specification_opt
../.././gcc/cp/parser.c:23345
0x8f4c9a cp_parser_class_specifier_1
../.././gcc/cp/parser.c:22487
0x8f6cf9 cp_parser_class_specifier
../.././gcc/cp/parser.c:22739
0x8f6cf9 cp_parser_type_specifier
../.././gcc/cp/parser.c:16745
0x903e86 cp_parser_decl_specifier_seq
../.././gcc/cp/parser.c:13606
0x9085c5 cp_parser_single_declaration
../.././gcc/cp/parser.c:27051
0x90894c cp_parser_template_declaration_after_parameters
../.././gcc/cp/parser.c:26743
0x90920c cp_parser_explicit_template_declaration
../.././gcc/cp/parser.c:26980
0x90920c cp_parser_template_declaration_after_export
../.././gcc/cp/parser.c:26999
0x90e579 cp_parser_declaration
../.././gcc/cp/parser.c:12710
0x90e861 cp_parser_declaration_seq_opt
../.././gcc/cp/parser.c:12637
0x90eb54 cp_parser_translation_unit
../.././gcc/cp/parser.c:4559
0x90eb54 c_parse_file()
../.././gcc/cp/parser.c:38857
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/59051] DW_tag_restrict_type not used

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Mark Wielaard from comment #2)
> Author: mark
> Date: Tue Aug 19 11:50:55 2014
> New Revision: 214143
> 
> URL: https://gcc.gnu.org/viewcvs?rev=214143=gcc=rev
> Log:
> Emit DW_tag_restrict_type for restrict-qualified pointers.
> 
> gcc/ChangeLog
> 
>   PR debug/59051
>   * dwarf2out.c (modified_type_die): Handle TYPE_QUAL_RESTRICT.
> 
> gcc/testsuite/ChangeLog
> 
>   PR debug/59051
>   * gcc.dg/guality/restrict.c: New test.
> 
> Added:
> trunk/gcc/testsuite/gcc.dg/guality/restrict.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/dwarf2out.c
> trunk/gcc/testsuite/ChangeLog

Did this fix this?

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[kyukhin at gcc dot gnu.org]

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

--- Comment #12 from Kirill Yukhin  ---
Author: kyukhin
Date: Mon Feb 12 06:14:15 2018
New Revision: 257579

URL: https://gcc.gnu.org/viewcvs?rev=257579=gcc=rev
Log:
Fix AVX-512 popcnt and bitalg tests.

gcc/testsuite/
PR target/83828
* gcc.target/i386/avx512bitalg-vpopcntb-1.c: Fix test.
* gcc.target/i386/avx512bitalg-vpopcntw-1.c: Ditto.
* gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Ditto.
* gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c: Ditto.
* gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512bitalg-vpopcntb-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512bitalg-vpopcntw-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c

[Bug target/83785] sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
So this goes latent with the branch probability updates from Jan 19.  It is
independent of the CSE issue I'm looking at.  It could well be related to delay
slot branching and CFIs.  r256887 should reproduce.

[Bug other/61257] configure should check if sys/sdt.h is usable, not just checking the existance of the header

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Maybe once autoconf 2.70 is released, this bug could be fixed just by updating
to it, since autoconf 2.70 will change all tests for header existence to tests
for header usability.

[Bug target/48576] wrong code when accessing variables in a large stack frame

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from Eric Gallager  ---
(In reply to Mikael Pettersson from comment #8)
> This got fixed for 4.9+ by Bernd Schmidt's "Fix for reloads_unique_chain_p"
> patch in r203596: https://gcc.gnu.org/ml/gcc-patches/2013-10/msg01041.html. 
> The patch submission describes a problem very similar to this one, so I'm
> fairly certain the fix is "proper".
> 
> The patch backports easily to 4.8 and 4.7 and fixes the bug there too.

OK, guess this can be closed as FIXED then.

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

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #32 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #31)
> > Any progress on this?
> > Or shall we just disable completely hot/cold function partitioning
> > on darwin till then?
> 
> IMO it would be better to set the priority to P2.

OK, done

[Bug target/83785] sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-12
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug target/78459] [7/8 Regression] [SH] ICE in maybe_record_trace_start building glibc string tests

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
So I've got a patch for the h8 instance of this problem.  I'll have to see if I
can reproduce the various SH instances and backtest my patch against them.

The situation we were running into was generic code was creating something like

(set (temp) (plus (stack_pointer_rtx) (const)))
(set (stack_pointer_rtx) (temp)  REG_ARGS_SIZE note)

CSE's back propagation would backprop stack_pointer_rtx for temp in the first
insn, the second insn is dead and gets removed.  The result is we lost the
REG_ARGS_SIZE note.  The obvious solution is to move the note during the back
propagation.

My tester has run that through a newlib build on the h8.

[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Mon Feb 12 01:21:39 2018
New Revision: 257575

URL: https://gcc.gnu.org/viewcvs?rev=257575=gcc=rev
Log:
PR c++/84036 - ICE with variadic capture.

Handle variadic capture proxies more like non-variadic.
* lambda.c (build_capture_proxy): Remove workaround.
* pt.c (find_parameter_packs_r): The proxy is a pack.
(instantiate_class_template_1): Remove dead lambda code.
(extract_fnparm_pack): Don't make_pack_expansion.
(extract_locals_r): Don't strip a pack expansion.
(tsubst_pack_expansion): Handle proxy packs.  Use
PACK_EXPANSION_EXTRA_ARGS less.
(tsubst_decl) [FIELD_DECL]: Don't register_specialization.
(tsubst_copy) [FIELD_DECL]: Don't retrieve*_specialization.
[VAR_DECL]: Handle ARGUMENT_PACK_SELECT.
(tsubst_expr) [DECL_EXPR]: Handle proxy packs.
(tsubst_copy_and_build) [VAR_DECL]: Handle proxy packs normally.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/cp/pt.c

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #11 from Segher Boessenkool  ---
Thanks for committing it!

I think it can be closed now yes.

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[munroesj at gcc dot gnu.org]

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

--- Comment #10 from Steven Munroe  ---
Change this to RESOLVED state now?

[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9

[munroesj at gcc dot gnu.org]

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

--- Comment #9 from Steven Munroe  ---
Author: munroesj
Date: Sun Feb 11 21:45:39 2018
New Revision: 257571

URL: https://gcc.gnu.org/viewcvs?rev=257571=gcc=rev
Log:
Fix PR 84266


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/mmintrin.h

[Bug c++/77771] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2090

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #5 from Volker Reichelt  ---
*** Bug 83231 has been marked as a duplicate of this bug. ***

[Bug c++/83231] ICE on constexpr evaluation

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||reichelt at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Volker Reichelt  ---
This is a duplicate of PR1.

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

[Bug fortran/54223] Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls

[rofirrim at gmail dot com]

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

--- Comment #5 from Roger Ferrer Ibanez  ---
(In reply to kargl from comment #3)
> I have a patch.  Sorry, it took so long to fix.

No worries, thanks for fixing it!

[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||reichelt at gcc dot gnu.org
  Known to work||6.4.0
 Resolution|--- |DUPLICATE
   Target Milestone|--- |6.4
  Known to fail||6.3.0

--- Comment #15 from Volker Reichelt  ---
This was fixed in GCC 6.4.0, possibly by the fix for PR79681.

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

[Bug c++/79681] [6 Regression] ICE with constexpr and bitfield

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||chet.simpson at gmail dot com

--- Comment #11 from Volker Reichelt  ---
*** Bug 57335 has been marked as a duplicate of this bug. ***

[Bug c++/55004] [meta-bug] constexpr issues

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 57335, which changed state.

Bug 57335 Summary: internal compiler error: in cxx_eval_bit_field_ref, at 
cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 11 19:07:55 2018
New Revision: 257568

URL: https://gcc.gnu.org/viewcvs?rev=257568=gcc=rev
Log:
Commit ChangeLog entries forgotten in r257566.

2018-02-11  Francois-Xavier Coudert  

PR fortran/35299
ChangeLog for r257566
* gfortran.dg/statement_function_3.f: New test.

2018-02-11  Francois-Xavier Coudert  

PR fortran/35299
ChangeLog for r257566
* resolve.c (resolve_formal_arglist): Update error message.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 11 18:55:31 2018
New Revision: 257566

URL: https://gcc.gnu.org/viewcvs?rev=257566=gcc=rev
Log:
2018-02-11  Francois-Xavier Coudert  

PR fortran/35299
* gfortran.dg/statement_function_3.f: New test.

2018-02-11  Francois-Xavier Coudert  

PR fortran/35299
* resolve.c (resolve_formal_arglist): Update error message.

Added:
trunk/gcc/testsuite/gfortran.dg/statement_function_3.f
Modified:
trunk/gcc/fortran/resolve.c

[Bug fortran/54223] Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 11 18:44:05 2018
New Revision: 257565

URL: https://gcc.gnu.org/viewcvs?rev=257565=gcc=rev
Log:
2018-02-11  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* interface.c (compare_actual_formal): Add in_statement_function
bool parameter.  Skip check of INTENT attribute for statement
functions.  Arguments to a statement function cannot be optional,
issue error for missing argument.
(gfc_procedure_use, gfc_ppc_use, gfc_arglist_matches_symbol): Use
in_statement_function.

2018-02-11  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* gfortran.dg/statement_function_1.f90: New test.
* gfortran.dg/statement_function_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/statement_function_1.f90
trunk/gcc/testsuite/gfortran.dg/statement_function_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84276] Invalid error for valid statement function

[kargl at gcc dot gnu.org]

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

--- Comment #15 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 11 18:44:05 2018
New Revision: 257565

URL: https://gcc.gnu.org/viewcvs?rev=257565=gcc=rev
Log:
2018-02-11  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* interface.c (compare_actual_formal): Add in_statement_function
bool parameter.  Skip check of INTENT attribute for statement
functions.  Arguments to a statement function cannot be optional,
issue error for missing argument.
(gfc_procedure_use, gfc_ppc_use, gfc_arglist_matches_symbol): Use
in_statement_function.

2018-02-11  Steven G. Kargl  

PR fortran/54223
PR fortran/84276
* gfortran.dg/statement_function_1.f90: New test.
* gfortran.dg/statement_function_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/statement_function_1.f90
trunk/gcc/testsuite/gfortran.dg/statement_function_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-11
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Confirmed even if I recover only a factor 2.

[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

--- Comment #31 from Dominique d'Humieres  ---
> Any progress on this?
> Or shall we just disable completely hot/cold function partitioning
> on darwin till then?

IMO it would be better to set the priority to P2.

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk. Thanks for the report.

Paul

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sun Feb 11 18:22:24 2018
New Revision: 257564

URL: https://gcc.gnu.org/viewcvs?rev=257564=gcc=rev
Log:
2018-02-11  Paul Thomas  

PR fortran/84074
* trans-expr.c (gfc_conv_derived_to_class): Set the use_offset
flag. If the is a vector subscript or the expression is not a
variable, make the descriptor one-based.

2018-02-11  Paul Thomas  

PR fortran/84074
* gfortran.dg/type_to_class_5.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/type_to_class_5.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/84324] New: objc/execute/exceptions/matcher-1.m:27:10: warning: return with a value, in function returning void

[hjl.tools at gmail dot com]

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

Bug ID: 84324
   Summary: objc/execute/exceptions/matcher-1.m:27:10: warning:
return with a value, in function returning void
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

objc/execute/exceptions/matcher-1.m has

void
my_exception_matcher(Class match_class, id exception)
{
  /* Always matches.  */
  return 1;
}

/export/gnu/import/git/sources/gcc/gcc/testsuite/objc/execute/exceptions/matcher-1.m:
In function \u2018my_exception_matcher\u2019:
/export/gnu/import/git/sources/gcc/gcc/testsuite/objc/execute/exceptions/matcher-1.m:27:10:
warning: \u2018return\u2019 with a value, in function returning void

This function should return int.  Otherwise, test will fail.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[juergen.reuter at desy dot de]

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

--- Comment #23 from Jürgen Reuter  ---
All our code is fine also with this fix.

[Bug libstdc++/84323] New: call_once uses TLS even when once_flag is set

[antoshkka at gmail dot com]

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

Bug ID: 84323
   Summary: call_once uses TLS even when once_flag is set
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Disassembly of the following code:

#include 

std::once_flag once;

int* foo() {
static int* p{};
std::call_once(once,[](){
p = 0;
});

return p;
}

shows that a lot of work is going on the hot path. TLS is used (twice) and
there is a function call:

  mov QWORD PTR [rsp+8], rax
  mov rax, QWORD PTR std::__once_callable@gottpoff[rip]
  mov QWORD PTR fs:[rax], rdx
  mov rax, QWORD PTR std::__once_call@gottpoff[rip]
  mov QWORD PTR fs:[rax], OFFSET FLAT:void
std::call_once(std::once_flag&,
foo()::{lambda()#1}&&)::{lambda()#2}::_FUN()
  mov eax, OFFSET FLAT:__gthrw___pthread_key_create(unsigned int*, void
(*)(void*))
  test rax, rax
  je .L6
  mov esi, OFFSET FLAT:__once_proxy
  mov edi, OFFSET FLAT:once
  call __gthrw_pthread_once(int*, void (*)())

This seems to be suboptimal, as double-checked-like locking could be used
without TLS + 'call' usage on a hot path. std::call_once could be implemented
just like thread safe static local variables resulting in a much better
disassembly on a hot path:

  movzx eax, BYTE PTR once
  test al, al
  je .L9; not called

[Bug c++/84322] New: -fstrong-eval-order violated on assignment with function call

[chortos at inbox dot lv]

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

Bug ID: 84322
   Summary: -fstrong-eval-order violated on assignment with
function call
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chortos at inbox dot lv
  Target Milestone: ---

The following C++ code:

extern int a[10];
int g();
void f() {
a[a[1]] = g();
}

generates the following assembler code on amd64 Darwin with -O3 -std=c++17
(with or without an explicit -fstrong-eval-order, which should be implied if I
understand correctly):

movq_a@GOTPCREL(%rip), %rbp
movslq  4(%rbp), %rbx
call__Z1gv
movl%eax, 0(%rbp,%rbx,4)

and the following with -O0 -std=c++17:

movq_a@GOTPCREL(%rip), %rax
movl4(%rax), %ebx
call__Z1gv
movl%eax, %ecx
movq_a@GOTPCREL(%rip), %rax
movslq  %ebx, %rdx
movl%ecx, (%rax,%rdx,4)

In both cases, the a[1] is evaluated before the g() call, which contradicts the
strong right-to-left order of assignment operands guaranteed/required by C++17.
If g() modifies a[1], the program can observe the difference:

int a[10];
int g() {
return a[1] = 2;
}
void f();
int main() {
f();
__builtin_printf("%d %d\n", a[1], a[2]);
}

produces "2 0" when compiled with GCC 7 but "2 2" when compiled with Clang 5,
which (intentionally or not) evaluates the operands in the correct order.

Here are my gcc -v and uname -a, which I doubt will be useful but are requested
on https://gcc.gnu.org/bugs/:

$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/7.3.0/libexec/gcc/x86_64-apple-darwin10.8.0/7.3.0/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: ../configure --build=x86_64-apple-darwin10.8.0
--prefix=/usr/local/Cellar/gcc/7.3.0
--libdir=/usr/local/Cellar/gcc/7.3.0/lib/gcc/7
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-7
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
7.3.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-dwarf2 --disable-nls
Thread model: posix
gcc version 7.3.0 (Homebrew GCC 7.3.0) 

$ uname -a
Darwin [hostname].local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

For reference, I have also tried GCC 6.3.0 and 5.1.0 (which do not understand
-fstrong-eval-order but do understand -std=c++17), and they use the same order
as GCC 7.3.0.

[Bug target/78459] [7/8 Regression] [SH] ICE in maybe_record_trace_start building glibc string tests

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
So I'm chasing two instances of this down as well in my tester, h8 and rx.  On
the H8 it looks like we remove a bunch of insns with REG_ARGS_SIZE notes, then
later crossjump the call itself and subsequent argument poping.  This leads to
inconsistent CFI state at the call.

Not sure what the rx issue is yet, but I suspect it's different since it's an
ACCUMULATE_OUTGOING_ARGS target.

[Bug c++/47488] sorry, unimplemented: string literal in function template signature

[sergey.ignatchenko at ithare dot com]

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

sergey.ignatchenko at ithare dot com changed:

   What|Removed |Added

 CC||sergey.ignatchenko at ithare 
dot c
   ||om

--- Comment #12 from sergey.ignatchenko at ithare dot com ---
FWIW, the same test case still fails under GCC 7.2.0. Moreover, I ran into
something-very-similar when playing with
constexpr-function-of-string-literal-as-a-template-parameter; IMO, with advent
of C++17 and constexpr functions this bug started to be significantly more
important - please consider raising priority. 

Oh, and it does compile under Clang (at least Apple Clang 9.0.0).

[Bug c/84321] ice in intersect_range_with_nonzero_bits, at tree-vrp.c:213

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
svn blame produced this for tree-vrp.c:213

257491   rsandifo   gcc_checking_assert (wi::le_p (*min, *max, sgn));

[Bug c/84321] ice in intersect_range_with_nonzero_bits, at tree-vrp.c:213

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced code:

*a;
b, c;
d() {
  int e = 0;
  if (b == 1)
return;
  for (; e < (b & ~7); e += 8)
;
  for (++e; e < b;)
c = a[e];
}

The problem seems to occur between revisions 257477 and 257519.

[Bug c/84321] New: ice in intersect_range_with_nonzero_bits, at tree-vrp.c:213

[dcb314 at hotmail dot com]

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

Bug ID: 84321
   Summary: ice in intersect_range_with_nonzero_bits, at
tree-vrp.c:213
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 43391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43391=edit
C source code

For the attached code, on recent gcc trunk, with compiler flags -O3 and
-fwrapv,
does this:

src/client/refresh/files/stb_image.h:2815:17: internal compiler error: in
intersect_range_with_nonzero_bits, at tree-vrp.c:213
0x6b5d59 intersect_range_with_nonzero_bits(value_range_type,
generic_wide_int*, generic_wide_int*,
generic_wide_int const&, signop)
../../trunk/gcc/tree-vrp.c:213
0x18f51c0 split_constant_offset_1
../../trunk/gcc/tree-data-ref.c:728
0x18f55a6 split_constant_offset(tree_node*, tree_node**, tree_node**)
../../trunk/gcc/tree-data-ref.c:782
0x18f4e34 split_constant_offset_1
../../trunk/gcc/tree-data-ref.c:617

I will have my usual go at reducing the code and finding a range 
of revisions for the problem.

[Bug fortran/65825] Cannot change attributes intrinsic

[rofirrim at gmail dot com]

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

Roger Ferrer Ibanez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Roger Ferrer Ibanez  ---
I should have read the standard more carefully. Fortran 2003 draft §11.2.1 says
(similarly in Fortran 95 except for the two new attributes)

  "The local identifier of an entity made accessible by a USE statement shall
not appear in any other nonexecutable statement that would cause any attribute
(5.1.2) of the entity to be specified in the scoping unit that contains the USE
statement, except that it may appear in a PUBLIC or PRIVATE statement in the
scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE
attribute."

Also, earlier in §11.2 it says

  "If an intrinsic procedure is declared in the scoping unit of a module, it
shall explicitly be given the INTRINSIC attribute in that scoping unit or be
used as an intrinsic procedure in that scoping unit."

Because of this, I believe gfortran is doing nothing wrong here. I'm closing
this as invalid.

Sorry for the fuss.

Kind regards,
Roger

[Bug c/84173] Support glibc multiarch interpreter names

[javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net]

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

Javier Serrano Polo  
changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #15 from Javier Serrano Polo 
 ---
There is a patch, thus wontfix is the right status.