[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[iains at gcc dot gnu.org]

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

--- Comment #66 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 28 09:25:43 2018
New Revision: 265568

URL: https://gcc.gnu.org/viewcvs?rev=265568&root=gcc&view=rev
Log:
darwin - fix powerpc-darwin stack alignments

2018-10-28  Iain Sandoe  

PR target/85669
* config/rs6000/darwin.h (STACK_BOUNDARY): New.
(RS6000_STARTING_FRAME_OFFSET): Adjust to preserve 16byte alignment.
(STACK_DYNAMIC_OFFSET): Likewise.


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

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[iains at gcc dot gnu.org]

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

--- Comment #67 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 28 10:02:06 2018
New Revision: 265569

URL: https://gcc.gnu.org/viewcvs?rev=265569&root=gcc&view=rev
Log:
darwin - fix powerpc-darwin stack alignment issue

2018-10-28  Iain Sandoe  

backport from mainline.
2018-10-28  Iain Sandoe  

PR target/85669
* config/rs6000/darwin.h (STACK_BOUNDARY): New.
(RS6000_STARTING_FRAME_OFFSET): Adjust to preserve 16byte alignment.
(STACK_DYNAMIC_OFFSET): Likewise.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/darwin.h

[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)

[john at johnwarburton dot net]

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

John Warburton  changed:

   What|Removed |Added

 CC||john at johnwarburton dot net

--- Comment #5 from John Warburton  ---
Related bug in other software:

https://gitlab.com/mbunkus/mkvtoolnix/issues/2417

(it also affects cross-compilation of the VLC player in addition to the
MKVToolNix suite, above)

[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[tkoenig at gcc dot gnu.org]

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

--- Comment #17 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Oct 28 11:05:05 2018
New Revision: 265570

URL: https://gcc.gnu.org/viewcvs?rev=265570&root=gcc&view=rev
Log:
2017-10-28  Thomas Koenig  

PR fortran/54613
* gfortran.h (gfc_isym_id): Add GFC_ISYM_FINDLOC.
(gfc_check_f): Add f6fl field.
(gfc_simplify_f): Add f6 field.
(gfc_resolve_f): Likewise.
(gfc_type_letter): Add optional logical_equas_int flag.
* check.c (intrinsic_type_check): New function.
(gfc_check_findloc): New function.
* intrinsics.c (gfc_type_letter): If logical_equals_int is
set, act accordingly.
(add_sym_5ml):  Reformat comment.
(add_sym_6fl): New function.
(add_functions): Add findloc.
(check_arglist): Add sixth argument, handle it.
(resolve_intrinsic): Likewise.
(check_specific): Handle findloc.
* intrinsic.h (gfc_check_findloc): Add prototype.
(gfc_simplify_findloc): Likewise.
(gfc_resolve_findloc): Likewise.
(MAX_INTRINSIC_ARGS): Adjust.
* iresolve.c (gfc_resolve_findloc): New function.
* simplify.c (gfc_simplify_minmaxloc): Make static.
(simplify_findloc_to_scalar): New function.
(simplify_findloc_nodim): New function.
(simplify_findloc_to_array): New function.
(gfc_simplify_findloc): New function.
(gfc_conv_intrinsic_findloc): New function.
(gfc_conv_intrinsic_function): Handle GFC_ISYM_FINDLOC.
(gfc_is_intrinsic_libcall): Likewise.

2017-10-28  Thomas Koenig  

PR fortran/54613
* Makefile.am: Add files for findloc.
* Makefile.in: Regenerated.
* libgfortran.h (gfc_array_index_type): Add.
(gfc_array_s1): Add using GFC_UINTEGER_1.
(gfc_array_s4): Likewise.
Replace unnecessary comment.
(HAVE_GFC_UINTEGER_1): Define.
(HAVE_GFC_UINTEGER_4): Define.
* m4/findloc0.m4: New file.
* m4/findloc0s.m4: New file.
* m4/findloc1.m4: New file.
* m4/findloc1s.m4: New file.
* m4/findloc2s.m4: New file.
* m4/ifindloc0.m4: New file.
* m4/ifindloc1.m4: New file.
* m4/ifindloc2.m4: New file.
* m4/iparm.m4: Use unsigned integer for characters.
* generated/findloc0_c16.c: New file.
* generated/findloc0_c4.c: New file.
* generated/findloc0_c8.c: New file.
* generated/findloc0_i1.c: New file.
* generated/findloc0_i16.c: New file.
* generated/findloc0_i2.c: New file.
* generated/findloc0_i4.c: New file.
* generated/findloc0_i8.c: New file.
* generated/findloc0_r16.c: New file.
* generated/findloc0_r4.c: New file.
* generated/findloc0_r8.c: New file.
* generated/findloc0_s1.c: New file.
* generated/findloc0_s4.c: New file.
* generated/findloc1_c16.c: New file.
* generated/findloc1_c4.c: New file.
* generated/findloc1_c8.c: New file.
* generated/findloc1_i1.c: New file.
* generated/findloc1_i16.c: New file.
* generated/findloc1_i2.c: New file.
* generated/findloc1_i4.c: New file.
* generated/findloc1_i8.c: New file.
* generated/findloc1_r16.c: New file.
* generated/findloc1_r4.c: New file.
* generated/findloc1_r8.c: New file.
* generated/findloc1_s1.c: New file.
* generated/findloc1_s4.c: New file.
* generated/findloc2_s1.c: New file.
* generated/findloc2_s4.c: New file.
* generated/maxloc0_16_s1.c: Regenerated.
* generated/maxloc0_16_s4.c: Regenerated.
* generated/maxloc0_4_s1.c: Regenerated.
* generated/maxloc0_4_s4.c: Regenerated.
* generated/maxloc0_8_s1.c: Regenerated.
* generated/maxloc0_8_s4.c: Regenerated.
* generated/maxloc1_16_s1.c: Regenerated.
* generated/maxloc1_16_s4.c: Regenerated.
* generated/maxloc1_4_s1.c: Regenerated.
* generated/maxloc1_4_s4.c: Regenerated.
* generated/maxloc1_8_s1.c: Regenerated.
* generated/maxloc1_8_s4.c: Regenerated.
* generated/maxloc2_16_s1.c: Regenerated.
* generated/maxloc2_16_s4.c: Regenerated.
* generated/maxloc2_4_s1.c: Regenerated.
* generated/maxloc2_4_s4.c: Regenerated.
* generated/maxloc2_8_s1.c: Regenerated.
* generated/maxloc2_8_s4.c: Regenerated.
* generated/maxval0_s1.c: Regenerated.
* generated/maxval0_s4.c: Regenerated.
* generated/maxval1_s1.c: Regenerated.
* generated/maxval1_s4.c: Regenerated.
* generated/minloc0_16_s1.c: Regenerated.
* generated/minloc0_16_s4.c: Regenerated.
* generated/minloc0_4_s1.c: Regenerated.
* generated/minloc0_4_s4.c: Regenerated.
* generated/minloc0_8_s1.c: Regenerated.
* generated/minloc0_8_s4.c: Regener

[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #18 from Thomas Koenig  ---
Implemented, closing.

[Bug fortran/39627] [meta-bug] Fortran 2008 support

[tkoenig at gcc dot gnu.org]

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

Bug 54613 Summary: [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613

   What|Removed |Added

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

[Bug fortran/82065] gfortran rejects redundant use of intrinsic module constant

[c.friedr...@fz-juelich.de]

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

c.friedr...@fz-juelich.de changed:

   What|Removed |Added

 CC||c.friedr...@fz-juelich.de

--- Comment #6 from c.friedr...@fz-juelich.de ---
Slightly different case but probably the same bug:

  subroutine sub(i)
c  if(i==1.or.i==2) call sub1 ! this works
  if(any(i==[1,2])) call sub1 ! this does not
  call sub2 

  contains  

  subroutine sub1   
  use iso_fortran_env   
  real(real64) :: a 
  end subroutine sub1   

  subroutine sub2   
  use iso_fortran_env   
  real(real64) :: b 
  end subroutine sub2

  end

Compilation fails with any optimization level different from -O0:
/tmp/ccZ13RIp.s: Assembler messages:
/tmp/ccZ13RIp.s:23: Error: symbol `__iso_fortran_env_MOD_real64' is already
defined

Slight changes of the code makes the error disappear. For example, not using
the "any" construction in the if command. Or commenting out one of the two
subroutine calls. Or commening out any of the declarations (a or b) in the
subroutines. Or using "real(8)" instead of "real(real64)".

Tested versions: 5.5.0, 7.3.0

[Bug ada/87777] New: Let gnat tools call each other with an explicit target and version

[nicolas.boulenguez at free dot fr]

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

Bug ID: 8
   Summary: Let gnat tools call each other with an explicit target
and version
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.boulenguez at free dot fr
  Target Milestone: ---

Created attachment 44913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44913&action=edit
The patch as applied by Debian.

Many problems have been caused by the fact that tools like gnatmake call other
tools like gcc without an explicit target or version.
The Osint.Program_Name function has been created in order to compute the name
of the right gcc subcommand.
The attached patch improves it for Debian, but as described in the header most
changes may be applied upstream.

[Bug ada/87778] New: Remove -q quiet option from some GNAT bootstrap command lines

[nicolas.boulenguez at free dot fr]

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

Bug ID: 87778
   Summary: Remove -q quiet option from some GNAT bootstrap
command lines
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.boulenguez at free dot fr
  Target Milestone: ---

Created attachment 44914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44914&action=edit
The patch as applied by Debian.

The log can be a page longer if it helps debugging.
The attached patch replaces -q with -v for Debian.
Please at least consider removing -q.

[Bug middle-end/87162] ICE with -fdump-passes -fgnu-tm

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Version|6.2.0   |9.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-10-28
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|[6.2.0] Internal compiler   |ICE with -fdump-passes
   |error: Error reporting  |-fgnu-tm
   |routines re-entered.|
  Known to fail||6.2.0

--- Comment #9 from Manuel López-Ibáñez  ---
Confirmed on trunk. It crashes on any input. 

If you want to propose a patch, see
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug libobjc/67455] Inheriting from Object (with GNU runtime) doesn't provide alloc, init, or new, rendering methods useless

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> 67455.m:21:2: warning: (Messages without a matching method signature
> 67455.m:21:2: warning: will be assumed to return ‘id’ and accept
> 67455.m:21:2: warning: ‘...’ as arguments.)

Also this message should probably be a single note rather than warnings, so I
guess this is a diagnostics issue too.

[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||admin at maniacsvault dot net

--- Comment #9 from Eric Gallager  ---
*** Bug 66504 has been marked as a duplicate of this bug. ***

[Bug objc++/66504] ICE using C++ exceptions in Objective-C++

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> Confirmed; message I get now with trunk is:
> 
> $ /usr/local/bin/g++ -c 35756.mm
> during GIMPLE pass: eh
> 35756.mm: In function ‘void Problem()’:
> 35756.mm:1:6: internal compiler error: in objc_eh_runtime_type, at
> objc/objc-next-runtime-abi-01.c:2791
>  void Problem()
>   ^~~
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> 
> Attaching gdb to get a backtrace, I get:
> 
> Breakpoint 2, 0x00fb3c74 in internal_error ()
> (gdb) bt
> #0  0x00fb3c74 in internal_error ()
> warning: .o file
> "/private/var/root/gcc-git/my_oddly_named_builddir/./mpfr/src/.libs/libmpfr.
> a(mpfr-gmp.o)" more recent than executable timestamp
> #1  0x014e9561 in fancy_abort ()
> #2  0x012db91c in objc_eh_runtime_type ()
> #3  0x007b571b in add_type_for_runtime ()
> #4  0x007b57ab in gen_eh_region_catch ()
> #5  0x00c676c1 in lower_eh_constructs_1 ()
> #6  0x00c68deb in (anonymous namespace)::pass_lower_eh::execute ()
> #7  0x00af3550 in execute_one_pass ()
> #8  0x00af3eb9 in execute_pass_list_1 ()
> #9  0x00af3f0e in execute_pass_list ()
> #10 0x006bed49 in cgraph_node::analyze ()
> #11 0x006c1d3d in analyze_functions ()
> #12 0x006c2c42 in symbol_table::finalize_compilation_unit ()
> #13 0x00bee32a in compile_file ()
> #14 0x01b02420 in toplev::main ()
> #15 0x01b03a34 in main ()
> 
> I'll have to rebuild with debug info to get a better backtrace.

Actually looking at the backtrace makes me think this is a dup of bug 61759

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

[Bug inline-asm/55681] Qualifiers on asm statements are order-dependent

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
There's a proposal to add "asm inline" too, which seems like it would be
relevant here: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00748.html

[Bug libstdc++/59472] Many warnings "type of 'X' does not match original declaration" when linking with libstdc++ static library compiled with -flto

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Paul Scruby from comment #5)
> Is there a patch to fix or suppress the warnings when link-time optimizing
> to libstdc++.a ?  I'm using gcc4.8.2, but I'm happy to upgrade to gcc4.9 if
> this release is more likely to get fixed first?

Well both those branches are closed now; could you upgrade to something more
recent instead?

[Bug fortran/49802] [F03] [F08] Wrong code with VALUE, VALUE with arrays/DIMENSION

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #9 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #8)
> > I also confirm that compiling the test in comment #5 gives an ICE
> 
> I get the same ICE with the following code
> 
>   call pr53876
> end
> 
> subroutine pr53876
>   IMPLICIT NONE
>   TYPE :: individual
> integer :: icomp ! Add an extra component to test offset
> REAL, DIMENSION(:), ALLOCATABLE :: genes
>   END TYPE
>   CLASS(individual), DIMENSION(:), ALLOCATABLE :: indv, indv1
>   allocate (indv(2), source = [individual(1, [99,999]), &
>individual(2, [999,])])
> !  allocate (indv1(2), source = [indv(1),indv(2)])
>   print *, fun([indv(1),indv(2)])
> contains
>   elemental function fun(x) result(res)
>  integer :: res
>  class(individual), intent(in) :: x
>  res = x%genes(1)
>   end
> END

This ICE is no longer present in trunk.

[Bug c++/87663] Exorbitant compile times

[lumosimann at gmail dot com]

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

--- Comment #5 from Lukas Mosimann  ---
I was able to track down the error. The problem is caused due to
`set_underlying_type` in cfamily/c_common.c. I tried to disable that function
by simply returning on entry - and compilation times for cc1plus are completely
restored in all examples in this issue. This of course breaks other code, but
for the case of demonstration this is enough.
The first example with Version C used to compile in N=23: 181s, N=24: 493s,
N=25: 1348s. We would expect this to be a fibonacchi sequence - and this are
the new compile times for the same source: N=23: 5s, N=24: 8s, N=25: 13s.
Tests of  

Consider the example in the last comment. There the problem arises because the
variant list gets huge as this function adds type variants for the int-typedef
over and over. When looking for the right variant later, we need to iterate
over potentially all this variants.

Now I need your help: I don't know the code base for gcc that well. Why do we
need this functionality, and how could we solve this issue? I could imagine
that this can also impact real code - but it's hard to say because the
quick-fix above only works in simple codes. I would love to continue working on
this, but I need some hints how I could do this (or that it cannot be done
without major rework).

[Bug c++/49251] [C++0x][parameter pack expanding] unused parameter warning with unpacking empty tuples

[logicstuffs at gmail dot com]

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

LogicStuff  changed:

   What|Removed |Added

 CC||logicstuffs at gmail dot com

--- Comment #6 from LogicStuff  ---
#include 

template< std::size_t... Indices >
struct indices {};

template< class... Args >
void sink( Args&&... ) {}

template< class Tuple, std::size_t... Indices >
void unpack_test( Tuple t, indices ) {
  sink( std::get(t)... );
}

int main() {
  unpack_test( std::tuple<>(), indices<>() );
}



With the small change in the signature (notice passing `t` by value), is this
warning acceptable?

bug.cc: In instantiation of 'void unpack_test(Tuple, indices)
[with Tuple = std::tuple<>; long unsigned int ...Indices = {}]':
bug.cc:15:44:   required from here
bug.cc:10:25: warning: parameter 't' set but not used
[-Wunused-but-set-parameter]
 void unpack_test( Tuple t, indices ) {
 ^

Observed with various versions from 4.4.7 to 9.0.0 201810. Not observed with
Clang.

[Bug inline-asm/55681] Qualifiers on asm statements are order-dependent

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
Yes.  In fact, *all* combinations of two or more of {const,volatile,restrict}
are disallowed it seems.  "goto" is only allowed at the very end.  C++ only
allows volatile.

I'll have a shot at this (for inline as well).

[Bug c/87779] New: Extremely large expression causes segfault

[326374 at danwolff dot se]

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

Bug ID: 87779
   Summary: Extremely large expression causes segfault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 326374 at danwolff dot se
  Target Milestone: ---

Created attachment 44915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44915&action=edit
example.c - C code that causes a segfault

$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright [...]

$ gcc example.c
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit [...]

$ cat example.c
#include

int main(void) {
int x = !!![one megabyte of exclamation marks]!!!1;
printf("%d", x);
return 0;
}



The same error occurs for the corresponding g++ command.

(I haven't come across this problem in the real world - I was just playing
around.)

[Bug bootstrap/81033] [8 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

[iains at gcc dot gnu.org]

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

--- Comment #48 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 28 22:56:02 2018
New Revision: 265576

URL: https://gcc.gnu.org/viewcvs?rev=265576&root=gcc&view=rev
Log:
fix PR81033 and associated.

2018-10-28  Iain Sandoe  

Backport from mainline
2018-08-22  Iain Sandoe  

PR bootstrap/81033
PR target/81733
PR target/52795
* gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New.
(dwarf2out_switch_text_section): Generate a local label for the second
function sub-section and apply it as the second FDE start label.
* gcc/final.c (final_scan_insn_1): Emit second FDE label after the
second
sub-section start.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/final.c

[Bug target/81733] stage1 libgcc_s.dylib fails to link on Darwin 11/x86_64

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 28 22:56:02 2018
New Revision: 265576

URL: https://gcc.gnu.org/viewcvs?rev=265576&root=gcc&view=rev
Log:
fix PR81033 and associated.

2018-10-28  Iain Sandoe  

Backport from mainline
2018-08-22  Iain Sandoe  

PR bootstrap/81033
PR target/81733
PR target/52795
* gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New.
(dwarf2out_switch_text_section): Generate a local label for the second
function sub-section and apply it as the second FDE start label.
* gcc/final.c (final_scan_insn_1): Emit second FDE label after the
second
sub-section start.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/final.c

[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
Author: iains
Date: Sun Oct 28 22:56:02 2018
New Revision: 265576

URL: https://gcc.gnu.org/viewcvs?rev=265576&root=gcc&view=rev
Log:
fix PR81033 and associated.

2018-10-28  Iain Sandoe  

Backport from mainline
2018-08-22  Iain Sandoe  

PR bootstrap/81033
PR target/81733
PR target/52795
* gcc/dwarf2out.c (FUNC_SECOND_SECT_LABEL): New.
(dwarf2out_switch_text_section): Generate a local label for the second
function sub-section and apply it as the second FDE start label.
* gcc/final.c (final_scan_insn_1): Emit second FDE label after the
second
sub-section start.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/final.c

[Bug bootstrap/81033] [8 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces

[iains at gcc dot gnu.org]

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

--- Comment #49 from Iain Sandoe  ---
so this should now be fixed on trunk/8.x

It's not listed as a regression on 7.x but as I noted in the original patch
submission it's wrong code there - just not triggered until the partitioning
became part of bootstrap.

So leaving this open until there's a decision on 7.x.

[Bug c++/87766] [9 Regression] ICE using __PRETTY_FUNCTION__ in dependent context

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-28
   Target Milestone|--- |9.0
Summary|ICE using   |[9 Regression] ICE using
   |__PRETTY_FUNCTION__ in  |__PRETTY_FUNCTION__ in
   |dependent context   |dependent context
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Started with r264292.

[Bug rtl-optimization/87780] New: [9 regression] ICE error: unrecognizable insn

[romain.geissler at amadeus dot com]

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

Bug ID: 87780
   Summary: [9 regression] ICE error: unrecognizable insn
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I have the following ICE when building llvm+clang+lld 7.0.0 (PGO + LTO profile)
on x64 with gcc from 28/10/2018 (while it was working fine with gcc from
11/10/2018):

/workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h:5222:1: error:
unrecognizable insn:
 5222 | }
  | ^
(insn 1262 1261 1263 2 (set (reg:V1TI 678)
(reg:TI 1 dx [ TL ]))
"/workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h":5212:1 -1
 (nil))
during RTL pass: subreg2
/workdir/src/llvm-7.0.0.src/tools/clang/lib/Sema/TreeTransform.h:5222:1:
internal compiler error: in extract_insn, at recog.c:2305
0xfb86cb ???
/workdir/src/gcc-9.0.0/gcc/rtl-error.c:108
0xfb86e7 ???
/workdir/src/gcc-9.0.0/gcc/rtl-error.c:116
0x90ac09 ???
/workdir/src/gcc-9.0.0/gcc/recog.c:2305
0x179be75 ???
/workdir/src/gcc-9.0.0/gcc/lower-subreg.c:1483
0x180b49d ???
/workdir/src/gcc-9.0.0/gcc/lower-subreg.c:1750
0x12750d6 ???
/workdir/src/gcc-9.0.0/gcc/passes.c:2428
0x12e9abc ???
/workdir/src/gcc-9.0.0/gcc/passes.c:2517
0x14dd528 ???
/workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2194
0x12727ca ???
/workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2332
0x1268677 ???
/workdir/src/gcc-9.0.0/gcc/cgraphunit.c:2861
0x1240f3a ???
/workdir/src/gcc-9.0.0/gcc/toplev.c:480
0x11b05c6 ???
/workdir/src/gcc-9.0.0/gcc/toplev.c:2172
0x11af92a ???
/workdir/src/gcc-9.0.0/gcc/main.c:39
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
ninja: build stopped: subcommand failed.

Cheers,
Romain

[Bug c++/87663] Exorbitant compile times

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Lukas Mosimann from comment #5)
> Now I need your help: I don't know the code base for gcc that well. Why do
> we need this functionality, and how could we solve this issue? I could
> imagine that this can also impact real code - but it's hard to say because
> the quick-fix above only works in simple codes. I would love to continue
> working on this, but I need some hints how I could do this (or that it
> cannot be done without major rework).

The answer to the first question is in the comment above the function. It seems
this is needed for debugging and other stuff. 

Perhaps the search over the variants is not needed or can be made more
efficient?

In any case, it may be worth it to ask the question in the gcc@ mailing list,
CCing the C++ maintainers, which you can find in the MAINTAINERS file. Not many
people read bugzilla.

[Bug c++/83028] Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin  changed:

   What|Removed |Added

 CC||matthijsvanduin at gmail dot 
com

--- Comment #1 from Matthijs van Duin  ---
There are many such cases which are well-defined in C++17 yet trigger a
sequence-point warning in g++ 8.2, such as:

(x+i)[i++]
i = i++
(funcs[i++])(i)

This incorrect behaviour is actually documented: "The C++17 standard will
define the order of evaluation of operands in more cases: in particular it
requires that the right-hand side of an assignment be evaluated before the
left-hand side, so the above examples are no longer undefined. But this warning
will still warn about them, to help people avoid writing code that is undefined
in C and earlier revisions of C++."

This reasoning here is of course complete garbage. Plenty of valid C++17 code
is invalid in earlier revisions of the standard. When compiling code with
-std=c++17 or -std=gnu++17, the compiler should only concern itself with
whether the code is valid C++17 code.

Since I think habitually ignoring warnings is very bad practice and compile
with -Werror to ensure this won't happen, I consider these warnings to be
nearly as bad as miscompilation, as the end result is the same: I still cannot
rely on this feature of the C++17 standard.

[Bug debug/87428] "Missed" inline instances cause bogus DWARF to be emitted

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #4 from Romain Geissler  ---
Hi,

The same issue happens with gcc 8 as well:

/workdir/src/gdb-8.2/gdb/dwarf2read.c:9715: internal-error: void
dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL ||
(SYMBOL_LANGUAGE ((*listhead)->symbol[
0]) == SYMBOL_LANGUAGE (symbol))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]

I could validate on my side that applying this patch + rebuilding all
LTO-enabled libraries participating into the final link of my binary did solve
this issue.

Cheers,
Romain

[Bug target/87780] [9 regression] ICE error: unrecognizable insn

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-10-29
  Component|rtl-optimization|target
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source?  Or reduce it as it is PGO/LTO.
Also it seems like a missing subreg.

[Bug tree-optimization/86965] nios2 optimizer forgets about known upper bits of register

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org
  Component|target  |tree-optimization

--- Comment #1 from sandra at gcc dot gnu.org ---
I'm not sure what command-line options you were using, but with -O2 the bad2
case now generates the expected code.

Looking at the bad1 case, this is what's coming out of the tree optimizers, and
what the back end has to deal with for RTL expansion:

bad1 (const signed char * str, int * res)
{
  int c;
  signed char _1;
  int _2;
  int _11;
  signed char _12;
  _Bool _13;

   [local count: 1073741824]:
  _1 = *str_6(D);
  c_8 = (int) _1;
  _2 = c_8 + -48;
  *res_9(D) = _2;
  _12 = _1 & -33;
  _13 = _12 == 69;
  _11 = (int) _13;
  return _11;

}

The code coming out of RTL expand is a mess too; there's no QImode "and"
instruction, it can't use the SImode "andi" instruction because that it only
accepts small unsigned constants (not -33), and then it has to sign-extend the
QImode result it computed because the comparison instructions need SImode too.

FWIW I think the real bug here is in the tree reassoc1 pass: it shouldn't
attempt this optimization if there is no optab support for bitwise AND in the
appropriate mode.  So I'm reclassifying this as a tree-optimization bug rather
than a target bug; if the maintainers dispute that, feel free to switch it back
and I will take another look see if I can do something in the backend to
recombine the insns.

[Bug target/86975] wrong peephole optimization applied on nios2 and mips targets

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
Given that this code is originating in the tree reassoc1 pass, wouldn't it be
better to just make that pass prefer to generate a code sequence with an
unsigned constant on all targets?  It should work just as well as the current
negative-constant expansion does on targets that support unsigned constants,
right?

[Bug tree-optimization/86965] nios2 optimizer forgets about known upper bits of register

[sandra at gcc dot gnu.org]

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

--- Comment #2 from sandra at gcc dot gnu.org ---
Also see PR86975, which is specifically about that negative constant operand to
the AND expression being generated by the range optimizer.

[Bug tree-optimization/70390] [6/7/8/9 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[asolokha at gmx dot com]

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

--- Comment #13 from Arseny Solokha  ---
Actually, I cannot reproduce it on the trunk anymore as of r265575.

[Bug rtl-optimization/87596] [9 Regression] ICE: Segmentation fault (in spill_hard_reg_in_range)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #8 from Arseny Solokha  ---
Fixed on the trunk.

[Bug c/71613] Useful warnings silenced when macros from system headers are used

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #6)
> Rather than piecemeal fixes with no evidence of completeness, I think we 
> should disable the smarts around system header macro locations determining 
> whether diagnostics appear (i.e., the system-header tests for disabling 
> diagnostics should all use the expansion location), until we have a proper 
> design for avoiding such issues and have systematically reviewed all 
> diagnostics for conforming to such a design (if the design needs each 
> diagnostic function call to be reviewed).

Coming up with a proper design might never happen though. I'd rather just have
the piecemeal fixes in the meantime.

[Bug c/71610] Improve location for "warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]"?

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to David Malcolm from comment #4)
> Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01658.html

Does this still apply?