[Bug c++/86678] New: constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function

[eric at efcs dot ca]

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

Bug ID: 86678
   Summary: constexpr evaluation incorrectly diagnoses unevaluated
call to non-constexpr function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Reproducer:

#include 

template 
constexpr int foo() {
if (sizeof(T))
return 1;
assert(false && "BOOM!");
}

constexpr int V = foo();

[Bug target/86677] New: popcount builtin detection is breaking some kernel build

[kugan at gcc dot gnu.org]

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

Bug ID: 86677
   Summary: popcount builtin detection is breaking some kernel
build
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

Linux kernel build for arm/aarch64 (and possibly other targets) which does not
provide appropriate patterns in the backend will break the kernel build. 

As for aarch64 this happens because kernel is built with -mgeneral-regs-only

Also discussed in:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00489.html

Is branding your concern?

[Melvin]

Is branding your concern?

















Most companies are thinking which way is the most effective yet affordable way 
to reach customers or clients? Having difficulty to reach the person that make 
it happen?


We are the solution! Big data is the future to connect your business to you 
target customers without spending tons of advertisements.



Why Big Data :
•   Cost effective
•   Prospecting
•   Higher  ROI
•   Branding
•   Customer engagement
•   Boost Sales


For more information feel free to call at 54029552 or email at 
mel...@netel-marketing.com





   





  

  
  
  
  

  
  
  
  
Should you wish not to receive any promotional 
email in the future, please click UNSUBSCRIBE.
如閣下不欲收到本公司的宣傳郵件，請按不訂閱。
  

Submitting Your Manuscripts _ Dear bug-gcc _ 3206753

[Journal JEEE]

Dear Author/Researcher,
For the purpose of supplying a better platform for you authors to publish
papers, we sincerely invite scholars and researchers to submit papers to
the journals or to join in the editorial board/reviewer team.
  To Become One of the Editorial Board Members or Reviewers
To make editorial board and reviewer group expanded, we would like to
invite you to be our editorial member or reviewer of our journals with
great sincerity. If you want to know more information about the Benefits
and Responsibilities of the editorial member or reviewer, please feel free
to visit the following link:
http://www.jgynobst.org/journals
  Invite You to Submit Research Papers to the Journal
If you have burst out some new research works in your specialized or
interested field, welcome to submit your papers to the corresponding
Journals or Special Issues so as to share your ideas with people around the
world.
Recommended Some Featured Journals

   1. American Journal of Modern Physics
   2. Psychology and Behavioral Sciences
   3. American Journal of Applied Scientific Research
   4. Journal of Plant Sciences
   5. American Journal of Sports Science
   6. Hydrology
   7. International Journal of Information and Communication Sciences
   8. International Journal of Economy, Energy and Environment

Please don't hesitate to contact us if there is any question.
Warm regards,
Jessie Wright

[Bug libstdc++/86676] 20_util/monotonic_buffer_resource/release.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed Jul 25 23:38:17 2018
New Revision: 262984

URL: https://gcc.gnu.org/viewcvs?rev=262984=gcc=rev
Log:
PR libstdc++/86676 another alignment fix for test

PR libstdc++/86676
* testsuite/20_util/monotonic_buffer_resource/release.cc: Request
same alignment for post-release allocation.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/20_util/monotonic_buffer_resource/release.cc

[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #15 from The Written Word  
---
Created attachment 3
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3=edit
gcc/config/rs6000/aix53.h patch

Similar to r227907 but for AIX 5.3 Have used this to successfully build
gcc-8.1.0 on AIX 5.3.

[Bug libstdc++/86676] 20_util/monotonic_buffer_resource/release.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
This should be fixed now, please reopen if not.

[Bug libstdc++/86676] 20_util/monotonic_buffer_resource/release.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Jul 25 20:23:07 2018
New Revision: 262980

URL: https://gcc.gnu.org/viewcvs?rev=262980=gcc=rev
Log:
PR libstdc++/86676 Do not assume stack buffer is aligned

PR libstdc++/86676
* testsuite/20_util/monotonic_buffer_resource/release.cc: Allow for
buffer being misaligned and so returned pointer not being at start.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/20_util/monotonic_buffer_resource/release.cc

[Bug libstdc++/86676] 20_util/monotonic_buffer_resource/release.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Oops, the test depends on stack alignment of a char buffer. Patch incoming.

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #45 from Nicolas Koenig  ---
Author: koenigni
Date: Wed Jul 25 19:34:33 2018
New Revision: 262979

URL: https://gcc.gnu.org/viewcvs?rev=262979=gcc=rev
Log:
2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* testsuite/libgomp.fortran/async_io_1.f90: Really commit.
* testsuite/libgomp.fortran/async_io_2.f90: Really commit.
* testsuite/libgomp.fortran/async_io_3.f90: Really commit.
* testsuite/libgomp.fortran/async_io_4.f90: Really commit.
* testsuite/libgomp.fortran/async_io_5.f90: Really commit.
* testsuite/libgomp.fortran/async_io_6.f90: Really commit.
* testsuite/libgomp.fortran/async_io_7.f90: Really commit.


Added:
trunk/libgomp/testsuite/libgomp.fortran/async_io_1.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_2.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_3.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_4.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_5.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_6.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_7.f90

[Bug libstdc++/86676] 20_util/monotonic_buffer_resource/release.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The AIX failures are different and should be fixed at r262977

[Bug libstdc++/86676] 20_util/monotonic_buffer_resource/release.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug fortran/25829] [F03] Asynchronous IO support

[dominiq at lps dot ens.fr]

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

--- Comment #44 from Dominique d'Humieres  ---
AFAICT this

2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* testsuite/libgomp.fortran/async_io_1.f90: New test.
* testsuite/libgomp.fortran/async_io_2.f90: New test.
* testsuite/libgomp.fortran/async_io_3.f90: New test.
* testsuite/libgomp.fortran/async_io_4.f90: New test.
* testsuite/libgomp.fortran/async_io_5.f90: New test.
* testsuite/libgomp.fortran/async_io_6.f90: New test.
* testsuite/libgomp.fortran/async_io_7.f90: New test.

has not been committed yet.

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #43 from Nicolas Koenig  ---
Author: koenigni
Date: Wed Jul 25 18:48:39 2018
New Revision: 262978

URL: https://gcc.gnu.org/viewcvs?rev=262978=gcc=rev
Log:
2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* gfortran.texi: Add description of asynchronous I/O.
* trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables
as volatile.
* trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to
st_wait_async and change argument spec from ".X" to ".w".
(gfc_trans_wait): Pass ID argument via reference.

2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* gfortran.dg/f2003_inquire_1.f03: Add write statement.
* gfortran.dg/f2003_io_1.f03: Add wait statement.

2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* Makefile.am: Add async.c to gfor_io_src.
Add async.h to gfor_io_headers.
* Makefile.in: Regenerated.
* gfortran.map: Add _gfortran_st_wait_async.
* io/async.c: New file.
* io/async.h: New file.
* io/close.c: Include async.h.
(st_close): Call async_wait for an asynchronous unit.
* io/file_pos.c (st_backspace): Likewise.
(st_endfile): Likewise.
(st_rewind): Likewise.
(st_flush): Likewise.
* io/inquire.c: Add handling for asynchronous PENDING
and ID arguments.
* io/io.h (st_parameter_dt): Add async bit.
(st_parameter_wait): Correct.
(gfc_unit): Add au pointer.
(st_wait_async): Add prototype.
(transfer_array_inner): Likewise.
(st_write_done_worker): Likewise.
* io/open.c: Include async.h.
(new_unit): Initialize asynchronous unit.
* io/transfer.c (async_opt): New struct.
(wrap_scalar_transfer): New function.
(transfer_integer): Call wrap_scalar_transfer to do the work.
(transfer_real): Likewise.
(transfer_real_write): Likewise.
(transfer_character): Likewise.
(transfer_character_wide): Likewise.
(transfer_complex): Likewise.
(transfer_array_inner): New function.
(transfer_array): Call transfer_array_inner.
(transfer_derived): Call wrap_scalar_transfer.
(data_transfer_init): Check for asynchronous I/O.
Perform a wait operation on any pending asynchronous I/O
if the data transfer is synchronous. Copy PDT and enqueue
thread for data transfer.
(st_read_done_worker): New function.
(st_read_done): Enqueue transfer or call st_read_done_worker.
(st_write_done_worker): New function.
(st_write_done): Enqueue transfer or call st_read_done_worker.
(st_wait): Document as no-op for compatibility reasons.
(st_wait_async): New function.
* io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK;
add NOTE where necessary.
(get_gfc_unit): Likewise.
(init_units): Likewise.
(close_unit_1): Likewise. Call async_close if asynchronous.
(close_unit): Use macros LOCK and UNLOCK.
(finish_last_advance_record): Likewise.
(newunit_alloc): Likewise.
* io/unix.c (find_file): Likewise.
(flush_all_units_1): Likewise.
(flush_all_units): Likewise.
* libgfortran.h (generate_error_common): Add prototype.
* runtime/error.c: Include io.h and async.h.
(generate_error_common): New function.

2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* testsuite/libgomp.fortran/async_io_1.f90: New test.
* testsuite/libgomp.fortran/async_io_2.f90: New test.
* testsuite/libgomp.fortran/async_io_3.f90: New test.
* testsuite/libgomp.fortran/async_io_4.f90: New test.
* testsuite/libgomp.fortran/async_io_5.f90: New test.
* testsuite/libgomp.fortran/async_io_6.f90: New test.
* testsuite/libgomp.fortran/async_io_7.f90: New test.


Added:
trunk/libgfortran/io/async.c
trunk/libgfortran/io/async.h
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03
trunk/gcc/testsuite/gfortran.dg/f2003_io_1.f03
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/gfortran.map
trunk/libgfortran/io/close.c
trunk/libgfortran/io/file_pos.c
trunk/libgfortran/io/inquire.c
trunk/libgfortran/io/io.h
trunk/libgfortran/io/open.c
trunk/libgfortran/io/read.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c
trunk/libgfortran/io/unix.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c
trunk/libgomp/ChangeLog

[Bug libstdc++/86676] 20_util/monotonic_buffer_resource/release.cc FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug libstdc++/86676] New: 20_util/monotonic_buffer_resource/release.cc FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 86676
   Summary: 20_util/monotonic_buffer_resource/release.cc FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11, powerpc-ibm-aix7.2.0.0

The new 20_util/monotonic_buffer_resource/release.cc tests FAILs on 32-bit
(only)
Solaris/SPARC and AiX 7.2 (according to gcc-testresults):

FAIL: 20_util/monotonic_buffer_resource/release.cc execution test

/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/20_util/monotonic_buffer_resource/release.cc:118:
void test04(): Assertion 'p == buffer' failed.

Strangely, the test PASSes when run under gdb.

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

[amrosalem820 at gmail dot com]

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

--- Comment #5 from amr  ---
I know all these rules , I mean he said the prototype in scope ,, he means
inside main or outside in my example

[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 #10 from jwjagersma at gmail dot com ---
Created attachment 2
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=2=edit
preprocessed source to trigger ICE

(In reply to rguent...@suse.de from comment #9)
> 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.

I've attached the entire preprocessed source (djgpp does not support -shared).
Compile/link with:

i586-pc-msdosdjgpp-g++ -std=gnu++17 -fconcepts -masm=intel -flto -g *.i

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #17 from Andrew Pinski  ---
Dup of bug 85745.

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

[Bug c/85745] variable with asm register assignment allocated in wrong reg

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|c

--- Comment #4 from Andrew Pinski  ---
C++ version of this issue is bug 56715.

[Bug c/85745] variable with asm register assignment allocated in wrong reg

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

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

You'rе my viсtim

[b]

Hi, viсtim.
I write yоu beсausе I рut а malwаre оn thе web раgе with pоrn whiсh you have 
visited.
My virus grabbеd аll yоur реrsоnаl info аnd turnеd оn your саmеra which 
captured thе process оf your оnаnism. Just аfter thаt thе soft saved your 
соntаct list.
I will delete thе соmpromising vidеo and info if yоu раy mе 350 EURO in 
bitcoin. This is аddress for рaymеnt : 15YhhpyLFM4rf9WQPKTuzREidxLwpGYJ56

I give you 30 hours after you оpen my mеssagе fоr mаking thе transасtiоn.
Аs soon as yоu reаd the message I'll sеe it right away.
It is nоt neсessаry tо tell me that yоu hаve sеnt money to me. This аddress is 
сonnеctеd to yоu, my system will dеlete evеrything autоmatiсally аftеr trаnsfеr 
соnfirmаtion.
If yоu nееd 48 h just reply оn this letter with +.
Yоu сan visit the pоliсе stаtion but nоbody саn hеlр yоu.
If yоu try to decеive mе , I'll sеe it right awаy !
I dоnt live in your сountry. Sо they сan not trасk my lоcаtion еven for 9 
mоnths.
Goоdbye. Dоnt forget abоut the shаme and to ignоre, Your lifе саn be ruined.

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

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
https://en.cppreference.com/w/c/language/scope

[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

--- Comment #16 from Alexander Monakov  ---
> I don't see what should we warn about.

I think the suggestion was to warn when a register const variable appears in
constraints, because the asm is not then guaranteed to receive that operand in
that register, contrary to user's expectations? So basically warn about this
non-intuitive aspect of local reg vars so the places where the code makes a
wrong assumption can be identified and fixed.

[Bug c++/85515] Bogus suggestions from "GCC's leaky abstractions"

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 25 16:46:34 2018
New Revision: 262975

URL: https://gcc.gnu.org/viewcvs?rev=262975=gcc=rev
Log:
PR c++/85515
* cp-tree.h (enum cp_tree_index): Add
CPTI_FOR_{RANGE,BEGIN,END}{,_}_IDENTIFIER.
(for_range__identifier, for_begin__identifier, for_end__identifier,
for_range_identifier, for_begin_identifier, for_end_identifier):
Define.
* decl.c (initialize_predefined_identifiers): Initialize
for_{range,begin,end}{,_}_identifier.
* parser.c (build_range_temp): Use for_range__identifier instead of
get_identifier ("__for_range").
(cp_convert_range_for): Use for_begin__identifier and
for_end__identifier instead of get_identifier ("__for_begin") and
get_identifier ("__for_end").
* semantics.c (finish_for_stmt): Rename "__for_{range,begin,end} "
local symbols to "__for_{range,begin,end}".

* g++.dg/pr85515-2.C: Add expected dg-error.
* g++.dg/cpp0x/range-for36.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for36.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/pr85515-2.C

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

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On July 25, 2018 5:50:40 PM GMT+02:00, "egallager at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19315
>
>Eric Gallager  changed:
>
>   What|Removed |Added
>
>CC||rguenth at gcc dot gnu.org,
>||schwab at gcc dot gnu.org

Just remove the extension and see where in the testsuite it fails. If it
doesn't, simply remove it.

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

[amrosalem820 at gmail dot com]

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

--- Comment #3 from amr  ---
(In reply to Andreas Schwab from comment #1)
> 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.

what is the meaning of in scope here , sir ,,

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

[amrosalem820 at gmail dot com]

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

--- Comment #2 from amr  ---
(In reply to Andreas Schwab from comment #1)
> 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.

what is the meaning of in scope here , sir ,,

[Bug fortran/86587] Derived-type with attributes BIND(C) and PRIVATE raises an error but standard accepts it

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-25
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.3.1 up to trunk (9.0).

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

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
register const void __user *__p asm("r0") = __ptr;
etc. isn't a problem, here __p isn't const, only *__p is.  The problem is if
the register variable itself is const.
So
arch/h8300/kernel/sim-console.c:register const unsigned _len
__asm__("er2") = n;
If n can be a constant or is const var initialized to constant etc.
The cases where a const register var doesn't have an initializer aren't a
problem either.

I don't see what should we warn about.

[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||jakub at gcc dot gnu.org

--- Comment #14 from Alexander Monakov  ---
Indeed, I agree the documentation should mention that (I can write a patch).
IIRC 'volatile register' also does not behave intuitively (I'll try to double
check).

I'm unsure about a warning, it seems "doing it right" might require changes in
both C and C++ frontends, and issuing a warning only if an asm statement using
the register variable is present?

Adding Jakub to Cc.

[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.

[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

[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 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

[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 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 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 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 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 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=edit
Script to test the compiler with different command line args

[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=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 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 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 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

[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

[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 #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 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 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 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

[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 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 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   \
: "=" (__e), "=r" (__r2)  \
: "0" (__p), "r" (__l)  \
: __GUP_CLOBBER_##__s)

[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

[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 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 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/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 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

[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

--- 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 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 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 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=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 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=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"
  : "="(e)
  : ""(i), ""(h), ""(j));
  e;
});
  });
  a = f;
}

[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=gcc=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 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 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] 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 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 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 #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/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 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 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/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 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/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/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/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/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 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 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 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=edit
gcc9-pr86660.patch

Untested patch.  Does this fix it?

[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 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 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 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

[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 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 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 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/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 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=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 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 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?