[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to Rafael Avila de Espindola from comment #11)
> (In reply to Martin Liška from comment #10)
> > > That said, I'm willing to ack it for GCC9 even then if upstream comes up
> > > with something or if they don't care, eventually as a GCC only tweak.
> > 
> > Works for me. Note that so far there has been no reply to my patch.
> 
> You might want to CC:
>  Filipe Cabecinhas 

I've just done that, thanks.

[Bug c++/86648] [9 Regression] ICE on class template argument deduction

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #8 from Alexandre Oliva  ---
Fixed

[Bug c++/87768] [8 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19002 when using concepts

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |tsubst_copy_and_build, at   |tsubst_copy_and_build, at
   |cp/pt.c:19002 when using|cp/pt.c:19002 when using
   |concepts|concepts

--- Comment #4 from Alexandre Oliva  ---
Fixed in the trunk

Submitted patches and discussion starting at:
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01782.html
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00979.html

[Bug c++/87768] [8/9 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19002 when using concepts

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Jan 17 07:32:29 2019
New Revision: 268006

URL: https://gcc.gnu.org/viewcvs?rev=268006=gcc=rev
Log:
[PR87768] reset location wrapper suppression when reentering top level

Concepts-checking and other kinds of early tsubsting may often take
place while location wrappers are suppressed, e.g. because we've
triggered template instantiation within template parameter lists.

With that, exprs that are usually wrapped by VIEW_CONVERT_EXPRs
location wrappers may end up wrapped by NON_LVALUE_EXPRs that are not
marked as location wrappers.  If such NON_LVALUE_EXPRs tsubsted exprs
undergo another round of tsubsting, say for constraint checking, or
even for another round of specialization, they will be rejected by
tsubst_copy_and_build.

This patch arranges for suppress_location_wrappers to be saved and
reset when pushing to the top level, and restored when popping from
it.


for  gcc/cp/ChangeLog

PR c++/87768
* cp-tree.h (saved_scope): Add suppress_location_wrappers.
* name-lookup.c (do_push_to_top_level): Save and reset it.
(do_pop_from_top_level): Restore it.

for  gcc/testsuite/ChangeLog

PR c++/87768
* g++.dg/concepts/pr87768.C: New.

Added:
trunk/gcc/testsuite/g++.dg/concepts/pr87768.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/86648] [9 Regression] ICE on class template argument deduction

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Jan 17 07:32:16 2019
New Revision: 268005

URL: https://gcc.gnu.org/viewcvs?rev=268005=gcc=rev
Log:
[PR86648] use auto identifier for class placeholder templates

dwarf2out recognizes unspecified auto types by the identifier.  C++
template class placeholders are unspecified auto types that take the
identifier of the class rather than those used by preexisting auto
types, so dwarf2out ICEs when it finds one of those.  Alas, they may
be visible to dwarf2out, since the types of e.g. static data members
of templates are only deduced at member instantiation, i.e., if the
data member is actually referenced, but the data member is added as a
field, still with unspecified auto placeholder type, when the
enclosing class is instantiated.

I've changed placeholder creator to use an auto identifier instead,
which allowed dropping the placeholder test in C++'s is_auto (alas, it
can't be used in dwarf2out, think LTO).  To avoid losing information
in error messages and dumps and whatnot, I've added code to recognize
placeholders for template classes say A and print them out as
A<...auto...>.

for  gcc/cp/ChangeLog

PR c++/86648
* pt.c (make_template_placeholder): Use auto_identifier.
(is_auto): Drop CLASS_PLACEHOLDER_TEMPLATE test.
* error.c (dump_type): Handle template placeholders.
* cxx-pretty-print.c (pp_cx_unqualified_id): Likewise.

for  gcc/testsuite/ChangeLog

PR c++/86648
* gcc.dg/cpp1z/pr86648.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/pr86648.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/88643] -Wl,--wrap not supported with LTO

[sebastian.hu...@embedded-brains.de]

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

Sebastian Huber  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #2 from Sebastian Huber  ---
Is this somehow related to the problem that the LD --wrap does not work for
references internal to a translation unit? See:

https://www.sourceware.org/ml/binutils/2018-12/msg00210.html

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=4ea904edb7b04ad526bd8a5401729a6c1f5a982f

[Bug c++/87770] [8/9 Regression] ICE in type_dependent_expression_p, at cp/pt.c:25230

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
Created attachment 45448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45448=edit
Candidate patch

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Kamlesh Kumar from comment #9)
> $./ccppc -mcpu=e6500 -mabi=elfv2 -msoft-float -m64 test.c

Maybe it is because not many people use soft-float with 64bit which explains
why this has not been seen before.

I don't know of a a 64bit PowerPC which does not have a FPU.  The only place
where soft-float is used is inside the kernel and almost nobody if any uses
float in there.

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[kamleshbhalui at gmail dot com]

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

--- Comment #9 from Kamlesh Kumar  ---
following testcase produces wrong result

$cat test.c

#include 
int main () {
unsigned int x=-1;
double d=x;
printf("%lf",d); 
return 0;
}

$./ccppc -mcpu=e6500 -mabi=elfv2 -msoft-float -m64 test.c

$./a.out
9223372036854775810.00

while Expected output is:
4294967295.00

[Bug c++/88146] ice in tsubst_copy, at cp/pt.c:16014

[aoliva at gcc dot gnu.org]

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

--- Comment #12 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Jan 17 04:49:55 2019
New Revision: 268004

URL: https://gcc.gnu.org/viewcvs?rev=268004=gcc=rev
Log:
[PR88146] avoid diagnostics diffs if cdtor_returns_this

Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms.  Specifically, on ARM, the diagnostics within the subtest
derived_ctor::inherited_derived_ctor::constexpr_noninherited_ctor did
not match those displayed on other platforms, and the test failed.

The difference seemed to have to do with locations assigned to ctors,
but it was more subtle: on ARM, the instantiation of bor's template
ctor was nested within the instantiation of bar's template ctor
inherited from bor.  The reason turned out to be related with the
internal return type of ctors: arm_cxx_cdtor_returns_this is enabled
for because of AAPCS, while cxx.cdtor_returns_this is disabled on most
other platforms.  While convert_to_void returns early with a VOID
expr, the non-VOID return type of the base ctor CALL_EXPR causes
convert_to_void to inspect the called decl for nodiscard attributes:
maybe_warn_nodiscard -> cp_get_fndecl_from_callee ->
maybe_constant_init -> cxx_eval_outermost_constant_expr ->
instantiate_constexpr_fns -> nested instantiation.

The internal return type assigned to a cdtor should not affect
instantiation (constexpr or template) decisions, IMHO.  We know it
affects diagnostics, but I have a hunch this might bring deeper issues
with it, so I've arranged for the CALL_EXPR handler in convert_to_void
to disregard cdtors, regardless of the ABI.


for  gcc/cp/ChangeLog

PR c++/88146
* cvt.c (convert_to_void): Handle all cdtor calls as if
returning void.

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

[Bug target/61593] Support '#pragma mark - foo' on non-Darwin targets (by simply ignoring it without warning)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #5 from Eric Gallager  ---
It should be pretty easy; in config/darwin.h #pragma mark is registered as part
of the DARWIN_REGISTER_TARGET_PRAGMAS() macro like this:

if (!flag_preprocess_only)  \
  cpp_register_pragma (parse_in, NULL, "mark",  \
   darwin_pragma_ignore, false);

...and then darwin_pragma_ignore() is a simple no-op declared in
config/darwin-protos.h and defined in config/darwin-c.c. So I guess it'd just
have to be re-titled and moved somewhere generic?

Submitting Your Manuscripts

[Journal member]

Dear Researcher or Professor,
We publish peer-reviewed international scientific journals devoted to
promoting the development of science and technology. Now we sincerely
invite scholars and researchers to submit papers to the journals or to join
in the editorial board/reviewer team.
Join the Editorial Board/Reviewers Team
In order to expand the editorial board and reviewer group, we would like to
invite you to be our editorial member or reviewer of our journals with
great sincerity. For more details about the Benefits and Responsibilities
of the editorial member or reviewer, please feel free to visit the
following link:
http://www.ijovs.org/journals
Submitting Your Research Paper
We have published 200+ online, peer-reviewed journals. If you have some new
works in your specialized or interested field, welcome to submit your
papers to the corresponding Journals or Special Issues so as to share your
ideas with people around the world.
Journal Lists

   1. American Journal of Chemical Engineering
   2. International Journal of Education, Culture and Society
   3. International Journal of Sustainable Development Research
   4. American Journal of BioScience
   5. International Journal of Clinical and Experimental Medical Sciences
   6. International Journal of Environmental Monitoring and Analysis
   7. International Journal of Intelligent Information Systems
   8. American Journal of Management Science and Engineering

Please feel free to contact us if you have any questions.
Warm regards,
Jessie Wright

[Bug testsuite/87306] test case gcc.dg/vect/bb-slp-pow-1.c fails with its introduction in r263290

[linkw at gcc dot gnu.org]

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

--- Comment #4 from Kewen Lin  ---
Author: linkw
Revision: 268003
Modified property: svn:log

Modified: svn:log at Thu Jan 17 03:24:27 2019
--
--- svn:log (original)
+++ svn:log Thu Jan 17 03:24:27 2019
@@ -1,10 +1,5 @@
-
 PR target/87306
 * gcc.dg/vect/bb-slp-pow-1.c: Modify to reflect that
 the loop is not vectorized on POWER unless hardware 
 misaligned loads are available.

---T his line, and those below, will be ignored--
-
-Mgcc/testsuite/ChangeLog
-Mgcc/testsuite/gcc.dg/vect/bb-slp-pow-1.c

[Bug testsuite/87306] test case gcc.dg/vect/bb-slp-pow-1.c fails with its introduction in r263290

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin  ---
Author: linkw
Date: Thu Jan 17 03:03:38 2019
New Revision: 268003

URL: https://gcc.gnu.org/viewcvs?rev=268003=gcc=rev
Log:

PR target/87306
* gcc.dg/vect/bb-slp-pow-1.c: Modify to reflect that
the loop is not vectorized on POWER unless hardware 
misaligned loads are available.

--T his line, and those below, will be ignored--

Mgcc/testsuite/ChangeLog
Mgcc/testsuite/gcc.dg/vect/bb-slp-pow-1.c

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pow-1.c

[Bug c/88887] Warn on unexpected continuation of 'return' to new line in if statement.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-17
 CC||egallager at gcc dot gnu.org
 Blocks||87403
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug middle-end/88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Version|9.0 |8.0

--- Comment #1 from Martin Sebor  ---
-Wstringop-truncation was first introduced in GCC 8.

[Bug middle-end/88780] [8/9 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||7.3.0
Summary|bogus -Wstringop-truncation |[8/9 Regression] bogus
   |for copying as many bytes   |-Wstringop-truncation for
   |from a string as its length |copying as many bytes from
   ||a string as its length
  Known to fail||8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
The Wstringop-truncation warning is new in GCC 8 and is not issued by GCC 7 so
I'm marking this a regression.

[Bug middle-end/88780] bogus -Wstringop-truncation for copying as many bytes from a string as its length

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-17
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug c/86125] missing -Wbuiltin-declaration-mismatch on a mismatched return type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00969.html

[Bug c/88886] [9 Regression] ice in get_constant, at c-family/c-format.c:292

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Updated patch for GCC 9:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00969.html

[Bug middle-end/86308] [7/8/9 Regression] ICE in verify_gimple calling an invalid index() declaration

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Updated patch for GCC 9:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00969.html

[Bug libbacktrace/82857] libbacktrace: please support binaries stripped with dwz -m (following the .gnu_debugaltlink)

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> Author: vries
> Date: Thu Jan 17 00:08:05 2019
> New Revision: 267996
> 
> URL: https://gcc.gnu.org/viewcvs?rev=267996=gcc=rev
> Log:
> [libbacktrace] Handle DW_FORM_GNU_strp_alt
> 
> Handle DW_FORM_GNU_strp_alt which references the .debug_str section in the
> .gnu_debugaltlink file.
> 
> 2019-01-17  Tom de Vries  
> 
>   PR libbacktrace/82857
>   * dwarf.c (read_attribute): Handle DW_FORM_GNU_strp_alt
>   using altlink.
> 
> Modified:
> trunk/libbacktrace/ChangeLog
> trunk/libbacktrace/dwarf.c

This is a partial fix. The DW_FORM_GNU_ref_alt part is still to be reviewed:
"[PATCH 7/9] [libbacktrace] Handle DW_FORM_GNU_ref_alt" @
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00640.html .

[Bug libbacktrace/82857] libbacktrace: please support binaries stripped with dwz -m (following the .gnu_debugaltlink)

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Author: vries
Date: Thu Jan 17 00:08:05 2019
New Revision: 267996

URL: https://gcc.gnu.org/viewcvs?rev=267996=gcc=rev
Log:
[libbacktrace] Handle DW_FORM_GNU_strp_alt

Handle DW_FORM_GNU_strp_alt which references the .debug_str section in the
.gnu_debugaltlink file.

2019-01-17  Tom de Vries  

PR libbacktrace/82857
* dwarf.c (read_attribute): Handle DW_FORM_GNU_strp_alt
using altlink.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/dwarf.c

[Bug fortran/88871] [9 regression] ICE segmentation fault in f951

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Created attachment 45447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45447=edit
Patch that appears to work

This should fix the linked-list problem.

I'll probably submit tomorrow.

[Bug fortran/88871] [9 regression] ICE segmentation fault in f951

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> This bug is the cause of:
> 
> FAIL: experimental/filesystem/operations/canonical.cc execution test

And also:

FAIL: experimental/filesystem/operations/temp_directory_path.cc execution test

because GetTempPathW always returns a directory with a trailing slash.

[Bug c/88886] [9 Regression] ice in get_constant, at c-family/c-format.c:292

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86125
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
The patch posted for bug 86125 fixes this ICE and results in the output below. 
Let me try to revive it.

$ /build/gcc-86125/gcc/xgcc -B /build/gcc-86125/gcc -S pr6.c
pr6.c:1:5: warning: conflicting types for built-in function ‘sscanf’;
expected ‘int(const char *, const char *, ...)’
[-Wbuiltin-declaration-mismatch]
1 | int sscanf(long, unsigned[], ...);
  | ^~
pr6.c:1:1: note: ‘sscanf’ is declared in header ‘’
  +++ |+#include 
1 | int sscanf(long, unsigned[], ...);
pr6.c:1:5: warning: conflicting types for built-in function ‘sscanf’;
expected ‘int(const char *, const char *, ...)’
[-Wbuiltin-declaration-mismatch]
1 | int sscanf(long, unsigned[], ...);
  | ^~
pr6.c: In function ‘a’:
pr6.c:2:22: warning: passing argument 2 of ‘sscanf’ from incompatible
pointer type [-Wincompatible-pointer-types]
2 | void a() { sscanf(0, ""); }
  |  ^~
  |  |
  |  char *
pr6.c:1:18: note: expected ‘unsigned int *’ but argument is of type ‘char
*’
1 | int sscanf(long, unsigned[], ...);
  |  ^~

[Bug fortran/87939] [F18] Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements

[weeks at iastate dot edu]

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

--- Comment #1 from Nathan Weeks  ---
My bad: END CRITICAL does not accept STAT= or ERRMSG= arguments in Fortran
2018.

[Bug c++/88699] [9 Regression] tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00962.html

[Bug libbacktrace/88244] [libbacktrace] Failure to open .gnu_debuglink is silent

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Discussed here ( https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00932.html ).

[Bug libstdc++/88888] New: Cannot construct filesystem::path from variable length array

[redi at gcc dot gnu.org]

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

Bug ID: 8
   Summary: Cannot construct filesystem::path from variable length
array
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

// { dg-options "-std=gnu++17" }
#include 
int main()
{
  int i = 2;
  char vla[i] = {};
  std::filesystem::path p = vla;
}


p.cc: In function 'int main()':
p.cc:7:29: error: conversion from 'char [i]' to non-scalar type
'std::filesystem::__cxx11::path' requested
7 |   std::filesystem::path p = vla;
  | ^~~

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
This bug is the cause of:

FAIL: experimental/filesystem/operations/canonical.cc execution test

The trailing slashes in the paths cause the _wstat calls to fail.

[Bug go/56431] -lpthread should be added to -lgo

[ian at airs dot com]

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

--- Comment #8 from Ian Lance Taylor  ---
The workaround for this is probably to change gcc/go/gospec.c to remove the
need_thread variable.  That would have the effect of changing the only use of
need_thread to only test library > 0, which would mean that gccgo would add
-lpthread every time it adds -lgo.  (I don't plan to try implementing and
testing this myself.)

Optimizer (-O3) Disabling IEEE Exception Handling

[Damian McGuckin]

Hi,

I hope this has not been addressed before but my search returned nothing
the same. I found vaguely related stuff but not this.

I am talking is straightforward optimization, i.e. -O3 (say), which I read 
the manual page to say, does not affect IEEE 754 stuff at all.


The following code

#include 
#include 

int bug()
{
double z;
int test;

feclearexcept(FE_ALL_EXCEPT);
printf("Except %x\n", fetestexcept(FE_ALL_EXCEPT));
z = 1.0 - Tiny;
test = fetestexcept(FE_ALL_EXCEPT);
printf("TEST says %x @%.9e should be %x\n", test, z, FE_INEXACT);

return(0);
}

int main()
{
bug();
return(0);
}

When compiled as just

gcc bug.c -lm

correctly raised the FP_INEXACT (0x20) flag. It produces

Except 0
TEST says 20 @1.0e+00 should be 20

where the first line notes that it starts cleared.

When compiled as

gcc -O3 bug.c -lm

or even
g++ bug.c

The second line produced says

TEST says 0 @1.0e+00 should be 20

There is no exception raised.

What did I do wrong. The -O flags is not supposed to affect that.

Does it need some extra flag? Do I need a much newer version?

The version is 4.8.5-16 (on CentOS 7.4)

Thanks - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

[Bug c/88887] New: Warn on unexpected continuation of 'return' to new line in if statement.

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 7
   Summary: Warn on unexpected continuation of 'return' to new
line in if statement.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
  Target Milestone: ---

A colleague tripped up on this typo:

  void bar();
  void
  foo (int x)
  {
if (x) return

bar ();
  }

Their intention was to return immediately if (x) holds, but they missed the
semicolon after 'return' and because bar() is declared with a void return type
didn't hit any warnings.

In my opinion, it would be reasonable for -wmisleading-indentation to cover a
case like this. The related case:

  void
  foo2 (int x)
  {
if (x)
  return

bar ();
  }

Could also be warned.

[Bug rtl-optimization/88423] [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
The code_label is for a tablejump_p, immediately before the jump_table_data.

[Bug go/88500] [SH]: SETCONTEXT_CLOBBERS_TLS needs to be handled in libgo

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
SETCONTEXT_CLOBBERS_TLS is set by libgo/configure.ac if this program fails to
exit successfully.  So the first step in fixing this bug is finding out why
this program fails on SH.


#include 
#include 
#include 
#include 

__thread int tls;

static char stack[[10 * 1024 * 1024]];
static ucontext_t c;

/* Called via makecontext/setcontext.  */

static void
cfn (void)
{
  exit (tls);
}

/* Called via pthread_create.  */

static void *
tfn (void *dummy)
{
  /* The thread should still see this value after calling
 setcontext.  */
  tls = 0;

  setcontext ();

  /* The call to setcontext should not return.  */
  abort ();
}

int
main ()
{
  pthread_t tid;

  /* The thread should not see this value.  */
  tls = 1;

  if (getcontext () < 0)
abort ();

  c.uc_stack.ss_sp = stack;
#ifdef MAKECONTEXT_STACK_TOP
  c.uc_stack.ss_sp += sizeof stack;
#endif
  c.uc_stack.ss_flags = 0;
  c.uc_stack.ss_size = sizeof stack;
  c.uc_link = NULL;
  makecontext (, cfn, 0);

  if (pthread_create (, NULL, tfn, NULL) != 0)
abort ();

  if (pthread_join (tid, NULL) != 0)
abort ();

  /* The thread should have called exit.  */
  abort ();
}

[Bug c/88726] [7 Regression] GCC thinks that translation unit does not contain a definition of inline function.

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #6 from Joseph S. Myers  ---
Also now fixed for GCC 7.5.

[Bug c/88720] [7 Regression] Strange error message about nested function declared but not defined when using inline.

[jsm28 at gcc dot gnu.org]

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

--- Comment #5 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Jan 16 21:40:33 2019
New Revision: 267987

URL: https://gcc.gnu.org/viewcvs?rev=267987=gcc=rev
Log:
Fix diagnostics for never-defined inline and nested functions (PR c/88720, PR
c/88726).

Bugs 88720 and 88726 report issues where a function is declared inline
in an inner scope, resulting in spurious diagnostics about it being
declared but never defined when that scope is left (possibly in some
cases also wrongly referring to the function as a nested function).
These are regressions that were introduced with the support for C99
inline semantics in 4.3 (they don't appear with 4.2; it's possible
some aspects of the bugs might have been introduced later than 4.3).

For the case of functions being wrongly referred to as nested,
DECL_EXTERNAL was not the right condition for a function being
non-nested; TREE_PUBLIC is appropriate for the case of non-nested
functions with external linkage, while !b->nested means this is the
outermost scope in which the function was declared and so avoids
catching the case of a file-scope static being redeclared inline
inside a function.

For the non-nested, external-linkage case, the code attempts to avoid
duplicate diagnostics by diagnosing only when scope != external_scope,
but actually scope == external_scope is more appropriate, as it's only
when the file and external scopes are popped that the code can
actually tell whether a function ended up being defined, and all such
functions will appear in the (GCC-internal) external scope.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc/c:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* c-decl.c (pop_scope): Use TREE_PUBLIC and b->nested to determine
whether a function is nested, not DECL_EXTERNAL.  Diagnose inline
functions declared but never defined only for external scope, not
for other scopes.

gcc/testsuite:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* gcc.dg/inline-40.c, gcc.dg/inline-41.c: New tests.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/inline-40.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/inline-41.c
Modified:
branches/gcc-7-branch/gcc/c/ChangeLog
branches/gcc-7-branch/gcc/c/c-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/88720] [7 Regression] Strange error message about nested function declared but not defined when using inline.

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #6 from Joseph S. Myers  ---
Also now fixed for GCC 7.5.

[Bug c/88726] [7 Regression] GCC thinks that translation unit does not contain a definition of inline function.

[jsm28 at gcc dot gnu.org]

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

--- Comment #5 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Jan 16 21:40:33 2019
New Revision: 267987

URL: https://gcc.gnu.org/viewcvs?rev=267987=gcc=rev
Log:
Fix diagnostics for never-defined inline and nested functions (PR c/88720, PR
c/88726).

Bugs 88720 and 88726 report issues where a function is declared inline
in an inner scope, resulting in spurious diagnostics about it being
declared but never defined when that scope is left (possibly in some
cases also wrongly referring to the function as a nested function).
These are regressions that were introduced with the support for C99
inline semantics in 4.3 (they don't appear with 4.2; it's possible
some aspects of the bugs might have been introduced later than 4.3).

For the case of functions being wrongly referred to as nested,
DECL_EXTERNAL was not the right condition for a function being
non-nested; TREE_PUBLIC is appropriate for the case of non-nested
functions with external linkage, while !b->nested means this is the
outermost scope in which the function was declared and so avoids
catching the case of a file-scope static being redeclared inline
inside a function.

For the non-nested, external-linkage case, the code attempts to avoid
duplicate diagnostics by diagnosing only when scope != external_scope,
but actually scope == external_scope is more appropriate, as it's only
when the file and external scopes are popped that the code can
actually tell whether a function ended up being defined, and all such
functions will appear in the (GCC-internal) external scope.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc/c:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* c-decl.c (pop_scope): Use TREE_PUBLIC and b->nested to determine
whether a function is nested, not DECL_EXTERNAL.  Diagnose inline
functions declared but never defined only for external scope, not
for other scopes.

gcc/testsuite:
Backport from mainline
2019-01-07  Joseph Myers  

PR c/88720
PR c/88726
* gcc.dg/inline-40.c, gcc.dg/inline-41.c: New tests.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/inline-40.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/inline-41.c
Modified:
branches/gcc-7-branch/gcc/c/ChangeLog
branches/gcc-7-branch/gcc/c/c-decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/88699] [9 Regression] tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug d/87824] x86_64-linux multilib issues

[ibuclaw at gcc dot gnu.org]

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

--- Comment #18 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Jan 16 20:40:21 2019
New Revision: 267985

URL: https://gcc.gnu.org/viewcvs?rev=267985=gcc=rev
Log:
[D] Fix failing EH execution test on i386.

Turn off partitioning unless it was explicitly requested, as it doesn't
work with D exception chaining, where personality routines use LSDA to
determine whether two thrown exceptions are in the same context.

The following distills what was failing in the D testsuite.
```
try {
  try {
fn();  // throws "1"
  }
  finally {
throw new Exception("2");
  }
}
catch (Exception e) {
  assert(e.msg == "1");
  assert(e.next.msg == "2");
}
```

gcc/d/ChangeLog:

PR d/87824
* d-lang.cc (d_post_options): Disable implicit
-forder-blocks-and-partition.

Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-lang.cc

[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline

[will_schmidt at vnet dot ibm.com]

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

Will Schmidt  changed:

   What|Removed |Added

 CC||will_schmidt at vnet dot 
ibm.com

--- Comment #2 from Will Schmidt  ---
Created attachment 45446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45446=edit
another testcase variation...

Another testcase variation.
I've cleaned up/removed some casts that may have been adding to the confusion
earlier.
This test variation exercises the vec_extract against char, short, int types.  
Per inspection, both char and short types appear to show incorrect results when
built with -O2 for power8 or newer.

[Bug c/88886] [9 Regression] ice in get_constant, at c-family/c-format.c:292

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-16
 CC||msebor at gcc dot gnu.org
Version|8.0 |9.0
Summary|ice in get_constant, at |[9 Regression] ice in
   |c-family/c-format.c:292 |get_constant, at
   ||c-family/c-format.c:292
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The ICE was introduced in r266195 (GCC 9):

r266195 | msebor | 2018-11-15 17:53:57 -0500 (Thu, 15 Nov 2018) | 50 lines

PR c++/87541 - ICE using a constant decl as an attribute alloc_size argument
PR c++/87542 - bogus error on attribute format with a named constant argument

gcc/ChangeLog:

PR c++/87541
PR c++/87542
* tree.c (type_argument_type): New function.
* tree.h (type_argument_type): Declare it.
* gcc/doc/extend.texi (alloc_align): Update and clarify.
(alloc_size, nonnull, sentinel): Same.

gcc/c-family/ChangeLog:

PR c++/87541
PR c++/87542
* c-attribs.c (positional_argument): New function.
(handle_alloc_size_attribute): Use it and simplify.
(handle_alloc_align_attribute): Same.
(handle_assume_aligned_attribute): Same.
(handle_nonnull_attribute): Same.
* c-common.c (check_function_arguments): Pass fntype to
check_function_format.
* c-common.h (check_function_format): Add an argument.
(PosArgFlags, positional_argument): Declare new type and function.
* c-format.c (decode_format_attr): Add arguments.
(check_format_string, get_constant): Same.
(convert_format_name_to_system_name): Adjust.

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Should be fixed by r267984.

[Bug c/88886] New: ice in get_constant, at c-family/c-format.c:292

[dcb314 at hotmail dot com]

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

Bug ID: 6
   Summary: ice in get_constant, at c-family/c-format.c:292
   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: ---

For this broken C code:

int sscanf(long, unsigned[], ...);
void a() { sscanf(0, ""); }

recent gcc trunk with flag -Wall does this:

bug496.c:2:1: internal compiler error: in get_constant, at
c-family/c-format.c:2
92
0x5e97e1 get_constant
../../trunk/gcc/c-family/c-format.c:292
0x5e97e1 get_constant
../../trunk/gcc/c-family/c-format.c:280
0x5e97e1 decode_format_attr
../../trunk/gcc/c-family/c-format.c:346

This seems to have been going wrong since sometime before revision 267000.

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jan 16 20:13:23 2019
New Revision: 267984

URL: https://gcc.gnu.org/viewcvs?rev=267984=gcc=rev
Log:
Fix ICE due to "combine" creating unreachable EH blocks (PR target/88861)

PR target/88861 reports an ICE in "ce2" due to an unreachable
basic block.

The block becomes unreachable in "combine" when delete_noop_moves
deletes an insn with a REG_EH_REGION, deleting the EH edge, the
only edge leading to the basic block.

Normally, rest_of_handle_combine would call cleanup_cfg, deleting
unreachable blocks, if combine_instructions returns true, and
combine_instructions does return true for some cases of edge-removal,
but it doesn't for this case, leading to the ICE.

This patch updates delete_noop_moves so that it returns true if
it deletes any edges, and passes that through to combine_instructions,
so that it too will return true if any edges were deleted, ensuring that
cleanup_cfg will be called by rest_of_handle_combine for this case,
deleting the now-unreachable block, and fixing the ICE.

gcc/ChangeLog:
PR target/88861
* combine.c (delete_noop_moves): Convert to "bool" return,
returning true if any edges are eliminated.
(combine_instructions): Also return true if delete_noop_moves
returns true.

gcc/testsuite/ChangeLog:
PR target/88861
* g++.dg/torture/pr88861.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr88861.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83531] Build broken on macOS 10.13.2

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
* thanks for looking at this! (my machines are all tied up right now, so any
testing won't happen before 'tomorrow') 

* apologies if this comes across as negative - but TBH I'm a bit nervous about
applying something like this without wider testing - certainly full reg-straps
on affected systems.

* A visual inspection of the patch, suggests it might be disabling more than is
necessary - GCC has attributes "available" and "deprecated" - it's only
"unavailable" that's currently missing [I have a patch for that somewhere, will
have to dust it off for 10].  (deprecated_with_replacement could be implemented
in terms of deprecated with message).

* I did not need any patch to bootstrap open branches [7, 8, and trunk] on
10.13.6 (in fact, not on any Darwin that supports libsanitizer - bearing in
mind that upstream doesn't support 10.6 now).

* GCC5 is closed, so any patch we might have would be something applied
"locally" to any private branches.

* The underlying issue is that there are a number of problems with system
headers [e.g. missing guards for __has_feature(), missing guards for block
syntax, nullability and lightweight generics, the latter two especially an
issue for objective c].  The problems tend to be dependent on the SDK version,
which is unfortunate because typically one could target 10.13 from 10.14 using
the 10.14 SDK, so the target OS version is not a 100% reliable test (TODO:
investigate whether there's an SDK version that we can easily pick up).

* for tests where there are a large number of problems (e.g. the objective c
stuff in particular, where there are no easy work-arounds), it's my plan to
cook up some proxy headers to allow us to continue to test what *does* work.

* from my investigations, it seems that the underlying issue can be solved by
including the relevant headers (but because of the points above "relevant
headers" depends on the SDK version). So, it might be that there' a small
number of tests for which a workaround will be better.. e.g at present, I have
the following to fix the test

diff --git a/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
b/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
index b2def1e858..7c08ef9c91 100644
--- a/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
+++ b/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
@@ -6,6 +6,12 @@
 /* { dg-do compile { target *-*-darwin* } } */
 /* { dg-options "-ftrack-macro-expansion=0 -mconstant-cfstrings" } */

+#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 101300
+#  include 
+#elif __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 101000
+#  include 
+#endif
+
 #include 

 #ifdef __CONSTANT_CFSTRINGS__

[Bug target/88885] GCC ICE internal compiler error: Segmentation fault in mpd

[raj.khem at gmail dot com]

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

--- Comment #1 from Khem Raj  ---
there are more errors probably same root cause

http://errors.yoctoproject.org/Errors/Details/216895/
http://errors.yoctoproject.org/Errors/Details/216899/

[Bug target/88885] New: GCC ICE internal compiler error: Segmentation fault in mpd

[raj.khem at gmail dot com]

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

Bug ID: 5
   Summary: GCC ICE internal compiler error: Segmentation fault in
mpd
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

Created attachment 45445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45445=edit
test case

While compiling mpd on cortex-a5 machine with gcc 9.0 snapshot from 9-20190113
g++ is segfaulting on attached test case

arm-yoe-linux-musleabi-g++  -march=armv7-a -mfpu=neon -mfloat-abi=hard
--sysroot=/mnt/a/yoe/build/tmp/work/cortexa5t2hf-neon-vfpv4-yoe-linux-musleabi/mpd/0.20.22-r0/recipe-sysroot
a.cpp -c

: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/51310] -finit-bla doesn't initialize *all* items of type bla to the requested constant.

[toon at moene dot org]

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

--- Comment #10 from Toon Moene  ---
On 1/14/19 11:52 PM, dominiq at lps dot ens.fr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
> 
> --- Comment #9 from Dominique d'Humieres  ---
> Output from the test in comment 0 is now
> 
> NaN   0.
> NaN
>   n=   3
>   a=   NaN   NaN
> NaN
>   var=   NaN
>   b=   NaN   NaN
> NaN
>   c=   0.0.0.
> 
> i.e., the allocated allocatable arrays are not initialized.
> 
> Toon do you still want to have this PR assigned to you?
> 
> This PR is also related to pr33430.
> 

Yes, leave it for the time being - I will see if I can do something 
about it (or unassign, if not).

Thanks,

[Bug tree-optimization/86214] [8/9 Regression] Strongly increased stack usage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Looking at the #c7 testcase, confirming that ~ 29KB stack in one of the
functions.  The problem is that msg has char buf[8192]; variable in it and is
inline, gets inlined into a function 3 times and can throw.
ehcleanup1 removes the buf (and str) clobbers that were the only reason to have
an EH pad that just rethrows (and I agree it is a good idea to do that, because
otherwise inliner thinks the functions are more expensive than they actually
are).
But then the function into which this function is ultimately inlined has some
finalization (destructors) covering the code into which it has been inlined, so
the former EH with no successor block because it would throw externally now
becomes EH edge from the code to a landing block onto which everything is
marked as conflicting, there is no clobber at all for the variables.

So, I wonder if we shouldn't add in such cases clobbers to the start of those
landing pads in the situation, either for all variables that live in memory, or
at least for the larger ones.  Will play with it tomorrow.

There is another thing - I've noticed add_stack_var_conflict is often called
with x == y, shouldn't we return right away in that case?  We don't need to
record that a var conflicts with itself, we later on return that no variable
conflicts with itself.

Note, before r255104 we weren't inlining msg into the bigger function and thus
the issue was latent.

The workaround for MySQL, at least for -O2, would be to move logger:msg
definition out from the class, so it is not inline, then at least gcc trunk
doesn't want to inline it and you don't run into this.

[Bug lto/88858] ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox build with LTO and PGO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-16
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Lemme try to fix it.

[Bug c++/65396] Function template default template arguments not merged

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2016-01-24 00:00:00 |2019-1-16

--- Comment #4 from Jonathan Wakely  ---
From PR 88864:

Shorter repro from StackOverflow https://stackoverflow.com/q/54202462/2069064:

struct B {
template B(T t);
};

template 
B::B(T t) { }

B b(3);


This is rejected by all versions of gcc because of an inability to deduce U.

[Bug tree-optimization/88760] GCC unrolling is suboptimal

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #11)
> 
> As an experiment I hacked the AArch64 assembly of the function generated
> with -funroll-loops to replace the peeled prologue version with a simple
> non-unrolled loop. That gave a sizeable speedup on two AArch64 platforms:
> >7%.
> 
> So beyond the vectorisation point Richard S. made above, maybe it's worth
> considering replacing the peeled prologue with a simple loop instead?
> Or at least add that as a distinct unrolling strategy and work to come up
> with an analysis that would allow us to choose one over the other?

Upon reflection I think I may have bungled up the assembly hacking (the changes
I made may not be equivalent to the source). I'll redo that experiment soon, so
please disregard that part for now. The iteration count distribution numbers
are still valid though.

[Bug c++/65396] Function template default template arguments not merged

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #3 from Jonathan Wakely  ---
*** Bug 88864 has been marked as a duplicate of this bug. ***

[Bug c++/88864] default template arguments not merged across all declarations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
.

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

[Bug c++/88864] default template arguments not merged across all declarations

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I'm pretty sure this is a dup of an existing bug.

[Bug libstdc++/88884] New: std::filesystem::absolute("//") does not produce an absolute path on mingw

[redi at gcc dot gnu.org]

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

Bug ID: 4
   Summary: std::filesystem::absolute("//") does not produce an
absolute path on mingw
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The current implementation of filesystem::absolute uses GetFullPathNameW which
turns a path like "//" into "\\", and "a" into "a", which are not
considered absolute by the filesystem::path::is_absolute() function.

The Windows function might be interpreting it as a UNC path (probably an
invalid one) but the std::filesystem library doesn't support UNC names. We
might need special handling in filesystem::absolute, something like:

--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -86,13 +86,24 @@ fs::absolute(const path& p, error_code& ec)
   return ret;
 }
 #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-  const wstring& s = p.native();
+  const wstring& native = p.native();
+  const wchar_t* s = native.c_str();
+  const auto pos = native.find_first_not_of(L"/\\");
+  // If there are multiple directory separators at the start,
+  // skip all but one of them:
+  if (pos > 1)
+{
+  if (pos == native.npos)
+   s += native.length() - 1;
+  else
+   s += pos - 1;
+}
   uint32_t len = 1024;
   wstring buf;
   do
 {
   buf.resize(len);
-  len = GetFullPathNameW(s.c_str(), len, buf.data(), nullptr);
+  len = GetFullPathNameW(s, len, buf.data(), nullptr);
 }
   while (len > buf.size());

[Bug target/88734] [8/9 Regression] AArch64's ACLE intrinsics give an ICE instead of compile error when option mismatch.

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina  ---
Hi Jakub,

Thanks for the patch, I've started a testrun but the fix looks sensible to me.

I'll post the result as soon as it's finished.

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
(In reply to Marek Polacek from comment #4)
> So one idea would to be to walk_tree on the expression at the end of
> finish_decltype_type, looking for compound literals and call check_narrowing.

Scratch this -- I don't know what I did last night but this is not the
solution.  Perhaps we should create DECLTYPE_TYPE in finish_decltype_type when
there's narrowing.

[Bug debug/88046] [9 Regression] ICE in add_data_member_location_attribute at gcc/dwarf2out.c:19237 since r261885

[tnfchris at gcc dot gnu.org]

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

--- Comment #7 from Tamar Christina  ---
Author: tnfchris
Date: Wed Jan 16 17:50:38 2019
New Revision: 267980

URL: https://gcc.gnu.org/viewcvs?rev=267980=gcc=rev
Log:
Fix PR88046 on AArch64 and Arm bare metal targets.

gcc/testsuite/ChangeLog:

PR debug/88046
* g++.dg/lto/pr88046_0.C: Check for shared and fPIC.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/pr88046_0.C

[Bug tree-optimization/88760] GCC unrolling is suboptimal

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Thank you all for the input.

Just to add a bit of data.
I've instrumented 510.parest_r to count the number of loop iterations to get a
feel for how much of the unrolled loop is spent in the actual unrolled part
rather than the prologue/peeled part. Overall, the hot function itself is
entered 290M times. The distribution of loop iteration counts is:

Frequency iter:
92438870  36
87028560  54
20404571  24
17312960  62
14237184  72
13403904  108
7574437   102
7574420   70
5564881   40
4328249   64
4328240   46
3142656   48
2666496   124
1248176   8
1236641   16
1166592   204
1166592   140
1134392   4
 857088   80
 24   92
 24   128
 618320   30
 613056   1
 234464   2
 190464   32
  95232   60
  84476   20
  48272   10
   6896   5

So the two most common iteration counts are 36 and 54. For an 8x unrolled loop
that's 4 and 6 iterations spent in the prologue with 4 and 6 times going around
the 8x unrolled loop respectively.

As an experiment I hacked the AArch64 assembly of the function generated with
-funroll-loops to replace the peeled prologue version with a simple
non-unrolled loop. That gave a sizeable speedup on two AArch64 platforms: >7%.

So beyond the vectorisation point Richard S. made above, maybe it's worth
considering replacing the peeled prologue with a simple loop instead?
Or at least add that as a distinct unrolling strategy and work to come up with
an analysis that would allow us to choose one over the other?

[Bug target/83531] Build broken on macOS 10.13.2

[mcccs at gmx dot com]

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

--- Comment #4 from MCCCS  ---
Iain could you please test if this patch works for you
too? If so, I'll send it as a patch tomorrow
(For me, it even fixes g++.dg/other/darwin-cfstring1.C):

Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x   (revision 267969)
+++ fixincludes/fixincl.x   (working copy)
@@ -2,11 +2,11 @@
  *
  * DO NOT EDIT THIS FILE   (fixincl.x)
  *
- * It has been AutoGen-ed  October 16, 2018 at 11:38:39 AM by AutoGen 5.18.7
+ * It has been AutoGen-ed  January 16, 2019 at 07:37:22 PM by AutoGen 5.18.12
  * From the definitionsinclhack.def
  * and the template file   fixincl
  */
-/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Oct 16 11:38:39 CEST 2018
+/* DO NOT SVN-MERGE THIS FILE, EITHER Wed Jan 16 19:37:22 CEST 2019
  *
  * You must regenerate it.  Use the ./genfixes script.
  *
@@ -15,7 +15,7 @@
  * certain ANSI-incompatible system header files which are fixed to work
  * correctly with ANSI C and placed in a directory that GNU C will search.
  *
- * This file contains 251 fixup descriptions.
+ * This file contains 252 fixup descriptions.
  *
  * See README for more information.
  *
@@ -2636,6 +2636,56 @@ static const char* apzDarwin_AvailabilityinternalP

 /* * * * * * * * * * * * * * * * * * * * * * * * * *
  *
+ *  Description of Darwin_Api_Availability fix
+ */
+tSCC zDarwin_Api_AvailabilityName[] =
+ "darwin_api_availability";
+
+/*
+ *  File name selection pattern
+ */
+tSCC zDarwin_Api_AvailabilityList[] =
+  "os/availability.h\0";
+/*
+ *  Machine/OS name selection pattern
+ */
+tSCC* apzDarwin_Api_AvailabilityMachs[] = {
+"*-*-darwin*",
+(const char*)NULL };
+
+/*
+ *  content selection pattern - do fix if pattern found
+ */
+tSCC zDarwin_Api_AvailabilitySelect0[] =
+   " *#define __API_AVAILABLE.*\n\
+ *#define __API_DEPRECATED.*\n\
+ *#define __API_DEPRECATED_WITH_REPLACEMENT.*\n\
+ *#define __API_UNAVAILABLE.*\n";
+
+/*
+ *  content bypass pattern - skip fix if pattern found
+ */
+tSCC zDarwin_Api_AvailabilityBypass0[] =
+   "__IPHONE_OS_VERSION_MIN_REQUIRED";
+
+#defineDARWIN_API_AVAILABILITY_TEST_CT  2
+static tTestDesc aDarwin_Api_AvailabilityTests[] = {
+  { TT_NEGREP,   zDarwin_Api_AvailabilityBypass0, (regex_t*)NULL },
+  { TT_EGREP,zDarwin_Api_AvailabilitySelect0, (regex_t*)NULL }, };
+
+/*
+ *  Fix Command Arguments for Darwin_Api_Availability
+ */
+static const char* apzDarwin_Api_AvailabilityPatch[] = {
+"format",
+"#define API_AVAILABLE(...)\n\
+#define API_DEPRECATED(...)\n\
+#define API_DEPRECATED_WITH_REPLACEMENT(...)\n\
+#define API_UNAVAILABLE(...)\n",
+(char*)NULL };
+
+/* * * * * * * * * * * * * * * * * * * * * * * * * *
+ *
  *  Description of Darwin_9_Long_Double_Funcs_2 fix
  */
 tSCC zDarwin_9_Long_Double_Funcs_2Name[] =
@@ -10188,9 +10238,9 @@ static const char* apzX11_SprintfPatch[] = {
  *
  *  List of all fixes
  */
-#define REGEX_COUNT  289
+#define REGEX_COUNT  291
 #define MACH_LIST_SIZE_LIMIT 187
-#define FIX_COUNT251
+#define FIX_COUNT252

 /*
  *  Enumerate the fixes
@@ -10258,6 +10308,7 @@ typedef enum {
 CTRL_QUOTES_USE_FIXIDX,
 CXX_UNREADY_FIXIDX,
 DARWIN_AVAILABILITYINTERNAL_FIXIDX,
+DARWIN_API_AVAILABILITY_FIXIDX,
 DARWIN_9_LONG_DOUBLE_FUNCS_2_FIXIDX,
 DARWIN_EXTERNC_FIXIDX,
 DARWIN_GCC4_BREAKAGE_FIXIDX,
@@ -10760,6 +10811,11 @@ tFixDesc fixDescList[ FIX_COUNT ] = {
  DARWIN_AVAILABILITYINTERNAL_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
  aDarwin_AvailabilityinternalTests,   apzDarwin_AvailabilityinternalPatch,
0 },

+  {  zDarwin_Api_AvailabilityName,zDarwin_Api_AvailabilityList,
+ apzDarwin_Api_AvailabilityMachs,
+ DARWIN_API_AVAILABILITY_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
+ aDarwin_Api_AvailabilityTests,   apzDarwin_Api_AvailabilityPatch, 0 },
+
   {  zDarwin_9_Long_Double_Funcs_2Name,zDarwin_9_Long_Double_Funcs_2List,
  apzDarwin_9_Long_Double_Funcs_2Machs,
  DARWIN_9_LONG_DOUBLE_FUNCS_2_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def(revision 267969)
+++ fixincludes/inclhack.def(working copy)
@@ -1298,6 +1298,33 @@ fix = {
 };

 /*
+ *  macOS 10.13 and 10.14 forget to define API_AVAILABLE if
+ *  __attribute__((availability)) is not supported.
+ */
+fix = {
+hackname  = darwin_api_availability;
+mach  = "*-*-darwin*";
+files = os/availability.h;
+bypass= "__IPHONE_OS_VERSION_MIN_REQUIRED";
+select=
+" *#define __API_AVAILABLE.*\n"
+" *#define __API_DEPRECATED.*\n"
+" *#define __API_DEPRECATED_WITH_REPLACEMENT.*\n"
+" *#define __API_UNAVAILABLE.*\n";
+c_fix = format;
+c_fix_arg =
+"#define API_AVAILABLE(...)\n"
+"#define 

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
There is no bug, so we don't have to do anything.

To make slightly better code we could make the soft float routines be
prototyped?

[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment

[glisse at gcc dot gnu.org]

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

--- Comment #18 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #17)
> Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from
> the above committed change + fixing up ptrs_compare_unequal, or something
> equivalent like the VRP change)

I am a bit lost with the current status there ;-) (I don't have much time now
so I can't really follow anyway, no need to explain it to me)

> I'm afraid there isn't much possibilities
> left to do, and those changes are too risky for GCC9.

I am not in a hurry. I don't personally write code where the performance of
string matters, I was forwarding (the first part of) a report by some user.

> The problem with your
> testcase is that NRV is in place, so we don't even know if s is an automatic
> variable or a global variable, or a heap variable etc.

NRV complicates things, but even with NRV I think we should be able to say that
s and "hello" cannot have the same address, since the caller is supposed to
pass the address of a writable buffer as argument. Or can you think of cases
where NRV would allow the return object and a string literal to have the same
address? Maybe if we store the returned value in a const object and never
compare the address of this const object to another one the compiler could skip
constructing the object and use a reference to a constant object?

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The "nonexistent-path/.." part is reported as
https://sourceforge.net/p/mingw-w64/bugs/782/

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[umesh.kalappa0 at gmail dot com]

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

--- Comment #7 from Umesh Kalappa  ---
Segher,true ,so how do we fix the case , modify the __floatunsidf to clear arg
higher 32 bits , before it use ?

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
But that fix looks wrong, it means "file/" will resolve to "file" and that's
wrong a for a non-directory, because "file/" should fail.

Testcase demonstrating the mingw bugs:

#include 
#include 

void print(const char* s, int i, int expected)
{
  printf("%-26s %2d %s\n", s, i, i == expected ? "" : " FAIL");
}

void f1()
{
  struct stat st;
  int i;
  i = stat(".\\", );
  print("stat(\".\\\")", i, 0);
  i = stat(".\\nonesuch\\..", );
  print("stat(\".\\nonesuch\\..\")", i, -1);

  // Trailing slash after a non-directory should fail:
  i = stat("a.exe\\", );
  print("stat(\"a.exe\\\")", i, -1);
  // "/." after a non-directory is also wrong:
  i = stat("a.exe\\.", );
  print("stat(\"a.exe\\.\")", i, -1);
  // And resolving "/dir/.." after a non-directory is also wrong:
  i = stat("a.exe\\nonesuch\\..", );
  print("stat(\"a.exe\\nonesuch\\..\")", i, -1);
}

void f2()
{
  struct _stat st;
  int i;
  i = _stat(".\\", );
  print("_stat(\".\\\")", i, 0);
  i = _stat(".\\nonesuch\\..", );
  print("_stat(\".\\nonesuch\\..\")", i, -1);
}

void f3()
{
  struct _stat st;
  int i;
  i = _wstat(L".\\", );
  print("_wstat(L\".\\\")", i, 0);
  i = _wstat(L".\\nonesuch\\..", );
  print("_wstat(L\".\\nonesuch\\..\")", i, -1);
}

int main()
{
  f1();
  f2();
  f3();
}


Output for mingw-w64 5.0

stat(".\")  0 
stat(".\nonesuch\..")   0  FAIL
stat("a.exe\")  0  FAIL
stat("a.exe\.") 0  FAIL
stat("a.exe\nonesuch\..")   0  FAIL
_stat(".\")-1  FAIL
_stat(".\nonesuch\..")  0  FAIL
_wstat(L".\")  -1  FAIL
_wstat(L".\nonesuch\..")0  FAIL

[Bug c++/86610] [8/9 Regression] non-const operator erroneously called in lambda in templated function

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-16
 CC||i.nixman at autistici dot org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The trailing slash problem is apparently fixed in mingw-w64:
https://sourceforge.net/p/mingw-w64/bugs/643/

[Bug target/88734] [8/9 Regression] AArch64's ACLE intrinsics give an ICE instead of compile error when option mismatch.

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Actually, with -Wsystem-headers we do warn about that:
include/arm_neon.h:33073:9: warning: ‘#pragma GCC option’ is not a string
[-Wpragmas]
33073 | #pragma GCC target(("arch=armv8.2-a+sm4"))
  | ^~~
include/arm_neon.h:33140:9: warning: ‘#pragma GCC option’ is not a string
[-Wpragmas]
33140 | #pragma GCC target(("arch=armv8.2-a+crypto"))
  | ^~~
include/arm_neon.h:33302:9: warning: ‘#pragma GCC option’ is not a string
[-Wpragmas]
33302 | #pragma GCC target(("arch=armv8.3-a"))
  | ^~~
include/arm_neon.h:33305:9: warning: ‘#pragma GCC option’ is not a string
[-Wpragmas]
33305 | #pragma GCC target(("+fp16"))
  | ^~~
include/arm_neon.h:33776:9: warning: ‘#pragma GCC option’ is not a string
[-Wpragmas]
33776 | #pragma GCC target(("arch=armv8.2-a+fp16fml"))
  | ^~~
So it is just that nobody tried -Wsystem-headers with the arm and aarch64
intrinsic headers.

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
That is most likely a bug in the package.  GCC 8 wasn't very good at detecting
narrow conversions, but in GCC 9 things have improved, so probably we just
detect invalid code now.  The problem in this PR is that we still don't detect
narrow conversions in certain contexts (here, decltype).

[Bug target/88734] [8/9 Regression] AArch64's ACLE intrinsics give an ICE instead of compile error when option mismatch.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45444=edit
gcc9-pr88734.patch

Untested fix.  I'll defer proper testcase to somebody familiar with
gcc.target/aarch64/ testing.

That said, I'm surprised GCC accepts this bogus syntax silently.

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[juergen.reuter at desy dot de]

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

--- Comment #10 from Jürgen Reuter  ---
Actually, it was Thomas Koenig in r267953, so not your commits, but very
close.^^ The report is PR88871.

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[trnka at scm dot com]

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

Tomáš Trnka  changed:

   What|Removed |Added

 CC||trnka at scm dot com

--- Comment #12 from Tomáš Trnka  ---
(In reply to Wilco from comment #11)
> I'm not sure it's the same problem but the huge size increases I noticed are
> due to not optimizing zeroes from initializers, so we end up with huge
> rodata with only zeroes in it.

It indeed is the same problem. The change in r254427 causes def_init to be
generated for all types in a module (even if there's nothing to initialize), so
any type with a large array in it will end up taking lots of space in rodata.

Example:

module FooModule
   type Foo
  integer :: array(100)
   end type
end module
program def_init_size
   use FooModule

   type(Foo) :: x

   x%array(1) = 1
   write(*,*) x%array(1)
end program

 VM SIZEFILE SIZE
 --  --
  50.0%  3.81Mi .rodata   3.81Mi  99.6%
 100.0%  3.81Mi __foomodule_MOD___def_init_foomodule_Foo  3.81Mi 100.0%
   0.0%  60 [section .rodata] 60   0.0%
   0.0%  48 __foomodule_MOD___vtab_foomodule_Foo  48   0.0%
   0.0%  28 options.1.357128   0.0%
   0.0%   4 _IO_stdin_used 4   0.0%
  50.0%  3.81Mi .bss   0   0.0%
 100.0%  3.81Mi x.3565 0   NAN%
   0.0%  31 [section .bss] 0   NAN%
   0.0%   1 completed.7132 0   NAN%

[Bug fortran/81849] Size of automatic array argument specified by host-associated variable.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Wed, Jan 16, 2019 at 07:13:37AM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849
> 
> --- Comment #8 from Jürgen Reuter  ---
> I think this fix or something very near by causes an ICE in our code, I will
> provide a bug report soon.
> 

That's a bummer.

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
Note that "dcmtk" in Fedora may be tripping over this as well.  I haven't
looked in detail at it yet...

BUILDSTDERR: In file included from
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/include/dcmtk/ofstd/variadic/variant.h:19,
BUILDSTDERR:  from
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/include/dcmtk/ofstd/ofvriant.h:379,
BUILDSTDERR:  from
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/tests/tvariant.cc:26:
BUILDSTDERR:
/builddir/build/BUILD/dcmtk-3.6.2/ofstd/include/dcmtk/ofstd/variadic/helpers.h:57:32:
error: narrowing conversion of '-1' from 'int' to 'long unsigned int' 
[-Wnarrowing]
BUILDSTDERR:57 | : OFintegral_constant {};
BUILDSTDERR:   |^
BUILDSTDERR: make[2]: ***
[ofstd/tests/CMakeFiles/ofstd_tests.dir/build.make:352:
ofstd/tests/CMakeFiles/ofstd_tests.dir/tvariant.cc.o] Error 1
BUILDSTDERR: make[2]: *** Waiting for unfinished jobs

Not exactly enough information to determine from the log file...

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Sure, with 32-bit ABIs the registers are just 32 bits, for all intents and
purposes.

But we have -m64 here. (see also the "lwa" insn).

I think that because __floatunsidf has no prototype all its args are taken
to be int?

[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Upstream bug:
https://github.com/xianyi/OpenBLAS/issues/1964

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan 16 15:58:34 2019
New Revision: 267976

URL: https://gcc.gnu.org/viewcvs?rev=267976=gcc=rev
Log:
PR c++/78244 - narrowing conversion in template not detected.
* call.c (perform_implicit_conversion_flags): Set
IMPLICIT_CONV_EXPR_BRACED_INIT.
* cp-tree.h (IMPLICIT_CONV_EXPR_BRACED_INIT): New.
* pt.c (tsubst_copy_and_build): Use it.

* g++.dg/cpp0x/Wnarrowing13.C: New test.
* g++.dg/cpp0x/Wnarrowing14.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing13.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
(In reply to Andrew Pinski from comment #4)
> Replace:
> :
> :
>   "r" (i),
>"r" (n),
> 
> With:
> :
>   "+r" (i),
>"+r" (n),
> :

I can confirm it works, thus it's failure in the package. Let me report that.

[Bug sanitizer/88684] Please make SANITIZER_NON_UNIQUE_TYPEINFO a runtime flag (or always true)

[rafael at espindo dot la]

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

--- Comment #11 from Rafael Avila de Espindola  ---
(In reply to Martin Liška from comment #10)
> > That said, I'm willing to ack it for GCC9 even then if upstream comes up
> > with something or if they don't care, eventually as a GCC only tweak.
> 
> Works for me. Note that so far there has been no reply to my patch.

You might want to CC:
 Filipe Cabecinhas 

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
And of course r265789 changed int{(p(), 0U)} from being dependent to being
non-dependent, so scenario 2) to scenario 1).

[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Replace:
:
:
  "r" (i),
   "r" (n),

With:
:
  "+r" (i),
   "+r" (n),
:

[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #5 from David Malcolm  ---
Created attachment 45443
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45443=edit
Reduced test case

This ICEs with -O3 at the same place.

3332  gcc_assert (new_priority >= 0);

where:

3321static int
3322sel_target_adjust_priority (expr_t expr)
3323{
3324  int priority = EXPR_PRIORITY (expr);
3325  int new_priority;
3326
3327  if (targetm.sched.adjust_priority)
3328new_priority = targetm.sched.adjust_priority (EXPR_INSN_RTX (expr),
priority);
3329  else
3330new_priority = priority;
3331
3332  gcc_assert (new_priority >= 0);

(gdb) p expr->priority
$7 = -1
(gdb) p new_priority
$8 = -1
(gdb) (gdb) p targetm.sched.adjust_priority
Undefined command: "".  Try "help".
(gdb) p targetm.sched.adjust_priority
$9 = (int (*)(rtx_insn *, int)) 0x0

[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
Thanks. This broke when the patch for PR 85458 was applied, and Andreas raised
it on the gcc-patches thread:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00128.html

Soon after that, the HP-PA adjust_priority target hook was removed, making the
sel-sched change unnecessary. Therefore, my recommendation is to revert the
sel-sched patch, or remove the new assert as Andreas has suggested. Andrey,
which approach would you prefer?

It's also possible to implement Jeff's suggestion and clamp negative priorities
to zero in create_speculation_check, but that may turn out to be insufficient
if there is other code producing negative priority values.

[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Andrew Pinski from comment #2)
> The inline asm modifies the 0th and 1st operands. I think the inline asm is
> broken .

You are right, they are modified. Can you please help me how to fix the
assembly (marking these 2 as output as well)?

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(My proof-of-concept patch to deal with narrowing in decltype fixed this PR as
a result.)

[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms

[jamborm at gcc dot gnu.org]

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

--- Comment #12 from Martin Jambor  ---
Author: jamborm
Date: Wed Jan 16 15:41:07 2019
New Revision: 267975

URL: https://gcc.gnu.org/viewcvs?rev=267975=gcc=rev
Log:
[PR 88214] Check that an argument is a pointer

2019-01-16  Martin Jambor  

Backported from mainline
2018-12-10  Martin Jambor  

PR ipa/88214
* ipa-prop.c (determine_locally_known_aggregate_parts): Make sure
we check pointers against pointers.

testsuite/
* gcc.dg/ipa/pr88214.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/ipa/pr88214.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/ipa-prop.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
There can be three scenarios:

1) decltype is in a template and it has no dependent expressions -- PROBLEM
- we call finish_compound_literal from cp_parser_functional_cast
- processing_template_decl is 1, so we just return compound_literal; without
calling check_narrowing
- then we call finish_decltype_type, EXPR is {NON_LVALUE_EXPR <2.0e+0>} but
that is not instantiation_dependent_uneval_expression_p, so we just take its
unlowered_expr_type and return it, without calling check_narrowing.

2) decltype is in a template and has dependent expressions
- we call finish_compound_literal from cp_parser_functional_cast
- processing_template_decl is 1, so we just return compound_literal; without
calling check_narrowing
- then we call finish_decltype_type, EXPR is
instantiation_dependent_uneval_expression_p, so we create DECLTYPE_TYPE with
the dependent expression
- tsubst_copy_and_build then calls
  RETURN (finish_compound_literal (type, r, complain, cl));
while substituting the CONSTRUCTOR.  Now processing_template_decl is 0, so
finish_compound_literal calls check_narrowing, so we detect it.

3) decltype is not in a template
- we call finish_compound_literal from cp_parser_functional_cast, but
processing_template_decl is 0, so we call check_narrowing so we detect it.



So one idea would to be to walk_tree on the expression at the end of
finish_decltype_type, looking for compound literals and call check_narrowing.

[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
Author: jamborm
Date: Wed Jan 16 15:37:33 2019
New Revision: 267974

URL: https://gcc.gnu.org/viewcvs?rev=267974=gcc=rev
Log:
[PR 88214] Check that an argument is a pointer

2019-01-16  Martin Jambor  

Backported from mainline
2018-12-10  Martin Jambor  

PR ipa/88214
* ipa-prop.c (determine_locally_known_aggregate_parts): Make sure
we check pointers against pointers.

testsuite/
* gcc.dg/ipa/pr88214.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/ipa/pr88214.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/ipa-prop.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #5 from Bill Schmidt  ---
So technically, if the target is 32-bit powerpc, the ABI is silent on the upper
32 bits.  That's not necessarily a reasonable position to stand on, but when
targeting powerpc (not powerpc64*) those bits are meaningless.

[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
The inline asm modifies the 0th and 1st operands. I think the inline asm is
broken .

[Bug driver/88883] New: [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type

[p...@gcc-bugzilla.mail.kapsi.fi]

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

Bug ID: 3
   Summary: [AArch64] gcc/config/aarch64/aarch64.opt:
aarch64_branch_protection_string type
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: aarch64-none-elf
 Build: x86_64-linux-gnu

Hi.

It appears that when trying to build an x86_64-w64-mingw32 cross compiler
targetting AArch64 the build fails at generated `gcc/options-save.c' due to
narrowing conversion (using the latest trunk). This has likely something to do
with the latest branch protection patches.

The generated code looks like this (generated by `gcc/optc-save-gen.awk'):
  if (ptr->x_aarch64_branch_protection_string)
fprintf (file, "%*s%s (%#lx)\n",
 indent, "",
 "aarch64_branch_protection_string",
 (unsigned long)ptr->x_aarch64_branch_protection_string);

And this will cause something like:
options-save.c::mm: error: cast from 'const char*' to 'long unsigned int'
loses precision [-fpermissive]
  (unsigned long)ptr->x_aarch64_branch_protection_string);


I'm not sure who is the real culprit here. Should the generated options saving
code handle narrowing conversions better, or, as the above cast is only done
for any option that does not fall under char, short, int, enum or /string/
types is this caused by a mishap when selecting the proper type for
aarch64_branch_protection_string (at aarch64.opt)?

[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
"Values shorter than 32 bits are sign-extended or zero-extended, depending on
whether they are signed or unsigned."  Source:
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf,
p.33.

The same is true of the 64-bit ABIs, both ELFv1 and ELFv2.

[Bug rtl-optimization/88880] [9 Regression] Wrong code since r264897

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
That inline asm looks big and suspicious.

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  ---
(In reply to Richard Biener from comment #12)
> OK, so C++ has
> 
>   else if ((DECL_NAME (decl) == NULL_TREE)
>&& TREE_CODE (decl) == NAMESPACE_DECL)
> dump_decl (cxx_pp, decl, TFF_PLAIN_IDENTIFIER | TFF_UNQUALIFIED_NAME);
> 
> and thus "copes" with namespaces without a name.  I wonder if we want
> pubnames late at all.  For darwin and other targets with "crippled"
> early LTO support (read: no support)

FWIW, I've implemented the GCC part of the support (it needs a bit of tidying
for posting, but [probably] not a stage #4 thing).  Also discussed the required
support in dsymutil with one of the devs (there seems no objection to doing
this, in principle)... so it's "when" rather than "if".

... progress on new features and enhancements for Darwin will go quicker if we
can squish the codegen and testsuite bugs (which is where the effort is going
at present) ;)

> this means we'd not generate those lookup entries.
> 
> Since we output_pubtables only from dwarf2out_finish (why?) we don't
> get those into early debug.  Sth to investigate.

my (limited) understanding of the purpose is to improve startup time for debug
sessions, so possibly relevant outside of darwin?

> The ICE can probably be fixed with the following - can you test that?

yes, that fixes it (only tested c++ asan).

> 
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index a1b5a5eaf19..cd2e889a8cc 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -11074,7 +11074,9 @@ output_comp_unit (dw_die_ref die, int
> output_if_empty,
>  static inline bool
>  want_pubnames (void)
>  {
> -  if (debug_info_level <= DINFO_LEVEL_TERSE)
> +  if (debug_info_level <= DINFO_LEVEL_TERSE
> +  /* Names and types go to the early debug part only.  */
> +  || in_lto_p)
>  return false;
>if (debug_generate_pub_sections != -1)
>  return debug_generate_pub_sections;