Re: PR80155: Code hoisting and register pressure

[Richard Biener]

On Sat, 26 May 2018, Bin.Cheng wrote:

> On Fri, May 25, 2018 at 5:54 PM, Richard Biener  wrote:
> > On May 25, 2018 6:57:13 PM GMT+02:00, Jeff Law  wrote:
> >>On 05/25/2018 03:49 AM, Bin.Cheng wrote:
> >>> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
> >>>  wrote:
>  On 23 May 2018 at 18:37, Jeff Law  wrote:
> > On 05/23/2018 03:20 AM, Prathamesh Kulkarni wrote:
> >> On 23 May 2018 at 13:58, Richard Biener  wrote:
> >>> On Wed, 23 May 2018, Prathamesh Kulkarni wrote:
> >>>
>  Hi,
>  I am trying to work on PR80155, which exposes a problem with
> >>code
>  hoisting and register pressure on a leading embedded benchmark
> >>for ARM
>  cortex-m7, where code-hoisting causes an extra register spill.
> 
>  I have attached two test-cases which (hopefully) are
> >>representative of
>  the original test-case.
>  The first one (trans_dfa.c) is bigger and somewhat similar to
> >>the
>  original test-case and trans_dfa_2.c is hand-reduced version of
>  trans_dfa.c. There's 2 spills caused with trans_dfa.c
>  and one spill with trans_dfa_2.c due to lesser amount of cases.
>  The test-cases in the PR are probably not relevant.
> 
>  Initially I thought the spill was happening because of "too many
>  hoistings" taking place in original test-case thus increasing
> >>the
>  register pressure, but it seems the spill is possibly caused
> >>because
>  expression gets hoisted out of a block that is on loop exit.
> 
>  For example, the following hoistings take place with
> >>trans_dfa_2.c:
> 
>  (1) Inserting expression in block 4 for code hoisting:
>  {mem_ref<0B>,tab_20(D)}@.MEM_45 (0005)
> 
>  (2) Inserting expression in block 4 for code hoisting:
> >>{plus_expr,_4,1} (0006)
> 
>  (3) Inserting expression in block 4 for code hoisting:
>  {pointer_plus_expr,s_33,1} (0023)
> 
>  (4) Inserting expression in block 3 for code hoisting:
>  {pointer_plus_expr,s_33,1} (0023)
> 
>  The issue seems to be hoisting of (*tab + 1) which consists of
> >>first
>  two hoistings in block 4
>  from blocks 5 and 9, which causes the extra spill. I verified
> >>that by
>  disabling hoisting into block 4,
>  which resulted in no extra spills.
> 
>  I wonder if that's because the expression (*tab + 1) is getting
>  hoisted from blocks 5 and 9,
>  which are on loop exit ? So the expression that was previously
>  computed in a block on loop exit, gets hoisted outside that
> >>block
>  which possibly makes the allocator more defensive ? Similarly
>  disabling hoisting of expressions which appeared in blocks on
> >>loop
>  exit in original test-case prevented the extra spill. The other
>  hoistings didn't seem to matter.
> >>>
> >>> I think that's simply co-incidence.  The only thing that makes
> >>> a block that also exits from the loop special is that an
> >>> expression could be sunk out of the loop and hoisting (commoning
> >>> with another path) could prevent that.  But that isn't what is
> >>> happening here and it would be a pass ordering issue as
> >>> the sinking pass runs only after hoisting (no idea why exactly
> >>> but I guess there are cases where we want to prefer CSE over
> >>> sinking).  So you could try if re-ordering PRE and sinking helps
> >>> your testcase.
> >> Thanks for the suggestions. Placing sink pass before PRE works
> >> for both these test-cases! Sadly it still causes the spill for the
> >>benchmark -:(
> >> I will try to create a better approximation of the original
> >>test-case.
> >>>
> >>> What I do see is a missed opportunity to merge the successors
> >>> of BB 4.  After PRE we have
> >>>
> >>>  [local count: 159303558]:
> >>> :
> >>> pretmp_123 = *tab_37(D);
> >>> _87 = pretmp_123 + 1;
> >>> if (c_36 == 65)
> >>>   goto ; [34.00%]
> >>> else
> >>>   goto ; [66.00%]
> >>>
> >>>  [local count: 54163210]:
> >>> *tab_37(D) = _87;
> >>> _96 = MEM[(char *)s_57 + 1B];
> >>> if (_96 != 0)
> >>>   goto ; [89.00%]
> >>> else
> >>>   goto ; [11.00%]
> >>>
> >>>  [local count: 105140348]:
> >>> *tab_37(D) = _87;
> >>> _56 = MEM[(char *)s_57 + 1B];
> >>> if (_56 != 0)
> >>>   goto ; [89.00%]
> >>> else
> >>>   goto ; [11.00%]
> >>>
> >>> here at least the stores and loads can be hoisted.  Note this
> >>> may also point at the real issue of the code hoisting which is
> >>> tearing apart the RMW operation?
> >> Indeed, this possibility seems much more likely than 

Re: Enabling -ftree-slp-vectorize on -O2/Os

[Allan Sandfeld Jensen]

On Montag, 28. Mai 2018 12:58:20 CEST Richard Biener wrote:
> compile-time effects of the patch on that. Embedded folks may want to rhn
> their favorite benchmark and report results as well.
> 
> So I did a -O2 -march=haswell [-ftree-slp-vectorize] SPEC CPU 2006 compile
> and run and the compile-time
> effect where measurable (SPEC records on a second granularity) is within
> one second per benchmark
> apart from 410.bwaves (from 3s to 5s)  and 481.wrf (76s to 78s).
> Performance-wise I notice significant
> slowdowns for SPEC FP and some for SPEC INT (I only did a train run
> sofar).  I'll re-run with ref input now
> and will post those numbers.
> 
If you continue to see slowdowns, could you check with either no avx, or with 
-mprefer-avx128? The occational AVX256 instructions might be downclocking the 
CPU. But yes that would be a problem for this change on its own.

'Allan

Re: not computable at load time

[Paul Koning]

> On May 28, 2018, at 12:03 PM, Richard Biener  
> wrote:
> 
> On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab  wrote:
>> On Mai 28 2018, Richard Biener  wrote:
>> 
>>> It means there's no relocation that can express the result of 's.f -
>> '
>>> and the frontend doesn't consider this a constant expression (likely
>> because
>>> of the conversion).
>> 
>> Shouldn't the frontend notice that s.f -  by itself is a constant?
> 
> Sure - the question is whether it is required to and why it doesn't. 

This is a test case in the C torture test suite.  The only  reason 
I can see for it being there is to verify that GCC resolves this as 
a compile time constant.

The issue can be masked by changing the "long" in that test case to
a ptrdiff_t, which eliminates the conversion.  Should I do that?
It would make the test pass, at the expense of masking this glitch.

By the way, I get the same error if I change the "long" to a "long long"
and them compile for 32-bit Intel. 

paul

Connect with me on LinkedIn to be on my safe supplier list we need your products

[Andrea Jung]

 
 

 gcc@gcc.gnu.org  
   


Here are some people you may know and would like to connect with you. Reach out 
and build new connections.

   


  
   Andrea Jung
   Chairperson and CEO of Avon Group of companies.

   

   View Profile  Connect
   

   Unsubscribe   |   Help
   
You are receiving LinkedIn notification emails.

   This email was intended for gcc@gcc.gnu.org. Learn why we included this.

  
   © LinkedIn. Mailing address: Room 817, 18F, Building 18, #1 DiSheng Bei 
Road, Bejing Yizhuang Development Area, China. LinkedIn and the LinkedIn logo 
are registered trademarks of LinkedIn.

 
 
 //  

Re: GCC Compiler Optimization ignores or mistreats MFENCE memory barrier related instruction

[Umesh Kalappa]

Ok, thanks for the clarification jakub.

Umesg

On Mon, May 7, 2018, 2:08 PM Jakub Jelinek  wrote:

> On Mon, May 07, 2018 at 01:58:48PM +0530, Umesh Kalappa wrote:
> > CCed Jakub,
>
> > > Agree that float division don't touch memory ,but fdiv  result (stack
> > > register ) is stored  back to a memory i.e fResult .
>
> That doesn't really matter.  It is stored to a stack spill slot, something
> that doesn't have address taken and other code (e.g. in other threads)
> can't
> in a valid program access it.  That is not considered memory for the
> inline-asm, only objects that must live in memory count.
>
> Jakub
>

Re: not computable at load time

[Andreas Schwab]

On Mai 28 2018, Richard Biener  wrote:

> It means there's no relocation that can express the result of 's.f - '
> and the frontend doesn't consider this a constant expression (likely because
> of the conversion).

Shouldn't the frontend notice that s.f -  by itself is a constant?

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Enabling -ftree-slp-vectorize on -O2/Os

[Richard Biener]

On Sat, May 26, 2018 at 12:36 PM Richard Biener 
wrote:

> On May 26, 2018 11:32:29 AM GMT+02:00, Allan Sandfeld Jensen <
li...@carewolf.com> wrote:
> >I brought this subject up earlier, and was told to suggest it again for
> >gcc 9,
> >so I have attached the preliminary changes.
> >
> >My studies have show that with generic x86-64 optimization it reduces
> >binary
> >size with around 0.5%, and when optimizing for x64 targets with SSE4 or
> >
> >better, it reduces binary size by 2-3% on average. The performance
> >changes are
> >negligible however*, and I haven't been able to detect changes in
> >compile time
> >big enough to penetrate general noise on my platform, but perhaps
> >someone has
> >a better setup for that?
> >
> >* I believe that is because it currently works best on non-optimized
> >code, it
> >is better at big basic blocks doing all kinds of things than tightly
> >written
> >inner loops.
> >
> >Anythhing else I should test or report?

> If you have access to SPEC CPU I'd like to see performance, size and
compile-time effects of the patch on that. Embedded folks may want to rhn
their favorite benchmark and report results as well.

So I did a -O2 -march=haswell [-ftree-slp-vectorize] SPEC CPU 2006 compile
and run and the compile-time
effect where measurable (SPEC records on a second granularity) is within
one second per benchmark
apart from 410.bwaves (from 3s to 5s)  and 481.wrf (76s to 78s).
Performance-wise I notice significant
slowdowns for SPEC FP and some for SPEC INT (I only did a train run
sofar).  I'll re-run with ref input now
and will post those numbers.

binary size numbers show an increase for 403.gcc, 433.milc 444.namd and
otherwise decreases or
no changes.  The changes are in the sub-percentage area of course.

Overall 12583 "BBs" are vectorized.  I need to improve that reporting for
multiple (non-)overlapping instances.

I realize that combining -O2 with -march=haswell might not be what people
do but I tried to increase
the number of vectorized BBs.

Richard.

> Richard.

> >Best regards
> >'Allan
> >
> >
> >diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >index beba295bef5..05851229354 100644
> >--- a/gcc/doc/invoke.texi
> >+++ b/gcc/doc/invoke.texi
> >@@ -7612,6 +7612,7 @@ also turns on the following optimization flags:
> > -fstore-merging @gol
> > -fstrict-aliasing @gol
> > -ftree-builtin-call-dce @gol
> >+-ftree-slp-vectorize @gol
> > -ftree-switch-conversion -ftree-tail-merge @gol
> > -fcode-hoisting @gol
> > -ftree-pre @gol
> >@@ -7635,7 +7636,6 @@ by @option{-O2} and also turns on the following
> >optimization flags:
> > -floop-interchange @gol
> > -floop-unroll-and-jam @gol
> > -fsplit-paths @gol
> >--ftree-slp-vectorize @gol
> > -fvect-cost-model @gol
> > -ftree-partial-pre @gol
> > -fpeel-loops @gol
> >@@ -8932,7 +8932,7 @@ Perform loop vectorization on trees. This flag is
> >
> >enabled by default at
> > @item -ftree-slp-vectorize
> > @opindex ftree-slp-vectorize
> >Perform basic block vectorization on trees. This flag is enabled by
> >default
> >at
> >-@option{-O3} and when @option{-ftree-vectorize} is enabled.
> >+@option{-O2} or higher, and when @option{-ftree-vectorize} is enabled.
> >
> > @item -fvect-cost-model=@var{model}
> > @opindex fvect-cost-model
> >diff --git a/gcc/opts.c b/gcc/opts.c
> >index 33efcc0d6e7..11027b847e8 100644
> >--- a/gcc/opts.c
> >+++ b/gcc/opts.c
> >@@ -523,6 +523,7 @@ static const struct default_options
> >default_options_table[] =
> > { OPT_LEVELS_2_PLUS, OPT_fipa_ra, NULL, 1 },
> > { OPT_LEVELS_2_PLUS, OPT_flra_remat, NULL, 1 },
> > { OPT_LEVELS_2_PLUS, OPT_fstore_merging, NULL, 1 },
> >+{ OPT_LEVELS_2_PLUS, OPT_ftree_slp_vectorize, NULL, 1 },
> >
> > /* -O3 optimizations.  */
> >{ OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
> >@@ -539,7 +540,6 @@ static const struct default_options
> >default_options_table[] =
> > { OPT_LEVELS_3_PLUS, OPT_floop_unroll_and_jam, NULL, 1 },
> > { OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
> > { OPT_LEVELS_3_PLUS, OPT_ftree_loop_vectorize, NULL, 1 },
> >-{ OPT_LEVELS_3_PLUS, OPT_ftree_slp_vectorize, NULL, 1 },
> >{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL,
> >VECT_COST_MODEL_DYNAMIC
> >},
> > { OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
> > { OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },

RISC-V problem with weak function references and -mcmodel=medany

[Sebastian Huber]

Hello,

I try to build a 64-bit RISC-V tool chain for RTEMS. RTEMS doesn't use 
virtual memory. The reference chips for 64-bit RISC-V such as FU540-C000 
locate the RAM at 0x8000_. This forces me to use -mcmodel=medany in 
64-bit mode. The ctrbegin.o contains this code (via crtstuff.c):


extern void *__deregister_frame_info (const void *)
 __attribute__ ((weak));
...
# 370 "libgcc/crtstuff.c"
static void __attribute__((used))
__do_global_dtors_aux (void)
{
  static _Bool completed;

  if (__builtin_expect (completed, 0))
    return;
# 413 "libgcc/crtstuff.c"
  deregister_tm_clones ();
# 423 "libgcc/crtstuff.c"
  if (__deregister_frame_info)
    __deregister_frame_info (__EH_FRAME_BEGIN__);



  completed = 1;
}

Which is:

    .text
    .align    1
    .type    __do_global_dtors_aux, @function
__do_global_dtors_aux:
    lbu    a5,completed.3298
    bnez    a5,.L22
    addi    sp,sp,-16
    sd    ra,8(sp)
    call    deregister_tm_clones
    lla    a5,__deregister_frame_info
    beqz    a5,.L17
    lla    a0,__EH_FRAME_BEGIN__
    call    __deregister_frame_info
.L17:
    ld    ra,8(sp)
    li    a5,1
    sb    a5,completed.3298,a4
    addi    sp,sp,16
    jr    ra
.L22:
    ret

If I link an executable I get this:

/opt/rtems/5/lib64/gcc/riscv64-rtems5/9.0.0/../../../../riscv64-rtems5/bin/ld: 
/opt/rtems/5/lib64/gcc/riscv64-rtems5/9.0.0/crtbegin.o: in function `.L0 ':
crtstuff.c:(.text+0x72): relocation truncated to fit: R_RISCV_CALL 
against undefined symbol `__deregister_frame_info'


I guess, that the resolution of the weak reference to the undefined 
symbol __deregister_frame_info somehow sets __deregister_frame_info to 
the absolute address 0 which is illegal in the following "call 
__deregister_frame_info"? Is this construct with weak references and a 
-mcmodel=medany supported on RISC-V at all?


If I change crtstuff.c like this using weak function definitions

diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 5e894455e16..770e3420c92 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -177,13 +177,24 @@ call_ ## FUNC 
(void)  \


 /* References to __register_frame_info and __deregister_frame_info should
    be weak in this file if at all possible.  */
-extern void __register_frame_info (const void *, struct object *)
- TARGET_ATTRIBUTE_WEAK;
+extern void __register_frame_info (const void *, struct object *) ;
+TARGET_ATTRIBUTE_WEAK void __register_frame_info (const void *unused, 
struct object *unused2)

+{
+   (void)unused;
+   (void)unused2;
+}
+
 extern void __register_frame_info_bases (const void *, struct object *,
 void *, void *)
  TARGET_ATTRIBUTE_WEAK;
-extern void *__deregister_frame_info (const void *)
- TARGET_ATTRIBUTE_WEAK;
+
+extern void *__deregister_frame_info (const void *);
+TARGET_ATTRIBUTE_WEAK void *__deregister_frame_info (const void *unused)
+{
+   (void)unused;
+   return 0;
+}
+
 extern void *__deregister_frame_info_bases (const void *)
TARGET_ATTRIBUTE_WEAK;
 extern void __do_global_ctors_1 (void);

then the example program links.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: not computable at load time

[Richard Biener]

On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab  wrote:
>On Mai 28 2018, Richard Biener  wrote:
>
>> It means there's no relocation that can express the result of 's.f -
>'
>> and the frontend doesn't consider this a constant expression (likely
>because
>> of the conversion).
>
>Shouldn't the frontend notice that s.f -  by itself is a constant?

Sure - the question is whether it is required to and why it doesn't. 

Richard. 

>Andreas.

Re: not computable at load time

[Richard Biener]

On Fri, May 25, 2018 at 8:05 PM Paul Koning  wrote:

> One of my testsuite failures for the pdp11 back end is
gcc.c-torture/compile/930326-1.c which is:

> struct
> {
>char a, b, f[3];
> } s;

> long i = s.f-

> It fails with "error: initializer element is not computable at load time".
> I don't understand why because it seems to be a perfectly reasonable
> compile time constant; "load time" doesn't enter into the picture that
> I can see.

It means there's no relocation that can express the result of 's.f - '
and the frontend doesn't consider this a constant expression (likely because
of the conversion).

> If I replace "long" by "short" it works correctly.  So presumably it has
> something to do with the fact that Pmode == HImode.  But how that
translates
> into this failure I don't know.

>  paul

[Bug target/85939] -mstackrealign does not realign stack with local __m64 variable

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
Created attachment 44197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44197=edit
A patch

[Bug c/69558] [6/7/8/9 Regression] glib2 warning pragmas stopped working

[egallager at gcc dot gnu.org]

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

--- Comment #23 from Eric Gallager  ---
(In reply to David Malcolm from comment #22)
> Assigning this to me in the hope that I'll get to it in gcc 9 stage 1.

It's gcc 9 stage 1 now.

[PATCH] Implement Fortran 2018's RANDOM_INIT

[Steve Kargl]

The attached patch implements the RANDOM_INIT intrinsic
subroutine specified in Fortran 2018.  I have had this
patch in my local tree for the last 5+ months.  Now that
8.1 is out, it is time to submit it.  It has been built
and regression tested on x86_64-*-freebsd.  OK to commit?

Note, I have only tested with -fcoarray=single as I don't
have OpenCoarray set up to build with trunk.  Testing with
OpenCoarray is encouraged.

2018-05-28  Steven G. Kargl  

* check.c (gfc_check_random_init): New function. Check arguments of
RANDOM_INIT.
* gfortran.h (GFC_ISYM_RANDOM_INIT): New enum token.
* intrinsic.c (add_subroutines): Add RANDOM_INIT to list of 
subroutines.
* intrinsic.h: Add prototypes for gfc_check_random_init and
gfc_resolve_random_init
* intrinsic.texi: Document new intrinsic subprogram.
* iresolve.c (gfc_resolve_random_init): Resolve routine name.
* trans-decl.c: Declare gfor_fndecl_random_init
* trans-intrinsic.c (conv_intrinsic_random_init): New function.
Translate call to RANDOM_INIT.
(gfc_conv_intrinsic_subroutine): Call it.
* trans.h: Declare gfor_fndecl_random_init
 
2018-05-28  Steven G. Kargl  
 
* gfortran.dg/random_init_1.f90: New test.
* gfortran.dg/random_init_2.f90: New test.
* gfortran.dg/random_init_3.f90: New test.
* gfortran.dg/random_init_4.f90: New test.
* gfortran.dg/random_init_5.f90: New test.
* gfortran.dg/random_init_6.f90: New test.

2018-05-28  Steven G. Kargl  

* libgfortran/Makefile.am: Add random_init.f90 to build.
* libgfortran/Makefile.in: Regenerated.
* libgfortran/gfortran.map: Expose symbol for _gfortran_random_init.
* libgfortran/intrinsics/random_init.f90: Implementation.

-- 
Steve
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c	(revision 256953)
+++ gcc/fortran/check.c	(working copy)
@@ -5744,6 +5744,27 @@ gfc_check_mvbits (gfc_expr *from, gfc_expr *frompos, g
 }
 
 
+/* Check the arguments for RANDOM_INIT.  */
+
+bool
+gfc_check_random_init (gfc_expr *repeatable, gfc_expr *image_distinct)
+{
+  if (!type_check (repeatable, 0, BT_LOGICAL))
+return false;
+
+  if (!scalar_check (repeatable, 0))
+return false;
+
+  if (!type_check (image_distinct, 1, BT_LOGICAL))
+return false;
+
+  if (!scalar_check (image_distinct, 1))
+return false;
+
+  return true;
+}
+
+
 bool
 gfc_check_random_number (gfc_expr *harvest)
 {
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h	(revision 256953)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -551,6 +551,7 @@ enum gfc_isym_id
   GFC_ISYM_PRODUCT,
   GFC_ISYM_RADIX,
   GFC_ISYM_RAND,
+  GFC_ISYM_RANDOM_INIT,
   GFC_ISYM_RANDOM_NUMBER,
   GFC_ISYM_RANDOM_SEED,
   GFC_ISYM_RANGE,
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c	(revision 256953)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -3555,6 +3555,12 @@ add_subroutines (void)
   make_alias ("kmvbits", GFC_STD_GNU);
 }
 
+  add_sym_2s ("random_init", GFC_ISYM_RANDOM_INIT, CLASS_IMPURE,
+	  BT_UNKNOWN, 0, GFC_STD_F2018,
+	  gfc_check_random_init, NULL, gfc_resolve_random_init,
+	  "repeatable", BT_LOGICAL, dl, REQUIRED, INTENT_IN,
+	  "image_distinct", BT_LOGICAL, dl, REQUIRED, INTENT_IN);
+
   add_sym_1s ("random_number", GFC_ISYM_RANDOM_NUMBER, CLASS_IMPURE,
 	  BT_UNKNOWN, 0, GFC_STD_F95,
 	  gfc_check_random_number, NULL, gfc_resolve_random_number,
Index: gcc/fortran/intrinsic.h
===
--- gcc/fortran/intrinsic.h	(revision 256953)
+++ gcc/fortran/intrinsic.h	(working copy)
@@ -203,6 +203,7 @@ bool gfc_check_getlog (gfc_expr *);
 bool gfc_check_move_alloc (gfc_expr *, gfc_expr *);
 bool gfc_check_mvbits (gfc_expr *, gfc_expr *, gfc_expr *, gfc_expr *,
 		  gfc_expr *);
+bool gfc_check_random_init (gfc_expr *, gfc_expr *);
 bool gfc_check_random_number (gfc_expr *);
 bool gfc_check_random_seed (gfc_expr *, gfc_expr *, gfc_expr *);
 bool gfc_check_dtime_etime_sub (gfc_expr *, gfc_expr *);
@@ -648,6 +649,7 @@ void gfc_resolve_lstat_sub (gfc_code *);
 void gfc_resolve_ltime (gfc_code *);
 void gfc_resolve_mvbits (gfc_code *);
 void gfc_resolve_perror (gfc_code *);
+void gfc_resolve_random_init (gfc_code *);
 void gfc_resolve_random_number (gfc_code *);
 void gfc_resolve_random_seed (gfc_code *);
 void gfc_resolve_rename_sub (gfc_code *);
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi	(revision 256953)
+++ gcc/fortran/intrinsic.texi	(working copy)
@@ -262,6 +262,7 @@ Some basic guidelines for editing this document:
 * @code{RADIX}: RADIX, Base of a data model
 * 

Re: [PING] [PATCH] Avoid excessive function type casts with splay-trees

[Richard Biener]

On May 28, 2018 4:25:02 PM GMT+02:00, Bernd Edlinger 
 wrote:
>On 05/28/18 11:19, Richard Biener wrote:
>> On Sat, May 26, 2018 at 10:19 AM Bernd Edlinger
>
>> wrote:
>> 
>> 
>> 
>>> On 05/17/18 16:37, Bernd Edlinger wrote:
 On 05/17/18 15:39, Richard Biener wrote:
> On Thu, May 17, 2018 at 3:21 PM Bernd Edlinger
> 
> wrote:
>
>> Ping...
>
> So this makes all traditional users go through the indirect
> splay_tree_compare_wrapper
> and friends (which is also exported for no good reason?).  And all
>> users
> are traditional
> at the moment.
>

 all except gcc/typed-splay-tree.h which only works if VALUE_TYPE is
 compatible with uint_ptr_t but cannot check this requirement.
 This one worried me the most.

 But not having to rewrite omp-low.c for instance where
>splay_tree_lookup
 and access to n->value are made all the time, made me think it
 will not work to rip out the old interface completely.

>> 
>>> Well, I think it will be best to split this patch in two parts:
>> 
>>> One that adds just two utility functions for avoiding undefined
>>> function type casts which can be used with the original C interface.
>>> This first part is attached.
>> 
>>> And another part that uses a similar approach as the splay-tree in
>>> libgomp, but instead of creating a type-safe C interface it should
>>> translate the complete code from splay-tree.c/.h into a template.
>>> The second part, I plan to do at a later time.
>> 
>> 
>>> Is this OK for trunk?
>> 
>> Looks ok to me.  Do we need to worry about !HAVE_STRING_H and
>> using strcmp?
>> 
>
>No, I would be rather surprised if libiberty would compile at all
>without string.h.  First some files include it without HAVE_STRING_H
>for instance sha1.c and argv.c, so I just replicated what
>the majority of the code base here did.
>
>Most sources include  ifdef HAVE_STRING_H, and use strcmp
>even if it is not declared (which should work for functions with int
>result).
>
>So I would commit this patch as is, if you agree.

Sure - go ahead. 

Richard. 

>
>Bernd.
>
>
>> Thanks,
>> Richard.
>> 
>> 
>>> Thanks
>>> Bernd.

[patch, libgfortran] Bug 85840 - Memory leak in write.c

[Jerry DeLisle]

The attached patch is a follow on from my previous for this PR. I could 
not reproduce the problem on these code paths, but one should not assume 
it won't happen.  Patch is obvious and I will commit shortly.


Regression tested on x86_64.


2018-05-28  Jerry DeLisle  

PR libgfortran/85840
* io/write.c (write_real, write_real_g0, write_complex): Use
separate local variables for the float string length.



diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 5d52fd6914f..dc6a234f42e 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1682,7 +1682,7 @@ write_real (st_parameter_dt *dtp, const char 
*source, int kind)

   char buf_stack[BUF_STACK_SZ];
   char str_buf[BUF_STACK_SZ];
   char *buffer, *result;
-  size_t buf_size, res_len;
+  size_t buf_size, res_len, flt_str_len;
   int orig_scale = dtp->u.p.scale_factor;
   dtp->u.p.scale_factor = 1;
   set_fnode_default (dtp, , kind);
@@ -1697,8 +1697,8 @@ write_real (st_parameter_dt *dtp, const char 
*source, int kind)

   buffer = select_buffer (dtp, , precision, buf_stack, _size, kind);

   get_float_string (dtp, , source , kind, 1, buffer,
-   precision, buf_size, result, _len);
-  write_float_string (dtp, result, res_len);
+   precision, buf_size, result, _str_len);
+  write_float_string (dtp, result, flt_str_len);

   dtp->u.p.scale_factor = orig_scale;
   if (buf_size > BUF_STACK_SZ)
@@ -1717,7 +1717,7 @@ write_real_g0 (st_parameter_dt *dtp, const char 
*source, int kind, int d)

   char buf_stack[BUF_STACK_SZ];
   char str_buf[BUF_STACK_SZ];
   char *buffer, *result;
-  size_t buf_size, res_len;
+  size_t buf_size, res_len, flt_str_len;
   int comp_d;
   set_fnode_default (dtp, , kind);

@@ -1741,8 +1741,8 @@ write_real_g0 (st_parameter_dt *dtp, const char 
*source, int kind, int d)

   buffer = select_buffer (dtp, , precision, buf_stack, _size, kind);

   get_float_string (dtp, , source , kind, comp_d, buffer,
-   precision, buf_size, result, _len);
-  write_float_string (dtp, result, res_len);
+   precision, buf_size, result, _str_len);
+  write_float_string (dtp, result, flt_str_len);

   dtp->u.p.g0_no_blanks = 0;
   if (buf_size > BUF_STACK_SZ)
@@ -1767,7 +1767,7 @@ write_complex (st_parameter_dt *dtp, const char 
*source, int kind, size_t size)

   char str1_buf[BUF_STACK_SZ];
   char str2_buf[BUF_STACK_SZ];
   char *buffer, *result1, *result2;
-  size_t buf_size, res_len1, res_len2;
+  size_t buf_size, res_len1, res_len2, flt_str_len1, flt_str_len2;
   int width, lblanks, orig_scale = dtp->u.p.scale_factor;

   dtp->u.p.scale_factor = 1;
@@ -1790,18 +1790,18 @@ write_complex (st_parameter_dt *dtp, const char 
*source, int kind, size_t size)

   buffer = select_buffer (dtp, , precision, buf_stack, _size, kind);

   get_float_string (dtp, , source , kind, 0, buffer,
-   precision, buf_size, result1, _len1);
+   precision, buf_size, result1, _str_len1);
   get_float_string (dtp, , source + size / 2 , kind, 0, buffer,
-   precision, buf_size, result2, _len2);
+   precision, buf_size, result2, _str_len2);
   if (!dtp->u.p.namelist_mode)
 {
-  lblanks = width - res_len1 - res_len2 - 3;
+  lblanks = width - flt_str_len1 - flt_str_len2 - 3;
   write_x (dtp, lblanks, lblanks);
 }
   write_char (dtp, '(');
-  write_float_string (dtp, result1, res_len1);
+  write_float_string (dtp, result1, flt_str_len1);
   write_char (dtp, semi_comma);
-  write_float_string (dtp, result2, res_len2);
+  write_float_string (dtp, result2, flt_str_len2);
   write_char (dtp, ')');

   dtp->u.p.scale_factor = orig_scale;

[Bug fortran/85942] ICE with PDTs

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
I have been to busy of late to attend to the problems with PDT. However, a
window is opening up in the second half of June and I will set to work then.
The starting point will be to introduce a pdt descriptor since this is an
essential correction to the implementation. Beyond this, I will do a bit of
triage and work my way through the PRs in priority order.

Thanks for the report.

Paul

[Bug target/85945] [6/7/8/9 Regression] ICE in resolve_subreg_use, at lower-subreg.c:751

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-28
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug c++/85944] Address of member variable of temporary not considered constexpr at global scope

[david at doublewise dot net]

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

--- Comment #2 from David Stone  ---
I have simplified the bug. It does not require a member variable to trigger the
bug, just taking the address of a a temporary bound to a reference function
parameter at global scope:



constexpr bool f(int const & x) {
return 
}

constexpr auto x = f(0);





Note that this code does not trigger the bug:



int const & x = 0;
constexpr bool b = 

[Bug c++/85952] New: Bogus -Wunused-but-set-variable warning with array structured binding

[jakub at gcc dot gnu.org]

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

Bug ID: 85952
   Summary: Bogus -Wunused-but-set-variable warning with array
structured binding
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int
foo ()
{
  int a[2] = {1, 2};// { dg-bogus "set but not used" } */
  auto [x, y] = a;
  return x + y;
}

should not warn, but we handle the array temporary initialization from another
array for structured bindings quite specially.

[Bug fortran/63570] [F2015] Implement 13.7.137 RANDOM INIT (REPEATABLE, IMAGE DISTINCT)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.0

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

https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01596.html

[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Assigned directly :


$ cat z2.f90
program p
   character(:), allocatable :: z(:)
   call s(z)
contains
   subroutine s(x)
  character(:), allocatable :: x(:)
  x = ['abc']
  print *, allocated(x), size(x), len(x), x
   end
end


$ gfortran-9-20180527 z2.f90 -static-libgfortran
$ a.out
 T   1   3 abc

[Bug fortran/85953] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Just for completeness, this variant works :


$ cat z2.f90
program p
   character(:), allocatable :: x(:)
   x = [character :: 'a', 'b']
   x = [character :: x, 'c']
   print *, x
end


$ gfortran-9-20180527 z2.f90 -static-libgfortran
$ a.out
 abc

[Bug fortran/85953] New: [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370

[gs...@t-online.de]

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

Bug ID: 85953
   Summary: [6/7/8/9 Regression] ICE in fold_convert_loc, at
fold-const.c:2370
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions 6 to 9, gfortran-5 works :


$ cat z1.f90
program p
   character(:), allocatable :: x(:)
   x = [character :: 'a', 'b']
   x = ([character :: x, 'c'])
   print *, x
end


$ gfortran-5 z1.f90
$ a.out
 abc


$ gfortran-9-20180527 -c z1.f90
z1.f90:4:0:

x = ([character :: x, 'c'])

internal compiler error: Segmentation fault
0xba072f crash_signal
../../gcc/toplev.c:325
0x929b80 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2370
0x7621b0 gfc_alloc_allocatable_for_assignment(gfc_loopinfo*, gfc_expr*,
gfc_expr*)
../../gcc/fortran/trans-array.c:9935
0x786fc5 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10329
0x74af47 trans_code
../../gcc/fortran/trans.c:1828
0x772269 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701040 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701040 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x7480ef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c/85955] New: ICE in fold_convert_loc, at fold-const.c:2408

[gs...@t-online.de]

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

Bug ID: 85955
   Summary: ICE in fold_convert_loc, at fold-const.c:2408
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Derived from gcc/testsuite/gcc.dg/torture/pr85567.c, ICE at -O[s23] :


$ cat z1.c
extern void sincos(double x, double *sinx, double *cosx);
void apply(void (*f)(double, double *, double *),
   double x, double *sinx, double *cosx)
{
  f(x, sinx, cosx);
  return;
}
void apply_sincos(double x, double **sinx, double **cosx)
{
  apply(sincos, x, sinx, cosx);
  return;
}


$ gcc-9-20180527 -c z1.c -O2
z1.c: In function 'apply_sincos':
z1.c:10:20: warning: passing argument 3 of 'apply' from incompatible pointer
type [-Wincompatible-pointer-types]
   apply(sincos, x, sinx, cosx);
^~~~
z1.c:3:30: note: expected 'double *' but argument is of type 'double **'
double x, double *sinx, double *cosx)
  ^~~~
z1.c:10:26: warning: passing argument 4 of 'apply' from incompatible pointer
type [-Wincompatible-pointer-types]
   apply(sincos, x, sinx, cosx);
  ^~~~
z1.c:3:44: note: expected 'double *' but argument is of type 'double **'
double x, double *sinx, double *cosx)
^~~~
during GIMPLE pass: einline
z1.c:5:3: internal compiler error: in fold_convert_loc, at fold-const.c:2408
   f(x, sinx, cosx);
   ^~~~
0x87694f fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2407
0x8d36e5 gimplify_modify_expr
../../gcc/gimplify.c:5580
0x8ca23b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11440
0x8cc586 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6663
0x8cccb7 gimplify_compound_expr
../../gcc/gimplify.c:5889
0x8ca215 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11429
0x8cc586 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6663
0x8cc5d2 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:441
0x8a51f2 gimplify_and_update_call_from_tree(gimple_stmt_iterator*, tree_node*)
../../gcc/gimple-fold.c:551
0x8ad5aa gimple_fold_builtin
../../gcc/gimple-fold.c:3792
0x8b057b gimple_fold_call
../../gcc/gimple-fold.c:4158
0x8b057b fold_stmt_1
../../gcc/gimple-fold.c:4822
0xb54aef fold_marked_statements
../../gcc/tree-inline.c:4977
0xb5ef79 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5102
0x11bd3c3 early_inliner(function*)
../../gcc/ipa-inline.c:2782

[Bug fortran/85954] New: [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266

[gs...@t-online.de]

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

Bug ID: 85954
   Summary: [8/9 Regression] ICE in make_ssa_name_fn, at
tree-ssanames.c:266
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20170924 and 20171008, ICE at -O[s123] :


$ cat z1.f90
program p
   character(:), allocatable :: z(:)
   call s(z)
contains
   subroutine s(x)
  character(:), allocatable :: x(:)
  associate (y => x)
 y = ['abc']
  end associate
  print *, allocated(x), size(x), len(x), x
   end
end


$ gfortran-8-20170924 -c z1.f90 -O2
$
$ gfortran-9-20180527 -c z1.f90 -O2
during IPA pass: materialize-all-clones
z1.f90:3:0:

call s(z)

internal compiler error: Segmentation fault
0xba072f crash_signal
../../gcc/toplev.c:325
0xd690a7 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../gcc/tree-ssanames.c:266
0xc068ae make_ssa_name
../../gcc/tree-ssanames.h:115
0xc068ae remap_ssa_name
../../gcc/tree-inline.c:241
0xc0ba47 copy_tree_body_r(tree_node**, int*, void*)
../../gcc/tree-inline.c:1091
0xdee123 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11400
0xdee313 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11716
0xc061bc remap_type_1
../../gcc/tree-inline.c:574
0xc063b1 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:603
0xc061f6 remap_type_1
../../gcc/tree-inline.c:518
0xc063b1 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:603
0xc05ff8 remap_type_1
../../gcc/tree-inline.c:421
0xc063b1 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:603
0xc0c14b remap_gimple_op_r
../../gcc/tree-inline.c:948
0xdee123 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11400
0x975a5a walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:203
0xc074bc remap_gimple_stmt
../../gcc/tree-inline.c:1767
0xc0813e copy_bb
../../gcc/tree-inline.c:1817
0xc0962a copy_cfg_body
../../gcc/tree-inline.c:2730
0xc0962a copy_body
../../gcc/tree-inline.c:2973

[Bug c/85956] New: [9 Regression] ICE in wide_int_to_tree_1, at tree.c:1549

[gs...@t-online.de]

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

Bug ID: 85956
   Summary: [9 Regression] ICE in wide_int_to_tree_1, at
tree.c:1549
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180506 and 20180513, ICE at -O[s23].
Derived from gomp/pr85696.c :


$ cat z1.c
void
foo (int n, void *p)
{
  int (*a)[n] = (int (*)[n]) p;
  #pragma omp parallel shared(a) default(none)
  #pragma omp master
a[-1][-1] = 42;
}


$ gcc-9-20180527 -c z1.c -Wall -fopenmp -O1
$
$ gcc-9-20180527 -c z1.c -Wall -fopenmp -O2
'int[
during GIMPLE pass: vrp
In function 'foo._omp_fn.0':
in wide_int_to_tree_1, at tree.c:1549
   #pragma omp parallel shared(a) default(none)
   ^~~
0xd38643 wide_int_to_tree_1
../../gcc/tree.c:1549
0xd38bbb wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
../../gcc/tree.c:1674
0xd38bbb build_int_cst(tree_node*, poly_int<1u, long>)
../../gcc/tree.c:1342
0x701f60 c_pretty_printer::direct_abstract_declarator(tree_node*)
../../gcc/c-family/c-pretty-print.c:582
0x693ef3 c_tree_printer
../../gcc/c/c-objc-common.c:147
0x1257043 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1375
0x125004b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:984
0x12504c3 diagnostic_impl
../../gcc/diagnostic.c:1108
0x12508e0 warning_at(unsigned int, int, char const*, ...)
../../gcc/diagnostic.c:1223
0xd18056 vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
../../gcc/tree-vrp.c:4990
0xd247bf vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
../../gcc/tree-vrp.c:4876
0xd247bf check_array_bounds
../../gcc/tree-vrp.c:5090
0xd3e483 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11400
0x8c26e3 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:221
0xd11cfc check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-vrp.c:5144
0x1145c9f dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xd14e1c vrp_prop::check_all_array_refs()
../../gcc/tree-vrp.c:5161
0xd15d8d vrp_prop::vrp_finalize(bool)
../../gcc/tree-vrp.c:6937
0xd250d3 execute_vrp
../../gcc/tree-vrp.c:7010

[Bug c++/85952] Bogus -Wunused-but-set-variable warning with array structured binding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-28
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 44199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44199=edit
gcc9-pr85952.patch

Untested fix.

[Bug fortran/85942] ICE with PDTs

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Paul, from my side absolutely no urgency. Just stumbled over this example on
c.l.f. and wanted to play a bit.

[Bug c/85957] New: i686: Integers appear to be different, but compare as equal

[lukeshu at lukeshu dot com]

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

Bug ID: 85957
   Summary: i686: Integers appear to be different, but compare as
equal
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukeshu at lukeshu dot com
  Target Milestone: ---

Created attachment 44200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44200=edit
The preprocessed source

This is a bug that at first looks a bit like a "problems with floating
point numbers" bug.  However, my problem is with integers (calculated
from float types) behave inconsistently.

a6 = a.dbl * 1e6;
b6 = b.dbl * 1e6;
printf ("a6 = %llu\n", a6); // prints "1"
printf ("b6 = %llu\n", b6); // prints "0"
printf ("(a6 == b6) = %s\n", (a6 == b6) ? "true" : "false"); // prints
"true"

I understand why floating point math could result in a6 and b6 being
different; my concern is that a6 and b6 (which are integer types)
appear to be different, yet compare as being equal.

This happens on i686 with -O1 and -O2 (but not -O0), and not on
x86-64.

I apologize that my minimal testcase makes use of the glib-2.0
library; I'm having a hard time replicating the problem without it; it
seems GCC optimizing out a variable is key; and removing the library
use makes it not optimize it out.

Here is the output of gcc, including the appropriate version information:

$ gcc -v -save-temps -O1 $(pkg-config --libs --cflags glib-2.0) demo.c -o
demo

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I' '/usr/include/glib-2.0'
'-I' '/usr/lib/glib-2.0/include' '-o' 'demo' '-mtune=generic'
'-march=pentiumpro'
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/cc1 -E -quiet -v -I
/usr/include/glib-2.0 -I /usr/lib/glib-2.0/include demo.c -mtune=generic
-march=pentiumpro -O1 -fpch-preprocess -o demo.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/glib-2.0
 /usr/lib/glib-2.0/include
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I' '/usr/include/glib-2.0'
'-I' '/usr/lib/glib-2.0/include' '-o' 'demo' '-mtune=generic'
'-march=pentiumpro'
 /usr/lib/gcc/i686-pc-linux-gnu/7.3.1/cc1 -fpreprocessed demo.i -quiet
-dumpbase demo.c -mtune=generic -march=pentiumpro -auxbase demo -O1 -version -o
demo.s
GNU C11 (GCC) version 7.3.1 20180312 (i686-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 7.3.1 20180312 (i686-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b94f7ca39249d495c6913c6ded8c0b64
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I' '/usr/include/glib-2.0'
'-I' '/usr/lib/glib-2.0/include' '-o' 'demo' '-mtune=generic'
'-march=pentiumpro'
 as -v -I /usr/include/glib-2.0 -I /usr/lib/glib-2.0/include --32 -o demo.o
demo.s
GNU assembler version 2.30 (i686-pc-linux-gnu) using BFD version (GNU
Binutils) 2.30
   
COMPILER_PATH=/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i686-pc-linux-gnu/
   
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/:/usr/lib/gcc/i686-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I' 

[Bug libstdc++/85951] make_signed and make_unsigned are incorrect for wchar_t, char16_t, and char32_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I thought I'd fixed this, but my fix for PR 60326 was just wrong.

[Bug c++/85943] Template function permits derived class access to private base class static variable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Anthony Chuah from comment #0)
> This probably should be classified under meta-bug
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002

It's just a duplicate of one of the existing bugs there.

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

[Bug c++/58993] incorrectly accept access of protected member method from derived class template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||achuah at drwsg dot com

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

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>(calculated from float types)

Which is exactly just that.
64bit float point does not have 64bit of precision but rather 53bits.
On x86, since it uses 80bit fpu internally and does not round between the
intermediate steps which is why you are getting two different answers.

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

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lukeshu at lukeshu dot com

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

[Bug middle-end/85956] [9 Regression] ICE in wide_int_to_tree_1, at tree.c:1549

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||openmp
  Component|c   |middle-end
   Target Milestone|--- |9.0

[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-28
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #3 from Uroš Bizjak  ---
Created attachment 44201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44201=edit
Proposed patch

Patch that implements round/cvtt combination for SSE4.1 target.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[lukeshu at lukeshu dot com]

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

Luke Shumaker  changed:

   What|Removed |Added

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

--- Comment #2 from Luke Shumaker  ---
I do not believe that this is a duplicate of bug 323.  As I wrote:

> As I understand why floating point math could result in a6 and b6 being
> different; my concern is that a6 and b6 (which are integer types)
> appear to be different, yet compare as being equal.

"a6" and "b6" are both variables with types that resolve to "long long unsigned
integer".

printf ("a6 = %llu\n", a6); // prints "a6 = 1"
printf ("b6 = %llu\n", b6); // prints "b6 = 0"

That's fine, I understand that a6 and b6 could be different because of
differing round-off between intermediate steps.  That's not my concern.

Note that a6 and b6 have should have concrete values at this point, as we have
printed them.

My concern is the following:

printf ("(a6 == b6) = %s\n",
(a6 == b6) ? "true" : "false"); // prints "(a6 == b6) = true"

That is, the entire output of the POC program is:

a6 = 1
b6 = 0
a6 == b6

I am not concerned that a6 and b6 disagree, or that they are equal.  I am
concerned that *both* are true.

[Bug c++/85958] New: Make const qualifier error clear

[jg at jguk dot org]

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

Bug ID: 85958
   Summary: Make const qualifier error clear
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Calling a function with a const int seems to give such an obscure message, can
it be made clearer?


output:

$ g++ -o main main.cpp -Wall -Werror -Wconversion
main.cpp: In function ‘int main()’:
main.cpp:11:25: error: binding ‘const int’ to reference of type ‘int&’ discards
qualifiers
 strstripspace(unused);
 ^
main.cpp:5:6: note:   initializing argument 1 of ‘void strstripspace(int&)’
 void strstripspace(int & value);


Expected something clearer:
$ g++ -o main main.cpp -Wall -Werror -Wconversion
main.cpp: In function ‘int main()’:
main.cpp:11:25: error: passing ‘const int’ as reference of type ‘int&’ discards
qualifier const
 strstripspace(unused);
 ^
main.cpp:5:6: note:   initializing argument 1 of ‘void strstripspace(int&)’
 void strstripspace(int & value);




/* g++ -o main main.cpp -Wall -Werror -Wconversion */

#include 

void strstripspace(int & value)
{
return;
}

int main()
{
const int unused = 0;

strstripspace(unused);

return 0;
}

[Bug c++/85959] New: g++ doesn't show second error

[jg at jguk dot org]

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

Bug ID: 85959
   Summary: g++ doesn't show second error
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

g++ doesn't show both errors in the below example.

Also the carat is not accurate, showing carat 30, should be 20

Output:
$ g++ -o main main.cpp
main.cpp: In function ‘int main()’:
main.cpp:15:30: error: binding ‘const int’ to reference of type ‘int&’ discards
qualifiers
 strstripspace(unused, two);
  ^
main.cpp:5:6: note:   initializing argument 1 of ‘void strstripspace(int&,
int&)’
 void strstripspace(int & value, int & two)


Expected:
$ g++ -o main main.cpp
main.cpp: In function ‘int main()’:
main.cpp:15:20: error: binding ‘const int’ to reference of type ‘int&’ discards
qualifiers
 strstripspace(unused, two);
   ^
main.cpp:5:6: note:   initializing argument 1 of ‘void strstripspace(int&,
int&)’
 void strstripspace(int & value, int & two)

main.cpp:15:28: error: binding ‘const int’ to reference of type ‘int&’ discards
qualifiers
 strstripspace(unused, two);
^
main.cpp:5:6: note:   initializing argument 2 of ‘void strstripspace(int&,
int&)’
 void strstripspace(int & value, int & two)



/* g++ -o main main.cpp -Wall -Werror -Wconversion */

#include 

void strstripspace(int & value, int & two)
{
return;
}

int main()
{
const int unused = 0;
const int two = 0;

strstripspace(unused, two);

return 0;
}

[Bug fortran/82721] [7/8/9 Regression] Error message with corrupted text, sometimes ICE

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> (In reply to G. Steinmetz from comment #0)
> > This snippet (clearly invalid) gives a second error message
> > with randomly corrupted text :
> > 
> > 
> > $ cat z1.f90
> > program p
> >real :: a, b(4)
> >character(len(c)) :: b
> > end
> > 
> > 
> > $ gfortran-8-20171022 -c z1.f90
> > z1.f90:3:25:
> > 
> > character(len(c)) :: b
> >  1
> > Error: Symbol 'b' at (1) already has basic type of REAL
> > z1.f90:3:13:
> > 
> > character(len(c)) :: b
> >  1
> > Error: '\xa8\x8e\x1f\x8e+' at (1) is not a function
> 
> Interesting.  Must be an OS specific issue.
> 
> % gfcx -c r.f90
> r.f90:3:25:
> 
> character(len(c)) :: b
>  1
> Error: Symbol 'b' at (1) already has basic type of REAL
> r.f90:3:17:
> 
> character(len(c)) :: b
>  1
> Error: 'string' argument of 'len' intrinsic at (1) must be CHARACTER
> 
> % valgrind ~/work/libexec/gcc/x86_64-unknown-freebsd12.0/8.0.0/f951 r.f90
> ==68051== Memcheck, a memory error detector
> ==68051== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==68051== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
> ==68051== Command:
> /mnt/sgk/work/libexec/gcc/x86_64-unknown-freebsd12.0/8.0.0/f951 r.f90
> ==68051== 
> --68051-- WARNING: unhandled syscall: 552
> --68051-- You may be able to write your own handler.
> --68051-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --68051-- Nevertheless we consider this a bug.  Please report
> --68051-- it at http://valgrind.org/support/bug_reports.html.
> --68051-- WARNING: unhandled syscall: 551
> --68051-- You may be able to write your own handler.
> --68051-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --68051-- Nevertheless we consider this a bug.  Please report
> --68051-- it at http://valgrind.org/support/bug_reports.html.
> Cannot fstat "/usr/local/lib/valgrind/vgpreload_core-amd64-freebsd.so"
> ==68051== 
> ==68051== HEAP SUMMARY:
> ==68051== in use at exit: 0 bytes in 0 blocks
> ==68051==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==68051==

So, I looked at this on my i586-*-freebsd system.  Internal state seems
to be corrupted.  The problem can be avoided by the following patch

Index: resolve.c
===
--- resolve.c   (revision 260808)
+++ resolve.c   (working copy)
@@ -2937,16 +2937,23 @@ is_external_proc (gfc_symbol *sym)
 /* Figure out if a function reference is pure or not.  Also set the name
of the function for a potential error message.  Return nonzero if the
function is PURE, zero if not.  */
+
 static int
 pure_stmt_function (gfc_expr *, gfc_symbol *);

 static int
 pure_function (gfc_expr *e, const char **name)
 {
-  int pure;
+  int error_count, pure;
   gfc_component *comp;

   *name = NULL;
+
+  /* If gfortran gets here with an issued error and a BT_UNKNOWN type,
+ something has corrupted internal state.  Die instead of an ICE.  */
+  gfc_get_errors (NULL, _count);
+  if (error_count > 0 && e->ts.type == BT_UNKNOWN)
+gfc_fatal_error ("Invalid Fortran detected");

   if (e->symtree != NULL
 && e->symtree->n.sym != NULL

[Bug c++/85961] New: scratch register rsi used after function call

[bki at hacon dot de]

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

Bug ID: 85961
   Summary: scratch register rsi used after function call
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bki at hacon dot de
  Target Milestone: ---

Created attachment 44203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44203=edit
Minimal cpp-File producing the bug

With g++ 7.0.0 and g++ 7.3.0 and compiling the attached file as detailed in the
comments, produces an object file containing the following instruction
sequence:

  76:   48 89 c6mov%rax,%rsi
  79:   e8 82 ff ff ff  callq  0
<_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6lengthEv.isra.0>
  7e:   48 8d 14 06 lea(%rsi,%rax,1),%rdx

According to the System V AMD64 ABI
(https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf),
%rsi is a scratch register not preserved across function calls. I therefore
think that this instruction sequence is wrong.

Why is this a problem?

The function which is called does not clobber %rsi itself. But compiling with
'-pg -mfentry' will instrument that function call and allow a user specified
function to clobber %rsi. A call to __fentry__ should not clobber %rsi, since
%rsi is used for parameter passing and must be unchanged when __fentry__
returns. But by temporarily replacing the return address __fentry__ can
instrument the function exit. There, clobbering %rsi (and all other scratch
registers) should be acceptable.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #3)
> There is still rounding errors when it comes to the math you are doing.

Yes, but the issue here is much more serious, and I don't see this bug as a
duplicate (bug 323 is just a cause of this more serious bug).

While it has been accepted that a floating-point variable can be multi-valued
(except in C99/C11 modes), this must not be the case on a variable of integer
type, even though the value of such a variable has been computed from a
floating-point expression: Once a floating-point number has been converted into
an integer type, the value of this integer must be fixed.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Try -std=c99 or -fexcess-precision=standard which will get you the behavior you
want.

[Bug c++/79393] [7/8/9 Regression] cc1plus rejects valid code with noexcept

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  ---
Should this show up as a P1?

[Bug translation/85960] New: -fipa-pta and ifunc are incompatible

[gianni at scaramanga dot co.uk]

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

Bug ID: 85960
   Summary: -fipa-pta and ifunc are incompatible
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gianni at scaramanga dot co.uk
  Target Milestone: ---

Created attachment 44202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44202=edit
Minimal example showing the bug

-fipa-pta and ifuncs are incompatible, it looks like ifunc resolved functions
are treated as no-ops which seems to lead to erroneous conclusions about the
possible values of objects pointed to in such a functions parameters.

For example, if an ifunc has a pointer argument and all implementations of that
functions write to the pointed-to object, then we get a warning about that
object being read before being set - which is erroneous. Moreover we end up
with miscompiled code as a result of this.

[Bug fortran/85840] Memory leak in write.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon May 28 21:55:31 2018
New Revision: 260851

URL: https://gcc.gnu.org/viewcvs?rev=260851=gcc=rev
Log:
2018-05-28  Jerry DeLisle  

PR libgfortran/85840
* io/write.c (write_real, write_real_g0, write_complex): Use
separate local variables for the float string length.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write.c

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

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

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

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
There is still rounding errors when it comes to the math you are doing.

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

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[vincent-gcc at vinc17 dot net]

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

--- Comment #6 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #5)
> Try -std=c99 or -fexcess-precision=standard which will get you the behavior
> you want.

This is not what is documented: "By default, -fexcess-precision=fast is in
effect; this means that operations may be carried out in a wider precision than
the types specified in the source if that would result in faster code, and it
is unpredictable when rounding to the types specified in the source code takes
place."

This means that in

  double x = 1.1 * 1.2;

x can be kept with excess precision (typically 64 bits instead of 53) or can be
rounded to double depending on its use.

But here, one has:

  unsigned long long a6 = a.dbl * 1e6;

This is no longer just a rounding of a floating-point value, but a conversion
to an integer type. From -fexcess-precision=fast, one cannot decide whether a6
will be 0 or 1, but once the value of a6 has been observed, it should no longer
be allowed to change.

[Bug c/85962] New: spurious warning on right shift constant > integer in trivially dead code

[joshudson at gmail dot com]

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

Bug ID: 85962
   Summary: spurious warning on right shift constant > integer in
trivially dead code
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joshudson at gmail dot com
  Target Milestone: ---

spurious warning on right shift constant > integer when code would be
eliminated by optimization step because it is only reachable when the warning
would not occur

Complete code snippet:

typedef unsigned long size_t;
typedef unsigned int uint32_t;
#define SIZE_MAX 0x

size_t vfunc(uint32_t n)
{
if (n > SIZE_MAX)
return n >> (sizeof(size_t) * 8);
else
return (size_t)n;
}


This senseless function is reduced from a real function in code that can't
assume the size of size_t is large enough to hold uint32_t. Note that n >
SIZE_MAX is not going to happen when compiling for 64 bits and will be
optimized away, but it raises a warning anyway:

eportbug.c: In function ‘vfunc’:
reportbug.c:8:12: warning: right shift count >= width of type
[-Wshift-count-overflow]
   return n >> (sizeof(size_t) * 8);

If the code were not optimized away, the shift would not be out of range. I
compile with -O3 to get dead code elimination.

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

[Bug c/85962] spurious warning on right shift constant > integer in trivially dead code

[joshudson at gmail dot com]

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

--- Comment #1 from Joshua  ---
(first three lines is because you don't want bug reports with external header
files--3 lines is a lot better than all of stdint.h and limits.h)

[Bug middle-end/4210] should not warning with dead code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||joshudson at gmail dot com

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

[Bug c/85962] spurious warning on right shift constant > integer in trivially dead code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
THis is a dup of bug 4210.

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

[Bug c++/85963] New: false positive "set but not used" warning [-Wunused-but-set-variable]

[mcortez at airpost dot net]

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

Bug ID: 85963
   Summary: false positive "set but not used" warning
[-Wunused-but-set-variable]
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcortez at airpost dot net
  Target Milestone: ---

Related to, but not fixed by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82799

Getting an annoying false positive "set but not used" warning when compiling
with -Wall

g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1) on Fedora 28.  gcc was updated to
whatever the latest version is available in Fedora 28 update repos.

Reduced test case:

template
struct foo {
  T val, alpha;
  foo() : val(0), alpha(0) {}
  };

template
inline void bar(const foo& A, const foo& B, foo& C) {
  const bool use_alpha = true;
  const Talpha = use_alpha ? (A.alpha * B.alpha) : T(0);

  C.val   = A.val * B.val;
  C.alpha = alpha;
  }


int main() {
  foo A,B,C;

  bar(A,B,C);

  return 0;
  }


g++ gccwarn.cpp -o gccwarn -Wall -O2
gccwarn.cpp: In instantiation of ‘void bar(const foo&, const foo&,
foo&) [with T = double]’:
gccwarn.cpp:21:12:   required from here
gccwarn.cpp:10:14: warning: variable ‘use_alpha’ set but not used
[-Wunused-but-set-variable]
   const bool use_alpha = true;
  ^

[Bug c++/82728] [8 regression] Incorrect -Wunused-but-set-variable warning with a const

[mcortez at airpost dot net]

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

Michael Cortez  changed:

   What|Removed |Added

 CC||mcortez at airpost dot net

--- Comment #6 from Michael Cortez  ---
(In reply to Jason Merrill from comment #5)
> Fixed.

It seems to be broken again on gcc 8.1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85963

[Bug tree-optimization/85964] New: [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[asolokha at gmx dot com]

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

Bug ID: 85964
   Summary: [8/9 Regression] Compile time hog w/ -O3 -ftracer
-fno-guess-branch-probability
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha20180527 snapshot (r260810) and gcc 8.1 both take inordinate
time when compiling the following snippet w/ -O3 (-Ofast) -ftracer
-fno-guess-branch-probability:

int
px (int t8)
{
  int sw;

#pragma GCC unroll 128
  for (sw = 0; sw < 128; ++sw)
{
  int uu = 8;

  do
{
  int yq = 8;

  do
{
  t8 /= (t8 < 2) ? 1 : 3;
  --yq;
}
  while (yq > 0);

  --uu;
}
  while (uu > 0);
}

  return t8;
}

% timeout 30 gcc-9.0.0-alpha20180527 -O3 -ftracer -fno-guess-branch-probability
-c tzihxwey.c
zsh: exit 124   timeout 30 gcc-9.0.0-alpha20180527 -O3 -ftracer
-fno-guess-branch-probability

Not sure if it is a duplicate of PR69580 or not.

[Bug c++/85965] New: G++ gives cryptic error instead of incomplete type

[psmith at gnu dot org]

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

Bug ID: 85965
   Summary: G++ gives cryptic error instead of incomplete type
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

Compiling code with GCC 8.1 / binutils 2.30 (built locally on GNU/Linux amd64)
which previously compiled and worked OK with GCC 6.2 and 7.3.

I received a very cryptic error that had me running around reworking class
implementations for quite a while before I realized the problem: I had an
incomplete type.  I don't know if there's anything G++ could do better here,
but FYI I had this code:

class Bar
{
public:
struct Less
{
bool operator()(const Bar& lhs, const Bar& rhs) const;
bool operator()(const Bar* lhs, const Bar* rhs) const;
};
};

class Biz;

#include 

class Foo
{
std::set _map;
};

It's not immediately clear that the incomplete Biz class is a problem,
especially in my code which is significantly more complex and crosses multiple
header files, and G++ doesn't give a very helpful (to me) error:

$ g++ -o set.o -c set.cpp
In file included from x86_64-generic-linux-gnu/include/c++/8.1.0/set:60,
 from set.cpp:13:
x86_64-generic-linux-gnu/include/c++/8.1.0/bits/stl_tree.h: In instantiation of
'class std::_Rb_tree,
Bar::Less, std::allocator >':
x86_64-generic-linux-gnu/include/c++/8.1.0/bits/stl_set.h:133:17:   required
from 'class std::set'
set.cpp:17:37:   required from here
x86_64-generic-linux-gnu/include/c++/8.1.0/bits/stl_tree.h:452:21: error:
static assertion failed: comparison object must be invocable with two arguments
of key type
   static_assert(__is_invocable<_Compare&, const _Key&, const _Key&>{},
 ^

If I had included the complete type for class Biz, the compiler would have seen
that Biz is a subclass of Bar and it would have been fine; adding in the header
file fixed my problem:

class Bar
{
public:
struct Less
{
bool operator()(const Bar& lhs, const Bar& rhs) const;
bool operator()(const Bar* lhs, const Bar* rhs) const;
};
};

class Biz : public Bar
{}

#include 

class Foo
{
std::set _map;
};

Re: Remove support for FreeBSD 4.x (and earlier)

[Andreas Tobler]

On 28.05.18 08:57, Gerald Pfeifer wrote:

On Thu, 24 May 2018, Jeff Law wrote:

Happy to trust you on what versions can be dropped and the resulting
simplifications.

Is it worth noting those old versions as deprecated/obsolete in config.gcc?


Good catch, Jeff, thanks.  Updated patch (also wrt. comments) below.

Andreas, anyhing from your side?


Ok.
Thanks,
Andreas


Gerald

2018-05-27  Gerald Pfeifer  

* config.gcc: Identify FreeBSD 3.x and 4.x as unsupported.

* config/freebsd-spec.h (FBSD_LIB_SPEC): Only consider FreeBSD 5
and later.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 260808)
+++ gcc/config.gcc  (working copy)
@@ -268,7 +268,7 @@
   | pdp11-*-bsd\
   | sparc-hal-solaris2*\
   | thumb-*-*  \
- | *-*-freebsd[12] | *-*-freebsd[12].* \
+ | *-*-freebsd[12] | *-*-freebsd[1234].* \
   | *-*-freebsd*aout*  \
   | *-*-linux*aout*\
   | *-*-linux*coff*\
Index: gcc/config/freebsd-spec.h
===
--- gcc/config/freebsd-spec.h   (revision 260808)
+++ gcc/config/freebsd-spec.h   (working copy)
@@ -79,15 +79,10 @@
  #define FBSD_ENDFILE_SPEC \
"%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
  
-/* Provide a LIB_SPEC appropriate for FreeBSD as configured and as

-   required by the user-land thread model.  Before __FreeBSD_version
-   500016, select the appropriate libc, depending on whether we're
-   doing profiling or need threads support.  At __FreeBSD_version
-   500016 and later, when threads support is requested include both
-   -lc and the threading lib instead of only -lc_r.  To make matters
-   interesting, we can't actually use __FreeBSD_version provided by
-directly since it breaks cross-compiling.  As a final
-   twist, make it a hard error if -pthread is provided on the command
+/* When threads support is requested include both -lc and the threading
+   library (which assumes FreeBSD 5.x or later, __FreeBSD_version 500016
+   to be precise).
+   And make it a hard error if -pthread is provided on the command
 line and gcc was configured with --disable-threads (this will help
 avoid bug reports from users complaining about threading when they
 misconfigured the gcc bootstrap but are later consulting FreeBSD
@@ -106,19 +101,8 @@
  %{pg:  -lc_p} \
}"
  #else
-#if FBSD_MAJOR < 5
  #define FBSD_LIB_SPEC "  \
%{!shared:  \
-%{!pg: \
-  %{!pthread:-lc}  \
-  %{pthread:-lc_r}}
\
-%{pg:  \
-  %{!pthread:-lc_p}
\
-  %{pthread:-lc_r_p}}  \
-  }"
-#else
-#define FBSD_LIB_SPEC "   \
-  %{!shared:   \
  %{!pg: %{pthread:-lpthread} -lc}  \
  %{pg:  %{pthread:-lpthread_p} -lc_p}  \
}   \
@@ -126,8 +110,10 @@
  %{pthread:-lpthread} -lc  \
}"
  #endif
-#endif
  
+/* To make matters interesting, we can't actually use __FreeBSD_version

+   provided by  directly since it breaks cross-compiling.  */
+
  #if FBSD_MAJOR < 6
  #define FBSD_DYNAMIC_LINKER "/usr/libexec/ld-elf.so.1"
  #else

[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X

[rudolf.chrispens at web dot de]

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

--- Comment #14 from Rudolf  ---
Even if the compiler would just use the workaround with pragma-pack() when he
encounters this specific pragma would be fine. (If there is a warning for
that!)

Some Infomrations:
http://www.msg.ucsf.edu/local/programs/IBM_Compilers/C:C++/html/compiler/ref/rnpgalin.htm

Seems like I will have to use the MAC OS Clang compiler for now...

[Bug tree-optimization/85929] _GLIBCXX_ASSERTIONS, subscript type mismatch, and std::vector bounds check elimination

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Richard Biener from comment #2)
> So somehow we need to enhance the code in VRP that registers additional
> asserts to also handle symbolic ranges and thus register not only
> i_4 < count_8 but also (long int) i_4 < _16 in a usable form.

(long int) i_4 < _16 may not hold, _16 could easily be negative.

Re: [PATCH, rs6000] Remove incorrect built-in function documentation

[Segher Boessenkool]

Hi Kelvin,

On Wed, May 23, 2018 at 05:04:23PM -0500, Kelvin Nilsen wrote:
> The following two functions are removed because they are not implemented:
> 
>   vector float vec_copysign (vector float);
>   vector float vec_recip (vector float, vector float);

Should they be though?  The corresponding __builtin_* exist?  But I guess
no one has ever tried to use it even.

> The following six functions are removed because though they are implemented,
> they are not specified in the AltiVec PIM document and the type of the result
> vector does not match the type of the supplied pointer argument:
> 
>   vector signed int vec_lde (int, const long long *);
>   vector unsigned int vec_lde (int, const unsigned long long *);
> 
>   vector int vec_ld (int, long *)
>   vector unsigned int vec_ld (int, const unsigned long *);
> 
>   vector signed int vec_lvewx (int, long *);
>   vector unsigned int vec_lvewx (int, unsigned long *);

Ack.

> The following two functions are removed because they are not implemented. 
> Also, they are not specified in the AltiVec PIM document and the type of
> the result vector does not match the type of the supplied pointer argument:
> 
>   vector signed int vec_ldl (int, const long *);
>   vector unsigned int vec_ldl (int, const unsigned long *);

Ah, you're leaving vec_ldl, just removing this paremeter combination.  Ack.

> The following four functions are removed because they are not implemented. 
> They do happen to be specified in the AltiVec PIM document. Until they are
> implemented, they should not be documented:
> 
>   void vec_st (vector pixel, int, unsigned short *)
>   void vec_st (vector pixel, int, short *)
> 
>   void vec_stl (vector pixel, int, unsigned short *);
>   void vec_stl (vector pixel, int, short *);

If no one missed it so far, it is never going to happen :-)

> The following two functions are removed because they are not implemented.
> They are not specified in the AltiVec PIM or ABI v.2 documents:
> 
>   void vec_stvehx (vector pixel, int, short *);
>   void vec_stvehx (vector pixel, int, unsigned short *);
> 
> The following function was incompletely documented.  The argument list lacked
> a closing parenthesis.  There is no function by this name.
> 
>   test_vsi_packsu_vssi_vssi (vector signed short x,

Heh.


Okay for trunk.  Thanks!


Segher


> 2018-05-23  Kelvin Nilsen  
> 
>   * doc/extend.texi (PowerPC AltiVec Built-in Functions): Remove
>   descriptions of various incorrectly documented functions.

[Bug tree-optimization/85947] New: gcc.dg/vect/bb-slp-div-1.c XPASSes

[ro at gcc dot gnu.org]

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

Bug ID: 85947
   Summary: gcc.dg/vect/bb-slp-div-1.c XPASSes
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.*

Created attachment 44193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44193=edit
32-bit sparc-sun-solaris2.11 bb-slp-div-1.c.171t.slp2

The new gcc.dg/vect/bb-slp-div-1.c test XPASSes on Solaris/SPARC:

+XPASS: gcc.dg/vect/bb-slp-div-1.c -flto -ffat-lto-objects  scan-tree-dump slp2
"basic block vectorized"
+XPASS: gcc.dg/vect/bb-slp-div-1.c scan-tree-dump slp2 "basic block vectorized"

both 32 and 64-bit.

[Bug tree-optimization/85947] gcc.dg/vect/bb-slp-div-1.c XPASSes

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #4 from Paolo Carlini  ---
I don't understand, sorry. This isn't the same issue, is it? The initial issue
was that we don't want to pass the naked decl to lookup_attribute. Then, what
else? Anyway, this code got added with this patch (r218769):

https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01195.html

Let's add Honza in CC.

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #5 from Paolo Carlini  ---
Ah, Ok, I think I understand now. You mean, for our testsuite:

  DECL_REALLY_EXTERN (decl)
  && ((TREE_CODE (decl) != FUNCTION_DECL
   && !optimize)
  || (TREE_CODE (decl) == FUNCTION_DECL
  && !opt_for_fn (decl, optimize)))

is always false. Then does that mean we have another bug, ie the condition is
wrong, or more trivially that we aren't exercising the optimization?? Honza
unfortunately didn't add any testcases at the time...

[PATCH] [MSP430] Fix PR39240 execution failure for msp430-elf

[Jozef Lawrynowicz]

pr39240.c fails at execution at -O1 and above for msp430, due to an erroneous
subreg expression in the zero_extendqisi2 msp430 insn pattern. This causes the
zero extension operation to get optimized out.

The attached patch fixes the insn pattern, and also removes the msp430x ISA
restriction on zero_extendqisi2 and zero_extendhisi2. The assembly instructions
in these patterns can be used in the base MSP430 ISA; they are not MSP430x
specific.

Successfully regtested the GCC testsuite for msp430-elf in the
-mcpu=msp430x/-mlarge configuration.

If the patch is acceptable, I would appreciate if someone would commit it for
me, as I don't have write access.

>From 4f96a05f4849e28064f5c202a55b753b59a106ef Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Sun, 27 May 2018 21:09:49 +0100
Subject: [PATCH] MSP430: Fix PR39240 execution failure for msp430-elf

2018-05-28  Jozef Lawrynowicz  

	* gcc/config/msp430/msp430.md: Remove erroneous subreg expression from
	zero_extendqisi2 insn pattern. Remove msp430x ISA restriction on
	zero_extend{q,h}isi2.

---
 gcc/config/msp430/msp430.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/msp430/msp430.md b/gcc/config/msp430/msp430.md
index 869b9ee..614d375 100644
--- a/gcc/config/msp430/msp430.md
+++ b/gcc/config/msp430/msp430.md
@@ -619,15 +619,15 @@
 
 (define_insn "zero_extendqisi2"
   [(set (match_operand:SI 0 "nonimmediate_operand" "=r")
-	(zero_extend:SI (subreg:HI (match_operand:QI 1 "nonimmediate_operand" "rm") 0)))]
-  "msp430x"
+	(zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "rm")))]
+  ""
   "MOV.B\t%1,%L0 { CLR\t%H0"
 )
 
 (define_insn "zero_extendhisi2"
   [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r")
 	(zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "0,r")))]
-  "msp430x"
+  ""
   "@
   MOV.W\t#0,%H0
   MOV.W\t%1,%L0 { MOV.W\t#0,%H0"
-- 
2.7.4

[Bug target/85946] [9 regression] gcc.target/i386/avx512vl-vcvtudq2ps-2.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/85946] New: [9 regression] gcc.target/i386/avx512vl-vcvtudq2ps-2.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 85946
   Summary: [9 regression] gcc.target/i386/avx512vl-vcvtudq2ps-2.c
FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386-pc-solaris2.11, amd64-pc-solaris2.11

Between 20180522 (r260539) and 20180523 (r260615),
gcc.target/i386/avx512vl-vcvtudq2ps-2.c
started to FAIL on Solaris 11/x86 with /bin/as (64-bit only):

+FAIL: gcc.target/i386/avx512vl-vcvtudq2ps-2.c (test for excess errors)
+UNRESOLVED: gcc.target/i386/avx512vl-vcvtudq2ps-2.c compilation failed to
produce executable

Excess errors:
Assembler: avx512vl-vcvtudq2ps-2.c
"/var/tmp//ccpfakpd.s", line 139 : Invalid instruction argument
Near line: "vcvtusi2ss  -176(%rbp,%rax), %xmm0, %xmm0"

  Rainer

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Paolo Carlini  ---
Looking into it: just matter of using DECL_ATTRIBUTES (decl)?

[Bug target/85946] [9 regression] gcc.target/i386/avx512vl-vcvtudq2ps-2.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
ICC accepts it as well.  objdump disassembles it to (also showing the insn
itself):

   0:   62 f1 7e 08 7b 44 05vcvtusi2ss -0xb0(%rbp,%rax,1),%xmm0,%xmm0
   7:   d4

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Yes, I would just remove the entire block.

[Bug c/85948] New: printf format attribute warning line carat inaccurate

[jg at jguk dot org]

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

Bug ID: 85948
   Summary: printf format attribute warning line carat inaccurate
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Created attachment 44194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44194=edit
main

Reproduced in 8.1 and 5.4

1. I noticed the line carat 9 below is not accurate for the printf format
specifier

2. The later two also has missing carat lines.

3. Output below, and then expected output aafter

Output:

$ gcc -o main main.c -Wall -Werror -Wconversion
main.c: In function ‘main’:
main.c:19:9: error: format ‘%s’ expects argument of type ‘char *’, but argument
2 has type ‘int’ [-Werror=format=]
 str_fmt("%s %zu %s %s", d, str, str, d);
 ^
main.c:19:9: error: format ‘%zu’ expects argument of type ‘size_t’, but
argument 3 has type ‘const char *’ [-Werror=format=]
main.c:19:9: error: format ‘%s’ expects argument of type ‘char *’, but argument
5 has type ‘int’ [-Werror=format=]
cc1: all warnings being treated as errors


Expected:

$ gcc -o main main.c -Wall -Werror -Wconversion
main.c: In function ‘main’:
main.c:19:10: error: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘int’ [-Werror=format=]
 str_fmt("%s %zu %s %s", d, str, str, d);
  ^
main.c:19:13: error: format ‘%zu’ expects argument of type ‘size_t’, but
argument 3 has type ‘const char *’ [-Werror=format=]
 str_fmt("%s %zu %s %s", d, str, str, d);
 ^
main.c:19:20: error: format ‘%s’ expects argument of type ‘char *’, but
argument 5 has type ‘int’ [-Werror=format=]
 str_fmt("%s %zu %s %s", d, str, str, d);
^
cc1: all warnings being treated as errors

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
I see. Then I guess we need an explicit rationale for doing that, beyond the
evidence that we aren't ICEing: the check first blush looks sensible. At least
that was the case back in 2014, when Jason quickly approved it ;)

[PATCH] Fix doc/invoke.texi ARM buglet

[Jakub Jelinek]

Hi!

I've noticed
../../gcc/doc/invoke.texi:15971: warning: @itemx should not begin @table
errors, fixed thusly, committed as obvious to trunk.
Probably it needs backporting too.

2018-05-28  Jakub Jelinek  

* doc/invoke.texi (ARM Options): Use @item instead of @itemx
for armv5te.

--- gcc/doc/invoke.texi.jj  2018-05-25 14:34:35.589376306 +0200
+++ gcc/doc/invoke.texi 2018-05-28 12:11:59.028679696 +0200
@@ -15968,7 +15968,7 @@ The table below lists the supported exte
 Architectures not mentioned do not support any extensions.
 
 @table @samp
-@itemx armv5te
+@item armv5te
 @itemx armv6
 @itemx armv6j
 @itemx armv6k


Jakub

[Bug tree-optimization/85934] [8/9 Regression] ICE: verify_gimple failed (error: type mismatch in vector pack expression)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon May 28 10:28:38 2018
New Revision: 260847

URL: https://gcc.gnu.org/viewcvs?rev=260847=gcc=rev
Log:
2018-05-28  Richard Biener  

PR tree-optimization/85934
* tree-vect-generic.c (expand_vector_operations_1): Hoist
vector boolean check before scalar optimization.

* gcc.target/i386/pr85934.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr85934.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug tree-optimization/85934] [8 Regression] ICE: verify_gimple failed (error: type mismatch in vector pack expression)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] ICE:   |[8 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: type mismatch in|(error: type mismatch in
   |vector pack expression) |vector pack expression)
  Known to fail|9.0 |

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> Looking into it: just matter of using DECL_ATTRIBUTES (decl)?

The code is unreachable since the compiler would stop if it was reached.

Re: [PATCH GCC][5/6]implement live range, reg pressure computation class

[Richard Biener]

On Fri, May 18, 2018 at 1:57 PM Bin.Cheng  wrote:

> On Fri, May 4, 2018 at 5:23 PM, Bin Cheng  wrote:
> > Hi,
> > Based on previous patch, this one implements live range, reg pressure
computation
> > class in tree-ssa-live.c.  The user would only need to instantiate the
class and
> > call the computation interface as in next patch.
> > During the work, I think it's also worthwhile to classify all live
range and coalesce
> > data structures and algorithms in the future.
> >
> > Bootstrap and test on x86_64 and AArch64 ongoing.  Any comments?

> Updated patch in line with change of previous patch.

So I see you do not want to expose the magic '16' in pressure_threshold to
the
user because in theory the target should provide enough information.  But
why
need it at all?  Also

+  /* Calculate maximum reg pressure information for region and store it in
+ MAX_PRESSURE.  Return true if the reg pressure is high.  */
+  bool calculate_pressure (unsigned *max_pressure);

it looks like you expect a [N_REG_CLASSES] sized output array here, that's
not
clear from the documentation.

The output information is a little shallow - I'd be interested in the
number of
live through region regs being separated from live in / out.  That is, can
you
add additional outputs to the above and thus make it more like

   bool calculate_pressure (unsigned max_pressure[], unsigned live_in[],
unsigned live_out[], unsigned live_through[]);

with the numbers being on the region?

It also seems to be a fire-and-forget class so I wonder why liveness is not
computed at construction
time so intermediate data can be freed and only the results stored?

stmt_lr_info -> id seems to be unused?  In fact what is the point of this
structure (and the per stmt bitmap)?
It looks write-only to me...

Thanks and sorry for the delay in review.
Richard.

> Thanks,
> bin
> >
> > Thanks,
> > bin
> > 2018-04-27  Bin Cheng  
> >
> > * tree-ssa-live.c (memmodel.h, ira.h, tree-ssa-coalesce.h):
Include.
> > (struct stmt_lr_info, free_stmt_lr_info): New.
> > (lr_region::lr_region, lr_region::~lr_region): New.
> > (lr_region::create_stmt_lr_info): New.
> > (lr_region::update_live_range_by_stmt): New.
> > (lr_region::calculate_coalesced_pressure): New.
> > (lr_region::calculate_pressure): New.
> > * tree-ssa-live.h (struct stmt_lr_info): New declaration.
> > (class lr_region): New class.

Re: [PATCH 1/3] Add vec::reverse.

[Richard Biener]

On Fri, May 25, 2018 at 1:04 PM marxin  wrote:


> gcc/ChangeLog:

> 2018-05-25  Martin Liska  
>  David Malcolm  

>  * vec.c (test_reverse): New.
>  (vec_c_tests): Add new test.
>  * vec.h (vl_ptr>::reverse): New function.

OK.
Richard.

> ---
>   gcc/vec.c | 38 ++
>   gcc/vec.h | 14 ++
>   2 files changed, 52 insertions(+)

[Bug c/85949] New: __attribute__ ((format (printf,1,1))); improve error messages

[jg at jguk dot org]

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

Bug ID: 85949
   Summary: __attribute__ ((format (printf,1,1)));  improve error
messages
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Created attachment 44195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44195=edit
main

Hello

This is very useful!

Could the build errors be clearer?

I found this online which describes the parameter order

https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax

Also, could the carat be accurate on the output, it is stuck at char 1.

I included two examples (2,3) and (1,1) below
It would actually require (1,2) to compile.

Output:

~$ gcc -o main main.c -Wall -Werror -Wconversion
main.c:7:1: error: format string argument is not a string type
 void str_fmt(const char * const format, ...) __attribute__ ((format
(printf,2,3)));
 ^
jonny@asus:~$ gcc -o main main.c -Wall -Werror -Wconversion
main.c:7:1: error: format string argument follows the args to be formatted
 void str_fmt(const char * const format, ...) __attribute__ ((format
(printf,1,1)));
 ^


Expected:

jonny@asus:~$ gcc -o main main.c -Wall -Werror -Wconversion
main.c:7:1: error: format string argument variadic list follows the args to be
formatted
 void str_fmt(const char * const format, ...) __attribute__ ((format
(printf,1,1)));
 ^

~$ gcc -o main main.c -Wall -Werror -Wconversion
main.c:7:78: error: format string argument ‘2’ is not a string type
 void str_fmt(const char * const format, ...) __attribute__ ((format
(printf,2,3)));
 ^
main.c:7:80: error: format string argument ‘3’ is not present
 void str_fmt(const char * const format, ...) __attribute__ ((format
(printf,2,3)));
  
^

[PATCH] Introduce VEC_UNPACK_FIX_TRUNC_{LO,HI}_EXPR and VEC_PACK_FLOAT_EXPR, use it in x86 vectorization (PR target/85918)

[Jakub Jelinek]

Hi!

AVX512DQ and AVX512DQ/AVX512VL has instructions for vector float <->
{,unsigned} long long conversions.  The following patch adds the missing
tree codes, optabs and expanders to make this possible.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-05-28  Jakub Jelinek  

PR target/85918
* tree.def (VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
VEC_PACK_FLOAT_EXPR): New tree codes.
* tree-pretty-print.c (op_code_prio): Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR.
(dump_generic_node): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
* tree-inline.c (estimate_operator_cost): Likewise.
* gimple-pretty-print.c (dump_binary_rhs): Handle VEC_PACK_FLOAT_EXPR.
* fold-const.c (const_binop): Likewise.
(const_unop): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR and
VEC_UNPACK_FIX_TRUNC_LO_EXPR.
* tree-cfg.c (verify_gimple_assign_unary): Likewise.
(verify_gimple_assign_binary): Handle VEC_PACK_FLOAT_EXPR.
* cfgexpand.c (expand_debug_expr): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
* expr.c (expand_expr_real_2): Likewise.
* optabs.def (vec_packs_float_optab, vec_packu_float_optab,
vec_unpack_sfix_trunc_hi_optab, vec_unpack_sfix_trunc_lo_optab,
vec_unpack_ufix_trunc_hi_optab, vec_unpack_ufix_trunc_lo_optab): New
optabs.
* optabs.c (expand_widen_pattern_expr): For
VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR use
sign from result type rather than operand's type.
(expand_binop_directly): For vec_packu_float_optab and
vec_packs_float_optab allow result type to be different from operand's
type.
* optabs-tree.c (optab_for_tree_code): Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
VEC_PACK_FLOAT_EXPR.  Formatting fixes.
* tree-vect-generic.c (expand_vector_operations_1):  Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
VEC_PACK_FLOAT_EXPR.
* tree-vect-stmts.c (supportable_widening_operation): Handle
FIX_TRUNC_EXPR.
(supportable_narrowing_operation): Handle FLOAT_EXPR.
* config/i386/i386.md (fixprefix, floatprefix): New code attributes.
* config/i386/sse.md (*floatv2div2sf2): Rename to ...
(floatv2div2sf2): ... this.  Formatting fix.
(vpckfloat_concat_mode, vpckfloat_temp_mode, vpckfloat_op_mode): New
mode attributes.
(vec_pack_float_): New expander.
(vunpckfixt_mode, vunpckfixt_model, vunpckfixt_extract_mode): New mode
attributes.
(vec_unpack_fix_trunc_lo_,
vec_unpack_fix_trunc_hi_): New expanders.
* doc/md.texi (vec_packs_float_@var{m}, vec_packu_float_@var{m},
vec_unpack_sfix_trunc_hi_@var{m}, vec_unpack_sfix_trunc_lo_@var{m},
vec_unpack_ufix_trunc_hi_@var{m}, vec_unpack_ufix_trunc_lo_@var{m}):
Document.
* doc/generic.texi (VEC_UNPACK_FLOAT_HI_EXPR,
VEC_UNPACK_FLOAT_LO_EXPR): Fix pasto in description.
(VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
VEC_PACK_FLOAT_EXPR): Document.

* gcc.target/i386/avx512dq-pr85918.c: Add -mprefer-vector-width=512
and -fno-vect-cost-model options.  Add aligned(64) attribute to the
arrays.  Add suffix 1 to all functions and use 4 iterations rather
than N.  Add functions with conversions to and from float.
Add new set of functions with 8 iterations and another one
with 16 iterations, expect 24 vectorized loops instead of just 4.
* gcc.target/i386/avx512dq-pr85918-2.c: New test.

--- gcc/tree.def.jj 2018-05-26 23:03:55.321873256 +0200
+++ gcc/tree.def2018-05-27 12:54:55.040197121 +0200
@@ -1371,6 +1371,15 @@ DEFTREECODE (VEC_UNPACK_LO_EXPR, "vec_un
 DEFTREECODE (VEC_UNPACK_FLOAT_HI_EXPR, "vec_unpack_float_hi_expr", tcc_unary, 
1)
 DEFTREECODE (VEC_UNPACK_FLOAT_LO_EXPR, "vec_unpack_float_lo_expr", tcc_unary, 
1)
 
+/* Unpack (extract) the high/low elements of the input vector, convert
+   floating point values to integer and widen elements into the output
+   vector.  The input vector has twice as many elements as the output
+   vector, that are half the size of the elements of the output vector.  */
+DEFTREECODE (VEC_UNPACK_FIX_TRUNC_HI_EXPR, "vec_unpack_fix_trunc_hi_expr",
+tcc_unary, 1)
+DEFTREECODE (VEC_UNPACK_FIX_TRUNC_LO_EXPR, "vec_unpack_fix_trunc_lo_expr",
+tcc_unary, 1)
+
 /* Pack (demote/narrow and merge) the elements of the two input vectors
into the output vector using truncation/saturation.
The elements of the input vectors are twice the size of the elements of the
@@ -1384,6 +1393,12 @@ DEFTREECODE (VEC_PACK_SAT_EXPR, 

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

[jhasse at bixense dot com]

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

--- Comment #8 from Jan Niklas Hasse  ---
Thanks! If I understand it correctly this will go into 8.1.2?

[Bug target/85946] [9 regression] gcc.target/i386/avx512vl-vcvtudq2ps-2.c FAILs

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
There is nothing wrong with the insn mnemonic, it converts SImode value from
memory to SFmode float register. This insn is different from vcvtusi2ssq.

[Bug middle-end/85933] [9 Regression] FAIL: gcc.dg/sso/p8.c -O3 -finline-functions (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug middle-end/85933] [9 Regression] FAIL: gcc.dg/sso/p8.c -O3 -finline-functions (internal compiler error)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon May 28 10:31:46 2018
New Revision: 260848

URL: https://gcc.gnu.org/viewcvs?rev=260848=gcc=rev
Log:
2018-05-28  Richard Biener  

PR tree-optimization/85933
* tree-vect-data-refs.c (vect_record_base_alignments): Only
look at stmts marked as vectorizable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-data-refs.c

Re: [PATCH] PR target/85358 patch v2: Add target hook to prevent default widening

[Segher Boessenkool]

On Fri, May 25, 2018 at 02:49:47PM -0400, Michael Meissner wrote:
>   * target.def (default_fp_widening_p): New target hook to automatic
>   widening betwen two floating point modes.

"default" is a pretty bad name.

The rs6000 parts are fine of course, if the rest is.


Segher

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
The code is intended to avoid specializations that are done only to possibly
inline the function. When not optimizing this only happens for always inlines
and doing so is just waste of effort.

In this case you have method keyed to other compilation unit. I will check what
flags we get in this case.

[Bug target/85945] [6/7/8/9 Regression] ICE in resolve_subreg_use, at lower-subreg.c:751

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Where is the testcase?

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  ---
Not sure about the first decl_needed_p call in emit_tinfo_decl.

Re: [PATCH] Introduce VEC_UNPACK_FIX_TRUNC_{LO,HI}_EXPR and VEC_PACK_FLOAT_EXPR, use it in x86 vectorization (PR target/85918)

[Uros Bizjak]

On Mon, May 28, 2018 at 11:58 AM, Jakub Jelinek  wrote:
> Hi!
>
> AVX512DQ and AVX512DQ/AVX512VL has instructions for vector float <->
> {,unsigned} long long conversions.  The following patch adds the missing
> tree codes, optabs and expanders to make this possible.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-05-28  Jakub Jelinek  
>
> PR target/85918
> * tree.def (VEC_UNPACK_FIX_TRUNC_HI_EXPR, 
> VEC_UNPACK_FIX_TRUNC_LO_EXPR,
> VEC_PACK_FLOAT_EXPR): New tree codes.
> * tree-pretty-print.c (op_code_prio): Handle
> VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR.
> (dump_generic_node): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
> VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
> * tree-inline.c (estimate_operator_cost): Likewise.
> * gimple-pretty-print.c (dump_binary_rhs): Handle VEC_PACK_FLOAT_EXPR.
> * fold-const.c (const_binop): Likewise.
> (const_unop): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR and
> VEC_UNPACK_FIX_TRUNC_LO_EXPR.
> * tree-cfg.c (verify_gimple_assign_unary): Likewise.
> (verify_gimple_assign_binary): Handle VEC_PACK_FLOAT_EXPR.
> * cfgexpand.c (expand_debug_expr): Handle 
> VEC_UNPACK_FIX_TRUNC_HI_EXPR,
> VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
> * expr.c (expand_expr_real_2): Likewise.
> * optabs.def (vec_packs_float_optab, vec_packu_float_optab,
> vec_unpack_sfix_trunc_hi_optab, vec_unpack_sfix_trunc_lo_optab,
> vec_unpack_ufix_trunc_hi_optab, vec_unpack_ufix_trunc_lo_optab): New
> optabs.
> * optabs.c (expand_widen_pattern_expr): For
> VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR use
> sign from result type rather than operand's type.
> (expand_binop_directly): For vec_packu_float_optab and
> vec_packs_float_optab allow result type to be different from operand's
> type.
> * optabs-tree.c (optab_for_tree_code): Handle
> VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
> VEC_PACK_FLOAT_EXPR.  Formatting fixes.
> * tree-vect-generic.c (expand_vector_operations_1):  Handle
> VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
> VEC_PACK_FLOAT_EXPR.
> * tree-vect-stmts.c (supportable_widening_operation): Handle
> FIX_TRUNC_EXPR.
> (supportable_narrowing_operation): Handle FLOAT_EXPR.
> * config/i386/i386.md (fixprefix, floatprefix): New code attributes.
> * config/i386/sse.md (*floatv2div2sf2): Rename to ...
> (floatv2div2sf2): ... this.  Formatting fix.
> (vpckfloat_concat_mode, vpckfloat_temp_mode, vpckfloat_op_mode): New
> mode attributes.
> (vec_pack_float_): New expander.
> (vunpckfixt_mode, vunpckfixt_model, vunpckfixt_extract_mode): New mode
> attributes.
> (vec_unpack_fix_trunc_lo_,
> vec_unpack_fix_trunc_hi_): New expanders.
> * doc/md.texi (vec_packs_float_@var{m}, vec_packu_float_@var{m},
> vec_unpack_sfix_trunc_hi_@var{m}, vec_unpack_sfix_trunc_lo_@var{m},
> vec_unpack_ufix_trunc_hi_@var{m}, vec_unpack_ufix_trunc_lo_@var{m}):
> Document.
> * doc/generic.texi (VEC_UNPACK_FLOAT_HI_EXPR,
> VEC_UNPACK_FLOAT_LO_EXPR): Fix pasto in description.
> (VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
> VEC_PACK_FLOAT_EXPR): Document.
>
> * gcc.target/i386/avx512dq-pr85918.c: Add -mprefer-vector-width=512
> and -fno-vect-cost-model options.  Add aligned(64) attribute to the
> arrays.  Add suffix 1 to all functions and use 4 iterations rather
> than N.  Add functions with conversions to and from float.
> Add new set of functions with 8 iterations and another one
> with 16 iterations, expect 24 vectorized loops instead of just 4.
> * gcc.target/i386/avx512dq-pr85918-2.c: New test.

LGTM for the x86 part.

Thanks,
Uros.

> --- gcc/tree.def.jj 2018-05-26 23:03:55.321873256 +0200
> +++ gcc/tree.def2018-05-27 12:54:55.040197121 +0200
> @@ -1371,6 +1371,15 @@ DEFTREECODE (VEC_UNPACK_LO_EXPR, "vec_un
>  DEFTREECODE (VEC_UNPACK_FLOAT_HI_EXPR, "vec_unpack_float_hi_expr", 
> tcc_unary, 1)
>  DEFTREECODE (VEC_UNPACK_FLOAT_LO_EXPR, "vec_unpack_float_lo_expr", 
> tcc_unary, 1)
>
> +/* Unpack (extract) the high/low elements of the input vector, convert
> +   floating point values to integer and widen elements into the output
> +   vector.  The input vector has twice as many elements as the output
> +   vector, that are half the size of the elements of the output vector.  */
> +DEFTREECODE (VEC_UNPACK_FIX_TRUNC_HI_EXPR, "vec_unpack_fix_trunc_hi_expr",
> +tcc_unary, 1)
> +DEFTREECODE (VEC_UNPACK_FIX_TRUNC_LO_EXPR, "vec_unpack_fix_trunc_lo_expr",
> +   

[PATCH] Update comment about the format of attribute name in attribute_spec handler

[Jozef Lawrynowicz]

With the changes in r250911 to canonicalize attribute names (i.e. remove
leading and trailing underscores if present) a comment for "handler" in
the attribute_spec struct needs to be updated to reflect that the NAME argument
is now stripped of any underscores.

Patch is attached.

If the patch is acceptable, I would appreciate if someone would commit it for
me, as I don't have write access.

>From 386f8e6aadf5627fcba0955a8dbb6abcec69b1a5 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Mon, 28 May 2018 13:04:12 +0100
Subject: [PATCH] Update comment about the format of attribute name in
 attribute_spec handler

2018-05-28  Jozef Lawrynowicz  

	* gcc/tree-core.h: Update comment about the format of NAME string
	passed to handler in attribute_spec.

---
 gcc/tree-core.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index 478c631..f7be51f 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1942,14 +1942,14 @@ struct attribute_spec {
   bool affects_type_identity;
   /* Function to handle this attribute.  NODE points to the node to which
  the attribute is to be applied.  If a DECL, it should be modified in
- place; if a TYPE, a copy should be created.  NAME is the name of the
- attribute (possibly with leading or trailing __).  ARGS is the TREE_LIST
- of the arguments (which may be NULL).  FLAGS gives further information
- about the context of the attribute.  Afterwards, the attributes will
- be added to the DECL_ATTRIBUTES or TYPE_ATTRIBUTES, as appropriate,
- unless *NO_ADD_ATTRS is set to true (which should be done on error,
- as well as in any other cases when the attributes should not be added
- to the DECL or TYPE).  Depending on FLAGS, any attributes to be
+ place; if a TYPE, a copy should be created.  NAME is the canonicalized
+ name of the attribute i.e. without any leading or trailing underscores.
+ ARGS is the TREE_LIST of the arguments (which may be NULL).  FLAGS gives
+ further information about the context of the attribute.  Afterwards, the
+ attributes will be added to the DECL_ATTRIBUTES or TYPE_ATTRIBUTES, as
+ appropriate, unless *NO_ADD_ATTRS is set to true (which should be done on
+ error, as well as in any other cases when the attributes should not be
+ added to the DECL or TYPE).  Depending on FLAGS, any attributes to be
  applied to another type or DECL later may be returned;
  otherwise the return value should be NULL_TREE.  This pointer may be
  NULL if no special handling is required beyond the checks implied
-- 
2.7.4

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[stefantalpalaru at yahoo dot com]

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

Stefan Talpalaru  changed:

   What|Removed |Added

 CC||stefantalpalaru at yahoo dot 
com

--- Comment #16 from Stefan Talpalaru  ---
I found a new case that is unrelated to the use of -fprofile-generate=directory
or the existence of multiple *.gcda files with the same name in different
directories.

The problem appears in Python-2.7.15 when building the extensions with PGO,
using gcc-7.3.0 or gcc-8.1.0 on Gentoo ~amd64:

[...]/cpython-2.7.15/Modules/timemodule.c:1162:1: internal compiler error: in
output_profile_summary, at lto-cgraph.c:705
 }
 ^

Detailed instructions for replicating the ICE:
https://gist.github.com/stefantalpalaru/a1f31b9dff6c2227999e32781741dd01

Serializing the profiling task does not help, nor does adding
-fprofile-update=atomic to the profile generation phase.

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
It seems that for the potentially interesting cases DECL_EXTERNAL is true but
DECL_REALLY_EXTERN is false.

[Bug target/85945] [6/7/8/9 Regression] ICE in resolve_subreg_use, at lower-subreg.c:751

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Is missing :)

Here it is:

typedef float b;
typedef b __attribute__((vector_size(16))) c;
typedef union {
  c d;
  b a[4];
} e;
int f;
b g[4];
void h() {
  c d;
  e i;
  i.d = d;
  f = 0;
  for (; f < 4; f++)
g[f] = i.a[f];
}

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Assignee|paolo.carlini at oracle dot com|hubicka at ucw dot cz

--- Comment #10 from Paolo Carlini  ---
Thanks Honza. Note that normally (in decl2.c, rtti.c) we call decl_needed_p
*only* when DECL_NOT_REALLY_EXTERN is false or even DECL_EXTERNAL is false!
Thus the check indeed seems redundant.

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
I meant of course DECL_NOT_REALLY_EXTERN is true.

[PATCH] [MSP430] Fix -fleading-underscore having no effect

[Jozef Lawrynowicz]

Fix -fleading-underscore having no effect for msp430-elf by prepending
user_label_prefix to name when outputting assembly labels.

Successfully regtested the GCC testsuite for msp430-elf, and this fixed
unwind-1.c from dg.exp.

If the patch is acceptable, I would appreciate if someone would commit it for
me, as I don't have write access.

>From 4b9fc3e0bf3e746c6be95c994f5ea4882dcd3e1d Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Wed, 23 May 2018 21:52:24 +0100
Subject: [PATCH] MSP430: Fix -fleading-underscore having no effect

2018-05-28  Jozef Lawrynowicz  

	* gcc/config/msp430/msp430.c (msp430_output_labelref): Prepend
	user_label_prefix to name.

---
 gcc/config/msp430/msp430.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index adde597..8c8e676 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3416,6 +3416,9 @@ msp430_output_labelref (FILE *file, const char *name)
 	}
 }
 
+  if (user_label_prefix[0] != 0)
+fputs (user_label_prefix, file);
+
   fputs (name, file);
 }
 
-- 
2.7.4

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
(In reply to Stefan Talpalaru from comment #16)
> I found a new case that is unrelated to the use of
> -fprofile-generate=directory or the existence of multiple *.gcda files with
> the same name in different directories.
> 
> The problem appears in Python-2.7.15 when building the extensions with PGO,
> using gcc-7.3.0 or gcc-8.1.0 on Gentoo ~amd64:
> 
> [...]/cpython-2.7.15/Modules/timemodule.c:1162:1: internal compiler error:
> in output_profile_summary, at lto-cgraph.c:705
>  }
>  ^
> 
> Detailed instructions for replicating the ICE:
> https://gist.github.com/stefantalpalaru/a1f31b9dff6c2227999e32781741dd01
> 
> Serializing the profiling task does not help, nor does adding
> -fprofile-update=atomic to the profile generation phase.

I can confirm that, let me dig into it.

Re: [PATCH] Introduce VEC_UNPACK_FIX_TRUNC_{LO,HI}_EXPR and VEC_PACK_FLOAT_EXPR, use it in x86 vectorization (PR target/85918)

[Richard Biener]

On Mon, 28 May 2018, Jakub Jelinek wrote:

> Hi!
> 
> AVX512DQ and AVX512DQ/AVX512VL has instructions for vector float <->
> {,unsigned} long long conversions.  The following patch adds the missing
> tree codes, optabs and expanders to make this possible.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Apart from

--- gcc/tree-cfg.c.jj   2018-05-26 23:03:55.361873297 +0200
+++ gcc/tree-cfg.c  2018-05-27 12:54:55.046197128 +0200
@@ -3676,6 +3676,8 @@ verify_gimple_assign_unary (gassign *stm
 case VEC_UNPACK_LO_EXPR:
 case VEC_UNPACK_FLOAT_HI_EXPR:
 case VEC_UNPACK_FLOAT_LO_EXPR:
+case VEC_UNPACK_FIX_TRUNC_HI_EXPR:
+case VEC_UNPACK_FIX_TRUNC_LO_EXPR:
   /* FIXME.  */
   return false;
 

the middle-end changes look OK.  Can you please add verification
for the new codes here?

Thanks,
Richard.

> 2018-05-28  Jakub Jelinek  
> 
>   PR target/85918
>   * tree.def (VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
>   VEC_PACK_FLOAT_EXPR): New tree codes.
>   * tree-pretty-print.c (op_code_prio): Handle
>   VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR.
>   (dump_generic_node): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
>   VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
>   * tree-inline.c (estimate_operator_cost): Likewise.
>   * gimple-pretty-print.c (dump_binary_rhs): Handle VEC_PACK_FLOAT_EXPR.
>   * fold-const.c (const_binop): Likewise.
>   (const_unop): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR and
>   VEC_UNPACK_FIX_TRUNC_LO_EXPR.
>   * tree-cfg.c (verify_gimple_assign_unary): Likewise.
>   (verify_gimple_assign_binary): Handle VEC_PACK_FLOAT_EXPR.
>   * cfgexpand.c (expand_debug_expr): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
>   VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
>   * expr.c (expand_expr_real_2): Likewise.
>   * optabs.def (vec_packs_float_optab, vec_packu_float_optab,
>   vec_unpack_sfix_trunc_hi_optab, vec_unpack_sfix_trunc_lo_optab,
>   vec_unpack_ufix_trunc_hi_optab, vec_unpack_ufix_trunc_lo_optab): New
>   optabs.
>   * optabs.c (expand_widen_pattern_expr): For
>   VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR use
>   sign from result type rather than operand's type.
>   (expand_binop_directly): For vec_packu_float_optab and
>   vec_packs_float_optab allow result type to be different from operand's
>   type.
>   * optabs-tree.c (optab_for_tree_code): Handle
>   VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
>   VEC_PACK_FLOAT_EXPR.  Formatting fixes.
>   * tree-vect-generic.c (expand_vector_operations_1):  Handle
>   VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
>   VEC_PACK_FLOAT_EXPR.
>   * tree-vect-stmts.c (supportable_widening_operation): Handle
>   FIX_TRUNC_EXPR.
>   (supportable_narrowing_operation): Handle FLOAT_EXPR.
>   * config/i386/i386.md (fixprefix, floatprefix): New code attributes.
>   * config/i386/sse.md (*floatv2div2sf2): Rename to ...
>   (floatv2div2sf2): ... this.  Formatting fix.
>   (vpckfloat_concat_mode, vpckfloat_temp_mode, vpckfloat_op_mode): New
>   mode attributes.
>   (vec_pack_float_): New expander.
>   (vunpckfixt_mode, vunpckfixt_model, vunpckfixt_extract_mode): New mode
>   attributes.
>   (vec_unpack_fix_trunc_lo_,
>   vec_unpack_fix_trunc_hi_): New expanders.
>   * doc/md.texi (vec_packs_float_@var{m}, vec_packu_float_@var{m},
>   vec_unpack_sfix_trunc_hi_@var{m}, vec_unpack_sfix_trunc_lo_@var{m},
>   vec_unpack_ufix_trunc_hi_@var{m}, vec_unpack_ufix_trunc_lo_@var{m}):
>   Document.
>   * doc/generic.texi (VEC_UNPACK_FLOAT_HI_EXPR,
>   VEC_UNPACK_FLOAT_LO_EXPR): Fix pasto in description.
>   (VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
>   VEC_PACK_FLOAT_EXPR): Document.
> 
>   * gcc.target/i386/avx512dq-pr85918.c: Add -mprefer-vector-width=512
>   and -fno-vect-cost-model options.  Add aligned(64) attribute to the
>   arrays.  Add suffix 1 to all functions and use 4 iterations rather
>   than N.  Add functions with conversions to and from float.
>   Add new set of functions with 8 iterations and another one
>   with 16 iterations, expect 24 vectorized loops instead of just 4.
>   * gcc.target/i386/avx512dq-pr85918-2.c: New test.
> 
> --- gcc/tree.def.jj   2018-05-26 23:03:55.321873256 +0200
> +++ gcc/tree.def  2018-05-27 12:54:55.040197121 +0200
> @@ -1371,6 +1371,15 @@ DEFTREECODE (VEC_UNPACK_LO_EXPR, "vec_un
>  DEFTREECODE (VEC_UNPACK_FLOAT_HI_EXPR, "vec_unpack_float_hi_expr", 
> tcc_unary, 1)
>  DEFTREECODE (VEC_UNPACK_FLOAT_LO_EXPR, "vec_unpack_float_lo_expr", 
> tcc_unary, 1)
>  
> +/* Unpack (extract) the high/low elements of the input vector, convert
> +   floating point values to integer and widen elements into the output
> +   

[PATCH] Fix PR85933

[Richard Biener]

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

>From f7b8dc6184448bc7fb7f8faa27281f2ac64b75a9 Mon Sep 17 00:00:00 2001
From: Richard Guenther 
Date: Mon, 28 May 2018 09:48:28 +0200
Subject: [PATCH] fix-pr85933

2018-05-28  Richard Biener  

PR tree-optimization/85933
* tree-vect-data-refs.c (vect_record_base_alignments): Only
look at stmts marked as vectorizable.

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 331423af821..f46eb467da6 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -829,7 +829,10 @@ vect_record_base_alignments (vec_info *vinfo)
   data_reference *dr;
   unsigned int i;
   FOR_EACH_VEC_ELT (vinfo->datarefs, i, dr)
-if (!DR_IS_CONDITIONAL_IN_STMT (dr))
+{
+  gimple *stmt = DR_STMT (dr);
+if (!DR_IS_CONDITIONAL_IN_STMT (dr)
+   && STMT_VINFO_VECTORIZABLE (vinfo_for_stmt (stmt)))
   {
gimple *stmt = DR_STMT (dr);
vect_record_base_alignment (vinfo, stmt, _INNERMOST (dr));
@@ -843,6 +846,7 @@ vect_record_base_alignments (vec_info *vinfo)
  (vinfo, stmt, _VINFO_DR_WRT_VEC_LOOP (stmt_info));
  }
   }
+}
 }
 
 /* Return the target alignment for the vectorized form of DR.  */