GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th
Status == The trunk is scheduled to transition from Stage 1 to Stage 3 at the end of Saturday, November 15th (use your timezone to your advantage). We have been in Stage 1 for almost 7 months now with a fortnight still to go. Still now is a good time to look into bugzilla and pick one or two regressions in your area of expertise and fix them (you may want to prioritize regressions against both 4.9 and 5). What larger merges are still planned for GCC 5? I'm aware of pending merges from match-and-simplify branch, there are the JIT changes partially? approved, MPX also partially? approved, Intel offloading patches partially approved, PTX support partially reviewed. Thomas, do you plan to post OpenACC changes for review still during stage1? Do you have any dependencies there (PTX and/or Intel offloading being merged first?)? What else have been people working on and can get posted for review before stage1 closes? As before, when new features are posted for review during stage 1 and only acked early during stage 3, they can still be accepted for GCC 5. Somewhat misleading quality data below, P3 bugs have not been re-prioritized for quite some time now. We promise to do this shortly after entering Stage 3. Quality Data Priority # Change from last report --- --- P1 10+ 10 P2 82+ 6 P3 92+ 86 --- --- Total 184+ 102 Previous Report === https://gcc.gnu.org/ml/gcc/2014-04/msg00090.html The next report will be sent by Richard, announcing transition to stage 3.
Re: Comparing tree types
Hi,
On Mon, Nov 03, 2014 at 03:12:10AM +0530, Vini Kanvar wrote:
> I am trying to compare the tree declarations of the lhs and the rhs of
> the assignment statement in the following program.
>
> struct node {
> struct node * next;
> };
> struct node ** obj1, obj2;
> obj1 = &obj2.next;// lhs is obj1, rhs is obj2.next
RHS should be &obj2.next, note the &. I suppose that is why you are
getting a non-pointer type when inspecting TREE_TYPE (obj2.next_tree),
because according to the dumps below, you are missing an ADDR_EXPR
somewhere.
Please note that when comparing types, you should probably use a
designated function to do that. If you work at GIMPLE level, such
functions are types_compatible_p or useless_type_conversion_p, I do
not remember now what they are at GENERIC stage.
>
> ---
> Let us call the following tree declaration of the lhs as "obj1_tree".
> -
> type type
> unsigned SI
> size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x405cc000
> pointer_to_this >
> unsigned SI
> size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x405c5ea0>
> used unsigned SI file structstruct2.c line 8 col 17
> size bitsizetype> constant 32>
> unit size sizetype> constant 4>
> align 32 context chain 0x405cc1e0 obj2>>
>
> -
> Let us call the following tree declaration of the rhs as
> "obj2.next_tree"
> -
> type type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x405c5f60
> fields context 0x40526804 D.2319>
> pointer_to_this chain 0x40526870 node>>
> unsigned SI
> size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x405cc000
> pointer_to_this >
> used unsigned nonlocal SI file structstruct2.c line 3 col 16
> size bitsizetype> constant 32>
> unit size sizetype> constant 4>
> align 32 offset_align 128
> offset sizetype> constant 0>
> bit offset bitsizetype> constant 0> context chain
> >
> -
>
> Please note from the above tree declarations that
> Type1 = TREE_TYPE (TREE_TYPE (obj1_tree)) = 0x405c5f00
> Type2 = TREE_TYPE (obj2.next_tree) = 0x405cc000
> Type3 = TYPE_POINTER_TO (TREE_TYPE (TREE_TYPE (obj2.next_tree))) =
> 0x405c5f00
>
> I was expecting Type1 and Type2 to be equal because obj1=&obj2.next.
> However, in this case, we see that Type1 and Type3 are equal. Please
> explain this.
>
> Also, what is the meaning of "pointer_to_this" in the tree declarations?
I have not double checked but I suppose that is a simple mechanism of
caching so that we do not re-create the same type multiple times.
HTH
Martin
Re: add support for debugging output
On Fri, Oct 31, 2014 at 3:30 PM, Prathamesh Kulkarni
wrote:
> On Fri, Oct 31, 2014 at 7:33 PM, Prathamesh Kulkarni
> wrote:
>> Hi,
>>I was wondering if it would be a good idea to add "debugging"
>> output to the patterns.
>> sth like:
>>
>> (simplify
>> (plus @x integer_zerop)
>> (non_lvalue @x)
>> debug_out "Simplified pattern_foo")
Hmm. Jakub requested to put back the (optional) naming of patterns.
So instead of just printing file:line we could name the pattern that applied.
Of course for
(simplify "foo"
(mult @x @y)
(if (integer_zerop (@y))
@y)
(if (integer_onep (@y))
@x))
it wouldn't distinguish both cases.
But yes, using the file:line in testcases makes them too volatile to
changes.
>> the corresponding change in gimple-match.c/generic-match.c would be:
>> if (dump_file && (dump_flags & TDF_DETAILS))
>> {
>> fprintf (dump_file, "Applying pattern match.pd:161, %s:%d\n",
>> __FILE__, __LINE__);
>> fprintf (dump_file, "Simplified pattern_foo\n");
>> }
> Transforms that involve subexpressions may return false, so it woudn't
> be correct to place debug_out there.
Hmm, why? Ah, because if "seq" is NULL.
> maybe instead place debug_out string just above "return true;" ?
Yeah, we probably should move the existing debug output there.
So besides from putting naming of simplify patterns back we probably
need to add a counter for the transform inside it so we could print
"Applying simplification 2 in pattern foo" if we applied x * 1 -> x.
OTOH it doesn't tell you the full story either if it is
(for op (mult plus)
(simplify
(op @x integer_zerop)
@x))
because ideally you'd want to know the operator that was used as well...
(so print "with op == mult"?). What about commutates and conditional
converts? In the end having both match.pd line and generated file
line gets me enough information for my debugging.
And for dump files all users of gimple_simplify add their own debug
dumping (which doesn't always tell the whole story).
(it's always a good idea to include a gcc mailing list in such discussions)
Richard.
> for the above pattern:
>
> /* #line 3 "plus.pd" */
> tree captures[2] ATTRIBUTE_UNUSED = {};
> captures[0] = op0;
> captures[1] = op1;
> if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file,
> "Applying pattern plus.pd:3, %s:%d\n", __FILE__, __LINE__);
> res_ops[0] = captures[0];
> *res_code = TREE_CODE (res_ops[0]);
> // add here
> if (dump_file && (dump_flags & TDF_DETAILS)) fprintf ("Simplified
> pattern_foo\n");
> return true;
>>
>> and in the test-cases we can simply grep for "Simplified pattern_foo".
>> sth like:
>>
>> int test (int x)
>> {
>> int t1 = 0;
>> int t2 = x + t1;
>> return t2;
>> }
>> /* { dg-final { scan-tree-dump "Simplified pattern_foo" "ccp1" } } */
>>
>> or maybe introduce name to simplifiers ?
>> (simplify "pattern_foo"
>> (plus @x integer_zerop)
>> (non_lvalue @x))
>>
>> and corresponding gimple-match.c change:
>> fprintf (dump_file, "pattern_foo\n");
>>
>> (not sure if it's correct grepping for debug_out in test-cases, it
>> worked for the
>> above pattern though).
>>
>> Thanks.
>> Prathamesh
Latest trunk does not build
The latest trunk code does not build (on s390x): git commit id: 2ad7e37ad4be8621eade1f90dd2bc8124034712e git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@217039 138bc75d-0d04-0410-961f-82ee72b054a4 Error messages: -- snip -- g++ -c -g3 -O3 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -o ifcvt.o -MT ifcvt.o -MMD -MP -MF ./.deps/ifcvt.TPo ../../gcc/ifcvt.c In file included from ./tm.h:19:0, from ../../gcc/ifcvt.c:23: ./options.h:263:36: error: token "." is not valid in preprocessor expressions #define target_flags global_options.x_target_flags ^ ./options.h:4276:29: note: in expansion of macro ‘target_flags’ #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0) ^ ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’ #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT) ^ ../../gcc/ifcvt.c:1467:5: note: in expansion of macro ‘HAVE_cbranchcc4’ #if HAVE_cbranchcc4 ^ ./options.h:263:36: error: token "." is not valid in preprocessor expressions #define target_flags global_options.x_target_flags ^ ./options.h:4276:29: note: in expansion of macro ‘target_flags’ #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0) ^ ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’ #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT) ^ ../../gcc/ifcvt.c:1799:5: note: in expansion of macro ‘HAVE_cbranchcc4’ #if HAVE_cbranchcc4 ^ ./options.h:263:36: error: token "." is not valid in preprocessor expressions #define target_flags global_options.x_target_flags ^ ./options.h:4276:29: note: in expansion of macro ‘target_flags’ #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0) ^ ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’ #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT) ^ ../../gcc/ifcvt.c:2381:5: note: in expansion of macro ‘HAVE_cbranchcc4’ #if HAVE_cbranchcc4 ^ -- snip -- Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since the recent changes to the testsuites the folowing make targets in the libstdc++ testsuite directory don't work anymore: check-parallel check-performance check-performance-parallel Any comments? Cheers Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUV5dzAAoJEB3HOsWs+KJbpyAIAKOttNcFAlFa5XSQ/bElqRrb tAbO5pam4uf51ibbb8aXih+okh9jR5EUThYD8WqPmq7mU+t5TZyjjL+4mfJJNoZQ hRAXb0nweO7Niy8CNUXv+gOOwVZ0vXAa1KA4+86Dz/dlKVSnZA/yNY+bXZrA/nnz eac2HZk+a6hXeWJuyq/rQKqy1pwAmJWkIjPpJLsLmpVYCkDcJE4DkX1bOdnIa7j1 kHyzF/rVszg9dpSkf92fD22jLgK88dL7RSun77fxRW8AMcQgdpq0++2elh4A+9yd TnSx5JKWbWtoRq2TXmZVlMcompyrhRqBI+nUUFgkqqlNDWKi+4EC7fUq6qXuL1o= =/2+x -END PGP SIGNATURE-
Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th
On 11/03/2014 10:18 AM, Jakub Jelinek wrote: What larger merges are still planned for GCC 5? I'm aware of pending merges from match-and-simplify branch, there are the JIT changes partially? approved, MPX also partially? approved, Intel offloading patches partially approved, PTX support partially reviewed. I think the basic ptx port has been fully reviewed and I'll start checking things in soon. The offloading pieces have depend on Ilya's patches. I'll let Thomas answer about the plan for OpenACC changes. Bernd
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
Hi,
On 11/03/2014 03:55 PM, Rainer Emrich wrote:
Since the recent changes to the testsuites the folowing make targets in the
libstdc++ testsuite directory don't work anymore:
check-parallel
check-performance
check-performance-parallel
Any comments?
All I can see so far is a non-conforming use of default arguments (ie,
repeated in the function template definitions) in
include/parallel/algo.h, which the front-end didn't catch until quite
recently (not in 4.9.x). See below what I mean to apply to fix that. Not
sure if you meant something else (too) in your terse message, tough.
Thanks,
Paolo.
///
Index: include/parallel/algo.h
===
--- include/parallel/algo.h (revision 217034)
+++ include/parallel/algo.h (working copy)
@@ -81,9 +81,8 @@
template
_Function
__for_each_switch(_RAIter __begin, _RAIter __end,
-_Function __f, random_access_iterator_tag,
-__gnu_parallel::_Parallelism __parallelism_tag
-= __gnu_parallel::parallel_balanced)
+_Function __f, random_access_iterator_tag,
+__gnu_parallel::_Parallelism __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION(
static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)
@@ -896,8 +895,7 @@
typename iterator_traits<_RAIter>::difference_type
__count_switch(_RAIter __begin, _RAIter __end,
const _Tp& __value, random_access_iterator_tag,
- __gnu_parallel::_Parallelism __parallelism_tag
- = __gnu_parallel::parallel_unbalanced)
+ __gnu_parallel::_Parallelism __parallelism_tag)
{
typedef iterator_traits<_RAIter> _TraitsType;
typedef typename _TraitsType::value_type _ValueType;
@@ -966,8 +964,7 @@
typename iterator_traits<_RAIter>::difference_type
__count_if_switch(_RAIter __begin, _RAIter __end,
_Predicate __pred, random_access_iterator_tag,
-__gnu_parallel::_Parallelism __parallelism_tag
-= __gnu_parallel::parallel_unbalanced)
+__gnu_parallel::_Parallelism __parallelism_tag)
{
typedef iterator_traits<_RAIter> _TraitsType;
typedef typename _TraitsType::value_type _ValueType;
@@ -1225,8 +1222,7 @@
__transform1_switch(_RAIter1 __begin, _RAIter1 __end,
_RAIter2 __result, _UnaryOperation __unary_op,
random_access_iterator_tag, random_access_iterator_tag,
- __gnu_parallel::_Parallelism __parallelism_tag
- = __gnu_parallel::parallel_balanced)
+ __gnu_parallel::_Parallelism __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION(
static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)
@@ -1315,8 +1311,7 @@
_RAIter3 __result, _BinaryOperation __binary_op,
random_access_iterator_tag, random_access_iterator_tag,
random_access_iterator_tag,
- __gnu_parallel::_Parallelism __parallelism_tag
- = __gnu_parallel::parallel_balanced)
+ __gnu_parallel::_Parallelism __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION(
(__end1 - __begin1) >=
@@ -1422,8 +1417,7 @@
__replace_switch(_RAIter __begin, _RAIter __end,
const _Tp& __old_value, const _Tp& __new_value,
random_access_iterator_tag,
- __gnu_parallel::_Parallelism __parallelism_tag
- = __gnu_parallel::parallel_balanced)
+ __gnu_parallel::_Parallelism __parallelism_tag)
{
// XXX parallel version is where?
replace(__begin, __end, __old_value, __new_value,
@@ -1478,8 +1472,7 @@
__replace_if_switch(_RAIter __begin, _RAIter __end,
_Predicate __pred, const _Tp& __new_value,
random_access_iterator_tag,
- __gnu_parallel::_Parallelism __parallelism_tag
- = __gnu_parallel::parallel_balanced)
+ __gnu_parallel::_Parallelism __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION(
static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)
@@ -1544,8 +1537,7 @@
void
__generate_switch(_RAIter __begin, _RAIter __end,
_Generator __gen, random_access_iterator_tag,
-__gnu_parallel::_Parallelism __parallelism_tag
-= __gnu_parallel::parallel_balanced)
+__gnu_parallel::_Parallelism __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION(
static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)
@@ -1608,8 +1600,7 @@
inline _RAIter
__generate_n
Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th
> What else have been people working > on and can get posted for review before stage1 closes? > As before, when new features are posted for review during stage 1 and only > acked early during stage 3, they can still be accepted for GCC 5. This patch: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg0.html is pending review and will allow two things: 1) Converting a lot of Fortran diagnostics to use the common diagnostics machinery. 2) More precise locations within strings: https://gcc.gnu.org/PR52952 (I have a semi-tested patch, but it needs more work). In addition, this patch: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02723.html is waiting for feedback: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02467.html As I said here: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02700.html "Despite the heroic, constant torrent of diagnostic fixes by Paolo, Marek and others, I have not seen much progress on the key infrastructure issues in the roadmap (https://gcc.gnu.org/wiki/Better_Diagnostics). We have had at least one major item per release since GCC 4.5, but I don't see any particular item being tackled for GCC 5.0." Having initial support for fix-it hints in GCC 5.0 would be nice. Future versions of, for example, Emacs, could already make use of the fix-it hints to automatically apply fixes, even if the number of hints we give in GCC 5.0 is very limited. Finally, there are patches from new contributors waiting for feedback: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02662.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01980.html Cheers, Manuel.
Re: how to keep a hard register across multiple instrutions?
On 10/31/14 16:01, David Kang wrote: Hi, I'm newbie in gcc porting. The architecture that I'm porting gcc has hardware FPU. But the compiler has to generate code which builds a FPU instruction in a integer register at run-time and writes the value to the FPU command register. To make a single FPU instruction, three instructions are needed. Two instructions make the FPU instruction in 32 bit (cmd, operands[2], operands[1], operands[0]) format. Here operands are the FPU register numbers, which can be 0 ~ 32. As an example, f3 = f1 + 2 can be encoded as (code of 'add', 2, 1, 3). And the third instruction write it to a FPU command register. The architecture can issue up to 3 instructions at a time. The difficulty lies in that we need to know the FPU register number for those operands to generate the FPU instruction. The easiest but lowest performance implementation is to generate those three instruction from a single "define_insn" as three consecutive instructions. However, we lose all possible bundling of those 3 instructions with other instructions for optimization. So, I'm trying to find a better way. I used "define_insn_and_split" and split a single FPU instruction into 3 instructions like this: (Here I assume to use register r10, but it can be any integer register.) operands[0] = plus (operands[1], operands[2]) ==> (1) r10 <- lower half of FPU instruction using (code of 'add', operands[0], operands[1], operands[2]) (2) r10 <- r10 | upper half of FPU instruction using (code of 'add', operands[0], operands[1], operands[2]) (3) (FPU cmd register) <- r10 The problem is that gcc catches that operands[0] is used before the 3rd instruction, and allocates two different hard registers for (1,2) instructions and (3) instruction. So, when the code is generated, the first two instructions are assuming wrong register for operands[0]. This happens especially frequently when '-unroll' option is used. So, I think if there is a way to inform gcc to use the same hard registers for operands[0] across those three instructions. Is it possible? Or would there be any better way to generate efficient FPU code? I will appreciate any advice or pointer to further information. Use a define_insn_and_split, but only split it after register allocation & reloading. Jeff
Enabling -fextended-identifiers by default
I propose enabling -fextended-identifiers by default for the appropriate standard versions (i.e. all C++ versions, C99 and above for C - so enabled by default for C now the default C version is gnu11). Any comments or objections? The following is my list of desirable improvements in the existing -fextended-identifiers support or testcases for it, but I don't think these issues need to stop it from being enabled by default. * C -aux-info. * ObjC -gen-decls. * Use DW_AT_use_UTF8 in DWARF-3 debug info for compilation units built with extended identifiers enabled (or unconditionally). * cpplib spelling preservation; correct output for -d (UCNs), DWARF debug info for macros (UCNs), PCH and PCH tests. * cpplib diagnostics (outputting characters or UCNs as appropriate depending on the locale, as done for identifiers in non-cpplib diagnostics). * C++ test for UCN linking with C and extern "C". * Testcase for pp-numbers containing UCNs, $ or other equivalent characters. * Debug info generation tests (at least add -g to existing tests, plus UCNs for fields / struct tags / enum values / goto labels / macros -g3). * C++ translation of extended characters (including $@` and various control characters) to UCNs in phase 1 (note diagnostics thus needed, but not for C++11, for control characters in strings / character constants as those UCNs invalid). * Actual UTF-8 in identifiers (?). -- Joseph S. Myers jos...@codesourcery.com
Re: Recent go changes broke alpha bootstrap
On Thu, Oct 30, 2014 at 08:05:14AM -0700, Ian Taylor wrote:
> On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt wrote:
> > I'm not quite sure about the best approach. The attempt to
> > represent C unions in the "right" way is ultimately futile as Go
> > does not have the types necessary for it. For example, the
> > handling of anonymous bit fields will never be right as it's
> > undefinied. On the other hand I could fix the issue at hand by
> > changing the way anonymous unions are represented in Go.
> >
> > Example:
> >
> > struct { int8_t x; union { int16_t y; int 32_t z; }; };
> >
> > Was represented (before the patch) as
> >
> > struct { X byte; int16 Y; }
> >
> > which had size 4, alignment 2 and y at offset 2 but should had
> > have size 8, alignment 4 and y at offset 4. With the current
> > patch the Go layout is
> >
> > struct { X byte; artificial_name struct { y [2]byte; align [0]int32; } }
> >
> > with the proper size, alignment and offset, but y is addressed as
> > ".artificial_name.y" insted of just ".y", and y is a byte array
> > and not an int16.
> >
> > I could remove the "artificial_name struct" and add padding before
> > and after y instead:
> >
> > struct { X byte; pad_0 [3]byte; Y int16; pad_1 [2]byte; align [0]int32; }
> >
> > What do you think?
>
> Sounds good to me. Basically the fields of the anonymous union should
> be promoted to become fields of the struct. We can't do it in
> general, but we can do it for the first field. That addresses the
> actual uses of anonymous unions.
The attached patch fixes this, at least if the first element of the
union is not a bitfield.
Bitfields can really not be represented properly in Go (think about
constructs like "struct { int : 1; int bf : 1; }"), I'd rather not
try to represent them in a predictable way. The patched code may
or may not give them a name, and reserves the proper amount of
padding where required in structs. If a union begins with an
anonymous bitfield (which makes no sense), that is ignored. If a
union begins with a named bitfield (possibly after unnamed ones),
this may or may not be used as the (sole) element of the Go
struct.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
>From 52d6792fb89a2f2beb2b897c7794b30245400e61 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 3 Nov 2014 17:49:33 +0100
Subject: [PATCH 1/2] godump: "Fix" handling of anonymous structs and unions.
Remove the "struct { ... }" around them as was the case before.
Note that bitfields are note handled in any predictable way. They may be
replaced by padding or not, and a union beginning with a bitfield may use the
bitfield in the Go struct or may use the first non-bitfield element of the
union. This is not really fixable.
---
gcc/godump.c| 183 +++
gcc/testsuite/gcc.misc-tests/godump-1.c | 849 +++-
2 files changed, 697 insertions(+), 335 deletions(-)
diff --git a/gcc/godump.c b/gcc/godump.c
index fccd3eb..7c386c4 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -678,11 +678,13 @@ go_force_record_alignment (struct obstack *ob, const char *type_string,
static bool
go_format_type (struct godump_container *container, tree type,
- bool use_type_name, bool is_func_ok, unsigned int *p_art_i)
+ bool use_type_name, bool is_func_ok, unsigned int *p_art_i,
+ bool is_anon_record_or_union)
{
bool ret;
struct obstack *ob;
unsigned int art_i_dummy;
+ bool is_union = false;
if (p_art_i == NULL)
{
@@ -856,7 +858,7 @@ go_format_type (struct godump_container *container, tree type,
else
{
if (!go_format_type (container, TREE_TYPE (type), use_type_name,
- true, NULL))
+ true, NULL, false))
ret = false;
}
break;
@@ -882,15 +884,19 @@ go_format_type (struct godump_container *container, tree type,
obstack_1grow (ob, '0');
obstack_1grow (ob, ']');
if (!go_format_type (container, TREE_TYPE (type), use_type_name, false,
- NULL))
+ NULL, false))
ret = false;
break;
+case UNION_TYPE:
+ is_union = true;
+ /* Fall through to RECORD_TYPE case. */
case RECORD_TYPE:
{
unsigned int prev_field_end;
- unsigned int most_strict_known_alignment;
+ unsigned int known_alignment;
tree field;
+ bool emitted_a_field;
/* FIXME: Why is this necessary? Without it we can get a core
dump on the s390x headers, or from a file containing simply
@@ -898,51 +904,77 @@ go_format_type (struct godump_container *container, tree type,
layout_type (type);
prev_field_end = 0;
- most_strict_known_alignment = 1;
- obstack_grow (ob, "struct { ", 9);
- for (field = TYPE_FIELDS (type);
+ known_alignment = 1;
+ /* Anonymous records and unions are flattened, i.e. they are not put
+ into "struct { ... }". */
+ if (!is_anon_record_or_union)
+ obstack_grow (ob, "struct { ", 9);
+ for (field = TYPE_FIELDS (type), emitted_a_field = false;
field != NULL_TREE;
fiel
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
.. other than the above issue, I see a segmentation fault for: performance/ext/pb_ds/multimap_text_insert_mem_large.cc and a compile error for: performance/ext/pb_ds/priority_queue_text_pop_mem.cc which boils down to a an error at include/bits/stl_deque.h:519 (likely pd_ds is misusing std::deque). Jon, can you double check the latter? Thanks, Paolo.
Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th
On Mon, 2014-11-03 at 10:18 +0100, Jakub Jelinek wrote: > Status > == > > The trunk is scheduled to transition from Stage 1 to Stage 3 at the end > of Saturday, November 15th (use your timezone to your advantage). > > We have been in Stage 1 for almost 7 months now with a fortnight > > still to go. Still now is a good time to look into bugzilla > and pick one or two regressions in your area of expertise and fix them > (you may want to prioritize regressions against both 4.9 and 5). > > What larger merges are still planned for GCC 5? > I'm aware of pending merges from match-and-simplify branch, there > are the JIT changes partially? approved, MPX also partially? approved, > Intel offloading patches partially approved, PTX support partially > reviewed. Thomas, do you plan to post OpenACC changes for review > still during stage1? Do you have any dependencies there (PTX and/or > Intel offloading being merged first?)? What else have been people working > on and can get posted for review before stage1 closes? > As before, when new features are posted for review during stage 1 and only > acked early during stage 3, they can still be accepted for GCC 5. As well as the JIT work, I'm hoping to merge the "dmalcolm/gimple-classes" git branch, which makes moves gimple statement accessor typechecking from runtime to compile time, by making use of gimple subclasses: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01380.html This is a big patch, currently: 152 files changed, 11166 insertions(+), 4806 deletions(-) and a followup part of it involves renaming every "gimple" to be a "gimple *". Richi said (in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01536.html ): > I think timing-wise you should now have the burden to wait > for the end of stage1 (and thus all pending big merges). I'm > fine doing this refactoring very early in stage3. I also have some mostly-done RTL subclass work which I hope to post before stage1 closes (using rtx_insn * in some more places; about another 20 or so patches). FWIW I've been investigating generalizing the JIT API to also be usable as a stable API for plugins (i.e. both extending *and* embedding from the same API), but at the moment I don't think that work is going to be ready in time for stage1 close. Dave
Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th
On 3 November 2014 09:18, Jakub Jelinek wrote: > Status > == > > The trunk is scheduled to transition from Stage 1 to Stage 3 at the end > of Saturday, November 15th (use your timezone to your advantage). > > We have been in Stage 1 for almost 7 months now with a fortnight > still to go. Still now is a good time to look into bugzilla > and pick one or two regressions in your area of expertise and fix them > (you may want to prioritize regressions against both 4.9 and 5). > > What larger merges are still planned for GCC 5? In libstdc++ I'll be committing the new std::string implementation before stage 1 ends and I posted my Filesystem TS implementation for review months ago, I have one makefile/dejagnu thing to resolve before that can be committed.
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
On 3 November 2014 17:51, Paolo Carlini wrote: > .. other than the above issue, I see a segmentation fault for: > > performance/ext/pb_ds/multimap_text_insert_mem_large.cc > > and a compile error for: > > performance/ext/pb_ds/priority_queue_text_pop_mem.cc > > which boils down to a an error at include/bits/stl_deque.h:519 (likely pd_ds > is misusing std::deque). Jon, can you double check the latter? Looking.
Re: how to keep a hard register across multiple instrutions?
Thank you for the tips. I tried the following condition for split. "reload_completed && FP_REG_P (operands[0])" But, the registers are still changed. How can I specify "after register allocation" in the split condition? Thanks, David - Original Message - > From: "Jeff Law" > To: "David Kang" , gcc@gcc.gnu.org > Sent: Monday, November 3, 2014 11:21:58 AM > Subject: Re: how to keep a hard register across multiple instrutions? > On 10/31/14 16:01, David Kang wrote: > > > > Hi, > > > > I'm newbie in gcc porting. > > > > The architecture that I'm porting gcc has hardware FPU. > > But the compiler has to generate code which builds a FPU instruction > > in a integer register > > at run-time and writes the value to the FPU command register. > > > > To make a single FPU instruction, three instructions are needed. > > Two instructions make the FPU instruction in 32 bit (cmd, > > operands[2], operands[1], operands[0]) format. > > Here operands are the FPU register numbers, which can be 0 ~ 32. > > As an example, f3 = f1 + 2 can be encoded as (code of 'add', 2, 1, > > 3). > > > > And the third instruction write it to a FPU command register. > > The architecture can issue up to 3 instructions at a time. > > > > The difficulty lies in that we need to know the FPU register > > number > > for those operands to generate the FPU instruction. > > > > The easiest but lowest performance implementation is to generate > > those three instruction > > from a single "define_insn" as three consecutive instructions. > > However, we lose all possible bundling of those 3 instructions with > > other instructions for optimization. > > > > So, I'm trying to find a better way. > > I used "define_insn_and_split" and split a single FPU instruction > > into 3 instructions like this: > > (Here I assume to use register r10, but it can be any integer > > register.) > > > > operands[0] = plus (operands[1], operands[2]) > > > > ==> > > > > (1) r10 <- lower half of FPU instruction using > >(code of 'add', operands[0], operands[1], operands[2]) > > > > (2) r10 <- r10 | upper half of FPU instruction using (code of 'add', > > operands[0], operands[1], operands[2]) > > > > (3) (FPU cmd register) <- r10 > > > > > > The problem is that gcc catches that operands[0] is used before > > the 3rd instruction, > > and allocates two different hard registers for (1,2) instructions > > and (3) instruction. > > So, when the code is generated, the first two instructions are > > assuming wrong register > > for operands[0]. > > This happens especially frequently when '-unroll' option is used. > > > > So, I think if there is a way to inform gcc to use the same hard > > registers for > > operands[0] across those three instructions. > > Is it possible? > > > > Or would there be any better way to generate efficient FPU code? > > I will appreciate any advice or pointer to further information. > Use a define_insn_and_split, but only split it after register > allocation > & reloading. > > Jeff -- -- Dr. Dong-In "David" Kang Computer Scientist USC/ISI
Re: how to keep a hard register across multiple instrutions?
On 3 November 2014 21:51, David Kang wrote: > > Thank you for the tips. > I tried the following condition for split. > > "reload_completed && FP_REG_P (operands[0])" > > But, the registers are still changed. > How can I specify "after register allocation" in the split condition? Are you sure that your problem is that the split is too early, or could you suffering from later register renumbering? You can get a set of dump files for all rtl passes by adding the -da option to gcc / cc1, so that you can see exactly when things go wrong. I would suspect the register renaming pass causing you trouble. You might have to define HARD_REGNO_RENAME_OK suitably for your target.
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
On 3 November 2014 17:51, Paolo Carlini wrote: > .. other than the above issue, I see a segmentation fault for: > > performance/ext/pb_ds/multimap_text_insert_mem_large.cc > > and a compile error for: > > performance/ext/pb_ds/priority_queue_text_pop_mem.cc > > which boils down to a an error at include/bits/stl_deque.h:519 (likely pd_ds > is misusing std::deque). Jon, can you double check the latter? I think it's a bug I introduced to std::deque -- I'm assuming that MoveConstructible allocators are also MoveAssignable, which is not a valid assumption. I'll fix it.
Re: Enabling -fextended-identifiers by default
On 11/03/14 09:24, Joseph Myers wrote: I propose enabling -fextended-identifiers by default for the appropriate standard versions (i.e. all C++ versions, C99 and above for C - so enabled by default for C now the default C version is gnu11). Any comments or objections? No objections here. jeff
Re: Recent go changes broke alpha bootstrap
On Mon, Nov 3, 2014 at 9:02 AM, Dominik Vogt wrote:
> On Thu, Oct 30, 2014 at 08:05:14AM -0700, Ian Taylor wrote:
>> On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt
>> wrote:
>> > I'm not quite sure about the best approach. The attempt to
>> > represent C unions in the "right" way is ultimately futile as Go
>> > does not have the types necessary for it. For example, the
>> > handling of anonymous bit fields will never be right as it's
>> > undefinied. On the other hand I could fix the issue at hand by
>> > changing the way anonymous unions are represented in Go.
>> >
>> > Example:
>> >
>> > struct { int8_t x; union { int16_t y; int 32_t z; }; };
>> >
>> > Was represented (before the patch) as
>> >
>> > struct { X byte; int16 Y; }
>> >
>> > which had size 4, alignment 2 and y at offset 2 but should had
>> > have size 8, alignment 4 and y at offset 4. With the current
>> > patch the Go layout is
>> >
>> > struct { X byte; artificial_name struct { y [2]byte; align [0]int32; } }
>> >
>> > with the proper size, alignment and offset, but y is addressed as
>> > ".artificial_name.y" insted of just ".y", and y is a byte array
>> > and not an int16.
>> >
>> > I could remove the "artificial_name struct" and add padding before
>> > and after y instead:
>> >
>> > struct { X byte; pad_0 [3]byte; Y int16; pad_1 [2]byte; align [0]int32; }
>> >
>> > What do you think?
>>
>> Sounds good to me. Basically the fields of the anonymous union should
>> be promoted to become fields of the struct. We can't do it in
>> general, but we can do it for the first field. That addresses the
>> actual uses of anonymous unions.
>
> The attached patch fixes this, at least if the first element of the
> union is not a bitfield.
>
> Bitfields can really not be represented properly in Go (think about
> constructs like "struct { int : 1; int bf : 1; }"), I'd rather not
> try to represent them in a predictable way. The patched code may
> or may not give them a name, and reserves the proper amount of
> padding where required in structs. If a union begins with an
> anonymous bitfield (which makes no sense), that is ignored. If a
> union begins with a named bitfield (possibly after unnamed ones),
> this may or may not be used as the (sole) element of the Go
> struct.
Thanks. I committed your patch.
Ian
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
On 03/11/14 17:19 +0100, Paolo Carlini wrote:
Hi,
On 11/03/2014 03:55 PM, Rainer Emrich wrote:
Since the recent changes to the testsuites the folowing make targets in the
libstdc++ testsuite directory don't work anymore:
check-parallel
check-performance
check-performance-parallel
Any comments?
All I can see so far is a non-conforming use of default arguments (ie,
repeated in the function template definitions) in
include/parallel/algo.h, which the front-end didn't catch until quite
recently (not in 4.9.x). See below what I mean to apply to fix that.
Not sure if you meant something else (too) in your terse message,
tough.
has the same problem, fixed with this patch.
commit 356183f393d2fce9beb5b2d4772b9f8ab83280cd
Author: Jonathan Wakely
Date: Tue Nov 4 03:33:07 2014 +
* include/parallel/numeric.h: Do not use default arguments in function
template redeclarations (definitions).
diff --git a/libstdc++-v3/include/parallel/numeric b/libstdc++-v3/include/parallel/numeric
index 8254635..e89f27e 100644
--- a/libstdc++-v3/include/parallel/numeric
+++ b/libstdc++-v3/include/parallel/numeric
@@ -85,8 +85,7 @@ namespace __parallel
__accumulate_switch(__RAIter __begin, __RAIter __end,
_Tp __init, _BinaryOperation __binary_op,
random_access_iterator_tag,
- __gnu_parallel::_Parallelism __parallelism_tag
- = __gnu_parallel::parallel_unbalanced)
+ __gnu_parallel::_Parallelism __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION(
static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)
@@ -193,8 +192,7 @@ namespace __parallel
_BinaryFunction2 __binary_op2,
random_access_iterator_tag,
random_access_iterator_tag,
- __gnu_parallel::_Parallelism __parallelism_tag
- = __gnu_parallel::parallel_unbalanced)
+ __gnu_parallel::_Parallelism __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION((__last1 - __first1)
>= __gnu_parallel::_Settings::get().
@@ -419,8 +417,7 @@ namespace __parallel
random_access_iterator_tag,
random_access_iterator_tag,
__gnu_parallel::_Parallelism
- __parallelism_tag
- = __gnu_parallel::parallel_balanced)
+ __parallelism_tag)
{
if (_GLIBCXX_PARALLEL_CONDITION(
static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
On 03/11/14 22:07 +, Jonathan Wakely wrote:
On 3 November 2014 17:51, Paolo Carlini wrote:
.. other than the above issue, I see a segmentation fault for:
performance/ext/pb_ds/multimap_text_insert_mem_large.cc
and a compile error for:
performance/ext/pb_ds/priority_queue_text_pop_mem.cc
which boils down to a an error at include/bits/stl_deque.h:519 (likely pd_ds
is misusing std::deque). Jon, can you double check the latter?
I think it's a bug I introduced to std::deque -- I'm assuming that
MoveConstructible allocators are also MoveAssignable, which is not a
valid assumption. I'll fix it.
Fixed by this patch, committed to trunk.
commit f84f372dceab9cd9401caf326f942557e8ccfcac
Author: Jonathan Wakely
Date: Tue Nov 4 03:16:55 2014 +
Do not assume allocator is assignable.
* include/bits/stl_deque.h (_Deque_base(_Deque_base&&)): Copy
allocator instead of moving.
* testsuite/23_containers/deque/allocator/move-2.cc: New.
diff --git a/libstdc++-v3/include/bits/stl_deque.h b/libstdc++-v3/include/bits/stl_deque.h
index acb7715..d50d3c90 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -503,23 +503,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
#if __cplusplus >= 201103L
_Deque_base(_Deque_base&& __x)
- : _M_impl(std::move(__x._M_get_Tp_allocator()))
+ : _M_impl(__x._M_get_Tp_allocator())
{
+ _M_initialize_map(0);
if (__x._M_impl._M_map)
- {
- this->_M_impl._M_swap_data(__x._M_impl);
- __try
- {
- // Re-initialize __x using its moved-from allocator.
- __x._M_initialize_map(0);
- }
- __catch (...)
- {
- this->_M_impl._M_swap_data(__x._M_impl);
- __x._M_get_Tp_allocator() = std::move(_M_get_Tp_allocator());
- __throw_exception_again;
- }
- }
+ this->_M_impl._M_swap_data(__x._M_impl);
}
_Deque_base(_Deque_base&& __x, const allocator_type& __a, size_type __n)
diff --git a/libstdc++-v3/testsuite/23_containers/deque/allocator/move-2.cc b/libstdc++-v3/testsuite/23_containers/deque/allocator/move-2.cc
new file mode 100644
index 000..3932676
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/allocator/move-2.cc
@@ -0,0 +1,53 @@
+// 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
+//
Re: Enabling -fextended-identifiers by default
On 11/03/2014 10:24 AM, Joseph Myers wrote: I propose enabling -fextended-identifiers by default for the appropriate standard versions (i.e. all C++ versions, C99 and above for C - so enabled by default for C now the default C version is gnu11). Any comments or objections? Yes, I've been thinking that we should do that. Jason
Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore
On 04/11/14 03:41 +, Jonathan Wakely wrote:
On 03/11/14 22:07 +, Jonathan Wakely wrote:
On 3 November 2014 17:51, Paolo Carlini wrote:
.. other than the above issue, I see a segmentation fault for:
performance/ext/pb_ds/multimap_text_insert_mem_large.cc
Fixed like so.
commit 75a3f132da320a76baf7e82f4f850cdfce239a2e
Author: Jonathan Wakely
Date: Tue Nov 4 04:33:32 2014 +
* testsuite/util/testsuite_allocator.h (operator==): Fix recursion.
diff --git a/libstdc++-v3/testsuite/util/testsuite_allocator.h b/libstdc++-v3/testsuite/util/testsuite_allocator.h
index 8edc0a5..dec8d1a 100644
--- a/libstdc++-v3/testsuite/util/testsuite_allocator.h
+++ b/libstdc++-v3/testsuite/util/testsuite_allocator.h
@@ -209,7 +209,7 @@ namespace __gnu_test
{
const Alloc1& alloc1 = lhs;
const Alloc2& alloc2 = rhs;
- return lhs == rhs;
+ return alloc1 == alloc2;
}
template
