[Patch, fortran] PR54679 Erroneous "Expected P edit descriptor" in conjunction with L descriptor

[Jerry DeLisle]

Hi All,

Gfortran currently treats an L format descriptor with no width as an extension. 
When the width is zero (not a positive integer) the error message was confused. 
The checking software was saving the format token, FMT_ZERO, for the next round 
of checks and this was interpreted to be a zero preceding a P edit descriptor.


This is fixed by adding the check for FMT_ZERO explicitly. I also added 
diagnostic messages to better explain the error. L0 is also allowed now as an 
extension.


Regression tested on x86-64-linux. New test case included in patch as well as 
adjusting the text for fmt_l.f90


OK for trunk?

Jerry

2016-10-29  Jerry DeLisle  

PR fortran/54679
* io.c (check_format): Adjust checks for FMT_L to treat a zero
width as an extension, giving warnings or error as appropriate.
Improve messages.

2016-10-24  Jerry DeLisle  

PR fortran/54679
* io/format.c (parse_format_list): Adjust checks for FMT_L to
treat a zero width as an extension, giving warnings or error
as appropriate. Improve messages.
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 7c48c491..0f81048a 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -592,7 +592,7 @@ check_format (bool is_input)
   const char *unexpected_end	  = _("Unexpected end of format string");
   const char *zero_width	  = _("Zero width in format descriptor");
 
-  const char *error;
+  const char *error = NULL;
   format_token t, u;
   int level;
   int repeat;
@@ -858,27 +858,31 @@ data_desc:
 	goto fail;
   if (t == FMT_POSINT)
 	break;
-
-  switch (gfc_notification_std (GFC_STD_GNU))
+  if (mode != MODE_FORMAT)
+	format_locus.nextc += format_string_pos;
+  if (t == FMT_ZERO)
 	{
-	  case WARNING:
-	if (mode != MODE_FORMAT)
-	  format_locus.nextc += format_string_pos;
-	gfc_warning (0, "Extension: Missing positive width after L "
-			 "descriptor at %L", _locus);
-	saved_token = t;
-	break;
-
-	  case ERROR:
-	error = posint_required;
-	goto syntax;
-
-	  case SILENT:
-	saved_token = t;
-	break;
-
-	  default:
-	gcc_unreachable ();
+	  switch (gfc_notification_std (GFC_STD_GNU))
+	{
+	  case WARNING:
+		gfc_warning (0, "Extension: Zero width after L "
+			 "descriptor at %L", _locus);
+		break;
+	  case ERROR:
+		gfc_error ("Extension: Zero width after L "
+			 "descriptor at %L", _locus);
+		goto fail;
+	  case SILENT:
+		break;
+	  default:
+		gcc_unreachable ();
+	}
+	}
+  else
+	{
+	  saved_token = t;
+	  gfc_notify_std (GFC_STD_GNU, "Missing positive width after "
+			  "L descriptor at %L", _locus);
 	}
   break;
 
diff --git a/gcc/testsuite/gfortran.dg/fmt_l.f90 b/gcc/testsuite/gfortran.dg/fmt_l.f90
index 9dc4f570..0fd19551 100644
--- a/gcc/testsuite/gfortran.dg/fmt_l.f90
+++ b/gcc/testsuite/gfortran.dg/fmt_l.f90
@@ -52,34 +52,34 @@ program test_l
 
 end program test_l
 ! { dg-output "At line 14 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 15 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 19 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 20 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 24 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 25 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 29 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 30 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: Positive width required with L descriptor(\n|\r\n|\r)" }
 ! { dg-output "At line 34 of file.*" }
-! { dg-output "Fortran runtime warning: Positive width required in format(\n|\r\n|\r)" }
+! { dg-output "Fortran runtime warning: 

Re: [committed] Fix bootstrap with ada x86_64-linux and -fcompare-debug failure on ppc64le-linux (PR target/78148)

[Richard Biener]

On October 29, 2016 5:57:17 PM GMT+02:00, Jakub Jelinek  
wrote:
>On Sat, Oct 29, 2016 at 10:07:22AM +0200, Andreas Schwab wrote:
>> That breaks Ada:
>> 
>> a-teioed.adb: In function 'Ada.Text_Io.Editing.Format_Number':
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb:127:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb: In function 'Ada.Text_Io.Editing.To_Picture':
>> a-teioed.adb:2724:4: error: alignment of array elements is greater
>than element size
>> a-teioed.adb: In function 'Ada.Text_Io.Editing.Valid':
>> a-teioed.adb:2751:4: error: alignment of array elements is greater
>than element size
>
>The bug is the same why PR78148 testcase fails with -fcompare-debug,
>build_nonstandard_integer_type return values are shared, all such calls
>with the same arguments return the same types, so using SET_TYPE_ALIGN
>on it
>is wrong.
>
>As it is a bootstrap failure on primary target and the fix is obvious,
>I've committed it to trunk after bootstrapping/regtesting it on
>x86_64-linux
>(where it fixed ada bootstrap) and i686-linux.

Whoops, sorry for not noticing during review.

Richard.

>2016-10-29  Jakub Jelinek  
>
>   PR target/78148
>   * gimple-ssa-store-merging.c
>   (imm_store_chain_info::output_merged_store): Use build_aligned_type
>   instead of SET_TYPE_ALIGN on shared integral type.
>
>   * gcc.dg/pr78148.c: New test.
>
>--- gcc/gimple-ssa-store-merging.c.jj  2016-10-29 14:39:24.0
>+0200
>+++ gcc/gimple-ssa-store-merging.c 2016-10-29 15:09:34.650749175 +0200
>@@ -1130,7 +1130,7 @@ imm_store_chain_info::output_merged_stor
> location_t loc = get_location_for_stmts (split_store->orig_stmts);
> 
>   tree int_type = build_nonstandard_integer_type (try_size, UNSIGNED);
>-  SET_TYPE_ALIGN (int_type, align);
>+  int_type = build_aligned_type (int_type, align);
>   tree addr = build_fold_addr_expr (base);
>   tree dest = fold_build2 (MEM_REF, int_type, addr,
>  build_int_cst (offset_type, try_pos));
>--- gcc/testsuite/gcc.dg/pr78148.c.jj  2016-10-29 15:10:05.432358626
>+0200
>+++ gcc/testsuite/gcc.dg/pr78148.c 2016-10-29 15:09:09.0 +0200
>@@ -0,0 +1,31 @@
>+/* PR target/78148 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -fcompare-debug" } */
>+
>+struct A { int a, b; };
>+struct B { char c, d; };
>+extern void bar (struct A, struct B);
>+struct C { char e, f; } a;
>+struct D
>+{
>+  int g;
>+  struct C h[4];
>+};
>+struct D *e;
>+
>+struct D
>+foo (void)
>+{
>+  int b;
>+  struct B c;
>+  struct A d;
>+  d.b = c.c = c.d = 0;
>+  bar (d, c);
>+}
>+
>+void
>+baz ()
>+{
>+  e->h[0].e = e->h[0].f = 0;
>+  foo ();
>+}
>
>   Jakub

Re: [PATCH] Fix COMPONENT_REF expansion (PR rtl-optimization/77919)

[Richard Biener]

On October 29, 2016 6:12:50 PM GMT+02:00, Jakub Jelinek  
wrote:
>On Fri, Oct 28, 2016 at 10:59:35AM +0200, Jakub Jelinek wrote:
>> On Fri, Oct 28, 2016 at 10:52:34AM +0200, Richard Biener wrote:
>> > > I've already committed the original patch based on Eric's review,
>but
>> > > managed to come up with another testcase that still ICEs (one
>with two
>> > > different complex modes).  Is the following ok for trunk if it
>passes
>> > > bootstrap/regtest?
>> > 
>> > As we're dealing with memory isn't GET_MODE_SIZE the correct thing
>to
>> > use?
>> 
>> GET_MODE_PRECISION is what the case VIEW_CONVERT_EXPR case tests:
>
>BTW, testing GET_MODE_SIZE or GET_MODE_BITSIZE doesn't make sense
>there,
>if (bitpos == 0
>&& bitsize == GET_MODE_BITSIZE (GET_MODE (op0))
>should already ensure that.  The GET_MODE_PRECISION check will force
>into
>memory say x86 XCmode to {TC,CTI}mode or vice versa conversions, which
>are
>better done through memory anyway.  If it isn't needed, then the
>question
>is why VCE uses it.
>
>Anyway, I've successfully bootstrapped/regtested the patch as is on
>x86_64-linux and i686-linux.

OK.

Richard.

>   Jakub

Re: [BUILDROBOT] [Ada] error: alignment of array elements is greater than element size (was: [PATCH] GIMPLE store merging pass)

[Markus Trippelsdorf]

On 2016.10.29 at 19:56 +0200, Jan-Benedict Glaw wrote:
> Hi Kyrill!
> 
> On Mon, 2016-10-24 15:56:48 +0100, Kyrill Tkachov 
>  wrote:
> > This is a slight update over [1] with Richard's feedback addressed.
> > In terminate_all_aliasing_chains we now terminate the chain early if
> > the destination is writing to a base offset by a variable amount.
> > This avoids walking the store chain and performing more alias checks.
> [...]
> > Bootstrapped and tested on aarch64, arm, x86_64.
> 
> I'm getting build failures when Ada is enabled (ie. --disable-multilib
> --enable-languages=all,ada,go), my build robot found it (see build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=648226
> for example):

This is already fixed by Jakub's r241679.

-- 
Markus

Re: [RFA] Fix various PPC build failures due to int-in-boolean-context code

[Segher Boessenkool]

On Fri, Oct 28, 2016 at 09:12:29AM -0600, Jeff Law wrote:
> 
> The PPC port is stumbling over the new integer in boolean context warnings.
> 
> In particular this code from rs6000_option_override_internal is 
> problematical:
> 
>   HOST_WIDE_INT flags = ((TARGET_DEFAULT) ? TARGET_DEFAULT
>  : 
> processor_target_table[cpu_index].target_enable);
> 
> The compiler is flagging the (TARGET_DEFAULT) condition.  That's 
> supposed to to be a boolean.
> 
> After all the macro expansions are done it ultimately looks something 
> like this:
> 
>  long flags = (((1L << 7)) ? (1L << 7)
> : processor_target_table[cpu_index].target_enable);
> 
> Note the (1L << 7) used as the condition for the ternary.  That's what 
> has the int-in-boolean-context warning tripping.  It's a false positive 
> IMHO.

Yes, there is an implicit conversion to bool here afaics.  So can the
misfiring warning be fixed instead, please?

> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 5e35e33..38a5226 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -3880,7 +3880,7 @@ rs6000_option_override_internal (bool global_init_p)
>  
>If there is a TARGET_DEFAULT, use that.  Otherwise fall back to using
>-mcpu=powerpc, -mcpu=powerpc64, or -mcpu=powerpc64le defaults.  */
> -  HOST_WIDE_INT flags = ((TARGET_DEFAULT) ? TARGET_DEFAULT
> +  HOST_WIDE_INT flags = ((TARGET_DEFAULT) != 0 ? TARGET_DEFAULT
>: processor_target_table[cpu_index].target_enable);
>rs6000_isa_flags |= (flags & ~rs6000_isa_flags_explicit);
>  }

Eww.

  HOST_WIDE_INT flags = TARGET_DEFAULT;
  if (flags == 0)
flags = processor_target_table[cpu_index].target_enable);

instead, if you have to do anything?


Segher

[BUILDROBOT] [Ada] error: alignment of array elements is greater than element size (was: [PATCH] GIMPLE store merging pass)

[Jan-Benedict Glaw]

Hi Kyrill!

On Mon, 2016-10-24 15:56:48 +0100, Kyrill Tkachov  
wrote:
> This is a slight update over [1] with Richard's feedback addressed.
> In terminate_all_aliasing_chains we now terminate the chain early if
> the destination is writing to a base offset by a variable amount.
> This avoids walking the store chain and performing more alias checks.
[...]
> Bootstrapped and tested on aarch64, arm, x86_64.

I'm getting build failures when Ada is enabled (ie. --disable-multilib
--enable-languages=all,ada,go), my build robot found it (see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=648226
for example):

[...]
/home/jbglaw/src/toolchain/build/./gcc/xgcc 
-B/home/jbglaw/src/toolchain/build/./gcc/ 
-B/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/bin/ 
-B/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/lib/ -isystem 
/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/include -isystem 
/home/jbglaw/src/toolchain/install/x86_64-pc-linux-gnu/sys-include-c -g -O2 
 -fpic  -W -Wall -gnatpg -nostdinc   a-teioed.adb -o a-teioed.o
a-teioed.adb: In function ‘Ada.Text_Io.Editing.Format_Number’:
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb: In function ‘Ada.Text_Io.Editing.To_Picture’:
a-teioed.adb:2724:4: error: alignment of array elements is greater than element 
size
a-teioed.adb: In function ‘Ada.Text_Io.Editing.Valid’:
a-teioed.adb:2751:4: error: alignment of array elements is greater than element 
size
make[7]: *** [a-teioed.o] Error 1
make[7]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2
make[6]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[5]: *** [gnatlib-shared-default] Error 2
make[5]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[4]: *** [gnatlib-shared-dual] Error 2
make[4]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory `/home/jbglaw/src/toolchain/build/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory 
`/home/jbglaw/src/toolchain/build/x86_64-pc-linux-gnu/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/home/jbglaw/src/toolchain/build'
make: *** [all] Error 2


I bisected it down to this commit, though I don't know if it caused or
uncovered the issue.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481


signature.asc
Description: Digital signature

Re: [C++ PATCH] Fix -std=c++11 -std=gnu++11 option handling (PR c++/77948)

[Jakub Jelinek]

On Sat, Oct 29, 2016 at 12:41:43PM -0400, Jason Merrill wrote:
> On Sat, Oct 29, 2016 at 12:09 PM, Jakub Jelinek  wrote:
> > Apparently the driver reorders the options, -std=* options come before
> > all -f* options, so both of the following patches work the same, except
> > when cc1plus is invoked by hand.  The first (inlined) patch solves it
> > more in line how e.g. -fgnu-keywords and similar options are handled, so I 
> > think
> > it is preferable (and I've successfully bootstrapped/regtested it on
> > x86_64-linux and i686-linux).  The second (attached) patch handles it
> > by not clearing -fext-numeric-literals during option processing
> > for -std=* options, just in post option handling clears it for the
> > strict c++11+ modes if the option is not specified explicitly.
> > If the driver wouldn't reorder the options, it would handle better
> > cases like -fext-numeric-literals -std=c++11 to mean the same thing
> > as -std=c++11 -fext-numeric-literals etc., but due to the reordering
> > it isn't needed and for consistency we'd also need to change -fgnu-keywords
> > etc.
> 
> I lean toward the second patch because it keeps the logic in a single
> place, but it looks like it doesn't currently handle C++98
> differently.  I don't think we need to change the handling of other
> options to match.

The second patch has that
+  /* Unless -f{,no-}ext-numeric-literals has been used explicitly,
+for -std=c++{11,14,1z} default to -fno-ext-numeric-literals.  */
+  if (flag_iso && !global_options_set.x_flag_ext_numeric_literals)
+   cpp_opts->ext_numeric_literals = 0;
in a block guarded with cxx_dialect >= cxx11.  So for -std=c++98 it will
just not disable them (the same as the other patch, and the same as
vanilla trunk/6/5 if just using -std=c++98 and not -std=c++11 -std=c++98;
or do you want to change behavior of -std=c++98 to reject those unless
using -std=gnu++98 or -std=c++98 -fext-numeric-literals?  Pedantically
they are GNU extensions, but if we want to be pedantic,
-pedantic/-pedantic-errors already rejects those anyway.

Jakub

[committed] hppa: Update FINI_SECTION_ASM_OP define

[John David Anglin]

The attached patch changes the define of FINI_SECTION_ASM_OP to match that of 
INIT_SECTION_ASM_OP.

Tested on hppa64-hp-hpux11.11.  Committed to trunk.

Dave
--
John David Anglin   dave.ang...@bell.net


2016-10-29  John David Anglin  

* config/pa/pa64-hpux.h (FINI_SECTION_ASM_OP): Define to null string.

Index: config/pa/pa64-hpux.h
===
--- config/pa/pa64-hpux.h   (revision 241676)
+++ config/pa/pa64-hpux.h   (working copy)
@@ -336,7 +336,7 @@
 #undef INIT_SECTION_ASM_OP
 #define INIT_SECTION_ASM_OP ""
 #undef FINI_SECTION_ASM_OP
-#define FINI_SECTION_ASM_OP
+#define FINI_SECTION_ASM_OP ""
 
 /* We are using array initializers and don't want calls in the INIT
and FINI sections.  */

Re: [C++ PATCH] Fix -std=c++11 -std=gnu++11 option handling (PR c++/77948)

[Jason Merrill]

On Sat, Oct 29, 2016 at 12:09 PM, Jakub Jelinek  wrote:
> Apparently the driver reorders the options, -std=* options come before
> all -f* options, so both of the following patches work the same, except
> when cc1plus is invoked by hand.  The first (inlined) patch solves it
> more in line how e.g. -fgnu-keywords and similar options are handled, so I 
> think
> it is preferable (and I've successfully bootstrapped/regtested it on
> x86_64-linux and i686-linux).  The second (attached) patch handles it
> by not clearing -fext-numeric-literals during option processing
> for -std=* options, just in post option handling clears it for the
> strict c++11+ modes if the option is not specified explicitly.
> If the driver wouldn't reorder the options, it would handle better
> cases like -fext-numeric-literals -std=c++11 to mean the same thing
> as -std=c++11 -fext-numeric-literals etc., but due to the reordering
> it isn't needed and for consistency we'd also need to change -fgnu-keywords
> etc.

I lean toward the second patch because it keeps the logic in a single
place, but it looks like it doesn't currently handle C++98
differently.  I don't think we need to change the handling of other
options to match.

Jason

[RFA] Fix false positive out of bounds array index warning in LRA

[Jeff Law]

On a small number of ports, we only have 2 defined register classes. 
NO_REGS and ALL_REGS.  Examples would include nvptx and vax.


So let's look at check_and_process_move from lra-constraints.c:

  sclass = dclass = NO_REGS;
  if (REG_P (dreg))
dclass = get_reg_class (REGNO (dreg));
  if (dclass == ALL_REGS)
/* ALL_REGS is used for new pseudos created by transformations
   like reload of SUBREG_REG (see function
   simplify_operand_subreg).  We don't know their class yet.  We
   should figure out the class from processing the insn
   constraints not in this fast path function.  Even if ALL_REGS
   were a right class for the pseudo, secondary_... hooks usually
   are not define for ALL_REGS.  */
return false;
  [ ... ]
  /* Set up hard register for a reload pseudo for hook
 secondary_reload because some targets just ignore unassigned
 pseudos in the hook.  */
  if (dclass != NO_REGS && lra_get_regno_hard_regno (REGNO (dreg)) < 0)
{
  dregno = REGNO (dreg);
  reg_renumber[dregno] = ira_class_hard_regs[dclass][0];
}


The reference to ira_class_hard_regs is flagged by VRP as having an 
out-of-bounds array reference.  WTF!?  Of course it's pretty obvious 
once you look at the dumps...


On most targets dclass in this code will have a VR_VARYING range and as 
a result no warning will be issued.  But on the ptx and vax ports VRP is 
able to give us the range ~[NO_REGS,ALL_REGS]  aka ~[0,1] The 
out-of-range array index is now obvious.


The fix is trivial, we just assert that dclass is < LIM_REG_CLASSES, 
similarly for sclass as it triggers a similar warning.


Bootstrapped and regression tested on x86_64-linux-gnu.  Also verified 
that the ptx and vax ports will build via config-list.mk.


Ok for the trunk?

Jeff


* lra-constraints.c (check_and_process_move): Constrain the
range of DCLASS and SCLASS to avoid false positive out of bounds
array index warning.

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index b592168..f14c86c 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1127,6 +1127,7 @@ check_and_process_move (bool *change_p, bool *sec_mem_p 
ATTRIBUTE_UNUSED)
   sclass = dclass = NO_REGS;
   if (REG_P (dreg))
 dclass = get_reg_class (REGNO (dreg));
+  gcc_assert (dclass < LIM_REG_CLASSES);
   if (dclass == ALL_REGS)
 /* ALL_REGS is used for new pseudos created by transformations
like reload of SUBREG_REG (see function
@@ -1138,6 +1139,7 @@ check_and_process_move (bool *change_p, bool *sec_mem_p 
ATTRIBUTE_UNUSED)
 return false;
   if (REG_P (sreg))
 sclass = get_reg_class (REGNO (sreg));
+  gcc_assert (sclass < LIM_REG_CLASSES);
   if (sclass == ALL_REGS)
 /* See comments above.  */
 return false;

[committed] hppa: Update MALLOC_ABI_ALIGNMENT define

[John David Anglin]

The attached patch changes the malloc ABI alignment to 128 bits on hppa64 and 
hppa-linux.
This suppresses the over-aligned new warning seen on linux.  On hppa64, we now 
match the
alignment for long double.

The default definition of MALLOC_ABI_ALIGNMENT is 32.  This is wrong for 
PA-RISC, so I back ported
the change and BIGGEST_ALIGNMENT comment updates to the gcc-5 and gcc-6 
branches.

Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.

Committed to trunk, gcc-5 and gcc-6 branches.

Dave
--
John David Anglin   dave.ang...@bell.net


2016-10-29  John David Anglin  

* config/pa/pa.h (BIGGEST_ALIGNMENT): Adjust comment.
(MALLOC_ABI_ALIGNMENT): Define to 128 on all targets except SOM.
Adjust comment.

Index: config/pa/pa.h
===
--- config/pa/pa.h  (revision 241546)
+++ config/pa/pa.h  (working copy)
@@ -295,17 +295,19 @@
 /* No data type wants to be aligned rounder than this.  The long double
type has 16-byte alignment on the 64-bit target even though it was never
implemented in hardware.  The software implementation only needs 8-byte
-   alignment.  This is to match the HP compilers.  */
+   alignment.  This matches the biggest alignment of the HP compilers.  */
 #define BIGGEST_ALIGNMENT (2 * BITS_PER_WORD)
 
 /* Alignment, in bits, a C conformant malloc implementation has to provide.
The HP-UX malloc implementation provides a default alignment of 8 bytes.
-   This can be increased with mallopt.  The glibc implementation also provides
-   8-byte alignment.  Note that this isn't enough for various POSIX types such
-   as pthread_mutex_t.  However, since we no longer need the 16-byte alignment
-   for atomic operations, we ignore the nominal alignment specified for these
-   types.  The same is true for long double on 64-bit HP-UX.  */
-#define MALLOC_ABI_ALIGNMENT (64)
+   It should be 16 bytes on the 64-bit target since long double has 16-byte
+   alignment.  It can be increased with mallopt but it's non critical since
+   long double was never implemented in hardware.  The glibc implementation
+   currently provides 8-byte alignment.  It should be 16 bytes since various
+   POSIX types such as pthread_mutex_t require 16-byte alignment.  Again,
+   this is non critical since 16-byte alignment is no longer needed for
+   atomic operations.  */
+#define MALLOC_ABI_ALIGNMENT (TARGET_SOM ? 64 : 128)
 
 /* Get around hp-ux assembler bug, and make strcpy of constants fast.  */
 #define CONSTANT_ALIGNMENT(EXP, ALIGN) \

Re: [PATCH] Fix COMPONENT_REF expansion (PR rtl-optimization/77919)

[Jakub Jelinek]

On Fri, Oct 28, 2016 at 10:59:35AM +0200, Jakub Jelinek wrote:
> On Fri, Oct 28, 2016 at 10:52:34AM +0200, Richard Biener wrote:
> > > I've already committed the original patch based on Eric's review, but
> > > managed to come up with another testcase that still ICEs (one with two
> > > different complex modes).  Is the following ok for trunk if it passes
> > > bootstrap/regtest?
> > 
> > As we're dealing with memory isn't GET_MODE_SIZE the correct thing to
> > use?
> 
> GET_MODE_PRECISION is what the case VIEW_CONVERT_EXPR case tests:

BTW, testing GET_MODE_SIZE or GET_MODE_BITSIZE doesn't make sense there,
if (bitpos == 0
&& bitsize == GET_MODE_BITSIZE (GET_MODE (op0))
should already ensure that.  The GET_MODE_PRECISION check will force into
memory say x86 XCmode to {TC,CTI}mode or vice versa conversions, which are
better done through memory anyway.  If it isn't needed, then the question
is why VCE uses it.

Anyway, I've successfully bootstrapped/regtested the patch as is on
x86_64-linux and i686-linux.

Jakub

[C++ PATCH] Fix -std=c++11 -std=gnu++11 option handling (PR c++/77948)

[Jakub Jelinek]

Hi!

As the testcases show, we mishandle e.g. -std=c++11 -std=gnu++14
or -std=c++11 -std=c++98, in that earlier -std=c++{1[147yz],0x}
disables -fext-numeric-literals and nothing turns this again on,
unless enabled explicitly, eventhough such option combinations
should just ignore the earlier -std= options (last one should win).

Apparently the driver reorders the options, -std=* options come before
all -f* options, so both of the following patches work the same, except
when cc1plus is invoked by hand.  The first (inlined) patch solves it
more in line how e.g. -fgnu-keywords and similar options are handled, so I think
it is preferrable (and I've successfully bootstrapped/regtested it on
x86_64-linux and i686-linux).  The second (attached) patch handles it
by not clearing -fext-numeric-literals during option processing
for -std=* options, just in post option handling clears it for the
strict c++11+ modes if the option is not specified explicitly.
If the driver wouldn't reorder the options, it would handle better
cases like -fext-numeric-literals -std=c++11 to mean the same thing
as -std=c++11 -fext-numeric-literals etc., but due to the reordering
it isn't needed and for consistency we'd also need to change -fgnu-keywords
etc.

Ok for trunk (the first patch, or second)?

2016-10-29  Jakub Jelinek  

PR c++/77948
* c-opts.c (c_common_handle_option): Don't clear
cpp_opts->ext_numeric_literals for -std=c++{11,14,1z} here.
(set_std_c89, set_std_c99, set_std_c11): Fix up formatting.
(set_std_cxx11, set_std_cxx14, set_std_cxx1z): Likewise.
Set cpp_opts->ext_numeric_literals to !iso.
(set_std_cxx98): Fix up formatting.  Set
cpp_opts->ext_numeric_literals to 1.

* g++.dg/cpp0x/pr77948-1.C: New test.
* g++.dg/cpp0x/pr77948-2.C: New test.
* g++.dg/cpp0x/pr77948-3.C: New test.
* g++.dg/cpp0x/pr77948-4.C: New test.
* g++.dg/cpp0x/pr77948-5.C: New test.
* g++.dg/cpp0x/pr77948-6.C: New test.

--- gcc/c-family/c-opts.c.jj2016-10-20 20:32:12.0 +0200
+++ gcc/c-family/c-opts.c   2016-10-29 12:10:29.864347364 +0200
@@ -624,31 +624,19 @@ c_common_handle_option (size_t scode, co
 case OPT_std_c__11:
 case OPT_std_gnu__11:
   if (!preprocessing_asm_p)
-   {
- set_std_cxx11 (code == OPT_std_c__11 /* ISO */);
- if (code == OPT_std_c__11)
-   cpp_opts->ext_numeric_literals = 0;
-   }
+   set_std_cxx11 (code == OPT_std_c__11 /* ISO */);
   break;
 
 case OPT_std_c__14:
 case OPT_std_gnu__14:
   if (!preprocessing_asm_p)
-   {
- set_std_cxx14 (code == OPT_std_c__14 /* ISO */);
- if (code == OPT_std_c__14)
-   cpp_opts->ext_numeric_literals = 0;
-   }
+   set_std_cxx14 (code == OPT_std_c__14 /* ISO */);
   break;
 
 case OPT_std_c__1z:
 case OPT_std_gnu__1z:
   if (!preprocessing_asm_p)
-   {
- set_std_cxx1z (code == OPT_std_c__1z /* ISO */);
- if (code == OPT_std_c__1z)
-   cpp_opts->ext_numeric_literals = 0;
-   }
+   set_std_cxx1z (code == OPT_std_c__1z /* ISO */);
   break;
 
 case OPT_std_c90:
@@ -1500,7 +1488,7 @@ cb_dir_change (cpp_reader * ARG_UNUSED (
 static void
 set_std_c89 (int c94, int iso)
 {
-  cpp_set_lang (parse_in, c94 ? CLK_STDC94: iso ? CLK_STDC89: CLK_GNUC89);
+  cpp_set_lang (parse_in, c94 ? CLK_STDC94 : iso ? CLK_STDC89 : CLK_GNUC89);
   flag_iso = iso;
   flag_no_asm = iso;
   flag_no_gnu_keywords = iso;
@@ -1515,7 +1503,7 @@ set_std_c89 (int c94, int iso)
 static void
 set_std_c99 (int iso)
 {
-  cpp_set_lang (parse_in, iso ? CLK_STDC99: CLK_GNUC99);
+  cpp_set_lang (parse_in, iso ? CLK_STDC99 : CLK_GNUC99);
   flag_no_asm = iso;
   flag_no_nonansi_builtin = iso;
   flag_iso = iso;
@@ -1529,7 +1517,7 @@ set_std_c99 (int iso)
 static void
 set_std_c11 (int iso)
 {
-  cpp_set_lang (parse_in, iso ? CLK_STDC11: CLK_GNUC11);
+  cpp_set_lang (parse_in, iso ? CLK_STDC11 : CLK_GNUC11);
   flag_no_asm = iso;
   flag_no_nonansi_builtin = iso;
   flag_iso = iso;
@@ -1543,12 +1531,13 @@ set_std_c11 (int iso)
 static void
 set_std_cxx98 (int iso)
 {
-  cpp_set_lang (parse_in, iso ? CLK_CXX98: CLK_GNUCXX);
+  cpp_set_lang (parse_in, iso ? CLK_CXX98 : CLK_GNUCXX);
   flag_no_gnu_keywords = iso;
   flag_no_nonansi_builtin = iso;
   flag_iso = iso;
   flag_isoc94 = 0;
   flag_isoc99 = 0;
+  cpp_opts->ext_numeric_literals = 1;
   cxx_dialect = cxx98;
   lang_hooks.name = "GNU C++98";
 }
@@ -1557,13 +1546,14 @@ set_std_cxx98 (int iso)
 static void
 set_std_cxx11 (int iso)
 {
-  cpp_set_lang (parse_in, iso ? CLK_CXX11: CLK_GNUCXX11);
+  cpp_set_lang (parse_in, iso ? CLK_CXX11 : CLK_GNUCXX11);
   flag_no_gnu_keywords = iso;
   flag_no_nonansi_builtin = iso;
   flag_iso = iso;
   /* C++11 includes the C99 standard library.  */
   flag_isoc94 = 1;
   flag_isoc99 = 1;
+  cpp_opts->ext_numeric_literals = !iso;
   cxx_dialect = cxx11;
 

[committed] Fix bootstrap with ada x86_64-linux and -fcompare-debug failure on ppc64le-linux (PR target/78148)

[Jakub Jelinek]

On Sat, Oct 29, 2016 at 10:07:22AM +0200, Andreas Schwab wrote:
> That breaks Ada:
> 
> a-teioed.adb: In function 'Ada.Text_Io.Editing.Format_Number':
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb:127:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb: In function 'Ada.Text_Io.Editing.To_Picture':
> a-teioed.adb:2724:4: error: alignment of array elements is greater than 
> element size
> a-teioed.adb: In function 'Ada.Text_Io.Editing.Valid':
> a-teioed.adb:2751:4: error: alignment of array elements is greater than 
> element size

The bug is the same why PR78148 testcase fails with -fcompare-debug,
build_nonstandard_integer_type return values are shared, all such calls
with the same arguments return the same types, so using SET_TYPE_ALIGN on it
is wrong.

As it is a bootstrap failure on primary target and the fix is obvious,
I've committed it to trunk after bootstrapping/regtesting it on x86_64-linux
(where it fixed ada bootstrap) and i686-linux.

2016-10-29  Jakub Jelinek  

PR target/78148
* gimple-ssa-store-merging.c
(imm_store_chain_info::output_merged_store): Use build_aligned_type
instead of SET_TYPE_ALIGN on shared integral type.

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

--- gcc/gimple-ssa-store-merging.c.jj   2016-10-29 14:39:24.0 +0200
+++ gcc/gimple-ssa-store-merging.c  2016-10-29 15:09:34.650749175 +0200
@@ -1130,7 +1130,7 @@ imm_store_chain_info::output_merged_stor
   location_t loc = get_location_for_stmts (split_store->orig_stmts);
 
   tree int_type = build_nonstandard_integer_type (try_size, UNSIGNED);
-  SET_TYPE_ALIGN (int_type, align);
+  int_type = build_aligned_type (int_type, align);
   tree addr = build_fold_addr_expr (base);
   tree dest = fold_build2 (MEM_REF, int_type, addr,
   build_int_cst (offset_type, try_pos));
--- gcc/testsuite/gcc.dg/pr78148.c.jj   2016-10-29 15:10:05.432358626 +0200
+++ gcc/testsuite/gcc.dg/pr78148.c  2016-10-29 15:09:09.0 +0200
@@ -0,0 +1,31 @@
+/* PR target/78148 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcompare-debug" } */
+
+struct A { int a, b; };
+struct B { char c, d; };
+extern void bar (struct A, struct B);
+struct C { char e, f; } a;
+struct D
+{
+  int g;
+  struct C h[4];
+};
+struct D *e;
+
+struct D
+foo (void)
+{
+  int b;
+  struct B c;
+  struct A d;
+  d.b = c.c = c.d = 0;
+  bar (d, c);
+}
+
+void
+baz ()
+{
+  e->h[0].e = e->h[0].f = 0;
+  foo ();
+}

Jakub

Re: RFD: Buffer handling for ASM_GENERATE_INTERNAL_LABEL

[Bernd Edlinger]

Hi,


 > Sadly, there's a bigger issue here. Namely that the caller and the
 > definition of ASM_GENERATE_INTERNAL_LABEL both can include arbitrary
 > length text into the label name. Furthermore, the buffer is allocated
 > in the caller's context. It's a terrible API.

Yes.  Even ASM_FORMAT_PRIVATE_NAME looks like a better way to define
the API.

# define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \
   do { const char *const name_ = (NAME); \
char *const output_ = (OUTPUT) = \
  (char *) alloca (strlen (name_) + 32); \
sprintf (output_, ASM_PN_FORMAT, name_, (unsigned long)(LABELNO)); \
   } while (0)


But it also depends on what ASM_PN_FORMAT looks like,
so also this "+ 32" should be a define, which tells us how much
overhead comes from the format string, then we should use that
in the allocation.

If the target overrides ASM_PN_FORMAT the target should also
define how long the ASM_PN_FORMAT prints minimum.  Then the macro
can use strlen (name_) + ASM_PN_FORMAT_MIN_LENGH + max. space
for the LABELNO, maybe just use strlen(ASM_PN_FORMAT) if the
target fails to cooperate.

 > ISTM the way "out" is to change very ASM_GENERATE_INTERNAL_LABEL
 > implementation to use snprintf to first determine the length of the
 > resulting string, then allocate an appropriate amount of memory
 > (returning it to the caller). The caller is then changed to use the
 > buffer allocated by ASM_GENERATE_INTERNAL_LABEL, free-ing it when
 > appropriate. Major ick. We'd probably want to hook-ize the damn thing
 > while we're at it.


I would like to have a simple solution, that does work with the current
code, without totally rewriting the users.

The middle end should be able to tell the target how long the longest
PREFIX will be, then the target should be able to give a formula how
long the total format will be.  Then some users already use
MAX_ARTIFICIAL_LABEL_BYTES to allocate a sufficient buffer, that should
be based on the target definition, all others that don't do it already
should follow.


Bernd.

Re: RFD: Buffer handling for ASM_GENERATE_INTERNAL_LABEL

[Trevor Saunders]

On Fri, Oct 28, 2016 at 09:42:10PM -0600, Jeff Law wrote:
> 
> Consider this definition of ASM_GENERATE_INTERNAL_LABEL (from sp64-elf.h):
> 
> #undef  ASM_GENERATE_INTERNAL_LABEL
> #define ASM_GENERATE_INTERNAL_LABEL(LABEL,PREFIX,NUM)   \
>   sprintf ((LABEL), "*.L%s%ld", (PREFIX), (long)(NUM))
> 
> And a use from assemble_static_space:
> 
>ASM_GENERATE_INTERNAL_LABEL (name, "LF", const_labelno);
> 
> 
> For this case we can generate up to 16 bytes of data + a nul terminator.
> 
> Sadly, we only allocate 16 bytes in assemble_static_space.
> 
> Obviously it's unlikely we'll ever have a labelno that will overflow to
> -2147483648 without something else breaking.  So in practice this isn't
> likely to ever cause a problem.  But we still need to address it.
> 
> This causes 8 sparc configurations from config-list.mk to fail to build
> using the trunk compiler to build the crosses.
> 
> 
> 
> We can obviously fix the array to be bigger here and it's a trivial change.
> If we get a situation where it's out of range again, we can detect it with
> the existing sprintf warnings.  It's also consistent in the sense that most
> callers to ASM_GENERATE_INTERNAL_LABEL use a significantly larger buffer
> than assemble_static_space.
> 
> Sadly, there's a bigger issue here.  Namely that the caller and the
> definition of ASM_GENERATE_INTERNAL_LABEL both can include arbitrary length
> text into the label name.  Furthermore, the buffer is allocated in the
> caller's context. It's a terrible API.
> 
> ISTM the way "out" is  to change very ASM_GENERATE_INTERNAL_LABEL
> implementation to use snprintf to first determine the length of the
> resulting string, then allocate an appropriate amount of memory (returning
> it to the caller).  The caller is then changed to use the buffer allocated
> by ASM_GENERATE_INTERNAL_LABEL, free-ing it when appropriate.  Major ick.
> We'd probably want to hook-ize the damn thing while we're at it.
> 
> Other thoughts?

So actually a thing I've wanted to do for a while is add a long string
building class to generate asm into that would use a set of buffers
adding new ones when the space is needed.  So that would look something
like

class string_builder
{
public:
  string_builder () {}

  ~string_builder ()
  {
for (unsigned i = 0; i < m_buffers.length (); i++)
free (m_buffers[i]);
  }

  void append_string (const char *s)
  {
unsigned int length = strlen (s);
if (length + m_last_buf_length >= MAX_BUF_LENGTH)
  alloc_buffer ();

strcat (m_buffers.last (), s);
m_last_buf_length += length;
  }

  void append_printf (const char *s...)
  {
// something somewhat more complicated than apend_string but similar
// in spirit
  }

  void write (FILE *f)
  {
for (unsigned int i = 0; i < m_buffers.length (); i++)
  fwrite (m_buffers[i], 1, MAX_BUFFER_LENGTH, f);
  }

private:
  void alloc_buffer ()
  {
m_buffers.safe_push (malloc (MAX_BUFFER_LENGTH));
m_buffers.last ()[0] = 0;
m_last_buf_length = 0;
  }

  auto_vec m_buffers;
  size_t m_last_buf_length;
};

The original reason was to reduce calls into libc while writing out
assembly to speed that up somewhat, but it should also work here so the
caller doesn't need to care about the buffer size.  We might need to add
a way to get the string out as one piece.

Although actually it seems likely we'll always need the string as one
piece here, and it will usually be small, so maybe we're better served
here with a standard C++ string of some sort.

Unfortunately I haven't found time yet to work on either the
string_builder or a plain string for gcc yet, sorry.

Trev

p.s. I think there are some non optimal and buggy things in the example,
but you get the picture.


> 
> Jeff

Re: [PATCH] Fix filesystem::path for iterators with const value_type

[Jonathan Wakely]

On 28/10/16 15:39 -0400, Tim Song wrote:

On Fri, Oct 28, 2016 at 1:47 PM, Jonathan Wakely  wrote:

For some reason the Filesystem library says that you can construct
paths from iterators with value_type that is a possibly const encoded
character type. I don't know why we support const value_type in this
place, when normally that is bogus (even const_iterators have a
non-const value_type, and various algorithms won't compile with const
value_type).


It doesn't say that. [path.req]/1 says that "the value type shall be
an encoded character type". [path.req]/2 says that the relevant
overloads need not be SFINAE'd away (or equivalent) if the value_type
is a const encoded character type, but doesn't actually say that they
are required to work.


Good point, so failing to compile those wonky iterators was OK. Oh
well, let's leave the "fix" for now.

Re: [PATCH] Delete GCJ

[Jakub Jelinek]

On Sat, Oct 29, 2016 at 09:07:42AM +, Bernd Edlinger wrote:
> > Things we may want to remove:
> > 
> > - references to java in contrib (download_ecj, gcc_update,
> >   patch_tester.sh, update-copyright.py)
> > - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> > - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> > - references to java in install.texi
> 
> Probably also gcc/jit/* and gcc/testsuite/jit.dg/* ?

??  gccjit has nothing to do with Java, it is a general purpose GIT for
whatever program wants to use it.

Jakub

Re: [PATCH] Delete GCJ

[Bernd Edlinger]

> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

Probably also gcc/jit/* and gcc/testsuite/jit.dg/* ?

Bernd.

Re: [PATCH][v5] GIMPLE store merging pass

[Andreas Schwab]

That breaks Ada:

a-teioed.adb: In function 'Ada.Text_Io.Editing.Format_Number':
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb:127:4: error: alignment of array elements is greater than element 
size
a-teioed.adb: In function 'Ada.Text_Io.Editing.To_Picture':
a-teioed.adb:2724:4: error: alignment of array elements is greater than element 
size
a-teioed.adb: In function 'Ada.Text_Io.Editing.Valid':
a-teioed.adb:2751:4: error: alignment of array elements is greater than element 
size

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."