PATCH RFA: Correct toplevel configury
One of my recent patches broke the toplevel configury. I moved a test of $configdirs to a point before nonexistent directories have been removed from configdirs. The test was for whether gcc is being configured. The test is fine in the gcc repository, but not in the src repository. This patch fixes the problem. If the gcc directory exists, we assume that we are going to build it. This only matters for setting the default value for --enable-bootstrap. Bootstrapped on x86_64-unknown-linux-gnu. OK for mainline? Ian 2011-07-21 Ian Lance Taylor * configure.ac: Set have_compiler based on whether gcc directory exists, rather than on whether gcc is in configdirs. Index: configure.ac === --- configure.ac (revision 176515) +++ configure.ac (working copy) @@ -1139,10 +1139,11 @@ AC_ARG_ENABLE([bootstrap], enable_bootstrap=default) # Issue errors and warnings for invalid/strange bootstrap combinations. -case "$configdirs" in - *gcc*) have_compiler=yes ;; - *) have_compiler=no ;; -esac +if test -r $srcdir/gcc/configure; then + have_compiler=yes +else + have_compiler=no ;; +fi case "$have_compiler:$host:$target:$enable_bootstrap" in *:*:*:no) ;;
Re: Allow Tru64 UNIX bootstrap with C++
Rainer Orth writes:
> diff --git a/gcc/system.h b/gcc/system.h
> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -24,6 +24,10 @@ along with GCC; see the file COPYING3.
> #ifndef GCC_SYSTEM_H
> #define GCC_SYSTEM_H
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> /* We must include stdarg.h before stdio.h. */
> #include
>
> @@ -969,4 +973,8 @@ helper_const_non_const_cast (const char
> #define DEBUG_VARIABLE
> #endif
>
> +#ifdef __cplusplus
> +}
> +#endif
> +
> #endif /* ! GCC_SYSTEM_H */
I agree with Joseph that this is wrong. We must never wrap the #include
of a system header file with extern "C". That will simply break on some
systems. You should only wrap extern "C" around the various HAVE_DECL
declarations.
> diff --git a/include/xregex2.h b/include/xregex2.h
> --- a/include/xregex2.h
> +++ b/include/xregex2.h
> @@ -399,7 +399,11 @@ struct re_pattern_buffer
> typedef struct re_pattern_buffer regex_t;
>
> /* Type for byte offsets within the string. POSIX mandates this. */
> +#if defined(__osf__) && defined(__cplusplus)
> +typedef off_t regoff_t;
> +#else
> typedef int regoff_t;
> +#endif
No, the right way to handle this is to add regoff_t to include/xregex.h.
Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
David Edelsohn writes: > On Wed, Jul 20, 2011 at 4:25 PM, Ian Lance Taylor wrote: > >> Presumably the fix will be to use -frandom-seed. Does this patch fix >> the problem? (The only real change is to fragment.am, the other changes >> are all generated by automake). > > This patch gets the build past the compiler and runtime, although the > build time now is much longer on AIX. I have bootstrapped with the patch and run the libstdc++ testsuite on x86_64-unknown-linux-gnu. OK for mainline? Ian 2011-07-21 Ian Lance Taylor * fragment.am (CONFIG_CXXFLAGS): Add -frandom-seed. * Makefile.in: Rebuild. * doc/Makefile.in: Rebuild. * include/Makefile.in: Rebuild. * libsupc++/Makefile.in: Rebuild. * po/Makefile.in: Rebuild. * python/Makefile.in: Rebuild. * src/Makefile.in: Rebuild. * testsuite/Makefile.in: Rebuild. Index: fragment.am === --- fragment.am (revision 176515) +++ fragment.am (working copy) @@ -16,7 +16,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdi # These bits are all figured out from configure. Look in acinclude.m4 # or configure.ac to see how they are set. See GLIBCXX_EXPORT_FLAGS. CONFIG_CXXFLAGS = \ - $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) + $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once
Re: PATCH [8/n] X32: Convert to Pmode if needed
On Thu, Jul 21, 2011 at 3:00 AM, Uros Bizjak wrote:
> On Tue, Jul 19, 2011 at 6:47 AM, H.J. Lu wrote:
>
> So, since copy_to_reg & co. expects x in Pmode or VOIDmode constant
> (due to force_reg that won't do mode conversion), we have to implement
> them with a mode conversion...
>
>> This patch adds the missing Pmode check and conversion. OK for trunk?
>
>> 2011-07-18 H.J. Lu
>>
>> * config/i386/i386.c (ix86_legitimize_address): Convert to
>> Pmode if needed.
>> (ix86_expand_move): Likewise.
>> (ix86_expand_call): Likewise.
>> (ix86_expand_special_args_builtin): Likewise.
>> (ix86_expand_builtin): Likewise.
>>
>
>> @@ -21475,7 +21554,10 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx
>> callarg1,
>> ? !sibcall_insn_operand (XEXP (fnaddr, 0), Pmode)
>> : !call_insn_operand (XEXP (fnaddr, 0), Pmode))
>> {
>> - fnaddr = copy_to_mode_reg (Pmode, XEXP (fnaddr, 0));
>> + fnaddr = XEXP (fnaddr, 0);
>> + if (GET_MODE (fnaddr) != Pmode)
>> + fnaddr = convert_to_mode (Pmode, fnaddr, 1);
>> + fnaddr = copy_to_mode_reg (Pmode, fnaddr);
>> fnaddr = gen_rtx_MEM (QImode, fnaddr);
>> }
>>
>
> Use force_reg (Pmode, ...) instead of copy_to_mode_reg (Pmode, ...).
> We know we have Pmode here. No need to copy a register if
> convert_to_mode returned a register.
>
> Better yet:
>
> fnaddr = gen_rtx_MEM (QImode, force_reg (Pmode, fnaddr));
>
This caused the regression in 32bit:
[hjl@gnu-6 gcc]$ cat /tmp/x.i
f(x)
{
(*(void (*)())&x)();
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/x.i -m32 -O
/tmp/x.i: In function \u2018f\u2019:
/tmp/x.i:4:1: error: unrecognizable insn:
(call_insn 5 4 11 3 (call (mem:QI (reg/f:SI 53 virtual-incoming-args)
[0 *x.0_1 S1 A8])
(const_int 0 [0])) /tmp/x.i:3 -1
(nil)
(nil))
/tmp/x.i:4:1: internal compiler error: in extract_insn, at recog.c:2115
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[hjl@gnu-6 gcc]$
I checked in the enclosed patch as an obvious fix.
--
H.J.
---
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6456000..5ac6697 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
2011-07-21 H.J. Lu
+ * config/i386/i386.c (ix86_expand_call): Call copy_to_mode_reg
+ instead of force_reg.
+
+2011-07-21 H.J. Lu
+
* config/i386/i386.c (ix86_expand_move): Convert to Pmode if
needed and use force_reg after convert.
(ix86_expand_call): Likewise.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6e030d9..ddf674a 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -21545,7 +21545,7 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
fnaddr = XEXP (fnaddr, 0);
if (GET_MODE (fnaddr) != Pmode)
fnaddr = convert_to_mode (Pmode, fnaddr, 1);
- fnaddr = gen_rtx_MEM (QImode, force_reg (Pmode, fnaddr));
+ fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (Pmode, fnaddr));
}
call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1);
Re: PATCH [3/n] X32: Promote pointers to Pmode
On Thu, Jul 21, 2011 at 5:36 PM, H.J. Lu wrote:
> On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson wrote:
>> On 07/21/2011 04:28 PM, H.J. Lu wrote:
>>> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson wrote:
On 07/21/2011 03:02 PM, H.J. Lu wrote:
> * config/i386/i386.c (function_value_64): Always return pointers
> in Pmode.
> (ix86_promote_function_mode): New.
> (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
Much better, thanks.
r~
>>>
>>> Also need this patch. Otherwise, I got
>>>
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler
>>> error)
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess
>>> errors)
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler
>>> error)
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess
>>> errors)
>>>
>>> OK for trunk?
>>
>> Hmm. Should we even be running ms_64 callabi tests across pointer sizes
>> though?
>>
>
> Good question. I can disable the test. But compiler will still ICE on this
> input.
>
>
How about this patch? OK for trunk?
Thanks.
--
H.J.
---
gcc/
2011-07-21 H.J. Lu
* config/i386/i386.c (ix86_option_override_internal): Disallow
MS ABI in x32 mode.
(ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi
only for TARGET_LP64.
(ix86_handle_abi_attribute): Check TARGET_LP64 instead of
TARGET_64BIT.
gcc/testsuite/
2011-07-21 H.J. Lu
* gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32
instead of ia32.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9e3532e..6e030d9 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3133,6 +3133,9 @@ ix86_option_override_internal (bool main_args_p)
if (!global_options_set.x_ix86_abi)
ix86_abi = DEFAULT_ABI;
+ if (ix86_abi == MS_ABI && TARGET_X32)
+error ("MS ABI not supported in x32 mode");
+
if (global_options_set.x_ix86_cmodel)
{
switch (ix86_cmodel)
@@ -25520,7 +25523,7 @@ ix86_init_builtins (void)
ix86_init_mmx_sse_builtins ();
- if (TARGET_64BIT)
+ if (TARGET_LP64)
ix86_init_builtins_va_builtins_abi ();
#ifdef SUBTARGET_INIT_BUILTINS
@@ -29340,7 +29343,7 @@ ix86_handle_abi_attribute (tree *node, tree name,
*no_add_attrs = true;
return NULL_TREE;
}
- if (!TARGET_64BIT)
+ if (!TARGET_LP64)
{
warning (OPT_Wattributes, "%qE attribute only available for 64-bit",
name);
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
index b0cba17..e76d0c1 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
+++ b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
@@ -20,7 +20,7 @@
load_lib gcc-dg.exp
if { (![istarget x86_64-*-*] && ![istarget i?86-*-*])
- || [is-effective-target ia32] } then {
+ || [is-effective-target ilp32] } then {
return
}
[v3] testsuite renames
Some shortened pathnames from doc cleanup branch.
tested x86/linux
-benjamin2011-07-21 Benjamin Kosnik
* testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/tree_set_rand.cc: ... here.
* testsuite/ext/pb_ds/regression/tree_no_data_map_rand_debug.cc: Move...
* testsuite/ext/pb_ds/regression/tree_set_rand_debug.cc: ... here.
* testsuite/ext/pb_ds/regression/tree_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/tree_map_rand.cc: ... here.
* testsuite/ext/pb_ds/regression/tree_data_map_rand_debug.cc: Move...
* testsuite/ext/pb_ds/regression/tree_map_rand_debug.cc: ... here.
* testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/trie_set_rand.cc: ... here.
* testsuite/ext/pb_ds/regression/trie_no_data_map_rand_debug.cc: Move...
* testsuite/ext/pb_ds/regression/trie_set_rand_debug.cc: ... here.
* testsuite/ext/pb_ds/regression/trie_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/trie_map_rand.cc: ... here.
* testsuite/ext/pb_ds/regression/trie_data_map_rand_debug.cc: Move...
* testsuite/ext/pb_ds/regression/trie_map_rand_debug.cc: ... here.
* testsuite/ext/pb_ds/regression/list_update_no_data_map_rand.cc: Move.
* testsuite/ext/pb_ds/regression/list_update_set_rand.cc: ...here.
* testsuite/ext/pb_ds/regression/list_update_no_data_map_rand_debug.cc:
Move...
* testsuite/ext/pb_ds/regression/list_update_set_rand_debug.cc: ...here.
* testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/list_update_map_rand.cc: ...here.
* testsuite/ext/pb_ds/regression/list_update_data_map_rand_debug.cc:
Move...
* testsuite/ext/pb_ds/regression/list_update_map_rand_debug.cc: ...here.
* testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/hash_set_rand.cc: ...here.
* testsuite/ext/pb_ds/regression/hash_no_data_map_rand_debug.cc: Move...
* testsuite/ext/pb_ds/regression/hash_set_rand_debug.cc: ...here.
* testsuite/ext/pb_ds/regression/hash_data_map_rand.cc: Move...
* testsuite/ext/pb_ds/regression/hash_map_rand.cc: ...here.
* testsuite/ext/pb_ds/regression/hash_data_map_rand_debug.cc: Move...
* testsuite/ext/pb_ds/regression/hash_map_rand_debug.cc: ...here.
Index: testsuite/ext/pb_ds/regression/tree_no_data_map_rand_debug.cc
===
--- testsuite/ext/pb_ds/regression/tree_no_data_map_rand_debug.cc (revision 176612)
+++ testsuite/ext/pb_ds/regression/tree_no_data_map_rand_debug.cc (working copy)
@@ -1,144 +0,0 @@
-// { dg-require-debug-mode "" }
-// { dg-require-time "" }
-// This can take long on simulators, timing out the test.
-// { dg-options "-DITERATIONS=5" { target simulator } }
-// { dg-timeout-factor 2.0 }
-
-// -*- C++ -*-
-
-// Copyright (C) 2011 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: [PATCH, testsuite]: Fix detection of ifunc support
On Jul 21, 2011, at 3:29 PM, Uros Bizjak wrote: > Actually, we can use existing testsuite infrastructure to simplify the > function substantially. > > 2011-07-21 Uros Bizjak > >* lib/target-supports.exp (check_ifunc_available): Rewrite. > > The patch is tested on x86_64-pc-linux-gnu, but my toolchain does not > support ifunc attribute. Can somebody please test it with ifunc > support? > > OK for mainline and 4.6 ? Ok.
re: Fix argument pushes to unaligned stack slots
> On Tue, 12 Jul 2011, matthew green wrote: > > > i'm having a problem with GCC 4.5.3 on netbsd-m68k target. i've tracked > > it down to this change from several years ago: > > > > > 2007-02-06 Joseph Myers > > > > > > * expr.c (emit_push_insn): If STRICT_ALIGNMENT, copy to an > > > unaligned stack slot via a suitably aligned slot. > > > > the problem is that emit_library_call_value_1() calls emit_push_insn() > > with TYPE_NULL which ends up triggering a NULL deref when emit_push_insn() > > calls assign_temp() with type = TYPE_NULL, and assign_temp() crashes. > > > > this simple change seems to be sufficient to avoid the crash and the > > generated code appears to run OK. if it is OK, could someone please > > I don't see how it can be safe; if the stack slot is insufficiently > aligned, the special handling will be needed. Maybe the alignment being > passed to this code is wrong, but if it's correct then you need a way to > handle the unaligned move properly; I don't know if it would be possible > or safe to pass a non-NULL type here, for example. how can i confirm if it is wrong alignment being passed down? i looked around for a little bit to see if some non-NULL type could be passed in from emit_library_call_value_1() (or other callers in the path) but i did not see any way. i happy to play around with trying to fix this the right way, but i haven't looked at this part of GCC before so any guidance would be greatly appreciated. thanks. .mrg.
[PATCH] Fixed some compilation warnings
Hi,
This patch fixes 3 compiling warnings. One of them was actually a wrong
assert (operator precedence mistake).
Diogo Sousa
2011-07-22 Diogo Sousa
* natObject.cc: Fixed an expression inside an assert (it
always yield true). This was also a compiler warning.
* libcaf.h: Added prototypes of functions
_gfortran_caf_critical() and _gfortran_caf_end_critical to
prevent compiler warnings.
Index: libjava/java/lang/natObject.cc
===
--- libjava/java/lang/natObject.cc (revision 176583)
+++ libjava/java/lang/natObject.cc (working copy)
@@ -929,7 +929,7 @@ retry:
// only be held by other threads waiting for conversion, and
// they, like us, drop it quickly without blocking.
_Jv_MutexLock(&(hl->si.mutex));
- JvAssert(he -> address == address | LOCKED );
+ JvAssert(he -> address == (address | LOCKED));
release_set(&(he -> address), (address | REQUEST_CONVERSION |
HEAVY));
// release lock on he
LOG(REQ_CONV, (address | REQUEST_CONVERSION | HEAVY), self);
Index: libgfortran/caf/libcaf.h
===
--- libgfortran/caf/libcaf.h(revision 176583)
+++ libgfortran/caf/libcaf.h(working copy)
@@ -77,6 +77,9 @@ void _gfortran_caf_sync_images (int, int
/* FIXME: The CRITICAL functions should be removed;
the functionality is better represented using Coarray's lock
feature. */
+void _gfortran_caf_critical (void);
+void _gfortran_caf_end_critical (void);
+
void _gfortran_caf_critical (void) { }
void _gfortran_caf_end_critical (void) { }
signature.asc
Description: OpenPGP digital signature
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson wrote: > On 07/21/2011 10:39 AM, Uros Bizjak wrote: >> IMO, it is OK to disable 64bit relocations, and that compiler is at >> fault here. Consider that something gets written to the d field (see >> example of PR49798). Reading a pointer from *m fileld in DImode, we >> will get non-zero bits in high 32bits of a pointer. We have to access >> the pointer in SImode. > > IMO this is only tangentially related to the compiler at all. > I think disabling 64bit relocations is unnecessarily awkward > for assembly programmers. > > Consider when one wants to build jump tables. You either have to > have a register available for zero-extension, or do the .word x, 0 > thing. Which I think is being silly and arbitrary; the assembler > damned well knows what I want when I write .quad x. > I withdrew this patch. Assembler will accept ".quad foo" and zero-extend it to 8 byte. -- H.J.
Re: PATCH [3/n] X32: Promote pointers to Pmode
On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson wrote: > On 07/21/2011 04:28 PM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson wrote: >>> On 07/21/2011 03:02 PM, H.J. Lu wrote: * config/i386/i386.c (function_value_64): Always return pointers in Pmode. (ix86_promote_function_mode): New. (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >>> >>> Much better, thanks. >>> >>> >>> r~ >>> >> >> Also need this patch. Otherwise, I got >> >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler >> error) >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess >> errors) >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler >> error) >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess >> errors) >> >> OK for trunk? > > Hmm. Should we even be running ms_64 callabi tests across pointer sizes > though? > Good question. I can disable the test. But compiler will still ICE on this input. -- H.J.
Re: [RFC, cfg/dataflow] Properly split EH edges for -freorder-blocks-and-partition
On 07/21/2011 03:11 PM, Richard Henderson wrote: > On 07/21/2011 03:05 PM, Steven Bosscher wrote: >> On Thu, Jul 21, 2011 at 11:17 PM, Richard Henderson wrote: >> >>> Suggestions for something better than the df_finish_pass hack >>> that I added at the end of partition_hot_cold_basic_blocks are >>> very welcome. >> >> Is it not enough to just call df_bb_refs_record and df_analyze >> manually after you have created the basic block and the EH edges? > > df_bb_refs_record is static. Perhaps fixing that's the real > solution, but that's why I'm RFC'ing dataflow maintainers. I should mention here that I suspect the Cleanest solution is to make DF_DEFER_INSN_RESCAN imply that we also shouldn't grab data from the blocks those new insns are in either. In this way one can create the block, link it up properly, and have everything Just Work later, when deferred insns are processed. But I didn't immediately see a good way to do that. r~
Re: [PATCH 0/3] Move Graphite to CLooG 0.16.3 with isl backend.
Hi Tobias, On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote: > Hi, > > I propose to switch to the official cloog.org cloog version with isl backend > and > at the same time to remove support for both CLooG-PPL legacy as well as > CLooG-Parma. > Many thanks for implementing this cleanup. > We want to switch to cloog-isl as it is the only officially maintained version > of cloog. Furthermore, it provides features that will help to fix some bugs in > the graphite code generation[1]. > The reason to abond CLooG-PPL (legacy version) is, that cloog-isl provides the > new CloogInput library interface. This interface is not available the old > CLooG. > I plan to move graphite to this interface. As I do not see enough benefits > from > being able to use CLooG PPL, I decided to not introduce any compatibility > scheme, but just remove any code that is only needed for CLooG-PPL. > I also removed CLooG-Parma (cloog.org with PPL backend), as it is currently > not > actively maintained and not well tested. I believe our time is better spent on > improving graphite or cloog isl, as in putting time into this cloog version. > > So here we are: Moving graphite back to the official cloog.org version! > > Passes 'make check RUNTESTFLAGS=graphite.exp' as well as a bootstrap on Linux > amd64. > > Cheers > Tobi > > P.S.: Why do we move to the super latest one. Because we expect that most > users > would need an update, and, as we will soon use some of the newer features, > there > is no need to force another update later. > > > Tobias Grosser (3): > Make CLooG isl the only supported CLooG version. > Require cloog 0.16.3 > Remove code that supported legacy CLooG. For all your changes, you would need the ok from a configure maintainer. The changes to the graphite framework are ok. Thanks, Sebastian
Re: PATCH [3/n] X32: Promote pointers to Pmode
On 07/21/2011 04:28 PM, H.J. Lu wrote: > On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson wrote: >> On 07/21/2011 03:02 PM, H.J. Lu wrote: >>> * config/i386/i386.c (function_value_64): Always return pointers >>> in Pmode. >>> (ix86_promote_function_mode): New. >>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >> >> Much better, thanks. >> >> >> r~ >> > > Also need this patch. Otherwise, I got > > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler > error) > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess > errors) > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler > error) > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess > errors) > > OK for trunk? Hmm. Should we even be running ms_64 callabi tests across pointer sizes though? r~
Re: [PATCH 3/3] Remove code that supported legacy CLooG.
On 07/22/2011 01:46 AM, Sebastian Pop wrote:
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
static void
create_params_index (htab_t index_table, CloogProgram *prog) {
- CloogNames* names = cloog_program_names (prog);
- int nb_parameters = cloog_names_nb_parameters (names);
- char **parameters = cloog_names_parameters (names);
+ CloogNames* names = prog->names;
Please also fix the formatting here:
CloogNames *names = prog->names;
The rest of the patch looks good. Before checking in, please wait for a
configure maintainer to approve the config changes.
Thanks for the review. I will obviously wait for the OK of a configure
maintainer.
Tobi
Re: [PATCH 3/3] Remove code that supported legacy CLooG.
On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
> static void
> create_params_index (htab_t index_table, CloogProgram *prog) {
> - CloogNames* names = cloog_program_names (prog);
> - int nb_parameters = cloog_names_nb_parameters (names);
> - char **parameters = cloog_names_parameters (names);
> + CloogNames* names = prog->names;
Please also fix the formatting here:
CloogNames *names = prog->names;
The rest of the patch looks good. Before checking in, please wait for a
configure maintainer to approve the config changes.
Thanks,
Sebastian
Re: PATCH [3/n] X32: Promote pointers to Pmode
On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson wrote:
> On 07/21/2011 03:02 PM, H.J. Lu wrote:
>> * config/i386/i386.c (function_value_64): Always return pointers
>> in Pmode.
>> (ix86_promote_function_mode): New.
>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>
> Much better, thanks.
>
>
> r~
>
Also need this patch. Otherwise, I got
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors)
OK for trunk?
Thanks.
--
H.J.
--
2011-07-21 H.J. Lu
* config/i386/i386.c (function_value_ms_64): Take a new argument.
Always return pointers in Pmode.
(ix86_function_value_1): Updated.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b603f4e..9bc2eef 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7097,11 +7097,17 @@ function_value_64 (enum machine_mode
orig_mode, enum machine_mode mode,
}
static rtx
-function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode)
+function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode,
+ const_tree valtype)
{
unsigned int regno = AX_REG;
- if (TARGET_SSE)
+ if (valtype && POINTER_TYPE_P (valtype))
+{
+ /* Pointers are always returned in Pmode. */
+ orig_mode = Pmode;
+}
+ else if (TARGET_SSE)
{
switch (GET_MODE_SIZE (mode))
{
@@ -7134,7 +7140,7 @@ ix86_function_value_1 (const_tree valtype,
const_tree fntype_or_decl,
fntype = fn ? TREE_TYPE (fn) : fntype_or_decl;
if (TARGET_64BIT && ix86_function_type_abi (fntype) == MS_ABI)
-return function_value_ms_64 (orig_mode, mode);
+return function_value_ms_64 (orig_mode, mode, valtype);
else if (TARGET_64BIT)
return function_value_64 (orig_mode, mode, valtype);
else
[PATCH 3/3] Remove code that supported legacy CLooG.
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Do not define CLOOG_ORG
and in gcc/
2011-07-21 Tobias Grosser
* Makefile.in (graphite-clast-to-gimple.o, graphite-cloog-util.o):
Remove graphite-cloog-util.h.
* graphite-clast-to-gimple.c (gcc_type_for_iv_of_clast_loop,
build_iv_mapping, translate_clast_user, translate_clast,
free_scattering, initialize_cloog_names, build_cloog_prog,
create_params_index): Do not use old compatibility functions.
(clast_name_to_index, set_cloog_options): Remove code for legacy cloog.
* graphite-cloog-util.c (openscop_print_cloog_matrix): Do not use old
compatibility functions.
(new_Cloog_Scattering_from_ppl_Polyhedron): Remove code for legacy
cloog.
* graphite-cloog-util.h: Remove include of graphite-cloog-util.h.
* graphite.c (graphite.c): Do not call outdated cloog_initialize() and
cloog_finalize().
* graphite-cloog-compat.h: Remove.
---
ChangeLog |5 +
config/cloog.m4|2 +-
configure |2 +-
gcc/ChangeLog | 18 +++
gcc/Makefile.in|4 +-
gcc/graphite-clast-to-gimple.c | 93 ++
gcc/graphite-cloog-compat.h| 275
gcc/graphite-cloog-util.c | 15 +--
gcc/graphite-cloog-util.h |1 -
gcc/graphite.c |2 -
10 files changed, 72 insertions(+), 345 deletions(-)
delete mode 100644 gcc/graphite-cloog-compat.h
diff --git a/ChangeLog b/ChangeLog
index 3d83bd2..9499da4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,11 @@
2011-07-21 Tobias Grosser
* configure: Regenerated.
+ * config/cloog.m4: Do not define CLOOG_ORGt
+
+2011-07-21 Tobias Grosser
+
+ * configure: Regenerated.
* configure.ac: Require cloog isl 0.16.3
2011-07-21 Tobias Grosser
diff --git a/config/cloog.m4 b/config/cloog.m4
index 8662acd..9c42445 100644
--- a/config/cloog.m4
+++ b/config/cloog.m4
@@ -109,7 +109,7 @@ AC_DEFUN([CLOOG_FIND_FLAGS],
_cloog_saved_LDFLAGS=$LDFLAGS
_cloog_saved_LIBS=$LIBS
- _cloogorginc="-DCLOOG_INT_GMP -DCLOOG_ORG"
+ _cloogorginc="-DCLOOG_INT_GMP"
dnl clooglibs & clooginc may have been initialized by CLOOG_INIT_FLAGS.
CFLAGS="${CFLAGS} ${clooginc} ${gmpinc}"
diff --git a/configure b/configure
index 57f099b..8de7bc69 100755
--- a/configure
+++ b/configure
@@ -5771,7 +5771,7 @@ if test "x$with_cloog" != "xno"; then
_cloog_saved_LDFLAGS=$LDFLAGS
_cloog_saved_LIBS=$LIBS
- _cloogorginc="-DCLOOG_INT_GMP -DCLOOG_ORG"
+ _cloogorginc="-DCLOOG_INT_GMP"
CFLAGS="${CFLAGS} ${clooginc} ${gmpinc}"
CPPFLAGS="${CPPFLAGS} ${_cloogorginc}"
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b9d95fa..b6009b7 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,21 @@
+2011-07-21 Tobias Grosser
+
+ * Makefile.in (graphite-clast-to-gimple.o, graphite-cloog-util.o):
+ Remove graphite-cloog-util.h.
+ * graphite-clast-to-gimple.c (gcc_type_for_iv_of_clast_loop,
+ build_iv_mapping, translate_clast_user, translate_clast,
+ free_scattering, initialize_cloog_names, build_cloog_prog,
+ create_params_index): Do not use old compatibility functions.
+ (clast_name_to_index, set_cloog_options): Remove code for legacy cloog.
+ * graphite-cloog-util.c (openscop_print_cloog_matrix): Do not use old
+ compatibility functions.
+ (new_Cloog_Scattering_from_ppl_Polyhedron): Remove code for legacy
+ cloog.
+ * graphite-cloog-util.h: Remove include of graphite-cloog-util.h.
+ * graphite.c (graphite.c): Do not call outdated cloog_initialize() and
+ cloog_finalize().
+ * graphite-cloog-compat.h: Remove.
+
2011-07-21 Georg-Johann Lay
* config/avr/avr.c (final_prescan_insn): Fix printing of rtx_costs.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index d924fb6..c5a2f7f 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2690,9 +2690,9 @@ graphite-clast-to-gimple.o : graphite-clast-to-gimple.c
$(CONFIG_H) \
$(SYSTEM_H) coretypes.h $(DIAGNOSTIC_CORE_H) $(TREE_FLOW_H) $(TREE_DUMP_H) \
$(CFGLOOP_H) $(TREE_DATA_REF_H) sese.h graphite-cloog-util.h \
graphite-ppl.h graphite-poly.h graphite-clast-to-gimple.h \
- graphite-dependences.h graphite-cloog-compat.h
+ graphite-dependences.h
graphite-cloog-util.o : graphite-cloog-util.c $(CONFIG_H) $(SYSTEM_H) \
- coretypes.h graphite-cloog-util.h graphite-cloog-compat.h
+ coretypes.h graphite-cloog-util.h
graphite-dependences.o : graphite-dependences.c $(CONFIG_H) $(SYSTEM_H) \
coretypes.h $(TREE_FLOW_H) $(TREE_DUMP_H) $(CFGLOOP_H) $(TREE_DATA_REF_H) \
sese.h graphite-ppl.h graphite-poly.h graphite-dependences.h \
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 6b17631..da9b84f 1006
[PATCH 1/3] Make CLooG isl the only supported CLooG version.
2011-07-21 Tobias Grosser
* configure: Regenerated.
* config/cloog.m4: Remove support for CLooG-ppl and CLooG-parma,
both cloog.org and legacy versions. The only supported version will
be CLooG with the isl backend.
---
ChangeLog |7 ++
config/cloog.m4 | 107 +++---
configure | 170 +++
3 files changed, 26 insertions(+), 258 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 6a27fb7..a08a780 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-07-21 Tobias Grosser
+
+ * configure: Regenerated.
+ * config/cloog.m4: Remove support for CLooG-ppl and CLooG-parma,
+ both cloog.org and legacy versions. The only supported version will
+ be CLooG with the isl backend.
+
2011-07-21 Joseph Myers
* MAINTAINERS (Global Reviewers): Add self.
diff --git a/config/cloog.m4 b/config/cloog.m4
index e95b98d..8662acd 100644
--- a/config/cloog.m4
+++ b/config/cloog.m4
@@ -37,17 +37,6 @@ AC_DEFUN([CLOOG_INIT_FLAGS],
[--with-cloog-lib=PATH],
[Specify the directory for the installed CLooG library])])
- AC_ARG_ENABLE(cloog-backend,
-[AS_HELP_STRING(
- [--enable-cloog-backend[[=BACKEND]]],
- [set the CLooG BACKEND used to either isl, ppl or ppl-legacy
(default)])],
-[ if test "x${enableval}" = "xisl"; then
- cloog_backend=isl
- elif test "x${enableval}" = "xppl"; then
- cloog_backend=ppl
- else
- cloog_backend=ppl-legacy
- fi], cloog_backend=ppl-legacy)
AC_ARG_ENABLE(cloog-version-check,
[AS_HELP_STRING(
[--disable-cloog-version-check],
@@ -107,23 +96,6 @@ m4_define([_CLOOG_ORG_PROG_ISL],[AC_LANG_PROGRAM(
[#include "cloog/cloog.h" ],
[cloog_version ()])])
-# _CLOOG_ORG_PROG_PPL ()
-# --
-# Helper for detecting CLooG.org's PPL backend.
-m4_define([_CLOOG_ORG_PROG_PPL],[AC_LANG_PROGRAM(
- [#include "cloog/cloog.h"
- #include "cloog/ppl/cloog.h"],
- [cloog_version ()])])
-
-# _CLOOG_PPL_LEGACY_PROG ()
-# -
-# Helper for detecting CLooG-Legacy (CLooG-PPL).
-m4_define([_CLOOG_PPL_LEGACY_PROG], [AC_LANG_PROGRAM(
- [#include "cloog/cloog.h"],
- [#ifndef CLOOG_PPL_BACKEND
-choke me
- #endif ])])
-
# CLOOG_FIND_FLAGS ()
# --
# Detect the used CLooG-backend and set clooginc/clooglibs/cloog_org.
@@ -144,49 +116,17 @@ AC_DEFUN([CLOOG_FIND_FLAGS],
CPPFLAGS="${CPPFLAGS} ${_cloogorginc}"
LDFLAGS="${LDFLAGS} ${clooglibs}"
- case $cloog_backend in
-"ppl-legacy")
-CFLAGS="${CFLAGS} ${pplinc}"
-LDFLAGS="${LDFLAGS} ${ppllibs}"
-AC_CACHE_CHECK([for installed CLooG PPL Legacy], [gcc_cv_cloog_type],
- [LIBS="-lcloog ${_cloog_saved_LIBS}"
- AC_LINK_IFELSE([_CLOOG_PPL_LEGACY_PROG], [gcc_cv_cloog_type="PPL
Legacy"],
-[gcc_cv_cloog_type=no])])
-;;
-"isl")
-AC_CACHE_CHECK([for installed CLooG ISL], [gcc_cv_cloog_type],
- [LIBS="-lcloog-isl ${_cloog_saved_LIBS}"
- AC_LINK_IFELSE([_CLOOG_ORG_PROG_ISL], [gcc_cv_cloog_type="ISL"],
-[gcc_cv_cloog_type=no])])
-;;
-"ppl")
-CFLAGS="${CFLAGS} ${pplinc}"
-LDFLAGS="${LDFLAGS} ${ppllibs}"
-AC_CACHE_CHECK([for installed CLooG PPL], [gcc_cv_cloog_type],
- [LIBS="-lcloog-ppl ${_cloog_saved_LIBS}"
- AC_LINK_IFELSE([_CLOOG_ORG_PROG_PPL], [gcc_cv_cloog_type="PPL"],
-[gcc_cv_cloog_type=no])])
-;;
-*)
- gcc_cv_cloog_type=""
- esac
+ AC_CACHE_CHECK([for installed CLooG ISL], [gcc_cv_cloog_type],
+[LIBS="-lcloog-isl ${_cloog_saved_LIBS}"
+AC_LINK_IFELSE([_CLOOG_ORG_PROG_ISL], [gcc_cv_cloog_type="ISL"],
+ [gcc_cv_cloog_type=no])])
case $gcc_cv_cloog_type in
-"PPL Legacy")
- clooginc="${clooginc}"
- clooglibs="${clooglibs} -lcloog"
- cloog_org=no
- ;;
"ISL")
clooginc="${clooginc} ${_cloogorginc}"
clooglibs="${clooglibs} -lcloog-isl -lisl"
cloog_org=yes
;;
-"PPL")
- clooginc="${clooginc} ${_cloogorginc}"
- clooglibs="${clooglibs} -lcloog-ppl"
- cloog_org=yes
- ;;
*)
clooglibs=
clooginc=
@@ -212,25 +152,10 @@ m4_define([_CLOOG_CHECK_CT_PROG],[AC_LANG_PROGRAM(
choke me
#endif])])
-# _CLOOG_CHECK_RT_PROG ()
-# ---
-# Helper for verifying that CLooG's compile time version
-# matches the run time version.
-m4_define([_CLOOG_CHECK_RT_PROG],[AC_LANG_PROGRAM(
- [#include "cloog/cloog.h"],
- [if ((cloog_version_major () != CLOOG_VERSION_MAJOR)
-&& (cloog_version_minor () != CLOOG_VERSION_MINOR)
-&& (cloog_version_revision () != CLOOG_VERSION_REVISION))
-{
- return 1;
-}])])
-
# CLOOG_CHECK_VERSION CLOOG_CHECK_VERSION (MAJOR, MINOR, REVISION)
#
# Test the found CLooG to be exact of version
[PATCH 2/3] Require cloog 0.16.3
2011-07-21 Tobias Grosser
* configure: Regenerated.
* configure.ac: Require cloog isl 0.16.3
---
ChangeLog|5 +
configure|6 +++---
configure.ac |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a08a780..3d83bd2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,11 @@
2011-07-21 Tobias Grosser
* configure: Regenerated.
+ * configure.ac: Require cloog isl 0.16.3
+
+2011-07-21 Tobias Grosser
+
+ * configure: Regenerated.
* config/cloog.m4: Remove support for CLooG-ppl and CLooG-parma,
both cloog.org and legacy versions. The only supported version will
be CLooG with the isl backend.
diff --git a/configure b/configure
index 6608b86..57f099b 100755
--- a/configure
+++ b/configure
@@ -5834,8 +5834,8 @@ $as_echo "$gcc_cv_cloog_type" >&6; }
CFLAGS="${_cloog_saved_CFLAGS} ${clooginc} ${pplinc} ${gmpinc}"
LDFLAGS="${_cloog_saved_LDFLAGS} ${clooglibs} ${ppllibs}"
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for version 0.16.1 of
CLooG" >&5
-$as_echo_n "checking for version 0.16.1 of CLooG... " >&6; }
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for version 0.16.3 of
CLooG" >&5
+$as_echo_n "checking for version 0.16.3 of CLooG... " >&6; }
if test "${gcc_cv_cloog+set}" = set; then :
$as_echo_n "(cached) " >&6
else
@@ -5847,7 +5847,7 @@ main ()
{
#if CLOOG_VERSION_MAJOR != 0 \
|| CLOOG_VERSION_MINOR != 16 \
-|| CLOOG_VERSION_REVISION < 1
+|| CLOOG_VERSION_REVISION < 3
choke me
#endif
;
diff --git a/configure.ac b/configure.ac
index e64e577..00325a1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1588,7 +1588,7 @@ if test "x$with_cloog" != "xno"; then
dnl
dnl If we use CLooG-Legacy, the provided version information is
dnl ignored.
- CLOOG_CHECK_VERSION(0,16,1)
+ CLOOG_CHECK_VERSION(0,16,3)
dnl Only execute fail-action, if CLooG has been requested.
CLOOG_IF_FAILED([
--
1.7.4.1
[PATCH 0/3] Move Graphite to CLooG 0.16.3 with isl backend.
Hi, I propose to switch to the official cloog.org cloog version with isl backend and at the same time to remove support for both CLooG-PPL legacy as well as CLooG-Parma. We want to switch to cloog-isl as it is the only officially maintained version of cloog. Furthermore, it provides features that will help to fix some bugs in the graphite code generation[1]. The reason to abond CLooG-PPL (legacy version) is, that cloog-isl provides the new CloogInput library interface. This interface is not available the old CLooG. I plan to move graphite to this interface. As I do not see enough benefits from being able to use CLooG PPL, I decided to not introduce any compatibility scheme, but just remove any code that is only needed for CLooG-PPL. I also removed CLooG-Parma (cloog.org with PPL backend), as it is currently not actively maintained and not well tested. I believe our time is better spent on improving graphite or cloog isl, as in putting time into this cloog version. So here we are: Moving graphite back to the official cloog.org version! Passes 'make check RUNTESTFLAGS=graphite.exp' as well as a bootstrap on Linux amd64. Cheers Tobi P.S.: Why do we move to the super latest one. Because we expect that most users would need an update, and, as we will soon use some of the newer features, there is no need to force another update later. Tobias Grosser (3): Make CLooG isl the only supported CLooG version. Require cloog 0.16.3 Remove code that supported legacy CLooG. ChangeLog | 17 +++ config/cloog.m4| 109 ++-- configure | 176 ++ configure.ac |2 +- gcc/ChangeLog | 18 +++ gcc/Makefile.in|4 +- gcc/graphite-clast-to-gimple.c | 93 ++ gcc/graphite-cloog-compat.h| 275 gcc/graphite-cloog-util.c | 15 +-- gcc/graphite-cloog-util.h |1 - gcc/graphite.c |2 - 11 files changed, 106 insertions(+), 606 deletions(-) delete mode 100644 gcc/graphite-cloog-compat.h -- 1.7.4.1
[PATCH] GNU/kFreeBSD systems running on MIPS
This patch adds support for GNU/kFreeBSD systems running on MIPS.
--
Robert Millan
2011-07-22 Robert Millan
Support for GNU/kFreeBSD systems running on MIPS.
* config.gcc: Detect mips*-*-kfreebsd*-gnu.
* config.host: Likewise.
* config/mips/kfreebsd-gnu.h: New file.
* config/mips/kfreebsd-gnu64.h: New file.
* config/mips/gnu-user.h: Restrict `-march=native' support to GNU/Linux.
Index: libgcc/config.host
===
--- libgcc/config.host (revision 176595)
+++ libgcc/config.host (working copy)
@@ -478,6 +478,14 @@
tmake_file="{$tmake_file} t-crtfm"
md_unwind_header=mips/linux-unwind.h
;;
+mips64*-*-kfreebsd*-gnu)
+ extra_parts="$extra_parts crtfastmath.o"
+ tmake_file="{$tmake_file} t-crtfm"
+ ;;
+mips*-*-kfreebsd*-gnu) # GNU/kFreeBSD MIPS, either endian.
+ extra_parts="$extra_parts crtfastmath.o"
+ tmake_file="{$tmake_file} t-crtfm"
+ ;;
mips*-*-openbsd*)
;;
mipsisa32-*-elf* | mipsisa32el-*-elf*)
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 176595)
+++ gcc/config.gcc (working copy)
@@ -1819,20 +1819,28 @@
tm_file="elfos.h ${tm_file} mips/elf.h netbsd.h netbsd-elf.h mips/netbsd.h"
extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
;;
-mips64*-*-linux* | mipsisa64*-*-linux*)
- tm_file="dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h ${tm_file} mips/gnu-user.h mips/gnu-user64.h mips/linux64.h"
+mips64*-*-linux* | mipsisa64*-*-linux* | mips64*-*-kfreebsd*-gnu | mipsisa64*-*-kfreebsd*-gnu)
+ tm_file="dbxelf.h elfos.h gnu-user.h glibc-stdint.h ${tm_file} mips/gnu-user.h mips/gnu-user64.h"
tmake_file="${tmake_file} mips/t-linux64 mips/t-libgcc-mips16"
tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
+ case ${target_os} in
+ linux*)
+ tm_file="${tm_file} linux.h mips/linux64.h"
+ ;;
+ kfreebsd*-gnu)
+ tm_file="${tm_file} kfreebsd-gnu.h mips/kfreebsd-gnu64.h"
+ ;;
+ esac
case ${target} in
- mips64el-st-linux-gnu)
+ mips64el-st-*)
tm_file="${tm_file} mips/st.h"
tmake_file="${tmake_file} mips/t-st"
;;
- mips64octeon*-*-linux*)
+ mips64octeon*-*-*)
tm_defines="${tm_defines} MIPS_CPU_STRING_DEFAULT=\\\"octeon\\\""
target_cpu_default=MASK_SOFT_FLOAT_ABI
;;
- mipsisa64r2*-*-linux*)
+ mipsisa64r2*-*-*)
tm_defines="${tm_defines} MIPS_ISA_DEFAULT=65"
;;
esac
@@ -1841,11 +1849,27 @@
gas=yes
test x$with_llsc != x || with_llsc=yes
;;
-mips*-*-linux*)# Linux MIPS, either endian.
-tm_file="dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h ${tm_file} mips/gnu-user.h mips/linux.h"
+mips*-*-linux* | mips*-*-kfreebsd*-gnu) # GNU/* MIPS, either endian.
+tm_file="dbxelf.h elfos.h gnu-user.h glibc-stdint.h ${tm_file} mips/gnu-user.h"
tmake_file="${tmake_file} mips/t-libgcc-mips16"
+ case ${target_os} in
+ linux*)
+ tm_file="${tm_file} linux.h mips/linux.h"
+ ;;
+ kfreebsd*-gnu)
+ tm_file="${tm_file} kfreebsd-gnu.h mips/kfreebsd-gnu.h"
+ ;;
+ esac
if test x$enable_targets = xall; then
- tm_file="${tm_file} mips/gnu-user64.h mips/linux64.h"
+ tm_file="${tm_file} mips/gnu-user64.h"
+ case ${target_os} in
+ linux*)
+tm_file="${tm_file} mips/linux64.h"
+;;
+ kfreebsd*-gnu)
+tm_file="${tm_file} mips/kfreebsd-gnu64.h"
+;;
+ esac
tmake_file="${tmake_file} mips/t-linux64"
tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_32"
fi
Index: gcc/config/mips/gnu-user.h
===
--- gcc/config/mips/gnu-user.h (revision 176595)
+++ gcc/config/mips/gnu-user.h (working copy)
@@ -106,8 +106,8 @@
#endif
/* -march=native handling only makes sense with compiler running on
- a MIPS chip. */
-#if defined(__mips__)
+ a MIPS chip. Also, for now only Linux targets are supported. */
+#if defined(__mips__) && defined(__linux__)
extern const char *host_detect_local_cpu (int argc, const char **argv);
# define EXTRA_SPEC_FUNCTIONS \
{ "local_cpu_detect", host_detect_local_cpu },
Index: gcc/config/mips/kfreebsd-gnu64.h
===
--- gcc/config/mips/kfreebsd-gnu64.h (revision 0)
+++ gcc/config/mips/kfreebsd-gnu64.h (revision 0)
@@ -0,0 +1,31 @@
+/* Definitions for MIPS running kFreeBSD-based GNU systems with ELF format
+ using n32/64 abi.
+ Copyright (C) 2011
+ Free Software Foundation, Inc.
+ Contributed by Robert Millan.
+
+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 t
Re: [PATCH, testsuite]: Fix detection of ifunc support
On Thu, Jul 21, 2011 at 11:56 PM, Uros Bizjak wrote:
> Revision 164725 [1] broke detection of ifunc support in the testsuite
> [2] due to extra "#endif" without if in the test function. Attached
> patch fixes this up.
Actually, we can use existing testsuite infrastructure to simplify the
function substantially.
2011-07-21 Uros Bizjak
* lib/target-supports.exp (check_ifunc_available): Rewrite.
The patch is tested on x86_64-pc-linux-gnu, but my toolchain does not
support ifunc attribute. Can somebody please test it with ifunc
support?
OK for mainline and 4.6 ?
Uros.
Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 176584)
+++ lib/target-supports.exp (working copy)
@@ -361,45 +361,16 @@
return $alias_available_saved
}
-###
-# proc check_ifunc_available { }
-###
+# Returns 1 if the target supports ifunc, 0 otherwise.
-# Determine if the target toolchain supports the ifunc attribute.
-
-# Returns 1 if the target supports ifunc. Returns 0 if the target
-# does not support ifunc.
-
proc check_ifunc_available { } {
-global ifunc_available_saved
-global tool
-
-if [info exists ifunc_available_saved] {
-verbose "check_ifunc_available returning saved
$ifunc_available_saved" 2
-} else {
- set src ifunc[pid].c
- set obj ifunc[pid].o
-verbose "check_ifunc_available compiling testfile $src" 2
- set f [open $src "w"]
- puts $f "#endif"
- puts $f "#ifdef __cplusplus\nextern \"C\"\n#endif"
- puts $f "void g() {}"
- puts $f "void f() __attribute__((ifunc(\"g\")));"
- close $f
- set lines [${tool}_target_compile $src $obj object ""]
- file delete $src
- remote_file build delete $obj
-
- if [string match "" $lines] then {
- set ifunc_available_saved 1
- } else {
- set ifunc_available_saved 0
- }
-
- verbose "check_ifunc_available returning $ifunc_available_saved" 2
-}
-
-return $ifunc_available_saved
+return [check_no_compiler_messages ifunc_available object {
+ #ifdef __cplusplus
+ extern "C"
+ #endif
+ void g() {}
+ f() __attribute__((ifunc("g")));
+}]
}
# Returns true if --gc-sections is supported on the target.
[patch] attribute to reverse bitfield allocations
Seeing little opposition, I plod further... now with documentation
and a test case. OK yet?
Index: doc/extend.texi
===
--- doc/extend.texi (revision 176586)
+++ doc/extend.texi (working copy)
@@ -5089,12 +5089,74 @@ Note that the type visibility is applied
associated with the class (vtable, typeinfo node, etc.). In
particular, if a class is thrown as an exception in one shared object
and caught in another, the class must have default visibility.
Otherwise the two shared objects will be unable to use the same
typeinfo node and exception handling will break.
+@item bit_order
+Normally, GCC allocates bitfields from either the least significant or
+most significant bit in the underlying type, such that bitfields
+happen to be allocated from lowest address to highest address.
+Specifically, big-endian targets allocate the MSB first, where
+little-endian targets allocate the LSB first. The @code{bit_order}
+attribute overrides this default, allowing you to force allocation to
+be MSB-first, LSB-first, or the opposite of whatever gcc defaults to. The
+@code{bit_order} attribute takes an optional argument:
+
+@table @code
+
+@item native
+This is the default, and also the mode when no argument is given. GCC
+allocates LSB-first on little endian targets, and MSB-first on big
+endian targets.
+
+@item swapped
+Bitfield allocation is the opposite of @code{native}.
+
+@item lsb
+Bits are allocated LSB-first.
+
+@item msb
+Bits are allocated MSB-first.
+
+@end table
+
+A short example demonstrates bitfield allocation:
+
+@example
+struct __attribute__((bit_order(msb))) @{
+ char a:3;
+ char b:3;
+@} foo = @{ 3, 5 @};
+@end example
+
+With LSB-first allocation, @code{foo.a} will be in the 3 least
+significant bits (mask 0x07) and @code{foo.b} will be in the next 3
+bits (mask 0x38). With MSB-first allocation, @code{foo.a} will be in
+the 3 most significant bits (mask 0xE0) and @code{foo.b} will be in
+the next 3 bits (mask 0x1C).
+
+Note that it is entirely up to the programmer to define bitfields that
+make sense when swapped. Consider:
+
+@example
+struct __attribute__((bit_order(msb))) @{
+ short a:7;
+ char b:6;
+@} foo = @{ 3, 5 @};
+@end example
+
+On some targets, or if the struct is @code{packed}, GCC may only use
+one byte of storage for A despite it being a @code{short} type.
+Swapping the bit order of A would cause it to overlap B. Worse, the
+bitfield for B may span bytes, so ``swapping'' would no longer be
+defined as there is no ``char'' to swap within. To avoid such
+problems, the programmer should either fully-define each underlying
+type, or ensure that their target's ABI allocates enough space for
+each underlying type regardless of how much of it is used.
+
@end table
@subsection ARM Type Attributes
On those ARM targets that support @code{dllimport} (such as Symbian
OS), you can use the @code{notshared} attribute to indicate that the
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 176586)
+++ c-family/c-common.c (working copy)
@@ -312,12 +312,13 @@ struct visibility_flags visibility_optio
static tree c_fully_fold_internal (tree expr, bool, bool *, bool *);
static tree check_case_value (tree);
static bool check_case_bounds (tree, tree, tree *, tree *);
static tree handle_packed_attribute (tree *, tree, tree, int, bool *);
+static tree handle_bitorder_attribute (tree *, tree, tree, int, bool *);
static tree handle_nocommon_attribute (tree *, tree, tree, int, bool *);
static tree handle_common_attribute (tree *, tree, tree, int, bool *);
static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
static tree handle_hot_attribute (tree *, tree, tree, int, bool *);
static tree handle_cold_attribute (tree *, tree, tree, int, bool *);
static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
@@ -589,12 +590,14 @@ const unsigned int num_c_common_reswords
const struct attribute_spec c_common_attribute_table[] =
{
/* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
affects_type_identity } */
{ "packed", 0, 0, false, false, false,
handle_packed_attribute , false},
+ { "bit_order", 0, 1, false, true, false,
+ handle_bitorder_attribute , false},
{ "nocommon", 0, 0, true, false, false,
handle_nocommon_attribute, false},
{ "common", 0, 0, true, false, false,
handle_common_attribute, false },
/* FIXME: logically, noreturn attributes should be listed as
"false, true, true" and apply to function types. But implementing this
@@ -5764,12 +5767,42 @@ handle_packed_attribute (tree *node, tre
*no_add_attrs = true;
}
return NULL_TREE;
}
+/* Handle a "bit_o
Re: [RFC, cfg/dataflow] Properly split EH edges for -freorder-blocks-and-partition
On 07/21/2011 03:05 PM, Steven Bosscher wrote: > On Thu, Jul 21, 2011 at 11:17 PM, Richard Henderson wrote: > >> Suggestions for something better than the df_finish_pass hack >> that I added at the end of partition_hot_cold_basic_blocks are >> very welcome. > > Is it not enough to just call df_bb_refs_record and df_analyze > manually after you have created the basic block and the EH edges? df_bb_refs_record is static. Perhaps fixing that's the real solution, but that's why I'm RFC'ing dataflow maintainers. I tried just df_scan_blocks, which is as close to df_bb_refs_record as one can get with what's currently exported, but then you run into problems with assertions that we havn't previously collected df info. Which is what led me to just copy the finish/alloc/scan/analyze sequence you see here from ira.c. r~
Re: [RFC, cfg/dataflow] Properly split EH edges for -freorder-blocks-and-partition
On Thu, Jul 21, 2011 at 11:17 PM, Richard Henderson wrote: > Suggestions for something better than the df_finish_pass hack > that I added at the end of partition_hot_cold_basic_blocks are > very welcome. Is it not enough to just call df_bb_refs_record and df_analyze manually after you have created the basic block and the EH edges? Ciao! Steven
Re: PATCH [3/n] X32: Promote pointers to Pmode
On 07/21/2011 03:02 PM, H.J. Lu wrote: > * config/i386/i386.c (function_value_64): Always return pointers > in Pmode. > (ix86_promote_function_mode): New. > (TARGET_PROMOTE_FUNCTION_MODE): Likewise. Much better, thanks. r~
Re: PATCH [3/n] X32: Promote pointers to Pmode
On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson wrote:
> On 07/13/2011 08:35 AM, H.J. Lu wrote:
>> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson wrote:
>>> On 07/13/2011 07:02 AM, H.J. Lu wrote:
Hi Richard,
Is my patch OK?
>>>
>>> No, I don't think it is.
>>>
>>
>> What is your suggestion?
>
> Promote the return value. If that means it doesn't match function_value,
> then I suggest that function_value is wrong.
>
>
> r~
>
This is the patch I am testing. I will check it in if it works.
Thanks.
--
H.J.
---
2011-07-21 H.J. Lu
* config/i386/i386.c (function_value_64): Always return pointers
in Pmode.
(ix86_promote_function_mode): New.
(TARGET_PROMOTE_FUNCTION_MODE): Likewise.
2011-07-21 H.J. Lu
* config/i386/i386.c (function_value_64): Always return pointers
in Pmode.
(ix86_promote_function_mode): New.
(TARGET_PROMOTE_FUNCTION_MODE): Likewise.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index da6c888..32af303 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7078,6 +7078,11 @@ function_value_64 (enum machine_mode orig_mode, enum machine_mode mode,
return gen_rtx_REG (mode, AX_REG);
}
}
+ else if (POINTER_TYPE_P (valtype))
+{
+ /* Pointers are always returned in Pmode. */
+ mode = Pmode;
+}
ret = construct_container (mode, orig_mode, valtype, 1,
X86_64_REGPARM_MAX, X86_64_SSE_REGPARM_MAX,
@@ -7147,6 +7152,22 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl,
return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
}
+/* Pointer function arguments and return values are promoted to Pmode. */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+ int *punsignedp, const_tree fntype,
+ int for_return)
+{
+ if (type != NULL_TREE && POINTER_TYPE_P (type))
+{
+ *punsignedp = POINTERS_EXTEND_UNSIGNED;
+ return Pmode;
+}
+ return default_promote_function_mode (type, mode, punsignedp, fntype,
+ for_return);
+}
+
rtx
ix86_libcall_value (enum machine_mode mode)
{
@@ -34970,6 +35055,9 @@ ix86_autovectorize_vector_sizes (void)
#undef TARGET_FUNCTION_VALUE_REGNO_P
#define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p
+#undef TARGET_PROMOTE_FUNCTION_MODE
+#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
+
#undef TARGET_SECONDARY_RELOAD
#define TARGET_SECONDARY_RELOAD ix86_secondary_reload
[PATCH, testsuite]: Fix detection of ifunc support
Hello!
Revision 164725 [1] broke detection of ifunc support in the testsuite
[2] due to extra "#endif" without if in the test function. Attached
patch fixes this up.
2011-07-21 Uros Bizjak
* lib/target-supports.exp (check_ifunc_available): Fix test function.
The patch is tested on x86_64-pc-linux-gnu, but my toolchain does not
support ifunc attribute. Can somebody please test it with ifunc
support?
OTOH, the patch is kind of obvious, so OK for mainline?
[1] http://gcc.gnu.org/viewcvs?view=revision&revision=164725
[2]
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/lib/target-supports.exp?r1=164725&r2=164724&pathrev=164725
Uros.
Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 176584)
+++ lib/target-supports.exp (working copy)
@@ -381,10 +381,8 @@
set obj ifunc[pid].o
verbose "check_ifunc_available compiling testfile $src" 2
set f [open $src "w"]
- puts $f "#endif"
puts $f "#ifdef __cplusplus\nextern \"C\"\n#endif"
- puts $f "void g() {}"
- puts $f "void f() __attribute__((ifunc(\"g\")));"
+ puts $f "void g() {} f() __attribute__((ifunc(\"g\")));"
close $f
set lines [${tool}_target_compile $src $obj object ""]
file delete $src
cp/cvt: don't assume pointer sizes
Some targets (m32c, tpf, mips) have more than one pointer size. It is
not correct to assume that a pointer is POINTER_SIZE.
Index: gcc/cp/cvt.c
===
--- gcc/cp/cvt.c(revision 176554)
+++ gcc/cp/cvt.c(working copy)
@@ -217,15 +217,16 @@ cp_convert_to_pointer (tree type, tree e
error ("invalid conversion from %qT to %qT", intype, type);
return error_mark_node;
}
if (INTEGRAL_CODE_P (form))
{
- if (TYPE_PRECISION (intype) == POINTER_SIZE)
+ int this_pointer_size = TYPE_PRECISION (type);
+ if (TYPE_PRECISION (intype) == this_pointer_size)
return build1 (CONVERT_EXPR, type, expr);
- expr = cp_convert (c_common_type_for_size (POINTER_SIZE, 0), expr);
+ expr = cp_convert (c_common_type_for_size (this_pointer_size, 0), expr);
/* Modes may be different but sizes should be the same. There
is supposed to be some integral type that is the same width
as a pointer. */
gcc_assert (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (expr)))
== GET_MODE_SIZE (TYPE_MODE (type)));
TPF tescase (default pointer and int are 64 bits):
typedef void * __attribute__ ((mode (SI))) __ptr32_t;
unsigned int foo;
__ptr32_t foo_addr;
int bar( )
{
foo_addr = (__ptr32_t)foo;
return 0;
}
Re: [PATCH] Fix PR49715, (float)unsigned -> (float)signed
On 07/21/2011 01:16 PM, Joseph S. Myers wrote: > On Thu, 21 Jul 2011, Richard Guenther wrote: > >> Patch also handling wider modes and not starting with SImode but >> the mode of int: > > Use of target int for anything not about C ABIs is certainly wrong. This > might be about what operations the target does efficiently, or what > functions are present in libgcc (both of which would be functions of > machine modes), but it's not about the choice of C int. > Given that we've leaked other uses of the contents of optabs into the gimple optimizers, would it be too gross to simply look at all of the integer modes and ignore all those for which can_float_p is false? r~
Re: PATCH RFA: Build stages 2 and 3 with C++
Basile Starynkevitch writes: > Using the md5sum of the file is probably not bad neither. I would understand > that you > find it being perhaps too complex for your need, but it is much more random > than just the > file name (because the md5sum changes with the file content). Granted, but I am concerned about the affect on bootstrap time. Ian
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 2:00 PM, Uros Bizjak wrote:
> On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu wrote:
>
>>> Expand generates:
>>>
>>> (insn 8 6 9 (set (reg:SI 68)
>>> (symbol_ref:SI ("") [flags 0x40] >> >)) p
>>> r49798.c:12 -1
>>> (nil))
>>>
>>> (insn 9 8 10 (set (reg:DI 67)
>>> (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1
>>> (nil))
>>>
>>> I don't know if this is OK to be transformed to DImode load.
>>>
>>
>> I believe it is valid.
>
> How is this situation handled in other targets? I don't see that any
> of other ptr_mode != Pmode targets define TARGET_ASM_INTEGER in the
> way you propose.
>
Other ptr_mode != Pmode targets don't run into this issue since they
have different instruction sets. X32 may be the first (only) target for
this problem.
--
H.J.
[RFC, cfg/dataflow] Properly split EH edges for -freorder-blocks-and-partition
Ignoring all of the other problems that partitioning might have, it does Just So Happen to work for the single most popular target. So let's see about keeping the pass limping along for a while longer. The problem I'm attempting to solve here is the gross hack in convert_to_eh_region_ranges, which adds new basic blocks, badly, very late in the optimization pipeline. Indeed, we know that these are needed much earlier when we did the partitioning originally. Splitting the EH edge itself is not too difficult. All that's required is to generate a new landing pad. I dithered about how to fill in the new landing pad. One option is to duplicate the entire block containing the old landing pad. I worried that we might inadvertently copy a very large basic block this way. Another option is to generate a new landing pad from scratch, and branch to the post-landing pad. This requires that the post-landing pad be kept separate from the landing pad until now. It seemed easy enough to add the EDGE_PRESERVE bit to prevent blocks from being merged. And here is where things go downhill. DF generates the bb info for a block immediately. And by immediately, I mean *during* creation of the block. #0 df_bb_refs_collect (collection_rec=0x7fffda60, bb=0x71a4f3a8) #1 in df_bb_refs_record (bb_index=42, scan_insns=0 '\000') #2 in create_basic_block_structure (head=0x71a4ce58, ...) Which means that the bb_has_eh_pred test in df_bb_refs_collect will *always* fail, because no edges can have been added to the block yet. Which of course means we don't add the right artificial refs, which means we fail df_verify (much) later. Suggestions for something better than the df_finish_pass hack that I added at the end of partition_hot_cold_basic_blocks are very welcome. r~ diff --git a/gcc/basic-block.h b/gcc/basic-block.h index 29c1167..c03129c 100644 --- a/gcc/basic-block.h +++ b/gcc/basic-block.h @@ -65,31 +65,34 @@ DEF_VEC_P(edge); DEF_VEC_ALLOC_P(edge,gc); DEF_VEC_ALLOC_P(edge,heap); -#define EDGE_FALLTHRU 1 /* 'Straight line' flow */ -#define EDGE_ABNORMAL 2 /* Strange flow, like computed +/* Always update the table in cfg.c dump_edge_info. */ +#define EDGE_FALLTHRU 0x0001 /* 'Straight line' flow */ +#define EDGE_ABNORMAL 0x0002 /* Strange flow, like computed label, or eh */ -#define EDGE_ABNORMAL_CALL 4 /* Call with abnormal exit +#define EDGE_ABNORMAL_CALL 0x0004 /* Call with abnormal exit like an exception, or sibcall */ -#define EDGE_EH8 /* Exception throw */ -#define EDGE_FAKE 16 /* Not a real edge (profile.c) */ -#define EDGE_DFS_BACK 32 /* A backwards edge */ -#define EDGE_CAN_FALLTHRU 64 /* Candidate for straight line +#define EDGE_EH0x0008 /* Exception throw */ +#define EDGE_FAKE 0x0010 /* Not a real edge (profile.c) */ +#define EDGE_DFS_BACK 0x0020 /* A backwards edge */ +#define EDGE_CAN_FALLTHRU 0x0040 /* Candidate for straight line flow. */ -#define EDGE_IRREDUCIBLE_LOOP 128 /* Part of irreducible loop. */ -#define EDGE_SIBCALL 256 /* Edge from sibcall to exit. */ -#define EDGE_LOOP_EXIT 512 /* Exit of a loop. */ -#define EDGE_TRUE_VALUE1024/* Edge taken when controlling +#define EDGE_IRREDUCIBLE_LOOP 0x0080 /* Part of irreducible loop. */ +#define EDGE_SIBCALL 0x0100 /* Edge from sibcall to exit. */ +#define EDGE_LOOP_EXIT 0x0200 /* Exit of a loop. */ +#define EDGE_TRUE_VALUE0x0400 /* Edge taken when controlling predicate is nonzero. */ -#define EDGE_FALSE_VALUE 2048/* Edge taken when controlling +#define EDGE_FALSE_VALUE 0x0800 /* Edge taken when controlling predicate is zero. */ -#define EDGE_EXECUTABLE4096/* Edge is executable. Only +#define EDGE_EXECUTABLE0x1000 /* Edge is executable. Only valid during SSA-CCP. */ -#define EDGE_CROSSING 8192/* Edge crosses between hot +#define EDGE_CROSSING 0x2000 /* Edge crosses between hot and cold sections, when we do partitioning. */ -#define EDGE_ALL_FLAGS16383 +#define EDGE_PRESERVE 0x4000 /* Never merge blocks via this edge. */ +#define EDGE_ALL_FLAGS 0x7fff -#define EDGE_COMPLEX (EDGE_ABNORMAL | EDGE_ABNORMAL_CALL | EDGE_EH) +#define EDGE_COMPLEX \ + (EDGE_ABNORMAL | EDGE_ABNORMAL_CALL | EDGE_EH | EDGE_PRESERVE) /* Counter summary from the last set of coverage counts read by profile.c. */ @@ -203
[PATCH,fortran] remove duplicate word in documentation
I committed the following patch as obvious. 2011-07-21 Steven G. Kargl * gfortran.texi: Remove a duplicate word. Index: gfortran.texi === --- gfortran.texi (revision 176586) +++ gfortran.texi (working copy) @@ -2461,7 +2461,7 @@ in GNU Fortran; therefore, these feature @node GNU Fortran Compiler Directives @section GNU Fortran Compiler Directives -The Fortran standard standard describes how a conforming program shall +The Fortran standard describes how a conforming program shall behave; however, the exact implementation is not standardized. In order to allow the user to choose specific implementation details, compiler directives can be used to set attributes of variables and procedures -- Steve
RE: AVX generic mode tuning discussion.
> >> We would like to propose changing AVX generic mode tuning to > generate 128-bit > >> AVX instead of 256-bit AVX. > > > > You indicate a 3% reduction on bulldozer with avx256. > > How does avx128 compare to -mno-avx -msse4.2? > > Will the next AMD generation have a useable avx256? > > > > I'm not keen on the idea of generic mode being tune > > for a single processor revision that maybe shouldn't > > actually be using avx at all. > > Btw, it looks like the data is massively skewed by > 436.cactusADM. What are the overall numbers if you > disregard cactus? Disregarding cactus, these are the cumulative SpecFP scores we see. On Bulldozer: AVX256/AVX128 SPECFP -1.8% On SandyBridge: AVX256/AVX128 SPECFP -0.15% > It's also for sure the case that the vectorizer > cost model has not been touched for avx256 vs. avx128 vs. sse, > so a more sensible approach would be to look at differentiating > things there to improve the cactus numbers. I am not sure how much the vectorizer cost model can help here. The cost model can decide whether to vectorize and/or what vectorization factor to use. But in generic mode, that decision has to be processor family neutral anyway. > Harsha, did you > investigate why avx256 is such a loss for cactus or why it is > so much of a win for SB? We are planning to investigate cactus and other cases to understand the reasons behind these observations better on Bulldozer, but disregarding cactus, there appear to be no significant gains on Sandybridge with AVX256 over AVX128 as well. Thanks, Harsha
Re: [google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
Ok.
David
On Thu, Jul 21, 2011 at 1:45 PM, Rong Xu wrote:
> Please review the new patch attached to this email.
>
> thanks,
>
> -Rong
>
> On Thu, Jul 21, 2011 at 12:44 PM, Rong Xu wrote:
>> wait a second. this still won't work if we disable the whole-program
>> pass (like my original change, the visibility analysis change won't
>> kick in). we also need to change varpool_node_link() to merge the
>> local attribute.
>>
>> -Rong
>>
>> On Thu, Jul 21, 2011 at 12:35 PM, Xinliang David Li
>> wrote:
>>> On Thu, Jul 21, 2011 at 12:27 PM, Rong Xu wrote:
this is a good point. ipa_discover_readonly_nonaddressable_vars() is
called in two passes. whole-program (whole program visibility
analysis) and static-var. The one in whole-program is ok here as it is
bundled together with the analysis. the invocation in static-var can
go wrong.
should we add a check for COMDAT flag also? like
>>>
>>> Probably not -- only non referenced comdat vars will be marked as not
>>> needed.
>>>
>>> David
>>>
if ((vnode->needed || (L_IPO_COMP_MODE && DECL_COMDAT (node->decl)))
&& varpool_node_externally_visible_p) (
Thanks,
-Rong
On Thu, Jul 21, 2011 at 11:59 AM, Xinliang David Li
wrote:
> On Thu, Jul 21, 2011 at 11:32 AM, Rong Xu wrote:
>> On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>>>
>>> http://codereview.appspot.com/4798045/diff/1/ipa.c
>>> File ipa.c (right):
>>>
>>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
>>> ipa.c:1034: {
>>> Has varpool node linking happened at this point? If not, the new code
>>> here is not excersised.
>>
>> This functions is called in multiple places: local pass and
>> whole_program pass. varpool_node_link is b/w these two passes. the
>> varpool node attribute is set before the use in
>> ipa_discover_readonly_nonaddressable_vars()
>
> So the code relies on the second visibility pass to get things right
> -- if that pass is disabled things can go wrong (if the default
> visibility value when vnode is created is true, LIPO mode will get
> pessemitic result; if the default is false, LIPO mode will still get
> wrong result if only local visiblity pass is run).
>
> A better fix might be simply do not check 'needed' bit for comdat
> varnode in LIPO mode and always run the visibiity checker:
>
> if ((vnode->needed || L_IPO_COMP_MODE)
> && varpool_node_externally_visible_p (...
> )
>
>
> David
>
>
>>
>>>
>>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
>>> ipa.c:1041: vnode->externally_visible = false;
>>> Better to add a simple loop after varpool_node_linking to merge the
>>> attribute in l-ipo.c assuming the linking happens after local visibility
>>> pass.
>>
>> We can merge in the varpool_node_link, but we still need to change
>> here as the attribute will be overwritten here in the whole_program
>> pass.
>>
>>>
>>> http://codereview.appspot.com/4798045/
>>>
>>
>
>>>
>>
>
Re: [Patches, Fortran] ALLOCATE & CAF library.
Daniel Carrera wrote: On 07/21/2011 07:22 PM, Tobias Burnus wrote: Doesn't compile here: gcc/fortran/trans.c:656:8: error: unused variable 'status_type' [-Werror=unused-variable] Hmm... I really wish that my Makefile was as picky as yours. But last time I tried to change my configure flag everything went crazy. The attached file contains the fix. I won't commit until I get a "ok" from you. Compiled and regtested successfully. Tobias
RE: AVX generic mode tuning discussion.
> On 07/12/2011 02:22 PM, harsha.jaga...@amd.com wrote: > > We would like to propose changing AVX generic mode tuning to generate > 128-bit > > AVX instead of 256-bit AVX. > > You indicate a 3% reduction on bulldozer with avx256. > How does avx128 compare to -mno-avx -msse4.2? We see these % differences going from SSE42 to AVX128 to AVX256 on Bulldozer with "-mtune=generic -Ofast". (Positive is improvement, negative is degradation) Bulldozer: AVX128/SSE42AVX256/AVX-128 410.bwaves -1.4% -1.4% 416.gamess -1.1% 0.0% 433.milc0.5%-2.4% 434.zeusmp 9.7%-2.1% 435.gromacs 5.1%0.5% 436.cactusADM 8.2%-23.8% 437.leslie3d8.1%0.4% 444.namd3.6%0.0% 447.dealII -1.4% -0.4% 450.soplex -0.4% -0.4% 453.povray 0.0%-1.5% 454.calculix15.7% -8.3% 459.GemsFDTD4.9%1.4% 465.tonto 1.3%-0.6% 470.lbm 0.9%0.3% 481.wrf 7.3%-3.6% 482.sphinx3 5.0%-9.8% SPECFP 3.8%-3.2% > Will the next AMD generation have a useable avx256? > I'm not keen on the idea of generic mode being tune > for a single processor revision that maybe shouldn't > actually be using avx at all. We see a substantial gain in several SPECFP benchmarks going from SSE42 to AVX128 on Bulldozer. IMHO, accomplishing even a 5% gain in an individual benchmark takes a hardware company several man months. The loss with AVX256 for Bulldozer is much more significant than the gain for SandyBridge. While the general trend in the industry is a move toward AVX256, for now we would be disadvantaging Bulldozer with this choice. We have several customers who use -mtune=generic and it is default, unless a user explicitly overrides it with -mtune=native. They are the ones who want to experiment with latest ISA using gcc, but want to keep their ISA selection and tuning agnostic on x86/64. IMHO, it is with these customers in mind that generic was introduced in the first place. Thanks, Harsha
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 10:22 PM, H.J. Lu wrote:
>> Expand generates:
>>
>> (insn 8 6 9 (set (reg:SI 68)
>> (symbol_ref:SI ("") [flags 0x40] > >)) p
>> r49798.c:12 -1
>> (nil))
>>
>> (insn 9 8 10 (set (reg:DI 67)
>> (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1
>> (nil))
>>
>> I don't know if this is OK to be transformed to DImode load.
>>
>
> I believe it is valid.
How is this situation handled in other targets? I don't see that any
of other ptr_mode != Pmode targets define TARGET_ASM_INTEGER in the
way you propose.
Uros.
Re: [PATCH 00/10] Second attempt to fix PR47654 and PR49649
On 07/21/2011 08:31 PM, Sebastian Pop wrote: Hi, This patch-set addresses the comments from Tobias on fixing PR47654. The first patches are cleanups: - Start counting nesting level from 0 and use the standard "Polyhedral SCattering Transformed" psct_* interface. - Do not compute twice type, lb, and ub. - Record the loop level that defines a clast_name. - Cleanup function params using a struct. - Add fixme comment. - Rename gcc_type_for_clast_* into type_for_clast_* - Remove max_signed_precision_type. The following patch is an optimization: - Compute once and cache the LB and UB for each clast_name. that uses the hashtable of clast_names to also attach the information on bounds of the name: this would avoid asking "polyhedral questions" every time we see the name of an induction variable in an expression. The following patch is also an optimization: - Generate signed types whenever possible. this makes us generate signed types instead of unsigned, whenever the interval would still fit in a signed type of the same precision. Finally the fix for PR47654: - Infer types based on lb and ub. I adapted the previous patch such that we now compute both the type and the bounds during the same traversal of the CLAST tree. The computation of the type now also integrates the information of the bounds of the sub-expressions and the result of the expression. The patch-set bootstrapped and tested on amd64-linux. Ok for trunk? Hi Sebastian, this looks nice. I tried, but was not able to find any bug. :-( I think this is definitely a big improvement. From my side it's OK to commit. Tobi
Re: [google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
Please review the new patch attached to this email.
thanks,
-Rong
On Thu, Jul 21, 2011 at 12:44 PM, Rong Xu wrote:
> wait a second. this still won't work if we disable the whole-program
> pass (like my original change, the visibility analysis change won't
> kick in). we also need to change varpool_node_link() to merge the
> local attribute.
>
> -Rong
>
> On Thu, Jul 21, 2011 at 12:35 PM, Xinliang David Li
> wrote:
>> On Thu, Jul 21, 2011 at 12:27 PM, Rong Xu wrote:
>>> this is a good point. ipa_discover_readonly_nonaddressable_vars() is
>>> called in two passes. whole-program (whole program visibility
>>> analysis) and static-var. The one in whole-program is ok here as it is
>>> bundled together with the analysis. the invocation in static-var can
>>> go wrong.
>>>
>>> should we add a check for COMDAT flag also? like
>>
>> Probably not -- only non referenced comdat vars will be marked as not needed.
>>
>> David
>>
>>> if ((vnode->needed || (L_IPO_COMP_MODE && DECL_COMDAT (node->decl)))
>>> && varpool_node_externally_visible_p) (
>>>
>>> Thanks,
>>>
>>> -Rong
>>> On Thu, Jul 21, 2011 at 11:59 AM, Xinliang David Li
>>> wrote:
On Thu, Jul 21, 2011 at 11:32 AM, Rong Xu wrote:
> On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c
>> File ipa.c (right):
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
>> ipa.c:1034: {
>> Has varpool node linking happened at this point? If not, the new code
>> here is not excersised.
>
> This functions is called in multiple places: local pass and
> whole_program pass. varpool_node_link is b/w these two passes. the
> varpool node attribute is set before the use in
> ipa_discover_readonly_nonaddressable_vars()
So the code relies on the second visibility pass to get things right
-- if that pass is disabled things can go wrong (if the default
visibility value when vnode is created is true, LIPO mode will get
pessemitic result; if the default is false, LIPO mode will still get
wrong result if only local visiblity pass is run).
A better fix might be simply do not check 'needed' bit for comdat
varnode in LIPO mode and always run the visibiity checker:
if ((vnode->needed || L_IPO_COMP_MODE)
&& varpool_node_externally_visible_p (...
)
David
>
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
>> ipa.c:1041: vnode->externally_visible = false;
>> Better to add a simple loop after varpool_node_linking to merge the
>> attribute in l-ipo.c assuming the linking happens after local visibility
>> pass.
>
> We can merge in the varpool_node_link, but we still need to change
> here as the attribute will be overwritten here in the whole_program
> pass.
>
>>
>> http://codereview.appspot.com/4798045/
>>
>
>>>
>>
>
2011-07-21 Rong Xu
* ipa.c: In LIPO mode, call varpool_externally_visible_p()
to set the externally visible attribute even for varpool
nodes that not marked as needed.
* l-ipo.c: Merge the externally visible attribute for varpool
nodes..
Index: ipa.c
===
--- ipa.c (revision 176535)
+++ ipa.c (working copy)
@@ -1024,7 +1024,7 @@
{
if (!vnode->finalized)
continue;
- if (vnode->needed
+ if ((vnode->needed || L_IPO_COMP_MODE)
&& varpool_externally_visible_p
(vnode,
pointer_set_contains (aliased_vnodes, vnode)))
Index: l-ipo.c
===
--- l-ipo.c (revision 176535)
+++ l-ipo.c (working copy)
@@ -2127,6 +2127,11 @@
eq_node_assembler_name, NULL);
for (node = varpool_nodes; node; node = node->next)
varpool_link_node (node);
+
+ /* Merge the externally visible attribute. */
+ for (node = varpool_nodes; node; node = node->next)
+if (node->externally_visible)
+ (real_varpool_node (node->decl))->externally_visible = true;
}
/* Get the list of assembler name ids with reference bit set. */
Re: safe unordered local iterators
Attached patch applied:
2011-07-21 François Dumont
* include/debug/safe_unordered_sequence.h,
safe_unordered_sequence.tcc: Rename respectively in...
* include/debug/safe_unordered_container.h,
safe_unordered_container.tcc: ...those. _Safe_unordered_sequence
rename _Safe_unordered_container.
* include/debug/safe_unordered_base.h:
_Safe_unordered_sequence_base
rename _Safe_unordered_container_base.
* include/debug/unordered_map, unordered_set: Adapt to previous
modifications.
* config/abi/pre/gnu.ver: Likewise.
* src/debug.cc: Likewise.
* include/Makefile.am: Likewise.
* include/Makefile.in: Regenerate.
Regards
On 07/21/2011 12:58 AM, Jonathan Wakely wrote:
On 20 July 2011 22:40, Paolo Carlini wrote:
On 07/20/2011 10:46 PM, François Dumont wrote:
Hello
Sorry for the inconvenience. Here is my proposition for the renaming, I
I should probably apologise for the inconvenience for suggesting
changing it! I do think it is a bit confusing though, the "Sequence"
containers in the standard library have a definite ordering, so an
unordered sequence is confusing :)
haven't tested it yet but will of course before commiting.
I'm Ok with it if Jonathan is...
Yes, thanks for changing it.
Thanks,
Paolo.
PS: my first language obviously isn't English, but I see you are using
a lot where I would normally prefer...
Yes, proposal would be correct there.
Index: src/debug.cc
===
--- src/debug.cc (revision 176533)
+++ src/debug.cc (working copy)
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
#include
#include
#include
@@ -78,8 +78,8 @@
}
void
- swap_useq(__gnu_debug::_Safe_unordered_sequence_base& __lhs,
- __gnu_debug::_Safe_unordered_sequence_base& __rhs)
+ swap_ucont(__gnu_debug::_Safe_unordered_container_base& __lhs,
+ __gnu_debug::_Safe_unordered_container_base& __rhs)
{
swap_seq(__lhs, __rhs);
swap_its(__lhs, __lhs._M_local_iterators,
@@ -174,8 +174,8 @@
" by a dereferenceable one",
"function requires a valid iterator range (%2.name;, %3.name;)"
", \"%2.name;\" shall be before and not equal to \"%3.name;\"",
-// std::unordered_sequence::local_iterator
-"attempt to compare local iterators from different unordered sequence"
+// std::unordered_container::local_iterator
+"attempt to compare local iterators from different unordered container"
" buckets"
};
@@ -374,38 +374,38 @@
_M_get_mutex() throw ()
{ return get_safe_base_mutex(_M_sequence); }
- _Safe_unordered_sequence_base*
+ _Safe_unordered_container_base*
_Safe_local_iterator_base::
- _M_get_sequence() const _GLIBCXX_NOEXCEPT
- { return static_cast<_Safe_unordered_sequence_base*>(_M_sequence); }
+ _M_get_container() const _GLIBCXX_NOEXCEPT
+ { return static_cast<_Safe_unordered_container_base*>(_M_sequence); }
void
_Safe_local_iterator_base::
- _M_attach(_Safe_sequence_base* __seq, bool __constant)
+ _M_attach(_Safe_sequence_base* __cont, bool __constant)
{
_M_detach();
-// Attach to the new sequence (if there is one)
-if (__seq)
+// Attach to the new container (if there is one)
+if (__cont)
{
- _M_sequence = __seq;
+ _M_sequence = __cont;
_M_version = _M_sequence->_M_version;
- _M_get_sequence()->_M_attach_local(this, __constant);
+ _M_get_container()->_M_attach_local(this, __constant);
}
}
void
_Safe_local_iterator_base::
- _M_attach_single(_Safe_sequence_base* __seq, bool __constant) throw ()
+ _M_attach_single(_Safe_sequence_base* __cont, bool __constant) throw ()
{
_M_detach_single();
-// Attach to the new sequence (if there is one)
-if (__seq)
+// Attach to the new container (if there is one)
+if (__cont)
{
- _M_sequence = __seq;
+ _M_sequence = __cont;
_M_version = _M_sequence->_M_version;
- _M_get_sequence()->_M_attach_local_single(this, __constant);
+ _M_get_container()->_M_attach_local_single(this, __constant);
}
}
@@ -414,7 +414,7 @@
_M_detach()
{
if (_M_sequence)
- _M_get_sequence()->_M_detach_local(this);
+ _M_get_container()->_M_detach_local(this);
_M_reset();
}
@@ -424,13 +424,13 @@
_M_detach_single() throw ()
{
if (_M_sequence)
- _M_get_sequence()->_M_detach_local_single(this);
+ _M_get_container()->_M_detach_local_single(this);
_M_reset();
}
void
- _Safe_unordered_sequence_base::
+ _Safe_unordered_container_base::
_M_detach_all()
{
__gnu_cxx::__scoped_lock sentry(_M_get_mutex());
@@ -448,17 +448,17 @@
}
void
- _Safe_unordered_sequence_base::
- _M_swap(_Safe_unordered_sequence_base& __x)
+ _Safe_unordered_container_base::
+ _M_swap(_Safe_unordered_container_base& __x)
{
-// We need to lock both sequences to swap
+// We need to lock
Re: [RFC PATCH] -grecord-gcc-switches (PR other/32998)
On Thu, 21 Jul 2011, Jakub Jelinek wrote: > So > > gcc_checking_assert (save_decoded_options[j].canonical_option[0][0] == > '-'); > switch (save_decoded_options[j].canonical_option[0][1]) > > instead? The reason for checking the option text instead of code Yes. > was just because there are hundreds of -W options etc. and I didn't want to > list them all and create a maintanance nightmare. Flags such as CL_WARNING and the various bit-fields in struct cl_option (bit-fields are preferred if --help doesn't need to care about a property of an option) could be used, but I don't think it would really be an improvement in this case. > If -no can't make it to cc1, I'll drop it. Is -fdump* checking that way > ok (with the orig_option_with_args_text -> canonical_option[0] change)? Yes, that seems reasonable. -- Joseph S. Myers jos...@codesourcery.com
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 1:17 PM, Uros Bizjak wrote:
> On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu wrote:
>
>>> /* Represents viewing something of one type as being of a second type.
>>> This corresponds to an "Unchecked Conversion" in Ada and roughly to
>>> the idiom *(type2 *)&X in C. The only operand is the value to be
>>> viewed as being of another type. **It is undefined if the type of the
>>> input and of the expression have different sizes.**
>>>
>>> ...
>>> DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1)
>>>
>>> We have:
>>>
>>> :
>>> D.2709_8 = VIEW_CONVERT_EXPR(&);
>>> D.2702_1 = u.d;
>>> D.2704_3 = D.2702_1 == D.2709_8;
>>> D.2701_4 = (int) D.2704_3;
>>> return D.2701_4;
>>>
>>> Where
>>>
>>> sizeof (double) = 64
>>> sizeof (ptr_type) = 32.
>>>
>>
>> Are you sure that you used -mx32? I couldn't reproduce it.
>> It looks like an x86 backend bug to me.
>
> Hm, can't reproduce it anymore... x32 -O2 looks OK:
>
> :
> v = {};
> v.m = &;
> D.2702_1 = u.d;
> D.2703_2 = v.d;
> D.2704_3 = D.2702_1 == D.2703_2;
> D.2701_4 = (int) D.2704_3;
> return D.2701_4;
>
> }
>
> Expand generates:
>
> (insn 8 6 9 (set (reg:SI 68)
> (symbol_ref:SI ("") [flags 0x40] ))
> p
> r49798.c:12 -1
> (nil))
>
> (insn 9 8 10 (set (reg:DI 67)
> (zero_extend:DI (reg:SI 68))) pr49798.c:12 -1
> (nil))
>
> I don't know if this is OK to be transformed to DImode load.
>
I believe it is valid.
--
H.J.
Re: [RFC PATCH] -grecord-gcc-switches (PR other/32998)
On Thu, Jul 21, 2011 at 08:06:49PM +, Joseph S. Myers wrote:
> On Wed, 13 Jul 2011, Jakub Jelinek wrote:
>
> > Ideally we'd just include explicitly passed options from command line that
> > haven't been overridden by other command line options, and would sort them,
> > so that there are higher chances of DW_AT_producer strings being merged
> > (e.g. -O2 -ffast-math vs. -ffast-math -O2 are now different strings, and
> > similarly -O2 vs. -O3 -O2 vs. -O0 -O1 -Ofast -O2), but I'm not sure if it is
> > easily possible using current option handling framework.
>
> I don't think there's enough structure for that, although prune_options
> could always be enhanced to cover more cases of overridden options.
Perhaps we can emit it in the original order even with duplicates for now
and if we get better infrastructure later, reduce its size.
> > + default:
> > + if (save_decoded_options[j].orig_option_with_args_text[0] != '-')
> > + continue;
>
> Should instead be ignoring OPT_SPECIAL_*.
It already ignores them above:
+ case OPT_SPECIAL_unknown:
+ case OPT_SPECIAL_ignore:
+ case OPT_SPECIAL_program_name:
+ case OPT_SPECIAL_input_file:
I just didn't want to crash if it wouldn't start with -.
I can make it a gcc_checking_assert instead.
>
> > + switch (save_decoded_options[j].orig_option_with_args_text[1])
> > + {
> > + case 'M':
> > + case 'i':
> > + case 'W':
>
> It would be better to check the canonical option text rather than the
> original text. Normally this wouldn't make any difference because the
> driver will have passed canonical options to cc1, but if someone calls cc1
> directly then I think aliases should still act the same as the options
> they are aliases for in this regard.
So
gcc_checking_assert (save_decoded_options[j].canonical_option[0][0] ==
'-');
switch (save_decoded_options[j].canonical_option[0][1])
instead? The reason for checking the option text instead of code
was just because there are hundreds of -W options etc. and I didn't want to
list them all and create a maintanance nightmare.
>
> > + continue;
> > + case 'n':
> > + if (save_decoded_options[j].orig_option_with_args_text[2]
> > + == 'o')
> > + continue;
>
> When would a "-no" option ever get passed to cc1?
If -no can't make it to cc1, I'll drop it. Is -fdump* checking that way
ok (with the orig_option_with_args_text -> canonical_option[0] change)?
Jakub
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 10:00 PM, H.J. Lu wrote:
>> /* Represents viewing something of one type as being of a second type.
>> This corresponds to an "Unchecked Conversion" in Ada and roughly to
>> the idiom *(type2 *)&X in C. The only operand is the value to be
>> viewed as being of another type. **It is undefined if the type of the
>> input and of the expression have different sizes.**
>>
>> ...
>> DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1)
>>
>> We have:
>>
>> :
>> D.2709_8 = VIEW_CONVERT_EXPR(&);
>> D.2702_1 = u.d;
>> D.2704_3 = D.2702_1 == D.2709_8;
>> D.2701_4 = (int) D.2704_3;
>> return D.2701_4;
>>
>> Where
>>
>> sizeof (double) = 64
>> sizeof (ptr_type) = 32.
>>
>
> Are you sure that you used -mx32? I couldn't reproduce it.
> It looks like an x86 backend bug to me.
Hm, can't reproduce it anymore... x32 -O2 looks OK:
:
v = {};
v.m = &;
D.2702_1 = u.d;
D.2703_2 = v.d;
D.2704_3 = D.2702_1 == D.2703_2;
D.2701_4 = (int) D.2704_3;
return D.2701_4;
}
Expand generates:
(insn 8 6 9 (set (reg:SI 68)
(symbol_ref:SI ("") [flags 0x40] )) p
r49798.c:12 -1
(nil))
(insn 9 8 10 (set (reg:DI 67)
(zero_extend:DI (reg:SI 68))) pr49798.c:12 -1
(nil))
I don't know if this is OK to be transformed to DImode load.
Uros.
Re: [PATCH] Fix PR49715, (float)unsigned -> (float)signed
On Thu, 21 Jul 2011, Richard Guenther wrote: > Patch also handling wider modes and not starting with SImode but > the mode of int: Use of target int for anything not about C ABIs is certainly wrong. This might be about what operations the target does efficiently, or what functions are present in libgcc (both of which would be functions of machine modes), but it's not about the choice of C int. -- Joseph S. Myers jos...@codesourcery.com
Re: PATCH RFA: Disable -Wstrict-overflow for unevaluated expressions
On Tue, 12 Jul 2011, Ian Lance Taylor wrote: > This patch to the C frontend disables warnings about -Wstrict-overflow > when handling expressions which will not be evaluated. This fixes PR > 49705. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > OK for mainline? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC PATCH] -grecord-gcc-switches (PR other/32998)
On Wed, 13 Jul 2011, Jakub Jelinek wrote:
> Ideally we'd just include explicitly passed options from command line that
> haven't been overridden by other command line options, and would sort them,
> so that there are higher chances of DW_AT_producer strings being merged
> (e.g. -O2 -ffast-math vs. -ffast-math -O2 are now different strings, and
> similarly -O2 vs. -O3 -O2 vs. -O0 -O1 -Ofast -O2), but I'm not sure if it is
> easily possible using current option handling framework.
I don't think there's enough structure for that, although prune_options
could always be enhanced to cover more cases of overridden options.
> + default:
> + if (save_decoded_options[j].orig_option_with_args_text[0] != '-')
> + continue;
Should instead be ignoring OPT_SPECIAL_*.
> + switch (save_decoded_options[j].orig_option_with_args_text[1])
> + {
> + case 'M':
> + case 'i':
> + case 'W':
It would be better to check the canonical option text rather than the
original text. Normally this wouldn't make any difference because the
driver will have passed canonical options to cc1, but if someone calls cc1
directly then I think aliases should still act the same as the options
they are aliases for in this regard.
> + continue;
> + case 'n':
> + if (save_decoded_options[j].orig_option_with_args_text[2]
> + == 'o')
> + continue;
When would a "-no" option ever get passed to cc1?
--
Joseph S. Myers
jos...@codesourcery.com
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 10:30 AM, Uros Bizjak wrote: > On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak wrote: >>> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu wrote: >>> >> ".quad symbol" isn't really valid for 32bit. > > Why not? We certainly know what value to put there. > x32 doesn't support 64bit relocation, like R_X86_64_64. In many causes, generate .long symbol .long 0 for ".quad symbol" is wrong. Please see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 for some examples. >>> >>> Please also see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >>> >>> on why I think this is middle-end/tree-optimization issue. >>> >> >> I still think it is a backend issue. > > /* Represents viewing something of one type as being of a second type. > This corresponds to an "Unchecked Conversion" in Ada and roughly to > the idiom *(type2 *)&X in C. The only operand is the value to be > viewed as being of another type. **It is undefined if the type of the > input and of the expression have different sizes.** > > ... > DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) > > We have: > > : > D.2709_8 = VIEW_CONVERT_EXPR(&); > D.2702_1 = u.d; > D.2704_3 = D.2702_1 == D.2709_8; > D.2701_4 = (int) D.2704_3; > return D.2701_4; > > Where > > sizeof (double) = 64 > sizeof (ptr_type) = 32. > Are you sure that you used -mx32? I couldn't reproduce it. It looks like an x86 backend bug to me. -- H.J.
Re: Allow Tru64 UNIX bootstrap with C++
On Thu, 21 Jul 2011, Rainer Orth wrote:
> diff --git a/gcc/system.h b/gcc/system.h
> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -24,6 +24,10 @@ along with GCC; see the file COPYING3.
> #ifndef GCC_SYSTEM_H
> #define GCC_SYSTEM_H
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
I don't think it's right to surround any system header includes with
extern "C". If a particular declaration in system.h needs to be extern
"C", surround only that declaration (though preferably such declarations
might go in other headers with their own extern "C").
--
Joseph S. Myers
jos...@codesourcery.com
Re: [wwwdocs, 4.6] Announce NetWare obsoletion, removal
On Fri, 15 Jul 2011, Rainer Orth wrote: > Index: htdocs/gcc-4.7/changes.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v > retrieving revision 1.22 > diff -u -p -r1.22 changes.html > --- htdocs/gcc-4.7/changes.html 15 Jul 2011 09:48:15 - 1.22 > +++ htdocs/gcc-4.7/changes.html 15 Jul 2011 15:29:34 - > @@ -46,6 +46,9 @@ > > The ARM port's -mwords-little-endian option has > been deprecated. It will be removed in a future release. > + > +Support has been removed for the NetWare x86 configuration > +obsoleted in GCC 4.6. I don't think NetWare should be called out specially like this; either list all removed targets explicitly, or say "all targets deprecated in 4.6" (with a link to the deprecation list), "except for" a list of the targets reprieved. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH Atom][PR middle-end/44382] Tree reassociation improvement
On Thu, 14 Jul 2011, Ilya Enkovich wrote: > * doc/tm.texi.in (reassociation_width): New hook documentation. Unless the documentation for a new hook is based on pre-existing GFDL-only text, it should go in target.def not tm.texi.in, with the only thing added to tm.texi.in being a single @hook line. -- Joseph S. Myers jos...@codesourcery.com
Re: CFT: [build] Move soft-fp support to toplevel libgcc
On Tue, 12 Jul 2011, Rainer Orth wrote:
> One odd thing out is that the lm32 snippet misses
>
> softfp_exclude_libgcc2 := y
>
> compared to the new t-softfp-sfdf. I'm currently handling this since I
> cannot tell if this is intentional or just an accident.
The general rule is that softfp_exclude_libgcc2 := y is to be avoided
where possible - and after this move it should be possible (in separate
patches) to eliminate the remaining instances of it.
Specifically, if all multilibs for a target are soft-float and using
soft-fp, then you shouldn't need softfp_exclude_libgcc2 := y, because it's
more efficient to implement the floating-point functions from libgcc2.c
directly using soft-fp instead of through the libgcc2.c wrappers around
other operations that will end up calling soft-fp functions. The use of
softfp_exclude_libgcc2 := y is if a target has both hard and soft float
multilibs, because the libgcc2.c versions are better for the hard float
multilibs and it wasn't easy to choose between them based on the multilib.
With soft-fp configuration in the toplevel libgcc directory, the libgcc
configure script can select different configuration files depending on the
multilib. For the soft-float multilibs it can select the soft-fp files
and disable the libgcc2.c versions of these functions. For hard-float
multilibs, the functions outside libgcc2.c aren't really needed as they
won't actually be called; for ABI compatibility they should stay in libgcc
if they were already there, but it would be best to keep the size of
libgcc down by compiling them from trivial code such as "float __addsf3
(float a, float b) { return a + b; }". (Some cases such as Power e500v1 -
hardware "float", software "double" - are more complicated, but the same
general principles still apply.)
In addition to the cases for whether TFmode is involved that you noted,
there are cases for whether TImode is involved as well. See
libgcc/config/i386/32/t-fprules-softfp. With the move to toplevel, that
file has a kludge to remove TImode functions that has no good reason to
exist; the 32-bit multilibs should simply not include "ti" in
softfp_int_modes, rather than including it then overriding some of the
variables generated from that setting.
Configure tests could also make a better replacement for softfp_wrap_start
and softfp_wrap_end.
Given the complexity of the symbol versioning setup for this code for
x86-linux (32-bit and 64-bit) it would be a good idea to verify that the
exported symbols in shared libgcc are the same, at the same versions,
before and after the patch, for each of 32-bit and 64-bit.
--
Joseph S. Myers
jos...@codesourcery.com
Re: PATCH RFA: Build stages 2 and 3 with C++
On Thu, 21 Jul 2011 11:13:00 -0700
Ian Lance Taylor wrote:
> Jakub Jelinek writes:
>
> > On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote:
> >> Basile Starynkevitch writes:
> >>
> >> > I have a similar issue in the MELT branch, and I am passing to
> >> > -frandom-seed the md5sum
> >> > of relevant source files. With such a trick, the seed is reproducible
> >> > from one build to
> >> > the next one (of the exact same source tree), and does provide much more
> >> > randomness than
> >> > just using 0 all the time.
> >>
> >> In practice I think it is fine to just pass the source file name to
> >> -frandom-seed. That's what the patch I sent out does. The source file
> >> name should be unique within a given program.
> >
> > Isn't the filename already encoded in what get_file_function_name returns?
> > It is __, so IMHO
> > -frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0.
> > Except perhaps for the characters from the filename that are
> > wiped into _ by clean_symbol_name.
>
> That's a fair point, but I guess I still think using the file name with
> -frandom-seed is going to be more future-proof against other users of
> random numbers.
Using the md5sum of the file is probably not bad neither. I would understand
that you
find it being perhaps too complex for your need, but it is much more random
than just the
file name (because the md5sum changes with the file content).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
wait a second. this still won't work if we disable the whole-program
pass (like my original change, the visibility analysis change won't
kick in). we also need to change varpool_node_link() to merge the
local attribute.
-Rong
On Thu, Jul 21, 2011 at 12:35 PM, Xinliang David Li wrote:
> On Thu, Jul 21, 2011 at 12:27 PM, Rong Xu wrote:
>> this is a good point. ipa_discover_readonly_nonaddressable_vars() is
>> called in two passes. whole-program (whole program visibility
>> analysis) and static-var. The one in whole-program is ok here as it is
>> bundled together with the analysis. the invocation in static-var can
>> go wrong.
>>
>> should we add a check for COMDAT flag also? like
>
> Probably not -- only non referenced comdat vars will be marked as not needed.
>
> David
>
>> if ((vnode->needed || (L_IPO_COMP_MODE && DECL_COMDAT (node->decl)))
>> && varpool_node_externally_visible_p) (
>>
>> Thanks,
>>
>> -Rong
>> On Thu, Jul 21, 2011 at 11:59 AM, Xinliang David Li
>> wrote:
>>> On Thu, Jul 21, 2011 at 11:32 AM, Rong Xu wrote:
On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c
> File ipa.c (right):
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
> ipa.c:1034: {
> Has varpool node linking happened at this point? If not, the new code
> here is not excersised.
This functions is called in multiple places: local pass and
whole_program pass. varpool_node_link is b/w these two passes. the
varpool node attribute is set before the use in
ipa_discover_readonly_nonaddressable_vars()
>>>
>>> So the code relies on the second visibility pass to get things right
>>> -- if that pass is disabled things can go wrong (if the default
>>> visibility value when vnode is created is true, LIPO mode will get
>>> pessemitic result; if the default is false, LIPO mode will still get
>>> wrong result if only local visiblity pass is run).
>>>
>>> A better fix might be simply do not check 'needed' bit for comdat
>>> varnode in LIPO mode and always run the visibiity checker:
>>>
>>> if ((vnode->needed || L_IPO_COMP_MODE)
>>> && varpool_node_externally_visible_p (...
>>> )
>>>
>>>
>>> David
>>>
>>>
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
> ipa.c:1041: vnode->externally_visible = false;
> Better to add a simple loop after varpool_node_linking to merge the
> attribute in l-ipo.c assuming the linking happens after local visibility
> pass.
We can merge in the varpool_node_link, but we still need to change
here as the attribute will be overwritten here in the whole_program
pass.
>
> http://codereview.appspot.com/4798045/
>
>>>
>>
>
Re: [google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
On Thu, Jul 21, 2011 at 12:27 PM, Rong Xu wrote:
> this is a good point. ipa_discover_readonly_nonaddressable_vars() is
> called in two passes. whole-program (whole program visibility
> analysis) and static-var. The one in whole-program is ok here as it is
> bundled together with the analysis. the invocation in static-var can
> go wrong.
>
> should we add a check for COMDAT flag also? like
Probably not -- only non referenced comdat vars will be marked as not needed.
David
> if ((vnode->needed || (L_IPO_COMP_MODE && DECL_COMDAT (node->decl)))
> && varpool_node_externally_visible_p) (
>
> Thanks,
>
> -Rong
> On Thu, Jul 21, 2011 at 11:59 AM, Xinliang David Li
> wrote:
>> On Thu, Jul 21, 2011 at 11:32 AM, Rong Xu wrote:
>>> On Thu, Jul 21, 2011 at 11:09 AM, wrote:
http://codereview.appspot.com/4798045/diff/1/ipa.c
File ipa.c (right):
http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
ipa.c:1034: {
Has varpool node linking happened at this point? If not, the new code
here is not excersised.
>>>
>>> This functions is called in multiple places: local pass and
>>> whole_program pass. varpool_node_link is b/w these two passes. the
>>> varpool node attribute is set before the use in
>>> ipa_discover_readonly_nonaddressable_vars()
>>
>> So the code relies on the second visibility pass to get things right
>> -- if that pass is disabled things can go wrong (if the default
>> visibility value when vnode is created is true, LIPO mode will get
>> pessemitic result; if the default is false, LIPO mode will still get
>> wrong result if only local visiblity pass is run).
>>
>> A better fix might be simply do not check 'needed' bit for comdat
>> varnode in LIPO mode and always run the visibiity checker:
>>
>> if ((vnode->needed || L_IPO_COMP_MODE)
>> && varpool_node_externally_visible_p (...
>> )
>>
>>
>> David
>>
>>
>>>
http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
ipa.c:1041: vnode->externally_visible = false;
Better to add a simple loop after varpool_node_linking to merge the
attribute in l-ipo.c assuming the linking happens after local visibility
pass.
>>>
>>> We can merge in the varpool_node_link, but we still need to change
>>> here as the attribute will be overwritten here in the whole_program
>>> pass.
>>>
http://codereview.appspot.com/4798045/
>>>
>>
>
Re: [PATCH (2/7)] Widening multiplies by more than one mode
On Tue, 12 Jul 2011, Richard Guenther wrote: > (**) We really ought to forbid any arithmetic on types that have non-mode > precision and only allow conversions to/from such types. Arithmetic on such types is a perfectly reasonable notion to have in language-independent code and carry out language-independent optimizations on. There may well be a case for lowering such arithmetic earlier than the present point at which it's lowered (expand), but it isn't obvious that gimplification is the right point for that lowering either. -- Joseph S. Myers jos...@codesourcery.com
re: Fix argument pushes to unaligned stack slots
On Tue, 12 Jul 2011, matthew green wrote: > i'm having a problem with GCC 4.5.3 on netbsd-m68k target. i've tracked > it down to this change from several years ago: > > > 2007-02-06 Joseph Myers > > > > * expr.c (emit_push_insn): If STRICT_ALIGNMENT, copy to an > > unaligned stack slot via a suitably aligned slot. > > the problem is that emit_library_call_value_1() calls emit_push_insn() > with TYPE_NULL which ends up triggering a NULL deref when emit_push_insn() > calls assign_temp() with type = TYPE_NULL, and assign_temp() crashes. > > this simple change seems to be sufficient to avoid the crash and the > generated code appears to run OK. if it is OK, could someone please I don't see how it can be safe; if the stack slot is insufficiently aligned, the special handling will be needed. Maybe the alignment being passed to this code is wrong, but if it's correct then you need a way to handle the unaligned move properly; I don't know if it would be possible or safe to pass a non-NULL type here, for example. -- Joseph S. Myers jos...@codesourcery.com
Re: [google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
this is a good point. ipa_discover_readonly_nonaddressable_vars() is
called in two passes. whole-program (whole program visibility
analysis) and static-var. The one in whole-program is ok here as it is
bundled together with the analysis. the invocation in static-var can
go wrong.
should we add a check for COMDAT flag also? like
if ((vnode->needed || (L_IPO_COMP_MODE && DECL_COMDAT (node->decl)))
&& varpool_node_externally_visible_p) (
Thanks,
-Rong
On Thu, Jul 21, 2011 at 11:59 AM, Xinliang David Li wrote:
> On Thu, Jul 21, 2011 at 11:32 AM, Rong Xu wrote:
>> On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>>>
>>> http://codereview.appspot.com/4798045/diff/1/ipa.c
>>> File ipa.c (right):
>>>
>>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
>>> ipa.c:1034: {
>>> Has varpool node linking happened at this point? If not, the new code
>>> here is not excersised.
>>
>> This functions is called in multiple places: local pass and
>> whole_program pass. varpool_node_link is b/w these two passes. the
>> varpool node attribute is set before the use in
>> ipa_discover_readonly_nonaddressable_vars()
>
> So the code relies on the second visibility pass to get things right
> -- if that pass is disabled things can go wrong (if the default
> visibility value when vnode is created is true, LIPO mode will get
> pessemitic result; if the default is false, LIPO mode will still get
> wrong result if only local visiblity pass is run).
>
> A better fix might be simply do not check 'needed' bit for comdat
> varnode in LIPO mode and always run the visibiity checker:
>
> if ((vnode->needed || L_IPO_COMP_MODE)
> && varpool_node_externally_visible_p (...
> )
>
>
> David
>
>
>>
>>>
>>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
>>> ipa.c:1041: vnode->externally_visible = false;
>>> Better to add a simple loop after varpool_node_linking to merge the
>>> attribute in l-ipo.c assuming the linking happens after local visibility
>>> pass.
>>
>> We can merge in the varpool_node_link, but we still need to change
>> here as the attribute will be overwritten here in the whole_program
>> pass.
>>
>>>
>>> http://codereview.appspot.com/4798045/
>>>
>>
>
Re: [google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
On Thu, Jul 21, 2011 at 11:32 AM, Rong Xu wrote:
> On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c
>> File ipa.c (right):
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
>> ipa.c:1034: {
>> Has varpool node linking happened at this point? If not, the new code
>> here is not excersised.
>
> This functions is called in multiple places: local pass and
> whole_program pass. varpool_node_link is b/w these two passes. the
> varpool node attribute is set before the use in
> ipa_discover_readonly_nonaddressable_vars()
So the code relies on the second visibility pass to get things right
-- if that pass is disabled things can go wrong (if the default
visibility value when vnode is created is true, LIPO mode will get
pessemitic result; if the default is false, LIPO mode will still get
wrong result if only local visiblity pass is run).
A better fix might be simply do not check 'needed' bit for comdat
varnode in LIPO mode and always run the visibiity checker:
if ((vnode->needed || L_IPO_COMP_MODE)
&& varpool_node_externally_visible_p (...
)
David
>
>>
>> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
>> ipa.c:1041: vnode->externally_visible = false;
>> Better to add a simple loop after varpool_node_linking to merge the
>> attribute in l-ipo.c assuming the linking happens after local visibility
>> pass.
>
> We can merge in the varpool_node_link, but we still need to change
> here as the attribute will be overwritten here in the whole_program
> pass.
>
>>
>> http://codereview.appspot.com/4798045/
>>
>
Re: [Patches, Fortran] ALLOCATE & CAF library.
On 07/21/2011 07:22 PM, Tobias Burnus wrote:
On 07/21/2011 06:46 PM, Daniel Carrera wrote:
Ok. Updated patch and updated ChangeLog attached. Compiles fine and
I'm about to start running the test suite again.
Doesn't compile here:
gcc/fortran/trans.c: In function 'tree_node*
gfc_allocate_using_lib(stmtblock_t*, tree, tree, tree, tree)':
gcc/fortran/trans.c:656:8: error: unused variable 'status_type'
[-Werror=unused-variable]
Please fix before committal.
Hmm... I really wish that my Makefile was as picky as yours. But last
time I tried to change my configure flag everything went crazy.
The attached file contains the fix. I won't commit until I get a "ok"
from you.
Cheers,
Daniel.
--
I'm not overweight, I'm undertall.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 176528)
+++ gcc/fortran/trans-array.c (working copy)
@@ -4384,3 +4384,4 @@ gfc_array_init_size (tree descriptor, in
bool
-gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree pstat)
+gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg,
+ tree errlen)
{
@@ -4479,18 +4480,11 @@ gfc_array_allocate (gfc_se * se, gfc_exp
- if (pstat != NULL_TREE && !integer_zerop (pstat))
-{
- /* Set the status variable if it's present. */
+ if (status != NULL_TREE)
+{
+ tree status_type = TREE_TYPE (status);
stmtblock_t set_status_block;
- tree status_type = pstat ? TREE_TYPE (TREE_TYPE (pstat)) : NULL_TREE;
gfc_start_block (&set_status_block);
- gfc_add_modify (&set_status_block,
- fold_build1_loc (input_location, INDIRECT_REF,
- status_type, pstat),
- build_int_cst (status_type, LIBERROR_ALLOCATION));
-
- tmp = fold_build2_loc (input_location, EQ_EXPR, boolean_type_node,
- pstat, build_int_cst (TREE_TYPE (pstat), 0));
- error = fold_build3_loc (input_location, COND_EXPR, void_type_node, tmp,
- error, gfc_finish_block (&set_status_block));
+ gfc_add_modify (&set_status_block, status,
+ build_int_cst (status_type, LIBERROR_ALLOCATION));
+ error = gfc_finish_block (&set_status_block);
}
@@ -4503,10 +4497,11 @@ gfc_array_allocate (gfc_se * se, gfc_exp
- /* The allocate_array variants take the old pointer as first argument. */
+ /* The allocatable variant takes the old pointer as first argument. */
if (allocatable)
-tmp = gfc_allocate_allocatable_with_status (&elseblock,
- pointer, size, pstat, expr);
+tmp = gfc_allocate_allocatable (&elseblock, pointer, size,
+status, errmsg, errlen, expr);
else
-tmp = gfc_allocate_with_status (&elseblock, size, pstat, false);
- tmp = fold_build2_loc (input_location, MODIFY_EXPR, void_type_node, pointer,
- tmp);
+tmp = gfc_allocate_using_malloc (&elseblock, size, status);
+
+ tmp = fold_build2_loc (input_location, MODIFY_EXPR, void_type_node,
+ pointer, tmp);
Index: gcc/fortran/trans-array.h
===
--- gcc/fortran/trans-array.h (revision 176528)
+++ gcc/fortran/trans-array.h (working copy)
@@ -26,3 +26,3 @@ tree gfc_array_deallocate (tree, tree, g
se, which should contain an expression for the array descriptor. */
-bool gfc_array_allocate (gfc_se *, gfc_expr *, tree);
+bool gfc_array_allocate (gfc_se *, gfc_expr *, tree, tree, tree);
Index: gcc/fortran/trans-openmp.c
===
--- gcc/fortran/trans-openmp.c (revision 176528)
+++ gcc/fortran/trans-openmp.c (working copy)
@@ -190,5 +190,5 @@ gfc_omp_clause_default_ctor (tree clause
size = gfc_evaluate_now (fold_convert (size_type_node, size), &cond_block);
- ptr = gfc_allocate_allocatable_with_status (&cond_block,
- build_int_cst (pvoid_type_node, 0),
- size, NULL, NULL);
+ ptr = gfc_allocate_allocatable (&cond_block,
+ build_int_cst (pvoid_type_node, 0),
+ size, NULL_TREE, NULL_TREE, NULL_TREE, NULL);
gfc_conv_descriptor_data_set (&cond_block, decl, ptr);
@@ -243,5 +243,5 @@ gfc_omp_clause_copy_ctor (tree clause, t
size = gfc_evaluate_now (fold_convert (size_type_node, size), &block);
- ptr = gfc_allocate_allocatable_with_status (&block,
- build_int_cst (pvoid_type_node, 0),
- size, NULL, NULL);
+ ptr = gfc_allocate_allocatable (&block,
+ build_int_cst (pvoid_type_node, 0),
+ size, NULL_TREE, NULL_TREE, NULL_TREE, NULL);
gfc_conv_descriptor_data_set (&block, dest, ptr);
@@ -665,5 +665,5 @@ gfc_trans_omp_array_reduction (tree c, g
size = gfc_evaluate_now (fold_convert (size_type_node, size), &block);
- ptr = gfc_allocate_allocatable_with_status (&block,
- build_int_cst (pvoid_type_node, 0),
- size, NULL, NULL);
+ ptr = gfc_allocate_allocatable (&block,
+ build_int_cst (pvoid_type_node, 0),
+ size, NULL_TREE, NULL_TREE, NULL_TREE, NULL)
Re: [google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
On Thu, Jul 21, 2011 at 11:09 AM, wrote:
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c
> File ipa.c (right):
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
> ipa.c:1034: {
> Has varpool node linking happened at this point? If not, the new code
> here is not excersised.
This functions is called in multiple places: local pass and
whole_program pass. varpool_node_link is b/w these two passes. the
varpool node attribute is set before the use in
ipa_discover_readonly_nonaddressable_vars()
>
> http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
> ipa.c:1041: vnode->externally_visible = false;
> Better to add a simple loop after varpool_node_linking to merge the
> attribute in l-ipo.c assuming the linking happens after local visibility
> pass.
We can merge in the varpool_node_link, but we still need to change
here as the attribute will be overwritten here in the whole_program
pass.
>
> http://codereview.appspot.com/4798045/
>
[PATCH 10/10] Infer types based on lb and ub.
2011-07-21 Sebastian Pop
PR middle-end/47654
PR middle-end/49649
* graphite-clast-to-gimple.c (type_for_clast_term): Pass v1 and v2
in parameter. Initialize v1 and v2 based on the values returned
by clast_name_to_lb_ub.
(type_for_clast_red): Pass v1 and v2 in parameter, and set their
values.
(type_for_clast_bin): Same.
(type_for_clast_expr): Same.
(type_for_clast_eq): Update calls to type_for_clast_expr.
(type_for_clast_for): Same.
(build_iv_mapping): Same.
* graphite-ppl.h (value_min): New.
* gcc.dg/graphite/run-id-pr47654.c: New.
---
gcc/ChangeLog | 16 ++
gcc/graphite-clast-to-gimple.c | 184 +++-
gcc/graphite-ppl.h | 11 ++
gcc/testsuite/ChangeLog|6 +
gcc/testsuite/gcc.dg/graphite/run-id-pr47654.c | 24 +++
5 files changed, 204 insertions(+), 37 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/graphite/run-id-pr47654.c
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c79f0b4..394863d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,21 @@
2011-07-21 Sebastian Pop
+ PR middle-end/47654
+ PR middle-end/49649
+ * graphite-clast-to-gimple.c (type_for_clast_term): Pass v1 and v2
+ in parameter. Initialize v1 and v2 based on the values returned
+ by clast_name_to_lb_ub.
+ (type_for_clast_red): Pass v1 and v2 in parameter, and set their
+ values.
+ (type_for_clast_bin): Same.
+ (type_for_clast_expr): Same.
+ (type_for_clast_eq): Update calls to type_for_clast_expr.
+ (type_for_clast_for): Same.
+ (build_iv_mapping): Same.
+ * graphite-ppl.h (value_min): New.
+
+2011-07-21 Sebastian Pop
+
* graphite-clast-to-gimple.c (type_for_interval): Generate signed
types whenever possible.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 9cd2737..ddf6d3d 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -488,79 +488,164 @@ type_for_value (mpz_t val)
return type_for_interval (val, val);
}
-/* Return the type for the clast_term T used in STMT. */
+/* Return the type for the clast_term T. Initializes V1 and V2 to the
+ bounds of the term. */
static tree
-type_for_clast_term (struct clast_term *t, ivs_params_p ip)
+type_for_clast_term (struct clast_term *t, ivs_params_p ip, mpz_t v1, mpz_t v2)
{
+ clast_name_p name = t->var;
+ bool found = false;
+
gcc_assert (t->expr.type == clast_expr_term);
- if (!t->var)
-return type_for_value (t->val);
+ if (!name)
+{
+ mpz_set (v1, t->val);
+ mpz_set (v2, t->val);
+ return type_for_value (t->val);
+}
+
+ if (ip->params && ip->params_index)
+found = clast_name_to_lb_ub (name, ip->params_index, v1, v2);
- return TREE_TYPE (clast_name_to_gcc (t->var, ip));
+ if (!found)
+{
+ gcc_assert (*(ip->newivs) && ip->newivs_index);
+ found = clast_name_to_lb_ub (name, ip->newivs_index, v1, v2);
+ gcc_assert (found);
+}
+
+ mpz_mul (v1, v1, t->val);
+ mpz_mul (v2, v2, t->val);
+
+ return TREE_TYPE (clast_name_to_gcc (name, ip));
}
static tree
-type_for_clast_expr (struct clast_expr *, ivs_params_p);
+type_for_clast_expr (struct clast_expr *, ivs_params_p, mpz_t, mpz_t);
-/* Return the type for the clast_reduction R used in STMT. */
+/* Return the type for the clast_reduction R. Initializes V1 and V2
+ to the bounds of the reduction expression. */
static tree
-type_for_clast_red (struct clast_reduction *r, ivs_params_p ip)
+type_for_clast_red (struct clast_reduction *r, ivs_params_p ip,
+ mpz_t v1, mpz_t v2)
{
int i;
- tree type = NULL_TREE;
+ tree type = type_for_clast_expr (r->elts[0], ip, v1, v2);
+ mpz_t b1, b2, m1, m2;
if (r->n == 1)
-return type_for_clast_expr (r->elts[0], ip);
-
- switch (r->type)
-{
-case clast_red_sum:
-case clast_red_min:
-case clast_red_max:
- type = type_for_clast_expr (r->elts[0], ip);
- for (i = 1; i < r->n; i++)
- type = max_precision_type
- (type, type_for_clast_expr (r->elts[i], ip));
+return type;
- return type;
+ mpz_init (b1);
+ mpz_init (b2);
+ mpz_init (m1);
+ mpz_init (m2);
-default:
- break;
+ for (i = 1; i < r->n; i++)
+{
+ tree t = type_for_clast_expr (r->elts[i], ip, b1, b2);
+ type = max_precision_type (type, t);
+
+ switch (r->type)
+ {
+ case clast_red_sum:
+ value_min (m1, v1, v2);
+ value_min (m2, b1, b2);
+ mpz_add (v1, m1, m2);
+
+ value_max (m1, v1, v2);
+ value_max (m2, b1, b2);
+ mpz_add (v2, m1, m2);
+ break;
+
+ case clast_red_min:
+ value_min (v1, v1, v2);
+ value_min (v2, b1, b2);
+ break;
+
+
[PATCH 08/10] Compute once and cache the LB and UB for each clast_name.
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (struct clast_name_index): Add lb
and ub fields.
(new_clast_name_index): Add lb and ub parameters.
(free_clast_name_index): New.
(clast_name_to_lb_ub): New.
(save_clast_name_index): Add lb and ub parameters.
(compute_bounds_for_param): New.
(type_for_level): Removed.
(type_for_clast_for): Removed level parameter. Do not call
type_for_level.
(graphite_create_new_loop): Store the lb and ub for the clast_name
of the iterator of the loop that has been generated.
(graphite_create_new_loop_guard): Remove parameter level.
(create_params_index): Store the lb and ub of each parameter.
(gloog): Use free_clast_name_index. Pass to create_params_index
the current scop.
---
gcc/ChangeLog | 19 +
gcc/graphite-clast-to-gimple.c | 144
2 files changed, 121 insertions(+), 42 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 03fe015..485afca 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,24 @@
2011-07-21 Sebastian Pop
+ * graphite-clast-to-gimple.c (struct clast_name_index): Add lb
+ and ub fields.
+ (new_clast_name_index): Add lb and ub parameters.
+ (free_clast_name_index): New.
+ (clast_name_to_lb_ub): New.
+ (save_clast_name_index): Add lb and ub parameters.
+ (compute_bounds_for_param): New.
+ (type_for_level): Removed.
+ (type_for_clast_for): Removed level parameter. Do not call
+ type_for_level.
+ (graphite_create_new_loop): Store the lb and ub for the clast_name
+ of the iterator of the loop that has been generated.
+ (graphite_create_new_loop_guard): Remove parameter level.
+ (create_params_index): Store the lb and ub of each parameter.
+ (gloog): Use free_clast_name_index. Pass to create_params_index
+ the current scop.
+
+2011-07-21 Sebastian Pop
+
* graphite-clast-to-gimple.c (max_signed_precision_type): Removed.
(max_precision_type): Inline max_signed_precision_type.
(type_for_clast_red): Use max_precision_type.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 495b0b7..6bc84d2 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -57,28 +57,46 @@ graphite_verify (void)
}
/* Stores the INDEX in a vector and the loop nesting LEVEL for a given
- clast NAME. */
+ clast NAME. LB and UB represent the exact lower and upper bounds
+ that can be inferred from the polyhedral representation. */
typedef struct clast_name_index {
int index;
int level;
+ mpz_t lb, ub;
const char *name;
} *clast_name_index_p;
/* Returns a pointer to a new element of type clast_name_index_p built
- from NAME, LEVEL, and INDEX. */
+ from NAME, INDEX, LEVEL, LB, and UB. */
static inline clast_name_index_p
-new_clast_name_index (const char *name, int index, int level)
+new_clast_name_index (const char *name, int index, int level,
+ mpz_t lb, mpz_t ub)
{
clast_name_index_p res = XNEW (struct clast_name_index);
res->name = name;
res->level = level;
res->index = index;
+ mpz_init (res->lb);
+ mpz_init (res->ub);
+ mpz_set (res->lb, lb);
+ mpz_set (res->ub, ub);
return res;
}
+/* Free the memory taken by a clast_name_index struct. */
+
+static void
+free_clast_name_index (void *ptr)
+{
+ struct clast_name_index *c = (struct clast_name_index *) ptr;
+ mpz_clear (c->lb);
+ mpz_clear (c->ub);
+ free (ptr);
+}
+
/* For a given clast NAME, returns -1 if NAME is not in the
INDEX_TABLE, otherwise returns the loop level for the induction
variable NAME, or if it is a parameter, the parameter number in the
@@ -130,11 +148,40 @@ clast_name_to_index (clast_name_p name, htab_t
index_table)
return -1;
}
+/* For a given clast NAME, initializes the lower and upper bounds LB
+ and UB stored in the INDEX_TABLE. Returns true when NAME has been
+ found in the INDEX_TABLE, false otherwise. */
+
+static inline bool
+clast_name_to_lb_ub (clast_name_p name, htab_t index_table, mpz_t lb, mpz_t ub)
+{
+ struct clast_name_index tmp;
+ PTR *slot;
+
+#ifdef CLOOG_ORG
+ gcc_assert (name->type == clast_expr_name);
+ tmp.name = ((const struct clast_name *) name)->name;
+#else
+ tmp.name = name;
+#endif
+
+ slot = htab_find_slot (index_table, &tmp, NO_INSERT);
+
+ if (slot && *slot)
+{
+ mpz_set (lb, ((struct clast_name_index *) *slot)->lb);
+ mpz_set (ub, ((struct clast_name_index *) *slot)->ub);
+ return true;
+}
+
+ return false;
+}
+
/* Records in INDEX_TABLE the INDEX and LEVEL for NAME. */
static inline void
save_clast_name_index (htab_t index_table, const char *name,
- int index, int level)
+ int index, int level, mpz_t lb, mp
[PATCH 06/10] Rename gcc_type_for_clast_* into type_for_clast_*
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (gcc_type_for_interval): Renamed
type_for_interval.
(gcc_type_for_value): Renamed type_for_value.
(gcc_type_for_clast_term): Renamed type_for_clast_term.
(gcc_type_for_clast_expr): Renamed type_for_clast_expr.
(gcc_type_for_clast_red): Renamed type_for_clast_red.
(gcc_type_for_clast_bin): Renamed type_for_clast_bin.
(gcc_type_for_clast_eq): Renamed type_for_clast_eq.
(graphite_translate_clast_equation): Update calls.
(compute_type_for_level): Renamed type_for_level.
(gcc_type_for_iv_of_clast_loop): Renamed type_for_clast_for.
(build_iv_mapping): Update calls.
(graphite_create_new_loop_guard): Same.
---
gcc/ChangeLog | 16 ++
gcc/graphite-clast-to-gimple.c | 65 ++-
2 files changed, 46 insertions(+), 35 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index eec05b8..0ae048f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,21 @@
2011-07-21 Sebastian Pop
+ * graphite-clast-to-gimple.c (gcc_type_for_interval): Renamed
+ type_for_interval.
+ (gcc_type_for_value): Renamed type_for_value.
+ (gcc_type_for_clast_term): Renamed type_for_clast_term.
+ (gcc_type_for_clast_expr): Renamed type_for_clast_expr.
+ (gcc_type_for_clast_red): Renamed type_for_clast_red.
+ (gcc_type_for_clast_bin): Renamed type_for_clast_bin.
+ (gcc_type_for_clast_eq): Renamed type_for_clast_eq.
+ (graphite_translate_clast_equation): Update calls.
+ (compute_type_for_level): Renamed type_for_level.
+ (gcc_type_for_iv_of_clast_loop): Renamed type_for_clast_for.
+ (build_iv_mapping): Update calls.
+ (graphite_create_new_loop_guard): Same.
+
+2011-07-21 Sebastian Pop
+
* graphite-clast-to-gimple.c (clast_get_body_of_loop): Add fixme
comment.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index b7bfaa8..b1d682a 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -398,7 +398,7 @@ clast_to_gcc_expression (tree type, struct clast_expr *e,
ivs_params_p ip)
/* Return a type that could represent the values between V1 and V2. */
static tree
-gcc_type_for_interval (mpz_t v1, mpz_t v2)
+type_for_interval (mpz_t v1, mpz_t v2)
{
bool unsigned_p;
tree type;
@@ -434,48 +434,46 @@ gcc_type_for_interval (mpz_t v1, mpz_t v2)
otherwise return NULL_TREE. */
static tree
-gcc_type_for_value (mpz_t val)
+type_for_value (mpz_t val)
{
- return gcc_type_for_interval (val, val);
+ return type_for_interval (val, val);
}
/* Return the type for the clast_term T used in STMT. */
static tree
-gcc_type_for_clast_term (struct clast_term *t,
-ivs_params_p ip)
+type_for_clast_term (struct clast_term *t, ivs_params_p ip)
{
gcc_assert (t->expr.type == clast_expr_term);
if (!t->var)
-return gcc_type_for_value (t->val);
+return type_for_value (t->val);
return TREE_TYPE (clast_name_to_gcc (t->var, ip));
}
static tree
-gcc_type_for_clast_expr (struct clast_expr *, ivs_params_p);
+type_for_clast_expr (struct clast_expr *, ivs_params_p);
/* Return the type for the clast_reduction R used in STMT. */
static tree
-gcc_type_for_clast_red (struct clast_reduction *r,
- ivs_params_p ip)
+type_for_clast_red (struct clast_reduction *r, ivs_params_p ip)
{
int i;
tree type = NULL_TREE;
if (r->n == 1)
-return gcc_type_for_clast_expr (r->elts[0], ip);
+return type_for_clast_expr (r->elts[0], ip);
switch (r->type)
{
case clast_red_sum:
case clast_red_min:
case clast_red_max:
- type = gcc_type_for_clast_expr (r->elts[0], ip);
+ type = type_for_clast_expr (r->elts[0], ip);
for (i = 1; i < r->n; i++)
- type = max_precision_type (type, gcc_type_for_clast_expr
+ type = max_precision_type (type, type_for_clast_expr
(r->elts[i], ip));
return type;
@@ -491,10 +489,10 @@ gcc_type_for_clast_red (struct clast_reduction *r,
/* Return the type for the clast_binary B used in STMT. */
static tree
-gcc_type_for_clast_bin (struct clast_binary *b, ivs_params_p ip)
+type_for_clast_bin (struct clast_binary *b, ivs_params_p ip)
{
- tree l = gcc_type_for_clast_expr ((struct clast_expr *) b->LHS, ip);
- tree r = gcc_type_for_value (b->RHS);
+ tree l = type_for_clast_expr ((struct clast_expr *) b->LHS, ip);
+ tree r = type_for_value (b->RHS);
return max_signed_precision_type (l, r);
}
@@ -502,19 +500,18 @@ gcc_type_for_clast_bin (struct clast_binary *b,
ivs_params_p ip)
STMT. */
static tree
-gcc_type_for_clast_expr (struct clast_expr *e,
-ivs_params_p ip)
+type_for_clast_expr (struct clast_expr *e, ivs_params_p ip)
{
switch (e->type)
{
[PATCH 04/10] Cleanup function params using a struct.
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (struct ivs_params): New.
(clast_name_to_gcc): Use ivs_params to pass around parameters.
(clast_to_gcc_expression): Same.
(clast_to_gcc_expression_red): Same.
(gcc_type_for_clast_term): Same.
(gcc_type_for_clast_expr): Same.
(gcc_type_for_clast_red): Same.
(gcc_type_for_clast_bin): Same.
(gcc_type_for_clast_eq): Same.
(graphite_translate_clast_equation): Same.
(graphite_create_guard_cond_expr): Same.
(graphite_create_new_guard): Same.
(graphite_create_new_loop): Same.
(build_iv_mapping): Same.
(translate_clast_user): Same.
(graphite_create_new_loop_guard): Same.
(translate_clast): Same.
(translate_clast_for_loop): Same.
(translate_clast_for): Same.
(translate_clast_guard): Same.
(initialize_cloog_names): Fix typo.
(gloog): Initialize an ivs_params struct, pass it to translate_clast.
---
gcc/ChangeLog | 25 +++
gcc/graphite-clast-to-gimple.c | 336
2 files changed, 155 insertions(+), 206 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d74938f..e6abcec 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,30 @@
2011-07-21 Sebastian Pop
+ * graphite-clast-to-gimple.c (struct ivs_params): New.
+ (clast_name_to_gcc): Use ivs_params to pass around parameters.
+ (clast_to_gcc_expression): Same.
+ (clast_to_gcc_expression_red): Same.
+ (gcc_type_for_clast_term): Same.
+ (gcc_type_for_clast_expr): Same.
+ (gcc_type_for_clast_red): Same.
+ (gcc_type_for_clast_bin): Same.
+ (gcc_type_for_clast_eq): Same.
+ (graphite_translate_clast_equation): Same.
+ (graphite_create_guard_cond_expr): Same.
+ (graphite_create_new_guard): Same.
+ (graphite_create_new_loop): Same.
+ (build_iv_mapping): Same.
+ (translate_clast_user): Same.
+ (graphite_create_new_loop_guard): Same.
+ (translate_clast): Same.
+ (translate_clast_for_loop): Same.
+ (translate_clast_for): Same.
+ (translate_clast_guard): Same.
+ (initialize_cloog_names): Fix typo.
+ (gloog): Initialize an ivs_params struct, pass it to translate_clast.
+
+2011-07-21 Sebastian Pop
+
* graphite-clast-to-gimple.c (struct clast_name_index): Add level.
(new_clast_name_index): Add level parameter.
(clast_name_to_level): New.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index c442f1e..099109a 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -171,29 +171,39 @@ eq_clast_name_indexes (const void *e1, const void *e2)
+/* NEWIVS_INDEX binds CLooG's scattering name to the index of the tree
+ induction variable in NEWIVS.
+
+ PARAMS_INDEX binds CLooG's parameter name to the index of the tree
+ parameter in PARAMS. */
+
+typedef struct ivs_params {
+ VEC (tree, heap) *params, **newivs;
+ htab_t newivs_index, params_index;
+ sese region;
+} *ivs_params_p;
+
/* Returns the tree variable from the name NAME that was given in
Cloog representation. */
static tree
-clast_name_to_gcc (clast_name_p name, sese region, VEC (tree, heap) *newivs,
- htab_t newivs_index, htab_t params_index)
+clast_name_to_gcc (clast_name_p name, ivs_params_p ip)
{
int index;
- VEC (tree, heap) *params = SESE_PARAMS (region);
- if (params && params_index)
+ if (ip->params && ip->params_index)
{
- index = clast_name_to_index (name, params_index);
+ index = clast_name_to_index (name, ip->params_index);
if (index >= 0)
- return VEC_index (tree, params, index);
+ return VEC_index (tree, ip->params, index);
}
- gcc_assert (newivs && newivs_index);
- index = clast_name_to_index (name, newivs_index);
+ gcc_assert (*(ip->newivs) && ip->newivs_index);
+ index = clast_name_to_index (name, ip->newivs_index);
gcc_assert (index >= 0);
- return VEC_index (tree, newivs, index);
+ return VEC_index (tree, *(ip->newivs), index);
}
/* Returns the signed maximal precision type for expressions TYPE1 and TYPE2.
*/
@@ -250,27 +260,22 @@ max_precision_type (tree type1, tree type2)
}
static tree
-clast_to_gcc_expression (tree, struct clast_expr *, sese, VEC (tree, heap) *,
-htab_t, htab_t);
+clast_to_gcc_expression (tree, struct clast_expr *, ivs_params_p);
/* Converts a Cloog reduction expression R with reduction operation OP
to a GCC expression tree of type TYPE. */
static tree
clast_to_gcc_expression_red (tree type, enum tree_code op,
-struct clast_reduction *r,
-sese region, VEC (tree, heap) *newivs,
-htab_t newivs_index, htab_t params_index)
+st
[PATCH 07/10] Remove max_signed_precision_type.
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (max_signed_precision_type): Removed.
(max_precision_type): Inline max_signed_precision_type.
(type_for_clast_red): Use max_precision_type.
(type_for_clast_bin): Same.
(type_for_clast_for): Same.
---
gcc/ChangeLog |8 ++
gcc/graphite-clast-to-gimple.c | 51 +--
2 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 0ae048f..03fe015 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,13 @@
2011-07-21 Sebastian Pop
+ * graphite-clast-to-gimple.c (max_signed_precision_type): Removed.
+ (max_precision_type): Inline max_signed_precision_type.
+ (type_for_clast_red): Use max_precision_type.
+ (type_for_clast_bin): Same.
+ (type_for_clast_for): Same.
+
+2011-07-21 Sebastian Pop
+
* graphite-clast-to-gimple.c (gcc_type_for_interval): Renamed
type_for_interval.
(gcc_type_for_value): Renamed type_for_value.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index b1d682a..495b0b7 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -206,16 +206,27 @@ clast_name_to_gcc (clast_name_p name, ivs_params_p ip)
return VEC_index (tree, *(ip->newivs), index);
}
-/* Returns the signed maximal precision type for expressions TYPE1 and TYPE2.
*/
+/* Returns the maximal precision type for expressions TYPE1 and TYPE2. */
static tree
-max_signed_precision_type (tree type1, tree type2)
+max_precision_type (tree type1, tree type2)
{
- int p1 = TYPE_PRECISION (type1);
- int p2 = TYPE_PRECISION (type2);
- int precision;
- tree type;
enum machine_mode mode;
+ int p1, p2, precision;
+ tree type;
+
+ if (POINTER_TYPE_P (type1))
+return type1;
+
+ if (POINTER_TYPE_P (type2))
+return type2;
+
+ if (TYPE_UNSIGNED (type1)
+ && TYPE_UNSIGNED (type2))
+return TYPE_PRECISION (type1) > TYPE_PRECISION (type2) ? type1 : type2;
+
+ p1 = TYPE_PRECISION (type1);
+ p2 = TYPE_PRECISION (type2);
if (p1 > p2)
precision = TYPE_UNSIGNED (type1) ? p1 * 2 : p1;
@@ -241,24 +252,6 @@ max_signed_precision_type (tree type1, tree type2)
return type;
}
-/* Returns the maximal precision type for expressions TYPE1 and TYPE2. */
-
-static tree
-max_precision_type (tree type1, tree type2)
-{
- if (POINTER_TYPE_P (type1))
-return type1;
-
- if (POINTER_TYPE_P (type2))
-return type2;
-
- if (!TYPE_UNSIGNED (type1)
- || !TYPE_UNSIGNED (type2))
-return max_signed_precision_type (type1, type2);
-
- return TYPE_PRECISION (type1) > TYPE_PRECISION (type2) ? type1 : type2;
-}
-
static tree
clast_to_gcc_expression (tree, struct clast_expr *, ivs_params_p);
@@ -473,8 +466,8 @@ type_for_clast_red (struct clast_reduction *r, ivs_params_p
ip)
case clast_red_max:
type = type_for_clast_expr (r->elts[0], ip);
for (i = 1; i < r->n; i++)
- type = max_precision_type (type, type_for_clast_expr
- (r->elts[i], ip));
+ type = max_precision_type
+ (type, type_for_clast_expr (r->elts[i], ip));
return type;
@@ -493,7 +486,7 @@ type_for_clast_bin (struct clast_binary *b, ivs_params_p ip)
{
tree l = type_for_clast_expr ((struct clast_expr *) b->LHS, ip);
tree r = type_for_value (b->RHS);
- return max_signed_precision_type (l, r);
+ return max_precision_type (l, r);
}
/* Returns the type for the CLAST expression E when used in statement
@@ -688,8 +681,8 @@ type_for_clast_for (struct clast_for *stmt_for, int level,
tree lb_type = type_for_clast_expr (stmt_for->LB, ip);
tree ub_type = type_for_clast_expr (stmt_for->UB, ip);
- return max_signed_precision_type (lb_type, max_precision_type
- (ub_type, type_for_level (pbb, level)));
+ return max_precision_type
+(lb_type, max_precision_type (ub_type, type_for_level (pbb, level)));
}
/* Creates a new LOOP corresponding to Cloog's STMT. Inserts an
--
1.7.4.1
[PATCH 09/10] Generate signed types whenever possible.
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (type_for_interval): Generate signed
types whenever possible.
---
gcc/ChangeLog |5 +
gcc/graphite-clast-to-gimple.c | 13 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 485afca..c79f0b4 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
2011-07-21 Sebastian Pop
+ * graphite-clast-to-gimple.c (type_for_interval): Generate signed
+ types whenever possible.
+
+2011-07-21 Sebastian Pop
+
* graphite-clast-to-gimple.c (struct clast_name_index): Add lb
and ub fields.
(new_clast_name_index): Add lb and ub parameters.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 6bc84d2..9cd2737 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -443,6 +443,7 @@ type_for_interval (mpz_t v1, mpz_t v2)
bool unsigned_p;
tree type;
enum machine_mode mode;
+ int wider_precision;
int precision = MAX (mpz_sizeinbase (v1, 2),
mpz_sizeinbase (v2, 2));
@@ -458,8 +459,16 @@ type_for_interval (mpz_t v1, mpz_t v2)
unsigned_p = (mpz_sgn (v2) >= 0);
mode = smallest_mode_for_size (precision, MODE_INT);
- precision = GET_MODE_PRECISION (mode);
- type = build_nonstandard_integer_type (precision, unsigned_p);
+ wider_precision = GET_MODE_PRECISION (mode);
+
+ /* As we want to generate signed types as much as possible, try to
+ fit the interval [v1, v2] in a signed type. For example,
+ supposing that we have the interval [0, 100], instead of
+ generating unsigned char, we want to generate a signed char. */
+ if (unsigned_p && precision < wider_precision)
+unsigned_p = false;
+
+ type = build_nonstandard_integer_type (wider_precision, unsigned_p);
if (!type)
{
--
1.7.4.1
[PATCH 03/10] Record the loop level that defines a clast_name.
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (struct clast_name_index): Add level.
(new_clast_name_index): Add level parameter.
(clast_name_to_level): New.
(save_clast_name_index): Add level parameter.
(newivs_to_depth_to_newiv): Removed.
(clast_name_to_gcc): Inlined newivs_to_depth_to_newiv.
(graphite_create_new_loop): Add level parameter. Pass level to
save_clast_name_index.
(translate_clast_for_loop): Pass level to graphite_create_new_loop.
(create_params_index): Pass level to save_clast_name_index.
---
gcc/ChangeLog | 13
gcc/graphite-clast-to-gimple.c | 61 +++-
2 files changed, 54 insertions(+), 20 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 13a8bd8..d74938f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2011-07-21 Sebastian Pop
+
+ * graphite-clast-to-gimple.c (struct clast_name_index): Add level.
+ (new_clast_name_index): Add level parameter.
+ (clast_name_to_level): New.
+ (save_clast_name_index): Add level parameter.
+ (newivs_to_depth_to_newiv): Removed.
+ (clast_name_to_gcc): Inlined newivs_to_depth_to_newiv.
+ (graphite_create_new_loop): Add level parameter. Pass level to
+ save_clast_name_index.
+ (translate_clast_for_loop): Pass level to graphite_create_new_loop.
+ (create_params_index): Pass level to save_clast_name_index.
+
2011-07-05 Sebastian Pop
* graphite-clast-to-gimple.c (graphite_create_new_loop): Do not
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index a8ac9c6..c442f1e 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -56,26 +56,55 @@ graphite_verify (void)
#endif
}
-/* Stores the INDEX in a vector for a given clast NAME. */
+/* Stores the INDEX in a vector and the loop nesting LEVEL for a given
+ clast NAME. */
typedef struct clast_name_index {
int index;
+ int level;
const char *name;
} *clast_name_index_p;
/* Returns a pointer to a new element of type clast_name_index_p built
- from NAME and INDEX. */
+ from NAME, LEVEL, and INDEX. */
static inline clast_name_index_p
-new_clast_name_index (const char *name, int index)
+new_clast_name_index (const char *name, int index, int level)
{
clast_name_index_p res = XNEW (struct clast_name_index);
res->name = name;
+ res->level = level;
res->index = index;
return res;
}
+/* For a given clast NAME, returns -1 if NAME is not in the
+ INDEX_TABLE, otherwise returns the loop level for the induction
+ variable NAME, or if it is a parameter, the parameter number in the
+ vector of parameters. */
+
+static inline int
+clast_name_to_level (clast_name_p name, htab_t index_table)
+{
+ struct clast_name_index tmp;
+ PTR *slot;
+
+#ifdef CLOOG_ORG
+ gcc_assert (name->type == clast_expr_name);
+ tmp.name = ((const struct clast_name *) name)->name;
+#else
+ tmp.name = name;
+#endif
+
+ slot = htab_find_slot (index_table, &tmp, NO_INSERT);
+
+ if (slot && *slot)
+return ((struct clast_name_index *) *slot)->level;
+
+ return -1;
+}
+
/* For a given clast NAME, returns -1 if it does not correspond to any
parameter, or otherwise, returns the index in the PARAMS or
SCATTERING_DIMENSIONS vector. */
@@ -101,10 +130,11 @@ clast_name_to_index (clast_name_p name, htab_t
index_table)
return -1;
}
-/* Records in INDEX_TABLE the INDEX for NAME. */
+/* Records in INDEX_TABLE the INDEX and LEVEL for NAME. */
static inline void
-save_clast_name_index (htab_t index_table, const char *name, int index)
+save_clast_name_index (htab_t index_table, const char *name,
+ int index, int level)
{
struct clast_name_index tmp;
PTR *slot;
@@ -116,7 +146,7 @@ save_clast_name_index (htab_t index_table, const char
*name, int index)
{
free (*slot);
- *slot = new_clast_name_index (name, index);
+ *slot = new_clast_name_index (name, index, level);
}
}
@@ -139,15 +169,6 @@ eq_clast_name_indexes (const void *e1, const void *e2)
return (elt1->name == elt2->name);
}
-/* For a given scattering dimension, return the new induction variable
- associated to it. */
-
-static inline tree
-newivs_to_depth_to_newiv (VEC (tree, heap) *newivs, int depth)
-{
- return VEC_index (tree, newivs, depth);
-}
-
/* Returns the tree variable from the name NAME that was given in
@@ -172,7 +193,7 @@ clast_name_to_gcc (clast_name_p name, sese region, VEC
(tree, heap) *newivs,
index = clast_name_to_index (name, newivs_index);
gcc_assert (index >= 0);
- return newivs_to_depth_to_newiv (newivs, index);
+ return VEC_index (tree, newivs, index);
}
/* Returns the signed maximal precision type for expressions TYPE1 and TYPE2.
*/
@@ -703,7 +724,7 @@ graphite_create_new_loop (edge entry_edge,
[PATCH 05/10] Add fixme comment.
2011-07-21 Sebastian Pop
* graphite-clast-to-gimple.c (clast_get_body_of_loop): Add fixme
comment.
---
gcc/ChangeLog |5 +
gcc/graphite-clast-to-gimple.c | 19 ++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index e6abcec..eec05b8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
2011-07-21 Sebastian Pop
+ * graphite-clast-to-gimple.c (clast_get_body_of_loop): Add fixme
+ comment.
+
+2011-07-21 Sebastian Pop
+
* graphite-clast-to-gimple.c (struct ivs_params): New.
(clast_name_to_gcc): Use ivs_params to pass around parameters.
(clast_to_gcc_expression): Same.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 099109a..b7bfaa8 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -640,7 +640,24 @@ compute_type_for_level (poly_bb_p pbb, int level)
}
/* Walks a CLAST and returns the first statement in the body of a
- loop. */
+ loop.
+
+ FIXME: This function should not be used to get a PBB in the STMT
+ loop in order to find out the iteration domain of the loop: the
+ counter example from Tobias is:
+
+ | for (i = 0; i < 100; i++)
+ | {
+ | if (i == 0)
+ | S1;
+ | S2;
+ | }
+
+ This function would return S1 whose iteration domain contains only
+ one point "i = 0", whereas the iteration domain of S2 has 100 points.
+
+ This should be implemented using some functionality existing in
+ CLooG-ISL. */
static struct clast_user_stmt *
clast_get_body_of_loop (struct clast_stmt *stmt)
--
1.7.4.1
[PATCH 02/10] Do not compute twice type, lb, and ub.
2011-07-05 Sebastian Pop
* graphite-clast-to-gimple.c (graphite_create_new_loop): Do not
recompute type, lb, and ub. Get them from...
(graphite_create_new_loop_guard): ...here. Pass in parameter
pointers to type, lb, and ub.
(translate_clast_for_loop): Update function calls.
(translate_clast_for): Same.
---
gcc/ChangeLog |9 ++
gcc/graphite-clast-to-gimple.c | 61 +++
2 files changed, 39 insertions(+), 31 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 5c1c630..13a8bd8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,14 @@
2011-07-05 Sebastian Pop
+ * graphite-clast-to-gimple.c (graphite_create_new_loop): Do not
+ recompute type, lb, and ub. Get them from...
+ (graphite_create_new_loop_guard): ...here. Pass in parameter
+ pointers to type, lb, and ub.
+ (translate_clast_for_loop): Update function calls.
+ (translate_clast_for): Same.
+
+2011-07-05 Sebastian Pop
+
* graphite-clast-to-gimple.c (compute_bounds_for_level): Call
psct_dynamic_dim.
(translate_clast_for_loop): Pass loop level to dependency_in_loop_p.
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 53af18e..a8ac9c6 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -696,23 +696,15 @@ gcc_type_for_iv_of_clast_loop (struct clast_for
*stmt_for, int level,
becomes the child loop of the OUTER_LOOP. NEWIVS_INDEX binds
CLooG's scattering name to the induction variable created for the
loop of STMT. The new induction variable is inserted in the NEWIVS
- vector. */
+ vector and is of type TYPE. */
static struct loop *
-graphite_create_new_loop (sese region, edge entry_edge,
+graphite_create_new_loop (edge entry_edge,
struct clast_for *stmt,
loop_p outer, VEC (tree, heap) **newivs,
- htab_t newivs_index, htab_t params_index, int level)
+ htab_t newivs_index,
+ tree type, tree lb, tree ub)
{
- tree lb_type = gcc_type_for_clast_expr (stmt->LB, region, *newivs,
- newivs_index, params_index);
- tree ub_type = gcc_type_for_clast_expr (stmt->UB, region, *newivs,
- newivs_index, params_index);
- tree type = gcc_type_for_iv_of_clast_loop (stmt, level, lb_type, ub_type);
- tree lb = clast_to_gcc_expression (type, stmt->LB, region, *newivs,
-newivs_index, params_index);
- tree ub = clast_to_gcc_expression (type, stmt->UB, region, *newivs,
-newivs_index, params_index);
tree stride = gmp_cst_to_tree (type, stmt->stride);
tree ivvar = create_tmp_var (type, "graphite_IV");
tree iv, iv_after_increment;
@@ -887,7 +879,8 @@ static edge
graphite_create_new_loop_guard (sese region, edge entry_edge,
struct clast_for *stmt,
VEC (tree, heap) *newivs,
- htab_t newivs_index, htab_t params_index)
+ htab_t newivs_index, htab_t params_index,
+ int level, tree *type, tree *lb, tree *ub)
{
tree cond_expr;
edge exit_edge;
@@ -895,28 +888,30 @@ graphite_create_new_loop_guard (sese region, edge
entry_edge,
newivs_index, params_index);
tree ub_type = gcc_type_for_clast_expr (stmt->UB, region, newivs,
newivs_index, params_index);
- tree type = max_precision_type (lb_type, ub_type);
- tree lb = clast_to_gcc_expression (type, stmt->LB, region, newivs,
-newivs_index, params_index);
- tree ub = clast_to_gcc_expression (type, stmt->UB, region, newivs,
-newivs_index, params_index);
+
+ *type = gcc_type_for_iv_of_clast_loop (stmt, level, lb_type, ub_type);
+ *lb = clast_to_gcc_expression (*type, stmt->LB, region, newivs,
+newivs_index, params_index);
+ *ub = clast_to_gcc_expression (*type, stmt->UB, region, newivs,
+newivs_index, params_index);
+
/* When ub is simply a constant or a parameter, use lb <= ub. */
- if (TREE_CODE (ub) == INTEGER_CST || TREE_CODE (ub) == SSA_NAME)
-cond_expr = fold_build2 (LE_EXPR, boolean_type_node, lb, ub);
+ if (TREE_CODE (*ub) == INTEGER_CST || TREE_CODE (*ub) == SSA_NAME)
+cond_expr = fold_build2 (LE_EXPR, boolean_type_node, *lb, *ub);
else
{
- tree one = (POINTER_TYPE_P (type)
+ tree one = (POINTER_TYPE_P (*type)
? size_one_node
- : fold_convert (type, integer_one_node));
+ : fold_convert (*type, integer_one_node));
[PATCH 01/10] Start counting nesting level from 0 and use the standard "Polyhedral SCattering Transformed" psct_* interface.
2011-07-05 Sebastian Pop
* graphite-clast-to-gimple.c (compute_bounds_for_level): Call
psct_dynamic_dim.
(translate_clast_for_loop): Pass loop level to dependency_in_loop_p.
(gcc_type_for_iv_of_clast_loop): Update use of level.
(gloog): Start counting nesting level from 0.
* graphite-clast-to-gimple.h (get_scattering_level): Removed.
* graphite-dependences.c (graphite_carried_dependence_level_k): Call
psct_dynamic_dim on level.
---
gcc/ChangeLog | 11 +++
gcc/graphite-clast-to-gimple.c | 11 +--
gcc/graphite-clast-to-gimple.h | 12
gcc/graphite-dependences.c |9 ++---
4 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f114c25..5c1c630 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2011-07-05 Sebastian Pop
+
+ * graphite-clast-to-gimple.c (compute_bounds_for_level): Call
+ psct_dynamic_dim.
+ (translate_clast_for_loop): Pass loop level to dependency_in_loop_p.
+ (gcc_type_for_iv_of_clast_loop): Update use of level.
+ (gloog): Start counting nesting level from 0.
+ * graphite-clast-to-gimple.h (get_scattering_level): Removed.
+ * graphite-dependences.c (graphite_carried_dependence_level_k): Call
+ psct_dynamic_dim on level.
+
2011-07-18 Martin Jambor
* ipa-prop.h: Include alloc-pool.h, all sorts of updates to general
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 6b17631..53af18e 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -622,7 +622,7 @@ compute_bounds_for_level (poly_bb_p pbb, int level, mpz_t
low, mpz_t up)
+ pbb_dim_iter_domain (pbb) + pbb_nb_params (pbb);
ppl_new_Linear_Expression_with_dimension (&le, dim);
-ppl_set_coef (le, 2 * level + 1, 1);
+ppl_set_coef (le, psct_dynamic_dim (pbb, level), 1);
}
ppl_max_for_le_pointset (ps, le, up);
@@ -687,7 +687,7 @@ gcc_type_for_iv_of_clast_loop (struct clast_for *stmt_for,
int level,
return max_signed_precision_type (lb_type, max_precision_type
(ub_type, compute_type_for_level
-(pbb, level - 1)));
+(pbb, level)));
}
/* Creates a new LOOP corresponding to Cloog's STMT. Inserts an
@@ -803,7 +803,7 @@ find_pbb_via_hash (htab_t bb_pbb_mapping, basic_block bb)
return NULL;
}
-/* Check data dependency in LOOP at scattering level LEVEL.
+/* Check data dependency in LOOP at level LEVEL.
BB_PBB_MAPPING is a basic_block and it's related poly_bb_p
mapping. */
@@ -961,8 +961,7 @@ translate_clast_for_loop (sese region, loop_p context_loop,
set_immediate_dominator (CDI_DOMINATORS, next_e->dest, next_e->src);
if (flag_loop_parallelize_all
- && !dependency_in_loop_p (loop, bb_pbb_mapping,
- get_scattering_level (level)))
+ && !dependency_in_loop_p (loop, bb_pbb_mapping, level))
loop->can_be_parallel = true;
return last_e;
@@ -1477,7 +1476,7 @@ gloog (scop_p scop, htab_t bb_pbb_mapping)
translate_clast (region, context_loop, pc.stmt,
if_region->true_region->entry,
&newivs, newivs_index,
- bb_pbb_mapping, 1, params_index);
+ bb_pbb_mapping, 0, params_index);
graphite_verify ();
scev_reset ();
recompute_all_dominators ();
diff --git a/gcc/graphite-clast-to-gimple.h b/gcc/graphite-clast-to-gimple.h
index 9d599d6..b5affd9 100644
--- a/gcc/graphite-clast-to-gimple.h
+++ b/gcc/graphite-clast-to-gimple.h
@@ -63,16 +63,4 @@ eq_bb_pbb_map (const void *bb_pbb1, const void *bb_pbb2)
return (bp1->bb->index == bp2->bb->index);
}
-/* Returns the scattering dimension for STMTFOR.
-
- The relationship between dimension in scattering matrix
- and the DEPTH of the loop is:
- DIMENSION = 2*DEPTH - 1
-*/
-
-static inline int get_scattering_level (int depth)
-{
- return 2 * depth - 1;
-}
-
#endif
diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c
index 081aa69..fb49f16 100644
--- a/gcc/graphite-dependences.c
+++ b/gcc/graphite-dependences.c
@@ -745,11 +745,13 @@ graphite_carried_dependence_level_k (poly_dr_p pdr1,
poly_dr_p pdr2,
{
ppl_Pointset_Powerset_C_Polyhedron_t po;
ppl_Pointset_Powerset_C_Polyhedron_t eqpp;
- graphite_dim_t tdim1 = pbb_nb_scattering_transform (PDR_PBB (pdr1));
- graphite_dim_t ddim1 = pbb_dim_iter_domain (PDR_PBB (pdr1));
+ poly_bb_p pbb = PDR_PBB (pdr1);
+ graphite_dim_t tdim1 = pbb_nb_scattering_transform (pbb);
+ graphite_dim_t ddim1 = pbb_dim_iter_domain (pbb);
ppl_dimension_type dim;
bool empty_p;
poly_ddr_p pddr = new_poly_ddr (pdr1, pdr2, 1, false);
+ graphite_dim_t pos;
if (PDDR_KIND (pddr) == unknown_dependence)
{
@@ -765,7 +767,8 @@ graphite_carried_dependence_le
[PATCH 00/10] Second attempt to fix PR47654 and PR49649
Hi, This patch-set addresses the comments from Tobias on fixing PR47654. The first patches are cleanups: - Start counting nesting level from 0 and use the standard "Polyhedral SCattering Transformed" psct_* interface. - Do not compute twice type, lb, and ub. - Record the loop level that defines a clast_name. - Cleanup function params using a struct. - Add fixme comment. - Rename gcc_type_for_clast_* into type_for_clast_* - Remove max_signed_precision_type. The following patch is an optimization: - Compute once and cache the LB and UB for each clast_name. that uses the hashtable of clast_names to also attach the information on bounds of the name: this would avoid asking "polyhedral questions" every time we see the name of an induction variable in an expression. The following patch is also an optimization: - Generate signed types whenever possible. this makes us generate signed types instead of unsigned, whenever the interval would still fit in a signed type of the same precision. Finally the fix for PR47654: - Infer types based on lb and ub. I adapted the previous patch such that we now compute both the type and the bounds during the same traversal of the CLAST tree. The computation of the type now also integrates the information of the bounds of the sub-expressions and the result of the expression. The patch-set bootstrapped and tested on amd64-linux. Ok for trunk? Thanks, Sebastian
Re: [PATCH] Attempt to increase RLIMIT_STACK in the driver as well as compiler (PR c++/49756, take 3)
Jakub Jelinek writes: > 2011-07-21 Jakub Jelinek > > PR c++/49756 > * libiberty.h (stack_limit_increase): New prototype. > > * stack-limit.c: New file. > * Makefile.in: Regenerate deps. > (CFILES): Add stack-limit.c. > (REQUIRED_OFILES): Add ./stack-limit.$(objext). > * configure.ac (checkfuncs): Add getrlimit and setrlimit. > (AC_CHECK_FUNCS): Likewise. > * configure: Regenerated. > * config.in: Regenerated. > > * gcc.c (main): Call stack_limit_increase (64MB). > * toplev.c (toplev_main): Likewise. This is OK. Thanks. Ian
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 10:30 AM, Uros Bizjak wrote: > On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak wrote: >>> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu wrote: >>> >> ".quad symbol" isn't really valid for 32bit. > > Why not? We certainly know what value to put there. > x32 doesn't support 64bit relocation, like R_X86_64_64. In many causes, generate .long symbol .long 0 for ".quad symbol" is wrong. Please see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 for some examples. >>> >>> Please also see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >>> >>> on why I think this is middle-end/tree-optimization issue. >>> >> >> I still think it is a backend issue. > > /* Represents viewing something of one type as being of a second type. > This corresponds to an "Unchecked Conversion" in Ada and roughly to > the idiom *(type2 *)&X in C. The only operand is the value to be > viewed as being of another type. **It is undefined if the type of the > input and of the expression have different sizes.** > > ... > DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) > > We have: > > : > D.2709_8 = VIEW_CONVERT_EXPR(&); > D.2702_1 = u.d; > D.2704_3 = D.2702_1 == D.2709_8; > D.2701_4 = (int) D.2704_3; > return D.2701_4; > > Where > > sizeof (double) = 64 > sizeof (ptr_type) = 32. > We may have 2 issues, one in middle-end, which generates undefined VIEW_CONVERT_EXPR and one in back-end, which fails to zero-extend symbol address. -- H.J.
Re: PATCH RFA: Build stages 2 and 3 with C++
Jakub Jelinek writes: > On Thu, Jul 21, 2011 at 08:51:46AM -0700, Ian Lance Taylor wrote: >> Basile Starynkevitch writes: >> >> > I have a similar issue in the MELT branch, and I am passing to >> > -frandom-seed the md5sum >> > of relevant source files. With such a trick, the seed is reproducible from >> > one build to >> > the next one (of the exact same source tree), and does provide much more >> > randomness than >> > just using 0 all the time. >> >> In practice I think it is fine to just pass the source file name to >> -frandom-seed. That's what the patch I sent out does. The source file >> name should be unique within a given program. > > Isn't the filename already encoded in what get_file_function_name returns? > It is __, so IMHO > -frandom-seed=$@ brings almost no advantages at all over -frandom-seed=0. > Except perhaps for the characters from the filename that are > wiped into _ by clean_symbol_name. That's a fair point, but I guess I still think using the file name with -frandom-seed is going to be more future-proof against other users of random numbers. Ian
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 11:02 AM, Richard Henderson wrote: > On 07/21/2011 10:39 AM, Uros Bizjak wrote: >> IMO, it is OK to disable 64bit relocations, and that compiler is at >> fault here. Consider that something gets written to the d field (see >> example of PR49798). Reading a pointer from *m fileld in DImode, we >> will get non-zero bits in high 32bits of a pointer. We have to access >> the pointer in SImode. > > IMO this is only tangentially related to the compiler at all. > I think disabling 64bit relocations is unnecessarily awkward > for assembly programmers. > > Consider when one wants to build jump tables. You either have to > have a register available for zero-extension, or do the .word x, 0 > thing. Which I think is being silly and arbitrary; the assembler > damned well knows what I want when I write .quad x. > It will make it harder to identify issues where you do want to array of pointers when porting x86-64 assembly codes to x32. -- H.J.
[google] fix global vars incorrectly marked as read-only in LIPO mode (issue4798045)
http://codereview.appspot.com/4798045/diff/1/ipa.c
File ipa.c (right):
http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
ipa.c:1034: {
Has varpool node linking happened at this point? If not, the new code
here is not excersised.
http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1041
ipa.c:1041: vnode->externally_visible = false;
Better to add a simple loop after varpool_node_linking to merge the
attribute in l-ipo.c assuming the linking happens after local visibility
pass.
http://codereview.appspot.com/4798045/
[PATCH, pre-approved] Fix operand scan problems for PR49749
This patch fixes part of PR tree-optimization/49749. The operand scans
in tree-ssa-reassoc.c:get_rank() can be prematurely halted by two
erroneous conditions, which this patch removes. Patch pre-approved by
IRC communication with Richard Guenther, 7/21/11.
The wider issue of biasing reassociation in favor of loop-carried
dependencies is still pending.
Bootstrapped and regression-tested on powerpc64-linux. I'll commit it
shortly.
2011-07-21 Bill Schmidt
PR tree-optimization/49749
* tree-ssa-reassoc.c (get_rank): Fix operand scan conditions and
remove no-longer-used maxrank variable.
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 176569)
+++ gcc/tree-ssa-reassoc.c (working copy)
@@ -235,7 +235,7 @@ get_rank (tree e)
if (TREE_CODE (e) == SSA_NAME)
{
gimple stmt;
- long rank, maxrank;
+ long rank;
int i, n;
if (TREE_CODE (SSA_NAME_VAR (e)) == PARM_DECL
@@ -258,7 +258,6 @@ get_rank (tree e)
/* Otherwise, find the maximum rank for the operands, or the bb
rank, whichever is less. */
rank = 0;
- maxrank = bb_rank[gimple_bb(stmt)->index];
if (gimple_assign_single_p (stmt))
{
tree rhs = gimple_assign_rhs1 (stmt);
@@ -267,15 +266,15 @@ get_rank (tree e)
rank = MAX (rank, get_rank (rhs));
else
{
- for (i = 0;
- i < n && TREE_OPERAND (rhs, i) && rank != maxrank; i++)
- rank = MAX(rank, get_rank (TREE_OPERAND (rhs, i)));
+ for (i = 0; i < n; i++)
+ if (TREE_OPERAND (rhs, i))
+ rank = MAX(rank, get_rank (TREE_OPERAND (rhs, i)));
}
}
else
{
n = gimple_num_ops (stmt);
- for (i = 1; i < n && rank != maxrank; i++)
+ for (i = 1; i < n; i++)
{
gcc_assert (gimple_op (stmt, i));
rank = MAX(rank, get_rank (gimple_op (stmt, i)));
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On 07/21/2011 10:39 AM, Uros Bizjak wrote: > IMO, it is OK to disable 64bit relocations, and that compiler is at > fault here. Consider that something gets written to the d field (see > example of PR49798). Reading a pointer from *m fileld in DImode, we > will get non-zero bits in high 32bits of a pointer. We have to access > the pointer in SImode. IMO this is only tangentially related to the compiler at all. I think disabling 64bit relocations is unnecessarily awkward for assembly programmers. Consider when one wants to build jump tables. You either have to have a register available for zero-extension, or do the .word x, 0 thing. Which I think is being silly and arbitrary; the assembler damned well knows what I want when I write .quad x. r~
Re: [RFC] More compact (100x) -g3 .debug_gnu_macro (take 4)
On Thu, Jul 21, 2011 at 10:10:39AM -0700, Richard Henderson wrote: > On 07/21/2011 04:22 AM, Jakub Jelinek wrote: > > Currently, the patch emits 3 byte section headers at the start of > > the .debug_gnu_macro chunks referenced from .debug_info (through > > DW_AT_GNU_macros), containing version number (2 byte, 4 ATM) and > > 1 byte section offset, but the DW_GNU_MACRO_transparent_include > > referenced sequences don't have it. > > The .debug_gnu_macro section isn't completely usable without the referencing > > CUs anyway, so IMHO we could still get away completely without > > any section header, but if we need it, the question is if > > the offset size there is useful and if the section header shouldn't > > go before the transparent_include chains as well (only with that > > e.g. readelf -wm would be able to dump .debug_gnu_macro without > > reading .debug_info and tracking offsets to it). > > I've been wondering if the header shouldn't contain the opcode > definitions, similar to .debug_line, and drop your _define_opcode. > It does mean that you couldn't re-define opcodes within any one > sequence, but does that actually seem useful? I've talked to Tom about it last night. The advantage of not having it in the header is saving 1 byte for the case when no extension opcodes need to be defined, and perhaps if we changed the wording that the defined opcodes end at 0 termination to allow it to last, then we could with many opcodes share the opcode arguments descriptions. So we could have DW_GNU_MACRO_transparent_include .Ldebug_macro17 after the header of many sections and then .Ldebug_macro17: DW_GNU_MACRO_define_opcode DW_GNU_MACRO_lo_user+0 1 DW_FORM_udata DW_GNU_MACRO_define_opcode DW_GNU_MACRO_lo_user+1 2 DW_FORM_udata DW_FORM_sdata DW_GNU_MACRO_define_opcode DW_GNU_MACRO_lo_user+2 1 DW_FORM_strp 0 If the opcode definitions were in the header, then they could be either after a uleb128 that would say how many of the definitions there are, followed by what I've been proposing as DW_GNU_MACRO_define_opcode arguments alone (i.e. opcode number and DW_FORM_block array of forms for arguments). Or it could be instead without the uleb128, but zero terminated. > Defining the opcodes in the header makes it clear that there > should be a header for the include sequences, and that makes it > clear that the defined opcodes are local to a given sequence, > without having to have awkward wording as for _define_opcode. > > I do like mjw's idea of using the version number to distinguish > our implementation and one with the dwarf5 stamp of approval. > This suggests going ahead with .debug_macro as the section name. If we knew that DWARF5 would either start the .debug_macro sections with a header starting with the 2 byte version and the version there would be 5 (I think if it does start with a 2 byte version number, it would use 5), then perhaps it would be safe to use .debug_macro section with version 4 (or 1?). Shall we use DW_GNU_MACRO_* names, or DW_MACRO_GNU_* names? > > In x86_64 cc1plus for which I've been posting figures, I see > > 395 CUs referencing .debug_gnu_macro and at most 511 different > > .debug_gnu_macro chains with unique md5sums. So, the cost of the > > 3 byte headers is for cc1plus just in CU referenced chunks > > 1185 bytes, 3 byte headers in all .debug_gnu_macro chunks > > 2718 bytes. > > Putting the opcode definitions into the header would increase > the overhead more, somewhere between 12 and 20 bytes per chain. > Which is, I think still manageable. The question is, do we want to always describe all the opcodes we use, or can we assume the ops described in the corresponding standard as given? Say if DWARF 5 (and our version 4) defines 8 standard opcodes, and DWARF 6 adds another 3, and we want to use the new opcodes, with -gdwarf-5 -gno-strict-dwarf we'd define the opcode arguments for the 3 DWARF 6 ops (or a subset of them that we actually use), while for -gdwarf-6 we wouldn't define any and just put version 6 into the section. > > Also, should the decision whether to emit .debug_gnu_macro or .debug_macinfo > > depend on -gdwarf-strict, or should we have a separate switch for that? > > I'm fine with strict. Anyone else have an opinion? Ok. Jakub
Re: [PATCH] C++0x, warnings for uses of override/final in non-c++0x mode, add __final for non-c++0x mode
At Thu, 21 Jul 2011 18:34:35 +0300,
Ville Voutilainen wrote:
> On 21 July 2011 18:23, Ville Voutilainen wrote:
> > +struct F : E {}; { dg-error "cannot derive from ‘final’ base" }
> Urgh, botched. Will send a new patch after I finish the test run. Note
This one seems to work...
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index c590585..fb17178 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -393,7 +393,9 @@ typedef enum cpp0x_warn_str
/* defaulted and deleted functions */
CPP0X_DEFAULTED_DELETED,
/* inline namespaces */
- CPP0X_INLINE_NAMESPACES
+ CPP0X_INLINE_NAMESPACES,
+ /* override controls, override/final */
+ CPP0X_OVERRIDE_CONTROLS
} cpp0x_warn_str;
/* The various kinds of operation used by composite_pointer_type. */
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 2d7c0f1..d435bbe 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -3227,6 +3227,11 @@ maybe_warn_cpp0x (cpp0x_warn_str str)
"inline namespaces "
"only available with -std=c++0x or -std=gnu++0x");
break;
+ case CPP0X_OVERRIDE_CONTROLS:
+ pedwarn (input_location, 0,
+"override controls (override/final) "
+"only available with -std=c++0x or -std=gnu++0x");
+break;
default:
gcc_unreachable();
}
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 2851801..dc54dc2 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15596,9 +15596,19 @@ cp_parser_virt_specifier_seq_opt (cp_parser* parser)
if (token->type != CPP_NAME)
break;
if (!strcmp (IDENTIFIER_POINTER(token->u.value), "override"))
- virt_specifier = VIRT_SPEC_OVERRIDE;
+{
+ maybe_warn_cpp0x (CPP0X_OVERRIDE_CONTROLS);
+ virt_specifier = VIRT_SPEC_OVERRIDE;
+}
else if (!strcmp (IDENTIFIER_POINTER(token->u.value), "final"))
- virt_specifier = VIRT_SPEC_FINAL;
+{
+ maybe_warn_cpp0x (CPP0X_OVERRIDE_CONTROLS);
+ virt_specifier = VIRT_SPEC_FINAL;
+}
+ else if (!strcmp (IDENTIFIER_POINTER(token->u.value), "__final"))
+{
+ virt_specifier = VIRT_SPEC_FINAL;
+}
else
break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/override1.C
b/gcc/testsuite/g++.dg/cpp0x/override1.C
index 83e0479..ba580b5 100644
--- a/gcc/testsuite/g++.dg/cpp0x/override1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/override1.C
@@ -1,4 +1,5 @@
// { dg-do compile }
+// { dg-options "--std=c++0x" }
struct B
{
virtual void f() final {}
diff --git a/gcc/testsuite/g++.dg/cpp0x/override3.C
b/gcc/testsuite/g++.dg/cpp0x/override3.C
new file mode 100644
index 000..2d22cbf
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/override3.C
@@ -0,0 +1,24 @@
+// { dg-do compile }
+// { dg-options "--std=c++98" }
+
+struct B final {}; // { dg-warning "override controls" }
+
+struct D : B {}; // { dg-error "cannot derive from 'final' base" }
+
+struct E __final {};
+
+struct F : E {}; // { dg-error "cannot derive from 'final' base" }
+
+struct G
+{
+ virtual void f();
+};
+
+struct H : G
+{
+ void f() override; // { dg-warning "override controls" }
+};
+
+int main()
+{
+}
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 6:42 PM, Richard Henderson wrote: > On 07/21/2011 09:28 AM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson wrote: >>> On 07/21/2011 09:20 AM, H.J. Lu wrote: ".quad symbol" isn't really valid for 32bit. >>> >>> Why not? We certainly know what value to put there. >>> >> >> x32 doesn't support 64bit relocation, like R_X86_64_64. > > This being a self-fulfilling assertion, because you decided > to disable that relocation. It *could* be supported. Easily. IMO, it is OK to disable 64bit relocations, and that compiler is at fault here. Consider that something gets written to the d field (see example of PR49798). Reading a pointer from *m fileld in DImode, we will get non-zero bits in high 32bits of a pointer. We have to access the pointer in SImode. Uros.
Re: [RFC ARM ivopts] : Check valid auto-inc addressing modes while looking at ivopts candidates
On 21/07/11 18:13, Steven Bosscher wrote: On Thu, Jul 21, 2011 at 2:47 PM, wrote: * tree-ssa-loop-ivopts.c (rtl.h): Include. Please don't do this. The goal should be that GIMPLE is independent of RTL, and almost no tree-* files include rtl.h for this reason. Including rtl.h in tree-ssa-loop-ivopts.c is a very big step in the wrong direction. Maybe add a function in tree-ssa-address.c for this, or use a target hook. Thanks for looking at this. The reason I had put this in was to avoid the issue around ivopts not finding the declaration of extern bool arm_autoinc_modes_ok_p (enum machine_mode, RTX_CODE); It just seemed natural to reuse RTX_CODE to distinguish the various pre/post inc/dec cases rather than write 8 macros that handled it in ever so similar ways. There's probably no reason why I can't use a private interface for that or create something in tree-ssa-address.c to take care of this. cheers Ramana
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 9:42 AM, Richard Henderson wrote: > On 07/21/2011 09:28 AM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson wrote: >>> On 07/21/2011 09:20 AM, H.J. Lu wrote: ".quad symbol" isn't really valid for 32bit. >>> >>> Why not? We certainly know what value to put there. >>> >> >> x32 doesn't support 64bit relocation, like R_X86_64_64. > > This being a self-fulfilling assertion, because you decided > to disable that relocation. It *could* be supported. Easily. > There is no reason to have it since x32 is a 32bit environment. I don't want/need this relocation in x32. -- H.J.
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On 07/21/2011 09:28 AM, H.J. Lu wrote: > On Thu, Jul 21, 2011 at 9:23 AM, Richard Henderson wrote: >> On 07/21/2011 09:20 AM, H.J. Lu wrote: >>> ".quad symbol" isn't really valid for 32bit. >> >> Why not? We certainly know what value to put there. >> > > x32 doesn't support 64bit relocation, like R_X86_64_64. This being a self-fulfilling assertion, because you decided to disable that relocation. It *could* be supported. Easily. r~
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 7:24 PM, H.J. Lu wrote: > On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak wrote: >> On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu wrote: >> > ".quad symbol" isn't really valid for 32bit. Why not? We certainly know what value to put there. >>> >>> x32 doesn't support 64bit relocation, like R_X86_64_64. >>> In many causes, generate >>> >>> .long symbol >>> .long 0 >>> >>> for ".quad symbol" is wrong. Please see: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >>> >>> for some examples. >> >> Please also see: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 >> >> on why I think this is middle-end/tree-optimization issue. >> > > I still think it is a backend issue. /* Represents viewing something of one type as being of a second type. This corresponds to an "Unchecked Conversion" in Ada and roughly to the idiom *(type2 *)&X in C. The only operand is the value to be viewed as being of another type. **It is undefined if the type of the input and of the expression have different sizes.** ... DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) We have: : D.2709_8 = VIEW_CONVERT_EXPR(&); D.2702_1 = u.d; D.2704_3 = D.2702_1 == D.2709_8; D.2701_4 = (int) D.2704_3; return D.2701_4; Where sizeof (double) = 64 sizeof (ptr_type) = 32. Uros.
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 10:04 AM, Uros Bizjak wrote: > On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu wrote: > ".quad symbol" isn't really valid for 32bit. >>> >>> Why not? We certainly know what value to put there. >>> >> >> x32 doesn't support 64bit relocation, like R_X86_64_64. >> In many causes, generate >> >> .long symbol >> .long 0 >> >> for ".quad symbol" is wrong. Please see: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 >> >> for some examples. > > Please also see: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 > > on why I think this is middle-end/tree-optimization issue. > I still think it is a backend issue. -- H.J.
Re: [Patches, Fortran] ALLOCATE & CAF library.
On 07/21/2011 06:46 PM, Daniel Carrera wrote: Ok. Updated patch and updated ChangeLog attached. Compiles fine and I'm about to start running the test suite again. Doesn't compile here: gcc/fortran/trans.c: In function 'tree_node* gfc_allocate_using_lib(stmtblock_t*, tree, tree, tree, tree)': gcc/fortran/trans.c:656:8: error: unused variable 'status_type' [-Werror=unused-variable] Please fix before committal. Thanks, Tobias
Re: PR 45819 - possible fix?
> The patch is not correct, it papers over a problem elsewhere (maybe
> in forwprop).
>
> I can't btw reproduce the issue on either the 4.5 or the 4.6 branch or trunk
> with the testcase from the PR. I always get
>
> v_2 ={v} st_1(D)->ptr;
>
> in the .optimized tree dump which correctly states this is a volatile load.
x86 isn't strict_align so the original problem doesn't happen. With
armv7hl-redhat-linux-gnueabi it happens with this test case (from the
PR):
struct ehci_regs {
char x;
unsigned int port_status[0];
} __attribute__ ((packed));
//} __attribute__ ((packed,aligned(__alignof__(int;
struct ehci_hcd{
struct ehci_regs *regs;
};
int ehci_hub_control (
struct ehci_hcd *ehci,
int wIndex
) {
unsigned int *status_reg = &ehci->regs->port_status[wIndex];
return *(volatile unsigned int *)status_reg;
}
Here's the 45819.c.023t.ccp1 dump:
;; Function ehci_hub_control (ehci_hub_control)
ehci_hub_control (struct ehci_hcd * ehci, int wIndex)
{
unsigned int * status_reg;
volatile unsigned int D.2015;
int D.2014;
unsigned int D.2013;
unsigned int wIndex.0;
unsigned int[0:] * D.2011;
struct ehci_regs * D.2010;
:
D.2010_2 = ehci_1(D)->regs;
D.2011_3 = &D.2010_2->port_status;
wIndex.0_5 = (unsigned int) wIndex_4(D);
D.2013_6 = wIndex.0_5 * 4;
status_reg_7 = D.2011_3 + D.2013_6;
D.2015_8 ={v} MEM[(volatile unsigned int *)status_reg_7];
D.2014_9 = (int) D.2015_8;
return D.2014_9;
}
The problem happens when status_reg_7 is replaced in the D.2015_9
assignment. I've attached the relevent before/after lhs/rhs trees.
By replacing the address with the previously computed value, gcc seems
to end up with alignment info that the user was trying to get rid of,
so gcc produces four byte-loads instead of a single word-load.
024t.forwprop1 shows this:
D.2015_8 = MEM[(volatile unsigned int *)D.2010_2].port_status[wIndex.0_5]{lb:
0 sz: 4};
It looks like the "volatile unsigned int *" semantics now happen
*before* the structure reference semantics, instead of after, and the
alignment of the structure field takes precedence over the volatile,
instead of the other way around. At least, that's what it looks like
to me ;-)
unit size
align 32 symtab 0 alias set -1 canonical type 0x7f87354bc540
precision 32 min max
pointer_to_this >
sizes-gimplified public unsigned SI size unit size
align 32 symtab 0 alias set -1 canonical type 0x7f87354cfb28>
var def_stmt status_reg_7 =
&D.2010_2->port_status[wIndex.0_5]{lb: 0 sz: 4};
version 7>
unit size
align 32 symtab 0 alias set -1 canonical type 0x7f87354bc540
precision 32 min max
pointer_to_this >
sizes-gimplified public unsigned SI size unit size
align 32 symtab 0 alias set -1 canonical type 0x7f87354cfb28>
arg 0
arg 0
arg 0
arg 0
var def_stmt D.2010_2 =
ehci_1(D)->regs;
version 2>
arg 1
45819.c:15:40> arg 1
45819.c:15:40>
arg 1
var def_stmt wIndex.0_5 =
(unsigned int) wIndex_4(D);
version 5>
arg 2 >>
unit size
align 32 symtab 0 alias set -1 canonical type 0x7f8735585690 precision
32 min max
pointer_to_this >
var def_stmt D.2015_8 ={v} MEM[(volatile
unsigned int *)status_reg_7];
version 8>
unit size
align 32 symtab 0 alias set -1 canonical type 0x7f8735585690 precision
32 min max
pointer_to_this >
side-effects volatile
arg 0
sizes-gimplified public unsigned SI size unit size
align 32 symtab 0 alias set -1 canonical type 0x7f87354cfb28>
var def_stmt status_reg_7 =
&D.2010_2->port_status[wIndex.0_5]{lb: 0 sz: 4};
version 7>
arg 1
constant 0>
45819.c:16:9>
Re: [PATCH] C++0x, warnings for uses of override/final in non-c++0x mode, add __final for non-c++0x mode
On 07/21/2011 11:34 AM, Ville Voutilainen wrote: Urgh, botched. Will send a new patch after I finish the test run. Note to self: it's not a good idea to run check-c++ target with make -j3. One might think tests pass when they don't.. :) Heh. I run check-c++ with -j N, but tee the make output to a file and do a grep ^FAIL: at the end. Jason
Re: [RFC ARM ivopts] : Check valid auto-inc addressing modes while looking at ivopts candidates
On Thu, Jul 21, 2011 at 2:47 PM, wrote: > * tree-ssa-loop-ivopts.c (rtl.h): Include. Please don't do this. The goal should be that GIMPLE is independent of RTL, and almost no tree-* files include rtl.h for this reason. Including rtl.h in tree-ssa-loop-ivopts.c is a very big step in the wrong direction. Maybe add a function in tree-ssa-address.c for this, or use a target hook. Ciao! Steven
Re: [RFC] More compact (100x) -g3 .debug_gnu_macro (take 4)
On 07/21/2011 04:22 AM, Jakub Jelinek wrote: > Currently, the patch emits 3 byte section headers at the start of > the .debug_gnu_macro chunks referenced from .debug_info (through > DW_AT_GNU_macros), containing version number (2 byte, 4 ATM) and > 1 byte section offset, but the DW_GNU_MACRO_transparent_include > referenced sequences don't have it. > The .debug_gnu_macro section isn't completely usable without the referencing > CUs anyway, so IMHO we could still get away completely without > any section header, but if we need it, the question is if > the offset size there is useful and if the section header shouldn't > go before the transparent_include chains as well (only with that > e.g. readelf -wm would be able to dump .debug_gnu_macro without > reading .debug_info and tracking offsets to it). I've been wondering if the header shouldn't contain the opcode definitions, similar to .debug_line, and drop your _define_opcode. It does mean that you couldn't re-define opcodes within any one sequence, but does that actually seem useful? Defining the opcodes in the header makes it clear that there should be a header for the include sequences, and that makes it clear that the defined opcodes are local to a given sequence, without having to have awkward wording as for _define_opcode. I do like mjw's idea of using the version number to distinguish our implementation and one with the dwarf5 stamp of approval. This suggests going ahead with .debug_macro as the section name. > In x86_64 cc1plus for which I've been posting figures, I see > 395 CUs referencing .debug_gnu_macro and at most 511 different > .debug_gnu_macro chains with unique md5sums. So, the cost of the > 3 byte headers is for cc1plus just in CU referenced chunks > 1185 bytes, 3 byte headers in all .debug_gnu_macro chunks > 2718 bytes. Putting the opcode definitions into the header would increase the overhead more, somewhere between 12 and 20 bytes per chain. Which is, I think still manageable. > Also, should the decision whether to emit .debug_gnu_macro or .debug_macinfo > depend on -gdwarf-strict, or should we have a separate switch for that? I'm fine with strict. Anyone else have an opinion? r~
Re: [build, ada] Allow Solaris bootstrap with C++ (PR bootstrap/49794)
Rainer Orth writes: > 2011-07-20 Rainer Orth > Ralf Wildenhues > > gcc: > PR bootstrap/49794 > * configure.ac: Test AM_ICONV with CXX. > * configure: Regenerate. > * config/sol2-c.c (solaris_format_types): Use EXPORTED_CONST. > > gcc/ada: > PR bootstrap/49794 > * init.c [sun && __SVR4 && !__vxworks] (__gnat_install_handler): > Assign to act.sa_sigaction. > * tracebak.c [USE_GENERIC_UNWINDER] (__gnat_backtrace): Cast > current->return_address to char * before arithmetic. > > libcpp: > PR bootstrap/49794 > * configure.ac: Test AM_ICONV with CXX. > * configure: Regenerate. > * system.h (HAVE_DESIGNATED_INITIALIZERS): Never define for C++. This is OK. Thanks. Ian
Re: PATCH [9/n] X32: PR target/49798: Zero-extend symbol address to 64bit if needed
On Thu, Jul 21, 2011 at 6:28 PM, H.J. Lu wrote: >>> ".quad symbol" isn't really valid for 32bit. >> >> Why not? We certainly know what value to put there. >> > > x32 doesn't support 64bit relocation, like R_X86_64_64. > In many causes, generate > > .long symbol > .long 0 > > for ".quad symbol" is wrong. Please see: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446 > > for some examples. Please also see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49798#c12 on why I think this is middle-end/tree-optimization issue. Uros.
Re: Don't use LANGUAGE_C in CLooG (PR bootstrap/49797)
On 07/21/2011 06:09 PM, Sebastian Pop wrote: Hi, On Thu, Jul 21, 2011 at 07:37, Rainer Orth wrote: As described in the PR, the use of LANGUAGE_C in CLooG breaks C++ bootstrap on IRIX 6.5. Both MIPS and Alpha C compilers predefine LANGUAGE_C themselves, which clashes with the CLooG macro in . In a bootstrap with C++, LANGUAGE_C of course isn't defined, so the symbol is missing. As a hack, I had renamed that to CLOOG_LANGUAGE_C in the installed CLooG headers, not noticing the use of LANGUAGE_C in graphite-clast-to-gimple.c. Since this macro name is obviously far too generic, I propose renaming it to CLOOG_LANGUAGE_C upstream. I forwarded this question to the cloog-dev mailing list and they like this change. The current patch accounts for such a change in gcc and allows the mips-sgi-irix6.5 bootstrap to continue. What's the best way forward from here? Could one of you propose that upstream? Is the patch below ok for mainline? Your patch is ok for GCC, please commit. You can post a patch for CLooG on cloog-developm...@googlegroups.com Don't forget to update the documentation of CLooG as well. I am about to post a patch to CLooG. I will take care of pushing it upstream. Tobi
Re: [Patches, Fortran] ALLOCATE & CAF library.
Ok. Updated patch and updated ChangeLog attached. Compiles fine and I'm
about to start running the test suite again.
Cheers,
Daniel.
On 07/21/2011 06:37 PM, Tobias Burnus wrote:
On 07/21/2011 06:01 PM, Daniel Carrera wrote:
I was using Mercurial wrong. I've been experimenting with using
Mercurial to work with GCC and was doing the diff wrong. The attached
file should be correct (fingers crossed).
Looks better :-)
The patch is OK after regtesting and fixing the following nits.
Changelog from http://gcc.gnu.org/ml/fortran/2011-07/txt8.txt:
* trans.c (gfc_allocate_with_status): Split into two functions
gfc_allocate_using_malloc ad gfc_allocate_usig_lib.
Typo: "and" and "gfc_allocate_using_lib" (usig->using).
@@ -4881,2 +4889,21 @@ gfc_trans_allocate (gfc_code * code)
+ /* Error checking -- Note: ERRMS only makes sense with STAT. */
Typo: ERRMSG.
@@ -676,2 +638,72 @@ gfc_allocate_with_status (stmtblock_t *
+/* Allocate memory, using an optional status argument.
+
+ This function follows the following pseudo-code:
+
+ void *
+ allocate (size_t size, integer_type stat)
+ {
+ void *newmem;
+
+ if (stat requested)
+ stat = 0;
No need to set "stat = 0". caf_registering always sets stat (if present).
+ newmem = _caf_register ( size, regtype, NULL,&stat, NULL, NULL);
+ if (newmem == NULL)
+ {
+ if (!stat requested)
+ runtime_error ("Allocation would exceed memory limit");
+ }
Remove the if block - it's not in the actual code and the library
function already aborts.
+ return newmem;
+ } */
+tree
+gfc_allocate_using_lib (stmtblock_t * block, tree size, tree status,
+ tree errmsg, tree errlen)
+{
+ tree res, pstat;
+ tree status_type = status ? TREE_TYPE (status) : NULL_TREE;
+
+ /* Evaluate size only once, and make sure it has the right type. */
+ size = gfc_evaluate_now (size, block);
+ if (TREE_TYPE (size) != TREE_TYPE (size_type_node))
+ size = fold_convert (size_type_node, size);
+
+ /* Create a variable to hold the result. */
+ res = gfc_create_var (prvoid_type_node, NULL);
+
+ /* Set the optional status variable to zero. */
+ if (status != NULL_TREE)
+ gfc_add_expr_to_block (block,
+ fold_build2_loc (input_location, MODIFY_EXPR, status_type,
+ status, build_int_cst (status_type, 0)));
As written above - just for the actual code.
Tobias
--
I'm not overweight, I'm undertall.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 176528)
+++ gcc/fortran/trans-array.c (working copy)
@@ -4384,3 +4384,4 @@ gfc_array_init_size (tree descriptor, in
bool
-gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree pstat)
+gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg,
+ tree errlen)
{
@@ -4479,18 +4480,11 @@ gfc_array_allocate (gfc_se * se, gfc_exp
- if (pstat != NULL_TREE && !integer_zerop (pstat))
-{
- /* Set the status variable if it's present. */
+ if (status != NULL_TREE)
+{
+ tree status_type = TREE_TYPE (status);
stmtblock_t set_status_block;
- tree status_type = pstat ? TREE_TYPE (TREE_TYPE (pstat)) : NULL_TREE;
gfc_start_block (&set_status_block);
- gfc_add_modify (&set_status_block,
- fold_build1_loc (input_location, INDIRECT_REF,
- status_type, pstat),
- build_int_cst (status_type, LIBERROR_ALLOCATION));
-
- tmp = fold_build2_loc (input_location, EQ_EXPR, boolean_type_node,
- pstat, build_int_cst (TREE_TYPE (pstat), 0));
- error = fold_build3_loc (input_location, COND_EXPR, void_type_node, tmp,
- error, gfc_finish_block (&set_status_block));
+ gfc_add_modify (&set_status_block, status,
+ build_int_cst (status_type, LIBERROR_ALLOCATION));
+ error = gfc_finish_block (&set_status_block);
}
@@ -4503,10 +4497,11 @@ gfc_array_allocate (gfc_se * se, gfc_exp
- /* The allocate_array variants take the old pointer as first argument. */
+ /* The allocatable variant takes the old pointer as first argument. */
if (allocatable)
-tmp = gfc_allocate_allocatable_with_status (&elseblock,
- pointer, size, pstat, expr);
+tmp = gfc_allocate_allocatable (&elseblock, pointer, size,
+status, errmsg, errlen, expr);
else
-tmp = gfc_allocate_with_status (&elseblock, size, pstat, false);
- tmp = fold_build2_loc (input_location, MODIFY_EXPR, void_type_node, pointer,
- tmp);
+tmp = gfc_allocate_using_malloc (&elseblock, size, status);
+
+ tmp = fold_build2_loc (input_location, MODIFY_EXPR, void_type_node,
+ pointer, tmp);
Index: gcc/fortran/trans-array.h
===
--- gcc/fortran/trans-array.h (revision 176528)
+++ gcc/fortran/trans-array.h (working copy)
@@ -26,3 +26,3 @@ tree gfc_array_deallocate (tree, tree, g
se, which should contain an expression for the array descriptor. */
-bool gfc_array_allocate (gfc_se *, gfc_expr *, tree);
+bool gfc_arr
Re: [Patches, Fortran] ALLOCATE & CAF library.
On 07/21/2011 06:01 PM, Daniel Carrera wrote:
I was using Mercurial wrong. I've been experimenting with using
Mercurial to work with GCC and was doing the diff wrong. The attached
file should be correct (fingers crossed).
Looks better :-)
The patch is OK after regtesting and fixing the following nits.
Changelog from http://gcc.gnu.org/ml/fortran/2011-07/txt8.txt:
* trans.c (gfc_allocate_with_status): Split into two functions
gfc_allocate_using_malloc ad gfc_allocate_usig_lib.
Typo: "and" and "gfc_allocate_using_lib" (usig->using).
@@ -4881,2 +4889,21 @@ gfc_trans_allocate (gfc_code * code)
+ /* Error checking -- Note: ERRMS only makes sense with STAT. */
Typo: ERRMSG.
@@ -676,2 +638,72 @@ gfc_allocate_with_status (stmtblock_t *
+/* Allocate memory, using an optional status argument.
+
+ This function follows the following pseudo-code:
+
+void *
+allocate (size_t size, integer_type stat)
+{
+ void *newmem;
+
+ if (stat requested)
+ stat = 0;
No need to set "stat = 0". caf_registering always sets stat (if present).
+ newmem = _caf_register ( size, regtype, NULL,&stat, NULL, NULL);
+ if (newmem == NULL)
+ {
+if (!stat requested)
+ runtime_error ("Allocation would exceed memory limit");
+ }
Remove the if block - it's not in the actual code and the library
function already aborts.
+ return newmem;
+} */
+tree
+gfc_allocate_using_lib (stmtblock_t * block, tree size, tree status,
+ tree errmsg, tree errlen)
+{
+ tree res, pstat;
+ tree status_type = status ? TREE_TYPE (status) : NULL_TREE;
+
+ /* Evaluate size only once, and make sure it has the right type. */
+ size = gfc_evaluate_now (size, block);
+ if (TREE_TYPE (size) != TREE_TYPE (size_type_node))
+size = fold_convert (size_type_node, size);
+
+ /* Create a variable to hold the result. */
+ res = gfc_create_var (prvoid_type_node, NULL);
+
+ /* Set the optional status variable to zero. */
+ if (status != NULL_TREE)
+ gfc_add_expr_to_block (block,
+fold_build2_loc (input_location, MODIFY_EXPR, status_type,
+ status, build_int_cst (status_type, 0)));
As written above - just for the actual code.
Tobias
