Re: Hurd port for GCC Go

[Thomas Schwinge]

Hi!

On Fri, 14 Jun 2013 22:37:03 +0200, Svante Signell  
wrote:
> On Fri, 2013-06-14 at 16:42 +0200, Thomas Schwinge wrote:
> > On Thu, 13 Jun 2013 10:39:58 +0200, I wrote:
> > > On Wed, 12 Jun 2013 15:36:39 +0200, Svante Signell 
> > >  wrote:
> > > > On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote:
> > > > > On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell 
> > > > >  wrote:
> > > > > > Attached are patches to enable gccgo to build properly on Debian
> > > > > > GNU/Hurd on gcc-4.7 (4.7.3-4).
> > > > > 
> > > > > Thanks!  I've begun integrating them into my GCC tree (based on 
> > > > > upstream
> > > > > GCC trunk, so some changes to be done to your patches), and get it in 
> > > > > a
> > > > > state for Fotis to base his GSoC work on.
> ...
> > I have now pushed my working branch to tschwinge/t/hurd/go, and will
> > update this from time to time, both for integrating further changes (my
> > own as well as those that you send me), and merge in GCC trunk changes.
> > On that branch, use something like »git diff :/refs/top-bases/baseline«
> > to diff your working tree against the branch's base.  When reviewing the
> > commit history on that branch, it may be helpful to exclude any bulk
> > merges from trunk, so use something like »git log HEAD ^origin/trunk«.
> > 
> > Fotis and Svante, please base any futher work for the Hurd port for GCC
> > Go on that branch.  Send patches by email, for now.
> > 
> > > I got as far as having GCC Go compiling with GCC trunk sources; more to
> > > come later.
> 
> Sorry, I'm not fluent in git. Which command to use to check out your
> branch tschwinge/t/hurd/go? Cannot find it at
> http://git.savannah.gnu.org/cgit/hurd/glibc.git/

That's no surprise, as I've talking about the GCC Git repository,
.  Clone it, and then create a local
branch based on the one I pushed, so something like:

$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc/
$ git checkout -b tschwinge/t/hurd/go origin/tschwinge/t/hurd/go


As I'm still occasionally seeing file corruption as described on
 and
,
I suggest you either pass the --quiet flag to any Git command you use, or
clone on a GNU/Linux box and then use rsync or something similar for
copying the repository and working directory to your GNU/Hurd system.


Grüße,
 Thomas


pgpeMhTIQeNMx.pgp
Description: PGP signature

Alias set coverage issues (Was: Re: RFA: Fix rtl-optimization/57425)

[Joern Rennecke]

Quoting Eric Botcazou :


Bootstrapped/regtested on i686-pc-linux-gnu.


For the record, and as you diagnosed, the change proposed in
  http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00367.html
means that we must now be very careful with memory dependency checking in the
various RTL optimization passes.  Another example is PR rtl-opt/57569.


[subject / list changed because this goes off on a tangent]

I have set out here to just fix the problem at hand, but it is a bit
worrying that cse is about to replace a read with a copy of a value read
before using an alias set that is not considered compatible.
It would be OK if the alias set of the re-used read was adjusted, but I don't
think we have any such code in cse.
In this case, avoiding an invalid transformation (due to anti-dependency)
avoids further complications from the alias sets, but what if we had
a more complex case?  Could we end up with a non-matching write/read pair
that can be re-ordered by subsequent passes?  It couldn't be for sharing
a previous stack-slot like in the test cases here, since then we would
have to have an uninitialized read or overlapping lifetimes to start with,
but maybe it could happen when using union member/aliased read accesses
with use that depends on a discriminator?
The thing is, when it comes to alias set issues, very seldom is it true that
everything that can go wrong, does.  Michael Matz shuffle mode would go
some way to address this, but it still would provide poor coverage when
we need to take a specific path on a long Markov chain to see a problem.

Now, if we had an rtl interpreter that can be invoked in addition to/instead
of a dump generation with specific options, and this interpreter not only
kept track of values being initialized (as valgrind does), but actually
kept track of the alias of the last write for each addressable unit, and
checked the compatibility of the alias set on read, we'd have a powerful
tool to both add new regression tests, and to help during debugging where
the compiler goes wrong, or for a user, to check if his/her code contains
alias set problems.
Would this be suitable for a GSOC project?
It would already be useful if it worked just for self-contained tests,
although obviously the utility would increase if it could dynamically load
other object files (with name mangling?) to complete a multi-module test case.

out of source builds and precompiled headers

[Rodolfo Lima]

I'm just pinging bug #19541 which, despite having patches with several 
solutions, isn't assigned to anybody. It's a 8 years old bug...


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541

Here's the note I added there, FYI:

How difficult is it to add a parameter to add paths to precompiled 
header search list *only*?


We have a big code base with #include "pch.h" in some source files.
If source file directory is always searched first for headers, this 
breaks out-of-source builds, unless the precompiled header is generated 
in the source tree. For read-only source trees, this "solution" is 
unacceptable.


The ideal solution would be a parameter like -ipch  that adds 
 to be searched for precompiled headers *before* the current 
source directory.


I could spend some time creating a patch, but seeing that others have 
come with patches that weren't applied, this kind of demotivate me.



Best regards,
Rodolfo Lima

[PR43721] Failure to optimise (a/b) and (a%b) into single call

[Kugan]

Hi,

I am attempting to fix Bug 43721 - Failure to optimise (a/b) and (a%b) 
into single __aeabi_idivmod call 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721)


execute_cse_sincos tree level pass does similar cse so I attempted to 
use similar approach here. Div/mod cse is not really using built-in 
functions though at this level.


For the case of div and mod operations, after CSE is performed, there 
isnt a way to represent the resulting stament in gimple. We will endup 
with divmod  taking two arguments and returning double the size of one 
arguments in the three address format (divmod will return reminder and 
quotient so the return type is double the size of argument type).


Since GIMPLE_ASSIGN will result in type checking failure in this case, I 
atempted use built-in functions (GIMPLE_CALL to represent the runtime 
library call). Name for the function here  is target specific and can be 
obtained from sdivmod_optab so the builtin function name defined in tree 
level is not used. I am not entirelt sure this is the right approach so 
I am attaching the first cut of the patch to get your feedback and 
understand the right approach to this problem.




Thank you,
Kugan

diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index 2634ecc..21c483a 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -250,6 +250,10 @@ DEF_FUNCTION_TYPE_2 (BT_FN_INT_CONST_STRING_FILEPTR,
 		 BT_INT, BT_CONST_STRING, BT_FILEPTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_INT_INT_FILEPTR,
 		 BT_INT, BT_INT, BT_FILEPTR)
+DEF_FUNCTION_TYPE_2 (BT_FN_LONGLONG_INT_INT,
+		 BT_LONGLONG, BT_INT, BT_INT)
+DEF_FUNCTION_TYPE_2 (BT_FN_ULONGLONG_UINT_UINT,
+		 BT_ULONGLONG, BT_UINT, BT_UINT)
 DEF_FUNCTION_TYPE_2 (BT_FN_VOID_PTRMODE_PTR,
 		 BT_VOID, BT_PTRMODE, BT_PTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_VOID_PTR_PTRMODE,
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 402bb1f..1cae2bb 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -1876,7 +1876,9 @@ mathfn_built_in_1 (tree type, enum built_in_function fn, bool implicit_p)
   CASE_MATHFN (BUILT_IN_Y0)
   CASE_MATHFN (BUILT_IN_Y1)
   CASE_MATHFN (BUILT_IN_YN)
-
+  case BUILT_IN_DIVMOD:
+  case BUILT_IN_UDIVMOD:
+return builtin_decl_explicit (fn);
   default:
 	return NULL_TREE;
   }
@@ -2449,6 +2451,57 @@ expand_builtin_interclass_mathfn (tree exp, rtx target)
   return NULL_RTX;
 }
 
+/* Expand a call to the builtin divmod function to
+   library call.  */
+static rtx
+expand_builtin_divmod (tree exp, rtx target)
+{
+  rtx op0, op1;
+  enum machine_mode mode;
+  tree arg0, arg1;
+  rtx libval;
+  rtx libfunc;
+  rtx insns;
+  bool is_unsigned;
+
+  arg0 = CALL_EXPR_ARG (exp, 0);
+  arg1 = CALL_EXPR_ARG (exp, 1);
+
+  mode = TYPE_MODE (TREE_TYPE (arg0));
+  is_unsigned = TYPE_UNSIGNED (TREE_TYPE (arg0));
+
+  /* Get the libcall.  */
+  libfunc = optab_libfunc (is_unsigned ? udivmod_optab : sdivmod_optab, mode);
+  gcc_assert (libfunc);
+
+  op0 = expand_normal (arg0);
+  op1 = expand_normal (arg1);
+
+  if (MEM_P (op0))
+op0 = force_reg (mode, op0);
+  if (MEM_P (op1))
+op1 = force_reg (mode, op1);
+
+  /* The value returned by the library function will have twice as
+ many bits as the nominal MODE.  */
+  machine_mode libval_mode
+= smallest_mode_for_size (2 * GET_MODE_BITSIZE (mode),
+  MODE_INT);
+  start_sequence ();
+  libval = emit_library_call_value (libfunc, NULL_RTX, LCT_CONST,
+libval_mode, 2,
+op0, mode,
+op1, mode);
+  insns = get_insns ();
+  end_sequence ();
+  /* Move into the desired location.  */
+  if (target != const0_rtx)
+emit_libcall_block (insns, target, libval,
+gen_rtx_fmt_ee (is_unsigned ?  UMOD : MOD, mode, op0, op1));
+
+  return target;
+}
+
 /* Expand a call to the builtin sincos math function.
Return NULL_RTX if a normal call should be emitted rather than expanding the
function in-line.  EXP is the expression that is a call to the builtin
@@ -5977,6 +6030,13 @@ expand_builtin (tree exp, rtx target, rtx subtarget, enum machine_mode mode,
 	return target;
   break;
 
+case BUILT_IN_DIVMOD:
+case BUILT_IN_UDIVMOD:
+  target = expand_builtin_divmod (exp, target);
+  if (target)
+return target;
+  break;
+
 CASE_FLT_FN (BUILT_IN_SINCOS):
   if (! flag_unsafe_math_optimizations)
 	break;
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 91879a6..7664700 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -599,6 +599,8 @@ DEF_C99_BUILTIN(BUILT_IN_VSCANF, "vscanf", BT_FN_INT_CONST_STRING_VALIST
 DEF_C99_BUILTIN(BUILT_IN_VSNPRINTF, "vsnprintf", BT_FN_INT_STRING_SIZE_CONST_STRING_VALIST_ARG, ATTR_FORMAT_PRINTF_NOTHROW_3_0)
 DEF_LIB_BUILTIN(BUILT_IN_VSPRINTF, "vsprintf", BT_FN_INT_STRING_CONST_STRING_VALIST_ARG, ATTR_FORMAT_PRINTF_NOTHROW_2_0)
 DEF

source code to object code tracetability

[Barry Holm]

Hi,

I am trying to analyze source code to object code traceability while
using C source code and GCC 3.3.2 with optimization levels O0, O1, O2.
I create test cases that each test case (separate routine) contains
one C source code construct (if - else, do-while, for loop, switch and
etc.) and analyse the traceability to the object code. I would like to
ensure that all cases of constructs in the source code are covered by
this analysis.  I wonder if I need to extend the list of constructs
with additional cases as “if….else do….while”  in case the object code
created from separate  “if….else" and "do….while” statements is
different from the object code created  from two consecutive “if…else
do ... while” statements.  Is there a way to identify the full list of
these constructs to ensure that each object code is traceable back to
the source code using optimization level -O2? How different is this
list from optimization level -O1 or -O0?

Thanks,

Barry.

Re: setcontext et al. functions (was: Inquiry about GCC Summer Of Code project idea.)

[Samuel Thibault]

Thomas Schwinge, le Tue 11 Jun 2013 10:27:09 +0200, a écrit :
> Anyway, Samuel, would you please
> put the current »tg patch t/context_functions« as a new patch into the
> Debian glibc package?

Yep, it is done, waiting for next upload.

Samuel

designated initializers extension and sparc

[Sergey Kljopov]

Hi,

Reading the text
-
In a structure initializer, specify the name of a field to initialize 
with `.fieldname =' before the element value. For example, given the 
following structure,

 struct point { int x, y; };
the following initialization
 struct point p = { .y = yvalue, .x = xvalue };
is equivalent to
 struct point p = { xvalue, yvalue };
Another syntax which has the same meaning, obsolete since GCC 2.5, is 
`fieldname:', as shown here:

 struct point p = { y: yvalue, x: xvalue };
The `[index]' or `.fieldname' is known as a designator. You can also use 
a designator (or the obsolete colon syntax) when initializing a union, 
to specify which element of the union should be used. For example,

 union foo { int i; double d; };
 union foo f = { .d = 4 };
will convert 4 to a double to store it in the union using the second 
element. By contrast, casting 4 to type union foo would store it into 
the union as the integer i, since it is an integer. (See Cast to Union.)

-
I wrote the following test:

union foo { int i; double d; };

int main(int argc, char **argv)
{
union foo f = { .d = 4 };

ASSERT_EQ(0, f.i);
ASSERT_FEQ(4.0, f.d);

return 0;
}

ASSERT_EQ and ASSERT_FEQ are some macros which checks the falue and 
gives some error messages.


It seems that this extension should be bi-endian, however it fails on 
the sparc.

What the problem with the test?

Sergey

gcc-4.9-20130616 is now available

[gccadmin]

Snapshot gcc-4.9-20130616 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20130616/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 200141

You'll find:

 gcc-4.9-20130616.tar.bz2 Complete GCC

  MD5=64b451e5dfcc930e80f9d2107a04b65c
  SHA1=ab07de380f467e644930417a5ed5efb88b737cdd

Diffs from 4.9-20130609 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: source code to object code tracetability

[Ian Lance Taylor]

On Sun, Jun 16, 2013 at 10:06 AM, Barry Holm  wrote:
>
> I am trying to analyze source code to object code traceability while
> using C source code and GCC 3.3.2 with optimization levels O0, O1, O2.
> I create test cases that each test case (separate routine) contains
> one C source code construct (if - else, do-while, for loop, switch and
> etc.) and analyse the traceability to the object code. I would like to
> ensure that all cases of constructs in the source code are covered by
> this analysis.  I wonder if I need to extend the list of constructs
> with additional cases as “if….else do….while”  in case the object code
> created from separate  “if….else" and "do….while” statements is
> different from the object code created  from two consecutive “if…else
> do ... while” statements.  Is there a way to identify the full list of
> these constructs to ensure that each object code is traceable back to
> the source code using optimization level -O2? How different is this
> list from optimization level -O1 or -O0?

You didn't really say what the goal was.

At -O2 some source code constructs can disappear from the object code
entirely, because the results they compute are unused.  Is that OK for
your purposes?

When optimizing, the compiler doesn't really see the input in source
code terms.  Conditions and loops are broken down into simple branches
and conditional branches, then basic blocks and loops are built out of
that.  So the divergence between the source code and the compiled code
can be fairly large.

Ian