Re: Handle XOR in canonicalize_condition

[Richard Sandiford]

Richard Sandiford  writes:
> The other problem is related to the way that MIPS16 tests for equality.
> Conditional branches test register $24, and the only instructions that
> set $24 are MOVE and CMP(I), which is actually an XOR rather than a
> subtraction.

Er, don't know what I was thinking here, but please ignore this summary
of the ISA.  There are conditional branches to test MIPS16 registers
and other ways of setting $24.  (But other than that...)

The patch itself still stands though.

Thanks,
Richard

[PATCH, SH] fix builtin_strncmp

[Christian Bruel]

Hi,

This patch fixes a bug of mine whereas more bytes than needed was read
when processing remaining bytes after an aligned  word at at time loop.
This case was not caught neither by the gcc testsuite not the glibc
tests, Regression test included.

no new regressions with the GCC and glibc testsuites., OK for trunk ?

thanks,
Christian




2014-01-23  Christian Bruel  

	* config/sh/sh-mem.cc (sh_expand_cmpnstr): Fix remaining bytes after
	words comparisons.

2014-01-23  Christian Bruel  

	* gcc.target/sh/torture/strncmp.c: New tests.

Index: gcc/config/sh/sh-mem.cc
===
--- gcc/config/sh/sh-mem.cc	(revision 206918)
+++ gcc/config/sh/sh-mem.cc	(working copy)
@@ -344,7 +344,6 @@ sh_expand_cmpnstr (rtx *operands)
 
   rtx L_loop_long = gen_label_rtx ();
   rtx L_end_loop_long = gen_label_rtx ();
-  rtx L_small = gen_label_rtx ();
 
   int align = INTVAL (operands[4]);
   int bytes = INTVAL (operands[3]);
@@ -403,34 +402,60 @@ sh_expand_cmpnstr (rtx *operands)
   jump = emit_jump_insn (gen_branch_false (L_loop_long));
   add_int_reg_note (jump, REG_BR_PROB, prob_likely);
 
+ int sbytes = bytes % 4;
+
   /* end loop.  Reached max iterations.  */
-  if (bytes % 4 == 0)
+  if (! sbytes)
 {
-  /* Done.  */
   jump = emit_jump_insn (gen_jump_compact (L_return));
   emit_barrier_after (jump);
 }
   else
 {
-  /* Remaining bytes to read.   */
-  jump = emit_jump_insn (gen_jump_compact (L_small));
+  /* Remaining bytes to check.  */
+
+  addr1 = adjust_automodify_address (addr1, QImode, s1_addr, 0);
+  addr2 = adjust_automodify_address (addr2, QImode, s2_addr, 0);
+
+  while (sbytes--)
+{
+  emit_insn (gen_extendqisi2 (tmp1, addr1));
+  emit_insn (gen_extendqisi2 (tmp2, addr2));
+
+  emit_insn (gen_cmpeqsi_t (tmp2, const0_rtx));
+  jump = emit_jump_insn (gen_branch_true (L_end_loop_byte));
+  add_int_reg_note (jump, REG_BR_PROB, prob_unlikely);
+
+  emit_insn (gen_cmpeqsi_t (tmp1, tmp2));
+  if (flag_delayed_branch)
+emit_insn (gen_zero_extendqisi2 (tmp2,
+ gen_lowpart (QImode,
+  tmp2)));
+  jump = emit_jump_insn (gen_branch_false (L_end_loop_byte));
+  add_int_reg_note (jump, REG_BR_PROB, prob_unlikely);
+
+  addr1 = adjust_address (addr1, QImode,
+  GET_MODE_SIZE (QImode));
+  addr2 = adjust_address (addr2, QImode,
+  GET_MODE_SIZE (QImode));
+}
+
+  jump = emit_jump_insn (gen_jump_compact( L_end_loop_byte));
   emit_barrier_after (jump);
 }
 
   emit_label (L_end_loop_long);
 
   /* Found last word.  Restart it byte per byte. */
-  bytes =  4;
+
   emit_move_insn (s1_addr, plus_constant (Pmode, s1_addr,
   -GET_MODE_SIZE (SImode)));
   emit_move_insn (s2_addr, plus_constant (Pmode, s2_addr,
   -GET_MODE_SIZE (SImode)));
+
+  /* fall thru.  */
 }
 
-  emit_label (L_small);
-
-  gcc_assert (bytes <= 7);
-
   addr1 = adjust_automodify_address (addr1, QImode, s1_addr, 0);
   addr2 = adjust_automodify_address (addr2, QImode, s2_addr, 0);
 
@@ -445,7 +470,8 @@ sh_expand_cmpnstr (rtx *operands)
 
   emit_insn (gen_cmpeqsi_t (tmp1, tmp2));
   if (flag_delayed_branch)
-emit_insn (gen_zero_extendqisi2 (tmp2, gen_lowpart (QImode, tmp2)));
+emit_insn (gen_zero_extendqisi2 (tmp2,
+ gen_lowpart (QImode, tmp2)));
   jump = emit_jump_insn (gen_branch_false (L_end_loop_byte));
   add_int_reg_note (jump, REG_BR_PROB, prob_unlikely);
 
Index: gcc/testsuite/gcc.target/sh/torture/strncmp.c
===
--- gcc/testsuite/gcc.target/sh/torture/strncmp.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/torture/strncmp.c	(working copy)
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+
+extern void abort (void);
+
+const char *s="astc";
+const char *s1="-BEGIN RSA PRIVATE KEY-";
+const char *s2="atextaac";
+
+main()
+{
+  if (! __builtin_strncmp ("astb", s, 4))
+abort();
+
+  if (__builtin_strncmp(s1, "-BEGIN ", 11))
+abort();
+
+  if (! __builtin_strncmp ("atextaacb", s2, 9))
+abort();
+
+  return 0;
+}
+

Re: [PATCH] Documentation for dump and optinfo output

[Thomas Schwinge]

Hi!

On Thu, 19 Dec 2013 01:44:08 -0800, Sharad Singhai  wrote:
> I ran 'make doc' and browsed the info output for basic sanity. Okay for trunk?

>   * Makefile.in: Add optinfo.texi.
>   * doc/optinfo.texi: New documentation for optimization info.
>   * doc/passes.texi: Add new node.

Thanks for contributing to the documentation!

During build, I'm seeing the following warnings; would be great if you
could address these:

../../source/gcc/doc/optinfo.texi:45: warning: node next `Optimization 
groups' in menu `Dump output verbosity' and in sectioning `Dump files and 
streams' differ
../../source/gcc/doc/optinfo.texi:77: warning: node next `Dump files and 
streams' in menu `Dump types' and in sectioning `Dump output verbosity' differ
../../source/gcc/doc/optinfo.texi:77: warning: node prev `Dump files and 
streams' in menu `Dump output verbosity' and in sectioning `Optimization 
groups' differ
../../source/gcc/doc/optinfo.texi:104: warning: node next `Dump output 
verbosity' in menu `Dump files and streams' and in sectioning `Dump types' 
differ
../../source/gcc/doc/optinfo.texi:104: warning: node prev `Dump output 
verbosity' in menu `Optimization groups' and in sectioning `Dump files and 
streams' differ
../../source/gcc/doc/optinfo.texi:137: warning: node prev `Dump types' in 
menu `Dump files and streams' and in sectioning `Dump output verbosity' differ


Grüße,
 Thomas


pgpbEVl9Ts89I.pgp
Description: PGP signature

[committed] Fix PR59846 test

[Marek Polacek]

This patch makes the test pass even on -m32, where sizeof (int) ==
sizeof (long).  Committed as obvious.

2014-01-24  Marek Polacek  

testsuite/
* gcc.dg/pr59846.c (fn1, fn2): Use ULL suffix.

--- gcc/testsuite/gcc.dg/pr59846.c.mp   2014-01-24 11:24:49.143033290 +0100
+++ gcc/testsuite/gcc.dg/pr59846.c  2014-01-24 11:31:36.341367712 +0100
@@ -5,13 +5,13 @@
 _Bool
 fn1 (unsigned int p)
 {
-  return 0UL > p; /* { dg-warning "14:comparison is always false due to 
limited range of data type" } */
+  return 0ULL > p; /* { dg-warning "15:comparison is always false due to 
limited range of data type" } */
 }
 
 _Bool
 fn2 (unsigned int p)
 {
-  return 0UL <= p; /* { dg-warning "14:comparison is always true due to 
limited range of data type" } */
+  return 0ULL <= p; /* { dg-warning "15:comparison is always true due to 
limited range of data type" } */
 }
 
 _Bool

Marek

Re: [PATCH, SH] fix builtin_strncmp

[kkojima]

Christian Bruel  wrote:
> This patch fixes a bug of mine whereas more bytes than needed was read
> when processing remaining bytes after an aligned  word at at time loop.
> This case was not caught neither by the gcc testsuite not the glibc
> tests, Regression test included.
> 
> no new regressions with the GCC and glibc testsuites., OK for trunk ?

OK.

Regards,
kaz

Re: [RFA][PATCH] Fix tree-optimization/59919

[Jakub Jelinek]

On Thu, Jan 23, 2014 at 02:22:35PM -0700, Jeff Law wrote:
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -5891,8 +5891,13 @@ find_assert_locations_1 (basic_block bb, sbitmap live)
>   }
>   }
>  
> -   register_new_assert_for (op, op, comp_code, value, bb, NULL, si);
> -   need_assert = true;
> +   /* Do not register any assertions for a non-returning call.  */
> +   if (!is_gimple_call (stmt) || !gimple_call_noreturn_p (stmt))
> + {
> +   register_new_assert_for (op, op, comp_code,
> +value, bb, NULL, si);
> +   need_assert = true;
> + }
>   }
>   }

I'd say this belongs into infer_value_range instead.
It has:
  /* If STMT is the last statement of a basic block with no
 successors, there is no point inferring anything about any of its
 operands.  We would not be able to find a proper insertion point
 for the assertion, anyway.  */
  if (stmt_ends_bb_p (stmt) && EDGE_COUNT (gimple_bb (stmt)->succs) == 0)
return false;
so I'd say it should instead do:
  if (stmt_ends_bb_p (stmt))
{
  edge_iterator ei;
  edge e;

  FOR_EACH_EDGE (e, ei, gimple_bb (stmt)->succs)
if (!(e->flags & EDGE_ABNORMAL))
  break;
  if (e == NULL)
return false;
}
Because, there are e.g. two register_new_assert_for calls with
non-NULL bb and NULL e, so you'd need to handle this for both, etc.

Jakub

[Ada] Fix crash for bad Depends operand

[Arnaud Charlet]

This fixes a failure to properly diagnose a bad Depends operand.
The following program used to provoke this crash:

 1. procedure DependsCrash is
 2.type R is record
 3.   B : Boolean;
 4.end record;
 5.
 6.procedure Test (X : R; B : out Boolean)
   |
>>> item "X" must appear in at least one input list
of aspect Depends

 7.  with Depends => (B => X.B);
|
>>> item must denote variable, state or formal
parameter

 8.
 9.procedure Test (X : R; B : out Boolean)
10.is begin null; end;
11.
12. begin
13.null;
14. end DependsCrash;

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Robert Dewar  

* sem_prag.adb (Analyze_Input_Output): Add missing error check
for junk operand.
* sem_util.adb (Is_Refined_State): Add defense against junk
tree from error.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 207026)
+++ sem_prag.adb(working copy)
@@ -783,9 +783,9 @@
 
Item_Id := Entity_Of (Item);
 
-   Record_Possible_Body_Reference (Item, Item_Id);
+   if Present (Item_Id) then
+  Record_Possible_Body_Reference (Item, Item_Id);
 
-   if Present (Item_Id) then
   if Ekind_In (Item_Id, E_Abstract_State,
 E_In_Parameter,
 E_In_Out_Parameter,
Index: sem_util.adb
===
--- sem_util.adb(revision 207026)
+++ sem_util.adb(working copy)
@@ -3723,6 +3723,12 @@
  else
 Item_Id := Entity_Of (Item);
 
+--  Defend against junk
+
+if No (Item_Id) then
+   return False;
+end if;
+
 return
   Ekind (Item_Id) = E_Abstract_State
 and then Has_Visible_Refinement (Item_Id);

Re: Allow passing arrays in registers on AArch64

[Matthias Klose]

Am 17.01.2014 19:50, schrieb Yufeng Zhang:
> Hi Michael,
> 
> Thanks for the fix.  The patch looks OK to me in general, although I have some
> minor comments below.
> 
> On 01/17/14 08:22, Michael Hudson-Doyle wrote:
>> Hi, as discussed inhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
>> GCC currently gets a detail of the AArch64 ABI wrong: arrays are not
>> always passed by reference.  Fortunately the fix is rather easy...
> 
> Can you please indicate what kind of testing you have run, e.g. regtest on
> aarch64-none-abi?

Test with the trunk (all languages except Ada) with and without this patch:

 Running target unix
 FAIL: math
 FAIL: net
-FAIL: reflect
 FAIL: runtime

=== libgo Summary ===

-# of expected passes   118
-# of unexpected failures   4
+# of expected passes   119
+# of unexpected failures   3
 /home/doko/gcc/gcc-4.9-4.9-20140122/build/./gcc/gccgo version 4.9.0 20140122
(experimental) [trunk revision 206940] (Ubuntu 4.9-20140122-1ubuntu1)

no other changes for the tests.

I did test with the Linaro 4.8 branch, including FSF changes up to r206935, with
and without this patch:

-FAIL: io
-FAIL: os
-FAIL: reflect
-FAIL: sync
-FAIL: time
-FAIL: archive/zip
-FAIL: database/sql
-FAIL: encoding/base64
-FAIL: go/doc
-FAIL: go/printer
-FAIL: log/syslog
-FAIL: net/http/cgi
-FAIL: net/http/httputil
-FAIL: net/rpc
-FAIL: net/rpc/jsonrpc
-FAIL: old/template
-FAIL: os/exec
-FAIL: os/signal
-FAIL: sync/atomic
-FAIL: text/template

-# of expected passes   99
-# of unexpected failures   23
+# of expected passes   119
+# of unexpected failures   3

there are some XPASS's for quality tests, and FAIL's for the pr36728 quality
tests, however in the past these were always a bit noisy, succeeding or failing
for various builds.

I do see additional fails for:

+FAIL: gcc.dg/simulate-thread/atomic-other-int.c  -O0 -g  thread simulation test
+FAIL: gcc.dg/simulate-thread/atomic-other-int.c  -O2 -g  thread simulation test
+FAIL: gcc.dg/simulate-thread/atomic-other-int.c  -O3 -g  thread simulation test
+FAIL: gcc.dg/simulate-thread/atomic-other-short.c  -O0 -g  thread simulation 
test
+FAIL: gcc.dg/simulate-thread/atomic-other-short.c  -O2 -g  thread simulation 
test
+FAIL: gcc.dg/simulate-thread/atomic-other-short.c  -O3 -g  thread simulation 
test

[C++ Patch] PR 57524

[Paolo Carlini]

HI,

as far as I can see this regression, where we ICE inside timevar_start, 
is very easy to fix: just use timevar_cond_start instead (as in many 
other places for TV_NAME_LOOKUP).


Tested x86_64-linux. Seems suited for 4_8-branch too.

Thanks,
Paolo.


/cp
2014-01-24  Paolo Carlini  

PR c++/57524
* name-lookup.c (push_using_directive): Use timevar_cond_start.

/testsuite
2014-01-24  Paolo Carlini  

PR c++/57524
* g++.dg/ext/timevar2.C: New.
Index: cp/name-lookup.c
===
--- cp/name-lookup.c(revision 207026)
+++ cp/name-lookup.c(working copy)
@@ -5683,9 +5683,9 @@ static tree
 push_using_directive (tree used)
 {
   tree ret;
-  timevar_start (TV_NAME_LOOKUP);
+  bool subtime = timevar_cond_start (TV_NAME_LOOKUP);
   ret = push_using_directive_1 (used);
-  timevar_stop (TV_NAME_LOOKUP);
+  timevar_cond_stop (TV_NAME_LOOKUP, subtime);
   return ret;
 }
 
Index: testsuite/g++.dg/ext/timevar2.C
===
--- testsuite/g++.dg/ext/timevar2.C (revision 0)
+++ testsuite/g++.dg/ext/timevar2.C (working copy)
@@ -0,0 +1,14 @@
+// PR c++/57524
+// { dg-options "-ftime-report" }
+// { dg-prune-output "wall" }
+// { dg-prune-output "times" }
+// { dg-prune-output "TOTAL" }
+// { dg-prune-output "checks" }
+
+namespace detail {
+namespace indirect_traits {}
+using namespace indirect_traits;
+void fn1() {
+using namespace detail;
+}
+}

[Ada] Turn off SPARK_Mode for generated subprograms

[Arnaud Charlet]

SPARK_Mode should always be off for internally generated subprograms
When the following is compiled with -gnatdt:

 1. package IntSPARK is
 2.pragma SPARK_Mode (ON);
 3.type R is record
 4.   X : Integer := 4;
 5.   Y : Integer := 5;
 6.end record;
 7. end;

The resulting file should have just one instance of the SPARK_Pragma
field being set (in the entity for the package), it should not be
set in the spec of body of the generated initialization procedure.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Robert Dewar  

* sem_ch6.adb (Analyze_Subprogram_Body_Helper): SPARK_Mode OFF
for generated subprograms.
(Analyze_Subprogram_Specification): Ditto.

Index: sem_ch6.adb
===
--- sem_ch6.adb (revision 207026)
+++ sem_ch6.adb (working copy)
@@ -2995,9 +2995,17 @@
 
 Push_Scope (Spec_Id);
 
---  Set SPARK_Mode from spec if spec had a SPARK_Mode pragma
+--  Set SPARK_Mode
 
-if Present (SPARK_Pragma (Spec_Id))
+--  For internally generated subprogram, always off
+
+if not Comes_From_Source (Spec_Id) then
+   SPARK_Mode := Off;
+   SPARK_Mode_Pragma := Empty;
+
+--  Inherited from spec
+
+elsif Present (SPARK_Pragma (Spec_Id))
   and then not SPARK_Pragma_Inherited (Spec_Id)
 then
SPARK_Mode_Pragma := SPARK_Pragma (Spec_Id);
@@ -3058,12 +3066,19 @@
   (Body_Id, Body_Id, 'b', Set_Ref => False, Force => True);
 Install_Formals (Body_Id);
 
---  Set SPARK_Mode from context
+Push_Scope (Body_Id);
 
-Set_SPARK_Pragma (Body_Id, SPARK_Mode_Pragma);
-Set_SPARK_Pragma_Inherited (Body_Id, True);
+--  Set SPARK_Mode from context or OFF for internal routine
 
-Push_Scope (Body_Id);
+if Comes_From_Source (Body_Id) then
+   Set_SPARK_Pragma (Body_Id, SPARK_Mode_Pragma);
+   Set_SPARK_Pragma_Inherited (Body_Id, True);
+else
+   Set_SPARK_Pragma (Body_Id, Empty);
+   Set_SPARK_Pragma_Inherited (Body_Id, False);
+   SPARK_Mode := Off;
+   SPARK_Mode_Pragma := Empty;
+end if;
  end if;
 
  --  For stubs and bodies with no previous spec, generate references to
@@ -3609,9 +3624,17 @@
 
   Generate_Definition (Designator);
 
-  Set_SPARK_Pragma (Designator, SPARK_Mode_Pragma);
-  Set_SPARK_Pragma_Inherited (Designator, True);
+  --  Set SPARK mode, always off for internal routines, otherwise set
+  --  from current context (may be overwritten later with explicit pragma)
 
+  if Comes_From_Source (Designator) then
+ Set_SPARK_Pragma (Designator, SPARK_Mode_Pragma);
+ Set_SPARK_Pragma_Inherited (Designator, True);
+  else
+ Set_SPARK_Pragma (Designator, Empty);
+ Set_SPARK_Pragma_Inherited (Designator, False);
+  end if;
+
   if Debug_Flag_C then
  Write_Str ("==> subprogram spec ");
  Write_Name (Chars (Designator));

[Ada] Duplicate projects not detected

[Arnaud Charlet]

When the project path specified with environment variables ADA_PROJECT_PATH
or GPR_PROJECT_PATH, or with switch -aP includes a directory where one project
is found, this project may be used incorrectly when imported instead of the
project with a similar name in the directory of the importing project, while
a duplicated project name should have been detected.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Vincent Celier  

* prj-env.adb (Find_Project): If cached project path is not in
project directory, look in current directory first and use cached
project path only if project is not found in project directory.

Index: prj-env.adb
===
--- prj-env.adb (revision 207026)
+++ prj-env.adb (working copy)
@@ -2229,20 +2229,21 @@
   Directory  : String;
   Path   : out Namet.Path_Name_Type)
is
+  Result  : String_Access;
+  Has_Dot : Boolean := False;
+  Key : Name_Id;
+
   File : constant String := Project_File_Name;
   --  Have to do a copy, in case the parameter is Name_Buffer, which we
-  --  modify below
+  --  modify below.
 
-  function Try_Path_Name is new Find_Name_In_Path
-(Check_Filename => Is_Regular_File);
+  Cached_Path : Namet.Path_Name_Type;
+  --  This should be commented rather than making us guess from the name???
+
+  function Try_Path_Name is new
+Find_Name_In_Path (Check_Filename => Is_Regular_File);
   --  Find a file in the project search path
 
-  --  Local Declarations
-
-  Result  : String_Access;
-  Has_Dot : Boolean := False;
-  Key : Name_Id;
-
--  Start of processing for Find_Project
 
begin
@@ -2259,13 +2260,8 @@
   Name_Len := File'Length;
   Name_Buffer (1 .. Name_Len) := File;
   Key := Name_Find;
-  Path := Projects_Paths.Get (Self.Cache, Key);
+  Cached_Path := Projects_Paths.Get (Self.Cache, Key);
 
-  if Path /= No_Path then
- Debug_Decrease_Indent;
- return;
-  end if;
-
   --  Check if File contains an extension (a dot before a
   --  directory separator). If it is the case we do not try project file
   --  with an added extension as it is not possible to have multiple dots
@@ -2283,13 +2279,42 @@
 
   if not Is_Absolute_Path (File) then
 
+ --  If we have found project in the cache, check if in the directory
+
+ if Cached_Path /= No_Path then
+declare
+   Cached : constant String := Get_Name_String (Cached_Path);
+begin
+   if (not Has_Dot
+and then Cached =
+  GNAT.OS_Lib.Normalize_Pathname
+(File & Project_File_Extension,
+ Directory  => Directory,
+ Resolve_Links  => Opt.Follow_Links_For_Files,
+ Case_Sensitive => True))
+ or else
+   Cached =
+ GNAT.OS_Lib.Normalize_Pathname
+   (File,
+Directory  => Directory,
+Resolve_Links  => Opt.Follow_Links_For_Files,
+Case_Sensitive => True)
+   then
+  Path := Cached_Path;
+  Debug_Decrease_Indent;
+  return;
+   end if;
+end;
+ end if;
+
  --  First we try /.
 
  if not Has_Dot then
-Result := Try_Path_Name
-  (Self,
-   Directory & Directory_Separator &
-   File & Project_File_Extension);
+Result :=
+  Try_Path_Name
+(Self,
+ Directory & Directory_Separator &
+   File & Project_File_Extension);
  end if;
 
  --  Then we try /
@@ -2300,6 +2325,14 @@
  end if;
   end if;
 
+  --  If we found the path in the cache, this is the one
+
+  if Result = null and then Cached_Path /= No_Path then
+ Path := Cached_Path;
+ Debug_Decrease_Indent;
+ return;
+  end if;
+
   --  Then we try .
 
   if Result = null and then not Has_Dot then

[Ada] Protect against potentially uninitialized source information

[Arnaud Charlet]

Some tools that use the project manager might be creating a project
on the fly (no reference to an actual project file), which could
result in a Constraint_Error in this code.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Emmanuel Briot  

* prj-nmsc.adb (Check_File): Add protection when the source is
not fully initialized.

Index: prj-nmsc.adb
===
--- prj-nmsc.adb(revision 207032)
+++ prj-nmsc.adb(working copy)
@@ -7051,7 +7051,9 @@
 --  Check if it is OK to have the same file name in several
 --  source directories.
 
-if Source_Dir_Rank = Name_Loc.Source.Source_Dir_Rank then
+if Name_Loc.Source /= No_Source
+  and then Source_Dir_Rank = Name_Loc.Source.Source_Dir_Rank
+then
Error_Msg_File_1 := File_Name;
Error_Msg
  (Data.Flags,

[Ada] Fix problem with run-time library units and SPARK mode

[Arnaud Charlet]

The test for library units was wrong, resulting in run-time
library units being incorrectly marked with SPARK_Mode on
when a configuration pragma file had pragma SPARK_Mode (ON).

The following program

 1. with Ada.Text_IO; use Ada.Text_IO;
 2. procedure SPragLib is
 3. begin
 4.Put_Line ("Hello World!");
 5. end SPragLib;

compiled with -gnatdtf should yield a file that has only one
reference to the SPARK_Mode field, not dozens as before.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Robert Dewar  

* sem.adb (Sem): Avoid premature reference to Current_Sem_Unit
(this was causing Is_Main_Unit_Or_Main_Unit_Spec to be set wrong,
leading to wrong handling of SPARK_Mode for library units).

Index: sem.adb
===
--- sem.adb (revision 207026)
+++ sem.adb (working copy)
@@ -1312,18 +1312,19 @@
   S_Outer_Gen_Scope   : constant Entity_Id:= Outer_Generic_Scope;
   S_Style_Check   : constant Boolean  := Style_Check;
 
+  Curunit : constant Unit_Number_Type := Get_Cunit_Unit_Number (Comp_Unit);
+  --  New value of Current_Sem_Unit
+
   Generic_Main : constant Boolean :=
-   Nkind (Unit (Cunit (Main_Unit)))
- in N_Generic_Declaration;
+Nkind (Unit (Cunit (Main_Unit))) in N_Generic_Declaration;
   --  If the main unit is generic, every compiled unit, including its
   --  context, is compiled with expansion disabled.
 
   Is_Main_Unit_Or_Main_Unit_Spec : constant Boolean :=
- Current_Sem_Unit = Main_Unit
+ Curunit = Main_Unit
or else
  (Nkind (Unit (Cunit (Main_Unit))) = N_Package_Body
-   and then Library_Unit (Cunit (Main_Unit)) =
-  Cunit (Current_Sem_Unit));
+   and then Library_Unit (Cunit (Main_Unit)) = Cunit (Curunit));
   --  Configuration flags have special settings when compiling a predefined
   --  file as a main unit. This applies to its spec as well.
 
@@ -1393,7 +1394,7 @@
   end if;
 
   Compiler_State   := Analyzing;
-  Current_Sem_Unit := Get_Cunit_Unit_Number (Comp_Unit);
+  Current_Sem_Unit := Curunit;
 
   --  Compile predefined units with GNAT_Mode set to True, to properly
   --  process the categorization stuff. However, do not set GNAT_Mode

[Ada] Missing error for derived task not overriding primitive

[Arnaud Charlet]

The compiler does not report an error when a task type does not define an
entry or a procedure to cover a primitive inherited from an interface type.

After this patch the following test compiles with an error:

package Progenitor is
  type Progenitor_T is synchronized interface;

  procedure Primitive_Operation (P : Progenitor_T) is abstract;
end;

with Progenitor; use Progenitor;
package Pkg is
  task type T is new Progenitor_T with end T;

  procedure Fee;
end;

Command:i
gcc -c pkg.ads
pkg.ads:4:03: interface subprogram "Primitive_Operation" must be overridden

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Javier Miranda  

* sem_ch3.adb (Check_Abstract_Overriding): Code reestructuration
required to report the error in case of task types.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 207026)
+++ sem_ch3.adb (working copy)
@@ -9684,18 +9684,17 @@
elsif Is_Concurrent_Record_Type (T)
  and then Present (Interfaces (T))
then
-  --  The controlling formal of Subp must be of mode "out",
-  --  "in out" or an access-to-variable to be overridden.
+  --  If an inherited subprogram is implemented by a protected
+  --  procedure or an entry, then the first parameter of the
+  --  inherited subprogram shall be of mode out or in out, or
+  --  an access-to-variable parameter (RM 9.4(11.9/3))
 
-  if Ekind (First_Formal (Subp)) = E_In_Parameter
+  if Is_Protected_Type (Corresponding_Concurrent_Type (T))
+and then Ekind (First_Formal (Subp)) = E_In_Parameter
 and then Ekind (Subp) /= E_Function
+and then not Is_Predefined_Dispatching_Operation (Subp)
   then
- if not Is_Predefined_Dispatching_Operation (Subp)
-   and then Is_Protected_Type
-  (Corresponding_Concurrent_Type (T))
- then
-Error_Msg_PT (T, Subp);
- end if;
+ Error_Msg_PT (T, Subp);
 
   --  Some other kind of overriding failure
 

[Ada] Fix some missing cases of floating-point validity checks

[Arnaud Charlet]

When a program is compiled with -gnatVaf, all floating-point results
of operators must be checked, since they might yield infinite or NaN
results. Some cases of required checks, notably the result of object
declarations with initialization expressions were not being checked.

The following program, compiled with -gnatVaf

 1. with Ada.Text_IO; use Ada.Text_IO;
 2.
 3. procedure Float_Div_Inf is
 4.function Id (X : Float) return Float is (X);
 5.
 6.A : Float := Id (1.0);
 7.B : Float := Id (0.0);
 8.C : Float := A / B;
 9. begin
10.Put_Line (C'Img);
11.C := B / B;
12.Put_Line (C'Img);
13. end Float_Div_Inf;

must yield the output:

raised CONSTRAINT_ERROR : float_div_inf.adb:8 invalid data

Previously the check on line 8 was missing, line 10 printed out
+Inf, and then there was a validity check failure on line 11.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Robert Dewar  

* checks.adb (Expr_Known_Valid): Result of fpt operator never
considered valid.

Index: checks.adb
===
--- checks.adb  (revision 207026)
+++ checks.adb  (working copy)
@@ -5308,23 +5308,27 @@
   elsif Nkind_In (Expr, N_Type_Conversion, N_Qualified_Expression) then
  return Expr_Known_Valid (Expression (Expr));
 
-  --  The result of any operator is always considered valid, since we
-  --  assume the necessary checks are done by the operator. For operators
-  --  on floating-point operations, we must also check when the operation
-  --  is the right-hand side of an assignment, or is an actual in a call.
+  --  Case of expression is a non-floating-point operator. In this case we
+  --  can assume the result is valid the generated code for the operator
+  --  will include whatever checks are needed (e.g. range checks) to ensure
+  --  validity. This assumption does not hold for the floating-point case,
+  --  since floating-point operators can generate Infinite or NaN results
+  --  which are considered invalid.
 
-  elsif Nkind (Expr) in N_Op then
- if Is_Floating_Point_Type (Typ)
-and then Validity_Check_Floating_Point
-and then (Nkind_In (Parent (Expr), N_Assignment_Statement,
-   N_Function_Call,
-   N_Parameter_Association))
- then
-return False;
- else
-return True;
- end if;
+  --  Historical note: in older versions, the exemption of floating-point
+  --  types from this assumption was done only in cases where the parent
+  --  was an assignment, function call or parameter association. Presumably
+  --  the idea was that in other contexts, the result would be checked
+  --  elsewhere, but this list of cases was missing tests (at least the
+  --  N_Object_Declaration case, as shown by a reported missing validity
+  --  check), and it is not clear why function calls but not procedure
+  --  calls were tested for. It really seems more accurate and much
+  --  safer to recognize that expressions which are the result of a
+  --  floating-point operator can never be assumed to be valid.
 
+  elsif Nkind (Expr) in N_Op and then not Is_Floating_Point_Type (Typ) then
+ return True;
+
   --  The result of a membership test is always valid, since it is true or
   --  false, there are no other possibilities.
 

[Ada] Allow raise expression in return statement

[Arnaud Charlet]

In Ada 2012, a neat way to write a function that is stubbed and just
raises an exception is to write "return raise excep-name", where the
return expression is a raise expression. But the parser did not allow
that (legal) construct. This is now fixed.

The following program:

 1. procedure Return_Raise is
 2.function F return Boolean is
 3.begin
 4.   return raise Program_Error;
 5.end F;
 6.B : Boolean := F;
 7. begin
 8.null;
 9. end Return_Raise;

compiles quietly, yielding at run-time:

raised PROGRAM_ERROR : return_raise.adb:4 explicit raise

Compiled in Ada 95 mode, we get:

 1. procedure Return_Raise is
 2.function F return Boolean is
 3.begin
 4.   return raise Program_Error;
 |
>>> raise expression is an Ada 2012 feature
>>> unit must be compiled with -gnat2012 switch

 5.end F;
 6.B : Boolean := F;
 7. begin
 8.null;
 9. end Return_Raise;

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Robert Dewar  

* scans.ads: Remove Tok_Raise from Sterm, Eterm, After_SM
categories, now that Ada 95 supports raise expressions.

Index: scans.ads
===
--- scans.ads   (revision 207026)
+++ scans.ads   (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2013, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -82,6 +82,15 @@
   Tok_Others,  -- OTHERS
   Tok_Null,-- NULL
 
+  --  Note: Tok_Raise is in no categories now, it used to be Cterm, Eterm,
+  --  After_SM, but now that Ada 2012 has added raise expressions, the
+  --  raise token can appear anywhere. Note in particular that Tok_Raise
+  --  being in Eterm stopped the parser from recognizing "return raise
+  --  exception-name". This degrades error recovery slightly, and perhaps
+  --  we could do better, but not worth the effort.
+
+  Tok_Raise,   -- RAISE
+
   Tok_Dot, -- .Namext
   Tok_Apostrophe,  -- 'Namext
 
@@ -148,7 +157,6 @@
   Tok_Goto,-- GOTO Eterm, Sterm, After_SM
   Tok_If,  -- IF   Eterm, Sterm, After_SM
   Tok_Pragma,  -- PRAGMA   Eterm, Sterm, After_SM
-  Tok_Raise,   -- RAISEEterm, Sterm, After_SM
   Tok_Requeue, -- REQUEUE  Eterm, Sterm, After_SM
   Tok_Return,  -- RETURN   Eterm, Sterm, After_SM
   Tok_Select,  -- SELECT   Eterm, Sterm, After_SM

[Ada] Fix function Prj.Env.Ada_Objects_Path

[Arnaud Charlet]

Function Prj.Env.Ada_Objects_Path was no conform to its documentation,
in particular, the second call was returning the same value even if parameter
Including_Libraries was different. This patch corrects this.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Vincent Celier  

* prj-env.adb (Ada_Objects_Path): Use Ada_Objects_Path_No_Libs
to cache the result when Including_Libraries is False.
* prj-env.ads (Ada_Objects_Path): Update documentation
* prj.adb (Free (Project_Id)): Also free Ada_Objects_Path_No_Libs
(Get_Object_Directory): Return the Library_Ali_Dir only when
when Including_Libraries is True.
* prj.ads (Get_Object_Directory): Fix and complete documentation
(Project_Data): New component Ada_Objects_Path_No_Libs

Index: prj.adb
===
--- prj.adb (revision 207034)
+++ prj.adb (working copy)
@@ -1105,6 +1105,7 @@
  Free (Project.Ada_Include_Path);
  Free (Project.Objects_Path);
  Free (Project.Ada_Objects_Path);
+ Free (Project.Ada_Objects_Path_No_Libs);
  Free_List (Project.Imported_Projects, Free_Project => False);
  Free_List (Project.All_Imported_Projects, Free_Project => False);
  Free_List (Project.Languages);
@@ -1485,7 +1486,10 @@
 
  if Project.Library then
 if Project.Object_Directory = No_Path_Information
-  or else Contains_ALI_Files (Project.Library_ALI_Dir.Display_Name)
+  or else
+(Including_Libraries
+ and then
+ Contains_ALI_Files (Project.Library_ALI_Dir.Display_Name))
 then
return Project.Library_ALI_Dir.Display_Name;
 else
Index: prj.ads
===
--- prj.ads (revision 207026)
+++ prj.ads (working copy)
@@ -973,11 +973,12 @@
   Only_If_Ada : Boolean := False) return Path_Name_Type;
--  Return the object directory to use for the project. This depends on
--  whether we have a library project or a standard project. This function
-   --  might return No_Name when no directory applies.
-   --  If we have a library project file and Including_Libraries is True then
-   --  the library dir is returned instead of the object dir.
-   --  If Only_If_Ada is True, then No_Name will be returned when the project
-   --  doesn't Ada sources.
+   --  might return No_Name when no directory applies. If the project is a
+   --  library project file and Including_Libraries is True then the library
+   --  ALI dir is returned instead of the object dir, except when there is no
+   --  ALI files in the Library ALI dir and the object directory exists. If
+   --  Only_If_Ada is True, then No_Name is returned when the project doesn't
+   --  include any Ada source.
 
procedure Compute_All_Imported_Projects
  (Root_Project : Project_Id;
@@ -1400,10 +1401,15 @@
   ---
 
   Ada_Objects_Path : String_Access := null;
-  --  The cached value of ADA_OBJECTS_PATH for this project file. Do not
-  --  use this field directly outside of the compiler, use
-  --  Prj.Env.Ada_Objects_Path instead.
+  --  The cached value of ADA_OBJECTS_PATH for this project file, with
+  --  library ALI directories for library projects instead of object
+  --  directories. Do not use this field directly outside of the
+  --  compiler, use Prj.Env.Ada_Objects_Path instead.
 
+  Ada_Objects_Path_No_Libs : String_Access := null;
+  --  The cached value of ADA_OBJECTS_PATH for this project file with all
+  --  object directories (no library ALI dir for library projects).
+
   Libgnarl_Needed : Yes_No_Unknown := Unknown;
   --  Set to True when libgnarl is needed to link
 
Index: prj-env.adb
===
--- prj-env.adb (revision 207032)
+++ prj-env.adb (working copy)
@@ -219,21 +219,37 @@
 
   Dummy : Boolean := False;
 
+  Result : String_Access;
+
--  Start of processing for Ada_Objects_Path
 
begin
   --  If it is the first time we call this function for
   --  this project, compute the objects path
 
-  if Project.Ada_Objects_Path = null then
+  if Including_Libraries and then Project.Ada_Objects_Path /= null then
+ return Project.Ada_Objects_Path;
+
+  elsif not Including_Libraries
+and then Project.Ada_Objects_Path_No_Libs /= null
+  then
+ return Project.Ada_Objects_Path_No_Libs;
+
+  else
  Buffer := new String (1 .. 4096);
  For_All_Projects (Project, In_Tree, Dummy);
+ Result := new String'(Buffer (1 .. Buffer_Last));
+ Free (Buffer);
 
- Project.Ada_Objects_Path := new String'(Buffer (1 .. Buffer_Last));
- Free (Buffer);
+ if Including_Libraries then
+ 

[Ada] Semantic checks on iterator specifications.

[Arnaud Charlet]

An iterator specification can include a subtype indication in the case of an
array- or container-element iterator. This patch verifies that the subtype
indication matches the element type of the array or container.

Compiling the following must yield:

  range_in_iterator.adb:14:12: subtype indication does not match component type
  range_in_iterator.adb:20:12: subtype indication does not match element type

---
with Ada.Containers.Doubly_Linked_Lists;
procedure Range_In_Iterator is
   Zero : Integer;
   A : String := "hello world";
   type Rec is record
  Val : Integer := 111;
   end record;
   package L is new Ada.Containers.Doubly_Linked_Lists (Rec);
   Chain : L.List;
   
   R : Rec := (Val => 12345);
begin
   Zero := 0;
   for J : Integer  range Zero .. 1 of A loop
  null;
   end loop;

   Chain.Append (R);
   Chain.Append (R);
   for C : Character of Chain loop
  null;
   end loop;
end Range_In_Iterator;

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Ed Schonberg  

* sem_ch5.adb (Analyze_Iterator_Specification): If subtype
indication is given explicity, check that it matches the array
component type or the container element type of the domain
of iteration.

Index: sem_ch5.adb
===
--- sem_ch5.adb (revision 207026)
+++ sem_ch5.adb (working copy)
@@ -1680,12 +1680,21 @@
 
   Ent : Entity_Id;
   Typ : Entity_Id;
+  Bas : Entity_Id;
 
begin
   Enter_Name (Def_Id);
 
   if Present (Subt) then
  Analyze (Subt);
+
+ --  Save type of subtype indication for subsequent check.
+
+ if Nkind (Subt) = N_Subtype_Indication then
+Bas := Entity (Subtype_Mark (Subt));
+ else
+Bas := Entity (Subt);
+ end if;
   end if;
 
   Preanalyze_Range (Iter_Name);
@@ -1804,6 +1813,13 @@
  if Of_Present (N) then
 Set_Etype (Def_Id, Component_Type (Typ));
 
+if Present (Subt)
+  and then Bas /= Base_Type (Component_Type (Typ))
+then
+   Error_Msg_N
+ ("subtype indication does not match component type", Subt);
+end if;
+
  --  Here we have a missing Range attribute
 
  else
@@ -1849,6 +1865,17 @@
else
   Set_Etype (Def_Id, Entity (Element));
 
+  --  If subtype indication was given, verify that it matches
+  --  element type of container.
+
+  if Present (Subt)
+ and then Bas /= Base_Type (Etype (Def_Id))
+  then
+ Error_Msg_N
+   ("subtype indication does not match element type",
+  Subt);
+  end if;
+
   --  If the container has a variable indexing aspect, the
   --  element is a variable and is modifiable in the loop.
 

[Ada] Document check flags use in semantic analysis and expander

[Arnaud Charlet]

Document which check flags are completely set by semantic analysis,
including in ASIS mode and GNATprove mode, and which check flags are
only partially set. Analysis tools based on a tree obtained by
semantic analysis only should thus rely only on the first category of
flags to be set in the tree.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Yannick Moy  

* sinfo.ads: Add documentation of check flag fields.

Index: sinfo.ads
===
--- sinfo.ads   (revision 207026)
+++ sinfo.ads   (working copy)
@@ -516,12 +516,12 @@
--  expansion is performed and the analysis must generate a tree in a
--  form that meets additional requirements.
 
-   --  This light expansion does two transformations of the tree, that cannot
-   --  be postponed after the frontend semantic analysis:
+   --  This light expansion does two transformations of the tree that cannot
+   --  be postponed after semantic analysis:
 
--1. Replace object renamings by renamed object. This requires the
-   --   introdtion of temporaries at the point of the renaming, which must
-   --   be properly analyzed.
+   --   introduction of temporaries at the point of the renaming, which
+   --   must be properly analyzed.
 
--2. Fully qualify entity names. This is needed to generate suitable
--   local effects and call-graphs in ALI files, with the completely
@@ -549,6 +549,39 @@
--  not make sense from a user point-of-view, and that cross-references that
--  do not lead to data dependences for subprograms can be safely ignored.
 
+   ---
+   -- Check Flag Fields --
+   ---
+
+   --  The following flag fields appear in expression nodes:
+
+   --  Do_Division_Check
+   --  Do_Overflow_Check
+   --  Do_Range_Check
+
+   --  These three flags are always set by the front end during semantic
+   --  analysis, on expression nodes that may trigger the corresponding
+   --  check. The front end then inserts or not the check during expansion.
+   --  In particular, these flags should also be correctly set in ASIS mode
+   --  and GNATprove mode.
+
+   --  Note that this accounts for all nodes that trigger the corresponding
+   --  checks, except for range checks on subtype_indications, which may be
+   --  required to check that a range_constraint is compatible with the given
+   --  subtype (RM 3.2.2(11)).
+
+   --  The following flag fields appear in various nodes:
+
+   --  Do_Accessibility_Check
+   --  Do_Discriminant_Check
+   --  Do_Length_Check
+   --  Do_Storage_Check
+   --  Do_Tag_Check
+
+   --  These flags are used in some specific cases by the front end, either
+   --  during semantic analysis or during expansion, and cannot be expected
+   --  to be set on all nodes that trigger the corresponding check.
+

-- Common Flag Fields --

@@ -7325,7 +7358,7 @@
   --  N_Expression_With_Actions has type Standard_Void_Type. However some
   --  backends do not support such expression-with-actions occurring
   --  outside of a proper (non-void) expression, so this should just be
-  --  used as an intermediate representation within the front-end. Also
+  --  used as an intermediate representation within the front end. Also
   --  note that this is really an irregularity (expressions and statements
   --  are not interchangeable, and in particular an N_Null_Statement is
   --  not a proper expression), and in the long term all cases of this
@@ -7746,7 +7779,7 @@
   --  e.g. involving unconstrained array types.
 
   --  For the case of the standard gigi backend, this means that all
-  --  checks are done in the front-end.
+  --  checks are done in the front end.
 
   --  However, in the case of specialized back-ends, notably the JVM
   --  backend for JGNAT, additional requirements and restrictions apply

[Ada] Discriminant checks on view conversions

[Arnaud Charlet]

This patch adds a discriminant check on actuals in a call, that are type
conversions of a constrained discriminated object to a constrained type.

Compiling and executing discr.adb  must yield:

   discr.adb:12:11: warning: incorrect value for discriminant "J"
   discr.adb:12:11: warning: "Constraint_Error" will be raised at run time

   raised CONSTRAINT_ERROR : discr.adb:12 discriminant check failed

---
procedure Discr is
   type R (J : Integer) is null record;
   type R10 is new R(10);

   procedure P (X : in out R10) is
   begin
  null;
   end P;

   X : R(0);
begin
   P (R10(X));
end Discr;

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Ed Schonberg  

* sem_res.adb (Resolve_Actuals): If an actual is a view
conversion of a discriminated object, and the formal type is
discriminated and constrained, apply a discriminant check to
the object itself.

Index: sem_res.adb
===
--- sem_res.adb (revision 207034)
+++ sem_res.adb (working copy)
@@ -4041,6 +4041,16 @@
then
   Apply_Discriminant_Check (A, F_Typ);
 
+  --  For view conversions of a discriminated object, apply
+  --  check to object itself, the conversion alreay has the
+  --  proper type.
+
+  if Nkind (A) = N_Type_Conversion
+and then Is_Constrained (Etype (Expression (A)))
+  then
+ Apply_Discriminant_Check (Expression (A), F_Typ);
+  end if;
+
elsif Is_Access_Type (F_Typ)
  and then Is_Array_Type (Designated_Type (F_Typ))
  and then Is_Constrained (Designated_Type (F_Typ))

[Ada] Failure to detect redeclaration of constant with initial aggregate value

[Arnaud Charlet]

This patch fixes an omission in the detection of illegal redeclarations of
constants whose previous full declaration includes an expression that is an
aggregate.

Compiling double.adb must be rejected with:

   double.adb:5:04: "Data_1" conflicts with declaration at line 3

---
procedure Double is
   type Arr is array (1..10) of Integer;
   Data_1 : constant Arr := (1 => 1, others => 0);

   Data_1 : constant Arr := (others => 5);
begin
   null;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-01-24  Ed Schonberg  

* sem_ch3.adb (Constant_Redeclaration): New declaration is
illegal if previous one has an initial expression that is an
aggregate expanded into assignments.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 207039)
+++ sem_ch3.adb (working copy)
@@ -11104,10 +11104,13 @@
   --  If previous full declaration or a renaming declaration exists, or if
   --  a homograph is present, let Enter_Name handle it, either with an
   --  error or with the removal of an overridden implicit subprogram.
+  --  The previous one is a full declaration if it has an expression
+  --  (which in the case of an aggregate is indicated by the Init flag).
 
   if Ekind (Prev) /= E_Constant
 or else Nkind (Parent (Prev)) = N_Object_Renaming_Declaration
 or else Present (Expression (Parent (Prev)))
+or else Has_Init_Expression (Parent (Prev))
 or else Present (Full_View (Prev))
   then
  Enter_Name (Id);

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

[Markus Trippelsdorf]

On 2014.01.22 at 09:16 +0100, Dodji Seketeli wrote:
> Bernd Edlinger  writes:
> 
> > Hi,
> 
> Hello,
> 
> > since there was no progress in the last 2 months on that matter,
> 
> Sorry, this is my bad.  I got sidetracked by something else and forgot
> that I had the patch working et al, and all its bits that need approval
> got approved.  It still can go in right now.  It improves performance
> and fixes the issue the way it was discussed.
> 
> Here it is, regtested on x86_64-linux-gnu against trunk.
> 
> If nobody objects in the next 24 hours, I'll commit it.

The patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 .
The follow-up patch (fp == NULL check) doesn't help.

-- 
Markus

Re: [C PATCH] Improve locinfo a bit (PR c/59846)

[Andreas Schwab]

Marek Polacek  writes:

> --- gcc/testsuite/gcc.dg/pr59846.c.mp 2014-01-23 19:34:32.790368466 +0100
> +++ gcc/testsuite/gcc.dg/pr59846.c2014-01-23 19:42:00.910793437 +0100
> @@ -0,0 +1,39 @@
> +/* PR c/59846 */
> +/* { dg-do compile } */
> +/* { dg-options "-Wlogical-op -Wtype-limits" } */
> +
> +_Bool
> +fn1 (unsigned int p)
> +{
> +  return 0UL > p; /* { dg-warning "14:comparison is always false due to 
> limited range of data type" } */
> +}
> +
> +_Bool
> +fn2 (unsigned int p)
> +{
> +  return 0UL <= p; /* { dg-warning "14:comparison is always true due to 
> limited range of data type" } */
> +}

FAIL: gcc.dg/pr59846.c  (test for warnings, line 8)
FAIL: gcc.dg/pr59846.c  (test for warnings, line 14)
FAIL: gcc.dg/pr59846.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140124/gcc/testsuite/gcc.dg/pr59846.c:8:14: warning: 
comparison of unsigned expression < 0 is always false [-Wtype-limits]
/daten/aranym/gcc/gcc-20140124/gcc/testsuite/gcc.dg/pr59846.c:14:14: warning: 
comparison of unsigned expression >= 0 is always true [-Wtype-limits]

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

Re: [C++ Patch] PR 57524

[Jason Merrill]

OK for trunk and 4.8.

Jason

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

[Dodji Seketeli]

Markus Trippelsdorf  writes:

> On 2014.01.22 at 09:16 +0100, Dodji Seketeli wrote:
>> Bernd Edlinger  writes:
>> 
>> > Hi,
>> 
>> Hello,
>> 
>> > since there was no progress in the last 2 months on that matter,
>> 
>> Sorry, this is my bad.  I got sidetracked by something else and forgot
>> that I had the patch working et al, and all its bits that need approval
>> got approved.  It still can go in right now.  It improves performance
>> and fixes the issue the way it was discussed.
>> 
>> Here it is, regtested on x86_64-linux-gnu against trunk.
>> 
>> If nobody objects in the next 24 hours, I'll commit it.
>
> The patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 .
> The follow-up patch (fp == NULL check) doesn't help.

I am looking into that, sorry for the inconvenience.

-- 
Dodji

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

[Jakub Jelinek]

On Fri, Jan 24, 2014 at 04:40:52PM +0100, Dodji Seketeli wrote:
> > The patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 .
> > The follow-up patch (fp == NULL check) doesn't help.
> 
> I am looking into that, sorry for the inconvenience.

I'd say we want something like following.  Note that while the c == NULL
bailout would be usually sufficient, if you'll do:
echo foobar > ''
it would still crash.  Line 0 is used only for the special locations
(command line, built-in macros) and there is no file associated with it
anyway.

--- gcc/input.c.jj  2014-01-24 16:32:34.0 +0100
+++ gcc/input.c 2014-01-24 16:41:42.012671452 +0100
@@ -698,7 +698,13 @@ location_get_source_line (expanded_locat
   static char *buffer;
   static ssize_t len;
 
-  fcache * c = lookup_or_add_file_to_cache_tab (xloc.file);
+  if (xloc.line == 0)
+return NULL;
+
+  fcache *c = lookup_or_add_file_to_cache_tab (xloc.file);
+  if (c == NULL)
+return NULL;
+
   bool read = read_line_num (c, xloc.line, &buffer, &len);
 
   if (read && line_len)


Jakub

Re: lto-plugin: mismatch between ld's architecture and GCC's configure --host

[Thomas Schwinge]

Hi!

Ping.

On Fri, 10 Jan 2014 12:59:50 +0100, I wrote:
> Ping, after another month.  I've only received a private note from one
> build machinery manintainer who found this beyond his level of expertise,
> and wished me luck to find someone else to review.  Any takers in the new
> year?
> 
> On Sat, 14 Dec 2013 13:12:28 +0100, I wrote:
> > Ping, after another month.  Reposting the patches below; freshly
> > re-tested, both to cause no change if the new configure options are not
> > used, and to do the right thing if they are.
> > 
> > On Tue, 12 Nov 2013 14:52:37 +0100, I wrote:
> > > Could a global maintainer or build machinery maintainer please review the
> > > two unreviewed patches posted in this series?
> > > 
> > > On Mon, 4 Nov 2013 10:13:39 -0800, Cary Coutant  
> > > wrote:
> > > > >> Ping.  To sum it up, with these patches applied, there are no 
> > > > >> changes for
> > > > >> a "regular" build (not using the new configure options).  On the 
> > > > >> other
> > > > >> hand, configuring GCC as described, it is possible use the 32-bit x86
> > > > >> linker for/with a x86_64 build, and get the very same GCC test 
> > > > >> results as
> > > > >> when using a x86_64 linker.
> > > > 
> > > > Sorry, I've been hoping someone with more global approval authority
> > > > would respond.
> > > > 
> > > > > Allow overriding the libiberty used for building the LTO plugin.
> > > > >
> > > > > lto-plugin/
> > > > > * configure.ac (--with-libiberty): New configure option.
> > > > > * configure: Regenerate.
> > > > > * Makefile.am (libiberty, libiberty_pic): New variables.
> > > > > (liblto_plugin_la_LIBADD, liblto_plugin_la_LDFLAGS)
> > > > > (liblto_plugin_la_DEPENDENCIES): Use them.
> > > > > * Makefile.in: Regenerate.
> > > > 
> > > > These look OK to me.
> > > > 
> > > > > Allow for overriding a module's srcdir.
> > > > >
> > > > > * Makefile.tpl (configure-[+prefix+][+module+])
> > > > > (configure-stage[+id+]-[+prefix+][+module+]): Allow for
> > > > > overriding a module's srcdir.
> > > > > * Makefile.in: Regenerate.
> > > > 
> > > > These look OK, but I think a global maintainer or build machinery
> > > > maintainer should give approval.
> > > > 
> > > > > Non-host system configuration for linker plugins.
> > > > >
> > > > > * configure.ac (--enable-linker-plugin-flags)
> > > > > (--enable-linker-plugin-configure-flags): New flags.
> > > > > (configdirs): Conditionally add libiberty-linker-plugin.
> > > > > * configure: Regenerate.
> > > > > * Makefile.def (host_modules): Add libiberty-linker-plugin.
> > > > > (host_modules) : Pay attention to
> > > > > @extra_linker_plugin_flags@ and
> > > > > @extra_linker_plugin_configure_flags@.
> > > > > (all-lto-plugin): Also depend on all-libiberty-linker-plugin.
> > > > > * Makefile.in: Regenerate.
> > > > > gcc/
> > > > > * doc/install.texi (--enable-linker-plugin-flags)
> > > > > (--enable-linker-plugin-configure-flags): Document new flags.
> > > > 
> > > > Same here.
> > 
> > commit d09a4afcf55cde981ec9dad86950be5ade51f9eb
> > Author: Thomas Schwinge 
> > Date:   Sun Oct 13 16:15:56 2013 +0200
> > 
> > Allow overriding the libiberty used for building the LTO plugin.
> > 
> > lto-plugin/
> > * configure.ac (--with-libiberty): New configure option.
> > * configure: Regenerate.
> > * Makefile.am (libiberty, libiberty_pic): New variables.
> > (liblto_plugin_la_LIBADD, liblto_plugin_la_LDFLAGS)
> > (liblto_plugin_la_DEPENDENCIES): Use them.
> > * Makefile.in: Regenerate.
> > 
> > diff --git lto-plugin/Makefile.am lto-plugin/Makefile.am
> > index b24015e..8b7bb54 100644
> > --- lto-plugin/Makefile.am
> > +++ lto-plugin/Makefile.am
> > @@ -15,17 +15,19 @@ libexecsub_LTLIBRARIES = liblto_plugin.la
> >  gcc_build_dir = ../$(host_subdir)/gcc
> >  in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), 
> > $(gcc_build_dir)/$(lib))
> >  
> > -# Can be removed when libiberty becomes a normal convenience library
> > -Wc=-Wc,
> > -
> >  liblto_plugin_la_SOURCES = lto-plugin.c
> > +# Note that we intentionally override the bindir supplied by 
> > ACX_LT_HOST_FLAGS.
> > +liblto_plugin_la_LDFLAGS = $(lt_host_flags) -module -bindir 
> > $(libexecsubdir)
> > +# Can be simplified when libiberty becomes a normal convenience library.
> > +libiberty=$(with_libiberty)/libiberty.a
> > +libiberty_pic=$(with_libiberty)/pic/libiberty.a
> > +Wc=-Wc,
> >  liblto_plugin_la_LIBADD = \
> > -   $(if $(wildcard 
> > ../libiberty/pic/libiberty.a),$(Wc)../libiberty/pic/libiberty.a,)
> > -# Note that we intentionally override the bindir supplied by 
> > ACX_LT_HOST_FLAGS
> > -liblto_plugin_la_LDFLAGS = $(lt_host_flags) -module -bindir 
> > $(libexecsubdir) \
> > -   $(if $(wildcard 
> > ../libiberty/pic/libiberty.a)

ICE in Cilk Plus structured block checker (was: [gomp4] OpenACC structured blocks (was: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk))

[Thomas Schwinge]

Hi!

Ping.  With a different subject line, this time.  Let's first concentrate
on the ICE in the Cilk Plus structured block checker, then generalize
diagnose_omp_blocks' structured block logic, before finally getting to
the OpenACC extension.


Here starts the ICE patch:

On Fri, 10 Jan 2014 12:48:21 +0100, I wrote:
> Ping.
> 
> On Thu, 19 Dec 2013 17:49:09 +0100, I wrote:
> > Ping.
> > 
> > On Tue, 10 Dec 2013 13:53:39 +0100, I wrote:
> > > At the end of this email you can find the patch that I'd like to apply to
> > > gomp-4_0-branch for OpenACC structured blocks, after the following two
> > > have been approved:
> > 
> > > On Fri, 06 Dec 2013 19:33:35 +0100, I wrote:
> > > > On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez  
> > > > wrote:
> > > > > --- a/gcc/omp-low.c
> > > > > +++ b/gcc/omp-low.c
> > > > > @@ -10177,12 +10210,33 @@ diagnose_sb_0 (gimple_stmt_iterator *gsi_p,
> > > > >  error ("invalid entry to OpenMP structured block");
> > > > >  #endif
> > > > >  
> > > > > +  bool cilkplus_block = false;
> > > > > +  if (flag_enable_cilkplus)
> > > > > +{
> > > > > +  if ((branch_ctx
> > > > > +&& gimple_code (branch_ctx) == GIMPLE_OMP_FOR
> > > > > +&& gimple_omp_for_kind (branch_ctx) == 
> > > > > GF_OMP_FOR_KIND_CILKSIMD)
> > > > > +   || (gimple_code (label_ctx) == GIMPLE_OMP_FOR
> > > > > +   && gimple_omp_for_kind (label_ctx) == 
> > > > > GF_OMP_FOR_KIND_CILKSIMD))
> > > > > + cilkplus_block = true;
> > > > > +}
> > > > 
> > > > There is one issue here: consider the following code:
> > > > 
> > > > void baz()
> > > > {
> > > >   bad1:
> > > >   #pragma omp parallel
> > > > goto bad1;
> > > > }
> > > > 
> > > > Then, if both -fcilkplus and -fopenmp are specified, that will run into 
> > > > a
> > > > SIGSEGV/ICE because of label_ctx == NULL.  The fix is simple enough; OK
> > > > for trunk and gomp-4_0-branch (after full testing)?
> > > 
> > > Testing looks good.
> > > 
> > > > The testcase is
> > > > basically a concatenation of gcc.dg/cilk-plus/jump.c and
> > > > gcc.dg/gomp/block-1.c -- should this be done differently/better?
> > > > 
> > > > commit eee16f8aad4527b705d327476b00bf9f5ba6dcce
> > > > Author: Thomas Schwinge 
> > > > Date:   Fri Dec 6 18:55:41 2013 +0100
> > > > 
> > > > Fix possible ICE (null pointer dereference) introduced in r204863.
> > > > 
> > > > gcc/
> > > > * omp-low.c (diagnose_sb_0): Make sure label_ctx is valid to
> > > > dereference.
> > > > gcc/testsuite/
> > > > * gcc.dg/cilk-plus/jump-openmp.c: New file.
> > > > 
> > > > diff --git gcc/omp-low.c gcc/omp-low.c
> > > > index e0f7d1d..91221c0 100644
> > > > --- gcc/omp-low.c
> > > > +++ gcc/omp-low.c
> > > > @@ -10865,7 +10865,8 @@ diagnose_sb_0 (gimple_stmt_iterator *gsi_p,
> > > >if ((branch_ctx
> > > >&& gimple_code (branch_ctx) == GIMPLE_OMP_FOR
> > > >&& gimple_omp_for_kind (branch_ctx) == 
> > > > GF_OMP_FOR_KIND_CILKSIMD)
> > > > - || (gimple_code (label_ctx) == GIMPLE_OMP_FOR
> > > > + || (label_ctx
> > > > + && gimple_code (label_ctx) == GIMPLE_OMP_FOR
> > > >   && gimple_omp_for_kind (label_ctx) == 
> > > > GF_OMP_FOR_KIND_CILKSIMD))
> > > > cilkplus_block = true;
> > > >  }
> > > > diff --git gcc/testsuite/gcc.dg/cilk-plus/jump-openmp.c 
> > > > gcc/testsuite/gcc.dg/cilk-plus/jump-openmp.c
> > > > new file mode 100644
> > > > index 000..95e6b2d
> > > > --- /dev/null
> > > > +++ gcc/testsuite/gcc.dg/cilk-plus/jump-openmp.c
> > > > @@ -0,0 +1,49 @@
> > > > +/* { dg-do compile } */
> > > > +/* { dg-options "-fcilkplus -fopenmp" } */
> > > > +/* { dg-require-effective-target fopenmp } */
> > > > +
> > > > +int *a, *b, c;
> > > > +
> > > > +void foo()
> > > > +{
> > > > +#pragma simd
> > > > +  for (int i=0; i < 1000; ++i)
> > > > +{
> > > > +  a[i] = b[i];
> > > > +  if (c == 5)
> > > > +   return; /* { dg-error "invalid branch to/from a Cilk Plus 
> > > > structured block" } */
> > > > +}
> > > > +}
> > > > +
> > > > +void bar()
> > > > +{
> > > > +#pragma simd
> > > > +  for (int i=0; i < 1000; ++i)
> > > > +{
> > > > +lab:
> > > > +  a[i] = b[i];
> > > > +}
> > > > +  if (c == 6)
> > > > +goto lab; /* { dg-error "invalid entry to Cilk Plus structured 
> > > > block" } */
> > > > +}
> > > > +
> > > > +void baz()
> > > > +{
> > > > +  bad1:
> > > > +  #pragma omp parallel
> > > > +goto bad1; /* { dg-error "invalid branch to/from an OpenMP 
> > > > structured block" } */
> > > > +
> > > > +  goto bad2; /* { dg-error "invalid entry to OpenMP structured block" 
> > > > } */
> > > > +  #pragma omp parallel
> > > > +{
> > > > +  bad2: ;
> > > > +}
> > > > +
> > > > +  #pragma omp parallel
> > > > +{
> > > > +  int i;
> > > > +  goto ok1;
> > > > +  for (i = 0; i < 10; ++i)
> > > > +   { ok1: break; }
> > > > +}
> > > > +}

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

[Dodji Seketeli]

Jakub Jelinek  writes:

> On Fri, Jan 24, 2014 at 04:40:52PM +0100, Dodji Seketeli wrote:
>> > The patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 .
>> > The follow-up patch (fp == NULL check) doesn't help.
>> 
>> I am looking into that, sorry for the inconvenience.
>
> I'd say we want something like following.  Note that while the c == NULL
> bailout would be usually sufficient, if you'll do:
> echo foobar > ''
> it would still crash.  Line 0 is used only for the special locations
> (command line, built-in macros) and there is no file associated with it
> anyway.
>
> --- gcc/input.c.jj2014-01-24 16:32:34.0 +0100
> +++ gcc/input.c   2014-01-24 16:41:42.012671452 +0100
> @@ -698,7 +698,13 @@ location_get_source_line (expanded_locat
>static char *buffer;
>static ssize_t len;
>  
> -  fcache * c = lookup_or_add_file_to_cache_tab (xloc.file);
> +  if (xloc.line == 0)
> +return NULL;
> +
> +  fcache *c = lookup_or_add_file_to_cache_tab (xloc.file);
> +  if (c == NULL)
> +return NULL;
> +
>bool read = read_line_num (c, xloc.line, &buffer, &len);
>  
>if (read && line_len)

Indeed.

Though, I am testing the patch below that makes read_line_num gracefully
handle empty caches or zero locations.  The rest of the code should just
work with that as is.

* input.c (read_line_num): Gracefully handle non-file locations or
empty caches.

diff --git a/gcc/input.c b/gcc/input.c
index 547c177..b05e1da 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -600,7 +600,8 @@ static bool
 read_line_num (fcache *c, size_t line_num,
   char ** line, ssize_t *line_len)
 {
-  gcc_assert (line_num > 0);
+  if (!c || line_num < 1)
+return false;
 
   if (line_num <= c->line_num)
 {
diff --git a/gcc/testsuite/c-c++-common/cpp/warning-zero-location.c 
b/gcc/testsuite/c-c++-common/cpp/warning-zero-location.c
new file mode 100644
index 000..04a06b2
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cpp/warning-zero-location.c
@@ -0,0 +1,6 @@
+/*
+   { dg-options "-D _GNU_SOURCE" }
+   { dg-do compile }
+ */
+
+#define _GNU_SOURCE/* { dg-warning "redefined" } */
-- 
Dodji

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

[Jakub Jelinek]

On Fri, Jan 24, 2014 at 05:09:29PM +0100, Dodji Seketeli wrote:
>   * input.c (read_line_num): Gracefully handle non-file locations or
>   empty caches.
> 
> diff --git a/gcc/input.c b/gcc/input.c
> index 547c177..b05e1da 100644
> --- a/gcc/input.c
> +++ b/gcc/input.c
> @@ -600,7 +600,8 @@ static bool
>  read_line_num (fcache *c, size_t line_num,
>  char ** line, ssize_t *line_len)
>  {
> -  gcc_assert (line_num > 0);
> +  if (!c || line_num < 1)
> +return false;
>  
>if (line_num <= c->line_num)
>  {

Ok.

> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/cpp/warning-zero-location.c
> @@ -0,0 +1,6 @@
> +/*
> +   { dg-options "-D _GNU_SOURCE" }
> +   { dg-do compile }
> + */
> +
> +#define _GNU_SOURCE  /* { dg-warning "redefined" } */

I doubt this would fail without the patch though, because
fno-diagnostics-show-caret is added by default to flags.
So, I'd say you need also -fdiagnostics-show-caret in dg-options to
reproduce it.

Jakub

Re: lto-plugin: mismatch between ld's architecture and GCC's configure --host

[H.J. Lu]

On Fri, Jan 24, 2014 at 7:48 AM, Thomas Schwinge
 wrote:
> Hi!
>
> Ping.
>
> On Fri, 10 Jan 2014 12:59:50 +0100, I wrote:
>> Ping, after another month.  I've only received a private note from one
>> build machinery manintainer who found this beyond his level of expertise,
>> and wished me luck to find someone else to review.  Any takers in the new
>> year?
>>
>> On Sat, 14 Dec 2013 13:12:28 +0100, I wrote:
>> > Ping, after another month.  Reposting the patches below; freshly
>> > re-tested, both to cause no change if the new configure options are not
>> > used, and to do the right thing if they are.
>> >
>> > On Tue, 12 Nov 2013 14:52:37 +0100, I wrote:
>> > > Could a global maintainer or build machinery maintainer please review the
>> > > two unreviewed patches posted in this series?
>> > >
>> > > On Mon, 4 Nov 2013 10:13:39 -0800, Cary Coutant  
>> > > wrote:
>> > > > >> Ping.  To sum it up, with these patches applied, there are no 
>> > > > >> changes for
>> > > > >> a "regular" build (not using the new configure options).  On the 
>> > > > >> other
>> > > > >> hand, configuring GCC as described, it is possible use the 32-bit 
>> > > > >> x86
>> > > > >> linker for/with a x86_64 build, and get the very same GCC test 
>> > > > >> results as
>> > > > >> when using a x86_64 linker.
>> > > >
>> > > > Sorry, I've been hoping someone with more global approval authority
>> > > > would respond.
>> > > >
>> > > > > Allow overriding the libiberty used for building the LTO plugin.
>> > > > >
>> > > > > lto-plugin/
>> > > > > * configure.ac (--with-libiberty): New configure option.
>> > > > > * configure: Regenerate.
>> > > > > * Makefile.am (libiberty, libiberty_pic): New variables.
>> > > > > (liblto_plugin_la_LIBADD, liblto_plugin_la_LDFLAGS)
>> > > > > (liblto_plugin_la_DEPENDENCIES): Use them.
>> > > > > * Makefile.in: Regenerate.
>> > > >
>> > > > These look OK to me.
>> > > >
>> > > > > Allow for overriding a module's srcdir.
>> > > > >
>> > > > > * Makefile.tpl (configure-[+prefix+][+module+])
>> > > > > (configure-stage[+id+]-[+prefix+][+module+]): Allow for
>> > > > > overriding a module's srcdir.
>> > > > > * Makefile.in: Regenerate.
>> > > >
>> > > > These look OK, but I think a global maintainer or build machinery
>> > > > maintainer should give approval.
>> > > >
>> > > > > Non-host system configuration for linker plugins.
>> > > > >
>> > > > > * configure.ac (--enable-linker-plugin-flags)
>> > > > > (--enable-linker-plugin-configure-flags): New flags.
>> > > > > (configdirs): Conditionally add libiberty-linker-plugin.
>> > > > > * configure: Regenerate.
>> > > > > * Makefile.def (host_modules): Add libiberty-linker-plugin.
>> > > > > (host_modules) : Pay attention to
>> > > > > @extra_linker_plugin_flags@ and
>> > > > > @extra_linker_plugin_configure_flags@.
>> > > > > (all-lto-plugin): Also depend on all-libiberty-linker-plugin.
>> > > > > * Makefile.in: Regenerate.
>> > > > > gcc/
>> > > > > * doc/install.texi (--enable-linker-plugin-flags)
>> > > > > (--enable-linker-plugin-configure-flags): Document new flags.
>> > > >
>> > > > Same here.
>> >
>> > commit d09a4afcf55cde981ec9dad86950be5ade51f9eb
>> > Author: Thomas Schwinge 
>> > Date:   Sun Oct 13 16:15:56 2013 +0200
>> >
>> > Allow overriding the libiberty used for building the LTO plugin.
>> >
>> > lto-plugin/
>> > * configure.ac (--with-libiberty): New configure option.
>> > * configure: Regenerate.
>> > * Makefile.am (libiberty, libiberty_pic): New variables.
>> > (liblto_plugin_la_LIBADD, liblto_plugin_la_LDFLAGS)
>> > (liblto_plugin_la_DEPENDENCIES): Use them.
>> > * Makefile.in: Regenerate.

I have been building GCC in ia32, x86-64 and x32 formats on
Linux/x86-64.  I have

/usr/local/bin/ld:ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
not stripped
/usr/local32/bin/ld:  ELF 32-bit LSB executable, Intel 80386, version
1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
not stripped
/usr/localx32/bin/ld: ELF 32-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.4.0,
BuildID[sha1]=4e4f6bacfc5a95bd7df8518edf172f6cb8d4eb6f, not stripped

on my machine. I use appropriate ld when I use LTO.


-- 
H.J.

Re: [RFA][PATCH] Fix tree-optimization/59919

[Jeff Law]

On 01/24/14 03:52, Jakub Jelinek wrote:

On Thu, Jan 23, 2014 at 02:22:35PM -0700, Jeff Law wrote:

--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -5891,8 +5891,13 @@ find_assert_locations_1 (basic_block bb, sbitmap live)
}
}

- register_new_assert_for (op, op, comp_code, value, bb, NULL, si);
- need_assert = true;
+ /* Do not register any assertions for a non-returning call.  */
+ if (!is_gimple_call (stmt) || !gimple_call_noreturn_p (stmt))
+   {
+ register_new_assert_for (op, op, comp_code,
+  value, bb, NULL, si);
+ need_assert = true;
+   }
}
}


I'd say this belongs into infer_value_range instead.

Seems reasonable.  I'll spin that.

The only downside is we lose the ability to backward propagate through a 
typecast which feeds an argument in such a call.   But that's probably 
not a big deal.


Jeff

Re: [RFA][PATCH] Fix tree-optimization/59919

[Jakub Jelinek]

On Fri, Jan 24, 2014 at 09:35:10AM -0700, Jeff Law wrote:
> On 01/24/14 03:52, Jakub Jelinek wrote:
> >On Thu, Jan 23, 2014 at 02:22:35PM -0700, Jeff Law wrote:
> >>--- a/gcc/tree-vrp.c
> >>+++ b/gcc/tree-vrp.c
> >>@@ -5891,8 +5891,13 @@ find_assert_locations_1 (basic_block bb, sbitmap 
> >>live)
> >>}
> >>}
> >>
> >>- register_new_assert_for (op, op, comp_code, value, bb, NULL, si);
> >>- need_assert = true;
> >>+ /* Do not register any assertions for a non-returning call.  */
> >>+ if (!is_gimple_call (stmt) || !gimple_call_noreturn_p (stmt))
> >>+   {
> >>+ register_new_assert_for (op, op, comp_code,
> >>+  value, bb, NULL, si);
> >>+ need_assert = true;
> >>+   }
> >>}
> >>}
> >
> >I'd say this belongs into infer_value_range instead.
> Seems reasonable.  I'll spin that.
> 
> The only downside is we lose the ability to backward propagate
> through a typecast which feeds an argument in such a call.   But
> that's probably not a big deal.

I couldn't actually reproduce any backwards propagation,
since now all pointer casts are useless, so the code to walk the pointer
casts is likely just dead.

Jakub

Re: C++ PATCH for c++/59659 (compile-hog with list-initialization of member array)

[Jason Merrill]

On 01/15/2014 02:08 PM, Jason Merrill wrote:

1) Because atomics do have user-provided constructors, we were going
down the constructor path and not realizing that it just gave us
zero-initialization.  Fixed by calling maybe_constant_value and avoiding
adding extra zero-initialization to the end of the CONSTRUCTOR.

2) If we aren't dealing with zero-initialization, when we
value-initialize a bunch of elements at the end of an array, we really
ought to use a loop rather than initializing them individually.  Fixed
by using RANGE_EXPR and build_vec_init.


We really aren't ready to use RANGE_EXPR, as it turns out; a lot of 
places need to be changed to handle it, and this doesn't seem like the 
time in the development cycle for that sort of change.  So I'm reverting 
#2 until the next stage 1, to fix c++/59886.



commit c3a3e3bd9f8a4f03cd79b706d8005ca2f4c02cd1
Author: Jason Merrill 
Date:   Thu Jan 23 15:51:05 2014 -0500

	PR c++/59886
	PR c++/59659
	* typeck2.c (process_init_constructor_array): Don't create
	RANGE_EXPR yet.

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 897570a..a3fe2e3 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1201,42 +1201,40 @@ process_init_constructor_array (tree type, tree init,
   flags |= picflag_from_initializer (ce->value);
 }
 
-  /* No more initializers. If the array is unbounded, or we've initialized
- all the elements, we are done. Otherwise, we must add initializers
- ourselves.  */
-  if (!unbounded && i < len)
-{
-  tree next;
+  /* No more initializers. If the array is unbounded, we are done. Otherwise,
+ we must add initializers ourselves.  */
+  if (!unbounded)
+for (; i < len; ++i)
+  {
+	tree next;
 
-  if (type_build_ctor_call (TREE_TYPE (type)))
-	{
-	  /* If this type needs constructors run for default-initialization,
-	 we can't rely on the back end to do it for us, so make the
-	 initialization explicit by list-initializing from {}.  */
-	  next = build_constructor (init_list_type_node, NULL);
-	  next = massage_init_elt (TREE_TYPE (type), next, complain);
-	  if (initializer_zerop (next))
-	/* The default zero-initialization is fine for us; don't
-	   add anything to the CONSTRUCTOR.  */
-	next = NULL_TREE;
-	}
-  else if (!zero_init_p (TREE_TYPE (type)))
-	next = build_zero_init (TREE_TYPE (type),
-/*nelts=*/NULL_TREE,
-/*static_storage_p=*/false);
-  else
-	/* The default zero-initialization is fine for us; don't
-	   add anything to the CONSTRUCTOR.  */
-	next = NULL_TREE;
+	if (type_build_ctor_call (TREE_TYPE (type)))
+	  {
+	/* If this type needs constructors run for default-initialization,
+	   we can't rely on the back end to do it for us, so make the
+	   initialization explicit by list-initializing from {}.  */
+	next = build_constructor (init_list_type_node, NULL);
+	next = massage_init_elt (TREE_TYPE (type), next, complain);
+	if (initializer_zerop (next))
+	  /* The default zero-initialization is fine for us; don't
+		 add anything to the CONSTRUCTOR.  */
+	  next = NULL_TREE;
+	  }
+	else if (!zero_init_p (TREE_TYPE (type)))
+	  next = build_zero_init (TREE_TYPE (type),
+  /*nelts=*/NULL_TREE,
+  /*static_storage_p=*/false);
+	else
+	  /* The default zero-initialization is fine for us; don't
+	 add anything to the CONSTRUCTOR.  */
+	  next = NULL_TREE;
 
-  if (next)
-	{
-	  flags |= picflag_from_initializer (next);
-	  tree index = build2 (RANGE_EXPR, sizetype, size_int (i),
-			   size_int (len - 1));
-	  CONSTRUCTOR_APPEND_ELT (v, index, next);
-	}
-}
+	if (next)
+	  {
+	flags |= picflag_from_initializer (next);
+	CONSTRUCTOR_APPEND_ELT (v, size_int (i), next);
+	  }
+  }
 
   CONSTRUCTOR_ELTS (init) = v;
   return flags;
diff --git a/gcc/testsuite/g++.dg/init/aggr10.C b/gcc/testsuite/g++.dg/init/aggr10.C
new file mode 100644
index 000..e494e20
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/aggr10.C
@@ -0,0 +1,6 @@
+// PR c++/59886
+
+struct A { A (); ~A (); };
+struct B { A b[4]; };
+struct C { B c[5]; };
+const C e = {};

Re: [RFA][PATCH] Fix tree-optimization/59919

[Jeff Law]

On 01/24/14 09:41, Jakub Jelinek wrote:


The only downside is we lose the ability to backward propagate
through a typecast which feeds an argument in such a call.   But
that's probably not a big deal.


I couldn't actually reproduce any backwards propagation,
since now all pointer casts are useless, so the code to walk the pointer
casts is likely just dead.
I ran across some not terribly long ago and added similar code to DOM. 
You just need to try harder :-)



jeff

Re: [AArch64] fix big.LITTLE spec rewriting

[Marcus Shawcroft]

On 21 January 2014 10:48, James Greenhalgh  wrote:

> 2014-01-21  James Greenhalgh  
>
> * common/config/aarch64/aarch64-common.c
> (aarch64_rewrite_mcpu): Handle multiple names.
> * config/aarch64/aarch64.h
> (BIG_LITTLE_SPEC): Do not discard mcpu switches.

OK /Marcus

Re: [C PATCH] Improve locinfo a bit (PR c/59846)

[Marek Polacek]

On Fri, Jan 24, 2014 at 04:06:50PM +0100, Andreas Schwab wrote:
> FAIL: gcc.dg/pr59846.c  (test for warnings, line 8)
> FAIL: gcc.dg/pr59846.c  (test for warnings, line 14)
> FAIL: gcc.dg/pr59846.c (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20140124/gcc/testsuite/gcc.dg/pr59846.c:8:14: warning: 
> comparison of unsigned expression < 0 is always false [-Wtype-limits]
> /daten/aranym/gcc/gcc-20140124/gcc/testsuite/gcc.dg/pr59846.c:14:14: warning: 
> comparison of unsigned expression >= 0 is always true [-Wtype-limits]

Should be already fixed by r207026.

Marek

[jit] Use access methods for context options

[David Malcolm]

Committed to dmalcolm/jit:

gcc/jit/
* internal-api.h (gcc::jit::context::get_str_option): New access
method.
(gcc::jit::context::get_int_option): Likewise.

* internal-api.c (gcc::jit::context::~context): Use access methods
for options, rather than direct field access.
(gcc::jit::context::compile): Likewise.
---
 gcc/jit/ChangeLog.jit  | 10 ++
 gcc/jit/internal-api.c | 20 ++--
 gcc/jit/internal-api.h | 12 
 3 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index f4127d1..cdf9ddb 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,13 @@
+2014-01-24  David Malcolm  
+
+   * internal-api.h (gcc::jit::context::get_str_option): New access
+   method.
+   (gcc::jit::context::get_int_option): Likewise.
+
+   * internal-api.c (gcc::jit::context::~context): Use access methods
+   for options, rather than direct field access.
+   (gcc::jit::context::compile): Likewise.
+
 2014-01-23  David Malcolm  
 
* libgccjit.h (enum gcc_jit_bool_option): New value:
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 869185a..32af625 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -24,7 +24,7 @@
 gcc::jit::context::
 ~context ()
 {
-  if (m_bool_options[GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES])
+  if (get_bool_option (GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES))
 fprintf (stderr, "intermediate files written to %s\n", m_path_tempdir);
   else
 {
@@ -1213,7 +1213,7 @@ compile ()
 
   /* Pass in user-provided "progname", if any, so that it makes it
  into GCC's "progname" global, used in various diagnostics. */
-  progname = m_str_options[GCC_JIT_STR_OPTION_PROGNAME];
+  progname = get_str_option (GCC_JIT_STR_OPTION_PROGNAME);
   fake_args[0] = progname ? progname : "libgccjit.so";
 
   fake_args[1] = m_path_c_file;
@@ -1230,11 +1230,11 @@ compile ()
   ADD_ARG ("-fPIC");
 
   /* Handle int options: */
-  switch (m_int_options[GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL])
+  switch (get_int_option (GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL))
 {
 default:
   add_error ("unrecognized optimization level: %i",
-m_int_options[GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL]);
+get_int_option (GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL));
   goto error;
 
 case 0:
@@ -1256,18 +1256,18 @@ compile ()
   /* What about -Os? */
 
   /* Handle bool options: */
-  if (m_bool_options[GCC_JIT_BOOL_OPTION_DEBUGINFO])
+  if (get_bool_option (GCC_JIT_BOOL_OPTION_DEBUGINFO))
 ADD_ARG ("-g");
 
   /* Suppress timing (and other) info.  */
-  if (!m_bool_options[GCC_JIT_BOOL_OPTION_DUMP_SUMMARY])
+  if (!get_bool_option (GCC_JIT_BOOL_OPTION_DUMP_SUMMARY))
 {
   ADD_ARG ("-quiet");
   quiet_flag = 1;
 }
 
   /* Aggressively garbage-collect, to shake out bugs: */
-  if (m_bool_options[GCC_JIT_BOOL_OPTION_SELFCHECK_GC])
+  if (get_bool_option (GCC_JIT_BOOL_OPTION_SELFCHECK_GC))
 {
   ADD_ARG ("--param");
   ADD_ARG ("ggc-min-expand=0");
@@ -1275,7 +1275,7 @@ compile ()
   ADD_ARG ("ggc-min-heapsize=0");
 }
 
-  if (m_bool_options[GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING])
+  if (get_bool_option (GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING))
 {
   ADD_ARG ("-fdump-tree-all");
   ADD_ARG ("-fdump-rtl-all");
@@ -1302,8 +1302,8 @@ compile ()
   goto error;
 }
 
-  if (m_bool_options[GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE])
-  dump_generated_code ();
+  if (get_bool_option (GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE))
+dump_generated_code ();
 
   timevar_push (TV_ASSEMBLE);
 
diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h
index b226c23..3f0e9eb 100644
--- a/gcc/jit/internal-api.h
+++ b/gcc/jit/internal-api.h
@@ -135,6 +135,18 @@ public:
   set_bool_option (enum gcc_jit_bool_option opt,
   int value);
 
+  const char *
+  get_str_option (enum gcc_jit_str_option opt) const
+  {
+return m_str_options[opt];
+  }
+
+  int
+  get_int_option (enum gcc_jit_int_option opt) const
+  {
+return m_int_options[opt];
+  }
+
   int
   get_bool_option (enum gcc_jit_bool_option opt) const
   {
-- 
1.7.11.7

Re: [PATCH] add __attribute__ ((designated_init))

[Joseph S. Myers]

On Thu, 23 Jan 2014, Tom Tromey wrote:

> In this error, should I use "%" rather than just plain "struct"
> as well?

I think that's best (generally, %<%> or %q with anything quoting a 
source-code construct - anything that would go in a fixed-width font in 
documentation - "struct" is such a case, the English word is "structure").

> +  if (!implicit && warn_designated_init && !was_designated
> +  && TREE_CODE (constructor_type) == RECORD_TYPE
> +  && lookup_attribute ("designated_init",
> +TYPE_ATTRIBUTES (constructor_type)))
> +warning_init (OPT_Wdesignated_init,
> +   "positional initialization of field "
> +   "in struct declared with designated_init attribute");

Also % and % here.

> +@item designated_init
> +This attribute may only be applied to struct types.  It indicates that

And @code{struct} (or "structure") here.

Is there a reason someone using the attribute might not want the warning?  
That is, why isn't -Wdesignated-init enabled by default, given that it's 
only relevant to people using an attribute whose sole function relates to 
the warning?

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH, ARM] Suppress Redundant Flag Setting for Cortex-A15

[Ian Bolton]

Hi there!

An existing optimisation for Thumb-2 converts t32 encodings to
t16 encodings to reduce codesize, at the expense of causing
redundant flag setting for ADD, AND, etc.  This redundant flag
setting can have negative performance impact on cortex-a15.

This patch introduces two new tuning options so that the conversion
from t32 to t16, which takes place in thumb2_reorg, can be suppressed
for cortex-a15.

To maintain some of the original benefit (reduced codesize), the
suppression is only done where the enclosing basic block is deemed
worthy of optimising for speed.

This tested with no regressions and performance has improved for
the workloads tested on cortex-a15.  (It might be beneficial to
other processors too, but that has not been investigated yet.)

OK for stage 1?

Cheers,
Ian


2014-01-24  Ian Bolton  

gcc/
* config/arm/arm-protos.h (tune_params): New struct members.
* config/arm/arm.c: Initialise tune_params per processor.
(thumb2_reorg): Suppress conversion from t32 to t16 when
optimizing for speed, based on new tune_params.
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 13874ee..74645ee 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -272,6 +272,11 @@ struct tune_params
   const struct cpu_vec_costs* vec_costs;
   /* Prefer Neon for 64-bit bitops.  */
   bool prefer_neon_for_64bits;
+  /* Prefer 32-bit encoding instead of flag-setting 16-bit encoding.  */
+  bool disparage_flag_setting_t16_encodings;
+  /* Prefer 32-bit encoding instead of 16-bit encoding where subset of flags
+ would be set.  */
+  bool disparage_partial_flag_setting_t16_encodings;
 };
 
 extern const struct tune_params *current_tune;
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index fc81bf6..1ebaf84 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -1481,7 +1481,8 @@ const struct tune_params arm_slowmul_tune =
   false,   /* Prefer LDRD/STRD.  */
   {true, true},/* Prefer non short 
circuit.  */
   &arm_default_vec_cost,/* Vectorizer costs.  */
-  false /* Prefer Neon for 64-bits 
bitops.  */
+  false,/* Prefer Neon for 64-bits 
bitops.  */
+  false, false  /* Prefer 32-bit encodings.  */
 };
 
 const struct tune_params arm_fastmul_tune =
@@ -1497,7 +1498,8 @@ const struct tune_params arm_fastmul_tune =
   false,   /* Prefer LDRD/STRD.  */
   {true, true},/* Prefer non short 
circuit.  */
   &arm_default_vec_cost,/* Vectorizer costs.  */
-  false /* Prefer Neon for 64-bits 
bitops.  */
+  false,/* Prefer Neon for 64-bits 
bitops.  */
+  false, false  /* Prefer 32-bit encodings.  */
 };
 
 /* StrongARM has early execution of branches, so a sequence that is worth
@@ -1516,7 +1518,8 @@ const struct tune_params arm_strongarm_tune =
   false,   /* Prefer LDRD/STRD.  */
   {true, true},/* Prefer non short 
circuit.  */
   &arm_default_vec_cost,/* Vectorizer costs.  */
-  false /* Prefer Neon for 64-bits 
bitops.  */
+  false,/* Prefer Neon for 64-bits 
bitops.  */
+  false, false  /* Prefer 32-bit encodings.  */
 };
 
 const struct tune_params arm_xscale_tune =
@@ -1532,7 +1535,8 @@ const struct tune_params arm_xscale_tune =
   false,   /* Prefer LDRD/STRD.  */
   {true, true},/* Prefer non short 
circuit.  */
   &arm_default_vec_cost,/* Vectorizer costs.  */
-  false /* Prefer Neon for 64-bits 
bitops.  */
+  false,/* Prefer Neon for 64-bits 
bitops.  */
+  false, false  /* Prefer 32-bit encodings.  */
 };
 
 const struct tune_params arm_9e_tune =
@@ -1548,7 +1552,8 @@ const struct tune_params arm_9e_tune =
   false,   /* Prefer LDRD/STRD.  */
   {true, true},/* Prefer non short 
circuit.  */
   &arm_default_vec_cost,/* Vectorizer costs.  */
-  false /* Prefer Neon for 64-bits 
bitops.  */
+  false,/* Prefer Neon for 64-bits 
bitops.  */
+  false, false  /* Prefer 32-bit encodings.  */
 };
 
 const struct tune_params arm_v6t2_tune =
@@ -1564,7 +1569,8 @@ const struc

Re: [PATCH] add __attribute__ ((designated_init))

[Tom Tromey]

Joseph> I think that's best (generally, %<%> or %q with anything quoting
Joseph> a source-code construct - anything that would go in a
Joseph> fixed-width font in documentation - "struct" is such a case, the
Joseph> English word is "structure").

Makes sense.  I'll fix it all up.

Joseph> Is there a reason someone using the attribute might not want the
Joseph> warning?  That is, why isn't -Wdesignated-init enabled by
Joseph> default, given that it's only relevant to people using an
Joseph> attribute whose sole function relates to the warning?

Yes, good point -- and sparse enables this by default as well, which
somehow I hadn't noticed before.  I will do the same for gcc.

Tom

Re: Two build != host fixes

[Jeff Law]

On 01/23/14 16:02, Alan Modra wrote:

On Wed, Jan 22, 2014 at 09:21:46PM -0700, Jeff Law wrote:

* Makefile.in (BUILD_CPPFLAGS): Do not use ALL_CPPFLAGS.
* configure.ac : Define
GENERATOR_FILE.  Comment.  Use CXX_FOR_BUILD, CXXFLAGS_FOR_BUILD
and LD_FOR_BUILD too.
* configure: Regenerate.

The configure.ac changes look fine to me.


Thanks!  That part alone ought to fix the in-tree gmp breakage.
Feel free to push that one through now since it seems like a bit of a 
no-brainer.






Not sure about the Makefile.in changes, probably because I simply
don't understand this mess anymore.  Is it the $INCLUDES or
$CPPFLAGS from ALL_CPPFLAGS that causes the problem?  I'm guessing
the latter since it's substituted via @CPPFLAGS@.

If so, shouldn't we use BUILD_CPPFLAGS=$INCLUDES $(CPPINC)?


INCLUDES is the problem.

INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
   -I$(srcdir)/../include @INCINTL@ \
   $(CPPINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \
   $(CLOOGINC) $(ISLINC)
?!?  Not sure how I missed that.  Yea, and thanks for touching on ISLINC 
and CLOOGINC since those were my first thoughts when I looked at this again.



Of course, then your question becomes, why exclude CPPFLAGS?  (And if
CPPFLAGS needs to be excluded here, then I should have just used
CPPFLAGS=-DGENERATOR_FILE for the recursive configure call..)  I'm not
sure now, I'll have to do some digging.  Also as to why @INCINTL@ was
removed, when gettext is potentially needed for the gen programs.
Thanks.  My inclination is to go forward with this hunk as well, with 
any tweaks you find after investigating the situation around CPPFLAGS.


Jeff

Re: C++ PATCH for c++/59659 (compile-hog with list-initialization of member array)

[Jakub Jelinek]

On Fri, Jan 24, 2014 at 11:47:17AM -0500, Jason Merrill wrote:
> On 01/15/2014 02:08 PM, Jason Merrill wrote:
> >1) Because atomics do have user-provided constructors, we were going
> >down the constructor path and not realizing that it just gave us
> >zero-initialization.  Fixed by calling maybe_constant_value and avoiding
> >adding extra zero-initialization to the end of the CONSTRUCTOR.
> >
> >2) If we aren't dealing with zero-initialization, when we
> >value-initialize a bunch of elements at the end of an array, we really
> >ought to use a loop rather than initializing them individually.  Fixed
> >by using RANGE_EXPR and build_vec_init.
> 
> We really aren't ready to use RANGE_EXPR, as it turns out; a lot of
> places need to be changed to handle it, and this doesn't seem like
> the time in the development cycle for that sort of change.  So I'm
> reverting #2 until the next stage 1, to fix c++/59886.

Wouldn't my patch then be useful short-term partial fix for 4.9 and
we could revert it when RANGE_EXPR are committed again to 5.0?

Jakub

Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Thomas Schwinge]

Hi!

On Thu, 23 Jan 2014 22:01:19 +0400, Ilmir Usmanov  wrote:
> Jakub, could you review these patches, if they are OK to gomp-4_0-branch?
> 
> Thomas, please, have a look whether this implementation applies current 
> OpenACC support style.

So, in context of
,
I'll give a try with reviewing the patches you sent.  But, don't hold
your breath -- it's late on a Friday evening already (and even later in
your timezone).  ;-)

> These patches port OpenACC 1.0 support in fortran front-end from 
> openacc-1_0-branch to gomp-4_0-branch. In addition, they extend 
> middle-end infrastructure with necessary GENERIC nodes.

Again, many thanks for porting these patches!  That will definitely help
in synchronizing and then parallelizing our development work.

> Patches support almost all directives (except loop) and all clauses from 
> the specification ver. 1.0 (without subarrays).  [...]

That is totally fine; incremental development.


Grüße,
 Thomas


pgpQqr304i2Zf.pgp
Description: PGP signature

Re: [PATCH] Set correct probability for ORDER/UNORDER jumps

[Dehao Chen]

A new test is added:

gcc/testsuite/ChangeLog:

2014-01-24  Dehao Chen  

* gcc.dg/predict-8.c: New test.

Index: gcc/testsuite/gcc.dg/predict-8.c
===
--- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
+++ gcc/testsuite/gcc.dg/predict-8.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options "-O2 -fdump-rtl-expand -c" } */
+
+int foo(float a, float b) {
+  if (a == b)
+return 1;
+  else
+return 2;
+}
+
+/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 100" 1 "expand"} } */
+/* { dg-final { cleanup-rtl-dump "expand" } } */

On Thu, Jan 23, 2014 at 4:30 PM, Xinliang David Li  wrote:
> Is it possible to add a test case?
>
> David
>
> On Wed, Jan 22, 2014 at 6:08 PM, Dehao Chen  wrote:
>> During floating point comparison, compiler inserts conditional jumps
>> to check if the operand is NAN. These type of checks are normally
>> false. However, compiler sets the probability the same as the original
>> float-compare conditional jump. This patch sets the probability of
>> these conditional jumps as 1%.
>>
>> Bootstrapped and passed regression test.
>>
>> OK for trunk?
>>
>> Thanks,
>> Dehao
>>
>> gcc/ChangeLog:
>> 2014-01-22  Dehao Chen  
>>
>> * dojump.c (do_compare_rtx_and_jump): Sets correct probability for
>> compiler inserted conditional jumps for NAN float check.
>>
>> Index: gcc/dojump.c
>> ===
>> --- gcc/dojump.c (revision 206945)
>> +++ gcc/dojump.c (working copy)
>> @@ -1103,6 +1103,11 @@ do_compare_rtx_and_jump (rtx op0, rtx op1, enum rt
>>
>>else
>>  {
>> +  int first_prob = prob;
>> +  if (first_code == UNORDERED)
>> + first_prob = REG_BR_PROB_BASE / 100;
>> +  else if (first_code == ORDERED)
>> + first_prob = REG_BR_PROB_BASE - REG_BR_PROB_BASE / 100;
>>if (and_them)
>>   {
>>rtx dest_label;
>> @@ -1116,11 +1121,13 @@ do_compare_rtx_and_jump (rtx op0, rtx op1, enum rt
>>else
>>  dest_label = if_false_label;
>>do_compare_rtx_and_jump (op0, op1, first_code,
>> unsignedp, mode,
>> -   size, dest_label, NULL_RTX, prob);
>> +   size, dest_label, NULL_RTX,
>> +   first_prob);
>>   }
>>else
>>  do_compare_rtx_and_jump (op0, op1, first_code, unsignedp, 
>> mode,
>> - size, NULL_RTX, if_true_label, prob);
>> + size, NULL_RTX, if_true_label,
>> + first_prob);
>>  }
>>   }

Re: [PATCH] Set correct probability for ORDER/UNORDER jumps

[Jakub Jelinek]

On Fri, Jan 24, 2014 at 10:20:53AM -0800, Dehao Chen wrote:
> --- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
> +++ gcc/testsuite/gcc.dg/predict-8.c (revision 0)
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target { x86_64-*-* } } } */

If you want it for x86_64 64-bit, then
/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */

(or just limit the scan-rtl-dump-times regexp to the above mentioned
target).

> +/* { dg-options "-O2 -fdump-rtl-expand -c" } */

No -c in dg-options please.

Jakub

Re: C++ PATCH for c++/59659 (compile-hog with list-initialization of member array)

[Jason Merrill]

On 01/24/2014 12:53 PM, Jakub Jelinek wrote:

Wouldn't my patch then be useful short-term partial fix for 4.9 and
we could revert it when RANGE_EXPR are committed again to 5.0?


Your patch helps your testcase, but not the original testcase or my 
reduced testcase, so I'm not sure it's worth the risk at this point.


Jason

C++ PATCH for c++/58550 (ICE on invalid 'auto' with LTO)

[Jason Merrill]

Here, we were just giving a pedwarn about the invalid-in-C++11 
declaration of 'auto foo()' and then not giving the C++1y error about 
using a function with an undeduced return type in the initializer of fp, 
leading to confusion in LTO.  The simplest fix is to raise the pedwarn 
to a hard error.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit a3027fa4dc4869f90fb4228b5ba67c7f1df3f108
Author: Jason Merrill 
Date:   Fri Jan 24 12:07:11 2014 -0500

	PR c++/58550
	* decl.c (grokdeclarator): Turn pedwarn about auto return type in
	c++11 into error.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index f4819a6..aaafaa8 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -9599,9 +9599,14 @@ grokdeclarator (const cp_declarator *declarator,
 			&& LAMBDA_TYPE_P (current_class_type))
 			  /* OK for C++11 lambdas.  */;
 			else if (cxx_dialect < cxx1y)
-			  pedwarn (input_location, 0, "%qs function uses "
+			  {
+			error ("%qs function uses "
    "% type specifier without trailing "
    "return type", name);
+			inform (input_location, "deduced return type "
+"only available with -std=c++1y or "
+"-std=gnu++1y");
+			  }
 			else if (virtualp)
 			  permerror (input_location, "virtual function cannot "
  "have deduced return type");
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto41.C b/gcc/testsuite/g++.dg/cpp0x/auto41.C
new file mode 100644
index 000..6f102e7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/auto41.C
@@ -0,0 +1,5 @@
+// PR c++/58550
+// { dg-options "-std=c++11" }
+
+auto foo();			// { dg-error "auto" }
+auto fp = foo;

Re: [PATCH 4/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Thomas Schwinge]

Hi!

On Thu, 23 Jan 2014 22:04:45 +0400, Ilmir Usmanov  wrote:
> Subject: [PATCH 4/6] OpenACC GENERIC nodes

> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c

> @@ -7846,6 +7907,18 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
> gimple_seq *post_p,
> ret = GS_ALL_DONE;
> break;
>  
> +  case OACC_KERNELS:
> +  case OACC_DATA:
> +  case OACC_CACHE:
> +  case OACC_WAIT:
> +  case OACC_HOST_DATA:
> +  case OACC_DECLARE:
> +  case OACC_UPDATE:
> +  case OACC_ENTER_DATA:
> +  case OACC_EXIT_DATA:
> +ret = GS_ALL_DONE;
> +break;

Would it make sense, until it is really implemented, to add something
like:

sorry ("directive not yet implemented");

That way it'd be more obvious that this still missing.

> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -1543,10 +1543,12 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
>   break;
> /* FALLTHRU */
>  
> - case OMP_CLAUSE_FIRSTPRIVATE:
> - case OMP_CLAUSE_REDUCTION:
>   case OMP_CLAUSE_LINEAR:
> gcc_assert (gimple_code (ctx->stmt) != GIMPLE_OACC_PARALLEL);
> +/* FALLTHRU. */
> +
> +  case OMP_CLAUSE_FIRSTPRIVATE: /* == OACC_CLAUSE_FIRSTPRIVATE. */
> +  case OMP_CLAUSE_REDUCTION: /* == OACC_CLAUSE_REDUCTION. */
> decl = OMP_CLAUSE_DECL (c);
>   do_private:
> if (is_variable_sized (decl))

By the way, what I have been using these gcc_asserts for, is to mark all
code paths that I had not yet verified to be suitable for OpenACC.  As
we're now close to adding additional GIMPLE_OACC_* codes, maybe we should
have some gimple_code_is_oacc function instead of just watching out for
GIMPLE_OACC_PARALLEL?  That is, if we generally do agree that we want to
continue putting such gcc_asserts into the code?

> @@ -1713,6 +1719,35 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
>   install_var_local (decl, ctx);
> break;
>  
> +  case OACC_CLAUSE_COPY:
> +  case OACC_[...]
> +/* Not implemented yet. */
> +break;

> @@ -1822,6 +1856,38 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
> gcc_assert (gimple_code (ctx->stmt) != GIMPLE_OACC_PARALLEL);
> break;
>  
> +  case OACC_CLAUSE_COPY:
> +  case OACC_[...]
> +/* Not implemented yet. */
> +break;

Likewise for these, I wonder, add a sorry messages?

> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -216,12 +216,18 @@ enum omp_clause_code {
>/* OpenMP clause: private (variable_list).  */
>OMP_CLAUSE_PRIVATE,
>  
> +  /* OpenACC clause: private (variable_list). */
> +  OACC_CLAUSE_PRIVATE = OMP_CLAUSE_PRIVATE,

I prefer to avoid such duplicate names; here and in other instances in
the following.  I think they mostly just add redundancy.  Instead, I
prefer to map (in my mind) the existing OMP_CLAUSE_* to
OACC_or_OMP_CLAUSE_*.  Is that acceptable for you?

>/* OpenMP clause: copyin (variable_list).  */
>OMP_CLAUSE_COPYIN,
>  
> +  /* OpenACC clause: copyin (variable_list).  */
> +  OACC_CLAUSE_COPYIN = OMP_CLAUSE_COPYIN,
> +
>/* OpenMP clause: copyprivate (variable_list).  */
>OMP_CLAUSE_COPYPRIVATE,
>  
> @@ -261,12 +273,79 @@ enum omp_clause_code {
>/* OpenMP clause: map ({alloc:,to:,from:,tofrom:,}variable-list).  */
>OMP_CLAUSE_MAP,
>  
> +  /* OpenACC clause: copy (variable_list).  */
> +  OACC_CLAUSE_COPY,
> +
> +  /* OpenACC clause: [data clauses...]

Now, the data clauses.  In my patch series posted at
,
I have chosen the approach to map the OpenACC data clauses all into the
existing OMP_CLAUSE_MAP's map_kind, and extend that as required.  That
seemed the more appropriate approach to me, as it's the very same
functionality.  Also, OMP_CLAUSE_COPYIN semantically is something
different from OACC_CLAUSE_COPYIN.

> +  /* OpenACC clause: host (variable_list).  */
> +  OACC_CLAUSE_HOST,

If we're adding new names for implementing OpenACC things, maybe we
should also name these OMP_*, to keep things simple to read in the code
that uses them.

While they clearly do stem from OpenMP, with a future generalization task
in mind, I understand the OMP_CLAUSE_* (and generally OMP_*) names to no
longer mean something specific to OpenMP (or OpenACC, for that matter),
but instead to define a generic interface to the respective
functionality, that just happens to have OMP_* names due to its OpenMP
legacy.  For myself, I decided to apply this to clauses only, so -- at
least for now -- I have not spent any time on generalizing the OpenACC
and OpenMP directives themselves.  (For example, very roughly, would an
OpenACC parallel directive be something like a (suitably extended) OpenMP
parallel directive inside a OpenMP target region?)  So, I think it's find
to add new tree codes for the OpenACC directives (as you've done), and
any generalization work can be done later, once we have a good
understanding of what the required basic primitives actually are.

Back to the OpenACC ho

Re: [PATCH] Set correct probability for ORDER/UNORDER jumps

[H.J. Lu]

On Fri, Jan 24, 2014 at 10:57 AM, Jakub Jelinek  wrote:
> On Fri, Jan 24, 2014 at 10:20:53AM -0800, Dehao Chen wrote:
>> --- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
>> +++ gcc/testsuite/gcc.dg/predict-8.c (revision 0)
>> @@ -0,0 +1,12 @@
>> +/* { dg-do compile { target { x86_64-*-* } } } */
>
> If you want it for x86_64 64-bit, then
> /* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
>

It should be "! { ia32 }" instead of "lp64" unless it doesn't work
for x32.

-- 
H.J.

Re: [PATCH] _Cilk_for for C and C++

[Jakub Jelinek]

On Thu, Jan 23, 2014 at 04:38:53PM +, Iyer, Balaji V wrote:
>   This is how I started to think of it at first, but then when I thought 
> about it ... in _Cilk_for unlike the #pragma simd's for, the for statement - 
> not the body - (e.g. "_Cilk_for (int ii = 0; ii < 10; ii++") doesn't really 
> do anything nor does it belong in the child function. It is really mostly 
> used to calculate the loop count and capture step-size and starting point.
> 
>   The child function has its own loop that will have a step size of 1 
> regardless of your step size. You use the step-size to find the correct spot. 
> Let me give you an example:
> 
> _Cilk_for (int ii = 0; ii < 10; ii = ii  + 2)
> {
>   Array [ii] = 5;
> }
> 
> This is translated to the following (assume grain is something that the user 
> input):
> 
> data_ptr.start = 0;
> data_ptr.end = 10;
> data_ptr.step_size = 2;
> __cilkrts_cilk_for_32 (child_function, &data_ptr, (10-0)/2, grain);
> 
> Child_function (void *data_ptr, int high, int low)
> {
>   for (xx = low; xx < high; xx++) 
>{
>   Tmp_var = (xx * data_ptr->step_size) + data_ptr->start;
>   // Note: if the _Cilk_for was (ii = 9; ii >= 0; ii -= 2), we 
> would have something like this:
>   // Tmp_var = data_ptr->end - (xx * data_ptr->step_size)
>   // The for-loop above won't change.  
>   Array[Tmp_var] = 5;
>   }
> }

This isn't really much different from
#pragma omp parallel for schedule(runtime, N)
(i.e. the combined construct), when it is combined, we also don't emit a
call to GOMP_parallel but to some other function to which we pass the
number of iterations and chunk size (== grain in Cilk+ terminology), the
only (minor) difference is that for OpenMP when you handle the whole low ...
high range the child function doesn't exit, but calls a function to give it
next pari of low/high and only when that function tells it there is no
further work to do, it returns.  But, the Cilk+ case is clearly the same
thing with just implicit telling there is no further work in the current
function.

So, I'd strongly prefer if you swap the parallel with Cilk_for, just set
the flag that the two are combined like OpenMP already has for tons of
constructs, and during expansion you just treat it together.

Jakub

[patch] fix libstdc++/59548

[Jonathan Wakely]

The debug-mode container base classes need copy constructors that
zero-init their members rather than copy them from the source.

_Safe_unordered_container_base also needs its move constructor to be
non-throwing to fix some FAILs for the PR 55043 tests.

Tested x86_64-linux, normal and debug modes, committed to trunk.
I also want to fix this on the branches once I've finished fixing 4.9
regressions.


2014-01-24  Jonathan Wakely  

PR libstdc++/59548
* include/debug/safe_base.h (_Safe_sequence_base): Define copy
constructor to prevent it being implicitly defined as deleted, but
do not copy anything.
* include/debug/safe_unordered_base.h (_Safe_unordered_container_base):
Define copy and move constructors similar to _Safe_sequence_base's.
* testsuite/23_containers/unordered_map/59548.cc: New.

commit fa570dd6083240e995c0b3306a5ca345adc15373
Author: Jonathan Wakely 
Date:   Fri Jan 24 16:48:01 2014 +

PR libstdc++/59548
* include/debug/safe_base.h (_Safe_sequence_base): Define copy
constructor to prevent it being implicitly defined as deleted, but
do not copy anything.
* include/debug/safe_unordered_base.h (_Safe_unordered_container_base):
Define copy and move constructors similar to _Safe_sequence_base's.
* testsuite/23_containers/unordered_map/59548.cc: New.

diff --git a/libstdc++-v3/include/debug/safe_base.h 
b/libstdc++-v3/include/debug/safe_base.h
index 4b1d082..631ac77 100644
--- a/libstdc++-v3/include/debug/safe_base.h
+++ b/libstdc++-v3/include/debug/safe_base.h
@@ -193,6 +193,9 @@ namespace __gnu_debug
 { }
 
 #if __cplusplus >= 201103L
+_Safe_sequence_base(const _Safe_sequence_base&) noexcept
+  : _Safe_sequence_base() { }
+
 _Safe_sequence_base(_Safe_sequence_base&& __x) noexcept
   : _Safe_sequence_base()
 { _M_swap(__x); }
diff --git a/libstdc++-v3/include/debug/safe_unordered_base.h 
b/libstdc++-v3/include/debug/safe_unordered_base.h
index 9cde781..bbb274f 100644
--- a/libstdc++-v3/include/debug/safe_unordered_base.h
+++ b/libstdc++-v3/include/debug/safe_unordered_base.h
@@ -133,9 +133,19 @@ namespace __gnu_debug
   protected:
 // Initialize with a version number of 1 and no iterators
 _Safe_unordered_container_base()
-: _M_local_iterators(0), _M_const_local_iterators(0)
+: _M_local_iterators(nullptr), _M_const_local_iterators(nullptr)
 { }
 
+// Initialize with a version number of 1 and no iterators
+_Safe_unordered_container_base(const _Safe_unordered_container_base&)
+noexcept
+: _Safe_unordered_container_base() { }
+
+_Safe_unordered_container_base(_Safe_unordered_container_base&& __x)
+noexcept
+: _Safe_unordered_container_base()
+{ this->_M_swap(__x); }
+
 /** Notify all iterators that reference this container that the
container is being destroyed. */
 ~_Safe_unordered_container_base()
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_map/59548.cc 
b/libstdc++-v3/testsuite/23_containers/unordered_map/59548.cc
new file mode 100644
index 000..1e81bb7
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_map/59548.cc
@@ -0,0 +1,34 @@
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+// { dg-require-debug-mode "" }
+
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// libstdc++/59548
+
+#include 
+
+int main()
+{
+  std::unordered_map foo{ {0,1} };
+  auto i = foo.begin();
+  {
+auto bar = foo;
+  }
+  return i->first;
+}

[jit] Support floating-point division; add test-quadratic.c

[David Malcolm]

Committed to branch dmalcolm/jit:

Add testcase test-quadratic.c, written to achieve test coverage of
gcc_jit_rvalue_access_field - with this commit, the test suite has at
least one call to every public symbol in the API.

In the process, I found that GCC_JIT_BINARY_OP_DIVIDE on
floating-point types would lead to a crash when expanding gimple to RTL,
since the use of TRUNC_DIV_EXPR requires integer args.  (Violating this
assumption led to a crash when the division by 2 was turned into a shift,
which the RTL expander assumes is on an integer).

Hence we update GCC_JIT_BINARY_OP_DIVIDE to internally pick either
RDIV_EXPR (floating point division) or TRUNC_DIV_EXPR (truncation towards
zero) based on the result-type of the binary op (my intent being to be
least-surprising to a C programmer).

gcc/jit/
* libgccjit.h (enum gcc_jit_binary_op): We will use the result
type to determine if GCC_JIT_BINARY_OP_DIVIDE should
truncate towards zero, or be floating-point division.

* internal-api.c (gcc::jit::context::new_binary_op): Likewise.

gcc/testsuite/
* jit.dg/test-quadratic.c: New test case, written to achieve test
coverage of gcc_jit_rvalue_access_field, but also exercising
division of doubles.

* jit.dg/test-combination.c: Add test-quadratic.c

* jit.dg/test-expressions.c: Add TODOs.
---
 gcc/jit/ChangeLog.jit   |   8 +
 gcc/jit/internal-api.c  |   8 +-
 gcc/jit/libgccjit.h |  12 +-
 gcc/testsuite/ChangeLog.jit |  10 +
 gcc/testsuite/jit.dg/test-combination.c |   7 +
 gcc/testsuite/jit.dg/test-expressions.c |   3 +
 gcc/testsuite/jit.dg/test-quadratic.c   | 488 
 7 files changed, 532 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-quadratic.c

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index cdf9ddb..f13d0c5 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,13 @@
 2014-01-24  David Malcolm  
 
+   * libgccjit.h (enum gcc_jit_binary_op): We will use the result
+   type to determine if GCC_JIT_BINARY_OP_DIVIDE should
+   truncate towards zero, or be floating-point division.
+
+   * internal-api.c (gcc::jit::context::new_binary_op): Likewise.
+
+2014-01-24  David Malcolm  
+
* internal-api.h (gcc::jit::context::get_str_option): New access
method.
(gcc::jit::context::get_int_option): Likewise.
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 32af625..f95c09f 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -479,9 +479,13 @@ new_binary_op (location *loc,
   break;
 
 case GCC_JIT_BINARY_OP_DIVIDE:
-  inner_op = TRUNC_DIV_EXPR;
+  if (FLOAT_TYPE_P (result_type->as_tree ()))
+   /* Floating-point division: */
+   inner_op = RDIV_EXPR;
+  else
+   /* Truncating to zero: */
+   inner_op = TRUNC_DIV_EXPR;
   break;
-  /* do we want separate floor divide vs frac divide? */
 
 case GCC_JIT_BINARY_OP_MODULO:
   inner_op = TRUNC_MOD_EXPR;
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index baf1541..dd287e8 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -497,9 +497,17 @@ enum gcc_jit_binary_op
 
   /* Quotient of division of arithmetic values; analogous to:
(EXPR_A) / (EXPR_B)
- in C.  */
+ in C.
+ The result type affects the kind of division: if the result type is
+ integer-based, then the result is truncated towards zero, whereas
+ a floating-point result type indicates floating-point division.  */
   GCC_JIT_BINARY_OP_DIVIDE,
-  /* do we want separate floor divide vs frac divide? */
+
+  /* Quotient of division of floating-point values, without rounding;
+ analogous to:
+   (EXPR_A) / (EXPR_B)
+ in C.  */
+  GCC_JIT_BINARY_OP_FLOATING_DIVIDE,
 
   /* Remainder of division of arithmetic values; analogous to:
(EXPR_A) / (EXPR_B)
diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index 5cd4a63..02e73c7 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,5 +1,15 @@
 2014-01-23  David Malcolm  
 
+   * jit.dg/test-quadratic.c: New test case, written to achieve test
+   coverage of gcc_jit_rvalue_access_field, but also exercising
+   division of doubles.
+
+   * jit.dg/test-combination.c: Add test-quadratic.c
+
+   * jit.dg/test-expressions.c: Add TODOs.
+
+2014-01-23  David Malcolm  
+
* jit.dg/test-reading-struct.c: New test, to provide test coverage
of gcc_jit_type_get_const and gcc_jit_lvalue_access_field, in the
process uncovering bugs in how locals were handled.
diff --git a/gcc/testsuite/jit.dg/test-combination.c 
b/gcc/testsuite/jit.dg/test-combination.c
index 6a2372f..562f031 100644
--- a/gcc/testsuite/jit.dg/test-combination.c
+++ b/gcc/testsuite/jit.dg/test-combination.c
@@ -59,6 +59,13 @@
 #undef c

PR libstdc++/59529, 59530,59531 Various string_view bugs.

[Ed Smith-Rowland]

As committed:

Same patch as discussed before all the holidays.

Built and tested x86_64-linux.

2014-01-24  Ed Smith-Rowland  <3dw...@verizon.net>
Peter A. Bigot 

PR libstdc++/59529
* include/experimental/string_view
(basic_string_view(const _CharT*, size_type)): Don't care if len == 0.
* testsuite/experimental/string_view/operations/substr/char/1.cc:
Comment out catch of out_of_range; No terminating null
in basic_string_view.  Check begin == end.
* testsuite/experimental/string_view/operations/substr/wchar_t/1.cc:
Ditto.

2014-01-24  Ed Smith-Rowland  <3dw...@verizon.net>
Peter A. Bigot 

PR libstdc++/59530
* include/experimental/string_view (operator[](size_type) const):
Fix one-off index error in debug check.
* testsuite/experimental/string_view/element_access/char/1.cc: Don't
test basic_string_view at size().
* testsuite/experimental/string_view/element_access/wchar_t/1.cc: Ditto.

2014-01-24  Ed Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/59531
* testsuite/experimental/string_view/operations/copy/char/1.cc: New.
* testsuite/experimental/string_view/operations/copy/wchar_t/1.cc: New.


2014-01-24  Ed Smith-Rowland  <3dw...@verizon.net>
Peter A. Bigot 

PR libstdc++/59531
* include/experimental/string_view
(copy(_CharT*, size_type, size_type) const): Correct throw string.
Correct copy start location.

Index: include/experimental/string_view
===
--- include/experimental/string_view(revision 207027)
+++ include/experimental/string_view(working copy)
@@ -117,7 +117,7 @@
 
   constexpr basic_string_view(const _CharT* __str, size_type __len)
   : _M_len{__str == nullptr ? 0 :__len},
-_M_str{__str == nullptr || __len == 0 ? _S_empty_str : __str}
+_M_str{__str == nullptr ? _S_empty_str : __str}
   { }
 
   basic_string_view&
@@ -277,11 +277,11 @@
   constexpr basic_string_view
   substr(size_type __pos, size_type __n=npos) const
   {
-   return __pos < this->_M_len
+   return __pos <= this->_M_len
 ? basic_string_view{this->_M_str + __pos,
std::min(__n, size_type{this->_M_len  - __pos})}
-: (__throw_out_of_range_fmt(__N("basic_string_view::at: __pos "
-"(which is %zu) >= this->size() "
+: (__throw_out_of_range_fmt(__N("basic_string_view::substr: __pos "
+"(which is %zu) > this->size() "
 "(which is %zu)"),
 __pos, this->size()), basic_string_view{});
   }
Index: testsuite/experimental/string_view/operations/substr/char/1.cc
===
--- testsuite/experimental/string_view/operations/substr/char/1.cc  
(revision 207027)
+++ testsuite/experimental/string_view/operations/substr/char/1.cc  
(working copy)
@@ -63,11 +63,9 @@
   {
 str02 = str01.substr(csz01);
 VERIFY( str02.size() == 0 );
+VERIFY( str02.begin() == str01.end() );
+VERIFY( true );
   }
-  catch(std::out_of_range& fail)
-  {
-VERIFY( true ); // No terminating null in basic_string_view
-  }
   catch(...)
   {
 VERIFY( false );
Index: testsuite/experimental/string_view/operations/substr/wchar_t/1.cc
===
--- testsuite/experimental/string_view/operations/substr/wchar_t/1.cc   
(revision 207027)
+++ testsuite/experimental/string_view/operations/substr/wchar_t/1.cc   
(working copy)
@@ -63,11 +63,9 @@
   {
 str02 = str01.substr(csz01);
 VERIFY( str02.size() == 0 );
+VERIFY( str02.begin() == str01.end() );
+VERIFY( true );
   }
-  catch(std::out_of_range& fail)
-  {
-VERIFY( true ); // No terminating null in basic_string_view
-  }
   catch(...)
   {
 VERIFY( false );
Index: include/experimental/string_view
===
--- include/experimental/string_view(revision 207027)
+++ include/experimental/string_view(working copy)
@@ -182,7 +182,7 @@
   operator[](size_type __pos) const
   {
// TODO: Assert to restore in a way compatible with the constexpr.
-   // _GLIBCXX_DEBUG_ASSERT(__pos <= this->_M_len);
+   // _GLIBCXX_DEBUG_ASSERT(__pos < this->_M_len);
return *(this->_M_str + __pos);
   }
 
Index: testsuite/experimental/string_view/element_access/char/1.cc
===
--- testsuite/experimental/string_view/element_access/char/1.cc (revision 
207027)
+++ testsuite/experimental/string_view/element_access/char/1.cc (working copy)
@@ -41,8 +41,9 @@
   csz01 = str01.size(

Re: [RFA][PATCH] Fix tree-optimization/59919

[Jeff Law]

On 01/24/14 03:52, Jakub Jelinek wrote:


I'd say this belongs into infer_value_range instead.

Here we go with that variant:

OK for the trunk?

jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 2998c72..3b1abbc 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2014-01-23  Jeff Law  
+
+   PR tree-optimization/59919
+   * tree-vrp.c (find_assert_locations_1): Do not register asserts
+   for non-returning calls.
+
 2014-01-23  Pat Haugen  
 
* config/rs6000/rs6000.c (rs6000_option_override_internal): Don't
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 564d425..0d05178 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2014-01-23  Jeff Law  
+
+   PR tree-optimization/59919
+   * gcc.c-torture/compile/pr59919.c: New test.
+
 2014-01-23  Paolo Carlini  
 
PR c++/58980
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr59919.c 
b/gcc/testsuite/gcc.c-torture/compile/pr59919.c
new file mode 100644
index 000..6809caa
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr59919.c
@@ -0,0 +1,18 @@
+typedef int jmp_buf[10];
+struct S
+{
+  int i;
+  jmp_buf buf;
+};
+
+void setjmp (jmp_buf);
+void foo (int *);
+__attribute__ ((__noreturn__, __nonnull__)) void bar (struct S *);
+
+void
+baz (struct S *p)
+{
+  bar (p);
+  setjmp (p->buf);
+  foo (&p->i);
+}
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index f6da192..7aa732d 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4534,12 +4534,21 @@ infer_value_range (gimple stmt, tree op, enum tree_code 
*comp_code_p, tree *val_
   if (stmt_could_throw_p (stmt))
 return false;
 
-  /* If STMT is the last statement of a basic block with no
+  /* If STMT is the last statement of a basic block with no normal
  successors, there is no point inferring anything about any of its
  operands.  We would not be able to find a proper insertion point
  for the assertion, anyway.  */
-  if (stmt_ends_bb_p (stmt) && EDGE_COUNT (gimple_bb (stmt)->succs) == 0)
-return false;
+  if (stmt_ends_bb_p (stmt))
+{
+  edge_iterator ei;
+  edge e;
+
+  FOR_EACH_EDGE (e, ei, gimple_bb (stmt)->succs)
+   if (!(e->flags & EDGE_ABNORMAL))
+ break;
+  if (e == NULL)
+   return false;
+}
 
   if (infer_nonnull_range (stmt, op, true, true))
 {

Re: PR libstdc++/59529, 59530,59531 Various string_view bugs.

[Paolo Carlini]

Ed Smith-Rowland <3dw...@verizon.net> ha scritto:
>As committed:
>
>Same patch as discussed before all the holidays.
>
>Built and tested x86_64-linux.

Thanks. Please remember to also close the bugs.

Paolo.

Re: [RFA][PATCH] Fix tree-optimization/59919

[Jakub Jelinek]

On Fri, Jan 24, 2014 at 01:22:17PM -0700, Jeff Law wrote:
> On 01/24/14 03:52, Jakub Jelinek wrote:
> >
> >I'd say this belongs into infer_value_range instead.
> Here we go with that variant:
> 
> OK for the trunk?

Yes, thanks.
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,9 @@
> +2014-01-23  Jeff Law  
> +
> + PR tree-optimization/59919
> + * tree-vrp.c (find_assert_locations_1): Do not register asserts
> + for non-returning calls.
> +
>  2014-01-23  Pat Haugen  
>  
>   * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 564d425..0d05178 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2014-01-23  Jeff Law  
> +
> + PR tree-optimization/59919
> + * gcc.c-torture/compile/pr59919.c: New test.
> +
>  2014-01-23  Paolo Carlini  
>  
>   PR c++/58980

Jakub

Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Thomas Schwinge]

Hi!

Regarding my comments, please keep in mind that I don't have a lot of
Fortran experience; neither as a user nor as an implementor ;-) in the
GCC front end, so don't hesitate to tell me if I'm misunderstanding
something.  As I suggested, it may make sense to CC Fortran front end
maintainers for such patches.


When I say "again" in the following, that refers to things I
asked/suggested in »[PATCH 4/6] OpenACC GENERIC nodes«.

On Thu, 23 Jan 2014 22:03:09 +0400, Ilmir Usmanov  wrote:
> Subject: [PATCH 1/6] OpenACC fortran FE part 1

> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
> @@ -1230,6 +1230,194 @@ show_omp_node (int level, gfc_code *c)
>  fprintf (dumpfile, " (%s)", c->ext.omp_name);
>  }
>  
> +/* Show a single OpenACC directive node and everything underneath it
> +   if necessary.  */
> +
> +static void
> +show_oacc_node (int level, gfc_code *c)

Is this something that accurately needs to reproduce valid Fortran code?
Or, could we again re-use more of the existing OpenMP code, and get
nearly-valid Fortran, that differs in how some of the data clauses are
displayed, for example?

> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h

> @@ -1025,16 +1031,29 @@ gfc_namelist;

>  enum
>  {
>OMP_LIST_PRIVATE,
> +  OACC_LIST_PRIVATE = OMP_LIST_PRIVATE,
>OMP_LIST_FIRSTPRIVATE,
> +  OACC_LIST_FIRSTPRIVATE = OMP_LIST_FIRSTPRIVATE,

Again, possible to simply re-use the existing OMP_* ones?

> @@ -1047,7 +1066,29 @@ enum
>OMP_LIST_IOR,
>OMP_LIST_IEOR,
>OMP_LIST_REDUCTION_LAST = OMP_LIST_IEOR,
> -  OMP_LIST_NUM
> +  OACC_LIST_REDUCTION_LAST = OMP_LIST_REDUCTION_LAST,
> +  OMP_LIST_NUM,
> +
> +  OACC_LIST_COPY = OMP_LIST_NUM,
> +  OACC_LIST_FIRST = OACC_LIST_COPY,
> +  OACC_LIST_DATA_CLAUSE_FIRST = OACC_LIST_COPY,
> +  OACC_LIST_COPYIN,
> +  OACC_LIST_COPYOUT,
> +  OACC_LIST_CREATE,
> +  OACC_LIST_DELETE,
> +  OACC_LIST_PRESENT,
> +  OACC_LIST_PRESENT_OR_COPY,
> +  OACC_LIST_PRESENT_OR_COPYIN,
> +  OACC_LIST_PRESENT_OR_COPYOUT,
> +  OACC_LIST_PRESENT_OR_CREATE,
> +  OACC_LIST_DEVICEPTR,
> +  OACC_LIST_DATA_CLAUSE_LAST = OACC_LIST_DEVICEPTR,
> +  OACC_LIST_USE_DEVICE,
> +  OACC_LIST_DEVICE_RESIDENT,
> +  OACC_LIST_HOST,
> +  OACC_LIST_DEVICE,
> +  OACC_LIST_CACHE,
> +  OACC_LIST_NUM
>  };

Again, for conformity, maybe stick with OMP_LIST_* names
(OMP_LIST_OACC_*?).

Do we still need the OMP_LIST_NUM value if we now got OACC_LIST_NUM to
mark the number of items, and should the latter one in fact be named
OMP_LIST_NUM then?)

Again, can we re-use the existing infrastructure for OpenMP's memory
mapping instead of adding OACC_LIST_COPY* (and similar) here?

> @@ -1077,17 +1118,42 @@ typedef struct gfc_omp_clauses

> +  /* OpenACC. */
> +  bool is_acc;

Can we avoid the is_acc member and instead make it clear from the context
whether this is OpenACC or OpenMP?  (Just an idea.)

> +  [...]
>  }
>  gfc_omp_clauses;
>  
>  #define gfc_get_omp_clauses() XCNEW (gfc_omp_clauses)
>  
> +typedef gfc_omp_clauses gfc_oacc_clauses;

Again, I'd just use the existing gfc_omp_* name.

> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c

> @@ -3643,6 +3875,113 @@ parse_omp_atomic (void)
>  }
>  
>  
> +/* Parse the statements of an OpenACC structured block.  */
> +
> +static void
> +parse_oacc_structured_block (gfc_statement acc_st)
> +{
> +[...]

> --- a/gcc/fortran/parse.h
> +++ b/gcc/fortran/parse.h
> @@ -29,7 +29,8 @@ typedef enum
>COMP_BLOCK_DATA, COMP_INTERFACE, COMP_DERIVED, COMP_DERIVED_CONTAINS,
>COMP_BLOCK, COMP_ASSOCIATE, COMP_IF,
>COMP_DO, COMP_SELECT, COMP_FORALL, COMP_WHERE, COMP_CONTAINS, COMP_ENUM,
> -  COMP_SELECT_TYPE, COMP_OMP_STRUCTURED_BLOCK, COMP_CRITICAL, 
> COMP_DO_CONCURRENT
> +  COMP_SELECT_TYPE, COMP_OMP_STRUCTURED_BLOCK, COMP_CRITICAL, 
> COMP_DO_CONCURRENT,
> +  COMP_OACC_STRUCTURED_BLOCK
>  }
>  gfc_compile_state;

In Fortran, how is an OpenACC structured block different from an OpenMP
one?  In C they aren't; see the third patch in
,
for the C front end/middle end, which is pending approval.  Or is this
something else in the Fortran front end?


Grüße,
 Thomas


pgpCcAPrVfrQA.pgp
Description: PGP signature

RE: [PATCH] _Cilk_for for C and C++

[Iyer, Balaji V]

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Friday, January 24, 2014 2:42 PM
> To: Iyer, Balaji V
> Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: Re: [PATCH] _Cilk_for for C and C++
> 
> On Thu, Jan 23, 2014 at 04:38:53PM +, Iyer, Balaji V wrote:
> > This is how I started to think of it at first, but then when I thought
> about it ... in _Cilk_for unlike the #pragma simd's for, the for statement - 
> not
> the body - (e.g. "_Cilk_for (int ii = 0; ii < 10; ii++") doesn't really do 
> anything
> nor does it belong in the child function. It is really mostly used to 
> calculate the
> loop count and capture step-size and starting point.
> >
> > The child function has its own loop that will have a step size of 1
> regardless of your step size. You use the step-size to find the correct spot.
> Let me give you an example:
> >
> > _Cilk_for (int ii = 0; ii < 10; ii = ii  + 2) {
> > Array [ii] = 5;
> > }
> >
> > This is translated to the following (assume grain is something that the user
> input):
> >
> > data_ptr.start = 0;
> > data_ptr.end = 10;
> > data_ptr.step_size = 2;
> > __cilkrts_cilk_for_32 (child_function, &data_ptr, (10-0)/2, grain);
> >
> > Child_function (void *data_ptr, int high, int low) {
> > for (xx = low; xx < high; xx++)
> >  {
> > Tmp_var = (xx * data_ptr->step_size) + data_ptr->start;
> > // Note: if the _Cilk_for was (ii = 9; ii >= 0; ii -= 2), we 
> > would
> have something like this:
> > // Tmp_var = data_ptr->end - (xx * data_ptr->step_size)
> > // The for-loop above won't change.
> > Array[Tmp_var] = 5;
> > }
> > }
> 
> This isn't really much different from
> #pragma omp parallel for schedule(runtime, N) (i.e. the combined
> construct), when it is combined, we also don't emit a call to GOMP_parallel
> but to some other function to which we pass the number of iterations and
> chunk size (== grain in Cilk+ terminology), the only (minor) difference is 
> that
> for OpenMP when you handle the whole low ...
> high range the child function doesn't exit, but calls a function to give it 
> next
> pari of low/high and only when that function tells it there is no further work
> to do, it returns.  But, the Cilk+ case is clearly the same thing with just 
> implicit
> telling there is no further work in the current function.
> 
> So, I'd strongly prefer if you swap the parallel with Cilk_for, just set the 
> flag
> that the two are combined like OpenMP already has for tons of constructs,
> and during expansion you just treat it together.

Hi Jakub,
What you are suggesting here would require a significant rewrite of the 
code. This version of _Cilk_for works and it does share significant amount of 
work with OMP routines as requested by other GCC developers. Given the time 
constraints, let's try to get this version accepted so that the feature will be 
available for the users and we will look into moving toward your suggestion 
when the phase 1 opens again.

Thanks,

Balaji V. Iyer.


> 
>   Jakub

Re: Handle XOR in canonicalize_condition

[Jeff Law]

On 01/24/14 01:24, Richard Sandiford wrote:

Richard Sandiford  writes:

The other problem is related to the way that MIPS16 tests for equality.
Conditional branches test register $24, and the only instructions that
set $24 are MOVE and CMP(I), which is actually an XOR rather than a
subtraction.


Er, don't know what I was thinking here, but please ignore this summary
of the ISA.  There are conditional branches to test MIPS16 registers
and other ways of setting $24.  (But other than that...)

The patch itself still stands though.
Right.  This is just the RTL version of what I did for trees about a 
year ago.


The comment is a bit misleading as far as pulling things out of the RTL. 
 You're showing it a combined form.  SET is something like

(set (reg) (xor (reg) (reg))) if I'm reading everything correctly.

Please try to improve the comment and you're good to go.  No need to 
wait for further review, but please post the final form for the archivers.


Thanks,
Jeff

Re: [PATCH 2/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Thomas Schwinge]

Hi!

Regarding my comments, please keep in mind that I don't have a lot of
Fortran experience; neither as a user nor as an implementor ;-) in the
GCC front end, so don't hesitate to tell me if I'm misunderstanding
something.  As I suggested, it may make sense to CC Fortran front end
maintainers for such patches.


On Thu, 23 Jan 2014 22:03:42 +0400, Ilmir Usmanov  wrote:
> Subject: [PATCH 2/6] OpenACC fortran FE part 2

> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c

> @@ -186,15 +292,51 @@ cleanup:
>  #define OMP_CLAUSE_FINAL (1 << 14)
>  #define OMP_CLAUSE_MERGEABLE (1 << 15)
>  
> +/* OpenACC 2.0 clauses. */
> +#define OACC_CLAUSE_IF   OMP_CLAUSE_IF
> +#define OACC_CLAUSE_ASYNC(1 << 16)
> +#define OACC_CLAUSE_NUM_GANGS(1 << 17)
> +#define OACC_CLAUSE_NUM_WORKERS  (1 << 18)
> +#define OACC_CLAUSE_VECTOR_LENGTH(1 << 19)
> +#define OACC_CLAUSE_REDUCTIONOMP_CLAUSE_REDUCTION
> +#define OACC_CLAUSE_COPY (1 << 20)
> +#define OACC_CLAUSE_COPYIN   OMP_CLAUSE_COPYIN
> +#define OACC_CLAUSE_COPYOUT  (1 << 21)
> +#define OACC_CLAUSE_[...]

As asked/suggested in »[PATCH 4/6] OpenACC GENERIC nodes«, can we again
avoid the duplicate names, and use the existing OpenMP memory mapping
stuff for expressing the OpenACC data clauses?

>  /* Match OpenMP directive clauses. MASK is a bitmask of
> clauses that are allowed for a particular directive.  */
>  
>  static match
> -gfc_match_omp_clauses (gfc_omp_clauses **cp, int mask)
> +gfc_match_omp_clauses (gfc_omp_clauses **cp, long long mask, bool is_acc)

Here, in turn, in the C front end,

(and following), I went with a separate function for OpenACC vs. OpenMP
clauses parsing, specifically to avoid the is_acc disambiguation
variable.

That is, I parse the OACC_CLAUSE_* in context of either an OpenACC or
OpenMP directive, and as such it's implicitly clear whether this is an
OpenACC or OpenMP one.

That's the reason why I can have PRAGMA_OMP_CLAUSE_COPYIN mean different
things for OpenACC vs. OpenMP in the C front end.  Maybe such an approach
would work well in the Fortran front end, too?


Grüße,
 Thomas


pgp7OLcIEFPyu.pgp
Description: PGP signature

Re: Disable accumulate-outgoing-args for Generic and Buldozers

[Jakub Jelinek]

On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
>   * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
>   for generic and recent AMD chips
> Index: config/i386/x86-tune.def
> ===
> --- config/i386/x86-tune.def  (revision 206233)
> +++ config/i386/x86-tune.def  (working copy)
> @@ -143,7 +143,7 @@ DEF_TUNE (X86_TUNE_REASSOC_FP_TO_PARALLE
> regression on mgrid due to IRA limitation leading to unecessary
> use of the frame pointer in 32bit mode.  */
>  DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, "accumulate_outgoing_args",
> -   m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_AMD_MULTIPLE | 
> m_GENERIC)
> +   m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_ATHLON_K8)
>  
>  /* X86_TUNE_PROLOGUE_USING_MOVE: Do not use push/pop in prologues that are
> considered on critical path.  */

Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
have separate tunables for 32-bit and 64-bit code)?
I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing
x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking,
but am quite surprised that compared to 3 days ago the bootstrap time of
i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 minutes 
today,
while the x86_64-linux (all,obj-c++,go,ada) remained basically the same
around 2 hours.  This is on quad socket Quad-Core AMD Opteron(tm) Processor 
8354,
perhaps it is just extremely undesirable there.

Jakub

[PATCH] Don't warn with -Waggressive-loop-optimizations multiple times about the same loop (PR middle-end/59561)

[Jakub Jelinek]

Hi!

When a loop is duplicated, inlined etc. and we've already warned
about undefined behavior in it, it is undesirable to warn again.

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

2014-01-22  Jakub Jelinek  

PR middle-end/59561
* cfgloopmanip.c (copy_loop_info): If
loop->warned_aggressive_loop_optimizations, make sure
the flag is set in target loop too.

--- gcc/cfgloopmanip.c.jj   2014-01-03 11:40:33.0 +0100
+++ gcc/cfgloopmanip.c  2014-01-22 10:21:54.057871045 +0100
@@ -1022,6 +1022,8 @@ copy_loop_info (struct loop *loop, struc
   target->any_estimate = loop->any_estimate;
   target->nb_iterations_estimate = loop->nb_iterations_estimate;
   target->estimate_state = loop->estimate_state;
+  target->warned_aggressive_loop_optimizations
+|= loop->warned_aggressive_loop_optimizations;
 }
 
 /* Copies copy of LOOP as subloop of TARGET loop, placing newly

Jakub

[PATCH] Don't ignore write/write DDR_REVERSED_P dependencies (PR tree-optimization/59594)

[Jakub Jelinek]

Hi!

I admit I fully don't understand why exactly, but my experimentation so far
showed that for read/write and write/read ddrs it is ok and desirable to
ignore the dist > 0 && DDR_REVERSED_P (ddr) cases, but for write/write
ddrs it is undesirable.  See the PR for further tests, perhaps I could
turn them into further testcases.

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

2014-01-22  Jakub Jelinek  

PR tree-optimization/59594
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Don't
ignore dist > 0 && DDR_REVERSED_P (ddr) if step is negative and both
DRs are writes.

* gcc.dg/vect/no-vfa-vect-depend-2.c: New test.
* gcc.dg/vect/pr59594.c: New test.

--- gcc/tree-vect-data-refs.c.jj2014-01-16 20:54:59.0 +0100
+++ gcc/tree-vect-data-refs.c   2014-01-22 13:13:49.751362484 +0100
@@ -383,11 +383,13 @@ vect_analyze_data_ref_dependence (struct
  continue;
}
 
-  if (dist > 0 && DDR_REVERSED_P (ddr))
+  if (dist > 0 && DDR_REVERSED_P (ddr)
+ && (DR_IS_READ (dra) || DR_IS_READ (drb)))
{
  /* If DDR_REVERSED_P the order of the data-refs in DDR was
 reversed (to make distance vector positive), and the actual
-distance is negative.  */
+distance is negative.  If both DRs are writes, we can't ignore
+the DDR.  See PR59594.  */
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "dependence distance negative.\n");
--- gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-2.c.jj 2014-01-22 
13:28:47.100724091 +0100
+++ gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-2.c2014-01-22 
13:41:38.736778586 +0100
@@ -0,0 +1,55 @@
+/* { dg-require-effective-target vect_int } */
+
+#include 
+#include "tree-vect.h"
+
+#define N 17
+
+int ia[N] = {48,45,42,39,36,33,30,27,24,21,18,15,12,9,6,3,0};
+int ib[N] = {48,45,42,39,36,33,30,27,24,21,18,15,12,9,6,3,0};
+int res[N] = {48,192,180,168,156,144,132,120,108,96,84,72,60,48,36,24,12};
+
+__attribute__ ((noinline))
+int main1 ()
+{
+  int i;
+
+  /* Not vectorizable due to data dependence: dependence distance 1.  */ 
+  for (i = N - 1; i >= 0; i--)
+{
+  ia[i] = ia[i+1] * 4;
+}
+
+  /* check results:  */
+  for (i = 0; i < N; i++)
+{
+  if (ia[i] != 0)
+abort ();
+} 
+
+  /* Vectorizable. Dependence distance -1.  */
+  for (i = N - 1; i >= 0; i--)
+{
+  ib[i+1] = ib[i] * 4;
+}
+
+  /* check results:  */
+  for (i = 0; i < N; i++)
+{
+  if (ib[i] != res[i])
+abort ();
+}
+
+  return 0;
+}
+
+int main (void)
+{
+  check_vect();
+
+  return main1 ();
+}
+
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" {xfail 
vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times "dependence distance negative" 1 "vect"  
} } */
+/* { dg-final { cleanup-tree-dump "vect" } } */
--- gcc/testsuite/gcc.dg/vect/pr59594.c.jj  2014-01-22 13:39:51.362322166 
+0100
+++ gcc/testsuite/gcc.dg/vect/pr59594.c 2014-01-22 13:39:43.0 +0100
@@ -0,0 +1,31 @@
+/* PR tree-optimization/59594 */
+
+#include "tree-vect.h"
+
+#define N 1024
+int b[N + 1];
+
+int
+main ()
+{
+  int i;
+  check_vect ();
+  for (i = 0; i < N + 1; i++)
+{
+  b[i] = i;
+  asm ("");
+}
+  for (i = N; i >= 0; i--)
+{
+  b[i + 1] = b[i];
+  b[i] = 1;
+}
+  if (b[0] != 1)
+__builtin_abort ();
+  for (i = 0; i < N; i++)
+if (b[i + 1] != i)
+  __builtin_abort ();
+  return 0;
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */

Jakub

[PATCH] Improve dumping CALL_INSN_FUNCTION_USAGE

[Jakub Jelinek]

Hi!

This is something that has annyoed me for quite some time, but never got
around to do anything about it.  The EXPR_LIST mode in
CALL_INSN_FUNCTION_USAGE never means the various REG_DEAD/REG_CFA* etc.
note names, always normal mode, so e.g. when one is looking for REG_CFA*
notes, the calls can confuse it, and when looking at calls, one has to
look up the REG_* values and convert them to enum machine_mode in the
debugger.

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

2014-01-22  Jakub Jelinek  

* print-rtl.c (in_call_function_usage): New var.
(print_rtx): When in CALL_INSN_FUNCTION_USAGE, always print
EXPR_LIST mode as mode and not as reg note name.

--- gcc/print-rtl.c.jj  2014-01-03 11:40:57.0 +0100
+++ gcc/print-rtl.c 2014-01-22 18:50:59.094605279 +0100
@@ -51,6 +51,8 @@ static int sawclose = 0;
 
 static int indent;
 
+static bool in_call_function_usage;
+
 static void print_rtx (const_rtx);
 
 /* String printed at beginning of each RTL when it is dumped.
@@ -153,7 +155,8 @@ print_rtx (const_rtx in_rtx)
   if ((GET_CODE (in_rtx) == EXPR_LIST
   || GET_CODE (in_rtx) == INSN_LIST
   || GET_CODE (in_rtx) == INT_LIST)
- && (int)GET_MODE (in_rtx) < REG_NOTE_MAX)
+ && (int)GET_MODE (in_rtx) < REG_NOTE_MAX
+ && !in_call_function_usage)
fprintf (outfile, ":%s",
 GET_REG_NOTE_NAME (GET_MODE (in_rtx)));
 
@@ -350,7 +353,14 @@ print_rtx (const_rtx in_rtx)
   print_rtx_head, indent * 2, "");
if (!sawclose)
  fprintf (outfile, " ");
-   print_rtx (XEXP (in_rtx, i));
+   if (i == 8 && CALL_P (in_rtx))
+ {
+   in_call_function_usage = true;
+   print_rtx (XEXP (in_rtx, i));
+   in_call_function_usage = false;
+ }
+   else
+ print_rtx (XEXP (in_rtx, i));
indent -= 2;
break;
 

Jakub

Re: [PATCH] Set correct probability for ORDER/UNORDER jumps

[Dehao Chen]

Thanks, test updated:

Index: gcc/testsuite/gcc.dg/predict-8.c
===
--- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
+++ gcc/testsuite/gcc.dg/predict-8.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options "-O2 -fdump-rtl-expand" } */
+
+int foo(float a, float b) {
+  if (a == b)
+return 1;
+  else
+return 2;
+}
+
+/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 100" 1 "expand"} } */
+/* { dg-final { cleanup-rtl-dump "expand" } } */

On Fri, Jan 24, 2014 at 11:38 AM, H.J. Lu  wrote:
> On Fri, Jan 24, 2014 at 10:57 AM, Jakub Jelinek  wrote:
>> On Fri, Jan 24, 2014 at 10:20:53AM -0800, Dehao Chen wrote:
>>> --- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
>>> +++ gcc/testsuite/gcc.dg/predict-8.c (revision 0)
>>> @@ -0,0 +1,12 @@
>>> +/* { dg-do compile { target { x86_64-*-* } } } */
>>
>> If you want it for x86_64 64-bit, then
>> /* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
>>
>
> It should be "! { ia32 }" instead of "lp64" unless it doesn't work
> for x32.
>
> --
> H.J.

Re: [PATCH] Improve dumping CALL_INSN_FUNCTION_USAGE

[Eric Botcazou]

> This is something that has annyoed me for quite some time, but never got
> around to do anything about it.  The EXPR_LIST mode in
> CALL_INSN_FUNCTION_USAGE never means the various REG_DEAD/REG_CFA* etc.
> note names, always normal mode, so e.g. when one is looking for REG_CFA*
> notes, the calls can confuse it, and when looking at calls, one has to
> look up the REG_* values and convert them to enum machine_mode in the
> debugger.

You're not alone here. :-)
 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2014-01-22  Jakub Jelinek  
> 
>   * print-rtl.c (in_call_function_usage): New var.
>   (print_rtx): When in CALL_INSN_FUNCTION_USAGE, always print
>   EXPR_LIST mode as mode and not as reg note name.

OK, thanks for fixing this.

-- 
Eric Botcazou

Re: Disable accumulate-outgoing-args for Generic and Buldozers

[Jan Hubicka]

> On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
> > for generic and recent AMD chips
> > Index: config/i386/x86-tune.def
> > ===
> > --- config/i386/x86-tune.def(revision 206233)
> > +++ config/i386/x86-tune.def(working copy)
> > @@ -143,7 +143,7 @@ DEF_TUNE (X86_TUNE_REASSOC_FP_TO_PARALLE
> > regression on mgrid due to IRA limitation leading to unecessary
> > use of the frame pointer in 32bit mode.  */
> >  DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, "accumulate_outgoing_args",
> > - m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_AMD_MULTIPLE | 
> > m_GENERIC)
> > + m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_ATHLON_K8)
> >  
> >  /* X86_TUNE_PROLOGUE_USING_MOVE: Do not use push/pop in prologues that are
> > considered on critical path.  */
> 
> Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
> have separate tunables for 32-bit and 64-bit code)?
> I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing
> x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking,
> but am quite surprised that compared to 3 days ago the bootstrap time of
> i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 
> minutes today,
> while the x86_64-linux (all,obj-c++,go,ada) remained basically the same
> around 2 hours.  This is on quad socket Quad-Core AMD Opteron(tm) Processor 
> 8354,
> perhaps it is just extremely undesirable there.

I ran SPEC benchmarks and compile times on those + code size. I tested only
64bit cross.

I did see minor slowdown, but definitely not of the degree you observe.  My
main concern was overall binary size increase with EH tables enabled as
described in the original mail. Given that accumulation was already disabled
for cores that now has about the same characteristic as AMD chips (both has
stack engine) it seemed we should go both ways on one target and other.  It
also seemed that 4% actual text segment reduction is very nice.

Perhaps we degenerate on some testcase or we get a lot slower on -O0 codegen?
We may just enable accumulation by default -O0 since it results in faster
compile times.

Also perhaps it is debug info output problem, since my SPEC was without -g.

I use now AMD Opteron(TM) Processor 6272 that should behave pretty much same.
I will try to get some data.

Honza

Go patch committed: Use backend interface for unary expressions

[Ian Lance Taylor]

This patch from Chris Manghane changes the Go frontend to use the
backend interface for unary expressions.  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2014-01-24  Chris Manghane  

* go-gcc.cc (Gcc_backend::unary_expression): New function.


Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc	(revision 206904)
+++ gcc/go/gofrontend/expressions.cc	(working copy)
@@ -1464,6 +1464,10 @@ class Func_code_reference_expression : p
   do_traverse(Traverse*)
   { return TRAVERSE_CONTINUE; }
 
+  bool
+  do_is_immutable() const
+  { return true; }
+
   Type*
   do_type()
   { return Type::make_pointer_type(Type::make_void_type()); }
@@ -2941,6 +2945,10 @@ class Nil_expression : public Expression
   do_is_constant() const
   { return true; }
 
+  bool
+  do_is_immutable() const
+  { return true; }
+
   Type*
   do_type()
   { return Type::make_nil_type(); }
@@ -3682,10 +3690,17 @@ class Unary_expression : public Expressi
   Expression*
   do_lower(Gogo*, Named_object*, Statement_inserter*, int);
 
+  Expression*
+  do_flatten(Gogo*, Named_object*, Statement_inserter*);
+
   bool
   do_is_constant() const;
 
   bool
+  do_is_immutable() const
+  { return this->expr_->is_immutable(); }
+
+  bool
   do_numeric_constant_value(Numeric_constant*) const;
 
   Type*
@@ -3806,6 +3821,45 @@ Unary_expression::do_lower(Gogo*, Named_
   return this;
 }
 
+// Flatten expression if a nil check must be performed and create temporary
+// variables if necessary.
+
+Expression*
+Unary_expression::do_flatten(Gogo* gogo, Named_object*,
+ Statement_inserter* inserter)
+{
+  Location location = this->location();
+  if (this->op_ == OPERATOR_MULT
+  && !this->expr_->is_variable())
+{
+  go_assert(this->expr_->type()->points_to() != NULL);
+  Type* ptype = this->expr_->type()->points_to();
+  if (!ptype->is_void_type())
+{
+  Btype* pbtype = ptype->get_backend(gogo);
+  size_t s = gogo->backend()->type_size(pbtype);
+  if (s >= 4096 || this->issue_nil_check_)
+{
+  Temporary_statement* temp =
+  Statement::make_temporary(NULL, this->expr_, location);
+  inserter->insert(temp);
+  this->expr_ =
+  Expression::make_temporary_reference(temp, location);
+}
+}
+}
+
+  if (this->create_temp_ && !this->expr_->is_variable())
+{
+  Temporary_statement* temp =
+  Statement::make_temporary(NULL, this->expr_, location);
+  inserter->insert(temp);
+  this->expr_ = Expression::make_temporary_reference(temp, location);
+}
+
+  return this;
+}
+
 // Return whether a unary expression is a constant.
 
 bool
@@ -3821,8 +3875,8 @@ Unary_expression::do_is_constant() const
   else if (this->op_ == OPERATOR_AND)
 {
   // Taking the address of a variable is constant if it is a
-  // global variable, not constant otherwise.  In other cases
-  // taking the address is probably not a constant.
+  // global variable, not constant otherwise.  In other cases taking the
+  // address is probably not a constant.
   Var_expression* ve = this->expr_->var_expression();
   if (ve != NULL)
 	{
@@ -4151,58 +4205,40 @@ Unary_expression::do_get_tree(Translate_
 	{
 	  Temporary_statement* temp = sut->temporary();
 	  Bvariable* bvar = temp->get_backend_variable(context);
-	  tree var_tree = var_to_tree(bvar);
-	  Expression* val = sut->expression();
-	  tree val_tree = val->get_tree(context);
-	  if (var_tree == error_mark_node || val_tree == error_mark_node)
-	return error_mark_node;
-	  tree addr_tree = build_fold_addr_expr_loc(loc.gcc_location(),
-		var_tree);
-	  return build2_loc(loc.gcc_location(), COMPOUND_EXPR,
-			TREE_TYPE(addr_tree),
-			build2_loc(sut->location().gcc_location(),
-   MODIFY_EXPR, void_type_node,
-   var_tree, val_tree),
-			addr_tree);
+  Bexpression* bvar_expr = gogo->backend()->var_expression(bvar, loc);
+
+  Expression* val = sut->expression();
+  Bexpression* bval = tree_to_expr(val->get_tree(context));
+
+  Bstatement* bassign =
+  gogo->backend()->assignment_statement(bvar_expr, bval, loc);
+  Bexpression* bvar_addr =
+  gogo->backend()->address_expression(bvar_expr, loc);
+  Bexpression* ret =
+  gogo->backend()->compound_expression(bassign, bvar_addr, loc);
+  return expr_to_tree(ret);
 	}
 }
 
+  Bexpression* ret;
   tree expr = this->expr_->get_tree(context);
-  if (expr == error_mark_node)
-return error_mark_node;
-
+  Bexpression* bexpr = tree_to_expr(expr);
+  Btype* btype = this->expr_->type()->get_backend(gogo);
   switch (this->op_)
 {
 case OPERATOR_PLUS:
-  return expr;
+  ret = bexpr;
+  b

Re: [PATCH] Don't warn with -Waggressive-loop-optimizations multiple times about the same loop (PR middle-end/59561)

[Jeff Law]

On 01/24/14 14:14, Jakub Jelinek wrote:

Hi!

When a loop is duplicated, inlined etc. and we've already warned
about undefined behavior in it, it is undesirable to warn again.

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

2014-01-22  Jakub Jelinek  

PR middle-end/59561
* cfgloopmanip.c (copy_loop_info): If
loop->warned_aggressive_loop_optimizations, make sure
the flag is set in target loop too.

--- gcc/cfgloopmanip.c.jj   2014-01-03 11:40:33.0 +0100
+++ gcc/cfgloopmanip.c  2014-01-22 10:21:54.057871045 +0100
@@ -1022,6 +1022,8 @@ copy_loop_info (struct loop *loop, struc
target->any_estimate = loop->any_estimate;
target->nb_iterations_estimate = loop->nb_iterations_estimate;
target->estimate_state = loop->estimate_state;
+  target->warned_aggressive_loop_optimizations
+|= loop->warned_aggressive_loop_optimizations;

OK.

jeff

[PATCH, committed] Replace flag_enable_cilkplus with flag_cilkplus

[Iyer, Balaji V]

Hello Jakub and Aldy,
As you both requested, this patch will replace flag_enable_cilkplus 
with flag_cilkplus. I have committed this patch since the change is a 
small/obvious one. Please let me know if you like me to change anything.

Here are the ChangeLog entries:

gcc/ChangeLog
+2014-01-24  Balaji V. Iyer  
+
+   * builtins.c (is_builtin_name): Renamed flag_enable_cilkplus to
+   flag_cilkplus.
+   * builtins.def: Likewise.
+   * cilk.h (fn_contains_cilk_spawn_p): Likewise.
+   * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Likewise.
+   * ira.c (ira_setup_eliminable_regset): Likewise.
+   * omp-low.c (gate_expand_omp): Likewise.
+   (execute_lower_omp): Likewise.
+   (diagnose_sb_0): Likewise.
+   (gate_diagnose_omp_blocks): Likewise.
+   (simd_clone_clauses_extract): Likewise.
+   (gate): Likewise.
+

gcc/c-family/ChangeLog
+2014-01-24  Balaji V. Iyer  
+
+   * c-common.c (c_define_builtins): Replaced flag_enable_cilkplus with
+   flag_cilkplus.
+   * c-pragma.c (init_pragma): Likewise.
+   * c.opt: Likewise.
+

gcc/c/ChangeLog
+2014-01-24  Balaji V. Iyer  
+
+   * c-parser.c (c_parser_declaration_or_fndef): Replaced
+   flag_enable_cilkplus with flag_cilkplus.
+   (c_parser_direct_declarator_inner): Likewise.
+   (c_parser_attribute_any_word): Likewise.
+   (c_parser_attributes): Likewise.
+   (c_parser_compound_statement): Likewise.
+   (c_parser_statement_after_labels): Likewise.
+   (c_parser_if_statement): Likewise.
+   (c_parser_switch_statement): Likewise.
+   (c_parser_do_statement): Likewise.
+   (c_parser_for_statement): Likewise.
+   (c_parser_unary_expression): Likewise.
+   (c_parser_postfix_expression): Likewise.
+   (c_parser_postfix_expression_after_primary): Likewise.
+   (c_parser_postfix_expression_after_primary): Likewise.
+   (c_parser_omp_clause_name): Likewise.
+   (c_finish_omp_declare_simd): Likewise.
+   (c_parser_cilk_verify_simd): Likewise.
+   * c-typeck.c (build_array_ref): Likewise.
+   (build_function_call_vec): Likewise.
+   (convert_arguments): Likewise.
+   (build_compound_expr): Likewise.
+   (c_finish_return): Likewise.
+   (c_finish_if_stmt): Likewise.
+   (c_finish_loop): Likewise.
+   (build_binary_op): Likewise.
+

gcc/lto/ChangeLog
+2014-01-24  Balaji V. Iyer  
+
+   * lto-lang.c (lto_init): Replaced flag_enable_cilkplus with
+   flag_cilkplus.
+

Thanks,

Balaji V. Iyer.
diff --git a/gcc/builtins.c b/gcc/builtins.c
index d2ea606..3e34c83 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -244,7 +244,7 @@ is_builtin_name (const char *name)
 return true;
   if (strncmp (name, "__atomic_", 9) == 0)
 return true;
-  if (flag_enable_cilkplus 
+  if (flag_cilkplus 
   && (!strcmp (name, "__cilkrts_detach")   
  || !strcmp (name, "__cilkrts_pop_frame")))
 return true;
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 5a4012d..524153f 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -174,7 +174,7 @@ along with GCC; see the file COPYING3.  If not see
 #undef DEF_CILKPLUS_BUILTIN
 #define DEF_CILKPLUS_BUILTIN(ENUM, NAME, TYPE, ATTRS)  \
   DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, BT_FN_INT_VAR, BT_LAST, \
-  false, false, false, ATTRS, false, flag_enable_cilkplus) 
+  false, false, false, ATTRS, false, flag_cilkplus) 
 
 /* Define an attribute list for math functions that are normally
"impure" because some of them may write into global memory for
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 86cec72..3ea5763 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5261,7 +5261,7 @@ c_define_builtins (tree va_list_ref_type_node, tree 
va_list_arg_type_node)
 
   build_common_builtin_nodes ();
 
-  if (flag_enable_cilkplus)
+  if (flag_cilkplus)
 cilk_init_builtins ();
 }
 
diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
index af28085..07d23ac 100644
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-pragma.c
@@ -1384,7 +1384,7 @@ init_pragma (void)
  omp_pragmas_simd[i].id, true, true);
 }
 
-  if (flag_enable_cilkplus && !flag_preprocess_only)
+  if (flag_cilkplus && !flag_preprocess_only)
 cpp_register_deferred_pragma (parse_in, NULL, "simd", PRAGMA_CILK_SIMD,
  true, false);
 
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 38ae58e..aad54e2 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -863,7 +863,7 @@ C ObjC C++ ObjC++
 Where shorter, use canonicalized paths to systems headers.
 
 fcilkplus
-C ObjC C++ ObjC++ LTO Report Var(flag_enable_cilkplus) Init(0)
+C ObjC C++ ObjC++ LTO Report Var(flag_cilkplus) Init(0)
 Enable Cilk Plus
 
 fcond-mismatch
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index bbf5287..e6b7b30 100644
--- a/gcc/c/c-parser.c
+++ b/

Re: [PATCH] add __attribute__ ((designated_init))

[Tom Tromey]

Joseph> Is there a reason someone using the attribute might not want the
Joseph> warning?  That is, why isn't -Wdesignated-init enabled by
Joseph> default, given that it's only relevant to people using an
Joseph> attribute whose sole function relates to the warning?

In making this change, I also removed the new option from -Wall.
It seemed like that would be the best approach; but I thought I'd note
it just to be sure.

Tom

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

[Markus Trippelsdorf]

On 2014.01.24 at 17:09 +0100, Dodji Seketeli wrote:
> Jakub Jelinek  writes:
> 
> > On Fri, Jan 24, 2014 at 04:40:52PM +0100, Dodji Seketeli wrote:
> >> > The patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 .
> >> > The follow-up patch (fp == NULL check) doesn't help.
> >> 
> >> I am looking into that, sorry for the inconvenience.
> >
> > I'd say we want something like following.  Note that while the c == NULL
> > bailout would be usually sufficient, if you'll do:
> > echo foobar > ''
> > it would still crash.  Line 0 is used only for the special locations
> > (command line, built-in macros) and there is no file associated with it
> > anyway.
> >
> > --- gcc/input.c.jj  2014-01-24 16:32:34.0 +0100
> > +++ gcc/input.c 2014-01-24 16:41:42.012671452 +0100
> > @@ -698,7 +698,13 @@ location_get_source_line (expanded_locat
> >static char *buffer;
> >static ssize_t len;
> >  
> > -  fcache * c = lookup_or_add_file_to_cache_tab (xloc.file);
> > +  if (xloc.line == 0)
> > +return NULL;
> > +
> > +  fcache *c = lookup_or_add_file_to_cache_tab (xloc.file);
> > +  if (c == NULL)
> > +return NULL;
> > +
> >bool read = read_line_num (c, xloc.line, &buffer, &len);
> >  
> >if (read && line_len)
> 
> Indeed.
> 
> Though, I am testing the patch below that makes read_line_num gracefully
> handle empty caches or zero locations.  The rest of the code should just
> work with that as is.
> 
>   * input.c (read_line_num): Gracefully handle non-file locations or
>   empty caches.

Unfortunately this doesn't fix yet another issue:

markus@x4 /tmp % cat foo.c
#line 4636 "configure"
#include 
int main() { return 0; }

markus@x4 /tmp % gcc foo.c
configure:4636:26: fatal error: .h: No such file or directory
gcc: internal compiler error: Segmentation fault (program cc1)
0x40cc8e execute
../../gcc/gcc/gcc.c:2841
0x40cf09 do_spec_1
../../gcc/gcc/gcc.c:4641
0x40fc91 process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fc91 handle_braces
../../gcc/gcc/gcc.c:5838
0x40d692 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fc91 process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fc91 handle_braces
../../gcc/gcc/gcc.c:5838
0x40d692 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40d28e do_spec_1
../../gcc/gcc/gcc.c:5410
0x40fc91 process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fc91 handle_braces
../../gcc/gcc/gcc.c:5838
0x40d692 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fc91 process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fc91 handle_braces
../../gcc/gcc/gcc.c:5838
0x40d692 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fc91 process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fc91 handle_braces
../../gcc/gcc/gcc.c:5838
0x40d692 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fc91 process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fc91 handle_braces
../../gcc/gcc/gcc.c:5838
Please submit a full bug report,
with preprocessed source if appropriate.

-- 
Markus

[C++ RFC/Patch] PR 58561

[Paolo Carlini]

Hi,

in this bug we ICE in dwarf2out.c:is_base_type with -g, because it 
doesn't know how to handle the TEMPLATE_TYPE_PARM coming from the C++ 
front-end and representing 'auto' in this kind of C++1y code.


That it shouldn't ICE and return 0 instead I'm pretty sure, I'm less 
sure about the next problem, that is what gen_type_die_with_usage should 
do: build a DW_TAG_unspecified_type, like happens for NULLPTR_TYPE or 
LANG_TYPE?!? Anyway, my wild guessing resulted in adding an hook, per 
the below draft (in any case, tentative names and comments but passes 
testing). Or we want something completely different?


Thanks,
Paolo.

///
Index: cp/cp-lang.c
===
--- cp/cp-lang.c(revision 207048)
+++ cp/cp-lang.c(working copy)
@@ -68,6 +68,9 @@ static tree get_template_argument_pack_elems_folde
 #undef LANG_HOOKS_GENERIC_GENERIC_PARAMETER_DECL_P
 #define LANG_HOOKS_GENERIC_GENERIC_PARAMETER_DECL_P \
template_template_parameter_p
+#undef LANG_HOOKS_IS_AUTO
+#define LANG_HOOKS_IS_AUTO \
+   is_auto
 #undef LANG_HOOKS_FUNCTION_PARM_EXPANDED_FROM_PACK_P
 #define LANG_HOOKS_FUNCTION_PARM_EXPANDED_FROM_PACK_P \
function_parameter_expanded_from_pack_p
Index: dwarf2out.c
===
--- dwarf2out.c (revision 207048)
+++ dwarf2out.c (working copy)
@@ -10222,6 +10222,9 @@ base_type_die (tree type)
 static inline int
 is_base_type (tree type)
 {
+  if (lang_hooks.decls.is_auto (type))
+return 0;
+  
   switch (TREE_CODE (type))
 {
 case ERROR_MARK:
@@ -19653,6 +19656,23 @@ gen_tagged_type_die (tree type,
  when appropriate.  */
 }
 
+/* Generate a DIE for an unspecified type.  */
+
+static void
+gen_unspecified_type_die (tree type)
+{
+  dw_die_ref type_die = lookup_type_die (type);
+  if (type_die == NULL)
+{
+  tree name = TYPE_NAME (type);
+  if (TREE_CODE (name) == TYPE_DECL)
+   name = DECL_NAME (name);
+  type_die = new_die (DW_TAG_unspecified_type, comp_unit_die (), type);
+  add_name_attribute (type_die, IDENTIFIER_POINTER (name));
+  equate_type_number_to_die (type, type_die);
+}
+}
+
 /* Generate a type description DIE.  */
 
 static void
@@ -19718,6 +19738,13 @@ gen_type_die_with_usage (tree type, dw_die_ref con
   return;
 }
 
+  if (lang_hooks.decls.is_auto (type))
+{
+  gen_unspecified_type_die (type);
+  TREE_ASM_WRITTEN (type) = 1;
+  return;
+}
+
   /* We are going to output a DIE to represent the unqualified version
  of this type (i.e. without any const or volatile qualifiers) so
  get the main variant (i.e. the unqualified version) of this type
@@ -19805,18 +19832,7 @@ gen_type_die_with_usage (tree type, dw_die_ref con
 case NULLPTR_TYPE:
 case LANG_TYPE:
   /* Just use DW_TAG_unspecified_type.  */
-  {
-dw_die_ref type_die = lookup_type_die (type);
-if (type_die == NULL)
-  {
-   tree name = TYPE_NAME (type);
-   if (TREE_CODE (name) == TYPE_DECL)
- name = DECL_NAME (name);
-type_die = new_die (DW_TAG_unspecified_type, comp_unit_die (), 
type);
-add_name_attribute (type_die, IDENTIFIER_POINTER (name));
-equate_type_number_to_die (type, type_die);
-  }
-  }
+  gen_unspecified_type_die (type);
   break;
 
 default:
Index: langhooks-def.h
===
--- langhooks-def.h (revision 207048)
+++ langhooks-def.h (working copy)
@@ -159,6 +159,7 @@ extern tree lhd_make_node (enum tree_code);
 #define LANG_HOOKS_FUNCTION_PARAMETER_PACK_P hook_bool_const_tree_false
 #define LANG_HOOKS_GET_ARGUMENT_PACK_ELEMS hook_tree_const_tree_null
 #define LANG_HOOKS_GENERIC_GENERIC_PARAMETER_DECL_P hook_bool_const_tree_false
+#define LANG_HOOKS_IS_AUTO hook_bool_const_tree_false
 #define LANG_HOOKS_FUNCTION_PARM_EXPANDED_FROM_PACK_P \
hook_bool_tree_tree_false
 #define LANG_HOOKS_GET_GENERIC_FUNCTION_DECL hook_tree_const_tree_null
@@ -220,6 +221,7 @@ extern tree lhd_make_node (enum tree_code);
   LANG_HOOKS_GETDECLS, \
   LANG_HOOKS_FUNCTION_DECL_EXPLICIT_P, \
   LANG_HOOKS_GENERIC_GENERIC_PARAMETER_DECL_P, \
+  LANG_HOOKS_IS_AUTO, \
   LANG_HOOKS_FUNCTION_PARM_EXPANDED_FROM_PACK_P, \
   LANG_HOOKS_GET_GENERIC_FUNCTION_DECL, \
   LANG_HOOKS_WARN_UNUSED_GLOBAL_DECL, \
Index: langhooks.h
===
--- langhooks.h (revision 207048)
+++ langhooks.h (working copy)
@@ -164,6 +164,9 @@ struct lang_hooks_for_decls
  of a generic type, e.g a template template parameter for the C++ FE.  */
   bool (*generic_generic_parameter_decl_p) (const_tree);
 
+  /* Returns true if the parameter represents 'auto' or 'decltype(auto)'.  */
+  bool (*is_auto) (const_tree);
+
   /* Determine if a function para

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

[Markus Trippelsdorf]

On 2014.01.25 at 00:02 +0100, Markus Trippelsdorf wrote:
> On 2014.01.24 at 17:09 +0100, Dodji Seketeli wrote:
> > Jakub Jelinek  writes:
> > 
> > > On Fri, Jan 24, 2014 at 04:40:52PM +0100, Dodji Seketeli wrote:
> > >> > The patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 .
> > >> > The follow-up patch (fp == NULL check) doesn't help.
> > >> 
> > >> I am looking into that, sorry for the inconvenience.
> > >
> > > I'd say we want something like following.  Note that while the c == NULL
> > > bailout would be usually sufficient, if you'll do:
> > > echo foobar > ''
> > > it would still crash.  Line 0 is used only for the special locations
> > > (command line, built-in macros) and there is no file associated with it
> > > anyway.
> > >
> > > --- gcc/input.c.jj2014-01-24 16:32:34.0 +0100
> > > +++ gcc/input.c   2014-01-24 16:41:42.012671452 +0100
> > > @@ -698,7 +698,13 @@ location_get_source_line (expanded_locat
> > >static char *buffer;
> > >static ssize_t len;
> > >  
> > > -  fcache * c = lookup_or_add_file_to_cache_tab (xloc.file);
> > > +  if (xloc.line == 0)
> > > +return NULL;
> > > +
> > > +  fcache *c = lookup_or_add_file_to_cache_tab (xloc.file);
> > > +  if (c == NULL)
> > > +return NULL;
> > > +
> > >bool read = read_line_num (c, xloc.line, &buffer, &len);
> > >  
> > >if (read && line_len)
> > 
> > Indeed.
> > 
> > Though, I am testing the patch below that makes read_line_num gracefully
> > handle empty caches or zero locations.  The rest of the code should just
> > work with that as is.
> > 
> > * input.c (read_line_num): Gracefully handle non-file locations or
> > empty caches.
> 
> Unfortunately this doesn't fix yet another issue:

Whereas Jakub's patch is fine.

-- 
Markus

Re: [PATCH, committed] Replace flag_enable_cilkplus with flag_cilkplus

[Aldy Hernandez]

On 01/24/14 14:57, Iyer, Balaji V wrote:

Hello Jakub and Aldy, As you both requested, this patch will replace
flag_enable_cilkplus with flag_cilkplus. I have committed this patch
since the change is a small/obvious one. Please let me know if you
like me to change anything.


This is fine.

Thank you.

[jit] Add test case for a client that adds nothing to a gcc_jit_context

[David Malcolm]

Committed to dmalcolm/jit:

gcc/testsuite/
* jit.dg/test-empty.c: New test case: a client that adds nothing
to a gcc_jit_context.
---
 gcc/testsuite/ChangeLog.jit   |  4 
 gcc/testsuite/jit.dg/test-empty.c | 20 
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/jit.dg/test-empty.c

diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index 924030f..3ca1072 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,5 +1,9 @@
 2014-01-24  David Malcolm  
 
+   * jit.dg/test-empty.c: New test case.
+
+2014-01-24  David Malcolm  
+
* jit.dg/harness.h (code_making_callback): Rename to...
(create_code): ...this, and eliminate the returned
error-handling value: test cases will simply call into the
diff --git a/gcc/testsuite/jit.dg/test-empty.c 
b/gcc/testsuite/jit.dg/test-empty.c
new file mode 100644
index 000..820f232
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-empty.c
@@ -0,0 +1,20 @@
+#include 
+#include 
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+  /* Do nothing.  */
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+  /* We should have a non-NULL result, albeit one with nothing in it.  */
+  CHECK_NON_NULL (result);
+}
+
-- 
1.7.11.7

[GOOGLE] Adjust profile for AutoFDO

[Dehao Chen]

This patch fixes performance regression for AutoFDO. When the entry
block count is 0, which is quite possible in AutoFDO, it can still
make right optimization decision.

Bootstrapped passed regression test and performance test (improve 0.5%
on average).

OK for google-4_8?

Thanks,
Dehao
Index: gcc/bb-reorder.c
===
--- gcc/bb-reorder.c(revision 207066)
+++ gcc/bb-reorder.c(working copy)
@@ -1564,15 +1564,14 @@ find_rarely_executed_basic_blocks_and_crossing_edg
   /* Mark which partition (hot/cold) each basic block belongs in.  */
   FOR_EACH_BB (bb)
 {
-  bool cold_bb = false;
+  bool cold_bb = probably_never_executed_bb_p (cfun, bb);
 
-  if (probably_never_executed_bb_p (cfun, bb))
+  if (!flag_auto_profile && cold_bb)
 {
   /* Handle profile insanities created by upstream optimizations
  by also checking the incoming edge weights. If there is a non-cold
  incoming edge, conservatively prevent this block from being split
  into the cold section.  */
-  cold_bb = true;
   FOR_EACH_EDGE (e, ei, bb->preds)
 if (!probably_never_executed_edge_p (cfun, e))
   {
Index: gcc/predict.c
===
--- gcc/predict.c   (revision 207066)
+++ gcc/predict.c   (working copy)
@@ -2902,7 +2902,7 @@ counts_to_freqs (void)
   /* Don't overwrite the estimated frequencies when the profile for
  the function is missing.  We may drop this function PROFILE_GUESSED
  later in drop_profile ().  */
-  if (!ENTRY_BLOCK_PTR->count)
+  if (!flag_auto_profile && !ENTRY_BLOCK_PTR->count)
 return 0;
 
   FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR, NULL, next_bb)
@@ -3161,7 +3161,8 @@ rebuild_frequencies (void)
 count_max = MAX (bb->count, count_max);
 
   if (profile_status == PROFILE_GUESSED
-  || (profile_status == PROFILE_READ && count_max < REG_BR_PROB_BASE/10))
+  || (!flag_auto_profile && profile_status == PROFILE_READ
+ && count_max < REG_BR_PROB_BASE/10))
 {
   loop_optimizer_init (0);
   add_noreturn_fake_exit_edges ();