[Bug c/39117] missed strict-aliasing warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
strict-aliasing warnings are IMHO completely misguided.

Note that for the testcase accessing char[] storage is valid with all
types so it is correct to not warn about either case.

So I'd say "fixed" to this one... but fixed in another way than requested.

[Bug middle-end/39322] Missed aliasing warning

[rguenth at gcc dot gnu.org]

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

Bug 39117 Summary: missed strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39117

   What|Removed |Added

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

[Bug c++/86669] New: [5/6/7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser

[iains at gcc dot gnu.org]

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

Bug ID: 86669
   Summary: [5/6/7/8/9 regression] Complete object constructor
clone omits length for a c++11 braced initialiser
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44435&action=edit
pre-processed and reduced code

This applies to targets that do not allow (or have) alias support for
constructor clones.

c-reduce has obfuscated the variable names in the reduced code, of course ...

The original code looks like this:



AArch64LegalizerInfo::AArch64LegalizerInfo(const AArch64Subtarget &ST) 
  : LegalizerInfo()  {
  const LLT p0 = LLT::pointer(0, 64);
  const LLT s1 = LLT::scalar(1);
  const LLT s8 = LLT::scalar(8);
  const LLT s16 = LLT::scalar(16);
  const LLT s32 = LLT::scalar(32);
  const LLT s64 = LLT::scalar(64);
  const LLT s128 = LLT::scalar(128);
  const LLT v2s32 = LLT::vector(2, 32);
  const LLT v4s32 = LLT::vector(4, 32);
  const LLT v2s64 = LLT::vector(2, 64);

  for (auto Ty : {p0, s1, s8, s16, s32, s64})
setAction({/*G_IMPLICIT_DEF*/41, Ty}, Legal);

...
 }
=

The gimple for the base constructor contains:

"

try
  {
D.2730 = {};
D.2730.i = 6; < OK _M_len is set
D.2729[0] = e;
D.2729[1] = f;
D.2729[2] = g;
D.2729[3] = h;
D.2729[4] = i;
D.2729[5] = j;
D.2730.a = &D.2729;
__for_range = &D.2730;
__for_begin = std::initializer_list::begin
(__for_range);
__for_end = std::initializer_list::end
(__for_range);

"

but for the complete constructor:

"
try
  {
D.2745 = {}; <<< _M_len init missing 
D.2744[0] = e;
D.2744[1] = f;
D.2744[2] = g;
D.2744[3] = h;
D.2744[4] = i;
D.2744[5] = j;
D.2745.a = &D.2744;
__for_range = &D.2745;
__for_begin = std::initializer_list::begin
(__for_range);
__for_end = std::initializer_list::end
(__for_range);
:

"



With clang 
.../bin/clang -cc1 -triple x86_64-apple-macosx10.12.0 -x c++-cpp-output
AArch64LegalizerInfo-fmt.ii -O0 -S -std=c++11 -fvisibility-inlines-hidden
-fno-rtti -o tc.s

The complete constructor is rendered as a thunk calling the base constructor
(not sure why we conclude this is not viable in GCC)

==

With GCC (all versions I've tried 5...trunk) we get the effect above.

.../libexec/gcc/x86_64-apple-darwin14/7.3.0/cc1plus -fpreprocessed
AArch64LegalizerInfo-fmt.ii -fPIC -quiet  -mmacosx-version-min=10.10 
-mtune=core2  -g3 -O0 -Werror=date-time -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wpedantic
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-std=c++11 -fPIC -fvisibility-inlines-hidden -fno-exceptions -fno-rtti  -o tg.s 

==

I took a look at what was happening in cp/optimize.c:maybe_clone_body() but
couldn't see any special difference between the operations carried out to clone
the base and the complete constructors.

[Bug lto/86654] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24933

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Richard Biener from comment #11)
> OK, so patch at least regresses
> 
> FAIL: g++.dg/debug/dwarf2/lambda1.C  -std=gnu++11  scan-assembler-times
> DW_TAG_variable[^.]*.ascii "this.0" 2
> FAIL: g++.dg/debug/dwarf2/lambda1.C  -std=gnu++14  scan-assembler-times
> DW_TAG_variable[^.]*.ascii "this.0" 2
> 
> but otherwise passes LTO bootstrap.  Have to investigate the above tomorrow.

The reason is that in the late phase we fail DIE re-use and instead generate
a specification DIE because

  if (((is_unit_die (old_die->die_parent)
/* This condition fixes the inconsistency/ICE with the
   following Fortran test (or some derivative thereof) while
   building libgfortran:

  module some_m
  contains
 logical function funky (FLAG)
   funky = .true.
end function
  end module
 */
|| (old_die->die_parent
&& old_die->die_parent->die_tag == DW_TAG_module)
|| context_die == NULL)
...
  subr_die = old_die;

triggers only because of context_die == NULL.  This is a funky area
but the comment "For local class methods, this doesn't apply; we just use the
old DIE." suggests

|| local_scope_p (old_die->die_parent)

pre early-debug merge already had the context_die == NULL check which
_possibly_ was supposed to match that comment.

[Bug c/86668] mixing ansi prototype with K&R definition

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Please use gcc-h...@gcc.gnu.org for user questions.

With the prototype in scope the non-prototyped definition of fun is adjusted. 
This doesn't happen if the prototype is no longer in scope.  If you want
defined behaviour you need to use the correct prototype with the argument
declared as double.

[Bug sanitizer/79635] Explain to translators what "asan" means

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Wed Jul 25 08:02:53 2018
New Revision: 262959

URL: https://gcc.gnu.org/viewcvs?rev=262959&root=gcc&view=rev
Log:
Explain asan parameters in params.def (PR sanitizer/79635).

2018-07-25  Martin Liska  

PR sanitizer/79635
* params.def: Explain ASan abbreviation and provide
a documentation link.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def

[Bug middle-end/86645] [9 Regression] UBSAN error: tree-cfg.c:7874:26: runtime error: load of value 4293224825, which is not a valid value for type 'dump_flag'

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Wed Jul 25 08:04:15 2018
New Revision: 262960

URL: https://gcc.gnu.org/viewcvs?rev=262960&root=gcc&view=rev
Log:
Limit dump_flag enum values range (PR middle-end/86645).

2018-07-25  Martin Liska  

PR middle-end/86645
* dumpfile.c: And excluded values with TDF_ALL_VALUES.
* dumpfile.h (enum dump_flag): Defince TDF_ALL_VALUES.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dumpfile.c
trunk/gcc/dumpfile.h

[Bug sanitizer/79635] Explain to translators what "asan" means

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug objc/80798] Dynamic stack buffer (alloca) overflow in ObjC compiler.

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Thanks Max.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[marxin at gcc dot gnu.org]

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

Bug 86645 Summary: [9 Regression] UBSAN error: tree-cfg.c:7874:26: runtime 
error: load of value 4293224825, which is not a valid value for type 'dump_flag'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86645

   What|Removed |Added

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

[Bug middle-end/86645] [9 Regression] UBSAN error: tree-cfg.c:7874:26: runtime error: load of value 4293224825, which is not a valid value for type 'dump_flag'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug gcov-profile/84758] Wrong coverage for quite simple CFG

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Martin Liška  ---
I've got patch candidate for that.

[Bug gcov-profile/83813] [GCOV] unsigned char in a union lead to incorrect coverage in gcov

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I've got patch candidate for that.

[Bug c++/84589] Failure to diagnose conflicting declaration of struct

[redi at gcc dot gnu.org]

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

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

[Bug c++/86665] declaration conflicts with target of using declaration already in scope

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Well done, yet another duplicate of your own bug.

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

[Bug other/60330] Licensed an unlicensed file

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I think this can just be closed as INVALID.

[Bug other/60330] Licensed an unlicensed file

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Agreed with Richi on IRC, let's close this.

[Bug c++/86661] [9 Regression] g++ ICE:tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in note_name_declared_in_class, at cp/class.c:8288

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-7-25
 CC||marxin at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
  Known to work||8.1.0
   Target Milestone|--- |9.0
Summary|g++ ICE:tree check: |[9 Regression] g++ ICE:tree
   |expected tree that contains |check: expected tree that
   |‘decl minimal’ structure,   |contains ‘decl minimal’
   |have ‘overload’ in  |structure, have ‘overload’
   |note_name_declared_in_class |in
   |, at cp/class.c:8288|note_name_declared_in_class
   ||, at cp/class.c:8288
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r262851.

[Bug c++/86663] g++ ICE with -std=c++11: internal compiler error: Segmentation fault

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-25
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug fortran/86667] [7/8/9 Regression] can no longer traverse environment table

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||wrong-code
   Last reconfirmed||2018-07-25
 Ever confirmed|0   |1
Summary|can no longer traverse  |[7/8/9 Regression] can no
   |environment table   |longer traverse environment
   ||table
   Target Milestone|--- |7.4
  Known to fail||7.3.0, 8.1.0, 9.0

--- Comment #3 from Dominique d'Humieres  ---
Confirmed. The change occurred between revisions r237590 (2016-06-20, OK) and
r238821 (2016-07-28, wrong code.

[Bug c++/86669] [6/7/8/9 regression] Complete object constructor clone omits length for a c++11 braced initialiser

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |6.5
Summary|[5/6/7/8/9 regression]  |[6/7/8/9 regression]
   |Complete object constructor |Complete object constructor
   |clone omits length for a|clone omits length for a
   |c++11 braced initialiser|c++11 braced initialiser

[Bug target/82005] Early lto debug not implemented on Darwin

[iains at gcc dot gnu.org]

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

--- Comment #43 from Iain Sandoe  ---
(In reply to Richard Biener from comment #42)
> (In reply to Iain Sandoe from comment #40)
> > Created attachment 44417 [details]
> > Patch series to enable copying of early debug data.

< snip>
(not ignoring the other options - but let's look at the possibilities to do it
a better way)

> >  - we seem to be jumping through quite a few hoops here, presumably because
> > it's too complex to emit the relevant data as markup into the LTO stream
> > directly?
> 
> The issue is that we'd have to distribute _all_ early debug to _each_
> LTRANS unit with late debug.  That's N-fold duplication that I wanted
> to avoid...  but yes, with the assembly scheme from above you could
> "prepend" each LTRANS unit with the "merged" early debug assembly.
> (at least N is limited by --param lto-partitions which defaults to 32...)

hmm...
> 
> Note that doing the assembling of the early debug during compile-time
> and then have the linker at the final link pick up that debug from the
> original objects as would have been my prefered way would be still the
> best for compile-time and disk-space usage.  But of course it wouldn't
> work for DARWIN w/o assembler changes to support this kind of relocations.

Darwin's assembler supports < undef symbol >+offset as a relocation.

with 
 "actual_target" the address we want
 "< undef symbol >" the LTO "_sinus.c.f4d7e603" type symbol we emit

I'm not too well up on DWARF specifics, probably time to RTFM... is the
intention of +offset-Lcurrent_section_start a PC-rel form? (i.e.
does the "offset" roll any more in than the actual_target-< undef symbol >)?

Normally, as I noted above, Darwin does things like
  set $foo Ltarget_sym-Lcurrent_section_start
  .long $foo 
to render the inter-section-offset as an absolute value (i.e. eliding the
reloc.) which dsymutil can understand because it knows the section starts
already.



So .. if we can 
 * copy the LTO early debug (renaming as now)
 * omit ld -r operation on these (which will just produce 0 output)
 * make the external refs into < undef symbol >+offset (where offset is
actual_target-symbol)
 * defer the linking of the early debug copied objects until the final link.

Then, since there will be references to the debug symbols in objects with
non-zero text/data, presumably the linker has to honour those.  (I don't know
if it will, but it seems it should).

this seems like something worth trying, before heading into the more
complicated stuff.

maybe I can fake the steps by hand and try it .. 

WDYT?

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[rsandifo at gcc dot gnu.org]

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

Bug 86618 Summary: tree-vect-stmts.c:3340: ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86618

   What|Removed |Added

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

[Bug gcov-profile/85367] [GCOV] A call to the _subborrow_u64 builtin-function is wrongly marked as executed twice

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Martin Liška  ---
Using gcc 8.1.1 I see proper values:

-:0:Source:pr85367.c
-:0:Graph:pr85367.gcno
-:0:Data:pr85367.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:int main ()
-:4:{
-:5:  unsigned char c;
-:6:  unsigned long long x, y;
-:7:
1:8:  c = 0;
1:9:  x = 1LL;
1:   10:  y = 0LL;
-:   11:
-:   12:  /* X = 0x0001, Y = 0x, C = 0.  */
1:   13:  c = _subborrow_u64 (c, y, x, &x); // executed 2x
-:   14:
1:   15:  return 0;
-:   16:}

[Bug c/86618] tree-vect-stmts.c:3340: ubsan error

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed by r262951.

[Bug tree-optimization/86644] [9 Regression] UBSAN error: tree-vect-patterns.c:225:17: runtime error: shift exponent 64 is too large for 32-bit type 'int'

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Fixed by r262961.

[Bug gcov-profile/85178] [GCOV] for(;;) statement is wrongly marked as not executed when there is a int array in its body in Gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Martin Liška  ---
Again, it's partially folded and due to that a misleading are reported.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[rsandifo at gcc dot gnu.org]

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

Bug 86644 Summary: [9 Regression] UBSAN error: tree-vect-patterns.c:225:17: 
runtime error: shift exponent 64 is too large for 32-bit type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86644

   What|Removed |Added

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

[Bug c/86667] [7/8/9 Regression] can no longer traverse environment table

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

  Component|fortran |c

--- Comment #4 from Dominique d'Humieres  ---
If I compile the C file with r237590 and link the object file to the fortran
file compiled with any revision (I have tried), the test works. This looks as a
C bug rather than a fortran one.

Note that compiling the C file with -Wall gives

pr86667.c: In function 'my_initenv':
pr86667.c:39:7: warning: value computed is not used [-Wunused-value]
   *ep++;
   ^
pr86667.c: In function 'my_readenv':
pr86667.c:54:14: warning: operation on 'ep' may be undefined [-Wsequence-point]
   *ep=*ep++;
~~^~

Also I get the warning (on darwin)

ld: warning: tentative definition of '_longest_env_variable' with size 8 from
'/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccDHXTrU.o' is being
replaced by real definition of smaller size 4 from 'pr86667.o'

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

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-07-25
Version|8.0 |7.3.1
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #14 from Andreas Krebbel  ---
I ran into the same problem with current GCC 7 branch. Could you apply your fix
also to GCC 7 branch?

[Bug lto/86654] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24933

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Just for record, building Firefox w/ GCC 8.1 w/o LTO produces:

 VM SIZE   FILE SIZE
 -- --
   0.0%   0 .debug_info   978Mi  48.5%
   0.0%   0 .debug_loc460Mi  22.8%
   0.0%   0 .debug_str158Mi   7.9%
   0.0%   0 .debug_ranges 132Mi   6.6%
   0.0%   0 .debug_line   111Mi   5.5%
  67.7%  74.9Mi .text74.9Mi   3.7%
   0.0%   0 .strtab  37.8Mi   1.9%
   0.0%   0 .symtab  14.1Mi   0.7%
   0.0%   0 .debug_abbrev11.4Mi   0.6%
   7.9%  8.75Mi .eh_frame8.75Mi   0.4%
   7.7%  8.47Mi .rela.dyn8.47Mi   0.4%
   7.7%  8.47Mi .rodata  8.47Mi   0.4%
   3.8%  4.20Mi .data.rel.ro 4.20Mi   0.2%
   1.9%  2.05Mi .eh_frame_hdr2.05Mi   0.1%
   1.5%  1.65Mi .dynstr  1.65Mi   0.1%
   0.9%  1.04Mi [Other]  1.33Mi   0.1%
   0.0%   0 .debug_aranges   1.29Mi   0.1%
   0.6%   650Ki .bss  0   0.0%
   0.4%   413Ki .dynsym   413Ki   0.0%
   0.0%   0 .debug_pubtypes   349Ki   0.0%
   0.0%  15 [None]0   0.0%
 100.0%   110Mi TOTAL1.97Gi 100.0%

[Bug libstdc++/86655] std::assoc_legendre should not constrain the value of m

[kretz at kde dot org]

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

--- Comment #2 from Matthias Kretz  ---
http://eel.is/c++draft/c.math#sf.cmath-1.3 might be the reason why `m <= l` is
enforced. But unless I'm confused the footnote on "mathematically defined"
tells us it should work:

- "(a) if it is explicitly defined for that set of argument values" - does not
hold

- "(b) if its limiting value exists and does not depend on the direction of
approach" - this holds, no?

[Bug fortran/80645] FAIL: gfortran.dg/elemental_subroutine_3.f90 -O1 (test for excess errors)

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|m68k-*-*, ia64-*-*, |m68k-*-*, ia64-*-*,
   |sparc*-*-*, powerpc*-*-*,   |sparc*-*-*, powerpc*-*-*,
   |hppa*-*-*, alpha*-*-*,  |hppa*-*-*, alpha*-*-*,
   |arm-*-* |arm-*-*, riscv*-*-*
 Status|WAITING |NEW

--- Comment #14 from Andreas Schwab  ---
Also fails on riscv.

[Bug c/86670] New: unsized static array var is removed but still accessed.

[iains at gcc dot gnu.org]

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

Bug ID: 86670
   Summary: unsized static array var is removed but still
accessed.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44436&action=edit
example code showing the issue

gcc-trunk-build$ ./gcc/xgcc -Bgcc ../static-var-removed-and-accessed.c -c
-save-temps -Wall -O0


Here we have

static int a[];

which is later assigned to.

===

we don't emit any storage for a, and it is silently changed to an undefined
external.

gcc-trunk-build$ nm static-var-removed-and-accessed.o
 U a
 T foo

gcc-trunk-build$ objdump -dr static-var-removed-and-accessed.o



 29:8b 55 fcmov-0x4(%ebp),%edx
  2c:   89 14 85 00 00 00 00mov%edx,0x0(,%eax,4)
2f: R_386_32a
  33:   83 45 f8 01 addl   $0x1,-0x8(%ebp)
  37:   81 7d f8 ff 00 00 00cmpl   $0xff,-0x8(%ebp)



The code is wrong, of course, but we are neither diagnosing, nor producing
sensible output.

I noticed this because it fails at assembly time on m32 Darwin (where the
compiler has concluded that 'a' is TU-local, but not present).

[Bug gcov-profile/85338] [GCOV] Type conversion leads to incorrect coverage in printf

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
I've got patch candidate for that.

[Bug testsuite/86671] New: Many testsuite failures due to -latomic not found

[sch...@linux-m68k.org]

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

Bug ID: 86671
   Summary: Many testsuite failures due to -latomic not found
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: riscv*-*-*

A lot of tests fail due to missing set up to find the uninstalled -latomic
during linking.  This affects gcc, g++, libstdc++ and a large part of the
libgomp tests.

[Bug gcov-profile/85350] [GCOV] wrong coverage when using constant variable in struct declaration

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
I've got patch candidate for that.

[Bug gcov-profile/85372] [GCOV] Wrong coverage with setjmp and longjmp function

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
I've got patch for that.

[Bug target/82005] Early lto debug not implemented on Darwin

[rguenther at suse dot de]

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

--- Comment #44 from rguenther at suse dot de  ---
On Wed, 25 Jul 2018, iains at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
> 
> --- Comment #43 from Iain Sandoe  ---
> (In reply to Richard Biener from comment #42)
> > (In reply to Iain Sandoe from comment #40)
> > > Created attachment 44417 [details]
> > > Patch series to enable copying of early debug data.
> 
> < snip>
> (not ignoring the other options - but let's look at the possibilities to do it
> a better way)
> 
> > >  - we seem to be jumping through quite a few hoops here, presumably 
> > > because
> > > it's too complex to emit the relevant data as markup into the LTO stream
> > > directly?
> > 
> > The issue is that we'd have to distribute _all_ early debug to _each_
> > LTRANS unit with late debug.  That's N-fold duplication that I wanted
> > to avoid...  but yes, with the assembly scheme from above you could
> > "prepend" each LTRANS unit with the "merged" early debug assembly.
> > (at least N is limited by --param lto-partitions which defaults to 32...)
> 
> hmm...
> > 
> > Note that doing the assembling of the early debug during compile-time
> > and then have the linker at the final link pick up that debug from the
> > original objects as would have been my prefered way would be still the
> > best for compile-time and disk-space usage.  But of course it wouldn't
> > work for DARWIN w/o assembler changes to support this kind of relocations.
> 
> Darwin's assembler supports < undef symbol >+offset as a relocation.

That's actually what we want...

> with 
>  "actual_target" the address we want
>  "< undef symbol >" the LTO "_sinus.c.f4d7e603" type symbol we emit
> 
> I'm not too well up on DWARF specifics, probably time to RTFM... is the
> intention of +offset-Lcurrent_section_start a PC-rel form? (i.e.
> does the "offset" roll any more in than the actual_target-< undef symbol >)?

The -Lcurrent_section_start is zero because .debug_info gets relocated to
zero.

That is, we want the offset in the final .debug_info section where
 points somewhere into it and offset is relative to
that symbol.

One of my "hacks" was to simply elide the minus in 
darwin_asm_output_dwarf_offset, if the section is a DWARF one.
ISTR that worked "fine" (it fixed the assembler messages) but I
didn't check the result further.

> Normally, as I noted above, Darwin does things like
>   set $foo Ltarget_sym-Lcurrent_section_start
>   .long $foo 
> to render the inter-section-offset as an absolute value (i.e. eliding the
> reloc.) which dsymutil can understand because it knows the section starts
> already.

So

 set $foo < undef symbol > - Lcurrent_section_start

makes $foo + offset work as a relocation?

> 
> 
> So .. if we can 
>  * copy the LTO early debug (renaming as now)
>  * omit ld -r operation on these (which will just produce 0 output)
>  * make the external refs into < undef symbol >+offset (where offset is
> actual_target-symbol)
>  * defer the linking of the early debug copied objects until the final link.
> 
> Then, since there will be references to the debug symbols in objects with
> non-zero text/data, presumably the linker has to honour those.  (I don't know
> if it will, but it seems it should).
> 
> this seems like something worth trying, before heading into the more
> complicated stuff.
> 
> maybe I can fake the steps by hand and try it .. 
> 
> WDYT?

If the relocation issue can be solved then yes, we should be able to
handle this.  The ld -r step was just to avoid explosion in the number
of input files for the final link - it currently doesn't save us
very much on ELF either because .debug_str isn't string-merged by
ld -r.  So I think we can simply remove this step alltogether.

[Bug lto/86654] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24933

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Wed, 25 Jul 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86654
> 
> --- Comment #13 from Martin Liška  ---
> Just for record, building Firefox w/ GCC 8.1 w/o LTO produces:
> 
>  VM SIZE   FILE SIZE
>  -- --
>0.0%   0 .debug_info   978Mi  48.5%
>0.0%   0 .debug_loc460Mi  22.8%
>0.0%   0 .debug_str158Mi   7.9%
>0.0%   0 .debug_ranges 132Mi   6.6%
>0.0%   0 .debug_line   111Mi   5.5%
>   67.7%  74.9Mi .text74.9Mi   3.7%
>0.0%   0 .strtab  37.8Mi   1.9%
>0.0%   0 .symtab  14.1Mi   0.7%
>0.0%   0 .debug_abbrev11.4Mi   0.6%
>7.9%  8.75Mi .eh_frame8.75Mi   0.4%
>7.7%  8.47Mi .rela.dyn8.47Mi   0.4%
>7.7%  8.47Mi .rodata  8.47Mi   0.4%
>3.8%  4.20Mi .data.rel.ro 4.20Mi   0.2%
>1.9%  2.05Mi .eh_frame_hdr2.05Mi   0.1%
>1.5%  1.65Mi .dynstr  1.65Mi   0.1%
>0.9%  1.04Mi [Other]  1.33Mi   0.1%
>0.0%   0 .debug_aranges   1.29Mi   0.1%
>0.6%   650Ki .bss  0   0.0%
>0.4%   413Ki .dynsym   413Ki   0.0%
>0.0%   0 .debug_pubtypes   349Ki   0.0%
>0.0%  15 [None]0   0.0%
>  100.0%   110Mi TOTAL1.97Gi 100.0%

If you throw dwz on it?  It should be able to compress the
early debug quite well (header file stuff)

[Bug target/82005] Early lto debug not implemented on Darwin

[iains at gcc dot gnu.org]

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

--- Comment #45 from Iain Sandoe  ---
(In reply to rguent...@suse.de from comment #44)
> On Wed, 25 Jul 2018, iains at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
> > 
> > --- Comment #43 from Iain Sandoe  ---
> > (In reply to Richard Biener from comment #42)
> > > (In reply to Iain Sandoe from comment #40)
> > > > Created attachment 44417 [details]
> > > > Patch series to enable copying of early debug data.

> > > Note that doing the assembling of the early debug during compile-time
> > > and then have the linker at the final link pick up that debug from the
> > > original objects as would have been my prefered way would be still the
> > > best for compile-time and disk-space usage.  But of course it wouldn't
> > > work for DARWIN w/o assembler changes to support this kind of relocations.
> > 
> > Darwin's assembler supports < undef symbol >+offset as a relocation.
> 
> That's actually what we want...
> 
> > with 
> >  "actual_target" the address we want
> >  "< undef symbol >" the LTO "_sinus.c.f4d7e603" type symbol we emit
> > 
> > I'm not too well up on DWARF specifics, probably time to RTFM... is the
> > intention of +offset-Lcurrent_section_start a PC-rel form? 
> > (i.e.
> > does the "offset" roll any more in than the actual_target-< undef symbol >)?
> 
> The -Lcurrent_section_start is zero because .debug_info gets relocated to
> zero.
> 
> That is, we want the offset in the final .debug_info section where
>  points somewhere into it and offset is relative to
> that symbol.
> 
> One of my "hacks" was to simply elide the minus in 
> darwin_asm_output_dwarf_offset, if the section is a DWARF one.
> ISTR that worked "fine" (it fixed the assembler messages) but I
> didn't check the result further.

OK .. so I should resurrect a version of that that applies only for the LTO
cases (since the "normal" cases are expecting the optimisation below).

> 
> > Normally, as I noted above, Darwin does things like
> >   set $foo Ltarget_sym-Lcurrent_section_start
> >   .long $foo 
> > to render the inter-section-offset as an absolute value (i.e. eliding the
> > reloc.) which dsymutil can understand because it knows the section starts
> > already.
> 
> So
> 
>  set $foo < undef symbol > - Lcurrent_section_start
> 
> makes $foo + offset work as a relocation?

When the consumer is dsymutil (or some other tool that expects this
optimisation, at least some versions of GDB can consume mach-o .o files)

It does what you'd expect - encodes the offset as an absolute value.

dsymutil (the debug linker) is walking the debug structures; so at each point
it knows what the offset relates to, thus avoiding the object storage and extra
time for the relocs.

ld64 does understand at least some of this (it has to handle at minimum FDEs) -
but I don't know without checking if it will ignore the debug relocs or not
(not been in that code recently).

> 
> > 
> > 
> > So .. if we can 
> >  * copy the LTO early debug (renaming as now)
> >  * omit ld -r operation on these (which will just produce 0 output)
> >  * make the external refs into < undef symbol >+offset (where offset is
> > actual_target-symbol)
> >  * defer the linking of the early debug copied objects until the final link.
> > 
> > Then, since there will be references to the debug symbols in objects with
> > non-zero text/data, presumably the linker has to honour those.  (I don't 
> > know
> > if it will, but it seems it should).
> > 
> > this seems like something worth trying, before heading into the more
> > complicated stuff.
> > 
> > maybe I can fake the steps by hand and try it .. 
> > 
> > WDYT?
> 
> If the relocation issue can be solved then yes, we should be able to
> handle this.  The ld -r step was just to avoid explosion in the number
> of input files for the final link - it currently doesn't save us
> very much on ELF either because .debug_str isn't string-merged by
> ld -r.  So I think we can simply remove this step alltogether.

OK.. it's on my TODO to try and simulate this by hand (at least I now have the
simple-object part done)

[Bug other/60330] Licensed an unlicensed file

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices

"You should maintain a proper copyright notice and a license notice in each
nontrivial file in the package. (Any file more than ten lines long is
nontrivial for this purpose.)"

So there's no need on this file.

[Bug gcov-profile/85351] [GCOV] Wrong coverage with exit() executed in a if statement within a called function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, it's really small issue.

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[jakub at gcc dot gnu.org]

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

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

Untested patch.  Does this fix it?

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 44437 [details]
> gcc9-pr86660.patch
> 
> Untested patch.  Does this fix it?

I'll try it out.

[Bug c/86670] unsized static array var is removed but still accessed.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-25
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The decl becomes

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x768a75e8 precision:32 min  max

pointer_to_this >
BLK
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x769bf738>
used static external read preserve BLK defer-output t.c:1:12
align:32 warn_if_not_align:0
attributes >>

so is STATIC EXTERNAL.  That means somehow grokdeclarator goes wrong.

[Bug gcov-profile/85370] [GCOV] Wrong coverage with the target_clones attribute

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
I've got patch candidate for that prints following:

-:0:Source:pr85370.c
-:0:Graph:pr85370.gcno
-:0:Data:pr85370.gcda
-:0:Runs:1
-:0:Programs:1
-:1:__attribute__((target_clones("arch=slm","default")))
1:2:int foo1 (int a, int b) { // executed  wrongly
1:3:  return a + b;
-:4:}
--
foo1.arch_slm.0:
0:2:int foo1 (int a, int b) { // executed  wrongly
0:3:  return a + b;
-:4:}
--
foo1.default.1:
1:2:int foo1 (int a, int b) { // executed  wrongly
1:3:  return a + b;
-:4:}
--
-:5:
1:6:int foo2 (int a, int b) {
1:7:  return a + b;
-:8:}
-:9:
1:   10:int main() {
1:   11:  foo1(1, 1);
1:   12:  foo2(1, 1);
1:   13:  return 1;
-:   14:}

[Bug gcov-profile/85337] [GCOV] inconsistent coverage in switch-case statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
If I put there some statements in the empty cases, then it's fine. Thus low
priority.

[Bug gcov-profile/85332] [GCOV] wrong coverage with do-while in switch-case statement

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
I've got patch candidate for that.

[Bug gcov-profile/83505] [GCOV] a pointer assignment before a dead return statment lead to incorrect coverage in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #3 from Martin Liška  ---
Anyway, low priority.

[Bug gcov-profile/83678] [GCOV] a pointer assignment before a break statment lead to incorrect coverage in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Martin Liška  ---
Due to folding of dead-code it's all optimized out.

[Bug gcov-profile/85197] [GCOV] The main function is wrongly marked as executed twice in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Martin Liška  ---
It's true but it's due to infinite loop done by 'while' statement.

[Bug gcov-profile/85349] [GCOV] struct varaible definition in while(1) will cause incorrect coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, but low priority issue.

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Created attachment 44437 [details]
> > gcc9-pr86660.patch
> > 
> > Untested patch.  Does this fix it?
> 
> I'll try it out.

Failure mode changes to:
...
/home/vries/openacc/trunk/build-gcc/gcc/xgcc
-B/home/vries/openacc/trunk/build-gcc/gcc/ -x c++
/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/libgomp.c++/for-15.C
-B/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/./libgomp/
-B/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/./libgomp/.libs
-I/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/./libgomp
-I/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/../../include
-I/home/vries/openacc/trunk/source-gcc/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never
-B/home/vries/openacc/trunk/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/9.0.0
-B/home/vries/openacc/trunk/install/offload-nvptx-none/bin -fopenmp -nostdinc++
-I/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/vries/openacc/trunk/source-gcc/libstdc++-v3/libsupc++
-I/home/vries/openacc/trunk/source-gcc/libstdc++-v3/include/backward
-I/home/vries/openacc/trunk/source-gcc/libstdc++-v3/testsuite/util -O2
-std=c++17
-B/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/./libgomp/../libstdc++-v3/src/.libs
-L/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/./libgomp/.libs
-L/home/vries/openacc/trunk/build-gcc/x86_64-pc-linux-gnu/./libgomp/../libstdc++-v3/src/.libs
-lstdc++ -lm -o ./for-15.exe 
ptxas /tmp/ccWklsQO.o, line 124; error   : Arguments mismatch for instruction
'mov'
ptxas /tmp/ccWklsQO.o, line 209; fatal   : Parsing error near '0xff': syntax
error
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error:
/home/vries/openacc/trunk/install/offload-nvptx-none/bin//x86_64-pc-linux-gnu-accel-nvptx-none-gcc
returned 1 exit status
compilation terminated.
lto-wrapper: fatal error:
/home/vries/openacc/trunk/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/9.0.0//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld.bfd.real: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

The ptxas error is due to the $LLSDA0 in a mov insn, and the .byte:
...
mov.u64 %r53, %ar0; 
mov.u64 %r84, __gxx_personality_v0; 
st.u64  [%frame+48], %r84;  
mov.u64 %r85, $LLSDA0;  
st.u64  [%frame+56], %r85;  
...

$LLSDA0:
.byte   0xff
.byte   0xff
.byte   0x3
.byte   0
...

[Bug gcov-profile/85276] [GCOV] A comparative statement with '=', '&&' , '||', and '==' operators is wrongly marked as executed twice in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
Confirmed, low priority.

[Bug gcov-profile/85217] [GCOV] A no side effect statement between a break statement and a continue statement will lead to incorrect code coverage in gcov

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I've got patch candidate for that.

[Bug gcov-profile/85201] [GCOV] A statement with two && operators and a comma operator in the for loop body is wrongly marked in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #4 from Martin Liška  ---
Confirmed, but low priority.

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So a nvptx backend bug?
Does ptxas require only decimal constants and not hexadecimal, or require
64-bit load from something that needs to be initialized with 64-bit initializer
rather than series of bytes, something else?

[Bug gcov-profile/85336] [GCOV] wrong coverage for builtin functions and "||" logic operators in return statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
Confirmed, it's created wrongly by gimplfication. Low priority thought.

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
LLSDA labels are for EH support, this testcase doesn't really use exceptions in
any way, but it isn't compiled with -fno-exceptions; but that is the case of
most of the C++ tests in libgomp (I see only 6 OpenACC tests with it), isn't
it?

[Bug c++/86672] New: Facing issue with gcc-4.9.0 while using with llvm-6.0.1

[abinaya.manikandan at wipro dot com]

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

Bug ID: 86672
   Summary: Facing issue with gcc-4.9.0 while using with
llvm-6.0.1
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abinaya.manikandan at wipro dot com
  Target Milestone: ---

Hi,

We are trying to build llvm-6.0.1 with gcc version 4.9.0.
Please find our machine and installed component details below:

**
[root@abinaya-llvm6 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.9 (Santiago)

[root@abinaya-llvm6 ~]# gcc --version
gcc (GCC) 4.9.0
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
**

Please find below command which we are trying to install llvm with gcc:


cmake -DCMAKE_INSTALL_PREFIX=%{_prefix} -DCMAKE_BUILD_WITH_INSTALL_RPATH=1 \
-DCMAKE_INSTALL_RPATH=$ORIGIN/../lib:%{gccpath}/lib64\
-DCMAKE_CROSSCOMPILING=True -DCMAKE_BUILD_TYPE=Release  \
-Wno-dev  --enable-zlib -DCMAKE_BUILD_TYPE=Release \
--enable-gold --enable-plugins \
-DLLVM_ENABLE_ZLIB:BOOL=ON ..

make

make install 

Only the cmake step getting success.
When we are trying to run "make" facing below issue:

***
In file included from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/utility:198:0,
 from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/algorithm:642,
 from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/src/algorithm.cpp:10:
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/__tuple: In
substitution of 'template using __all =
std::__1::is_same,
std::__1::__all_dummy<(void(_Pred), true)...> > [with bool ..._Pred =
{{true}...}]':
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/__tuple:401:84:  
required from here
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/__tuple:395:82:
internal compiler error: unexpected expression '(void({true}), true)...' of
kind expr_pack_expansion
 using __all = is_same<__all_dummy<_Pred...>, __all_dummy<((void)_Pred,
true)...>>;
   
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: ***
[projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/algorithm.cpp.o] Error 1
In file included from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/utility:198:0,
 from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/algorithm:642,
 from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/__bit_reference:15,
 from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/vector:266,
 from
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxxabi/src/cxa_demangle.cpp:20:
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/__tuple: In
substitution of 'template using __all =
std::__1::is_same,
std::__1::__all_dummy<(void(_Pred), true)...> > [with bool ..._Pred =
{{true}...}]':
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/__tuple:401:84:  
required from here
/root/rpmbuild/BUILD/llvm-6.0.0.src/projects/libcxx/include/__tuple:395:82:
internal compiler error: unexpected expression '(void({true}), true)...' of
kind expr_pack_expansion
 using __all = is_same<__all_dummy<_Pred...>, __all_dummy<((void)_Pred,
true)...>>;
   
  ^
***

Can anyone help me to fix this issue.

Regards,
Abinaya

[Bug ada/86659] [9 regression] gnat.dg/sso/q[23].adb FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
A reghunt now identified this patch as the culprit:

2018-07-24  Richard Biener  

* match.pd: Add BIT_FIELD_REF canonicalizations.

Comparing the assembler output, I find

--- /var/gcc/reghunt/pr86659/47386/gcc/testsuite/gnat/q2.s  2018-07-25
13:27:50.135854630 +
+++ q2.s2018-07-25 13:28:06.147647885 +
@@ -309,10 +309,7 @@
call__gnat_rcheck_PE_Explicit_Raise, 0
 nop
 .LL2:
-   ldx [%fp+2039], %o0
-   call__bswapdi2, 0
-nop
-   mov %o0, %g1
+   ldx [%fp+2039], %g1
and %g1, 3, %g1
cmp %g1, 2
be  %xcc, .LL3

[Bug c++/86672] Facing issue with gcc-4.9.0 while using with llvm-6.0.1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Richard Biener  ---
GCC 4.9 is no longer supported, you have to try GCC 6 or newer or find a
workaround yourself.

[Bug lto/86654] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24933

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Wed Jul 25 12:10:13 2018
New Revision: 262965

URL: https://gcc.gnu.org/viewcvs?rev=262965&root=gcc&view=rev
Log:
2018-07-25  Richard Biener  

PR debug/86654
* dwarf2out.c (dwarf2out_decl): Do not handle nested functions
special wrt context_die late.
(gen_subprogram_die): Re-use DIEs in local scope.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug target/86673] New: inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

Bug ID: 86673
   Summary: inline asm sometimes ignores 'register asm("reg")'
declarations
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 44438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44438&action=edit
linux/net/core/scm.o, preprocessed

Building older linux kernels for ARM with a gcc-8.1 compiler has triggered a
check for broken compiler versions, which compares the register number that is
used in an inline assembly statement with the expected value, for an argument
that was declared with the 'register foo asm ("reg")' syntax described in the
gcc manual under "Specifying Registers for Local Variables".

The diagnostic from the assembler is

$ arm-linux-gnueabi-gcc -Wall -O2 scm.i -c -Wno-pointer-sign
-fno-strict-aliasing
/tmp/ccCGMQmS.s:648: Error: .err encountered
/tmp/ccCGMQmS.s:679: Error: .err encountered

Unfortunately, a change made to the kernel a few years ago had made this go
unnoticed as everyone was testing gcc-8.1 only on more recent kernels that did
not run into the particular check, but may have run into the bug without
triggering the check. Architectures other than arm may also be affected, but
nothing else has this check.

I tested gcc-8.1.0 and today's gcc-8.1.1 (r262956), both with the same result.
I attached one of the files that showed the problem, and reduced this using
creduce to:

int a, c, d, e;
long b;
void fn1() {
  int f = ({
({
  long g = b, j = g;
  register const typeof(c) h asm("r2") = 1, i = d;
  __asm__(".ifnc %2,r2; .err; .endif\n\t"
"bl __put_user_4"
  : "=&r"(e)
  : ""(i), ""(h), ""(j));
  e;
});
  });
  a = f;
}

[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument

[jwjagersma at gmail dot com]

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

--- Comment #4 from jwjagersma at gmail dot com ---
Created attachment 44439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44439&action=edit
Proposed patch

I cloned the fix that was applied to cygwin/mingw targets in SVN r259347. There
didn't seem to be any way to identify COFF targets for use in dwarf2out.c, so I
defined a new macro TARGET_COFF. I hope this is the right way to do it.

This patch works for me, please review and merge if possible.

[Bug lto/86654] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24933

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
(In reply to Martin Liška from comment #13)
> Just for record, building Firefox w/ GCC 8.1 w/o LTO produces:
> 
>  VM SIZE   FILE SIZE
>  -- --
>0.0%   0 .debug_info   978Mi  48.5%
>0.0%   0 .debug_loc460Mi  22.8%
>0.0%   0 .debug_str158Mi   7.9%
>0.0%   0 .debug_ranges 132Mi   6.6%
>0.0%   0 .debug_line   111Mi   5.5%
>   67.7%  74.9Mi .text74.9Mi   3.7%
>0.0%   0 .strtab  37.8Mi   1.9%
>0.0%   0 .symtab  14.1Mi   0.7%
>0.0%   0 .debug_abbrev11.4Mi   0.6%
>7.9%  8.75Mi .eh_frame8.75Mi   0.4%
>7.7%  8.47Mi .rela.dyn8.47Mi   0.4%
>7.7%  8.47Mi .rodata  8.47Mi   0.4%
>3.8%  4.20Mi .data.rel.ro 4.20Mi   0.2%
>1.9%  2.05Mi .eh_frame_hdr2.05Mi   0.1%
>1.5%  1.65Mi .dynstr  1.65Mi   0.1%
>0.9%  1.04Mi [Other]  1.33Mi   0.1%
>0.0%   0 .debug_aranges   1.29Mi   0.1%
>0.6%   650Ki .bss  0   0.0%
>0.4%   413Ki .dynsym   413Ki   0.0%
>0.0%   0 .debug_pubtypes   349Ki   0.0%
>0.0%  15 [None]0   0.0%
>  100.0%   110Mi TOTAL1.97Gi 100.0%

When running dwz on that:

bloaty libxul.so
 VM SIZE  FILE SIZE
 ----
   0.0%   0 .debug_info  629Mi  37.8%
   0.0%   0 .debug_loc   460Mi  27.6%
   0.0%   0 .debug_str   158Mi   9.5%
   0.0%   0 .debug_ranges132Mi   8.0%
   0.0%   0 .debug_line  111Mi   6.7%
  67.7%  74.9Mi .text   74.9Mi   4.5%
   0.0%   0 .strtab 37.8Mi   2.3%
   0.0%   0 .symtab 14.1Mi   0.8%
   0.0%   0 .debug_abbrev   10.3Mi   0.6%
   7.9%  8.75Mi .eh_frame   8.75Mi   0.5%
   7.7%  8.47Mi .rela.dyn   8.47Mi   0.5%
   7.7%  8.47Mi .rodata 8.47Mi   0.5%
   3.8%  4.20Mi .data.rel.ro4.20Mi   0.3%
   1.9%  2.05Mi .eh_frame_hdr   2.05Mi   0.1%
   1.5%  1.65Mi .dynstr 1.65Mi   0.1%
   0.0%   0 .debug_aranges  1.29Mi   0.1%
   0.7%   805Ki [Other]  815Ki   0.0%
   0.6%   650Ki .bss 0   0.0%
   0.4%   413Ki .dynsym  413Ki   0.0%
   0.2%   255Ki .rela.plt255Ki   0.0%
   0.0%  15 [None]   0   0.0%
 100.0%   110Mi TOTAL   1.63Gi 100.0%

I'll test LTO build as well.

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #6)
> LLSDA labels are for EH support, this testcase doesn't really use exceptions
> in any way, but it isn't compiled with -fno-exceptions; but that is the case
> of most of the C++ tests in libgomp (I see only 6 OpenACC tests with it),
> isn't it?

The test-case compiles with -fno-exceptions, but fails in execution here:
...
192 check (i >= 75 && i < 1945 && (i - 75) % 3 == 0);
...
We'll have to analyze that.

I think fexceptions is not implemented for nvptx. setjmp/longjmp is not
supported on nvptx, so using that variant is not possible. The other
possibility is using dwarf exceptions, but that is not setup. I think it could
be possible to use that for nvptx, but I expect modifications are needed to
deal with propagating exceptions from offloaded to host code.

[Bug target/86673] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #1 from Arnd Bergmann  ---
Further inspection shows that this happens for the cases where the input
argument to the inline asm is a compile-time constant, but not for those that
are variables.

[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-25
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
(In reply to jwjagersma from comment #4)
> Created attachment 44439 [details]
> Proposed patch
> 
> I cloned the fix that was applied to cygwin/mingw targets in SVN r259347.
> There didn't seem to be any way to identify COFF targets for use in
> dwarf2out.c, so I defined a new macro TARGET_COFF. I hope this is the right
> way to do it.
> 
> This patch works for me, please review and merge if possible.

Thanks, that looks good to me.  Can you post the patch to
gcc-patc...@gcc.gnu.org
please and state how you tested the patch (I suppose bootstrap was OK, etc.)?

I'll take care of integrating the fix then.

[Bug target/86673] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #2 from Arnd Bergmann  ---
Forcing constant inputs for put_user to be read from a volatile variable avoids
this problem and lets me cleanly build all files that showed it.

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 35c9db857ebe..23e92a9a5ef4 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -251,7 +251,8 @@ extern int __put_user_8(void *, unsigned long long);
({  \
unsigned long __limit = current_thread_info()->addr_limit - 1;
\
const typeof(*(p)) __user *__tmp_p = (p);   \
-   register const typeof(*(p)) __r2 asm("r2") = (x);   \
+   const typeof(*(p)) __x = (x);   \
+   register const typeof(*(p)) __r2 asm("r2") = READ_ONCE(__x);   
\
register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \
register unsigned long __l asm("r1") = __limit; \
register int __e asm("r0"); \

This confirms that constant inputs are what leads to the problem.

[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument

[jwjagersma at gmail dot com]

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

--- Comment #6 from jwjagersma at gmail dot com ---
(In reply to Richard Biener from comment #5)

After building a more complex program with the above patch (applied to gcc
8.1.0 release sources), this ICE appears during linking:

lto1.exe: internal compiler error: in gen_subprogram_die, at dwarf2out.c:22668
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper.exe: fatal error:
D:\msys64\usr\local\cross\bin\i586-pc-msdosdjgpp-g++.exe returned 1 exit status
compilation terminated.
collect2.exe: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

Being entirely unfamiliar with gcc internals, I'm not sure what went wrong
here.

[Bug c/86667] [7/8/9 Regression] can no longer traverse environment table

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
The test works as expected if I replace

  *ep=*ep++;

with

  *ep++;

in the C file.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm-none-linux-gnueabi ,
   ||arm-none-eabi
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-25
 CC||ramana at gcc dot gnu.org
  Known to work||7.2.0
Summary|inline asm sometimes|[8/9 regression] inline asm
   |ignores 'register   |sometimes ignores 'register
   |asm("reg")' declarations|asm("reg")' declarations
 Ever confirmed|0   |1
  Known to fail||8.1.0, 9.0

--- Comment #3 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab  ---
Why are you using empty constraints when a register is required?

[Bug c/86667] [7/8/9 Regression] can no longer traverse environment table

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #6 from Andreas Schwab  ---
*ep=*ep++ is undefined.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
(In reply to Andreas Schwab from comment #4)
> Why are you using empty constraints when a register is required?

creduce did that, it had no effect on the result. The original source looks
like:

#define __get_user_x_64t(__r2, __p, __e, __l, __s)  \
   __asm__ __volatile__ (   \
__asmeq("%0", "r0") __asmeq("%1", "r2") \
__asmeq("%3", "r1") \
"bl __get_user_64t_" #__s   \
: "=&r" (__e), "=r" (__r2)  \
: "0" (__p), "r" (__l)  \
: __GUP_CLOBBER_##__s)

[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 25 Jul 2018, jwjagersma at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651
> 
> --- Comment #6 from jwjagersma at gmail dot com ---
> (In reply to Richard Biener from comment #5)
> 
> After building a more complex program with the above patch (applied to gcc
> 8.1.0 release sources), this ICE appears during linking:
> 
> lto1.exe: internal compiler error: in gen_subprogram_die, at dwarf2out.c:22668
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper.exe: fatal error:
> D:\msys64\usr\local\cross\bin\i586-pc-msdosdjgpp-g++.exe returned 1 exit 
> status
> compilation terminated.
> collect2.exe: fatal error: lto-wrapper returned 1 exit status
> compilation terminated.
> 
> Being entirely unfamiliar with gcc internals, I'm not sure what went wrong
> here.

There are latent bugs that now affect darwin, mingw and djgpp (after your
patch) by default when compiling with -g0 and linking with -g
(which is basically what those patches enforce).

Some of them have been fixed on the GCC 8 branch already so I suggest
you use the GCC 8.2 release candidate tarball to see if it works there.
(ftp://gcc.gnu.org/pub/gcc/snapshots/8.2.0-RC-20180719/)

[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-07-25
 Ever confirmed|0   |1

--- Comment #6 from Dominique d'Humieres  ---
This looks like a target issue. Have you ever build gcc on HP-UX 11.31/PA?

[Bug c++/86672] Facing issue with gcc-4.9.0 while using with llvm-6.0.1

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
What possible reason could you have to use gcc-4.9.0 instead of gcc-4.9.4?

Anyway this seems to be a duplicate of PR 66426 which is fixed in gcc-5

[Bug fortran/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #7 from The Written Word  
---
(In reply to Dominique d'Humieres from comment #6)
> This looks like a target issue. Have you ever build gcc on HP-UX 11.31/PA?

Definitely a target issue. With some patches I can build gcc 4.x on 11.31/PA. I
am building 8.1.0 now with a fixinc patch to address the issue I am raising in
this PR. I don't know how to quickly test a fixinc patch without doing a full
rebuild so it's taking awhile. Should know by the end of the day.

[Bug pch/86674] New: -W(no)-error=invalid-pch does not affect incorrect language warning

[jwyatt at feralinteractive dot com]

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

Bug ID: 86674
   Summary: -W(no)-error=invalid-pch does not affect incorrect
language warning
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwyatt at feralinteractive dot com
  Target Milestone: ---

-Werror=invalid-pch does not turn warnings caused by -Winvalid-pch into errors.
-Wno-error=invalid-pch does not turn errors caused by -Winvalid-pch -Werror
into warnings.

Context:
When compiling the same prefix for multiple languages,
https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html suggests that they
can all co-exist in the same folder, since the compiler will search them all
and choose the correct one. However this will cause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17162.

As a result, in cases where -Werror is enabled, it would be useful to turn
-Winvalid-pch back into a warning.

Example - the contents of the files are irrelevant, just use empty files if
need be:
gcc -Wall -Wextra -x c-header Prefix.h -o Prefix.h.gch/c.h
gcc -Wall -Wextra -x c++-header Prefix.h -o Prefix.h.gch/c++.h
gcc -Wall -Wextra -Winvalid-pch -Werror -Wno-error=invalid-pch -include
Prefix.h -c Test.c
gcc -Wall -Wextra -Winvalid-pch -Werror -Wno-error=invalid-pch -include
Prefix.h -c Test.cpp

This produces only the following output:
cc1plus: error: ./Prefix.h.gch/c.h: not for GNU C++14 [-Werror]
cc1plus: all warnings being treated as errors

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
The following simpler testcase also shows the problem:

void fn1() {
  register const int h asm("r2") = 1;
  __asm__(".ifnc %0,r2; .err; .endif\n\t"
  "bl   __put_user_4" :: "r"(h));
}

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[thopre01 at gcc dot gnu.org]

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

--- Comment #7 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #6)
> The following simpler testcase also shows the problem:
> 
> void fn1() {
>   register const int h asm("r2") = 1;
>   __asm__(".ifnc %0,r2; .err; .endif\n\t"
>   "bl   __put_user_4" :: "r"(h));
> }

The register label gets optimized during gimple stages.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[thopre01 at gcc dot gnu.org]

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

--- Comment #8 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #7)
> (In reply to Thomas Preud'homme from comment #6)
> > The following simpler testcase also shows the problem:
> > 
> > void fn1() {
> >   register const int h asm("r2") = 1;
> >   __asm__(".ifnc %0,r2; .err; .endif\n\t"
> >   "bl   __put_user_4" :: "r"(h));
> > }
> 
> The register label gets optimized during gimple stages.

Dump for original already shows propagation of the constant has happened which
later lead to the removal of the register declaration:

;; Function fn1 (null)
;; enabled by -tree-original


{
  register const int h __asm__ (*r2) = 1;

register const int h __asm__ (*r2) = 1;
  __asm__ __volatile__(".ifnc %0,r2; .err; .endif\n\tbl\t__put_user_4"::"r" 1);
}

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
Reproduced on arm64 and x86 as well, see x86 version:

void fn1() {
   register const int h asm("edx") = 1;
__asm__(".ifnc %0,edx; .err; .endif" :: "r"(h));
}

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #10 from Alexander Monakov  ---
See PR 85745 where Jakub said,

The reason this happens is that the register variable is marked const.  Don't
do that.  If it is const, the compiler optimizes it more aggressively - it will
happily fold uses of the variable to the constant ininitializer, so the inline
asm becomes "r" (110) instead of "r" (__r2) and thus it can use any register.
This is how C++ behaved for years and how C in GCC behaves since the folding
improvements.

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
(In reply to Tom de Vries from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > LLSDA labels are for EH support, this testcase doesn't really use exceptions
> > in any way, but it isn't compiled with -fno-exceptions; but that is the case
> > of most of the C++ tests in libgomp (I see only 6 OpenACC tests with it),
> > isn't it?
> 
> The test-case compiles with -fno-exceptions, but fails in execution here:
> ...
> 192 check (i >= 75 && i < 1945 && (i - 75) % 3 == 0);
> ...
> We'll have to analyze that.
> 

Hmm, for me that minimizes to:
...
extern "C" void abort ();

#pragma omp declare target
int results[2000];
#pragma omp end declare target

int
main ()
{
#pragma omp target teams map (always, tofrom: results)
  {
results[75] = 1;
  }
  if (results[75] == 0)
abort ();
}
...

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[cesar at gcc dot gnu.org]

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

--- Comment #9 from cesar at gcc dot gnu.org ---
(In reply to Tom de Vries from comment #8)

> Hmm, for me that minimizes to:
> ...
> extern "C" void abort ();
> 
> #pragma omp declare target
> int results[2000];
> #pragma omp end declare target
> 
> int
> main ()
> {
> #pragma omp target teams map (always, tofrom: results)
>   {
> results[75] = 1;
>   }
>   if (results[75] == 0)
> abort ();
> }
> ...

If omp declare target behaves like acc declare, wouldn't you still need to
update the host's copy of results? I'd expect results[75] to be zero outside of
the omp target region.

[Bug debug/86675] New: C++ lambdas are not debugable with -std=c++17 (or above) and -Og

[bernd.amend at outlook dot com]

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

Bug ID: 86675
   Summary: C++ lambdas are not debugable with -std=c++17 (or
above) and -Og
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.amend at outlook dot com
  Target Milestone: ---

Created attachment 0
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=0&action=edit
Example program

If I compile the attached (main.cpp) test program
  int main() {
return [] {
return 31415;
}();
  }

with the following options I'm unable to debug it
  g++ main.cpp -std=c++17 -g -Og
  g++ main.cpp -std=c++2a -g -Og

using the following compile options debugging works as expected
  g++ main.cpp -std=c++17 -g -O0
  g++ main.cpp -std=c++2a -g -O0
  g++ main.cpp -std=c++11 -g -Og
  g++ main.cpp -std=c++14 -g -Og
  g++ main.cpp -std=c++14 -g -Og

The attached script test.sh reports the following
Success: Standard c++11 Optimization 0
Success: Standard c++14 Optimization 0
Success: Standard c++17 Optimization 0
Success: Standard c++2a Optimization 0
Success: Standard c++11 Optimization g
Success: Standard c++14 Optimization g
Failed: Standard c++17 Optimization g
Failed: Standard c++2a Optimization g

Systems used: Archlinux (last updated 2018-07-25)
g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.1 20180531 (GCC)

[Bug debug/86675] C++ lambdas are not debugable with -std=c++17 (or above) and -Og

[bernd.amend at outlook dot com]

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

--- Comment #1 from Bernd Amend  ---
Created attachment 1
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=edit
Script to test the compiler with different command line args

[Bug testsuite/86660] libgomp.c++/for-15.C ICEs with nvptx offloading

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Indeed, lowering ignores map clauses for declare target to global vars, but it
can do that only if always is not present.  Will have a look.

[Bug c/86670] unsized static array var is removed but still accessed.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 19315.

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

[Bug c/19315] document undocumented extension that allows code where variable is not emitted in the asm

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
*** Bug 86670 has been marked as a duplicate of this bug. ***

[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument

[jwjagersma at gmail dot com]

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

--- Comment #8 from jwjagersma at gmail dot com ---
(In reply to rguent...@suse.de from comment #7)
> There are latent bugs that now affect darwin, mingw and djgpp (after your
> patch) by default when compiling with -g0 and linking with -g
> (which is basically what those patches enforce).
> 
> Some of them have been fixed on the GCC 8 branch already so I suggest
> you use the GCC 8.2 release candidate tarball to see if it works there.
> (ftp://gcc.gnu.org/pub/gcc/snapshots/8.2.0-RC-20180719/)

I successfully built the snapshot you linked with this patch applied, but
compiling my c++ program still generated the same ICE.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #11 from Arnd Bergmann  ---
I have checked all instances of 'register const' or 'const register' in the
current linux kernel (4.18-rc), and we never assign a constant expression to
any of them, so I guess none of them are affected:

arch/arm/include/asm/uaccess.h: register const void __user *__p
asm("r0") = __ptr;  \
arch/h8300/kernel/sim-console.c:register const char *_ptr
__asm__("er1") = s;
arch/h8300/kernel/sim-console.c:register const unsigned _len
__asm__("er2") = n;
arch/mips/include/asm/uaccess.h:register const void __user *__cu_from_r
__asm__("$5");  \
arch/mips/include/asm/uaccess.h:register const void *__cu_from_r
__asm__("$5"); \
arch/riscv/kernel/process.c:const register unsigned long gp __asm__
("gp");
arch/riscv/kernel/stacktrace.c: const register unsigned long current_sp
__asm__ ("sp");
arch/riscv/kernel/stacktrace.c: const register unsigned long current_sp
__asm__ ("sp");

Should we drop the 'const' for all of them as a rule? If there is no use case
for ever using a 'const register' variable and it can lead to bugs, should gcc
warn about it in the future?

Should this issue be mentioned in the documentation in
https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html?

I also checked all instances in linux-4.4, and the ARM put_user() helper is the
only one I see that gets a constant expression input, so I suppose that is all
that needs to be fixed in backports, unless someone thinks we should get rid of
all them in backports as well.

[Bug c/19315] document undocumented extension that allows code where variable is not emitted in the asm

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---

IMHO (as you say in c#3) this is "surprising behaviour" 
 * if there's any case you'd want it - then maybe you should have to ask for
it.
   (so if it's intentional it should be behind some flag?)
 * it ought to warn by default (not require '-pedantic').
 * as Richi commented in 86670, it means grokdeclarator has conflicting storage
classes which doesn't seem like a useful idea for maintenance.

 I guess the point is "what do we want the behaviour to be?".

 Documenting it doesn't seem to really make it less surprising (if it's an
'extension' then one ought to be able to identify a sensible use-case and put
it in the test-suite).

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[sch...@linux-m68k.org]

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

--- Comment #12 from Andreas Schwab  ---
arch/h8300/kernel/sim-console.c:register const int fd __asm__("er0") =
1; /* stdout */

[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On July 25, 2018 5:21:38 PM GMT+02:00, jwjagersma at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651
>
>--- Comment #8 from jwjagersma at gmail dot com ---
>(In reply to rguent...@suse.de from comment #7)
>> There are latent bugs that now affect darwin, mingw and djgpp (after
>your
>> patch) by default when compiling with -g0 and linking with -g
>> (which is basically what those patches enforce).
>> 
>> Some of them have been fixed on the GCC 8 branch already so I suggest
>> you use the GCC 8.2 release candidate tarball to see if it works
>there.
>> (ftp://gcc.gnu.org/pub/gcc/snapshots/8.2.0-RC-20180719/)
>
>I successfully built the snapshot you linked with this patch applied,
>but
>compiling my c++ program still generated the same ICE.

Thanks for checking. Do you maybe can make preprocessed source of required CUs
available? You can reduce the set of needed inputs by using -shared at link
time so unresolved symbols are considered OK.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #13 from Arnd Bergmann  ---
(In reply to Andreas Schwab from comment #12)
> arch/h8300/kernel/sim-console.c:  register const int fd __asm__("er0") = 
> 1;

I found that too, and then noticed it is already fixed in linux-next:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=14cf9451be78f8a

Ard points out that most of the other ones are pointers to const data, which
are not a problem. This leaves the arm put_user bug as the only definite
problem that needs to be addressed in older kernels.

The three arch/riscv instances of 'const register unsigned long gp __asm__
("gp")' are different because they are never passed into an inline assembly as
far as I can tell. This seems to be unsupported for local register variables
according to the gcc documentation, but if that's a problem, it's unrelated to
this bug.