[Bug debug/87295] [early debug] ICE with -ffat-lto-objects -fdebug-types-section -g

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jan 29 08:12:02 2019
New Revision: 268361

URL: https://gcc.gnu.org/viewcvs?rev=268361&root=gcc&view=rev
Log:
2019-01-29  Richard Biener  

PR debug/87295
* dwarf2out.c (collect_skeleton_dies): New helper.
(copy_decls_for_unworthy_types): Call it.
(build_abbrev_table): Assert we do not try to replace
DW_AT_signature refs with local refs.

* g++.dg/lto/pr87295_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr87295_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/87295] [8 Regression][early debug] ICE with -ffat-lto-objects -fdebug-types-section -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||7.3.1, 9.0
   Target Milestone|--- |8.3
Summary|[early debug] ICE with  |[8 Regression][early debug]
   |-ffat-lto-objects   |ICE with -ffat-lto-objects
   |-fdebug-types-section -g|-fdebug-types-section -g
  Known to fail||8.2.1

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar, also fails on the GCC 8 branch.

[Bug rtl-optimization/88593] [9 Regression] cleanup_cfg may make cached dominance info stale

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Mon, 28 Jan 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
> 
> --- Comment #12 from Jakub Jelinek  ---
> And isn't it latent on all older branches too?  Or do you have revision number
> between 8 and 9 that broke this?

The issue in mode-switching is latent everywhere and worth fixing.

[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions

[peter at cordes dot ca]

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

--- Comment #10 from Peter Cordes  ---
(In reply to Uroš Bizjak from comment #9)
> There was similar patch for sqrt [1], I think that the approach is
> straightforward, and could be applied to other reg->reg scalar insns as
> well, independently of PR87007 patch.
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00202.html

Yeah, that looks good.  So I think it's just vcvtss2sd and sd2ss, and
VROUNDSS/SD that aren't done yet.

That patch covers VSQRTSS/SD, VRCPSS, and VRSQRTSS.

It also bizarrely uses it for VMOVSS, which gcc should only emit if it actually
wants to merge (right?).  *If* this part of the patch isn't a bug

-   return "vmovss\t{%1, %0, %0|%0, %0, %1}";
+   return "vmovss\t{%d1, %0|%0, %d1}";

then even better would be vmovaps %1, %0 (which can benefit from
mov-elimination, and doesn't need a port-5-only ALU uop.)  Same for vmovsd of
course.

[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix7.1.3.0
   Target Milestone|--- |7.5
Summary|[6/7/8/9 regression] AIX 7  |[7/8/9 regression] AIX 7
   |linker rejects  |linker rejects
   |_.ro_ sections by |_.ro_ sections by
   |default |default

[Bug testsuite/89095] gcc-dg-prune calls check_effective_target_offload_gcn every time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed (I think we have a dup which says we should cache the result of
check_effective_target_offload_gcn).

[Bug driver/89094] collect2.c:main c_argv buffer is undersized when -EL, -EB or -B used in COLLECT_GCC_OPTIONS

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  lto-wrapper uses an obstack for this.

[Bug tree-optimization/89098] ICE: verify_ssa failed (Error: definition in block 27 follows the use)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 CC||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug fortran/88298] [7/8/9 Regression] Bogus conversion warning for CSHIFT with -fno-range-check -m64

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The same bogus conversion warning appears for EOSHIFT.

[Bug testsuite/89095] gcc-dg-prune calls check_effective_target_offload_gcn every time

[ams at gcc dot gnu.org]

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

--- Comment #2 from Andrew Stubbs  ---
There's a patch on pr88920, but no review yet. I was planning to chase it
today.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
If the EABI has such requirements, then libgcc/config/arm/t-arm (or whatever
else) needs to pass down -msoft-float (or whatever else disables the VFP
registers), rather than relying on that the compiler won't choose them.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely  ---
Done - do you want to keep this open?

[Bug fortran/35040] usage of init expression in its own definition

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #9 from Dominique d'Humieres  ---
*** Bug 56174 has been marked as a duplicate of this bug. ***

[Bug fortran/56174] Wrongly accepts "INTEGER :: b = HUGE(b)"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of pr35040.

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

[Bug middle-end/89099] New: Have "-fopt-info" show the original source code context

[tschwinge at gcc dot gnu.org]

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

Bug ID: 89099
   Summary: Have "-fopt-info" show the original source code
context
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

It would be useful to have "-fopt-info" show the original source code context.

For example, we've got diagnostics like:

[...]/asyncwait-1.c: In function 'main':
[...]/asyncwait-1.c:14:11: warning: unused parameter 'argc'
[-Wunused-parameter]
   14 | main (int argc, char **argv)
  |   ^~~~

..., but "-fopt-info" only prints a terse form:

[...]
[...]/asyncwait-1.c:480:9: optimized: assigned OpenACC gang loop
parallelism
[...]

... without showing any of the original source code context.

This should be enabled by default, if possible, but disabled by some flag (can
just use "-fno-diagnostics-show-caret" here, too?).

[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

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

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

Sebastian Huber  changed:

   What|Removed |Added

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

--- Comment #11 from Sebastian Huber  ---
(In reply to Chris Johns from comment #10)
> (In reply to Joel Sherrill from comment #9)
> > Yes. I believe it is the same bug. Use of GNU sed specifics on a system
> > without GNU sed.
> > 
> > I don't know if that changes the resolution.
> 
> For this bug that is true however the other bug is still open and so the
> issue is not resolved so I hope there is a chance someone with a suitable
> level of sed knowledge may take a look to see if the use can be made to be
> universal or highlight a bug in BSD sed. I had a look but I could not
> determine if the issue is in the sed expressions used or BSD sed.

I opened a FreeBSD bug:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235293

[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode

[csaba_22 at yahoo dot co.uk]

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

--- Comment #2 from Csaba Ráduly  ---
> Are you actually seeing a problem because of this?

Not as such. What I did was to generate the pre-processed output, replace #s
with // (so the line numbers are the raw ones for the raw preprocessed file)
and compile it as if it were a regular C++ file. Then the compiler complained
because the "if constexpr" didn't seem like part of a system header.

[Bug fortran/48655] "False positive" with -Warray-temporaries or missing warning with -fcheck=array-temps

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
See also pr56937 comment 8.

[Bug fortran/56937] Unnecessarily temporary with array-vector assignments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #14 from Dominique d'Humieres  ---
> Do people think that the case of comment#8 is worth fixing?

This is pr48655 thus closing this PR.

[Bug fortran/52861] (missed optimisation) missed transformation to memset with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
Related to pr31016?

[Bug c++/52119] [C++11] overflow in signed left shift isn't diagnosed

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Fixed by r225998

PR c++/55095
* c-common.c (c_fully_fold_internal): Warn about left shift
overflows.
Use EXPR_LOC_OR_LOC.
(maybe_warn_shift_overflow): New function.
* c-common.h (maybe_warn_shift_overflow): Declare.
* c-opts.c (c_common_post_options): Set warn_shift_overflow.
* c.opt (Wshift-overflow): New option.

* c-typeck.c (digest_init): Pass OPT_Wpedantic to pedwarn_init.
(build_binary_op): Warn about left shift overflows.

* typeck.c (cp_build_binary_op): Warn about left shift overflows.

* doc/invoke.texi: Document -Wshift-overflow and -Wshift-overflow=.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

--- Comment #10 from Ramana Radhakrishnan  ---
Created attachment 45547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45547&action=edit
untested prototype patch.

Not sure if this is complete yet but it gives a framework to dig further.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Comment on attachment 45547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45547
untested prototype patch.

Doesn't the whole unwinder (so eh_personality.cc (whole, not just one function
in it), unwind-arm.c, unwind-c.c, maybe some other unwind-*.c)) need that?

[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Csaba Ráduly from comment #2)
> > Are you actually seeing a problem because of this?
> 
> Not as such. What I did was to generate the pre-processed output, replace #s
> with // (so the line numbers are the raw ones for the raw preprocessed file)
> and compile it as if it were a regular C++ file.

... why?

Just don't do that. The # lines affect how the code is compiled and are a
necessary part of the standard library implementation.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
If one appends -mfloat-abi=soft to command lines of those files, does that
imply incompatible ABI even if nothing is passed in float/VFP etc. registers
nor there is any floating point code?

[Bug fortran/89100] New: Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

Bug ID: 89100
   Summary: Default widths for i, f and g format specifiers in
format strings
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark.eggleston at codethink dot com
  Target Milestone: ---

Created attachment 45548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45548&action=edit
Patch to support default widths for f, g and i

gfortran as of revision: svn+ssh://gcc.gnu.org/svn/gcc/trunk@268360

Fortran currently rejects format specifiers i, f and g without widths, e.g:

   24 | write(buffer, "(A, F, A)") ':',real_4,':'
  |   1
Error: Nonnegative width required in format string at (1)

The PGI Fortran compiler 18.10 silently accepts this with no compiler options.
Jakub Jelinek provided this link
https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-default-widths-for-data-edit-descriptors
showing that ifort also defaults the widths of i, f and g.

Please find attach a patch that provides default widths for f, g and i.

As this feature is non-standard and most likely originated with DEC Fortran it
is only available using the option -fdec-format-defaults which is also enabled
by -fdec.

For trunk and supported versions.

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #1 from MarkEggleston  ---
Created attachment 45549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45549&action=edit
Change log for gcc/fortran for patch

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #2 from MarkEggleston  ---
Created attachment 45550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45550&action=edit
Change Log for libgfortran for patch

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

--- Comment #13 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #12)
> If one appends -mfloat-abi=soft to command lines of those files, does that
> imply incompatible ABI even if nothing is passed in float/VFP etc. registers
> nor there is any floating point code?

-mfloat-abi=soft is an interesting option, it means use floating point
emulation code using the base pcs as well as use the base parameter passing
conventions for passing floating point parameters to functions. 

so it would end up failing at link time . That's why we need an -mfpu=none
option which is silent and I've not liked it for a while. 

(In reply to Jakub Jelinek from comment #11)
> Comment on attachment 45547 [details]
> untested prototype patch.
> 
> Doesn't the whole unwinder (so eh_personality.cc (whole, not just one
> function in it), unwind-arm.c, unwind-c.c, maybe some other unwind-*.c))
> need that?

Yes that would be needed. Reading the EHABI again suggests that - I don't see a
macro that would help with that everywhere.

[Bug d/88150] Use sections_elf_shared.d on Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-01/msg01661.ht
   ||ml

--- Comment #7 from Rainer Orth  ---
Patch posted, together with followups:

https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01663.html
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01664.html

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-01/msg01666.ht
   ||ml

--- Comment #6 from Rainer Orth  ---
Patch posted.

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #3 from MarkEggleston  ---
Created attachment 45551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45551&action=edit
Change Log for testsuite for patch

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
We require GNU make, so one can use something like:
unwind-arm.o unwind-c.o libunwind.o pr-support.o: CFLAGS += -mfpu=none
or similar in libgcc/config/arm/t-arm (or similar) with a comment explaining
the reason.  For eh_personality.o that needs to be done elsewhere and there are
no such makefile fragments (and libtool is used).

[Bug target/89101] New: [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[gael.guennebaud at gmail dot com]

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

Bug ID: 89101
   Summary: [Aarch64] vfmaq_laneq_f32 generates unnecessary dup
instrcutions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gael.guennebaud at gmail dot com
  Target Milestone: ---

vfmaq_laneq_f32 is currently implemented as:

__extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
vfmaq_laneq_f32 (float32x4_t __a, float32x4_t __b,
 float32x4_t __c, const int __lane)
{
  return __builtin_aarch64_fmav4sf (__b,
__aarch64_vdupq_laneq_f32 (__c, __lane),
__a);
}

thus leading to unoptimized code as:

ldr q1, [x2, 16]
dup v28.4s, v1.s[0]
dup v27.4s, v1.s[1]
dup v26.4s, v1.s[2]
dup v1.4s, v1.s[3]
fmlav22.4s, v25.4s, v28.4s
fmlav3.4s, v25.4s, v27.4s
fmlav6.4s, v25.4s, v26.4s
fmlav17.4s, v25.4s, v1.4s

instead of:

ldr q1, [x2, 16]
fmlav22.4s, v25.4s, v1.s[0]
fmlav3.4s, v25.4s, v1.s[1]
fmlav6.4s, v25.4s, v1.s[2]
fmlav17.4s, v25.4s, v1.s[3]

I guess several other *lane* intrinsics exhibit the same shortcoming.

For the record, I managed to partly workaround this issue by writing my own
version as:

 if(LaneID==0)  asm("fmla %0.4s, %1.4s, %2.s[0]\n" : "+w" (c) : "w"
(a), "w" (b) :  );
else if(LaneID==1)  asm("fmla %0.4s, %1.4s, %2.s[1]\n" : "+w" (c) : "w"
(a), "w" (b) :  );
else if(LaneID==2)  asm("fmla %0.4s, %1.4s, %2.s[2]\n" : "+w" (c) : "w"
(a), "w" (b) :  );
else if(LaneID==3)  asm("fmla %0.4s, %1.4s, %2.s[3]\n" : "+w" (c) : "w"
(a), "w" (b) :  );

but that's of course not ideal. This change yields a 32% speed up in Eigen's
matrix product: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1633

[Bug fortran/89086] Add a Fortran language reference chapter

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> > I don't think this is realistic unless someone steps on with at least a
> > draft.
>
> Well, yes. Howewer, I would prefer if you did not close it.

What is the rationale?

[Bug tree-optimization/88739] [7/8 Regression] Big-endian union bug

[dongjianqiang2 at huawei dot com]

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

--- Comment #54 from John Dong  ---
(In reply to Richard Biener from comment #53)
> Fixed on trunk sofar, still waiting for somebody to produce a testcase for
> the testsuite (I can't run-test on BE).

hi, any plan to fix on gcc-7-branch?

[Bug tree-optimization/88739] [7/8 Regression] Big-endian union bug

[rguenth at gcc dot gnu.org]

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

--- Comment #55 from Richard Biener  ---
(In reply to John Dong from comment #54)
> (In reply to Richard Biener from comment #53)
> > Fixed on trunk sofar, still waiting for somebody to produce a testcase for
> > the testsuite (I can't run-test on BE).
> 
> hi, any plan to fix on gcc-7-branch?

Yes, maybe you can help with a testcase that can be put into
gcc/testsuite/gcc.dg/torture/ and that currently fails on the branches but
passes on trunk?  I didn't want to backport w/o a testcase.

[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
I suspect this is the reason that our is_nothrow_convertible trait fails in
some cases:

template T&& declval();
template struct bool_constant { static constexpr bool value = B; };
using true_type = bool_constant;
using false_type = bool_constant;

template
struct char_traits
{
  static int length(T* p) { int n = 0; while (*p++ != T()) ++n; return n; }
};

template>
struct basic_string_view
{
  constexpr basic_string_view(T* p) noexcept : len(U::length(p)) { }
  int len;
};

template
  class is_nothrow_convertible_helper
  {
template
  static void test_aux(To1) noexcept;

template(declval()))>
  static bool_constant
  test_nothrow(int);

template
  static false_type
  test_nothrow(...);

  public:
typedef decltype(test_nothrow(0)) type;
  };

template
  struct is_nothrow_convertible
  : is_nothrow_convertible_helper::type
  { };

struct X { };

bool b = is_nothrow_convertible>::value;


ntconv.cc: In instantiation of 'static int char_traits::length(T*) [with T =
X]':
ntconv.cc:15:61:   required from 'constexpr basic_string_view::basic_string_view(T*) [with T = X; U = char_traits]'
ntconv.cc:26:66:   required by substitution of 'template static bool_constant is_nothrow_convertible_helper >::test_nothrow(int) [with From1 = X*;
To1 = basic_string_view; bool NoEx = false]'
ntconv.cc:35:44:   required from 'class is_nothrow_convertible_helper >'
ntconv.cc:39:10:   required from 'struct is_nothrow_convertible >'
ntconv.cc:45:58:   required from here
ntconv.cc:9:52: error: no match for 'operator!=' (operand types are 'X' and
'X')
9 |   static int length(T* p) { int n = 0; while (*p++ != T()) ++n; return
n; }
  |   ~^~

The basic_string_view::basic_string_view(X*) ctor is ill-formed, but I don't
think it should actually need to be instantiated here in order to tell whether
it can throw. I suspect it gets instantiated because of this bug, by the
compiler trying to determine if it can throw.

I don't have a rejects-valid testcase though, so it might not matter.

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #1 from Wilco  ---
(In reply to Gael Guennebaud from comment #0)
> vfmaq_laneq_f32 is currently implemented as:
> 
> __extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
> vfmaq_laneq_f32 (float32x4_t __a, float32x4_t __b,
>float32x4_t __c, const int __lane)
> {
>   return __builtin_aarch64_fmav4sf (__b,
>   __aarch64_vdupq_laneq_f32 (__c, __lane),
>   __a);
> }
> 
> thus leading to unoptimized code as:
> 
> ldr   q1, [x2, 16]
>   dup v28.4s, v1.s[0]
>   dup v27.4s, v1.s[1]
>   dup v26.4s, v1.s[2]
>   dup v1.4s, v1.s[3]
>   fmlav22.4s, v25.4s, v28.4s
>   fmlav3.4s, v25.4s, v27.4s
>   fmlav6.4s, v25.4s, v26.4s
>   fmlav17.4s, v25.4s, v1.4s
> 
> instead of:
> 
> ldr   q1, [x2, 16]
>   fmlav22.4s, v25.4s, v1.s[0]
>   fmlav3.4s, v25.4s, v1.s[1]
>   fmlav6.4s, v25.4s, v1.s[2]
>   fmlav17.4s, v25.4s, v1.s[3]
> 
> I guess several other *lane* intrinsics exhibit the same shortcoming.

Which compiler version did you use? I tried this on GCC6, 7, 8, and 9 with -O2:

#include "arm_neon.h"
float32x4_t f(float32x4_t a, float32x4_t b, float32x4_t c)
{
  a = vfmaq_laneq_f32 (a, b, c, 0);
  a = vfmaq_laneq_f32 (a, b, c, 1);
  return a;
}

fmlav0.4s, v1.4s, v2.4s[0]
fmlav0.4s, v1.4s, v2.4s[1]
ret

In all cases the optimizer is able to merge the dups as expected.

If it still fails for you, could you provide a compilable example like above
that shows the issue?

> For the record, I managed to partly workaround this issue by writing my own
> version as:
> 
>  if(LaneID==0)  asm("fmla %0.4s, %1.4s, %2.s[0]\n" : "+w" (c) : "w"
> (a), "w" (b) :  );
> else if(LaneID==1)  asm("fmla %0.4s, %1.4s, %2.s[1]\n" : "+w" (c) : "w"
> (a), "w" (b) :  );
> else if(LaneID==2)  asm("fmla %0.4s, %1.4s, %2.s[2]\n" : "+w" (c) : "w"
> (a), "w" (b) :  );
> else if(LaneID==3)  asm("fmla %0.4s, %1.4s, %2.s[3]\n" : "+w" (c) : "w"
> (a), "w" (b) :  );
> 
> but that's of course not ideal. This change yields a 32% speed up in Eigen's
> matrix product: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1633

I'd strongly advise against using inline assembler since most people make
mistakes writing it, and GCC won't be able to optimize code using inline
assembler.

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

[Bug c/89061] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Joseph, you mean we should skip the compound literals from this warning because
if one doesn't take their address, they are used only directly in the code in
which they are referenced and not anywhere else, and if their address is taken,
there is probably no way to propagate that address through to after the label?
I mean, if I do:
  struct S *p = something;
  if (whatever)
goto l;
  p = &(struct S){ .a = 1, .b = 2, .c = 3 };
l:
  return p->b;
then although the initialization was crossed by the jump, nothing should be
able to find the address of the compound literal that got not initialized?

If yes, we don't have the complit decls marked specially in any way,
DECL_ARTIFICIAL && !DECL_NAME is way too generic check.  So we'd need some
unused C lang bit to mark it.

[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Specifically, we get a new FAIL when running the libstdc++ tests in c++2a mode:

FAIL: 21_strings/basic_string/types/1.cc (test for excess errors)

That's because the is_convertible trait instantiates the new c++2a-only
__is_nothrow_type member, which instantiates the basic_string_view ctor,
which is ill-formed because X isn't equality comparable.


I think this might be a rejects-valid example:

template
struct basic_string_view
{
  constexpr basic_string_view(T p) noexcept { (void) p.i; }
};

struct X { } x;

bool b = noexcept(basic_string_view{x});


ntconv.cc: In instantiation of 'constexpr
basic_string_view::basic_string_view(T) [with T = X]':
ntconv.cc:10:42:   required from here
ntconv.cc:5:56: error: 'struct X' has no member named 'i'
5 |   constexpr basic_string_view(T p) noexcept { (void) p.i; }
  |  ~~^


If I'm reading the standard correctly, the constructor's noexcept-specifier is
instantiated because it's "needed" but that should not cause the instantiation
of the function declaration.

If the constructor is not constexpr it isn't instantiated when the
noexcept-specifier is needed, which is why I think it's related to this bug.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #7 from Nicolas Koenig  ---
(In reply to Damian Rouson from comment #5)
> This is an exciting idea.  When I gave some thought to writing a
> shared-memory alternative coarray ABI, it seemed to me that pthreads would
> be a better choice than OpenMP.  Part of the problem is that I was
> considering writing the implementation in Fortran, and OpenMP lacked support
> several modern Fortran features, including several object-oriented
> programming features.  That of course won't be an issue for you, however,
> assuming you're going to write the implementation in C.  I was going to
> leverage "forthreads," an open-source Fortran 20003 interface to pthreads. 
> One thing that I think would be a major benefit of having a Fortran
> implementation of the library is that it greatly expand the potential
> community of contributors to include more of the users of the compiler.
> 

I actually opted to use multiprocessing with shared memory (shm_open() & co)
instead of multithreading, since it will be much easier and faster with static
variables, of which gfortran makes extensive use. Also, it greatly simplifies
interoperability with OpenMP. The only real downsides I can think of are slower
spinup times (~1 cycles for processes vs. ~1000 for threads), far slower
context switches (only a problem if more more images than cores are used) and
slower allocation, since at the moment a mmap() call is needed for each one
(the allocator tracks the offset and size in the memfile instead of the
mmap()'ed memory regions. If this is to slow, I can just cache the pointers).
As for writting it in fortran, see below :)

>
> Another important consideration is whether to use the current gfortran
> descriptors as arguments in the library functions (as is currently used) or
> instead to use the Fortran 2018 CFI descriptors for which Paul recently
> committed support.  If you go with the current gfortran descriptors, then
> there could be a lot of code to rewrite if gfortran later adopts the
> standard descriptors internally.  Paul's recent commit adds functions that
> can translate between the gfortran and standard descriptors. I have a
> volunteer who I'm hoping will use the translation functions to develop a
> new, alternative coarray ABI that accepts the standard descriptors.
> 

I actually think it would be best not to turn it into a separate library but
instead integrate it into libgfortran. This way, it will not be necessary to
install a seperate library and thereby make it easier for people to start using
coarrays. Therefore, it would make sense to use the libgfortran descriptors.

>
> On another note mentioned earlier in this PR, I believe it will be necessary
> to fork all threads at the beginning of execution and not join them at the
> end.  Section 5.3.5 of the Fortran 2018 standard states, "Following the
> creation of a fixed number of images, execution begins on each image."
> Assuming there is a one-to-one correspondence between images and threads, I
> read that as implying that a fixed number of threads have to be set up
> before any one thread can execute.  (Possibly there could also be additional
> non-image threads that get forked later also though.) 

At the moment, sync_all() is called after image creation.

> I recall seeing several interesting papers from 10-15 years ago on SPMD-style
> programming using threads (OpenMP) so a literature search on this topic be 
> useful to read.

[Bug libstdc++/89102] New: 'common_type' of single abominable function should not have a nested typename

[alisdairm at me dot com]

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

Bug ID: 89102
   Summary: 'common_type' of single abominable function should not
have a nested typename
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

According to the formula for 'common_type', as an abominable function type does
not have a valid return type for 'declval', the trait should not have a nested
'type' name.

The following program shows this is not the case (I have not tried to work out
what the nested name aliases, probably the type itself):


template 
inline constexpr bool DetectType = false;

template 
inline constexpr
bool DetectType> = true;

// Quick proof detector works correctly
struct NoType {};
struct HasType { using type = HasType; };

static_assert( DetectType );
static_assert(!DetectType );


auto main() -> int {
   static_assert(!DetectType< std::common_type >);
   static_assert(!DetectType< std::common_type >);
   static_assert(!DetectType< std::common_type >);
   static_assert(!DetectType< std::common_type >);

   return 0;
}


I have also tested with gcc9 in development, but MacPorts stopped updating
around October 2018, so my test environment is quite out of date - so only
claiming the bug
against the latest release version I have tested.

[Bug middle-end/89099] Have "-fopt-info" show the original source code context

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Indeed: -fopt-info is currently implemented via writing to up to two FILE *
destinations: the dumpfile and the opt-info destination (e.g. stderr).

In particular it doesn't go through the diagnostic subsystem.

Some of the differences between dumping and diagnostics:
* as noted in comment #0, it's missing the quoted source code
* it's missing the announcements about function names, such as the: "In
function 'main':" from the diagnostic example; for diagnostics this can include
things like printing the inlining chain
* we don't have quotes and bold in the opt-info output (e.g. via "%qs")
* we don't localize the messages

Two approaches to addressing this:
(a) unify the two, so that -fopt-info messages
(b) hack in a call to diagnostic_show_locus into the dump subsystem (this seems
easier)

Approach (b) seems easier.  It sounds like you want this for the -fopt-info
destination (alt_dump_file; typically stderr).   Should diagnostic_show_locus
be called for the dumpfile as well?

There are some warts involving things like:
* whether colorization should happen (if writing to a "real" file rather than
stderr)
* the cache for suppressing what was last printed, since there'd be multiple
output sources
* probably things I haven't thought of
[perhaps the dump subsystem would need its own diagnostic_context for handling
such output???]

[Bug middle-end/89099] Have "-fopt-info" show the original source code context

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)
> (a) unify the two, so that -fopt-info messages
..."go through the diagnostics subsystem", I meant to write.

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[gael.guennebaud at gmail dot com]

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

--- Comment #2 from Gael Guennebaud  ---
Indeed, it fails to remove the dup only if the coefficient is used multiple
times as in the following reduced exemple: (https://godbolt.org/z/hmSaE0)


#include 

void foo(const float* a, const float * b, float * c, int n) {
float32x4_t c0, c1, c2, c3;
c0 = vld1q_f32(c+0*4);
c1 = vld1q_f32(c+1*4);
for(int k=0; k

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

  Attachment #45547|0   |1
is obsolete||

--- Comment #15 from Ramana Radhakrishnan  ---
Created attachment 45552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45552&action=edit
new patch.

Testing this and would be grateful for a test run.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

--- Comment #16 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #14)
> We require GNU make, so one can use something like:
> unwind-arm.o unwind-c.o libunwind.o pr-support.o: CFLAGS += -mfpu=none
> or similar in libgcc/config/arm/t-arm (or similar) with a comment explaining
> the reason.  For eh_personality.o that needs to be done elsewhere and there
> are no such makefile fragments (and libtool is used).

Sadly that doesn't work for -mfpu=none in t-arm because we still need gcc-9 to
build with older binutils that don't necessarily support -mfpu=none, thus for
now let's hide this with target pragmas.

[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #4 from Matthias Klose  ---
Created attachment 45553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45553&action=edit
preprocessed source

another preprocessed source from the trilinos package.

$ g++ -std=c++11 -c -Wall -Wextra TestSerial_SharedAlloc.ii 
TestSerial_SharedAlloc.ii: In instantiation of 'void test_shared_alloc() [with
MemorySpace = HostSpace; ExecutionSpace = Serial]':
TestSerial_SharedAlloc.ii:5645:48:   required from here
TestSerial_SharedAlloc.ii:169:66: internal compiler error: in
lookup_template_class_1, at cp/pt.c:9459
   auto __trans_tmp_5467 = RecordFull::allocate( s, name, size * 0 );
  ^~~~
0x7f0352c3b09a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.


unfortunately creduce doesn't terminate when trying to reproduce it.

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Known to work||9.0
Version|unknown |8.2.0
   Target Milestone|--- |9.0
  Known to fail||8.2.0

--- Comment #3 from Wilco  ---
(In reply to Gael Guennebaud from comment #2)
> Indeed, it fails to remove the dup only if the coefficient is used multiple
> times as in the following reduced exemple: (https://godbolt.org/z/hmSaE0)
> 
> 
> #include 
> 
> void foo(const float* a, const float * b, float * c, int n) {
> float32x4_t c0, c1, c2, c3;
> c0 = vld1q_f32(c+0*4);
> c1 = vld1q_f32(c+1*4);
> for(int k=0; k {
> float32x4_t a0 = vld1q_f32(a+0*4+k*4);
> float32x4_t b0 = vld1q_f32(b+k*4);
> c0 = vfmaq_laneq_f32(c0, a0, b0, 0);
> c1 = vfmaq_laneq_f32(c1, a0, b0, 0);
> }
> vst1q_f32(c+0*4, c0);
> vst1q_f32(c+1*4, c1);
> }
> 
> 
> I tested with gcc 7 and 8.

Confirmed for GCC8, fixed on trunk. I tried the above example with up to 4 uses
and it always generates the expected code on trunk. So this is fixed for GCC9,
however it seems unlikely the fix (multi-use support in Combine) could be
backported.

[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions

[gael.guennebaud at gmail dot com]

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

--- Comment #4 from Gael Guennebaud  ---
Good to know this is fixed in trunk! Thank you, and sorry for the false alarm
then.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/89103] New: Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

Bug ID: 89103
   Summary: Allow blank format items in format strings
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark.eggleston at codethink dot com
  Target Milestone: ---

Created attachment 45554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45554&action=edit
Patch to allow blank item in format

gfortran as of revision: svn+ssh://gcc.gnu.org/svn/gcc/trunk@268360

At the end of list of specifiers a blank item can appear between the comma and
closing bracket.

The following error is produced, as it should be:

   18 | 10FORMAT( I5,)
  |  1
Error: Unexpected element ')' in format string at (1)

In legacy Fortran this is not the case PGI Fortran 18.10 silently accepts this
with no compiler switches. I believe this is feature originated from DEC
Fortran.

Attached is a patch that will allow this.

As this is non-standard Fortran this feature is only enabled using
-fdec-blank-format-item which is also enabled by -fdec.

[Bug fortran/89103] Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #1 from MarkEggleston  ---
Created attachment 4
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4&action=edit
Change log for gcc/fortran for patch

[Bug fortran/89103] Allow blank format items in format strings

[mark.eggleston at codethink dot com]

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

--- Comment #2 from MarkEggleston  ---
Created attachment 45556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45556&action=edit
Change Log for gc/testsuite for patch

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #17 from Florian Weimer  ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
> 
> Testing this and would be grateful for a test run.

I believe the #pragma GCC push_options needs to come first, but it shouldn't
matter in this context because the option set is never actually restored.

(I have not tested the patch yet.)

[Bug ipa/89104] New: ICE: Segmentation fault (in tree_int_cst_elt_check)

[asolokha at gmx dot com]

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

Bug ID: 89104
   Summary: ICE: Segmentation fault (in tree_int_cst_elt_check)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gcc-9.0.0-alpha20190127 snapshot (r268327), 8.2, 7.3, 6.3, 5.4, 4.9.4 all ICE
when compiling the following testcase:

#pragma omp declare simd aligned (c5)
void
lp (int *c5)
{
  (void) c5;
}

% gcc-9.0.0-alpha20190127 -fopenmp -c udqj9h0r.c
during IPA pass: simdclone
udqj9h0r.c:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xd7147f crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/toplev.c:326
0x1673858 tree_int_cst_elt_check(tree_node*, int, char const*, int, char
const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/tree.h:3375
0x1673858 simd_clone_clauses_extract
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:248
0x1673858 expand_simd_clones(cgraph_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:1611
0x16744cf ipa_omp_simd_clone
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:1704
0x16744cf execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/omp-simd-clone.c:1732

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #28 from dave.anglin at bell dot net ---
On 2019-01-29 4:53 a.m., redi at gcc dot gnu.org wrote:
> Done - do you want to keep this open?
Could the change be backported?  I will test in coming days.

[Bug c++/89105] New: -Wabi warns for functions with internal linkage

[redi at gcc dot gnu.org]

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

Bug ID: 89105
   Summary: -Wabi warns for functions with internal linkage
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

// { dg-options "-fabi-version=12 -Wabi=11" }

namespace {
  template
void run(F f, int i)
{
  f(i);
}
}

void f()
{
  run([](int) { }, 1);
}


wabi.cc: In function ‘void f()’:
wabi.cc:13:6: warning: empty class ‘f()::’ parameter passing ABI
changes in -fabi-version=12 (GCC 8) [-Wabi]
   run([](int) { }, 1);
   ~~~^~~~
wabi.cc: In function ‘void {anonymous}::run(F, int) [with F =
f()::]’:
wabi.cc:5:10: warning: empty class ‘f()::’ parameter passing ABI
changes in -fabi-version=12 (GCC 8) [-Wabi]
 void run(F f, int i)
  ^~~

This seems like a false position, because the function cannot be called from
outside the current translation unit. It has internal linkage, and its address
is never taken.

Making it static instead of using an unnamed namespace doesn't change anything.

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[a.drobyshev at samsung dot com]

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

Andrey Drobyshev  changed:

   What|Removed |Added

 CC||a.drobyshev at samsung dot com

--- Comment #8 from Andrey Drobyshev  ---
I recently started to work on this issue as well. I managed to put a dummy
global variable into .data, .rodata and .bss as follows:

static void
emit_globals_protector(void)
{
  tree decl, id, init;

  id = get_identifier ("__asan_dummy_global");
  decl = build_decl (BUILTINS_LOCATION, VAR_DECL, id, integer_type_node);
  init = build_one_cst(integer_type_node);

  SET_DECL_ASSEMBLER_NAME (decl, id);
  TREE_ADDRESSABLE (decl) = 1;
  DECL_ARTIFICIAL (decl) = 1;
  TREE_STATIC (decl) = 1;
  TREE_PUBLIC (decl) = 1;
  TREE_USED (decl) = 1;

  TREE_READONLY (init) = 1;  // controls whether variable goes to .rodata
or .data
  TREE_STATIC (init) = 1;
  DECL_INITIAL (decl) = init;// controls whether variable gets initialized
or goes to .bss

  varpool_node::add(decl);
}

Calling varpool_node::add() makes sure that created dummy global goes first
into the target section, as it leads to call to assemble_variable():

#0  categorize_decl_for_section (decl=0x77ff4e10, reloc=0) at
../../gcc/varasm.c:6378
#1  0x01096112 in default_elf_select_section (decl=0x77ff4e10,
reloc=0, align=256) at ../../gcc/varasm.c:6499
#2  0x010b6ce3 in x86_64_elf_select_section (decl=0x77ff4e10,
reloc=0, align=256) at ../../gcc/config/i386/i386.c:6549
#3  0x0108afd3 in get_variable_section (decl=0x77ff4e10,
prefer_noswitch_p=false) at ../../gcc/varasm.c:1170
#4  0x0108d70b in assemble_variable (decl=0x77ff4e10, top_level=0,
at_end=1, dont_output_data=0) at ../../gcc/varasm.c:2206
#5  0x0109fd8a in varpool_node::assemble_decl (this=0x77281100) at
../../gcc/varpool.c:582
#6  0x00917f92 in varpool_node::finalize_decl (decl=0x77ff4e10) at
../../gcc/cgraphunit.c:823
#7  0x0109f9c0 in varpool_node::add (decl=0x77ff4e10) at
../../gcc/varpool.c:473
#8  0x0091ba93 in emit_globals_protector () at
../../gcc/cgraphunit.c:2187
#9  0x0091bab6 in output_in_order (no_reorder=false) at
../../gcc/cgraphunit.c:2218
#10 0x0091c4f4 in symbol_table::compile (this=0x771280a8) at
../../gcc/cgraphunit.c:2524
#11 0x0091c73f in symbol_table::finalize_compilation_unit
(this=0x771280a8) at ../../gcc/cgraphunit.c:2620
#12 0x00d90fbf in compile_file () at ../../gcc/toplev.c:496
#13 0x00d93448 in do_compile () at ../../gcc/toplev.c:1998
#14 0x00d936d2 in toplev::main (this=0x7fffdbb0, argc=27,
argv=0x7fffdcb8) at ../../gcc/toplev.c:2106
#15 0x016e11d1 in main (argc=27, argv=0x7fffdcb8) at
../../gcc/main.c:39

However, there're questions:
1. I wonder is it really possible to emit zero-sized dummies and initialize
them as well (i.e. emit them into .data/.rodata)? For now I emit variables of
integer types, but that leads to the presence of couple addressable bytes in
the beginning of the section.
2. What should we do with sections like .data.rel.ro, .data.rel.ro.local? They
suffer from this bug too, but it's not that easy to put globals there, as you
must set various attributes onto decl to ensure it will receive the right reloc
value.

[Bug c++/89105] -Wabi warns for functions with internal linkage

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This is seen while building libstdc++.so but is harmless and can be ignored:

/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc: In function
‘uintmax_t std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)’:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc:954:68: warning:
empty class ‘std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)::’ parameter passing ABI changes in
-fabi-version=12 (GCC 8) [-Wabi]
  954 |   auto s = do_stat(p, ec, [](const auto& st) { return S{st}; }, S{});
  |^
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc: In function ‘T
{anonymous}::do_stat(const std::filesystem::__cxx11::path&, std::error_code&,
Accessor, T) [with Accessor = std::filesystem::file_size(const
std::filesystem::__cxx11::path&, std::error_code&)::; T
= std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)::S]’:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++17/fs_ops.cc:925:5: warning:
empty class ‘std::filesystem::file_size(const std::filesystem::__cxx11::path&,
std::error_code&)::’ parameter passing ABI changes in
-fabi-version=12 (GCC 8) [-Wabi]
  925 | do_stat(const fs::path& p, std::error_code& ec, Accessor f, T
deflt)
  | ^~~

It can't be suppressed with a pragma (PR 87611).

[Bug c/89061] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45557&action=edit
gcc9-pr89061.patch

Untested patch that implements this.

[Bug c/89061] [9 Regression] GCC 9 introduces false positive in -Wjump-misses-init

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|GCC 9 introduces false  |[9 Regression] GCC 9
   |positive in |introduces false positive
   |-Wjump-misses-init  |in -Wjump-misses-init

[Bug c++/88865] [[no_unique_address]] leads to sizeof(T) == 0, which cannot be

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Tue Jan 29 15:39:40 2019
New Revision: 268368

URL: https://gcc.gnu.org/viewcvs?rev=268368&root=gcc&view=rev
Log:
PR c++/89089 - ICE with [[no_unique_address]].

In 89089, we were never actually setting DECL_SIZE on an empty data member,
because its type is a POD, so we didn't set it in the maybe-overlapping
section.  Fixed by also handling empty types there.

In 88865, we were failing to consider empty data members in
include_empty_classes.  Fixed by making end_of_class always include them.

While looking at these I noticed that the ABI says that a
potentially-overlapping data member makes its class non-layout-POD, and that
an empty data member doesn't prevent its class from being empty, so I've
implemented those points as well.

PR c++/88865 - wrong layout with [[no_unique_address]].
* class.c (check_field_decls): A potentially-overlapping field makes
the class non-layout-POD, but not non-empty.
(end_of_class): Always consider empty data members.
(layout_class_type): Set DECL_SIZE for empty fields.

Added:
trunk/gcc/testsuite/g++.dg/abi/no_unique_address4.C
trunk/gcc/testsuite/g++.dg/abi/no_unique_address5.C
trunk/gcc/testsuite/g++.dg/cpp2a/no_unique_address2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Tue Jan 29 15:39:40 2019
New Revision: 268368

URL: https://gcc.gnu.org/viewcvs?rev=268368&root=gcc&view=rev
Log:
PR c++/89089 - ICE with [[no_unique_address]].

In 89089, we were never actually setting DECL_SIZE on an empty data member,
because its type is a POD, so we didn't set it in the maybe-overlapping
section.  Fixed by also handling empty types there.

In 88865, we were failing to consider empty data members in
include_empty_classes.  Fixed by making end_of_class always include them.

While looking at these I noticed that the ABI says that a
potentially-overlapping data member makes its class non-layout-POD, and that
an empty data member doesn't prevent its class from being empty, so I've
implemented those points as well.

PR c++/88865 - wrong layout with [[no_unique_address]].
* class.c (check_field_decls): A potentially-overlapping field makes
the class non-layout-POD, but not non-empty.
(end_of_class): Always consider empty data members.
(layout_class_type): Set DECL_SIZE for empty fields.

Added:
trunk/gcc/testsuite/g++.dg/abi/no_unique_address4.C
trunk/gcc/testsuite/g++.dg/abi/no_unique_address5.C
trunk/gcc/testsuite/g++.dg/cpp2a/no_unique_address2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed.

[Bug c++/88865] [[no_unique_address]] leads to sizeof(T) == 0, which cannot be

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/86740] [8 Regression] ICE with hana and nested lambdas (likely a regression, tsubst_copy, at cp/pt.c:15325)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 8.3 as well.

[Bug c++/89105] -Wabi warns for functions with internal linkage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #9 from Steve Ellcey  ---
Created attachment 45559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45559&action=edit
Assembly output from aarch64-linux-gnu

This test is still failing on aarch64.  Attached is the .s file from a
top-of-tree GCC build on aarch64-linux-gnu.

[Bug ipa/89104] ICE: Segmentation fault (in tree_int_cst_elt_check)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Jakub Jelinek  ---
*** Bug 89104 has been marked as a duplicate of this bug. ***

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Looking again what ICC does here: ICC 16 emits a1 (i.e. like aligned(i_x:1)),
ICC 17 emits a8 (i.e. like aligned(i_x:8)), ICC 18 and 19 don't emit anything
(i.e. ignore the aligned clause that doesn't tell anything interesting.
I guess that is the most reasonable behavior, so will implement it in GCC.

[Bug c++/66676] pragma omp simd aligned(x) results in "internal compiler error: Segmentation fault"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45560&action=edit
gcc9-pr66676.patch

Untested fix.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #18 from Florian Weimer  ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
> 
> Testing this and would be grateful for a test run.

Is this hunk needed as well, or will the unwinding information take care of
this?  (__cxa_call_unexpected has another d8 register spill.)

Index: libstdc++-v3/libsupc++/eh_call.cc
===
--- libstdc++-v3/libsupc++/eh_call.cc   (revision 268364)
+++ libstdc++-v3/libsupc++/eh_call.cc   (working copy)
@@ -22,6 +22,11 @@
 // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .

+#ifdef __arm__
+#pragma GCC target ("fpu=none")
+#pragma GCC push_options
+#endif
+
 #include 
 #include 
 #include 

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #10 from Dominique d'Humieres  ---
What should be the status of this PR? It works for me.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #19 from Jakub Jelinek  ---
(In reply to Florian Weimer from comment #18)
> (In reply to Ramana Radhakrishnan from comment #15)
> > Testing this and would be grateful for a test run.
> 
> Is this hunk needed as well, or will the unwinding information take care of
> this?  (__cxa_call_unexpected has another d8 register spill.)

No idea here.

> --- libstdc++-v3/libsupc++/eh_call.cc   (revision 268364)
> +++ libstdc++-v3/libsupc++/eh_call.cc   (working copy)
> @@ -22,6 +22,11 @@
>  // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>  // .
>  
> +#ifdef __arm__
> +#pragma GCC target ("fpu=none")
> +#pragma GCC push_options
> +#endif

But why the #pragma GCC push_options?  That makes no sense.
Either you need to push options before GCC target and pop later on, but if you
pop at the end of TU and don't really expect anything else to be emitted there,
only #pragma GCC target should be enough (that applies to the other patch too).

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[fw at gcc dot gnu.org]

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

--- Comment #20 from Florian Weimer  ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
> 
> Testing this and would be grateful for a test run.

I can confirm that this patch fixes the glibc test suite failure,
nptl/tst-thread-exit-clobber.

[Bug fortran/51637] Add compile-time error if array is too large

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
If I add a line

print *, size(a, kind=16), sizeof(a(1))

the output is

 184467440737095516150

Note that the size of A is zero.

For very large arrays the darwin loader emits either

ld: LC_SEGMENT filesize too large file 'object.o' for architecture x86_64

for

program main
  character(len=2_8**33), parameter :: a = ""
  character(len=2_8**33) :: b
  print '(A)',a
  b = ""
  print '(A)',b
end program main

or (pr69061)

ld: 32-bit RIP relative reference out of range (5624320831 max is +/-2GB): from
_MAIN__ (0x11692) to _pxz.3873 (0x24F3C8080) in '_MAIN__' from
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccYDTFMi.o for architecture
x86_64

What should be do with this PR?

[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #1)
> We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for
> anonymous namespace type but it has EXTERNAL flag set.
> 
> Jason, why this happens? I am changing type to C++: if there is indeed legal
> reason to have exported vtables for anonymous types, then we can simply drop
> the sanity check.

It isn't exported; it has DECL_EXTERNAL set because it isn't defined, and it
isn't defined because nothing uses it, so it isn't needed.  Note that it isn't
TREE_PUBLIC.

[Bug tree-optimization/89098] ICE: verify_ssa failed (Error: definition in block 27 follows the use)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reproduceable on x86_64-linux with -m32 too.
We have:
  _62 = stride.18_139 * 4;
  _281 = _62 + offset.19_147;
  _63 = stride.18_139 * 5;
  _282 = _63 + offset.19_147;
  _283 = size.20_140 + offset.19_147;
  _486 = stride.18_139 * 6;
  _487 = offset.19_147 + _486;
  _488 = stride.18_139 * 3;
  _489 = offset.19_147 + _488;
  _490 = stride.18_139 * 2;
  _491 = offset.19_147 + _490;
before slsr and slsr changes that into:
  _62 = stride.18_139 * 4;
  _281 = _62 + offset.19_147;
  _63 = stride.18_139 * 5;
  _282 = _281 + stride.18_139;
  slsr_324 = stride.18_139 * 3;
  _283 = _281 + slsr_324;
  _486 = stride.18_139 * 6;
  _487 = _281 + _490;
  _488 = stride.18_139 * 3;
  _489 = _281 - stride.18_139;
  _490 = stride.18_139 * 2;
  _491 = _281 - _490;
and the ICE is because _490 is used before definition.

C testcase that ICEs even on x86_64-linux with -O2 --param
max-slsr-cand-scan=1:
void bar (int, int, int, int, int, int);

int
foo (int s, int o, int x)
{
  int t0 = s * 7;
  if (x)
{
  int t1 = s * 4;
  int t2 = t1 + o;
  int t3 = s * 5;
  int t4 = t3 + o;
  int t5 = t0 + o;
  int t6 = s * 6;
  int t7 = o + t6;
  int t8 = s * 3;
  int t9 = o + t8;
  int t10 = s * 2;
  int t11 = o + t10;
  bar (t2, t4, t5, t7, t9, t11);
}
  return t0;
}

[Bug c++/89089] [9 regression] various ICEs in range-v3's 1.0 branch

[h2+bugs at fsfe dot org]

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

--- Comment #10 from Hannes Hauswedell  ---
Thanks for the quick fix!

[Bug fortran/61073] -fcheck='do' leads to twice the amount of GDB steps in a do loop

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
I cannot reproduce it with recent gfortran (9.0).

Without feedback I'll close this PR as FIXED.

[Bug fortran/89103] Allow blank format items in format strings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
The patch was discussed in the fortran@ list.  One can
find history here: https://gcc.gnu.org/ml/fortran/2019-01/msg00175.html

[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  ---
> > We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for
> > anonymous namespace type but it has EXTERNAL flag set.
> > 
> > Jason, why this happens? I am changing type to C++: if there is indeed legal
> > reason to have exported vtables for anonymous types, then we can simply drop
> > the sanity check.
> 
> It isn't exported; it has DECL_EXTERNAL set because it isn't defined, and it
> isn't defined because nothing uses it, so it isn't needed.  Note that it isn't
> TREE_PUBLIC.

Hmm, so perhaps just adjusting sanity check to also check ||
!TREE_PUBLIC?

Honza

[Bug fortran/66708] Possible (minor) improvement on formatted io with format too short

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of pr27436.

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

[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #5 from Dominique d'Humieres  ---
*** Bug 66708 has been marked as a duplicate of this bug. ***

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #21 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Florian Weimer from comment #18)
> > (In reply to Ramana Radhakrishnan from comment #15)
> > > Testing this and would be grateful for a test run.
> > 
> > Is this hunk needed as well, or will the unwinding information take care of
> > this?  (__cxa_call_unexpected has another d8 register spill.)
> 
> No idea here.

I'll try and analyse that - The key is ensuring that there is absolutely no
floating point code in eh_call.cc , if there is likely to be floating point
anywhere this isn't correct 

> 
> > --- libstdc++-v3/libsupc++/eh_call.cc   (revision 268364)
> > +++ libstdc++-v3/libsupc++/eh_call.cc   (working copy)
> > @@ -22,6 +22,11 @@
> >  // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> >  // .
> >  
> > +#ifdef __arm__
> > +#pragma GCC target ("fpu=none")
> > +#pragma GCC push_options
> > +#endif
> 
> But why the #pragma GCC push_options?  That makes no sense.
> Either you need to push options before GCC target and pop later on, but if
> you pop at the end of TU and don't really expect anything else to be emitted
> there, only #pragma GCC target should be enough (that applies to the other
> patch too).

I think that's just percolated my quick hack to discuss the issue. 

It should be enough to do #pragma GCC target . The final patch I have does that
. Thanks for confirming that the patch in it's essence fixes up the issue.

regards
Ramana

[Bug fortran/89086] Add a Fortran language reference chapter

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #3)
> > > I don't think this is realistic unless someone steps on with at least a
> > > draft.
> >
> > Well, yes. Howewer, I would prefer if you did not close it.
> 
> What is the rationale?

Because I just submitted it? :-)

I think there is no harm in keeping this, because it serves to keep
track of the issue.

[Bug other/89106] New: cast-to-union documentation incorrect w.r.t. lvalueness

[amonakov at gcc dot gnu.org]

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

Bug ID: 89106
   Summary: cast-to-union documentation incorrect w.r.t.
lvalueness
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

The patch for PR 71560 changed the wording in "Cast to a Union Type"
documentation section. It now reads:

A cast to a union actually creates a compound literal and yields an lvalue,
not an rvalue like true casts do.

which is not true: a cast to union never produced an lvalue expression. The
last hunk in the patch was therefore incorrect:

-A cast to union type is similar to other casts, except that the type
-specified is a union type.  You can specify the type either with
-@code{union @var{tag}} or with a typedef name.  A cast to union is actually
-a constructor, not a cast, and hence does not yield an lvalue like
-normal casts.  (@xref{Compound Literals}.)
+A cast to union type looks similar to other casts, except that the type
+specified is a union type.  You can specify the type either with the
+@code{union} keyword or with a @code{typedef} name that refers to
+a union.  A cast to a union actually creates a compound literal and
+yields an lvalue, not an rvalue like true casts do.
+(@xref{Compound Literals}.)

[Bug c/89107] New: -Wconversion warning is not appropriate since conversion doesn't alter value, because of mask entered before.

[mareksz1958 at wp dot pl]

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

Bug ID: 89107
   Summary: -Wconversion warning is not appropriate since
conversion doesn't alter value, because of mask
entered before.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mareksz1958 at wp dot pl
  Target Milestone: ---

Such code is failing to compile on 2):

union U {
unsigned int a:20;
};

int main() {
union U u;
unsigned int val = 0xaabbc000;

u.a = val & 0xf; // 1) works
u.a = (val >> 12) & 0xf; // 2) doesn't
}

Because of the shift the compiler refuses to accept the conversion. And
complains in the following way:

$ gcc wconv.c -Wconversion -Werror
wconv.c: In function ‘main’:
wconv.c:10:11: error: conversion to ‘unsigned int:20’ from ‘unsigned int’ may
alter its value [-Werror=conversion]
 u.a = (val >> 12) & 0xf; /* 2) doesn't */
   ^
cc1: all warnings being treated as errors

Clang is compiling following code successfully. Seems like there is some
off-by-one bug; Mask 0x7 works without warnings/errors.

[Bug middle-end/89002] [7/8 Regression] ICE in scan_omp_1_op, at omp-low.c:3166

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |scan_omp_1_op, at   |scan_omp_1_op, at
   |omp-low.c:3166  |omp-low.c:3166

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

[Bug fortran/55978] class_optional_2.f90 -Os fails

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres  ---
This PR is probably related to/duplicate of pr54618.

These two PRs are so mangled that it very difficult to tell what has been fixed
and what remains to be fixed.

IMO it would be better to open a new PR for what is still broken an to close
these two as FIXED.

[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #22 from Dominique d'Humieres  ---
This PR is probably related to/duplicate of pr55978.

These two PRs are so mangled that it very difficult to tell what has been fixed
and what remains to be fixed.

IMO it would be better to open a new PR for what is still broken an to close
these two as FIXED.

[Bug c/89108] New: variable tracking size limit exceeded

[jg at jguk dot org]

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

Bug ID: 89108
   Summary: variable tracking size limit exceeded
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Created attachment 45561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45561&action=edit
var tracking test case

I'm seeing this on 350 line file, will attach.

Could the "note: variable tracking size limit exceeded with
-fvar-tracking-assignments" message be expanded?

How about including the size limit, and how much would be actually required?

"note: variable tracking size limit 1,000,000 bytes exceeded by 512,000 bytes"


I saw there was this option, but not clear what to set it to, it's not ideal
for me to need to set it.
--param=max-vartrack-size=


$ g++-8 -g -O2 -D_GLIBCXX_ASSERTIONS -fsanitize=undefined,address
-fno-omit-frame-pointer -c var_tracking.cpp
var_tracking.cpp: In function ‘bool f(const string&, std::__cxx11::string&)’:
var_tracking.cpp:20:6: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without
 bool f(const std::string & name, string & ref)
  ^

[Bug c/89108] variable tracking size limit exceeded

[jg at jguk dot org]

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

--- Comment #1 from Jonny Grant  ---
Could gcc even support a dynamic size? to avoid a hard coded limit?

[Bug c/35608] limit-structnest.c fails due to O(n^2) memory usage in record_component_alias

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #10 from John David Anglin  ---
This test doesn't fail using gcc-8, but it now fails with 9.0.1 on
hppa-unknown-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg02949.html

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagn
ostics-color=never-O0  -w -c -o limits-structnest.o
/home/dave/gnu/gcc/gcc/g
cc/testsuite/gcc.c-torture/compile/limits-structnest.c(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagno
stics-color=never -O0 -w -c -o limits-structnest.o
/home/dave/gnu/gcc/gcc/gcc/te
stsuite/gcc.c-torture/compile/limits-structnest.c
virtual memory exhausted: Cannot allocate memory
compiler exited with status 1
FAIL: gcc.c-torture/compile/limits-structnest.c   -O0  (test for excess errors)
Excess errors:
virtual memory exhausted: Cannot allocate memory

[Bug fortran/88076] Shared Memory implementation for Coarrays

[damian at sourceryinstitute dot org]

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

--- Comment #8 from Damian Rouson  ---
(In reply to Nicolas Koenig from comment #7)

> I actually opted to use multiprocessing with shared memory (shm_open() & co)
> instead of multithreading, since it will be much easier and faster with
> static variables, of which gfortran makes extensive use. Also, it greatly
> simplifies interoperability with OpenMP. 

This sounds like a great choice.  I have no prior familiarity with shm_open(),
but I very much like the idea of simplifying interoperability with OpenMP. 

> The only real downsides I can think of are slower spinup times... 

It will be interesting to compare the performance with MPI.  I also wonder if
this would also someday provide for a hybrid implementation wherein shm_open()
is used within a node and MPI is used across nodes, e.g., maybe images within
a TEAM could use shm_open() to communicate, while any communication between
TEAMs could use MPI.

> 
> I actually think it would be best not to turn it into a separate library but
> instead integrate it into libgfortran. 

I agree. 

> This way, it will not be necessary to
> install a seperate library and thereby make it easier for people to start
> using coarrays. Therefore, it would make sense to use the libgfortran
> descriptors.

> 
> At the moment, sync_all() is called after image creation.

I think that will suffice.

[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-29
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from kargl at gcc dot gnu.org ---
The patch was discussed in the fortran@ list.  One can
find history here: https://gcc.gnu.org/ml/fortran/2019-01/msg00175.html

Patch is OK to commit when gcc 10 stage 1 opens.