Re: [PATCH] Fix array sizes created by Java FE (PR libgcj/57074)
On Sat, May 04, 2013 at 09:33:34AM +0930, Alan Modra wrote:
> On Fri, May 03, 2013 at 07:10:15PM +0200, Jakub Jelinek wrote:
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, but
> > not tested on powerpc32 where it actually caused runtime issues, can
> > somebody please try it there? Ok for trunk/4.8?
>
> /home/amodra/build/gcc-current/./gcc/gcj
> -B/home/amodra/build/gcc-current/powerpc-linux/64/libjava/
> -B/home/amodra/build/gcc-current/powerpc-linux/64/libjava/
> -B/home/amodra/build/gcc-current/./gcc/ -B/home/amodra/gnu/powerpc-linux/bin/
> -B/home/amodra/gnu/powerpc-linux/lib/ -isystem
> /home/amodra/gnu/powerpc-linux/include -isystem
> /home/amodra/gnu/powerpc-linux/sys-include -m64 -fclasspath=
> -fbootclasspath=/home/amodra/src/gcc-current/libjava/classpath/lib
> --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64
> -fsource-filename=/home/amodra/build/gcc-current/powerpc-linux/64/libjava/classpath/lib/classes
> -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list -fPIC -o
> .libs/gnu-CORBA.o -v -save-temps
>
> Looks like this is not the only problem. Using the attached patch to
> verify section anchor block layout leads me to
>
> .org .LANCB76+23560
> .type _atable_syms_gnu_CORBA_NamingService_NameValidator, @object
> .size _atable_syms_gnu_CORBA_NamingService_NameValidator, 96
> _atable_syms_gnu_CORBA_NamingService_NameValidator:
> .quad _Utf42
> .quad _Utf34
> .quad _Utf35
> .quad _Utf3318.82185
> .quad _Utf34
> .quad _Utf170
> .quad _Utf293
> .quad _Utf34
> .quad _Utf170
> .quad 0
> .quad 0
> .quad 0
> .org .LANCB76+23608
>
> The difference between .org's is 48, but the actual size 96. The next
> _atable in this file shows 48/72.
Ah right, build_decl (in gen_indirect_dispatch_tables (GET_TABLE macro))
calls layout_decl immediately, so when the type changes soon afterwards,
while TYPE_SIZE{,_UNIT} is correct, DECL_SIZE{,_UNIT} isn't.
Can you try this? Just the relayout_decl call has been added...
An alternative would be to create symbols_array_type as an ARRAY_TYPE
with just low bound 0 and no upper bound, guess then build_decl wouldn't set
a DECL_SIZE for it, or rework the code so that it creates this decl only
in emit_symbols_table rather than in gen_indirect_dispatch_tables.
But I hope this should work fine too, emit_symbol_table is called very soon
in the compilation so nothing should be e.g. creating RTL for the decls at
that point.
2013-05-04 Jakub Jelinek
PR libgcj/57074
* class.c (emit_symbol_table): Use array type of the
right size for the_syms_decl and its DECL_INITIAL, instead
of symbols_array_type. Set TREE_TYPE (the_syms_decl) to it.
(emit_assertion_table): Use array type of the right size
for table_decl and its DECL_INITIAL.
--- gcc/java/class.c.jj 2013-01-11 09:02:30.0 +0100
+++ gcc/java/class.c2013-05-02 20:38:13.848886817 +0200
@@ -2958,9 +2958,14 @@ emit_symbol_table (tree name, tree the_t
null_pointer_node);
CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, null_symbol);
- table = build_constructor (symbols_array_type, v);
+ tree symbols_arr_type
+= build_prim_array_type (symbol_type, vec_safe_length (v));
+
+ table = build_constructor (symbols_arr_type, v);
/* Make it the initial value for otable_syms and emit the decl. */
+ TREE_TYPE (the_syms_decl) = symbols_arr_type;
+ relayout_decl (the_syms_decl);
DECL_INITIAL (the_syms_decl) = table;
DECL_ARTIFICIAL (the_syms_decl) = 1;
DECL_IGNORED_P (the_syms_decl) = 1;
@@ -3109,12 +3114,15 @@ emit_assertion_table (tree klass)
null_pointer_node);
CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, null_entry);
+
+ tree type
+= build_prim_array_type (assertion_entry_type, vec_safe_length (v));
- ctor = build_constructor (assertion_table_type, v);
+ ctor = build_constructor (type, v);
table_decl = build_decl (input_location,
VAR_DECL, mangled_classname ("_type_assert_", klass),
- assertion_table_type);
+ type);
TREE_STATIC (table_decl) = 1;
TREE_READONLY (table_decl) = 1;
Jakub
Re: [PATCH] Fix array sizes created by Java FE (PR libgcj/57074)
> I believe the real problem here is in place_block_symbol() and > output_object_block(). If DECL_INITIAL is given for an array, then > shouldn't we be taking the size from the initializer? This means that the size of the array and the size of the initializer don't agree, right? IMO this should be fixed instead since this could run afoul of various optimizations using array_ref_up_bound for example. -- Eric Botcazou
Re: [PATCH] Improve simplify_subreg
Jakub Jelinek writes: > On Thu, May 02, 2013 at 06:53:31PM +0100, Richard Sandiford wrote: >> Jakub Jelinek writes: >> > When working on PR57130, I've wondered why we don't simplify it much >> > earlier >> > and end up with creating such weirdness. >> > >> > The following patch fixes that, by using nonzero_bits to see if all the low >> > bits must be zero and in that case just return zero. >> > >> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >> > >> > 2013-05-02 Jakub Jelinek >> > >> >* simplify-rtx.c (simplify_truncation): If nonzero_bits >> >on op shows all bits zero in mode, return zero. >> >> I'm probably wrong, but just in case: it looks like this might >> fall foul of: >> >> /* Try to simplify a MODE truncation of OP, which has OP_MODE. >>Only handle cases where the truncated value is inherently an rvalue. >> >> If op is a register, it might be being used as an lvalue instead of an >> rvalue. >> We don't want to simplify (subreg (reg ..)) to (const_int 0) in that case. >> >> It should be OK to put this under the TRUNCATE case in >> simplify_unary_operation_1, but I don't know if that'd be good >> enough for your testcase. > > I understand, if simplify_subreg would be called on LHS, that would be a bad > transformation. Unfortunately, simplify_rtx isn't called on the testcase > and there isn't a TRUNCATE, just a SUBREG, so simplify_unary_operation_1 > wouldn't be the right spot for it anyway. > > What about this? Is combine_simplify_rtx only called on rvalues? Both lvalues and rvalues I think, but at least in_dest says which. The patch looks good to me with an "&& !in_dest". Thanks, Richard
Re: [Patch, Fortran] PR57142 - Fix simplify for SHAPE and SIZE for large arrays
Hi Tobias, Instead of using the return "size" value directly, the code converted it first to an int and then back into a GMP number. This patch now directly uses the mpz value. Additionally, I added range checks - to print the proper function name (SHAPE instead of SIZE), I split the worker code from the checking code. Build and regtested on x86-64-gnu-linux. OK for the trunk and the 4.7/4.8 branches? OK for all. Thanks for the patch! Thomas
Re: [patch, mips] Allow users to avoid promoting prototypes.
Steve Ellcey writes: > On Thu, 2013-05-02 at 23:26 +0100, Richard Sandiford wrote: >> > 2013-05-02 Steve Ellcey >> > >> >* config/mips/mips.c (mips_promote_prototypes) :New. >> >(TARGET_PROMOTE_PROTOTYPES): Change to use mips_promote_prototypes. >> >* config/mips/mips.opt (mpromote-prototypes): New. >> >> It'd need an invoke.texi change too. >> >> The ABI thing is a problem though. Unlike the recent -mimadd option, >> this isn't something a user could reasonably turn on and off for >> individual files to see what happens. They'd need to rebuild all >> their libraries with it. And as written, the patch provides no way >> to compile gcc's own libraries that way, so they'd need to patch the >> gcc sources locally. > > I wasn't looking at providing an extra set of libraries, my assumption > was that the libraries would be compiled with the default setting of > promoting prototypes they way they are now and that these would still > work with objects that were compiled with -mno-promote-prototypes. The problem is that TARGET_PROMOTE_PROTOTYPES is both a requirement on the caller and a guarantee to the callee. Any library function that takes a sub-int type is allowed to assume that the type is passed in extended form, and might be making use of that. And typedefs can make it less obvious which types are sub-int and which aren't. >> Ideally we'd also have a .gnu_attribute to record which promotion >> rules are being used, so that the linker can pick up incompatibilities. >> >> Sorry to be a pain... >> >> Thanks, >> Richard > > That's alright, I will drop this idea for now and perhaps look at > Richard Biener's idea (optimizing out the promotion on local calls) > later. Thanks, going with Richard's suggestion sounds good. Richard
[wwwdocs] Buildstat update for 4.8
Latest results for gcc 4.8.x. -tgc Testresults for 4.8.0 hppa64-hp-hpux11.00 i686-pc-linux-gnu powerpc-apple-darwin8.11.0 powerpc-ibm-aix6.1.0.0 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v retrieving revision 1.2 diff -u -r1.2 buildstat.html --- buildstat.html 15 Apr 2013 11:33:33 - 1.2 +++ buildstat.html 4 May 2013 09:49:35 - @@ -47,6 +47,14 @@ +hppa64-hp-hpux11.00 + +Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg00457.html";>4.8.0 + + + + hppa64-hp-hpux11.11 Test results: @@ -87,6 +95,14 @@ +i686-pc-linux-gnu + +Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg03091.html";>4.8.0 + + + + mipsel-unknown-linux-gnu Test results: @@ -95,6 +111,14 @@ +powerpc-apple-darwin8.11.0 + +Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01012.html";>4.8.0 + + + + powerpc-apple-darwin9.8.0 Test results: @@ -103,6 +127,14 @@ +powerpc-ibm-aix6.1.0.0 + +Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg00961.html";>4.8.0 + + + + powerpc-unknown-linux-gnu Test results:
[wwwdocs] Buildstat update for 4.7
Latest results for gcc 4.7.x. -tgc Testresults for 4.7.3 arm-unknown-linux-gnueabi i386-pc-solaris2.8 i686-pc-linux-gnu (2) mips-sgi-irix6.5 powerpc-apple-darwin8.11.0 sparc-sun-solaris2.9 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/buildstat.html,v retrieving revision 1.8 diff -u -r1.8 buildstat.html --- buildstat.html 17 Feb 2013 19:35:36 - 1.8 +++ buildstat.html 4 May 2013 09:15:48 - @@ -54,6 +54,7 @@ arm-unknown-linux-gnueabi Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01400.html";>4.7.3, http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01105.html";>4.7.2 @@ -105,6 +106,7 @@ i386-pc-solaris2.8 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00269.html";>4.7.3, http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg01980.html";>4.7.2, http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg02064.html";>4.7.1, http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg01781.html";>4.7.1, @@ -144,6 +146,8 @@ i686-pc-linux-gnu Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg02958.html";>4.7.3, +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg02891.html";>4.7.3, http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01089.html";>4.7.2, http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg02518.html";>4.7.2, http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg00199.html";>4.7.1, @@ -153,6 +157,14 @@ +mips-sgi-irix6.5 + +Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01589.html";>4.7.3 + + + + mipsel-unknown-linux-gnu Test results: @@ -164,6 +176,7 @@ powerpc-apple-darwin8.11.0 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01530.html";>4.7.3, http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02736.html";>4.7.2, http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg01566.html";>4.7.1, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02890.html";>4.7.0 @@ -199,6 +212,7 @@ sparc-sun-solaris2.9 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00265.html";>4.7.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02620.html";>4.7.0
[wwwdocs] Buildstat update for 4.6
Latest results for gcc 4.6.x. -tgc Testresults for 4.6.4 i386-pc-solaris2.8 powerpc-apple-darwin8.11.0 sparc-sun-solaris2.9 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v retrieving revision 1.13 diff -u -r1.13 buildstat.html --- buildstat.html 3 Oct 2012 23:11:27 - 1.13 +++ buildstat.html 4 May 2013 08:23:23 - @@ -113,6 +113,7 @@ i386-pc-solaris2.8 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00268.html";>4.6.4, http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg02817.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html";>4.6.3, @@ -216,6 +217,7 @@ powerpc-apple-darwin8.11.0 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01893.html";>4.6.4, http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00497.html";>4.6.3, http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03272.html";>4.6.2, http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01092.html";>4.6.1 @@ -301,6 +303,7 @@ sparc-sun-solaris2.9 Test results: +http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00264.html";>4.6.4, http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02934.html";>4.6.0, http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02724.html";>4.6.0, http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02721.html";>4.6.0
Re: [PATCH] Fix array sizes created by Java FE (PR libgcj/57074)
On Sat, May 04, 2013 at 10:34:52AM +0200, Eric Botcazou wrote:
> > I believe the real problem here is in place_block_symbol() and
> > output_object_block(). If DECL_INITIAL is given for an array, then
> > shouldn't we be taking the size from the initializer?
>
> This means that the size of the array and the size of the initializer don't
> agree, right? IMO this should be fixed instead since this could run afoul of
> various optimizations using array_ref_up_bound for example.
Good to hear. I wasn't sure whether the sizes were even supposed to
agree. Assuming Jakub's second patch fixes java for us (testing now),
that just leaves gcc.c-torture/execute/20010924-1.c which fails to
size a3 and a4 properly. Both of these vars have DECL_SIZE_UNIT of 1.
struct {
char a3c;
char a3p[];
} a3 = {
'o',
"wx"
};
struct {
char a4c;
char a4p[];
} a4 = {
'9',
{ 'e', 'b' }
};
--
Alan Modra
Australia Development Lab, IBM
Re: [PATCH] Fix array sizes created by Java FE (PR libgcj/57074)
> Good to hear. I wasn't sure whether the sizes were even supposed to
> agree. Assuming Jakub's second patch fixes java for us (testing now),
> that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> size a3 and a4 properly. Both of these vars have DECL_SIZE_UNIT of 1.
>
> struct {
> char a3c;
> char a3p[];
> } a3 = {
> 'o',
> "wx"
> };
>
> struct {
> char a4c;
> char a4p[];
> } a4 = {
> '9',
> { 'e', 'b' }
> };
Flexible array members (or related GNU extensions) are a specific issue,
reported under PR middle-end/28865.
--
Eric Botcazou
Re: [PATCH] Fix array sizes created by Java FE (PR libgcj/57074)
On Sat, May 04, 2013 at 09:20:24AM +0200, Jakub Jelinek wrote: > 2013-05-04 Jakub Jelinek > > PR libgcj/57074 > * class.c (emit_symbol_table): Use array type of the > right size for the_syms_decl and its DECL_INITIAL, instead > of symbols_array_type. Set TREE_TYPE (the_syms_decl) to it. > (emit_assertion_table): Use array type of the right size > for table_decl and its DECL_INITIAL. This passes bootstrap and regression test on powerpc64-linux, with my .org validataion patch applied. Thanks! -- Alan Modra Australia Development Lab, IBM
Re: [PATCH] Fix array sizes created by Java FE (PR libgcj/57074)
On Sat, May 04, 2013 at 12:31:31PM +0200, Eric Botcazou wrote:
> > Good to hear. I wasn't sure whether the sizes were even supposed to
> > agree. Assuming Jakub's second patch fixes java for us (testing now),
> > that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> > size a3 and a4 properly. Both of these vars have DECL_SIZE_UNIT of 1.
> >
> > struct {
> > char a3c;
> > char a3p[];
> > } a3 = {
> > 'o',
> > "wx"
> > };
> >
> > struct {
> > char a4c;
> > char a4p[];
> > } a4 = {
> > '9',
> > { 'e', 'b' }
> > };
>
> Flexible array members (or related GNU extensions) are a specific issue,
> reported under PR middle-end/28865.
Actually when I look more closely, it was me taking the size from
DECL_INITIAL that caused these to fail. Interestingly, the var_decl
size is correct. I was wrong to claim it wasn't.
.org .LANCB1+0
.type a4, @object
.size a4, 1
a4:
.byte 57
.byte 101
.byte 98
.org .LANCB1+3
.type a3, @object
.size a3, 1
a3:
.byte 111
.string "wx"
.org .LANCB1+7
>From that, I see the .size is wrong (assemble_variable_contents() uses
DECL_INITIAL), but the size gleaned from the .org differences
(effectively from var_decl DECL_SIZE_UNIT) is correct.
--
Alan Modra
Australia Development Lab, IBM
[C++ testcase, committed] PR 51927
Hi,
committed to mainline.
Thanks,
Paolo.
//
2013-05-04 Paolo Carlini
PR c++/51927
* g++.dg/cpp0x/lambda/lambda-nsdmi4.C: New.
Index: g++.dg/cpp0x/lambda/lambda-nsdmi4.C
===
--- g++.dg/cpp0x/lambda/lambda-nsdmi4.C (revision 0)
+++ g++.dg/cpp0x/lambda/lambda-nsdmi4.C (working copy)
@@ -0,0 +1,14 @@
+// PR c++/51927
+// { dg-do compile { target c++11 } }
+
+struct function
+{
+ template
+ function(Functor);
+};
+
+struct testee
+{
+ function l1 = []() { };
+ function l2 = [=]() { l1; };
+};
[PATCH] Add implicit C linkage for win32-specific entry points
Hi,
This is another version of my old patch, changed to use target hooks as
requested by Steven Bosscher.
Tested on i686-w64-mingw32, x86_64-w64-mingw32 and
x86_64-unknown-linux-gnu, bootstrapped on x86_64-unknown-linux-gnu.
Disclaimer: the patch is in public domain.
(because I don't have copyright assignment done).
gcc/c-family/ChangeLog:
c-target.def: New hook
gcc/ChangeLog:
config/config.gcc: Use new winnt-c.c target hooks
config/t-winnt: New file
config/winnt-c.c: New file
doc/tm.texi.in: Document new hook
doc/tm.texi: Regenerated
gcc/cp/Changelog:
decl.c: Use new cxx_implicit_extern_c hook
gcc/testsuite/ChangeLog:
g++.dg/abi/main.C: Added implicit C linkage tests
---
gcc/c-family/c-target.def | 7 +++
gcc/config.gcc | 5 -
gcc/config/t-winnt | 22 ++
gcc/config/winnt-c.c| 39
+++
gcc/cp/decl.c | 5 -
gcc/doc/tm.texi | 4
gcc/doc/tm.texi.in | 2 ++
gcc/testsuite/g++.dg/abi/main.C | 24
8 files changed, 106 insertions(+), 2 deletions(-)
create mode 100644 gcc/config/t-winnt
create mode 100644 gcc/config/winnt-c.c
create mode 100644 gcc/testsuite/g++.dg/abi/main.C
diff --git a/gcc/c-family/c-target.def b/gcc/c-family/c-target.def
index 80042df..b9efae5 100644
--- a/gcc/c-family/c-target.def
+++ b/gcc/c-family/c-target.def
@@ -102,5 +102,12 @@ DEFHOOK
than just the compiler.",
const char *, (void),
hook_constcharptr_void_null)
+
+DEFHOOK
+(cxx_implicit_extern_c,
+ "Define this hook to add target-specific C++ implicit extern C functions.\
+ An example of such function is WinMain on Win32 targets.",
+ bool, (const char*),
+ NULL)
HOOK_VECTOR_END (C90_EMPTY_HACK)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5a205df..0cf61b0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1475,6 +1475,9 @@ x86_64-*-cygwin*)
i[34567]86-*-mingw* | x86_64-*-mingw*)
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h dbxcoff.h i386/cygming.h"
xm_file=i386/xm-mingw32.h
+ c_target_objs="${c_target_objs} winnt-c.o"
+ cxx_target_objs="${cxx_target_objs} winnt-c.o"
+ target_has_targetcm="yes"
case ${target} in
x86_64-*-* | *-w64-*)
need_64bit_isa=yes
@@ -1514,7 +1517,7 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
;;
esac
tm_file="${tm_file} i386/mingw-stdint.h"
- tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
+ tmake_file="${tmake_file} t-winnt i386/t-cygming t-slibgcc"
case ${target} in
x86_64-w64-*)
tmake_file="${tmake_file} i386/t-mingw-w64"
diff --git a/gcc/config/t-winnt b/gcc/config/t-winnt
new file mode 100644
index 000..4cc3339
--- /dev/null
+++ b/gcc/config/t-winnt
@@ -0,0 +1,22 @@
+# Copyright (C) 2004, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC 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.
+#
+# GCC 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 GCC; see the file COPYING3. If not see
+#
[C++ Patch] PR 53745
Hi,
in this issue (and its duplicate) the complain is that for cases like:
enum E : unsigned { e = -1 };
saying in the error message that the enumerator is *too large* can be
rather misleading. It seems to me that replacing that with "... outside
the range..." (we already use this form in at least another place) it's
a good improvement. ICC behave similarly, clang++ uses the more
technical "cannot be narrowed".
Tested x86_64-linux.
Thanks!
Paolo.
///
/cp
2013-05-04 Paolo Carlini
PR c++/53745
* decl.c (build_enumerator): Improve error message.
/testsuite
2013-05-04 Paolo Carlini
PR c++/53745
* g++.dg/cpp0x/enum27.C: New.
* g++.dg/cpp0x/enum_base.C: Adjust.
Index: cp/decl.c
===
--- cp/decl.c (revision 198593)
+++ cp/decl.c (working copy)
@@ -12847,8 +12847,8 @@ incremented enumerator value is too large for %",
- value, ENUM_UNDERLYING_TYPE (enumtype));
+ error ("enumerator value %E is outside the range of underlying "
+ "type %<%T%>", value, ENUM_UNDERLYING_TYPE (enumtype));
/* Convert the value to the appropriate type. */
value = convert (ENUM_UNDERLYING_TYPE (enumtype), value);
Index: testsuite/g++.dg/cpp0x/enum27.C
===
--- testsuite/g++.dg/cpp0x/enum27.C (revision 0)
+++ testsuite/g++.dg/cpp0x/enum27.C (working copy)
@@ -0,0 +1,4 @@
+// PR c++/53745
+// { dg-do compile { target c++11 } }
+
+enum E : unsigned { e = -1 }; // { dg-error "outside the range" }
Index: testsuite/g++.dg/cpp0x/enum_base.C
===
--- testsuite/g++.dg/cpp0x/enum_base.C (revision 198593)
+++ testsuite/g++.dg/cpp0x/enum_base.C (working copy)
@@ -6,11 +6,11 @@ enum E1 : char { };
enum E2 : signed const short { };
enum E3 : uvlonglong { };
enum E4 : char {
- val = 500 // { dg-error "too large" }
+ val = 500 // { dg-error "outside the range" }
};
enum class E5 {
- val = (unsigned long long)-1 // { dg-error "too large" }
+ val = (unsigned long long)-1 // { dg-error "outside the range" }
};
typedef float Float;
Re: mips SNaN/QNaN is swapped
Hi!
Ping.
On Mon, 29 Apr 2013 10:16:52 +0200, I wrote:
> Ping.
>
> On Mon, 22 Apr 2013 11:52:23 +0200, I wrote:
> > On Fri, 5 Apr 2013 23:55:37 +0100, "Maciej W. Rozycki"
> > wrote:
> > > On Fri, 5 Apr 2013, Thomas Schwinge wrote:
> > > > > Index: gcc/config/fp-bit.c
> > > > > ===
> > > > > RCS file: /cvs/uberbaum/gcc/config/fp-bit.c,v
> > > > > retrieving revision 1.39
> > > > > diff -u -p -r1.39 fp-bit.c
> > > > > --- gcc/config/fp-bit.c 26 Jan 2003 10:06:57 - 1.39
> > > > > +++ gcc/config/fp-bit.c 1 Apr 2003 21:35:00 -
> > > > > @@ -210,7 +210,11 @@ pack_d ( fp_number_type * src)
> > > > >exp = EXPMAX;
> > > > >if (src->class == CLASS_QNAN || 1)
> > > > > {
> > > > > +#ifdef QUIET_NAN_NEGATED
> > > > > + fraction |= QUIET_NAN - 1;
> > > > > +#else
> > > > > fraction |= QUIET_NAN;
> > > > > +#endif
> >
> > > I think the intent of this code is to preserve a NaN's payload (it
> > > certainly does for non-QUIET_NAN_NEGATED targets)
> >
> > I agree. For preserving the payload, both the unpack/pack code also has
> > to shift by NGARDS.
> >
> > > Complementing the change above I think it will also make
> > > sense to clear the qNaN bit when extracting a payload from fraction in
> > > unpack_d as the class of a NaN being handled is stored separately.
> >
> > I agree.
> >
> > > Also I find the "|| 1" clause in the condition immediately above the
> > > pack_d piece concerned suspicious -- why is a qNaN returned for sNaN
> > > input? Likewise why are __thenan_sf, etc. encoded as sNaNs rather than
> > > qNaNs? Does anybody know?
> >
> > I also stumbled over that, but for all these, I suppose the idea is that
> > when a sNaN is "arithmetically processed" (which includes datatype
> > conversion), an INVALID exception is to be raised (though, »[fp-bit]
> > implements IEEE 754 format arithmetic, but does not provide a mechanism
> > [...] for generating or handling exceptions«), and then converted into a
> > qNaN.
> >
> > Also, I found that the bit to look at for distinguishing qNaN/sNaN is
> > defined wrongly for float. Giving me some "interesting" test results...
> > ;-)
> >
> > Manual testing looks good. Automated testing is still running; in case
> > nothing turns up, is this OK to check in?
> >
> > libgcc/
> > * fp-bit.c (unpack_d, pack_d): Properly preserve and restore a
> > NaN's payload.
> > * fp-bit.h [FLOAT] (QUIET_NAN): Correct value.
> >
> > Index: libgcc/fp-bit.c
> > ===
> > --- libgcc/fp-bit.c (revision 402061)
> > +++ libgcc/fp-bit.c (working copy)
> > @@ -214,11 +214,18 @@ pack_d (const fp_number_type *src)
> >else if (isnan (src))
> > {
> >exp = EXPMAX;
> > + /* Restore the NaN's payload. */
> > + fraction >>= NGARDS;
> > + fraction &= QUIET_NAN - 1;
> >if (src->class == CLASS_QNAN || 1)
> > {
> > #ifdef QUIET_NAN_NEGATED
> > - fraction |= QUIET_NAN - 1;
> > + /* The quiet/signaling bit remains unset. */
> > + /* Make sure the fraction has a non-zero value. */
> > + if (fraction == 0)
> > + fraction |= QUIET_NAN - 1;
> > #else
> > + /* Set the quiet/signaling bit. */
> > fraction |= QUIET_NAN;
> > #endif
> > }
> > @@ -574,8 +581,10 @@ unpack_d (FLO_union_type * src, fp_number_type * d
> > {
> > dst->class = CLASS_SNAN;
> > }
> > - /* Keep the fraction part as the nan number */
> > - dst->fraction.ll = fraction;
> > + /* Now that we know which kind of NaN we got, discard the
> > +quiet/signaling bit, but do preserve the NaN payload. */
> > + fraction &= ~QUIET_NAN;
> > + dst->fraction.ll = fraction << NGARDS;
> > }
> > }
> >else
> > Index: libgcc/fp-bit.h
> > ===
> > --- libgcc/fp-bit.h (revision 402061)
> > +++ libgcc/fp-bit.h (working copy)
> > @@ -190,7 +190,7 @@ typedef unsigned int UTItype __attribute__ ((mode
> > # define EXPBIAS 127
> > # define FRACBITS 23
> > # define EXPMAX (0xff)
> > -# define QUIET_NAN 0x10L
> > +# define QUIET_NAN 0x40L
> > # define FRAC_NBITS 32
> > # define FRACHIGH 0x8000L
> > # define FRACHIGH2 0xc000L
> > @@ -298,7 +298,7 @@ typedef unsigned int UTItype __attribute__ ((mode
> > /* numeric parameters */
> > /* F_D_BITOFF is the number of bits offset between the MSB of the mantissa
> > of a float and of a double. Assumes there are only two float types.
> > - (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS-float::NGARDS))
> > + (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS+float::NGARDS))
> > */
> > #define F_D_BITOFF (52+8-(23+7))
> >
Grüße,
Thomas
pgpIo9CJzeTH9.pgp
Description: PGP signature
[PATCH] Fix libgconv.c warning
Compiling libgconv.c with gthr-single.h current generates warnings
because __GTHREAD_MUTEX_INIT_FUNCTION may be empty. The following
patch avoids the warnings.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
Thanks, David
* libgcov.c (__gcov_fork): Add ATTRIBUTE_UNUSED to __gcov_flush_mx.
Wrap possibly empty GTHREAD_MUTEX_INIT_FUNCTION in braces.
Index: libgcov.c
===
--- libgcov.c (revision 198587)
+++ libgcov.c (working copy)
@@ -1184,11 +1184,14 @@
__gcov_fork (void)
{
pid_t pid;
- extern __gthread_mutex_t __gcov_flush_mx;
+ /* __GTHREAD_MUTEX_INIT_FUNCTION may be empty. */
+ extern __gthread_mutex_t __gcov_flush_mx ATTRIBUTE_UNUSED;
__gcov_flush ();
pid = fork ();
if (pid == 0)
-__GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
+{
+ __GTHREAD_MUTEX_INIT_FUNCTION (&__gcov_flush_mx);
+}
return pid;
}
#endif
Re: [Patch, Fortran] Permit allocatable/pointer attributes with BIND(C)
Hi Tobias, TS29113 permits the allocatable/pointer attribute with BIND(C); this patch allows it now with -std=f2008ts. Build and regtested on x86-84-gnu-linux. OK for the trunk? OK. Thanks for the patch! Thomas
[committed] Fix up stdarg-6.c testcase
Hi!
Segher reported on IRC that stdarg-6.c testcase leaves *.stdarg files behind
it. Fixed thusly, committed to trunk/4.8 as obvious.
2013-05-04 Jakub Jelinek
PR tree-optimization/56205
* gcc.dg/tree-ssa/stdarg-6.c: Add cleanup-tree-dump "stdarg".
--- gcc/testsuite/gcc.dg/tree-ssa/stdarg-6.c.jj 2013-05-04 20:10:56.203322321
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/stdarg-6.c2013-05-04 20:10:12.049571078
+0200
@@ -33,3 +33,4 @@ bar (int x, char const *y, ...)
/* { dg-final { scan-tree-dump "bar: va_list escapes 1, needs to save all GPR
units" "stdarg" { target { { i?86-*-* x86_64-*-* } && ia32 } } } } */
/* { dg-final { scan-tree-dump "bar: va_list escapes 1, needs to save all GPR
units" "stdarg" { target ia64-*-* } } } */
/* { dg-final { scan-tree-dump "bar: va_list escapes 1, needs to save all GPR
units" "stdarg" { target { powerpc*-*-* && lp64 } } } } */
+/* { dg-final { cleanup-tree-dump "stdarg" } } */
Jakub
[PATCH 1/2] rs6000: Remove legacy HOST_BITS_PER_WIDE_INT < 64 code
We always have HOST_BITS_PER_WIDE_INT >= 64, so remove the code testing for == 32, and remove the tests testing for >= 64. Also remove the tests testing for == 64 that should really have been testing for >= 64. DImode constants are always CONST_INT, never CONST_DOUBLE. Simplify the old code that hasn't caught up yet. Bootstrapped and tested on powerpc64-linux --enable-languages=c,c++,fortran --disable-libsanitizer, -m64,-m32,-m32/-mpowerpc64, no regressions. Okay to apply? gcc/ 2013-05-04 Segher Boessenkool * config/rs6000/predicates.md (reg_or_add_cint_operand, reg_or_sub_cint_operand): Delete "HOST_BITS_PER_WIDE_INT == 32" case. (reg_or_logical_cint_operand, easy_fp_constant, logical_const_operand): Delete "CONST_DOUBLE" case. * config/rs6000/rs6000.c (num_insns_constant_wide): Delete "HOST_BITS_PER_WIDE_INT == 64" test. (num_insns_constant): Ditto. Delete CONST_DOUBLE DImode/VOIDmode case. (build_mask64_2_operands): Delete "HOST_BITS_PER_WIDE_INT >= 64" test. (rs6000_emit_set_const): Delete CONST_DOUBLE case. (rs6000_emit_set_long_const): Delete "HOST_BITS_PER_WIDE_INT >= 64" test. (includes_rldic_lshift_p, includes_rldicr_lshift_p): Delete CONST_DOUBLE DImode/VOIDmode case. (INT_P, INT_LOWPART): Delete CONST_DOUBLE case. (print_operand): Delete "HOST_BITS_PER_WIDE_INT == 32" case. Delete CONST_DOUBLE VOIDmode case. (output_toc): Delete "HOST_BITS_PER_WIDE_INT == 32" case. (rs6000_rtx_costs): Delete CONST_DOUBLE DImode/VOIDmode case. * config/rs6000/rs6000.md (iordi3, xordi3, splitter for these): Delete CONST_DOUBLE case. (splitters for mov FMOVE64 const_double): Delete "HOST_BITS_PER_WIDE_INT == 32" case. Delete "HOST_BITS_PER_WIDE_INT >= 64" test. (splitter for mov DI const_int): Delete "HOST_BITS_PER_WIDE_INT == 32" case. (mov DI const_double): Delete. --- gcc/config/rs6000/predicates.md | 49 ++ gcc/config/rs6000/rs6000.c | 207 +++- gcc/config/rs6000/rs6000.md | 77 ++- 3 files changed, 33 insertions(+), 300 deletions(-) diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md index 8112f26..78ec1b2 100644 --- a/gcc/config/rs6000/predicates.md +++ b/gcc/config/rs6000/predicates.md @@ -279,22 +279,17 @@ (define_predicate "reg_or_cint_operand" ;; or non-special register. (define_predicate "reg_or_add_cint_operand" (if_then_else (match_code "const_int") -(match_test "(HOST_BITS_PER_WIDE_INT == 32 - && (mode == SImode || INTVAL (op) < 0x7fff8000)) -|| ((unsigned HOST_WIDE_INT) (INTVAL (op) + 0x80008000) -< (unsigned HOST_WIDE_INT) 0x1ll)") +(match_test "(unsigned HOST_WIDE_INT) (INTVAL (op) + 0x80008000) +< (unsigned HOST_WIDE_INT) 0x1ll") (match_operand 0 "gpc_reg_operand"))) ;; Return 1 if op is a constant integer valid for subtraction ;; or non-special register. (define_predicate "reg_or_sub_cint_operand" (if_then_else (match_code "const_int") -(match_test "(HOST_BITS_PER_WIDE_INT == 32 - && (mode == SImode || - INTVAL (op) < 0x7fff8000)) -|| ((unsigned HOST_WIDE_INT) (- INTVAL (op) - + (mode == SImode - ? 0x8000 : 0x80008000)) -< (unsigned HOST_WIDE_INT) 0x1ll)") +(match_test "(unsigned HOST_WIDE_INT) + (- INTVAL (op) + (mode == SImode ? 0x8000 : 0x80008000)) +< (unsigned HOST_WIDE_INT) 0x1ll") (match_operand 0 "gpc_reg_operand"))) ;; Return 1 if op is any 32-bit unsigned constant integer @@ -305,11 +300,7 @@ (define_predicate "reg_or_logical_cint_operand" && INTVAL (op) >= 0) || ((INTVAL (op) & GET_MODE_MASK (mode) & (~ (unsigned HOST_WIDE_INT) 0x)) == 0)") -(if_then_else (match_code "const_double") - (match_test "GET_MODE_BITSIZE (mode) > HOST_BITS_PER_WIDE_INT - && mode == DImode - && CONST_DOUBLE_HIGH (op) == 0") - (match_operand 0 "gpc_reg_operand" +(match_operand 0 "gpc_reg_operand"))) ;; Return 1 if operand is a CONST_DOUBLE that can be set in a register ;; with no more than one instruction per word. @@ -403,9 +394,7 @@ (define_predicate "easy_fp_constant" return num_insns_constant_wide (k[0]) == 1; case DImode: -return ((TARGET_POWERPC64 -&& GET_CODE (op) == CONST_DOUBLE && CONST_DOUBLE_LOW (op) == 0) - || (num_insns_constant (op, DImode) <= 2)); +return (num_insns_constant (op, DImode) <= 2); case SImode: return 1; @@ -605,29 +594,11 @@ (define_predicate "non_add_cint_operand"
[PATCH 2/2] rs6000: remove INT_LOWPART
It's just INTVAL now, which is shorter and clearer.
Bootstrapped and tested on powerpc64-linux --enable-languages=c,c++,fortran
--disable-libsanitizer, -m64,-m32,-m32/-mpowerpc64, no regressions. Okay
to apply?
gcc/
2013-05-04 Segher Boessenkool
* config/rs6000/rs6000.c (INT_LOWPART): Delete.
(extract_MB): Adjust.
(extract_ME): Adjust.
(print_operand): Adjust.
---
gcc/config/rs6000/rs6000.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index dc3e4e5..dbe8980 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -14843,17 +14843,13 @@ rs6000_init_machine_status (void)
return ggc_alloc_cleared_machine_function ();
}
-/* These macros test for integers and extract the low-order bits. */
-#define INT_P(X) \
-(GET_CODE (X) == CONST_INT && GET_MODE (X) == VOIDmode)
-
-#define INT_LOWPART(X) INTVAL (X)
+#define INT_P(X) (GET_CODE (X) == CONST_INT && GET_MODE (X) == VOIDmode)
int
extract_MB (rtx op)
{
int i;
- unsigned long val = INT_LOWPART (op);
+ unsigned long val = INTVAL (op);
/* If the high bit is zero, the value is the first 1 bit we find
from the left. */
@@ -14885,7 +14881,7 @@ int
extract_ME (rtx op)
{
int i;
- unsigned long val = INT_LOWPART (op);
+ unsigned long val = INTVAL (op);
/* If the low bit is zero, the value is the first 1 bit we find from
the right. */
@@ -15006,7 +15002,7 @@ print_operand (FILE *file, rtx x, int code)
/* If constant, low-order 16 bits of constant, unsigned.
Otherwise, write normally. */
if (INT_P (x))
- fprintf (file, HOST_WIDE_INT_PRINT_DEC, INT_LOWPART (x) & 0x);
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x) & 0x);
else
print_operand (file, x, 0);
return;
@@ -15014,7 +15010,7 @@ print_operand (FILE *file, rtx x, int code)
case 'B':
/* If the low-order bit is zero, write 'r'; otherwise, write 'l'
for 64-bit mask direction. */
- putc (((INT_LOWPART (x) & 1) == 0 ? 'r' : 'l'), file);
+ putc (((INTVAL (x) & 1) == 0 ? 'r' : 'l'), file);
return;
/* %c is output_addr_const if a CONSTANT_ADDRESS_P, otherwise
@@ -15072,7 +15068,7 @@ print_operand (FILE *file, rtx x, int code)
/* If constant, output low-order five bits. Otherwise, write
normally. */
if (INT_P (x))
- fprintf (file, HOST_WIDE_INT_PRINT_DEC, INT_LOWPART (x) & 31);
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x) & 31);
else
print_operand (file, x, 0);
return;
@@ -15081,7 +15077,7 @@ print_operand (FILE *file, rtx x, int code)
/* If constant, output low-order six bits. Otherwise, write
normally. */
if (INT_P (x))
- fprintf (file, HOST_WIDE_INT_PRINT_DEC, INT_LOWPART (x) & 63);
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x) & 63);
else
print_operand (file, x, 0);
return;
@@ -15118,7 +15114,7 @@ print_operand (FILE *file, rtx x, int code)
if (! INT_P (x))
output_operand_lossage ("invalid %%k value");
else
- fprintf (file, HOST_WIDE_INT_PRINT_DEC, ~ INT_LOWPART (x));
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC, ~ INTVAL (x));
return;
case 'K':
@@ -15203,8 +15199,8 @@ print_operand (FILE *file, rtx x, int code)
case 'p':
/* X is a CONST_INT that is a power of two. Output the logarithm. */
if (! INT_P (x)
- || INT_LOWPART (x) < 0
- || (i = exact_log2 (INT_LOWPART (x))) < 0)
+ || INTVAL (x) < 0
+ || (i = exact_log2 (INTVAL (x))) < 0)
output_operand_lossage ("invalid %%p value");
else
fprintf (file, "%d", i);
@@ -15277,7 +15273,7 @@ print_operand (FILE *file, rtx x, int code)
if (! INT_P (x))
output_operand_lossage ("invalid %%s value");
else
- fprintf (file, HOST_WIDE_INT_PRINT_DEC, (32 - INT_LOWPART (x)) & 31);
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC, (32 - INTVAL (x)) & 31);
return;
case 'S':
@@ -15287,7 +15283,7 @@ print_operand (FILE *file, rtx x, int code)
if (! mask64_operand (x, DImode))
output_operand_lossage ("invalid %%S value");
- uval = INT_LOWPART (x);
+ uval = INTVAL (x);
if (uval & 1)/* Clear Left */
{
@@ -15338,7 +15334,7 @@ print_operand (FILE *file, rtx x, int code)
output_operand_lossage ("invalid %%u value");
else
fprintf (file, HOST_WIDE_INT_PRINT_HEX,
-(INT_LOWPART (x) >> 16) & 0x);
+(INTVAL (x) >> 16) & 0x);
return;
case 'v':
@@ -15347,7 +15343,7 @@ print_operand (FILE *file, rtx x, int code)
output_operand_lossage ("invalid %%v value");
else
fprintf (file, HOST_WIDE_INT_PRINT_HEX,
-(INT_LOWPART (x) >> 16) &
Re: [PATCH 1/2] rs6000: Remove legacy HOST_BITS_PER_WIDE_INT < 64 code
On Sat, May 4, 2013 at 2:37 PM, Segher Boessenkool wrote: > We always have HOST_BITS_PER_WIDE_INT >= 64, so remove the code testing > for == 32, and remove the tests testing for >= 64. Also remove the tests > testing for == 64 that should really have been testing for >= 64. > > DImode constants are always CONST_INT, never CONST_DOUBLE. Simplify the > old code that hasn't caught up yet. > > Bootstrapped and tested on powerpc64-linux --enable-languages=c,c++,fortran > --disable-libsanitizer, -m64,-m32,-m32/-mpowerpc64, no regressions. Okay > to apply? > > > gcc/ > 2013-05-04 Segher Boessenkool > > * config/rs6000/predicates.md (reg_or_add_cint_operand, > reg_or_sub_cint_operand): Delete "HOST_BITS_PER_WIDE_INT == 32" case. > (reg_or_logical_cint_operand, easy_fp_constant, > logical_const_operand): Delete "CONST_DOUBLE" case. > * config/rs6000/rs6000.c (num_insns_constant_wide): Delete > "HOST_BITS_PER_WIDE_INT == 64" test. > (num_insns_constant): Ditto. Delete CONST_DOUBLE DImode/VOIDmode > case. > (build_mask64_2_operands): Delete "HOST_BITS_PER_WIDE_INT >= 64" test. > (rs6000_emit_set_const): Delete CONST_DOUBLE case. > (rs6000_emit_set_long_const): Delete "HOST_BITS_PER_WIDE_INT >= 64" > test. > (includes_rldic_lshift_p, includes_rldicr_lshift_p): Delete > CONST_DOUBLE DImode/VOIDmode case. > (INT_P, INT_LOWPART): Delete CONST_DOUBLE case. > (print_operand): Delete "HOST_BITS_PER_WIDE_INT == 32" case. Delete > CONST_DOUBLE VOIDmode case. > (output_toc): Delete "HOST_BITS_PER_WIDE_INT == 32" case. > (rs6000_rtx_costs): Delete CONST_DOUBLE DImode/VOIDmode case. > * config/rs6000/rs6000.md (iordi3, xordi3, splitter for these): > Delete CONST_DOUBLE case. > (splitters for mov FMOVE64 const_double): Delete > "HOST_BITS_PER_WIDE_INT == 32" case. Delete > "HOST_BITS_PER_WIDE_INT >= 64" test. > (splitter for mov DI const_int): Delete "HOST_BITS_PER_WIDE_INT == 32" > case. > (mov DI const_double): Delete. Okay. Thanks, David
Re: [PATCH 2/2] rs6000: remove INT_LOWPART
On Sat, May 4, 2013 at 2:37 PM, Segher Boessenkool wrote: > It's just INTVAL now, which is shorter and clearer. > > Bootstrapped and tested on powerpc64-linux --enable-languages=c,c++,fortran > --disable-libsanitizer, -m64,-m32,-m32/-mpowerpc64, no regressions. Okay > to apply? > > > gcc/ > 2013-05-04 Segher Boessenkool > > * config/rs6000/rs6000.c (INT_LOWPART): Delete. > (extract_MB): Adjust. > (extract_ME): Adjust. > (print_operand): Adjust. Okay. But please comment that you are reformatting INT_P. Thanks, David
Re: [PATCH 1/9] Improve pointer hash function to include all bits
The revised version of hash_pointer() produces warnings when compiled
on a 32 bit host because it shift a 32 bit variable by 32 bits.
+ intptr_t v = (intptr_t)p;
...
+ b += v & 0x;
The code is not executed when intptr_t is 32 bits, but it still is
present in the function, causing a warning.
The appended, revised implementation was designed by a blue ribbon commission.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
2013-05-04 David Edelsohn
Peter Bergner
Segher Boessenkool
Jakub Jelinek
Index: hashtab.c
===
--- hashtab.c (revision 198587)
+++ hashtab.c (working copy)
@@ -990,17 +990,8 @@
unsigned a, b, c;
a = b = 0x9e3779b9;
- if (sizeof (intptr_t) == 4)
-{
- /* Mix as 16bit for now */
- a += v >> 16;
- b += v & 0x;
-}
- else
-{
- a += v >> 32;
- b += v & 0x;
-}
+ a += v >> (sizeof (intptr_t) * CHAR_BIT / 2);
+ b += v & (((intptr_t) 1 << (sizeof (intptr_t) * CHAR_BIT / 2)) - 1);
c = 0x42135234;
mix (a, b, c);
return c;
[PATCH, FORTRAN] Include unistd.h in environ.c
environ.c is referencing functions like getuid(), geteuid(), getgid()
and getegid(), but it does not include the header file that declares
them.
I also noticed that libgfortran is not consistent about checking that
unistd.h exists.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
Thanks, David
* runtime/pause.c: Test HAVE_UNISTD_H.
* runtime/environ.c: Include unistd.h.
* runtime/stop.c: Test HAVE_UNISTD_H.
Index: runtime/pause.c
===
--- runtime/pause.c (revision 198587)
+++ runtime/pause.c (working copy)
@@ -25,8 +25,12 @@
#include "libgfortran.h"
#include
+
+#ifdef HAVE_UNISTD_H
#include
+#endif
+
static void
do_pause (void)
{
Index: runtime/environ.c
===
--- runtime/environ.c (revision 198587)
+++ runtime/environ.c (working copy)
@@ -28,7 +28,11 @@
#include
#include
+#ifdef HAVE_UNISTD_H
+#include
+#endif
+
/* Environment scanner. Examine the environment for controlling minor
* aspects of the program's execution. Our philosophy here that the
* environment should not prevent the program from running, so an
Index: runtime/stop.c
===
--- runtime/stop.c (revision 198587)
+++ runtime/stop.c (working copy)
@@ -26,8 +26,12 @@
#include "libgfortran.h"
#include
#include
+
+#ifdef HAVE_UNISTD_H
#include
+#endif
+
/* A numeric STOP statement. */
extern void stop_numeric (GFC_INTEGER_4)
[PATCH,FORTRAN] Variable "value" possibly unused in io/read.c
All uses of "value" are protected by
#if defined HAVE_GFC_REAL_16 || defined HAVE_GFC_REAL_10
so it may be unused, which generates a warning on some platforms.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
Thanks, David
* io/read.c (si_max): Annotate value with attribute unused.
Index: io/read.c
===
--- io/read.c (revision 198587)
+++ io/read.c (working copy)
@@ -91,7 +91,7 @@
GFC_UINTEGER_LARGEST
si_max (int length)
{
- GFC_UINTEGER_LARGEST value;
+ GFC_UINTEGER_LARGEST value __attribute__((unused));
switch (length)
{
Re: [PATCH, FORTRAN] Include unistd.h in environ.c
David Edelsohn wrote:
environ.c is referencing functions like getuid(), geteuid(), getgid()
and getegid(), but it does not include the header file that declares
them.
I also noticed that libgfortran is not consistent about checking that
unistd.h exists.
You can add io/unix.c and io/open.c to the list of files which do not
check whether unistd.h exists. Can you add the #ifdef there as well?
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
Okay. Thanks for the patch!
Tobias
* runtime/pause.c: Test HAVE_UNISTD_H.
* runtime/environ.c: Include unistd.h.
* runtime/stop.c: Test HAVE_UNISTD_H.
Index: runtime/pause.c
===
--- runtime/pause.c (revision 198587)
+++ runtime/pause.c (working copy)
@@ -25,8 +25,12 @@
#include "libgfortran.h"
#include
+
+#ifdef HAVE_UNISTD_H
#include
+#endif
+
static void
do_pause (void)
{
Index: runtime/environ.c
===
--- runtime/environ.c (revision 198587)
+++ runtime/environ.c (working copy)
@@ -28,7 +28,11 @@
#include
#include
+#ifdef HAVE_UNISTD_H
+#include
+#endif
+
/* Environment scanner. Examine the environment for controlling minor
* aspects of the program's execution. Our philosophy here that the
* environment should not prevent the program from running, so an
Index: runtime/stop.c
===
--- runtime/stop.c (revision 198587)
+++ runtime/stop.c (working copy)
@@ -26,8 +26,12 @@
#include "libgfortran.h"
#include
#include
+
+#ifdef HAVE_UNISTD_H
#include
+#endif
+
/* A numeric STOP statement. */
extern void stop_numeric (GFC_INTEGER_4)
Re: [PATCH,FORTRAN] Variable "value" possibly unused in io/read.c
David Edelsohn wrote:
All uses of "value" are protected by
#if defined HAVE_GFC_REAL_16 || defined HAVE_GFC_REAL_10
so it may be unused, which generates a warning on some platforms.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
* io/read.c (si_max): Annotate value with attribute unused.
I think using
#if defined HAVE_GFC_REAL_16 || defined HAVE_GFC_REAL_10
GFC_UINTEGER_LARGEST value;
#endif
is cleaner than using the unused attribute.
OK with that change. And thanks for the the cleanup!
Tobias
Index: io/read.c
===
--- io/read.c (revision 198587)
+++ io/read.c (working copy)
@@ -91,7 +91,7 @@
GFC_UINTEGER_LARGEST
si_max (int length)
{
- GFC_UINTEGER_LARGEST value;
+ GFC_UINTEGER_LARGEST value __attribute__((unused));
switch (length)
{
Re: [build, driver] RFC: Support compressed debug sections
"Joseph S. Myers" writes:
> On Tue, 30 Apr 2013, Rainer Orth wrote:
>
>> * gcc.c (LINK_COMPRESS_DEBUG_SPEC, ASM_COMPRESS_DEBUG_SPEC):
>> Define.
>> (LINK_COMMAND_SPEC): Invoke LINK_COMPRESS_DEBUG_SPEC.
>> (asm_options): Invoke ASM_COMPRESS_DEBUG_SPEC.
>
> Note that there are separate copies of LINK_COMMAND_SPEC in darwin.h and
> i386/djgpp.h, which maybe should include the new spec.
I hadn't thought about that. Here's what I found:
* Darwin is Mach-O, but current gas supports DWARF-in-Mach-O.
Unfortunately, current gcc mainline only supports Apple as:
i386/darwin.h hardcodes as-only options in ASM_SPEC, which causes gas
to barf. If you manually invoke gas on gcc -gdwarf output, you get
compressed debug sections, though objdump cannot handle them.
* DJGPP is COFF, but again gas seems to support DWARF. Unfortunately,
current gcc mainline doesn't even build:
gcc/config/i386/i386.c: In function 'void ix86_code_end()':
gcc/config/i386/i386.c:8667: error: 'ASM_DECLARE_FUNCTION_NAME' was not
declared in this scope
I didn't look further from here.
Anyway, I tried a i386-pc-solaris2.11 x i686-pc-darwin build with the
following patch to check it doesn't break the build:
* config/darwin.h (LINK_COMMAND_SPEC_A): Invoke
LINK_COMPRESS_DEBUG_SPEC.
* config/i386/djgpp.h (LINK_COMMAND_SPEC): Likewise.
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -171,7 +171,8 @@ extern GTY(()) int darwin_ms_struct;
LINK_PLUGIN_SPEC \
"%{flto*:%
Especially darwin.h LINK_COMMAND_SPEC_A is a total mess: it's a copy of
gcc.c LINK_COMMAND_SPEC with various changes not carried forward and
other parts done in a slightly different syntax for no apparent reason.
I'm pretty sure the two could be merged to avoid problems from
duplication in the future, but I'll leave that to the Darwin
maintainers.
I can include the snippet above for symmetry, if only to reject -gz as
on ELF targets without the toolchain support, if you prefer.
> It's not clear to me from the documentation added by this patch whether
> users are meant to specify their -gz options when compiling, when linking,
> or both - and whether there might be cases when such an option is accepted
> for one of compiling and linking but not the other (which would be
> especially confusing).
The goal is to have -gz work for both compilation and linking, but
unfortunately, the current situation very much depends on both the
toolchain used and your intentions. The following matrix shows read and
write support in the GNU and Solaris toolchains. For the latter, full
support for zlib and zlib-gnu formats is being worked on, with ld
already there.
GNU Solaris
gas gld gold gdb as ld dbx
wr w r w r wr w r
none xx x x x x xx x x
zlib-gnu xxx x xx x
zlib x x
I plan to add zlib support first to gas and gdb, eventually to gld
(which also means adding support for compression on output, though I had
a very hard time finding my way through bfd and gld in the past), but
will rely on Cary Coutant and/or Ian, who were involved in the zlib/ELF
gABI format design, to handle gold.
Right now, the gas/gold combination supports -gz just fine (producing
the zlib-gnu format), while gas/gld only support -gz in the assemble
step. I know this is highly undesirable, but whether or not it's
acceptable depends on your goals:
* If you mean to trade compilation/assembly speed for disk usage, -gz
for compilation only is ok.
* If your primary goal is space savings for executables and shared
objects while still allowing debugability, you need to use gold for
-gz at link time to work.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [C++ Patch] PR 53745
OK. Jason
[patch, libgfortran] PR56743 Namelist bug with comment and no blank
The attached patch resolves this PR by treating '!', the Fortran comment mark,
as a valid separator between values. Thus, when encountered while reading a
value, the read is ended normally with whatever value was encountered. This is
an extension beyond the Standards which require a separator before a comment
mark.
I must emphasize that extensions like this are no guarantee of portability
across compilers. Users should use well formed namelists always.
Regression tested on x86-64. Test case attached. OK for trunk?
Regards,
Jerry
Index: list_read.c
===
--- list_read.c (revision 198600)
+++ list_read.c (working copy)
@@ -840,6 +840,7 @@ read_integer (st_parameter_dt *dtp, int length)
CASE_SEPARATORS: /* Not a repeat count. */
case EOF:
+ case '!':
goto done;
default:
@@ -890,6 +891,7 @@ read_integer (st_parameter_dt *dtp, int length)
CASE_SEPARATORS:
case EOF:
+ case '!':
goto done;
default:
@@ -1489,6 +1491,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
CASE_SEPARATORS:
case EOF:
+ case '!':
if (c != '\n' && c != ',' && c != '\r' && c != ';')
unget_char (dtp, c);
goto done;
@@ -1558,6 +1561,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
CASE_SEPARATORS:
case EOF:
+ case '!':
goto done;
case '.':
@@ -1618,6 +1622,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
CASE_SEPARATORS:
case EOF:
+ case '!':
goto done;
default:
! { dg-do run }
!
! PR fortran/56743
!
! Contributed by Kai Gallmeister
!
! Note that Fortran 2008 (Section 10.11.3.6) requires that there is
! a value separator between the value and the "!". Thus, all examples
! in this file are invalid; they should either by accepted as vendor
! extension or lead to a run-time error (iostat /=0).
!
! For the c1 and c2 character example, please note that the Fortran
! standard (F2008, 10.11.3.3) requires delimiters; accepting
! a single word (in spirit of list-directed I/O) would be possible
! as vendor extension. But the current run-time failure is fine as well.
!
implicit none
integer :: i = -1
real :: r1 = -2
real :: r2 = -3
real :: r3 = -4
real :: r4 = -5
real :: r5 = -6
complex :: c = (-7,-7)
logical :: ll = .false.
character :: c1 = 'X'
character(3) :: c2 = 'YYY'
character(3) :: c3 = 'ZZZ'
integer :: ios
namelist /nml/ i, r1,r2,r3,r4,r5,c,ll,c1,c2,c3
!write (*, nml=nml)
open (99, file='nml.dat', status="replace")
write(99,*) "&nml"
write(99,*) " i=42!11" ! BUG: wrong result: Unmodified, no error
write(99,*) " r1=43!11"! BUG: wrong result: Unmodified, no error
write(99,*) " r2=43.!11" ! BUG: wrong result: Unmodified, no error
!write(99,*) " r3=inf!11" ! OK: run-time error (Cannot match namelist object)
!write(99,*) " r4=NaN(0x33)!11" ! OK: run-time error (Cannot match namelist object)
write(99,*) " r5=3.e5!11" ! BUG: wrong result: Unmodified, no error
write(99,*) " c=(4,2)!11" ! OK: value accepted as vendor extension
write(99,*) " ll=.true.!11"! OK: value accepted as vendor extension
!write(99,*) " c1=a!11" ! OK: run-time error (Cannot match namelist object)
!write(99,*) " c2=bc!11"! OK: run-time error (Cannot match namelist object)
write(99,*) " c3='ax'!11" ! OK: value accepted as vendor extension
write(99,*) "/"
rewind(99)
read (99, nml=nml)
!write (*, nml=nml)
close (99, status="delete")
if (i /= 42) call abort ()
if (r1 /= 43) call abort ()
if (r2 /= 43) call abort ()
! if (r3 /= r3 .or. r3 <= huge(r3)) call abort ()
! if (r4 == r4) call abort ()
if (r5 /= 30) call abort ()
if (c /= cmplx(4,2)) call abort ()
if (.not. ll) call abort ()
! if (c1 /= "a") call abort ()
! if (c2 /= "bc") call abort ()
if (c3 /= "ax") call abort ()
end
Re: [patch, libgfortran] PR56743 Namelist bug with comment and no blank
On 05/04/2013 05:13 PM, Jerry DeLisle wrote: > The attached patch resolves this PR by treating '!', the Fortran comment mark, > as a valid separator between values. Thus, when encountered while reading a > value, the read is ended normally with whatever value was encountered. This > is > an extension beyond the Standards which require a separator before a comment > mark. > > I must emphasize that extensions like this are no guarantee of portability > across compilers. Users should use well formed namelists always. > > Regression tested on x86-64. Test case attached. OK for trunk? > > Regards, > > Jerry > BTW Here is the ChangeLog entry 2013-05-04 Jerry DeLisle PR libfortran/56743 * io/list_read.c (read_integer): Treat '!' as a separator. (read_real): Likewise.
Re: [patch, libgfortran] PR56743 Namelist bug with comment and no blank
On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
>
> CASE_SEPARATORS:/* Not a repeat count. */
> case EOF:
> + case '!':
if (c == '!')
gfc_warning("GNU Fortran extension: accepting a possibly "
"corrupted namelist");
> goto done;
>
> default:
> @@ -890,6 +891,7 @@ read_integer (st_parameter_dt *dtp, int length)
>
> CASE_SEPARATORS:
> case EOF:
> + case '!':
see above
> goto done;
>
> default:
> @@ -1489,6 +1491,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
>
> CASE_SEPARATORS:
> case EOF:
> + case '!':
>if (c != '\n' && c != ',' && c != '\r' && c != ';')
> unget_char (dtp, c);
> goto done;
> @@ -1558,6 +1561,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
>
> CASE_SEPARATORS:
> case EOF:
> + case '!':
see above
> goto done;
>
> case '.':
> @@ -1618,6 +1622,7 @@ read_real (st_parameter_dt *dtp, void * dest, int
>
> CASE_SEPARATORS:
> case EOF:
> + case '!':
see above.
> goto done;
>
> default:
I would prefer that gfortran issues an error.
Issuing a warning is acceptable.
Patch as is not OK IMHO.
PS: A vendor extension should be documented in the manual.
--
Steve
Re: powerpc64le-linux support
This fixes a couple more little-endian bugs. bswapdi stores when
!TARGET_LDBRX were being split to two bswapsi but written to the wrong
words because we word swapped twice. ashrdi3 resulted in a libcall.
I think I have ashrdi3_no_power correct. For LE, the first reg of a
register pair is the low word, the second the high word, and you use
%L to select the high reg. (For BE the second reg is the low word and
%L really does stand for low). So a quick rule of thumb for
converting big-endian register pair patterns to little-endian is
replace all the reg pair %n with %Ln and all %Ln with %n.
* config/rs6000/rs6000.md (bswapdi 2nd splitter): Don't swap words
twice for little-endian.
(ashrdi3_no_power, ashrdi3): Support little-endian.
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 198274)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -2329,16 +2330,14 @@
{
word_high = change_address (dest, SImode, addr1);
word_low = change_address (dest, SImode, addr2);
- emit_insn (gen_bswapsi2 (word_high, src_si));
- emit_insn (gen_bswapsi2 (word_low, op3_si));
}
else
{
word_high = change_address (dest, SImode, addr2);
word_low = change_address (dest, SImode, addr1);
- emit_insn (gen_bswapsi2 (word_low, src_si));
- emit_insn (gen_bswapsi2 (word_high, op3_si));
}
+ emit_insn (gen_bswapsi2 (word_high, src_si));
+ emit_insn (gen_bswapsi2 (word_low, op3_si));
}")
(define_split
@@ -6634,10 +6633,25 @@
[(set (match_operand:DI 0 "gpc_reg_operand" "=&r,&r")
(ashiftrt:DI (match_operand:DI 1 "gpc_reg_operand" "r,r")
(match_operand:SI 2 "const_int_operand" "M,i")))]
- "TARGET_32BIT && !TARGET_POWERPC64 && WORDS_BIG_ENDIAN"
- "@
- srawi %0,%1,31\;srawi %L0,%1,%h2
- srwi %L0,%L1,%h2\;insrwi %L0,%1,%h2,0\;srawi %0,%1,%h2"
+ "!TARGET_POWERPC64"
+ "*
+{
+ switch (which_alternative)
+{
+default:
+ gcc_unreachable ();
+case 0:
+ if (WORDS_BIG_ENDIAN)
+return \"srawi %0,%1,31\;srawi %L0,%1,%h2\";
+ else
+return \"srawi %L0,%L1,31\;srawi %0,%L1,%h2\";
+case 1:
+ if (WORDS_BIG_ENDIAN)
+ return \"srwi %L0,%L1,%h2\;insrwi %L0,%1,%h2,0\;srawi %0,%1,%h2\";
+ else
+ return \"srwi %0,%1,%h2\;insrwi %0,%L1,%h2,0\;srawi %L0,%L1,%h2\";
+}
+}"
[(set_attr "type" "two,three")
(set_attr "length" "8,12")])
@@ -7734,13 +7748,12 @@
[(set (match_operand:DI 0 "gpc_reg_operand" "")
(ashiftrt:DI (match_operand:DI 1 "gpc_reg_operand" "")
(match_operand:SI 2 "reg_or_cint_operand" "")))]
- "WORDS_BIG_ENDIAN"
+ ""
"
{
if (TARGET_POWERPC64)
;
- else if (TARGET_32BIT && GET_CODE (operands[2]) == CONST_INT
- && WORDS_BIG_ENDIAN)
+ else if (GET_CODE (operands[2]) == CONST_INT)
{
emit_insn (gen_ashrdi3_no_power (operands[0], operands[1], operands[2]));
DONE;
--
Alan Modra
Australia Development Lab, IBM
Re: [patch, libgfortran] PR56743 Namelist bug with comment and no blank
On 05/04/2013 06:30 PM, Steve Kargl wrote:
> On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
>>
>> CASE_SEPARATORS:/* Not a repeat count. */
>> case EOF:
>> +case '!':
>
> if (c == '!')
> gfc_warning("GNU Fortran extension: accepting a possibly "
> "corrupted namelist");
--- SNIP ---
> I would prefer that gfortran issues an error.
> Issuing a warning is acceptable.
> Patch as is not OK IMHO.
>
> PS: A vendor extension should be documented in the manual.
>
I don't see much point in issuing a warning if we accept it. I can just as
easily make it an error with something like "A value separator is required
before a namelist comment" and be done with trying to second guess whether
someone is using namelists right or not.
An error would be most consistent across all variable kinds.
Any other opinions out there?
Jerry
Re: mips SNaN/QNaN is swapped
Hi Iain!
Joseph pointed out that I didn't include you, the libgcc and fp-bit
maintainer, in my mails' recipient lists. I'm waiting for approval for
the following changes:
On Mon, 22 Apr 2013 11:52:23 +0200, I wrote:
> On Fri, 5 Apr 2013 23:55:37 +0100, "Maciej W. Rozycki"
> wrote:
> > On Fri, 5 Apr 2013, Thomas Schwinge wrote:
> > > > Index: gcc/config/fp-bit.c
> > > > ===
> > > > RCS file: /cvs/uberbaum/gcc/config/fp-bit.c,v
> > > > retrieving revision 1.39
> > > > diff -u -p -r1.39 fp-bit.c
> > > > --- gcc/config/fp-bit.c 26 Jan 2003 10:06:57 - 1.39
> > > > +++ gcc/config/fp-bit.c 1 Apr 2003 21:35:00 -
> > > > @@ -210,7 +210,11 @@ pack_d ( fp_number_type * src)
> > > >exp = EXPMAX;
> > > >if (src->class == CLASS_QNAN || 1)
> > > > {
> > > > +#ifdef QUIET_NAN_NEGATED
> > > > + fraction |= QUIET_NAN - 1;
> > > > +#else
> > > > fraction |= QUIET_NAN;
> > > > +#endif
>
> > I think the intent of this code is to preserve a NaN's payload (it
> > certainly does for non-QUIET_NAN_NEGATED targets)
>
> I agree. For preserving the payload, both the unpack/pack code also has
> to shift by NGARDS.
>
> > Complementing the change above I think it will also make
> > sense to clear the qNaN bit when extracting a payload from fraction in
> > unpack_d as the class of a NaN being handled is stored separately.
>
> I agree.
>
> > Also I find the "|| 1" clause in the condition immediately above the
> > pack_d piece concerned suspicious -- why is a qNaN returned for sNaN
> > input? Likewise why are __thenan_sf, etc. encoded as sNaNs rather than
> > qNaNs? Does anybody know?
>
> I also stumbled over that, but for all these, I suppose the idea is that
> when a sNaN is "arithmetically processed" (which includes datatype
> conversion), an INVALID exception is to be raised (though, »[fp-bit]
> implements IEEE 754 format arithmetic, but does not provide a mechanism
> [...] for generating or handling exceptions«), and then converted into a
> qNaN.
>
> Also, I found that the bit to look at for distinguishing qNaN/sNaN is
> defined wrongly for float. Giving me some "interesting" test results...
> ;-)
>
> Manual testing looks good. Automated testing is still running; in case
> nothing turns up, is this OK to check in?
>
> libgcc/
> * fp-bit.c (unpack_d, pack_d): Properly preserve and restore a
> NaN's payload.
> * fp-bit.h [FLOAT] (QUIET_NAN): Correct value.
>
> Index: libgcc/fp-bit.c
> ===
> --- libgcc/fp-bit.c (revision 402061)
> +++ libgcc/fp-bit.c (working copy)
> @@ -214,11 +214,18 @@ pack_d (const fp_number_type *src)
>else if (isnan (src))
> {
>exp = EXPMAX;
> + /* Restore the NaN's payload. */
> + fraction >>= NGARDS;
> + fraction &= QUIET_NAN - 1;
>if (src->class == CLASS_QNAN || 1)
> {
> #ifdef QUIET_NAN_NEGATED
> - fraction |= QUIET_NAN - 1;
> + /* The quiet/signaling bit remains unset. */
> + /* Make sure the fraction has a non-zero value. */
> + if (fraction == 0)
> + fraction |= QUIET_NAN - 1;
> #else
> + /* Set the quiet/signaling bit. */
> fraction |= QUIET_NAN;
> #endif
> }
> @@ -574,8 +581,10 @@ unpack_d (FLO_union_type * src, fp_number_type * d
> {
> dst->class = CLASS_SNAN;
> }
> - /* Keep the fraction part as the nan number */
> - dst->fraction.ll = fraction;
> + /* Now that we know which kind of NaN we got, discard the
> + quiet/signaling bit, but do preserve the NaN payload. */
> + fraction &= ~QUIET_NAN;
> + dst->fraction.ll = fraction << NGARDS;
> }
> }
>else
> Index: libgcc/fp-bit.h
> ===
> --- libgcc/fp-bit.h (revision 402061)
> +++ libgcc/fp-bit.h (working copy)
> @@ -190,7 +190,7 @@ typedef unsigned int UTItype __attribute__ ((mode
> #define EXPBIAS 127
> #define FRACBITS 23
> #define EXPMAX (0xff)
> -#define QUIET_NAN 0x10L
> +#define QUIET_NAN 0x40L
> #define FRAC_NBITS 32
> #define FRACHIGH 0x8000L
> #define FRACHIGH2 0xc000L
> @@ -298,7 +298,7 @@ typedef unsigned int UTItype __attribute__ ((mode
> /* numeric parameters */
> /* F_D_BITOFF is the number of bits offset between the MSB of the mantissa
> of a float and of a double. Assumes there are only two float types.
> - (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS-float::NGARDS))
> + (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS+float::NGARDS))
> */
> #define F_D_BITOFF (52+8-(23+7))
>
Grüße,
Thomas
pgpXnH44VR9Se.pgp
Description: PGP signature
Re: powerpc64le-linux support
This tidies endian selection. Prior to this change, if you gave a
little-endian gcc the -mcall-aixdesc option, gcc would operate
big-endian but the assembler in little-endian. Which was confusing to
say the least.
The sysv4.h changes below don't actually make any substantive changes
in the specs file, except to always add a default endian option to
ASM_SPEC. I think that's wise given a bi-endian binutils can be built
with either endian default. The linux64.h changes are a little more
substantive in order to cure the mixed endian problem.
The endian rules are:
a) Specify -mbig/-mlittle/-mbig-endian/-mlitte-endian and that's what
you get, otherwise,
b) specify any of the -mcall options except the -mcall-sysv variants
and you get an endian appropriate to the -mcall, mostly big,
otherwise
c) you get the default endian for your toolchain which depends on
configure options.
Something to consider for the future is making more of the -mcall
options endian agnostic, like -mcall-sysv. Tested with a number of
powerpc ELF builds.
* config/rs6000/sysv4.h (ENDIAN_SELECT): Define, extracted from
(ASM_SPEC): ..here. Emit DEFAULT_ASM_ENDIAN too.
(DEFAULT_ASM_ENDIAN): Define.
(CC1_SPEC, LINK_TARGET_SPEC): Use ENDIAN_SELECT.
* config/rs6000/linux64.h (ASM_SPEC32): Remove endian options.
Update -K PIC clause from sysv4.h.
(ASM_SPEC_COMMON): Use ENDIAN_SELECT.
(LINK_OS_LINUX_EMUL32, LINK_OS_LINUX_EMUL64): Likewise.
Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h (revision 198274)
+++ gcc/config/rs6000/sysv4.h (working copy)
@@ -517,19 +523,28 @@
while (0)
#endif
+/* Select one of BIG_OPT, LITTLE_OPT or DEFAULT_OPT depending
+ on various -mbig, -mlittle and -mcall- options. */
+#define ENDIAN_SELECT(BIG_OPT, LITTLE_OPT, DEFAULT_OPT)\
+"%{mlittle|mlittle-endian:"LITTLE_OPT ";" \
+ "mbig|mbig-endian:" BIG_OPT";" \
+ "mcall-aixdesc|mcall-freebsd|mcall-netbsd|" \
+ "mcall-openbsd|mcall-linux:" BIG_OPT";" \
+ "mcall-i960-old:"LITTLE_OPT ";" \
+ ":" DEFAULT_OPT "}"
+
+#if (TARGET_DEFAULT & MASK_LITTLE_ENDIAN)
+#define DEFAULT_ASM_ENDIAN " -mlittle"
+#else
+#define DEFAULT_ASM_ENDIAN " -mbig"
+#endif
+
#undef ASM_SPEC
#defineASM_SPEC "%(asm_cpu) \
%{,assembler|,assembler-with-cpp: %{mregnames} %{mno-regnames}} \
%{mrelocatable} %{mrelocatable-lib} %{fpic|fpie|fPIC|fPIE:-K PIC} \
-%{memb|msdata=eabi: -memb} \
-%{mlittle|mlittle-endian:-mlittle; \
- mbig|mbig-endian :-mbig;\
- mcall-aixdesc | \
- mcall-freebsd | \
- mcall-netbsd | \
- mcall-openbsd | \
- mcall-linux :-mbig;\
- mcall-i960-old:-mlittle}"
+%{memb|msdata=eabi: -memb}" \
+ENDIAN_SELECT(" -mbig", " -mlittle", DEFAULT_ASM_ENDIAN)
#defineCC1_ENDIAN_BIG_SPEC ""
@@ -547,17 +562,10 @@
#endif
/* Pass -G xxx to the compiler and set correct endian mode. */
-#defineCC1_SPEC "%{G*} %(cc1_cpu) \
-%{mlittle|mlittle-endian: %(cc1_endian_little); \
- mbig |mbig-endian : %(cc1_endian_big); \
- mcall-aixdesc |\
- mcall-freebsd |\
- mcall-netbsd |\
- mcall-openbsd |\
- mcall-linux : -mbig %(cc1_endian_big);\
- mcall-i960-old: -mlittle %(cc1_endian_little); \
-: %(cc1_endian_default)} \
-%{meabi: %{!mcall-*: -mcall-sysv }} \
+#defineCC1_SPEC "%{G*} %(cc1_cpu)" \
+ ENDIAN_SELECT(" %(cc1_endian_big)", " %(cc1_endian_little)", \
+ " %(cc1_endian_default)") \
+"%{meabi: %{!mcall-*: -mcall-sysv }} \
%{!meabi: %{!mno-eabi: \
%{mrelocatable: -meabi } \
%{mcall-freebsd: -mno-eabi } \
@@ -601,11 +609,8 @@
%{symbolic:-Bsymbolic -G -dy -z text }"
/* Override the default target of the linker. */
-#defineLINK_TARGET_SPEC "\
-%{mlittle: --oformat elf32-powerpcle } %{mlittle-endian: --oformat
elf32-powerpcle } \
-%{!mlittle: %{!mlittle-endian: %{!mbig: %{!mbig-endian: \
-%{mcall-i960-old: --oformat elf32-powerpcle} \
- "
+#defineLINK_TARGET_SPEC \
+ ENDIAN_SELECT("", " --oformat elf32-powerpcle", "")
/* Any specific OS flags. */
#define LINK_OS_SPEC "\
Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 198274)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -180,20 +183,14 @@
#endif
#define ASM_SPEC32 "-a32 \
-%{mrelocatable} %{mrelocatable-lib} %{fpic:-K PIC} %{fPIC:-K PIC} \
-%{memb} %{!memb: %{msdata=eabi: -memb}} \
-%{!mlittle: %{!mlittle-endian: %{!mbig: %{!mbig-endian:
