[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #15 from Zhendong Su  ---
(In reply to Jakub Jelinek from comment #12)
> Can you attach -fdump-tree-optimized and -fdump-rtl-cse2
> -fdump-rtl-pro_and_epilogue -fdump-rtl-dse ?  I really wonder what is
> different in our vs. your compiler.

Jakub, I've just added the two files.  For -fdump-rtl-dse, I assume that you
meant -fdump-rtl-dse2 instead.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #14 from Zhendong Su  ---
Created attachment 43688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43688=edit
output from "gcctk -fdump-rtl-cse2 -fdump-rtl-pro_and_epilogue -fdump-rtl-dse2
-c small.c"

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #13 from Zhendong Su  ---
Created attachment 43687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43687=edit
output from "gcctk -fdump-rtl-cse2 -c small.c"

[Bug fortran/84922] New: fortran reports inconsistency in rank of arguments in interface and contained procedures

[w.clodius at icloud dot com]

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

Bug ID: 84922
   Summary: fortran reports inconsistency in rank of arguments in
interface and contained procedures
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w.clodius at icloud dot com
  Target Milestone: ---

When compiling modules it is sometimes useful to provide an interface for the
contained procedure. For some of my procedures gfortran 7.1 is reporting an
inconsistency in the ranks for some of the arguments. This has occurred for
using a simple interface, a generic interface, or for using an interface for a
procedure defined in a submodule. The following file causes the problem for
fortran 7.1

module copy

use, intrinsic :: iso_fortran_env, only : int8


interface

module subroutine copy_byte_data( data, copy ) ! Chase's copier
integer(int8), intent(in)   :: data(:)
integer(int8), allocatable, intent(out) :: copy(:)
end subroutine copy_byte_data

end interface



contains


subroutine copy_byte_data( data, copy ) ! Chase's copier
integer(int8), intent(in)   :: data(:)
integer(int8), allocatable, intent(out) :: copy(:)

if ( allocated( copy ) ) then
deallocate( copy )
end if
allocate( copy( size(data) ) )
copy = data

return

end subroutine copy_byte_data

end module copy

program test_copy

use copy

integer(int8)  :: data(8) = 0_int8
integer(int8), allocatable :: acopy(:)

write(*,*) 'DATA = ', data

call copy_byte_data( data, acopy)

write(*, *) 'ACOPY = ', acopy

stop

end program test_copy

When compiled from the Terminal command line on Mac OS X 10.13.3, using the
command
gfortran test_copy.f90

I get the following response

test_copy.f90:21:35:

 subroutine copy_byte_data( data, copy ) ! Chase's copier
   1
Error: Shape mismatch in argument 'data' at (1)
test_copy.f90:39:8:

 use copy
1
Fatal Error: Can't open module file ‘copy.mod’ for reading at (1): No such file
or directory
compilation terminated.

[Bug fortran/78593] [6/7 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2053

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kimwooyoung at gmail dot com

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

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #9 from Dominique d'Humieres  ---
>So, it can be closed?

Marked as duplicate of pr78593.

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

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Jeffrey A. Law from comment #3)
> Umm, isn't that invalid code?  The whole point of the warning is to catch
> precisely this kind of broken idiom.  Right?

Why is it invalid?  Argument 4 is for %p. It looks valid to me.

[committed] Remove trailing whitespace from diagnostics (PR c/84910)

[Jakub Jelinek]

Hi!

All of warning, error_at and inform functions emit a newline after the
message, so trailing whitespace is undesirable there.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.

2018-03-16  Jakub Jelinek  

PR c/84910
* c-warn.c (diagnose_mismatched_attributes): Remove trailing space from
diagnostics.

* parser.c (cp_parser_lambda_introducer): Remove trailing space from
diagnostics.
* method.c (synthesize_method): Likewise.
* pt.c (convert_nontype_argument): Likewise.

--- gcc/c-family/c-warn.c.jj2018-03-13 00:38:23.808662251 +0100
+++ gcc/c-family/c-warn.c   2018-03-16 17:36:31.431124231 +0100
@@ -2258,7 +2258,7 @@ diagnose_mismatched_attributes (tree old
   && DECL_UNINLINABLE (newdecl)
   && lookup_attribute ("noinline", DECL_ATTRIBUTES (newdecl)))
 warned |= warning (OPT_Wattributes, "declaration of %q+D with attribute "
-  "%qs follows inline declaration ", newdecl, noinline);
+  "%qs follows inline declaration", newdecl, noinline);
 
   return warned;
 }
--- gcc/cp/parser.c.jj  2018-03-15 08:36:27.982776658 +0100
+++ gcc/cp/parser.c 2018-03-16 17:35:17.628093001 +0100
@@ -10383,7 +10383,7 @@ cp_parser_lambda_introducer (cp_parser*
   && TREE_CODE (capture_init_expr) != PARM_DECL)
{
  error_at (capture_token->location,
-   "capture of non-variable %qE ",
+   "capture of non-variable %qE",
capture_init_expr);
  if (DECL_P (capture_init_expr))
inform (DECL_SOURCE_LOCATION (capture_init_expr),
--- gcc/cp/method.c.jj  2018-01-27 07:26:08.357912834 +0100
+++ gcc/cp/method.c 2018-03-16 17:35:42.024103324 +0100
@@ -950,7 +950,7 @@ synthesize_method (tree fndecl)
   pop_deferring_access_checks ();
 
   if (error_count != errorcount || warning_count != warningcount + werrorcount)
-inform (input_location, "synthesized method %qD first required here ",
+inform (input_location, "synthesized method %qD first required here",
fndecl);
 }
 
--- gcc/cp/pt.c.jj  2018-03-15 08:36:27.980776658 +0100
+++ gcc/cp/pt.c 2018-03-16 17:34:06.575062936 +0100
@@ -6753,7 +6753,7 @@ convert_nontype_argument (tree type, tre
  else
expr = cxx_constant_value (expr);
  if (errorcount > errs || warningcount + werrorcount > warns)
-   inform (loc, "in template argument for type %qT ", type);
+   inform (loc, "in template argument for type %qT", type);
  if (expr == error_mark_node)
return NULL_TREE;
  /* else cxx_constant_value complained but gave us

Jakub

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Umm, isn't that invalid code?  The whole point of the warning is to catch
precisely this kind of broken idiom.  Right?

[Bug fortran/65453] ICE in build_function_decl, at fortran/trans-decl.c:2001

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
patch submitted.

[PATCH] PR fortran/65453 -- procedure statement vs subprogram name clash

[Steve Kargl]

The attached patch fixes an ICE by detecting a name
clash between a procedure statement and a contained
subprogram.  Regression tested on x86_64-*-freebsd.

2018-03-16  Steven G. Kargl  

PR fortran/65453
* decl.c (get_proc_name): Catch clash between a procedure statement
and a contained subprogram

2018-03-16  Steven G. Kargl  

PR fortran/65453
* gfortran.dg/pr65453.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 258607)
+++ gcc/fortran/decl.c	(working copy)
@@ -1219,6 +1219,12 @@ get_proc_name (const char *name, gfc_symbol **result, 
 	gfc_error_now ("Procedure %qs at %C is already defined at %L",
 		   name, >declared_at);
 
+  if (sym->attr.external && sym->attr.procedure
+	  && gfc_current_state () == COMP_CONTAINS)
+	gfc_error_now ("Contained procedure %qs at %C clashes with "
+			"procedure defined at %L",
+		   name, >declared_at);
+
   /* Trap a procedure with a name the same as interface in the
 	 encompassing scope.  */
   if (sym->attr.generic != 0
Index: gcc/testsuite/gfortran.dg/pr65453.f90
===
--- gcc/testsuite/gfortran.dg/pr65453.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr65453.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/65453
+! Contributed by Tobias Burnus  
+procedure() :: foo   ! { dg-error "(1)" }
+  contains
+subroutine foo() ! { dg-error "clashes with procedure" }
+end
+end

Re: [PATCH] avoid warning for memcpy to self (PR 83456)

[H.J. Lu]

On Wed, Mar 7, 2018 at 3:01 PM, Martin Sebor  wrote:
> I have become convinced that issuing -Wrestrict in gimple-fold
> for calls to memcpy() where the source pointer is the same as
> the destination causes more trouble than it's worth, especially
> when inlining is involved, as in:
>
>   inline void bar (void *d, void *s, unsigned N)
>   {
> if (s != d)
>   memcpy (d, s, N);
>   }
>
>   void foo (void* src)
>   {
> bar (src, src, 1);
>   }
>
> It seems that there should be a way to teach GCC to avoid
> folding statements in dead blocks (e.g., in a block controlled
> by 'if (0 != 0)' as the one below), and that it might even speed
> up compilation, but in the meantime it leads to false positive
> -Wrestrict warnings.
>
> The attached patch removes this instance of the warning and
> adjusts tests not to expect it.

This caused:

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


-- 
H.J.

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from H.J. Lu  ---
This is caused by r258455.

Re: [PATCH, rs6000] Finish implementation of __builtin_atlivec_lvx_v1ti

[Segher Boessenkool]

On Wed, Mar 14, 2018 at 04:27:31PM -0500, Kelvin Nilsen wrote:
> During code review, it was discovered that the implementation of
> __builtin_altivec_lvx_v1ti is not complete.  The constant
> ALTIVEC_BUILTINLVX_V1TI is introduced and is bound to the function
> __builtin_altivec_lvx_v1ti.  However, this function's implementation is
> incomplete because there is no call to the def_builtin function for this
> binding.
> 
> This patch provides the missing pieces to add support for this function.
> Additionally, this patch introduces four new __int128-based prototypes
> of the overloaded __builtin_vec_ld function.  This is the function that
> implements the vec_ld () macro expansion.  A new test case has been
> provided to exercise each of these prototypes.

Do we want/need stvx_v1ti as well?

> --- gcc/config/rs6000/rs6000.c(revision 258341)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -14452,6 +14452,7 @@ altivec_expand_lv_builtin (enum insn_code icode, t
>   LVXL and LVE*X expand to use UNSPECs to hide their special behavior,
>   so the raw address is fine.  */
>if (icode == CODE_FOR_altivec_lvx_v2df_2op
> +  || icode == CODE_FOR_altivec_lvx_v1ti_2op
>|| icode == CODE_FOR_altivec_lvx_v2di_2op
>|| icode == CODE_FOR_altivec_lvx_v4sf_2op
>|| icode == CODE_FOR_altivec_lvx_v4si_2op

That's a weird ordering; put v1ti first?

> @@ -15811,6 +15812,9 @@ altivec_expand_builtin (tree exp, rtx target, bool
>  case ALTIVEC_BUILTIN_LVX_V2DI:
>return altivec_expand_lv_builtin (CODE_FOR_altivec_lvx_v2di_2op,
>   exp, target, false);
> +case ALTIVEC_BUILTIN_LVX_V1TI:
> +  return altivec_expand_lv_builtin (CODE_FOR_altivec_lvx_v1ti_2op,
> + exp, target, false);
>  case ALTIVEC_BUILTIN_LVX_V4SF:
>return altivec_expand_lv_builtin (CODE_FOR_altivec_lvx_v4sf_2op,
>   exp, target, false);

Same here.

> --- gcc/testsuite/gcc.target/powerpc/altivec-ld-1.c   (nonexistent)
> +++ gcc/testsuite/gcc.target/powerpc/altivec-ld-1.c   (working copy)
> @@ -0,0 +1,67 @@
> +/* { dg-do run { target powerpc*-*-* } } */
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-options "-maltivec -O0 -Wall -Wno-deprecated" } */

Since this is a run testcase you need vmx_hw instead of powerpc_altivec_ok.
You also need a test for int128.  I don't think you need lp64, please check.

Okay for trunk with that fixed.  Thanks!


Segher

[Bug tree-optimization/84921] New: [5 Regression] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movdqa) can be used

[jim at meyering dot net]

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

Bug ID: 84921
   Summary: [5 Regression] With -O3 gcc incorrectly assumes
aligned SSE instructions (e.g. movdqa) can be used
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim at meyering dot net
  Target Milestone: ---

Created attachment 43686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43686=edit
5.5 reproducer, with g++ -O3

Much like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598, this affects only
the gcc-5-branch (I tested with head of 5) and appears to have been fixed on
trunk by a combination of changes terminating with the 2015-06-18 commit, PR
tree-optimization/66510 (git commit c1bee668987f371617586edafa0dfccf04162a83).

This may also be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564,
but someone claimed that was still present in 6.3, which this is not. Bisection
suggests that this was fixed on master before the gcc-6-branch point by the
commit mentioned above.

Running the following minimized reproducer elicits a segfault from 5.5, but not
from 6.1 (6.1 generates a movdqu rather than movdqa):

  g++ -std=c++14 -O3 unaligned-movdqa.cpp && ./a.out

I considered back-porting the above commit and even took a shot at resolving
the four conflicts, but that commit introduces uses of two functions
(vect_slp_analyze_operations and vect_update_vf_for_slp) that were added in
preceding diffs, so did not pursue it.

[Bug fortran/58787] ICE (error recovery) in check_proc_interface

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Fri, Mar 16, 2018 at 10:57:46PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
> 
> --- Comment #8 from Dominique d'Humieres  ---
> > Does it still fail for you?
> 
> Yep!-(
> 

Ah, so one needs to use a sanitizer.  Compiles without
issue on FreeBSD.

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Fri, Mar 16, 2018 at 11:03:30PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58904
> 
> --- Comment #6 from Dominique d'Humieres  ---
> I get
> 
> pr58904.f90:5:4:
> 
>  r%b = b
> 1
> Error: Unclassifiable statement at (1)
> pr58904.f90:3:2:
> 
>TYPE(mytype) FUNCTION create_sort_range(b) result(r)
>   1
> Error: The type for function 'create_sort_range' at (1) is not accessible
> 
> with 6.4, 7.3, and trunk (8.0) and an ICE with 5.5.
> 

So, it can be closed?

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[jimis at gmx dot net]

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

--- Comment #4 from jimis  ---
Indeed, as showcased by this example:

https://godbolt.org/g/nsSTHG

The function calls __udivmoddi4, like you said. However, the call is inlined in
main, but there we see separate calls for __udivdi3 and __umoddi3. Is it
because in main the divisor is the same constant?

If so I can close this bug and monitor bug 84759.

Thanks!

[Bug c++/84892] Missing accessor hint for private field

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> Reddit user "evaned" reports that we fail to offer a fix-it hint code
> suggesting the "get_field" accessor on this code:
> https://godbolt.org/g/y2cbuv
> 
> 
> class S {
> private:
> bool field;
> 
> public:
> bool get_field() const {
> return field;
> }
> };
> 
> bool thingy(const S & s) {
>   return s.field;
> }
> 
> 
> Removing the "const" from "thingy" seems to fix it.

Link to evaned's original comment is here:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrh7jf/
Thus, confirmed.

[Bug c++/84898] Fix-it hints for '.' vs '->'

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> Reddit user "Boojum" suggested:
> 
> > [...] Clang offers fix-its for both errors and gets the symmetry correct:
> 

Link to that comment is:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrj48o/

Re: [PATCH v2, rs6000] Remove unused (and incorrect) code for internal store and load operations

[Segher Boessenkool]

Hi Kelvin,

Okay for trunk.  Thanks!


Segher


On Wed, Mar 14, 2018 at 02:22:44PM -0500, Kelvin Nilsen wrote:
> 2018-03-14  Kelvin Nilsen  
> 
>   * config/rs6000/rs6000-builtin.def: Remove various BU_ALTIVEC_X
>   macro expansions for definition of ST_INTERNAL_ and
>   LD_INTERNAL_ builtins.
>   * config/rs6000/rs6000-protos.h (rs6000_address_for_altivec):
>   Remove prototype.
>   * config/rs6000/rs6000.c (altivec_expand_ld_builtin): Delete this
>   function.
>   (altivec_expand_st_builtin): Likewise.
>   (altivec_expand_builtin): Remove calls to deleted functions.
>   (rs6000_address_for_altivec): Delete this function.
>   * config/rs6000/vector.md: Remove expands for
>   vector_altivec_load_ and vector_altivec_store_.

[Bug c++/84897] Better handling of unqualified "string"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> Reddit user "Boojum" suggested:
> 
> > As far as other paper cuts, here's one that catches me
> > surprisingly frequently:
> 
> #include 
> int main() {
> string x("foo");
> }
> 
> > Obviously, I "forgot" to either qualify string as std::string,
> > add using namespace std;, or add using std::string;.
> >
> > Here's what GCC 7.2 tells me (header paths elided):
> 
> namespace.cpp: In function ‘int main()’:
> namespace.cpp:3:5: error: ‘string’ was not declared in this scope
>  string x("foo");
>  ^~
> namespace.cpp:3:5: note: suggested alternatives:
> In file included from .../string:39:0,
>  from namespace.cpp:1:
> .../stringfwd.h:74:33: note:   ‘std::__cxx11::string’
>typedef basic_stringstring;
>  ^~
> .../stringfwd.h:74:33: note:   ‘std::__cxx11::string’
> 
> > On the other hand, here's what Clang 6 tells me:
> 
> namespace.cpp:3:5: error: unknown type name 'string'; did you mean
> 'std::string'?
> string x("foo");
> ^~
> std::string
> .../stringfwd.h:74:33: note: 'std::string' declared here
>   typedef basic_stringstring;
> ^
> 1 error generated.
> 
> > Much nicer. It tells me exactly which namespace I probably
> > meant to use and proposes a fix-it qualifying the identifier.
> 

Link to this comment is here:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrj48o/

[Bug rtl-optimization/84660] Combine doing wrong optimization for 64 bits with SHIFT_COUNT_TRUNCATED target

[wilson at gcc dot gnu.org]

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

--- Comment #5 from Jim Wilson  ---
This is what the original patch I wrote looked like.  But then I tried to
optimize it a bit to eliminate the redundant nonzero_bits call, and that is
where I screwed up.  Then I got overwhelmed by work and haven't had a chance to
get back to it yet.

I can't self approve patches to combine, so it needs to be submitted to
gcc-patches for review.

It probably should be tested on at least one other target that isn't
SHIFT_COUNT_TRUNCATED.

[Bug c/84888] C/C++: Improve wording of unclosed paren/brace

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> 
> As in bug 84887, I'd like a link to the reddit thread mentioned here, too

Thread is here:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvr93d4/
Confirming on the basis that your original bug was actually a confirmation of
the linked comment.

[Bug c/84887] missing semicolon: further improvements

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> link to thread on reddit?
> 

Never mind, I found it:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvr93d4/
I'll confirm this bug after finding the Hacker News one, too.

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
The change occurred between revisions r242984 (2016-11-29, ICE) and r243219
(2016-12-03, errors), likely fixed by r243020 (pr78593) for gcc7 and r243485
for gcc6.

[Bug other/84889] Ideas on revamping how we format diagnostics

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
(In reply to David Malcolm from comment #4)
> (In reply to Eric Gallager from comment #3)
> > Link for this next one though?
> https://news.ycombinator.com/item?id=16598074

(In reply to David Malcolm from comment #5)
> ...and according to:
> https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/
> dvspoet/
> the rust developers took ideas on diagnostics-printing from Elm.  
> 
> Note to self: need to look at Elm.

Thanks, confirmed.

[Bug c/84890] Overly verbose notes for missing headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to David Malcolm from comment #3)
> (In reply to Eric Gallager from comment #2)
> > (In reply to David Malcolm from comment #0)
> > > 
> > > Reddit user "ramennoodle" comments:
> [...]
> > ...link for this one?
> https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/
> dvr6psr/

Thanks, confirmed.

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[b7.10110111 at gmail dot com]

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

--- Comment #3 from Ruslan  ---
Ah, actually your problem is with a constant divisor. I reported it as bug
84759. If you change 10 to e.g. a function parameter, then you'll get
__udivmoddi4.

[Bug c++/71167] Long typenames produce extremely hard to read diagnostics and slow down compilation time

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=17693

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Most likely a dup of bug 17693.

I'll just put it under "See Also" until there's more certainty that this is a
dup of it

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
I get

pr58904.f90:5:4:

 r%b = b
1
Error: Unclassifiable statement at (1)
pr58904.f90:3:2:

   TYPE(mytype) FUNCTION create_sort_range(b) result(r)
  1
Error: The type for function 'create_sort_range' at (1) is not accessible

with 6.4, 7.3, and trunk (8.0) and an ICE with 5.5.

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #1

[Michael Meissner]

In patch #4, I mentioned that the spec 2006 benchmark 'tonto' generated
different with the patches applied.  I tracked it down, and it was due to the
call I inserted in rs6000_debug_reg_print to update the conditional register
usage seemed to set the Altivec registers VS0..VS19 to call_used instead of
call_saved.  Since I no longer need to set the conditional register usage with
-mdebug=reg, it is simpler to just delete it.

2018-03-16  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_debug_reg_print): Eliminate call
to rs6000_conditional_register_usage.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 258576)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1314,7 +1314,6 @@ static bool rs6000_debug_can_change_mode
reg_class_t);
 static bool rs6000_save_toc_in_prologue_p (void);
 static rtx rs6000_internal_arg_pointer (void);
-static void rs6000_conditional_register_usage (void);
 
 rtx (*rs6000_legitimize_reload_address_ptr) (rtx, machine_mode, int, int,
 int, int *)
@@ -2144,10 +2143,6 @@ rs6000_debug_reg_print (int first_regno,
 {
   int r, m;
 
-  /* Insure the conditional registers are up to date when printing the debug
- information.  */
-  rs6000_conditional_register_usage ();
-
   for (r = first_regno; r <= last_regno; ++r)
 {
   const char *comma = "";

[Bug c++/84916] Tweaks to template type elision

[vittorio.romeo at outlook dot com]

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

Vittorio Romeo  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

--- Comment #2 from Vittorio Romeo  ---
This might be of interest as well:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71167

[Bug fortran/58787] ICE (error recovery) in check_proc_interface

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Does it still fail for you?

Yep!-(

...
Error: Expecting END SUBROUTINE statement at (1)
=
==19146==ERROR: AddressSanitizer: heap-use-after-free on address 0x61305b90
at pc 0x00010042c261 bp 0x7ffeefbfe830 sp 0x7ffeefbfe828
READ of size 1 at 0x61305b90 thread T0
#0 0x10042c260 in resolve_formal_arglist(gfc_symbol*) resolve.c:281
#1 0x10042fb23 in find_arglists(gfc_symbol*) resolve.c:551
#2 0x1004acd3e in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4159
#3 0x1004cafa3 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4184
#4 0x1003731a5 in resolve_formal_arglists(gfc_namespace*) resolve.c:564
#5 0x1003af5a2 in resolve_contained_functions(gfc_namespace*)
resolve.c:1119
#6 0x10042fec6 in resolve_types(gfc_namespace*) resolve.c:16470
#7 0x1003c3d32 in gfc_resolve(gfc_namespace*) resolve.c:16595
#8 0x1003290b2 in resolve_all_program_units(gfc_namespace*) parse.c:6060
#9 0x100348734 in gfc_parse_file() parse.c:6308
#10 0x100515192 in gfc_be_parse_file() f95-lang.c:204
#11 0x105d1be48 in compile_file() toplev.c:455
#12 0x105d26f8a in do_compile() toplev.c:2132
#13 0x108294d19 in toplev::main(int, char**) toplev.c:2267
#14 0x10829a1ff in main main.c:39
#15 0x7fff5260c114 in start (libdyld.dylib:x86_64+0x1114)

0x61305b90 is located 80 bytes inside of 336-byte region
[0x61305b40,0x61305c90)
freed by thread T0 here:
#0 0x156eff370 in wrap_free.part.0 sanitizer_malloc_mac.inc:142
#1 0x1004ca6da in gfc_free_symbol(gfc_symbol*) symbol.c:3063
#2 0x1004caa26 in gfc_release_symbol(gfc_symbol*) symbol.c:3090
#3 0x1004caea2 in free_sym_tree(gfc_symtree*) symbol.c:3892
#4 0x1004c9c5a in gfc_free_namespace(gfc_namespace*) symbol.c:4047
#5 0x1004caba2 in gfc_release_symbol(gfc_symbol*) symbol.c:3082
#6 0x1004caea2 in free_sym_tree(gfc_symtree*) symbol.c:3892
#7 0x1004c9c5a in gfc_free_namespace(gfc_namespace*) symbol.c:4047
#8 0x100347983 in parse_contained(int) parse.c:5616
#9 0x10034687f in parse_progunit(gfc_statement) parse.c:5739
#10 0x100348892 in gfc_parse_file() parse.c:6214
#11 0x100515192 in gfc_be_parse_file() f95-lang.c:204
#12 0x105d1be48 in compile_file() toplev.c:455
#13 0x105d26f8a in do_compile() toplev.c:2132
#14 0x108294d19 in toplev::main(int, char**) toplev.c:2267
#15 0x10829a1ff in main main.c:39
#16 0x7fff5260c114 in start (libdyld.dylib:x86_64+0x1114)

previously allocated by thread T0 here:
#0 0x156efe9e0 in wrap_calloc sanitizer_malloc_mac.inc:153
#1 0x108242032 in xcalloc xmalloc.c:162
#2 0x1004c1ac1 in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3099
#3 0x10028842e in load_needed(pointer_info*) module.c:4922
#4 0x100287e4f in load_needed(pointer_info*) module.c:4890
#5 0x100287e9a in load_needed(pointer_info*) module.c:4891
#6 0x10028db10 in read_module() module.c:5370
#7 0x10028f4d5 in gfc_use_module(gfc_use_list*) module.c:7072
#8 0x1002935f6 in gfc_use_modules() module.c:7196
#9 0x100329dc6 in use_modules() parse.c:114
#10 0x100335f2a in decode_statement() parse.c:332
#11 0x100338870 in next_free() parse.c:1230
#12 0x10033923e in next_statement() parse.c:1462
#13 0x10033f7eb in parse_spec(gfc_statement) parse.c:3854
#14 0x100346376 in parse_progunit(gfc_statement) parse.c:5667
#15 0x100348892 in gfc_parse_file() parse.c:6214
#16 0x100515192 in gfc_be_parse_file() f95-lang.c:204
#17 0x105d1be48 in compile_file() toplev.c:455
#18 0x105d26f8a in do_compile() toplev.c:2132
#19 0x108294d19 in toplev::main(int, char**) toplev.c:2267
#20 0x10829a1ff in main main.c:39
#21 0x7fff5260c114 in start (libdyld.dylib:x86_64+0x1114)

SUMMARY: AddressSanitizer: heap-use-after-free resolve.c:281 in
resolve_formal_arglist(gfc_symbol*)
Shadow bytes around the buggy address:
  0x1c260b20: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c260b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c260b50: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
  0x1c260b60: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
=>0x1c260b70: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260b80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260b90: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260ba0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260bb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260bc0: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone: 

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[jimis at gmx dot net]

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

--- Comment #2 from jimis  ---
No, I still see the same behaviour with gcc 7.3 on my Fedora box.

Is the this link from godbolt showcasing it for you?

https://godbolt.org/g/dKEf39

Re: [PATCH ] PR 844422 Fix FCTID, FCTIW with -mcpu=power7

[Segher Boessenkool]

Hi Carl,

On Wed, Mar 14, 2018 at 08:27:08AM -0700, Carl Love wrote:
> The following patch fixes an ICE when compiling the test case
> 
>   gcc -mcpu=power7 builtin-fctid-fctiw-runnable.c
> 
> The GCC compiler now gives a message 
> 
> "error: builtin function ‘__builtin_fctiw’ requires the ‘-mpower8-vector’ 
> option" 
> 
> and exits without generating an internal error.

This is an improvement over the ICE, for sure.

But fctiw is an ISA 1.xx instruction already (and fctid is as well,
but explicitly undefined for 32-bit implementations until some 2.xx,
I forgot which, 2.02 I think?)

Requiring power8 for it is weird and surprising.  power8-vector doubly so.

It does not seem to be a good idea to only enable the builtin for cases
where the current implementation is not broken.

(The issue is that pre-power8 we do not allow SImode in FPR registers.
Which makes the current fctiw implementation fail).

I think we have two good options:

1) Remove these builtins;
or
2) Make them work.


Segher

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
The original testcase on FreeBSD gives

troutmask:sgk[209] gfcx -c a.f90
a.f90:4:4:

 r%b = b
1
Error: Unclassifiable statement at (1)
a.f90:2:2:

   TYPE(mytype) FUNCTION create_sort_range(b) result(r)
  1
Error: The type for function 'create_sort_range' at (1) is not accessible
a.f90:6:3:

 END MODULE mymod
   1
Error: Expecting END PROGRAM statement at (1)
f951: Error: Unexpected end of file in 'a.f90'

without an ICE.

[Bug fortran/58787] ICE (error recovery) in check_proc_interface

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #6)
> > No longer ICEs with r238822.
> 
> It still fails for me:
> 
> [book15] f90/bug% /opt/gcc/gcc7p-238822p2/bin/gfortran pr58787.f90
> pr58787.f90:15:27:
>

>   1
> Error: Expecting END SUBROUTINE statement at (1)
> f951: internal compiler error: Segmentation fault: 11
> 
> f951: internal compiler error: Abort trap: 6
> gfortran: internal compiler error: Abort trap: 6 (program f951)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

Does it still fail for you?

[Bug c++/84920] Better handling of unmatched/ambiguous calls

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/84920] New: Better handling of unmatched/ambiguous calls

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84920
   Summary: Better handling of unmatched/ambiguous calls
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As reported by user "jcoffland" on Hacker News:
https://news.ycombinator.com/item?id=16598071

> One improvement I'd like to see is a simplified error message
> for mismatched overloaded calls. If you make an overloaded call
> for which the is no matching conversion or if the conversation is
> ambiguous the compiler will "helpfully" dump a list of possibly
> matching overloaded function signatures. The list can be hundreds
> of lines long.
>
> For example, when you try to pipe a class to std::cout that
> doesn't have an std::ostream <<(std::ostream &, const X &).
> Perhaps instead of dumping the complete function signatures it
> could show one function signature followed by a list of types
> accepted as the second parameter. Since the signatures are
> otherwise the same. Such improvements could also reduce
> template error spew.

I hope to have a look at this in the GCC 9 timeframe, so filing this here.

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
[hjl@gnu-bdx-1 tmp]$ cat x.c
#include 
#include 
char *str_error_r(char *buf, size_t buflen)
{
snprintf(buf, buflen, "(%p, %zd)", buf, buflen);
return buf;
}
[hjl@gnu-bdx-1 tmp]$ /usr/gcc-8.0.1-x32/bin/gcc -O2 -S -Wall x.c
x.c: In function ‘str_error_r’:
x.c:5:2: warning: passing argument 1 to restrict-qualified parameter aliases
with argument 4 [-Wrestrict]
  snprintf(buf, buflen, "(%p, %zd)", buf, buflen);
  ^~~~
[hjl@gnu-bdx-1 tmp]$

New German PO file for 'gcc' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-8.1-b20180128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug c/84919] New: [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

Bug ID: 84919
   Summary: [8 Regression] error: passing argument 1 to
restrict-qualified parameter aliases with argument 5
[-Werror=restrict]
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

When building Linux/x86-64 kernel 4.16-rc5, r258590 gave

gcc -Wp,-MD,/export/ssd/git/kernel.org/linux-cet/tools/objtool/.str_error_r.o.d
-Wp,-MT,/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o -Wall
-Werror -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
-Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked
-Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum
-Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Wno-switch-default
-Wno-switch-enum -Wno-packed -fomit-frame-pointer -O2 -g
-I/export/ssd/git/kernel.org/linux-cet/tools/include
-I/export/ssd/git/kernel.org/linux-cet/tools/arch/x86/include/uapi
-I/export/ssd/git/kernel.org/linux-cet/tools/objtool/arch/x86/include
-I/export/ssd/git/kernel.org/linux-cet/tools/lib -D"BUILD_STR(s)=\#s" -c -o
/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o
../lib/str_error_r.c
gnu-bdx-1:pts/7[63]> /usr/gcc-8.0.1-x32/bin/gcc
-Wp,-MD,/export/ssd/git/kernel.org/linux-cet/tools/objtool/.str_error_r.o.d
-Wp,-MT,/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o -Wall
-Werror -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
-Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked
-Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum
-Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Wno-switch-default
-Wno-switch-enum -Wno-packed -fomit-frame-pointer -O2 -g
-I/export/ssd/git/kernel.org/linux-cet/tools/include
-I/export/ssd/git/kernel.org/linux-cet/tools/arch/x86/include/uapi
-I/export/ssd/git/kernel.org/linux-cet/tools/objtool/arch/x86/include
-I/export/ssd/git/kernel.org/linux-cet/tools/lib -D"BUILD_STR(s)=\#s" -c -o
/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o
../lib/str_error_r.c
../lib/str_error_r.c: In function ‘str_error_r’:
../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified
parameter aliases with argument 5 [-Werror=restrict]
   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum,
buf, buflen, err);
   ^~~~
cc1: all warnings being treated as errors

[Bug c++/84918] Better handling of "std::cout >> 42;"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/84918] New: Better handling of "std::cout >> 42;"

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84918
   Summary: Better handling of "std::cout >> 42;"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvs5hjj/
points out:

> What is the current error message for

std::cout >> 42;

> On older compilers this would generate roughly 100 lines of unreadable
> error messages, so I detect and fix it in the static analyzer I wrote.

Checking on godbolt.org:

#include 
void test ()
{
std::cout >> 42;
}

we currently spew dozens of lines of diagnostics.

May be worth special-casing this, and offering a fix-it hint to convert ">>" to
"<<", if sane (and vice-versa).

[Bug c++/84269] C++ FE does not suggest which #include to use for "memset"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Another one:

void test (char *dst, const char *src)
{
strncpy (dst, 10, src);
}

In function 'void test(char*, const char*)':
:3:5: error: 'strncpy' was not declared in this scope
 strncpy (dst, 10, src);
 ^~~
:3:5: note: suggested alternative: 'struct'
 strncpy (dst, 10, src);
 ^~~
 struct

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to H.J. Lu from comment #3)
> (In reply to Jason Vas Dias from comment #2)
> > Thanks H.J. -
> > 
> > RE:
> > > vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> > > 4.16-rc5.  Why isn't it the case for you? 
> > 
> > All I know is ,  when submitting a patched vclock_gettime.c 
> > in which the switch in vdso_clock_gettime() had 6 clauses
> > instead of 5, I received in response a mail from 
> 
> 4.16-rc5 has
> 
> ifdef CONFIG_RETPOLINE
> ifneq ($(RETPOLINE_CFLAGS),)
>   KBUILD_CFLAGS += $(RETPOLINE_CFLAGS) -DRETPOLINE
> endif
> endif
> 
> vDSO isn't compiled with $(KBUILD_CFLAGS).  Why does your kernel do it?
> 

Please try my kernel patch at comment 4.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 43685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43685=edit
Kernel patch for 4.16-rc5

[Bug c++/84360] unnecessary aka in error message

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/84917] Verbosity when dealing with nested template data structures

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/84917] New: Verbosity when dealing with nested template data structures

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84917
   Summary: Verbosity when dealing with nested template data
structures
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvsa8dw/
Reddit user "rifeid" reports excess verbosity...

> [...] when dealing with nested template data structures. For example,

#include 
#include 
using vec = std::vector;
void blah() {
vec x;
x.foo();
}

> results in

test.cpp: In function ‘void blah()’:
test.cpp:6:4: error: ‘using vec = class
std::vector {aka class
std::vector}’ has no member named ‘foo’
  x.foo();
^~~

> My issues with this:
>
> It may look better if the error: line just uses vec, and
> have the full expansion relegated to a note: line. Not sure.
>
> The expansion is printed twice.
>
> As std::string is part of the C++ standard, I'd prefer it unexpanded.

Confirmed on godbolt.org.

I think parts of these are a dup (maybe of PR c++/84360) but it seems worth
capturing here and fixing.

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
...and according to:
https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvspoet/
the rust developers took ideas on diagnostics-printing from Elm.  

Note to self: need to look at Elm.

[Bug c++/84789] [6/7/8 Regression] ICE with broken variable declaration in template class

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Alexandre Oliva  ---
Patch posted, unchanged
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00823.html

[Bug c++/84916] Tweaks to template type elision

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Or just textual length? (perhaps with a param)?

[Bug c++/84916] Tweaks to template type elision

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/84916] New: Tweaks to template type elision

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84916
   Summary: Tweaks to template type elision
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrdyhv/
Reddit user "Liorithiel" pointed out:

> Have you considered performing elision conditionally on the length on the
> elided part? I see the benefits of changing, let say,

   std::map, std::string>

> into

   std::map<[...], std::string>,

> but for me,

  std::map

> is clearer than

  std::map<[...], int>.

(see the other comments downthread from thread).

I'm filing this reminder to take a look at tweaking this for gcc 9.

Maybe only elide common items if there's "more than one thing" e.g. if it's a
template itself, or is multiple args?

[PR c++/84789] do not resolve typename into template-independent

[Alexandre Oliva]

resolve_typename_type may peek into template types that might still be
specialized.  In some cases, e.g. g++.dg/template/friend48.C or
g++.dg/template/decl2.C, that is exactly the right thing to do.  In
others, like the newly-added testcase g++.dg/template/pr84789.C, it
isn't, and if the qualifying scope happens to resolve to a non-template
type, we resolve to that and then fail the assert that checks we still
have a template-dependent scope.

It appears to me that, in cases in which the assert would fail, we are
missing the typename keyword, and we ought to report an error; if we
just return the incoming type unchanged, that's exactly what we get.
So, I'm turning such failed asserts into early returns, so that the
parser can recover and report an error.

Regstrapped on i686- and x86_64-linux-gnu.  Ok to install?


for  gcc/cp/ChangeLog

PR c++/84789
* pt.c (resolve_typename_type): Keep the type
template-dependent.

for  gcc/testsuite/ChangeLog

PR c++/84789
* g++.dg/template/pr84789.C: New.
---
 gcc/cp/pt.c |   19 +--
 gcc/testsuite/g++.dg/template/pr84789.C |   13 +
 2 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/pr84789.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 89024c10fe2b..067221fa78ea 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25195,8 +25195,23 @@ resolve_typename_type (tree type, bool only_current_p)
 /* scope is either the template itself or a compatible instantiation
like X, so look up the name in the original template.  */
 scope = CLASSTYPE_PRIMARY_TEMPLATE_TYPE (scope);
-  /* We shouldn't have built a TYPENAME_TYPE with a non-dependent scope.  */
-  gcc_checking_assert (uses_template_parms (scope));
+  /* We shouldn't have built a TYPENAME_TYPE with a non-dependent
+ scope.  However, it might be a dependent scope that's being
+ resolved to a non-dependent scope just because we're looking up
+ scopes we shouldn't, e.g.
+
+   template  class B { typedef int I; };
+   template  class C : B { B::I i; };
+
+ We need 'typename' before C::i's type, because we can't enter
+ the scope of B for an unbound template parameter T to tell I
+ identifies a type (that's why we need typename), but the parser
+ attempts to do so, presumably so that it can produce better error
+ messages.  However, we'd skip necessary errors if we resolved a
+ template-dependent type to a template-independent one, so don't
+ do that.  */
+  if (!uses_template_parms (scope))
+return type;
   /* If scope has no fields, it can't be a current instantiation.  Check this
  before currently_open_class to avoid infinite recursion (71515).  */
   if (!TYPE_FIELDS (scope))
diff --git a/gcc/testsuite/g++.dg/template/pr84789.C 
b/gcc/testsuite/g++.dg/template/pr84789.C
new file mode 100644
index ..bc1567f3fe77
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr84789.C
@@ -0,0 +1,13 @@
+// { dg-do compile }
+
+struct A
+{
+  typedef int I;
+};
+
+template struct B : A {};
+
+template struct C : B
+{
+  B::A::I::I i; // { dg-error "typename" }
+};


-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

[PATCH 2/3] Add htdocs/ansi2html.css

[David Malcolm]

Generated by:

  ansi2html.sh --css-only --bg=dark --palette=xterm
---
 htdocs/ansi2html.css | 287 +++
 1 file changed, 287 insertions(+)
 create mode 100644 htdocs/ansi2html.css

diff --git a/htdocs/ansi2html.css b/htdocs/ansi2html.css
new file mode 100644
index 000..3401288
--- /dev/null
+++ b/htdocs/ansi2html.css
@@ -0,0 +1,287 @@
+.ef0,.f0 { color: #00; } .eb0,.b0 { background-color: #00; }
+.ef1,.f1 { color: #CD; } .eb1,.b1 { background-color: #CD; }
+.ef2,.f2 { color: #00CD00; } .eb2,.b2 { background-color: #00CD00; }
+.ef3,.f3 { color: #CDCD00; } .eb3,.b3 { background-color: #CDCD00; }
+.ef4,.f4 { color: #EE; } .eb4,.b4 { background-color: #EE; }
+.ef5,.f5 { color: #CD00CD; } .eb5,.b5 { background-color: #CD00CD; }
+.ef6,.f6 { color: #00CDCD; } .eb6,.b6 { background-color: #00CDCD; }
+.ef7,.f7 { color: #E5E5E5; } .eb7,.b7 { background-color: #E5E5E5; }
+.ef8, .f0 > .bold,.bold > .f0 { color: #7F7F7F; font-weight: normal; }
+.ef9, .f1 > .bold,.bold > .f1 { color: #FF; font-weight: normal; }
+.ef10,.f2 > .bold,.bold > .f2 { color: #00FF00; font-weight: normal; }
+.ef11,.f3 > .bold,.bold > .f3 { color: #00; font-weight: normal; }
+.ef12,.f4 > .bold,.bold > .f4 { color: #5C5CFF; font-weight: normal; }
+.ef13,.f5 > .bold,.bold > .f5 { color: #FF00FF; font-weight: normal; }
+.ef14,.f6 > .bold,.bold > .f6 { color: #00; font-weight: normal; }
+.ef15,.f7 > .bold,.bold > .f7 { color: #FF; font-weight: normal; }
+.eb8  { background-color: #7F7F7F; }
+.eb9  { background-color: #FF; }
+.eb10 { background-color: #00FF00; }
+.eb11 { background-color: #00; }
+.eb12 { background-color: #5C5CFF; }
+.eb13 { background-color: #FF00FF; }
+.eb14 { background-color: #00; }
+.eb15 { background-color: #FF; }
+.ef16 { color: #00; } .eb16 { background-color: #00; }
+.ef17 { color: #5f; } .eb17 { background-color: #5f; }
+.ef18 { color: #87; } .eb18 { background-color: #87; }
+.ef19 { color: #af; } .eb19 { background-color: #af; }
+.ef20 { color: #d7; } .eb20 { background-color: #d7; }
+.ef21 { color: #ff; } .eb21 { background-color: #ff; }
+.ef22 { color: #005f00; } .eb22 { background-color: #005f00; }
+.ef23 { color: #005f5f; } .eb23 { background-color: #005f5f; }
+.ef24 { color: #005f87; } .eb24 { background-color: #005f87; }
+.ef25 { color: #005faf; } .eb25 { background-color: #005faf; }
+.ef26 { color: #005fd7; } .eb26 { background-color: #005fd7; }
+.ef27 { color: #005fff; } .eb27 { background-color: #005fff; }
+.ef28 { color: #008700; } .eb28 { background-color: #008700; }
+.ef29 { color: #00875f; } .eb29 { background-color: #00875f; }
+.ef30 { color: #008787; } .eb30 { background-color: #008787; }
+.ef31 { color: #0087af; } .eb31 { background-color: #0087af; }
+.ef32 { color: #0087d7; } .eb32 { background-color: #0087d7; }
+.ef33 { color: #0087ff; } .eb33 { background-color: #0087ff; }
+.ef34 { color: #00af00; } .eb34 { background-color: #00af00; }
+.ef35 { color: #00af5f; } .eb35 { background-color: #00af5f; }
+.ef36 { color: #00af87; } .eb36 { background-color: #00af87; }
+.ef37 { color: #00afaf; } .eb37 { background-color: #00afaf; }
+.ef38 { color: #00afd7; } .eb38 { background-color: #00afd7; }
+.ef39 { color: #00afff; } .eb39 { background-color: #00afff; }
+.ef40 { color: #00d700; } .eb40 { background-color: #00d700; }
+.ef41 { color: #00d75f; } .eb41 { background-color: #00d75f; }
+.ef42 { color: #00d787; } .eb42 { background-color: #00d787; }
+.ef43 { color: #00d7af; } .eb43 { background-color: #00d7af; }
+.ef44 { color: #00d7d7; } .eb44 { background-color: #00d7d7; }
+.ef45 { color: #00d7ff; } .eb45 { background-color: #00d7ff; }
+.ef46 { color: #00ff00; } .eb46 { background-color: #00ff00; }
+.ef47 { color: #00ff5f; } .eb47 { background-color: #00ff5f; }
+.ef48 { color: #00ff87; } .eb48 { background-color: #00ff87; }
+.ef49 { color: #00ffaf; } .eb49 { background-color: #00ffaf; }
+.ef50 { color: #00ffd7; } .eb50 { background-color: #00ffd7; }
+.ef51 { color: #00; } .eb51 { background-color: #00; }
+.ef52 { color: #5f; } .eb52 { background-color: #5f; }
+.ef53 { color: #5f005f; } .eb53 { background-color: #5f005f; }
+.ef54 { color: #5f0087; } .eb54 { background-color: #5f0087; }
+.ef55 { color: #5f00af; } .eb55 { background-color: #5f00af; }
+.ef56 { color: #5f00d7; } .eb56 { background-color: #5f00d7; }
+.ef57 { color: #5f00ff; } .eb57 { background-color: #5f00ff; }
+.ef58 { color: #5f5f00; } .eb58 { background-color: #5f5f00; }
+.ef59 { color: #5f5f5f; } .eb59 { background-color: #5f5f5f; }
+.ef60 { color: #5f5f87; } .eb60 { background-color: #5f5f87; }
+.ef61 { color: #5f5faf; } .eb61 { background-color: #5f5faf; }
+.ef62 { color: #5f5fd7; } .eb62 { background-color: #5f5fd7; }
+.ef63 { color: #5f5fff; } .eb63 { background-color: #5f5fff; }
+.ef64 { color: #5f8700; } .eb64 { background-color: #5f8700; }
+.ef65 { color: #5f875f; } .eb65 { 

[PATCH 1/3] bin: add ansi2html.sh

[David Malcolm]

---
 bin/ansi2html.sh | 520 +++
 1 file changed, 520 insertions(+)
 create mode 100755 bin/ansi2html.sh

diff --git a/bin/ansi2html.sh b/bin/ansi2html.sh
new file mode 100755
index 000..ae83a78
--- /dev/null
+++ b/bin/ansi2html.sh
@@ -0,0 +1,520 @@
+#!/bin/sh
+
+# Convert ANSI (terminal) colours and attributes to HTML
+
+# Licence: LGPLv2
+# Author:
+#http://www.pixelbeat.org/docs/terminal_colours/
+# Examples:
+#ls -l --color=always | ansi2html.sh > ls.html
+#git show --color | ansi2html.sh > last_change.html
+#Generally one can use the `script` util to capture full terminal output.
+# Changes:
+#V0.1, 24 Apr 2008, Initial release
+#V0.2, 01 Jan 2009, Phil Harnish 
+# Support `git diff --color` output by
+# matching ANSI codes that specify only
+# bold or background colour.
+#   p...@draigbrady.com
+# Support `ls --color` output by stripping
+# redundant leading 0s from ANSI codes.
+# Support `grep --color=always` by stripping
+# unhandled ANSI codes (specifically ^[[K).
+#V0.3, 20 Mar 2009, http://eexpress.blog.ubuntu.org.cn/
+# Remove cat -v usage which mangled non ascii input.
+# Cleanup regular expressions used.
+# Support other attributes like reverse, ...
+#   p...@draigbrady.com
+# Correctly nest  tags (even across lines).
+# Add a command line option to use a dark background.
+# Strip more terminal control codes.
+#V0.4, 17 Sep 2009, p...@draigbrady.com
+# Handle codes with combined attributes and color.
+# Handle isolated  attributes with css.
+# Strip more terminal control codes.
+#V0.24, 14 Sep 2017
+#  http://github.com/pixelb/scripts/commits/master/scripts/ansi2html.sh
+
+gawk --version >/dev/null || exit 1
+
+if [ "$1" = "--version" ]; then
+printf '0.23\n' && exit
+fi
+
+usage()
+{
+printf '%s\n' \
+'This utility converts ANSI codes in data passed to stdin
+It has 4 optional parameters:
+--bg=dark --palette=linux|solarized|tango|xterm --css-only|--body-only
+E.g.: ls -l --color=always | ansi2html.sh --bg=dark > ls.html' >&2
+exit
+}
+
+if [ "$1" = "--help" ]; then
+usage
+fi
+
+processArg()
+{
+[ "$1" = "--bg=dark" ] && { dark_bg=yes; return; }
+[ "$1" = "--css-only" ] && { css_only=yes; return; }
+[ "$1" = "--body-only" ] && { body_only=yes; return; }
+if [ "$1" = "--palette=solarized" ]; then
+   # See http://ethanschoonover.com/solarized
+   P0=073642;  P1=D30102;  P2=859900;  P3=B58900;
+   P4=268BD2;  P5=D33682;  P6=2AA198;  P7=EEE8D5;
+   P8=002B36;  P9=CB4B16; P10=586E75; P11=657B83;
+  P12=839496; P13=6C71C4; P14=93A1A1; P15=FDF6E3;
+  return;
+elif [ "$1" = "--palette=solarized-xterm" ]; then
+   # Above mapped onto the xterm 256 color palette
+   P0=262626;  P1=AF;  P2=5F8700;  P3=AF8700;
+   P4=0087FF;  P5=AF005F;  P6=00AFAF;  P7=E4E4E4;
+   P8=1C1C1C;  P9=D75F00; P10=585858; P11=626262;
+  P12=808080; P13=5F5FAF; P14=8A8A8A; P15=D7;
+  return;
+elif [ "$1" = "--palette=tango" ]; then
+   # Gnome default
+   P0=00;  P1=CC;  P2=4E9A06;  P3=C4A000;
+   P4=3465A4;  P5=75507B;  P6=06989A;  P7=D3D7CF;
+   P8=555753;  P9=EF2929; P10=8AE234; P11=FCE94F;
+  P12=729FCF; P13=AD7FA8; P14=34E2E2; P15=EC;
+  return;
+elif [ "$1" = "--palette=xterm" ]; then
+   P0=00;  P1=CD;  P2=00CD00;  P3=CDCD00;
+   P4=EE;  P5=CD00CD;  P6=00CDCD;  P7=E5E5E5;
+   P8=7F7F7F;  P9=FF; P10=00FF00; P11=00;
+  P12=5C5CFF; P13=FF00FF; P14=00; P15=FF;
+  return;
+else # linux console
+   P0=00;  P1=AA;  P2=00AA00;  P3=AA5500;
+   P4=AA;  P5=AA00AA;  P6=00;  P7=AA;
+   P8=55;  P9=FF; P10=55FF55; P11=55;
+  P12=FF; P13=FF55FF; P14=55; P15=FF;
+  [ "$1" = "--palette=linux" ] && return;
+fi
+}
+
+processArg #defaults
+for var in "$@"; do processArg $var; done
+[ "$css_only" ] && [ "$body_only" ] && usage
+
+# Mac OSX's GNU sed is installed as gsed
+# use e.g. homebrew 'gnu-sed' to get it
+if ! sed --version >/dev/null 2>&1; then
+  if gsed --version >/dev/null 2>&1; then
+alias sed=gsed
+  else
+echo "Error, can't find an acceptable GNU sed." >&2
+exit 1
+  fi
+fi
+
+[ "$css_only" ] || [ "$body_only" ] || printf '%s' "
+
+
+
+"
+[ "$body_only" ] || printf ".ef0,.f0 { color: #$P0; } .eb0,.b0 { 
background-color: #$P0; }
+.ef1,.f1 { color: #$P1; } .eb1,.b1 { background-color: #$P1; }
+.ef2,.f2 { color: #$P2; } .eb2,.b2 { 

[PATCH 0/3] wwwdocs: Updates for gcc 8 changes

[David Malcolm]

This patch kit is for the website; I generated it against a local
git mirror of the CVS repo.

It adds lots of examples of colorized output from GCC, which
I generated using ansi2html.sh, an LGPLv2 script for turning ANSI
color codes into HTML spans.  It also emits a .css file for mapping
the span classes into HTML colorization.

OK for the website?  (Note the caveats in patch 3)

Thanks

David Malcolm (3):
  bin: add ansi2html.sh
  Add htdocs/ansi2html.css
  Document my gcc 8 changes for the website

 bin/ansi2html.sh  | 520 ++
 htdocs/ansi2html.css  | 287 +
 htdocs/gcc-8/changes.html | 264 ++-
 3 files changed, 1070 insertions(+), 1 deletion(-)
 create mode 100755 bin/ansi2html.sh
 create mode 100644 htdocs/ansi2html.css

-- 
1.8.5.3

[PATCH 3/3] Document my gcc 8 changes for the website

[David Malcolm]

This patch documents various improvements in GCC 8 for our website.

There are lots of examples of colorized output from GCC (generated
using ansi2html); the patch uses the ansi2html.css from the previous
patch for styling them.

Caveat: I don't have the toolchain working for building the site, so
I was only able to test the CSS by manually hacking the  during
testing.  The patch adds the CSS there.  I hope this works.

Successfully checked as XHTML 1.0 Transitional.
---
 htdocs/gcc-8/changes.html | 264 +-
 1 file changed, 263 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html
index 7b76e34..122d02d 100644
--- a/htdocs/gcc-8/changes.html
+++ b/htdocs/gcc-8/changes.html
@@ -1,6 +1,7 @@
 
 
 
+
 GCC 8 Release Series  Changes, New Features, and Fixes
 
 
@@ -120,11 +121,243 @@ a work-in-progress.
  default at all optimization levels.  Using
  -fsanitize=signed-integer-overflow is now the preferred
  way to audit code, -Wstrict-overflow is deprecated.
+When reporting mismatching argument types at a function call, the
+  C and C++ compilers now underline both the argument and the pertinent
+  parameter in the declaration.
+
+$ gcc arg-type-mismatch.cc
+arg-type-mismatch.cc: In function 'int caller(int, int, float)':
+arg-type-mismatch.cc:5:24: error: invalid conversion from 'int' to 'const char*' [-fpermissive]
+   return callee(first, second, third);
+^~
+arg-type-mismatch.cc:1:40: note:   initializing argument 2 of 'int callee(int, const char*, float)'
+ extern int callee(int one, const char 
*two, float three);
+^~~
+
+
+
+When reporting on unrecognized identifiers, the C and C++ compilers
+  will now emit fix-it hints suggesting #include directives
+  for various headers in the C and C++ standard libraries.
+
+$ gcc incomplete.c
+incomplete.c: In function 'test':
+incomplete.c:3:10: error: 'NULL' undeclared 
(first use in this function)
+   return NULL;
+  ^~~~
+incomplete.c:3:10: note: 'NULL' is defined in 
header 'stddef.h'; did you forget to '#include stddef.h'?
+incomplete.c:1:1:
++#include stddef.h
+ const char *test(void)
+incomplete.c:3:10:
+   return NULL;
+  ^~~~
+incomplete.c:3:10: note: each undeclared identifier is reported only once 
for each function it appears in
+
+
+
+$ gcc incomplete.cc
+incomplete.cc:1:6: error: 'string' in namespace 
'std' does not name a type
+ std::string s(hello 
world);
+  ^~
+incomplete.cc:1:1: note: 'std::string' is 
defined in header 'string'; did you forget to 
'#include string'?
++#include string
+ std::string s(hello 
world);
+ ^~~
+
+
+
+The C and C++ compilers now use more intuitive locations when
+  reporting on missing semicolons, and offer fix-it hints:
+
+$ gcc t.c
+t.c: In function 'test':
+t.c:3:12: error: 
expected ';' before '}' token
+   return 42
+^
+;
+ }
+ ~
+
+
+
+When reporting on missing '}' and ')' tokens, the C and C++
+  compilers will now highlight the corresponding '{' and '(' token,
+  issuing a 'note' if it's on a separate line:
+
+$ gcc unclosed.c
+unclosed.c: In function 'log_when_out_of_range':
+unclosed.c:12:50: error: expected ')' before 
'{' token
+(temperature  MIN || temperature  MAX) {
+  ^~
+  )
+unclosed.c:11:6: note: to match this '('
+   if (logging_enabled 
 check_range ()
+  ^
+
+  or highlighting it directly if it's on the same line:
+
+$ gcc unclosed-2.c
+unclosed-2.c: In function 'test':
+unclosed-2.c:8:45: error: expected ')' before 
'{' token
+   if (temperature  MIN || temperature  
MAX {
+  ~  ^~
+ )
+
+  They will also emit fix-it hints.
+
 
 
 C++
 
-  
+  When reporting on attempts to access private fields of a class or
+struct, the C++ compiler will now offer fix-it hints showing how to
+use an accessor function to get at the field in question, if one exists.
+
+$ gcc accessor.cc
+accessor.cc: In function 'void 
test(foo*)':
+accessor.cc:12:12: error: 'double foo::m_ratio' 
is private within this context
+   if (ptr-m_ratio = 
0.5)
+^~~
+accessor.cc:7:10: note: declared private here
+   double m_ratio;
+  ^~~
+accessor.cc:12:12: note: field 'double 
foo::m_ratio' can be accessed via 'double 
foo::get_ratio() const'
+   if (ptr-m_ratio = 
0.5)
+^~~
+get_ratio()
+
+
+  
+  The C++ compiler can now give you a hint if you use a macro before it
+was defined (e.g. if you mess up the order of your #include
+directives):
+
+$ gcc ordering.cc
+ordering.cc:2:24: error: expected ';' at end 
of member declaration
+   virtual void clone() const OVERRIDE { }
+   

[Bug target/84899] [6/7/8 Regression] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)

[jakub at gcc dot gnu.org]

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

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

[Bug target/84899] [6/7/8 Regression] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 16 21:01:16 2018
New Revision: 258610

URL: https://gcc.gnu.org/viewcvs?rev=258610=gcc=rev
Log:
PR target/84899
* postreload.c (reload_combine_recognize_pattern): Perform
INTVAL addition in unsigned HOST_WIDE_INT type to avoid UB and
truncate_int_for_mode the result for the destination's mode.

* gcc.dg/pr84899.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr84899.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed by Vlad's commit on the trunk.

Re: [PATCH] Fix postreload constant merging (PR target/84899)

[Jeff Law]

On 03/16/2018 02:17 PM, Jakub Jelinek wrote:
> Hi!
> 
> The following testcase ICEs on powerpc-linux, because we merge
> SImode constants 0x7fff and 1 into 0x8000, which is not valid SImode
> CONST_INT - -0x8000 is.  Fixed by calling trunc_int_for_mode, and to
> avoid UB in the compiler do the addition in unsigned type.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux and tested on the
> testcase with powerpc64-linux cross with -m32, ok for trunk?
> 
> 2018-03-16  Jakub Jelinek  
> 
>   PR target/84899
>   * postreload.c (reload_combine_recognize_pattern): Perform
>   INTVAL addition in unsigned HOST_WIDE_INT type to avoid UB and
>   truncate_int_for_mode the result for the destination's mode.
> 
>   * gcc.dg/pr84899.c: New test.
OK.
jeff

Re: [PATCH] Fix PR84873

[Jakub Jelinek]

On Fri, Mar 16, 2018 at 12:53:29PM +0100, Richard Biener wrote:
> > An alternative slightly more expensive patch is the following which
> > I'm now testing on x86_64-unknown-linux-gnu, the above testcase
> > is fixed with it (verified with a cross).
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?
> 
> > 2018-03-16  Richard Biener  
> > 
> > PR c/84873
> > * c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
> > unshare the possibly folded expression.
> > 
> > + /* Make sure to unshare the result, tree sharing is invalid
> > +during gimplification.  */
> > + *op1_p = unshare_expr (convert (unsigned_type_node, *op1_p));

Ok, thanks.

Jakub

[PATCH] Fix x86 -march/-mtune after recent icelake-* split (PR target/84902)

[Jakub Jelinek]

Hi!

We now have more than 32 enumerators in enum processor_type (well, we had
33 already before the icelake-* split, but the last one isn't really used),
and while all the m_* macros were changed tom 1U<

PR target/84902
* config/i386/i386.c (initial_ix86_tune_features,
initial_ix86_arch_features): Use unsigned HOST_WIDE_INT rather than
unsigned long long.
(set_ix86_tune_features): Change ix86_tune_mask from unsigned int
to unsigned HOST_WIDE_INT, initialize to HOST_WIDE_INT_1U << ix86_tune
rather than 1u << ix86_tune.  Formatting fix.
(ix86_option_override_internal): Change ix86_arch_mask from
unsigned int to unsigned HOST_WIDE_INT, initialize to
HOST_WIDE_INT_1U << ix86_arch rather than 1u << ix86_arch.
(ix86_function_specific_restore): Likewise.

--- gcc/config/i386/i386.c.jj   2018-03-15 22:07:57.964242564 +0100
+++ gcc/config/i386/i386.c  2018-03-16 18:35:53.621105345 +0100
@@ -183,7 +183,7 @@ unsigned char ix86_tune_features[X86_TUN
 
 /* Feature tests against the various tunings used to create ix86_tune_features
based on the processor mask.  */
-static unsigned long long initial_ix86_tune_features[X86_TUNE_LAST] = {
+static unsigned HOST_WIDE_INT initial_ix86_tune_features[X86_TUNE_LAST] = {
 #undef DEF_TUNE
 #define DEF_TUNE(tune, name, selector) selector,
 #include "x86-tune.def"
@@ -195,7 +195,7 @@ unsigned char ix86_arch_features[X86_ARC
 
 /* Feature tests against the various architecture variations, used to create
ix86_arch_features based on the processor mask.  */
-static unsigned long long initial_ix86_arch_features[X86_ARCH_LAST] = {
+static unsigned HOST_WIDE_INT initial_ix86_arch_features[X86_ARCH_LAST] = {
   /* X86_ARCH_CMOV: Conditional move was added for pentiumpro.  */
   ~(m_386 | m_486 | m_PENT | m_LAKEMONT | m_K6),
 
@@ -3310,7 +3310,7 @@ parse_mtune_ctrl_str (bool dump)
 static void
 set_ix86_tune_features (enum processor_type ix86_tune, bool dump)
 {
-  unsigned int ix86_tune_mask = 1u << ix86_tune;
+  unsigned HOST_WIDE_INT ix86_tune_mask = HOST_WIDE_INT_1U << ix86_tune;
   int i;
 
   for (i = 0; i < X86_TUNE_LAST; ++i)
@@ -3318,7 +3318,8 @@ set_ix86_tune_features (enum processor_t
   if (ix86_tune_no_default)
 ix86_tune_features[i] = 0;
   else
-ix86_tune_features[i] = !!(initial_ix86_tune_features[i] & 
ix86_tune_mask);
+   ix86_tune_features[i]
+ = !!(initial_ix86_tune_features[i] & ix86_tune_mask);
 }
 
   if (dump)
@@ -3373,7 +3374,7 @@ ix86_option_override_internal (bool main
   struct gcc_options *opts_set)
 {
   int i;
-  unsigned int ix86_arch_mask;
+  unsigned HOST_WIDE_INT ix86_arch_mask;
   const bool ix86_tune_specified = (opts->x_ix86_tune_string != NULL);
 
   const wide_int_bitmask PTA_3DNOW (HOST_WIDE_INT_1U << 0);
@@ -4234,7 +4235,7 @@ ix86_option_override_internal (bool main
   XDELETEVEC (s);
 }
 
-  ix86_arch_mask = 1u << ix86_arch;
+  ix86_arch_mask = HOST_WIDE_INT_1U << ix86_arch;
   for (i = 0; i < X86_ARCH_LAST; ++i)
 ix86_arch_features[i] = !!(initial_ix86_arch_features[i] & ix86_arch_mask);
 
@@ -5159,7 +5160,7 @@ ix86_function_specific_restore (struct g
 {
   enum processor_type old_tune = ix86_tune;
   enum processor_type old_arch = ix86_arch;
-  unsigned int ix86_arch_mask;
+  unsigned HOST_WIDE_INT ix86_arch_mask;
   int i;
 
   /* We don't change -fPIC.  */
@@ -5210,7 +5211,7 @@ ix86_function_specific_restore (struct g
   /* Recreate the arch feature tests if the arch changed */
   if (old_arch != ix86_arch)
 {
-  ix86_arch_mask = 1u << ix86_arch;
+  ix86_arch_mask = HOST_WIDE_INT_1U << ix86_arch;
   for (i = 0; i < X86_ARCH_LAST; ++i)
ix86_arch_features[i]
  = !!(initial_ix86_arch_features[i] & ix86_arch_mask);

Jakub

[Bug c/84910] typo: "%qs follows inline declaration "

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for 8.1+.

[Bug c/84909] typo: conversion from %qT to to %qT

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for 8.1+.

[PATCH] Fix postreload constant merging (PR target/84899)

[Jakub Jelinek]

Hi!

The following testcase ICEs on powerpc-linux, because we merge
SImode constants 0x7fff and 1 into 0x8000, which is not valid SImode
CONST_INT - -0x8000 is.  Fixed by calling trunc_int_for_mode, and to
avoid UB in the compiler do the addition in unsigned type.

Bootstrapped/regtested on x86_64-linux and i686-linux and tested on the
testcase with powerpc64-linux cross with -m32, ok for trunk?

2018-03-16  Jakub Jelinek  

PR target/84899
* postreload.c (reload_combine_recognize_pattern): Perform
INTVAL addition in unsigned HOST_WIDE_INT type to avoid UB and
truncate_int_for_mode the result for the destination's mode.

* gcc.dg/pr84899.c: New test.

--- gcc/postreload.c.jj 2018-01-03 10:19:55.572534024 +0100
+++ gcc/postreload.c2018-03-16 18:19:17.819417570 +0100
@@ -1157,11 +1157,13 @@ reload_combine_recognize_pattern (rtx_in
 value in PREV, the constant loading instruction.  */
  validate_change (prev, _DEST (prev_set), index_reg, 1);
  if (reg_state[regno].offset != const0_rtx)
-   validate_change (prev,
-_SRC (prev_set),
-GEN_INT (INTVAL (SET_SRC (prev_set))
- + INTVAL (reg_state[regno].offset)),
-1);
+   {
+ HOST_WIDE_INT c
+   = trunc_int_for_mode (UINTVAL (SET_SRC (prev_set))
+ + UINTVAL (reg_state[regno].offset),
+ GET_MODE (index_reg));
+ validate_change (prev, _SRC (prev_set), GEN_INT (c), 1);
+   }
 
  /* Now for every use of REG that we have recorded, replace REG
 with REG_SUM.  */
--- gcc/testsuite/gcc.dg/pr84899.c.jj   2018-03-16 18:22:39.243512333 +0100
+++ gcc/testsuite/gcc.dg/pr84899.c  2018-03-16 18:22:22.353504390 +0100
@@ -0,0 +1,12 @@
+/* PR target/84899 */
+/* { dg-do compile } */
+/* { dg-options "-O -funroll-all-loops -fno-move-loop-invariants" } */
+
+void
+foo (int x)
+{
+  int a = 1 / x, b = 0;
+
+  while ((a + b + 1) < x)
+b = __INT_MAX__;
+}

Jakub

[committed] Fix "to to" -> "to" in diagnostics and comments (PR c/84909)

[Jakub Jelinek]

Hi!

Duplicated word in diagnostics and the same issues in 3 comments.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.

2018-03-16  Jakub Jelinek  

PR c/84909
* c-warn.c (conversion_warning): Replace "to to" with "to" in
diagnostics.

* hsa-gen.c (mem_type_for_type): Fix comment typo.
* tree-vect-loop-manip.c (vect_create_cond_for_niters_checks):
Likewise.
* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
Likewise.

--- gcc/c-family/c-warn.c.jj2018-03-16 17:36:31.431124231 +0100
+++ gcc/c-family/c-warn.c   2018-03-16 17:44:34.905341083 +0100
@@ -1138,8 +1138,7 @@ conversion_warning (location_t loc, tree
   conversion_kind = unsafe_conversion_p (loc, type, expr, result, true);
   if (conversion_kind == UNSAFE_IMAGINARY)
warning_at (loc, OPT_Wconversion,
-   "conversion from %qT to to %qT discards imaginary "
-   "component",
+   "conversion from %qT to %qT discards imaginary component",
expr_type, type);
   else
{
--- gcc/hsa-gen.c.jj2018-02-09 06:44:38.421804424 +0100
+++ gcc/hsa-gen.c   2018-03-16 17:46:00.981383468 +0100
@@ -691,7 +691,7 @@ mem_type_for_type (BrigType16_t type)
   /* HSA has non-intuitive constraints on load/store types.  If it's
  a bit-type it _must_ be B128, if it's not a bit-type it must be
  64bit max.  So for loading entities of 128 bits (e.g. vectors)
- we have to to B128, while for loading the rest we have to use the
+ we have to use B128, while for loading the rest we have to use the
  input type (??? or maybe also flattened to a equally sized non-vector
  unsigned type?).  */
   if ((type & BRIG_TYPE_PACK_MASK) == BRIG_TYPE_PACK_128)
--- gcc/tree-vect-loop-manip.c.jj   2018-03-13 21:32:00.976647708 +0100
+++ gcc/tree-vect-loop-manip.c  2018-03-16 17:46:21.065393353 +0100
@@ -2700,7 +2700,7 @@ vect_do_peeling (loop_vec_info loop_vinf
 /* Function vect_create_cond_for_niters_checks.
 
Create a conditional expression that represents the run-time checks for
-   loop's niter.  The loop is guaranteed to to terminate if the run-time
+   loop's niter.  The loop is guaranteed to terminate if the run-time
checks hold.
 
Input:
--- gcc/gimple-ssa-warn-restrict.c.jj   2018-03-09 20:11:55.135835711 +0100
+++ gcc/gimple-ssa-warn-restrict.c  2018-03-16 17:45:03.983355395 +0100
@@ -417,7 +417,7 @@ builtin_memref::set_base_and_offset (tre
 
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
 
-  /* Convert the poly_int64 offset to to offset_int.  The offset
+  /* Convert the poly_int64 offset to offset_int.  The offset
  should be constant but be prepared for it not to be just in
  case.  */
   offset_int cstoff;

Jakub

[Bug c/84909] typo: conversion from %qT to to %qT

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 16 20:12:27 2018
New Revision: 258609

URL: https://gcc.gnu.org/viewcvs?rev=258609=gcc=rev
Log:
PR c/84909
* c-warn.c (conversion_warning): Replace "to to" with "to" in
diagnostics.

* hsa-gen.c (mem_type_for_type): Fix comment typo.
* tree-vect-loop-manip.c (vect_create_cond_for_niters_checks):
Likewise.
* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/hsa-gen.c
trunk/gcc/tree-vect-loop-manip.c

[Bug c/84915] New: documentation: __FUNCTION__ is said by gcc-6 info to be a preprocessor macro

[galex-...@galex-713.eu]

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

Bug ID: 84915
   Summary: documentation: __FUNCTION__ is said by gcc-6 info to
be a preprocessor macro
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: galex-...@galex-713.eu
  Target Milestone: ---

(info "(gcc-6) Other Builtins") says __FUNCTION__ is a preprocessor macro,
however, cpp info says it’s not. Am I missing something? do most cpp
implementation parse C code and implement it as a macro so gcc claims it is
while itself interprets it as not being one?

Look by yourselves:

 -- Built-in Function: const char * __builtin_FUNCTION ()
 This function is the equivalent to the preprocessor '__FUNCTION__'
 macro and returns the function name the invocation of the built-in
 is in.

It is not a bug of gcc but rather of its documentation, I don’t know if here is
the right place to ask…

[Bug c/84910] typo: "%qs follows inline declaration "

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 16 20:11:40 2018
New Revision: 258608

URL: https://gcc.gnu.org/viewcvs?rev=258608=gcc=rev
Log:
PR c/84910
* c-warn.c (diagnose_mismatched_attributes): Remove trailing space from
diagnostics.

* parser.c (cp_parser_lambda_introducer): Remove trailing space from
diagnostics.
* method.c (synthesize_method): Likewise.
* pt.c (convert_nontype_argument): Likewise.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
It requires TARGET_POWERPC64 (not TARGET_64BIT).

[Bug c/84890] Overly verbose notes for missing headers

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
(In reply to Eric Gallager from comment #2)
> (In reply to David Malcolm from comment #0)
> > 
> > Reddit user "ramennoodle" comments:
[...]
> ...link for this one?
https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvr6psr/

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to Eric Gallager from comment #3)
> Link for this next one though?
https://news.ycombinator.com/item?id=16598074

[Bug other/84889] Ideas on revamping how we format diagnostics

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Thanks for these links:

(In reply to David Malcolm from comment #0)
> Quoting an example from:
>  
> https://stackoverflow.com/questions/44003622/implementing-trait-for-
> fnsomething-in-rust

(In reply to David Malcolm from comment #1)
> Example of Rust error (showing colorization):
>   https://i.redd.it/qm4oceuuckyy.png

Link for this next one though?

(In reply to David Malcolm from comment #2)
> Hacker News user "earenndil" suggested:
> 
> > What about a line of ─ in between different unassociated errors?
> > So if there is a group of related errors that are about the same actual
> > problem, or a note associated with an error, they're together, but then
> > there's a line of coloured ─ separating them from the next set.

[Committed] PR fortran/69395 -- Correct error condition

[Steve Kargl]

The following patch fixes essentially and off-by-one
in the error condition.  Committed as obvious.

2018-03-16  Steven G. Kargl  

PR fortran/69395
* decl.c (merge_array_spec): Correct the error condition.

2018-03-16  Steven G. Kargl  

PR fortran/69395
* gfortran.dg/pr69395.f90: Add test for max dimensions

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 258581)
+++ gcc/fortran/decl.c  (working copy)
@@ -871,7 +871,7 @@ merge_array_spec (gfc_array_spec *from, gfc_array_spec
}
 }
 
-  if (to->rank + to->corank >= GFC_MAX_DIMENSIONS)
+  if (to->rank + to->corank > GFC_MAX_DIMENSIONS)
 {
   gfc_error ("Sum of array rank %d and corank %d at %C exceeds maximum "
 "allowed dimensions of %d",
Index: gcc/testsuite/gfortran.dg/pr69395.f90
===
--- gcc/testsuite/gfortran.dg/pr69395.f90   (revision 258580)
+++ gcc/testsuite/gfortran.dg/pr69395.f90   (working copy)
@@ -1,5 +1,6 @@
 ! { dg-do compile }
 ! { dg-options "-fcoarray=single" }
 program p
+real, dimension(1,2,1,2,1,2,1,2), codimension[1,2,1,2,1,2,*] :: y
 real, dimension(1,2,1,2,1,2,1,2), codimension[1,2,1,2,1,2,1,*] :: z  ! { 
dg-error "allowed dimensions" }
 end

-- 
Steve

[Bug c/84890] Overly verbose notes for missing headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #1)
> Hacker News user "dmckeon" commented:
>   https://news.ycombinator.com/item?id=16603185
> 

Thanks for including this link, but:

(In reply to David Malcolm from comment #0)
> 
> Reddit user "ramennoodle" comments:
> 
> > This seems redundantly verbose. Why not just:
> > 
> > incomplete.c:4:17: note: ‘INT_MAX’ is defined in header ‘
> > 
> > ?

...link for this one?

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Mar 16 19:20:15 2018
New Revision: 258607

URL: https://gcc.gnu.org/viewcvs?rev=258607=gcc=rev
Log:
2018-03-16  Steven G. Kargl  

PR fortran/69395
* decl.c (merge_array_spec): Correct the error condition.

2018-03-16  Steven G. Kargl  

PR fortran/69395
* gfortran.dg/pr69395.f90: Add test for max dimensions

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr69395.f90

[Bug c/84890] Overly verbose notes for missing headers

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Hacker News user "dmckeon" commented:
  https://news.ycombinator.com/item?id=16603185

> A small idea: reframe suggestions to be positive, future-looking,
> and pro-active, such as replacing:
>
>   did you forget to ‘#include ’?
> 
> with:
> 
>   do you want to ‘#include ’?
>
> or, perhaps better:
>
>   you may want to ‘#include ’.
>
> It may seem a small thing, but focusing on the solution rather
> than the problem may tend to sooth the mind of the coder, rather
> than to magnify their annoyance.

I like this.

> Consider it a path that is the opposite of Nedry's
> "You didn't say the magic word!"

Indeed.  We want the feeling that the compiler is the servant of the user, not
the other way around.

[Bug c++/71834] [6/7/8 Regression] accepts invalid C++11 code with too few number of template arguments for class template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

libgo patch committed: add missing entry to noinst_DATA

[Ian Lance Taylor]

This libgo patch adds runtime/pprof/internal/profile.gox to
noinst_DATA.  That package is only used by tests, so it needs to be in
noinst_DATA to ensure that it is built when tests are run.

It also adds noinst_DATA to CHECK_DEPS; it's not needed in practice
since `make` will build noinst_DATA, but it's logically required and
will make a difference if any of the noinst_DATA sources change
between `make` and `make check`.

As an aside,
Tony Reix figured out why omitting packages from noinst_DATA didn't
seem to matter: because if gccgo can't find foo.gox, it will fall back
to reading the export data in foo.o, and foo.o will exist because
these packages go into libgo.a.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 258565)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e4464efc767b8dee4f4c18ffaf6c891f7b9deee7
+e9c0e4d8fd3d951a367bb6a50e5cb546e01b81a8
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 258392)
+++ libgo/Makefile.am   (working copy)
@@ -399,7 +399,8 @@ noinst_DATA = \
internal/testenv.gox \
internal/trace.gox \
net/internal/socktest.gox \
-   os/signal/internal/pty.gox
+   os/signal/internal/pty.gox \
+   runtime/pprof/internal/profile.gox
 
 if LIBGO_IS_RTEMS
 rtems_task_variable_add_file = runtime/rtems-task-variable-add.c
@@ -1094,6 +1095,7 @@ CHECK_DEPS = \
$(toolexeclibgotext_DATA) \
$(toolexeclibgotexttemplate_DATA) \
$(toolexeclibgounicode_DATA) \
+   $(noinst_DATA) \
$(noinst_LIBRARIES)
 
 if GOC_IS_LLGO

[Bug c++/84906] [8 Regression] Ambiguous conversion not diagnosed, causes entire selection-statement to be omitted

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/80227] [6/7/8 Regression] SFINAE ambiguity with a pointer to array argument

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Mar 16 18:56:01 2018
New Revision: 258604

URL: https://gcc.gnu.org/viewcvs?rev=258604=gcc=rev
Log:
PR c++/80227 - SFINAE and negative array size.

* decl.c (compute_array_index_type): Use
build_converted_constant_expr and valid_constant_size_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/g++.dg/gomp/pr47963.C
trunk/gcc/testsuite/g++.dg/init/new37.C
trunk/gcc/testsuite/g++.dg/init/new44.C
trunk/gcc/testsuite/g++.dg/ubsan/pr81530.C

[Bug c++/84720] [7 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.c:3472

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Mar 16 18:56:06 2018
New Revision: 258605

URL: https://gcc.gnu.org/viewcvs?rev=258605=gcc=rev
Log:
PR c++/84720 - ICE with rvalue ref non-type argument.

* pt.c (invalid_nontype_parm_type_p): Prohibit rvalue reference.
(convert_nontype_argument): Revert earlier change.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C

[Bug c++/84906] [8 Regression] Ambiguous conversion not diagnosed, causes entire selection-statement to be omitted

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Mar 16 18:55:54 2018
New Revision: 258603

URL: https://gcc.gnu.org/viewcvs?rev=258603=gcc=rev
Log:
PR c++/84906 - silent wrong code with ambiguous conversion.

* call.c (build_user_type_conversion_1): Set need_temporary_p on
ambiguous conversion.
(convert_like_real): Check it.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

Re: C++ PATCH for c++/84720, ICE with rvalue ref template parameter

[Jason Merrill]

On Tue, Mar 13, 2018 at 2:54 PM, Jason Merrill  wrote:
> It's unclear to me that it is ever possible to instantiate a template
> taking an rvalue ref parameter, but I guess we might as well handle it
> properly.

...except that such parameters are actually ill-formed, so we should reject.
commit dea7cfdf2f1e7f17befbe3987badba9f74a6b2b9
Author: Jason Merrill 
Date:   Fri Mar 16 14:01:14 2018 -0400

PR c++/84720 - ICE with rvalue ref non-type argument.

* pt.c (invalid_nontype_parm_type_p): Prohibit rvalue reference.
(convert_nontype_argument): Revert earlier change.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 6c96424152e..f7b1b0dd9aa 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23985,7 +23985,10 @@ invalid_nontype_parm_type_p (tree type, tsubst_flags_t complain)
 {
   if (INTEGRAL_OR_ENUMERATION_TYPE_P (type))
 return false;
-  else if (POINTER_TYPE_P (type))
+  else if (TYPE_PTR_P (type))
+return false;
+  else if (TREE_CODE (type) == REFERENCE_TYPE
+	   && !TYPE_REF_IS_RVALUE (type))
 return false;
   else if (TYPE_PTRMEM_P (type))
 return false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C b/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
index b8e0daba0f7..06516dfa2b9 100644
--- a/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
@@ -1,7 +1,7 @@
 // PR c++/84720
 // { dg-do compile { target c++11 } }
 
-template
+template		// { dg-error "not a valid type" }
 struct a {
   template
   static void b() {

patch to fix PR84876

[Vladimir Makarov]

The following patch fixes

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

and another problem with LRA cycling which occurred on the same test.

The patch was successfully bootstrapped and tested on i686 and x86_64.

Committed as rev. 258602.


Index: ChangeLog
===
--- ChangeLog	(revision 258601)
+++ ChangeLog	(working copy)
@@ -1,3 +1,11 @@
+2018-03-16  Vladimir Makarov  
+
+	PR target/84876
+	* lra-assigns.c (lra_split_hard_reg_for): Don't use
+	regno_allocno_class_array and sorted_pseudos.
+	* lra-constraints.c (spill_hard_reg_in_range): Ignore hard regs in
+	insns where regno is used.
+
 2018-03-16  Martin Liska  
 
 	PR ipa/84833
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 258601)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2018-03-16  Vladimir Makarov  
+
+	PR target/84876
+	* gcc.target/i386/pr84876.c: New test.
+
 2018-03-16  Martin Liska  
 
 	PR ipa/84833
Index: lra-assigns.c
===
--- lra-assigns.c	(revision 258504)
+++ lra-assigns.c	(working copy)
@@ -1737,41 +1737,46 @@ find_reload_regno_insns (int regno, rtx_
 bool
 lra_split_hard_reg_for (void)
 {
-  int i, regno, n;
+  int i, regno;
   rtx_insn *insn, *first, *last;
   unsigned int u;
   bitmap_iterator bi;
+  enum reg_class rclass;
   int max_regno = max_reg_num ();
   /* We did not assign hard regs to reload pseudos after two
  iterations.  Either it's an asm and something is wrong with the
  constraints, or we have run out of spill registers; error out in
  either case.  */
   bool asm_p = false;
-  bitmap_head failed_reload_insns;
+  bitmap_head failed_reload_insns, failed_reload_pseudos;
   
   if (lra_dump_file != NULL)
 fprintf (lra_dump_file,
 	 "\n** Splitting a hard reg after assignment #%d: **\n\n",
 	 lra_assignment_iter);
-  for (n = 0, i = lra_constraint_new_regno_start; i < max_regno; i++)
+  bitmap_initialize (_reload_pseudos, _obstack);
+  for (i = lra_constraint_new_regno_start; i < max_regno; i++)
 if (reg_renumber[i] < 0 && lra_reg_info[i].nrefs != 0
-	&& regno_allocno_class_array[i] != NO_REGS
+	&& (rclass = lra_get_allocno_class (i)) != NO_REGS
 	&& ! bitmap_bit_p (_reload_pseudos, i))
   {
-	sorted_pseudos[n++] = i;
 	if (! find_reload_regno_insns (i, first, last))
 	  continue;
-	if (spill_hard_reg_in_range (i, regno_allocno_class_array[i],
- first, last))
-	  return true;
+	if (spill_hard_reg_in_range (i, rclass, first, last))
+	  {
+	bitmap_clear (_reload_pseudos);
+	return true;
+	  }
+	bitmap_set_bit (_reload_pseudos, i);
   }
   bitmap_initialize (_reload_insns, _obstack);
-  for (i = 0; i < n; i++)
+  EXECUTE_IF_SET_IN_BITMAP (_reload_pseudos, 0, u, bi)
 {
-  regno = sorted_pseudos[i];
+  regno = u;
   bitmap_ior_into (_reload_insns,
 		   _reg_info[regno].insn_bitmap);
-  lra_setup_reg_renumber (regno, ira_class_hard_regs[regno_allocno_class_array[regno]][0], false);
+  lra_setup_reg_renumber
+	(regno, ira_class_hard_regs[lra_get_allocno_class (regno)][0], false);
 }
   EXECUTE_IF_SET_IN_BITMAP (_reload_insns, 0, u, bi)
 {
@@ -1805,5 +1810,7 @@ lra_split_hard_reg_for (void)
 	  fatal_insn ("this is the insn:", insn);
 	}
 }
+  bitmap_clear (_reload_pseudos);
+  bitmap_clear (_reload_insns);
   return false;
 }
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 258504)
+++ lra-constraints.c	(working copy)
@@ -5680,13 +5680,30 @@ spill_hard_reg_in_range (int regno, enum
   int i, hard_regno;
   int rclass_size;
   rtx_insn *insn;
+  unsigned int uid;
+  bitmap_iterator bi;
+  HARD_REG_SET ignore;
   
   lra_assert (from != NULL && to != NULL);
+  CLEAR_HARD_REG_SET (ignore);
+  EXECUTE_IF_SET_IN_BITMAP (_reg_info[regno].insn_bitmap, 0, uid, bi)
+{
+  lra_insn_recog_data_t id = lra_insn_recog_data[uid];
+  struct lra_static_insn_data *static_id = id->insn_static_data;
+  struct lra_insn_reg *reg;
+  
+  for (reg = id->regs; reg != NULL; reg = reg->next)
+	if (reg->regno <= FIRST_PSEUDO_REGISTER)
+	  SET_HARD_REG_BIT (ignore, reg->regno);
+  for (reg = static_id->hard_regs; reg != NULL; reg = reg->next)
+	SET_HARD_REG_BIT (ignore, reg->regno);
+}
   rclass_size = ira_class_hard_regs_num[rclass];
   for (i = 0; i < rclass_size; i++)
 {
   hard_regno = ira_class_hard_regs[rclass][i];
-  if (! TEST_HARD_REG_BIT (lra_reg_info[regno].conflict_hard_regs, hard_regno))
+  if (! TEST_HARD_REG_BIT (lra_reg_info[regno].conflict_hard_regs, hard_regno)
+	  || TEST_HARD_REG_BIT (ignore, hard_regno))
 	continue;
   for (insn = from; insn != NEXT_INSN (to); insn = NEXT_INSN (insn))
 	if (bitmap_bit_p 

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Jason Vas Dias from comment #2)
> Thanks H.J. -
> 
> RE:
> > vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> > 4.16-rc5.  Why isn't it the case for you? 
> 
> All I know is ,  when submitting a patched vclock_gettime.c 
> in which the switch in vdso_clock_gettime() had 6 clauses
> instead of 5, I received in response a mail from 

4.16-rc5 has

ifdef CONFIG_RETPOLINE
ifneq ($(RETPOLINE_CFLAGS),)
  KBUILD_CFLAGS += $(RETPOLINE_CFLAGS) -DRETPOLINE
endif
endif

vDSO isn't compiled with $(KBUILD_CFLAGS).  Why does your kernel do it?

> 
> But I don't want my patch to have to depend on this being removed -
> the removal of these flags effectively removes retpoline support, no ?
> It is a shame to have to do that after it was carefully added.
> 
> My gripe is really that nothing in GCC should work with a switch
> with < 6 clauses, and fail with a switch with >= 6 clauses.
> 

This is if statement vs jump table for switch implementation.

C++ PATCH for c++/80227, SFINAE and negative array size

[Jason Merrill]

In this testcase, because sizeof (T) - 5 has unsigned type, it ends up
being an extremely large number rather than a negative one.
valid_constant_size_p seems to be a useful predicate for recognizing
problematic cases; tree_int_cst_sign_bit should also work, but seems
more subtle.

While I was looking at this I also noticed that the standard has
changed to specify that array bounds are converted constant
expressions, which allows us to simplify some of the code earlier in
the function.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d4ae942cdaf2f3a5b64c187d68a0907e5f611fbd
Author: Jason Merrill 
Date:   Fri Mar 16 10:50:59 2018 -0400

PR c++/80227 - SFINAE and negative array size.

* decl.c (compute_array_index_type): Use
build_converted_constant_expr and valid_constant_size_p.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 727bb04a394..546468bf79f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -9514,8 +9514,6 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
 
   if (!type_dependent_expression_p (size))
 {
-  tree type = TREE_TYPE (size);
-
   size = mark_rvalue_use (size);
 
   if (cxx_dialect < cxx11 && TREE_CODE (size) == NOP_EXPR
@@ -9525,29 +9523,8 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
   else
 	{
 	  size = instantiate_non_dependent_expr_sfinae (size, complain);
-
-	  if (CLASS_TYPE_P (type)
-	  && CLASSTYPE_LITERAL_P (type))
-	{
-	  size = build_expr_type_conversion (WANT_INT, size, true);
-	  if (!size)
-		{
-		  if (!(complain & tf_error))
-		return error_mark_node;
-		  if (name)
-		error ("size of array %qD has non-integral type %qT",
-			   name, type);
-		  else
-		error ("size of array has non-integral type %qT", type);
-		  size = integer_one_node;
-		}
-	  if (size == error_mark_node)
-		return error_mark_node;
-	  type = TREE_TYPE (size);
-	}
-
-	  if (INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (type))
-	size = maybe_constant_value (size);
+	  size = build_converted_constant_expr (size_type_node, size, complain);
+	  size = maybe_constant_value (size);
 
 	  if (!TREE_CONSTANT (size))
 	size = osize;
@@ -9557,6 +9534,7 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
 	return error_mark_node;
 
   /* The array bound must be an integer type.  */
+  tree type = TREE_TYPE (size);
   if (!INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (type))
 	{
 	  if (!(complain & tf_error))
@@ -9566,7 +9544,6 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
 	  else
 	error ("size of array has non-integral type %qT", type);
 	  size = integer_one_node;
-	  type = TREE_TYPE (size);
 	}
 }
 
@@ -9604,15 +9581,12 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
   /* Normally, the array-bound will be a constant.  */
   if (TREE_CODE (size) == INTEGER_CST)
 {
-  /* Check to see if the array bound overflowed.  Make that an
-	 error, no matter how generous we're being.  */
-  constant_expression_error (size);
-
   /* An array must have a positive number of elements.  */
-  if (tree_int_cst_lt (size, integer_zero_node))
+  if (!valid_constant_size_p (size))
 	{
 	  if (!(complain & tf_error))
 	return error_mark_node;
+
 	  if (name)
 	error ("size of array %qD is negative", name);
 	  else
diff --git a/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C
new file mode 100644
index 000..8d9b2d26f01
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C
@@ -0,0 +1,10 @@
+// PR c++/80227
+// { dg-do compile { target c++11 } }
+
+template 
+int foo (T);
+
+template 
+int foo (T, U* = 0);
+
+int i = foo (123);
diff --git a/gcc/testsuite/g++.dg/gomp/pr47963.C b/gcc/testsuite/g++.dg/gomp/pr47963.C
index 7c94e6422a7..5b0c60b80a4 100644
--- a/gcc/testsuite/g++.dg/gomp/pr47963.C
+++ b/gcc/testsuite/g++.dg/gomp/pr47963.C
@@ -5,7 +5,7 @@
 void
 foo (float n)
 {
-  int A[n][n];	// { dg-error "has non-integral type" }
+  int A[n][n];	// { dg-error "has non-integral type|converted constant expression" }
 #pragma omp parallel private(A)
   ;
 }
diff --git a/gcc/testsuite/g++.dg/init/new37.C b/gcc/testsuite/g++.dg/init/new37.C
index 3255a696143..9ecbfd7903d 100644
--- a/gcc/testsuite/g++.dg/init/new37.C
+++ b/gcc/testsuite/g++.dg/init/new37.C
@@ -32,7 +32,7 @@ template 
 void *
 callnew_fail_3()
 {
-  return new T[2][T::n]; // { dg-error "size of array has non-integral type" }
+  return new T[2][T::n]; // { dg-error "size of array has non-integral type|converted constant expression" }
 }
 
 struct T1 {
diff --git a/gcc/testsuite/g++.dg/init/new44.C b/gcc/testsuite/g++.dg/init/new44.C
index ab6e3484cc8..4ab73209e22 100644
--- a/gcc/testsuite/g++.dg/init/new44.C
+++ b/gcc/testsuite/g++.dg/init/new44.C
@@ -87,10 +87,10 @@ test_one_dim_short_array ()
 static void 

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Mar 16 18:48:26 2018
New Revision: 258602

URL: https://gcc.gnu.org/viewcvs?rev=258602=gcc=rev
Log:
2018-03-16  Vladimir Makarov  

PR target/84876
* lra-assigns.c (lra_split_hard_reg_for): Don't use
regno_allocno_class_array and sorted_pseudos.
* lra-constraints.c (spill_hard_reg_in_range): Ignore hard regs in
insns where regno is used.

2018-03-16  Vladimir Makarov  

PR target/84876
* gcc.target/i386/pr84876.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr84876.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

C++ PATCH for c++/84906, silent wrong code with ambiguous conversion

[Jason Merrill]

The problem here was that when we initially looked for the conversion
we were in direct-initialization context, but then when we tried to do
the lookup again to get an error it was done in copy-initialization
context, so it was no longer ambiguous.  Fixed by remembering which
we're in.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0959fc01e907ccc575d09280154b437efce97f33
Author: Jason Merrill 
Date:   Fri Mar 16 11:24:23 2018 -0400

PR c++/84906 - silent wrong code with ambiguous conversion.

* call.c (build_user_type_conversion_1): Set need_temporary_p on
ambiguous conversion.
(convert_like_real): Check it.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index a32f41915fc..23d4f82a1a0 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -93,7 +93,8 @@ struct conversion {
   BOOL_BITFIELD bad_p : 1;
   /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
  temporary should be created to hold the result of the
- conversion.  */
+ conversion.  If KIND is ck_ambig, true if the context is
+ copy-initialization.  */
   BOOL_BITFIELD need_temporary_p : 1;
   /* If KIND is ck_ptr or ck_pmem, true to indicate that a conversion
  from a pointer-to-derived to pointer-to-base is being performed.  */
@@ -3943,6 +3944,8 @@ build_user_type_conversion_1 (tree totype, tree expr, int flags,
   cand->second_conv->user_conv_p = true;
   if (!any_strictly_viable (candidates))
 	cand->second_conv->bad_p = true;
+  if (flags & LOOKUP_ONLYCONVERTING)
+	cand->second_conv->need_temporary_p = true;
   /* If there are viable candidates, don't set ICS_BAD_FLAG; an
 	 ambiguous conversion is no worse than another user-defined
 	 conversion.  */
@@ -6834,8 +6837,10 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
   if (complain & tf_error)
 	{
 	  /* Call build_user_type_conversion again for the error.  */
-	  build_user_type_conversion (totype, convs->u.expr, LOOKUP_IMPLICIT,
-  complain);
+	  int flags = (convs->need_temporary_p
+		   ? LOOKUP_IMPLICIT : LOOKUP_NORMAL);
+	  build_user_type_conversion (totype, convs->u.expr, flags, complain);
+	  gcc_assert (seen_error ());
 	  if (fn)
 	inform (DECL_SOURCE_LOCATION (fn),
 		"  initializing argument %P of %qD", argnum, fn);
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C b/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C
new file mode 100644
index 000..a2c7e40755b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C
@@ -0,0 +1,23 @@
+// PR c++/84906
+// { dg-do compile { target c++14 } }
+
+extern "C" int puts(const char*);
+
+struct aa {
+  operator auto() {
+puts("auto");
+return false;
+  }
+  explicit operator bool() {
+puts("bool");
+return true;
+  }
+};
+
+int main() {
+  aa x;
+  if (x)			// { dg-error "ambiguous" }
+puts("here");
+  else
+puts("there");
+}

[Bug c++/84897] Better handling of unqualified "string"

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #2)
> Yes, we want to special case the inline namespaces std::__cxx11 and std::_V2
> so that they only show their contents as std::xxx not std::_V2::xxx. Or
> maybe automatically elide any inline namespace under std, so that we show
> std::experimental::source_location not
> std::experimental::fundamentals_v2::source_location. The point of an inline
> namespace is that you don't need to use it to refer to the type, the type
> can be named as though it was declared in the enclosing namespace.

I don't think we want to special case anything.  I think we want to
automtically elide any (all) inline namespace even ones which are not under
std.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

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

--- Comment #2 from Jason Vas Dias  ---
Thanks H.J. -

RE:
> vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> 4.16-rc5.  Why isn't it the case for you? 

All I know is ,  when submitting a patched vclock_gettime.c 
in which the switch in vdso_clock_gettime() had 6 clauses
instead of 5, I received in response a mail from 
kbuild test robot<l...@intel.com>:

>Hi
>
>Thank you for the patch! Yet something to improve:
>
>[auto build test ERROR on v4.16-rc4]
>[also build test ERROR on next-20180315]
>[if your patch is applied to the wrong git tree, please drop us a note to help 
>>improve the system]
>
>url:
>https://github.com/0day-ci/linux/commits/jason-vas-dias-gmail-com/x86-vdso-on-Intel-VDSO-should-handle-CLOCK_MONOTONIC_RAW/20180316-070319
>config: x86_64-rhel (attached as .config)
>compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>reproduce:
># save the attached .config to linux build tree
>make ARCH=x86_64
>
>All errors (new ones prefixed by >>):
>
>   arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
>   vclock_gettime.c:(.text+0xf7): undefined reference to 
> >`__x86_indirect_thunk_rax'
>   /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32 
> >against undefined symbol `__x86_indirect_thunk_rax' can not be used when 
> making >a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Bad value
>>> collect2: error: ld returned 1 exit status
>--
>>> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
>--
>>> objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
>---
>0-DAY kernel test infrastructureOpen Source Technology Center
>https://lists.01.org/pipermail/kbuild-all   Intel Corporation

That github URL does not point to anything anymore.

So it was 4.16-rc4 they were compiling against.
Maybe it is fixed in 4.16-rc5.

I had seen exactly the same problem when compiling the same
patch with the RHEL-7 4.8.5-16-el7_4.2.x86_64 compiler,
which did not happen when compiling the same code with
the previous RHEL-7 4.8.5-16-el7_4.1.x86_64 compiler.

So it is caused by  -mindirect-branch=thunk-extern ?


Aha, I see in kernel Makefile of the RHEL 3.10.0-21.1.el7 kernel:
  RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern
-mindirect-branch-register)

And it is still in the CFLAGS of the kernel tagged 'v4.16-rc5:'

$ grep RETPOLINE linux-4.16-rc5/Makefile
RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern
-mindirect-branch-register
RETPOLINE_CFLAGS_CLANG := -mretpoline-external-thunk
RETPOLINE_CFLAGS := $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call
cc-option,$(RETPOLINE_CFLAGS_CLANG)))

But the compiler I am using for the 4.x builds is 6.4.1 , which
does not support -mindirect-branch=thunk-extern / -mindirect-branch-register .

I will get round to building one of the latest compilers with
retpoline support eventually, but it is not a priority for me
at the moment, for my Linux 4.x builds.

I just want to be able to build the patched vclock_gettime.c
under RHEL, with the new 4.8.5-16 retpoline supporting compiler,
and to be able to submit patches that don't break to the 4.16-rc5
branch .


YES, I have just tested, removing 
  '-mindirect-branch=thunk-extern -mindirect-branch-register'
from the 3.10.0-693.21.1.el7 build DOES allow it to succeed 
with the 6-clause version of the switch in vclock_gettime.c .

But I don't want my patch to have to depend on this being removed -
the removal of these flags effectively removes retpoline support, no ?
It is a shame to have to do that after it was carefully added.

My gripe is really that nothing in GCC should work with a switch
with < 6 clauses, and fail with a switch with >= 6 clauses.

Just reporting this issue so it can be fixed.

Thanks & Best Regards,
Jason

[Bug target/84914] PowerPC complex multiply/divide calls the wrong function when -mabi=ieeelongdouble

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

[Bug target/84914] New: PowerPC complex multiply/divide calls the wrong function when -mabi=ieeelongdouble

[meissner at gcc dot gnu.org]

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

Bug ID: 84914
   Summary: PowerPC complex multiply/divide calls the wrong
function when -mabi=ieeelongdouble
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Joseph Meyers had pointed out in January that we are calling the wrong function
for complex multiply/divide when using -mabi=ieeelongdouble -Wno-psabi:

long double _Complex cm (long double _Complex a, long double _Complex b)
{
  return a*b;
}

It should call __mulkc3 instead of __multc3.  Similarly for divide.

[Bug c/84903] internal compiler error: in convert_move, at expr.c:229

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This got fixed with r258272 aka PR84687 fix on the trunk.

[Bug target/84902] [8 Regression] 549.fotonik3d_r from SPEC2017 fails verification with -Ofast -march=native on Zen since r258518

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Created attachment 43684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43684=edit
gcc8-pr84902.patch

Just a wild guess, does this fix it?