RE: MPC 0.7 officially released, please test and report your results!
> -Original Message- > From: Kaveh R. GHAZI [mailto:gh...@caip.rutgers.edu] > Sent: Friday, September 11, 2009 12:07 AM > To: gcc@gcc.gnu.org > Subject: MPC 0.7 officially released, please test and report > your results! > > Hi, > > mpc-0.7 now has been released, > Please download, compile and run "make check" for this > release and post > your results as well your target triplet and the versions of your > compiler, gmp and mpfr. All platform results are welcome, but I am > especially interested in GCC's primary and secondary platform list. mpc 0.7 i686-pc-mingw32 gcc 3.4.5 gmp 4.3.1 mpfr 2.4.1 === All 45 tests passed === Eric Weddington
Re: MPC 0.7 officially released, please test and report your results!
Kaveh R. GHAZI wrote: > Hi, > > mpc-0.7 now has been released, you can get the package here: > http://www.multiprecision.org/index.php?prog=mpc&page=download Dude! You have a 2.2 megabyte JPG on your front page! Seriously, WTF?! It took like five seconds to slowly load by scanlines, it was like being back in 1995! (Also, it's embedded from wikimedia commons. What happens if the original uploader decides to replace it with a copy of goatse one day?) Err, anyway, to the point: > $ ./config.status --version > mpc config.status 0.7 > configured by ./configure, generated by GNU Autoconf 2.61, > with options "'-v' '--prefix=/usr' '--disable-static' '--enable-shared'" > === > All 45 tests passed > === > $ ./config.guess > i686-pc-cygwin > $ cygcheck -cd cygwin gcc4 mpfr gmp libmpfr1 libgmp3 > Cygwin Package Information > Package Version > cygwin 1.7.0-60 > gcc4 4.3.2-2 > gmp 4.3.1-3 > libgmp3 4.3.1-3 > libmpfr1 2.4.1-4 > mpfr 2.4.1-4 No sign of the previous compile problems, so that confirms the fix was integrated correctly. Thanks. cheers, DaveK
Re: MPC 0.7 officially released, please test and report your results!
On Thu, Sep 10, 2009 at 6:06 PM, Kaveh R. GHAZI wrote: > Please download, compile and run "make check" for this release and post > your results as well your target triplet and the versions of your > compiler, gmp and mpfr. All platform results are welcome, but I am > especially interested in GCC's primary and secondary platform list. powerpc-ibm-aix5.3.0.0 gcc-4.3.4 gmp-4.2.4 mpfr-2.4.0 mpc-0.7 === All 45 tests passed ===
Restrict qualifier doesn't work in TRUNK.
Hello,
I notice the restrict qualifier doesn't work properly in trunk any more.
In the following example, the memory accesses of a, b, c don't have different
alias set attached any more. Instead, the generic alias set of 2 is used
for all accesses.
I remember alias analysis part had some big changes since 4.5 branched out.
Is it still in unstable phase, or is there some new hooks I should use for
my port?
Cheers,
Bingfeng Mei
void foo (int * __restrict__ a, int * __restrict__ b, int * __restrict__ c)
{
int i;
for(i = 0; i < 100; i+=4)
{
a[i] = b[i] * c[i];
a[i+1] = b[i+1] * c[i+1];
a[i+2] = b[i+2] * c[i+2];
a[i+3] = b[i+3] * c[i+3];
}
}
Before expand:
foo (int * restrict a, int * restrict b, int * restrict c)
{
long unsigned int D.3213;
long unsigned int ivtmp.32;
long unsigned int ivtmp.31;
long unsigned int ivtmp.29;
int D.3168;
int D.3167;
int D.3165;
int D.3160;
int D.3159;
int D.3157;
int D.3152;
int D.3151;
int D.3149;
int D.3143;
int D.3142;
int D.3140;
# BLOCK 2 freq:385
# PRED: ENTRY [100.0%] (fallthru,exec)
ivtmp.29_77 = (long unsigned int) b_9(D);
ivtmp.31_74 = (long unsigned int) c_14(D);
ivtmp.32_83 = (long unsigned int) a_5(D);
D.3213_85 = ivtmp.32_83 + 400;
# SUCC: 3 [100.0%] (fallthru,exec)
# BLOCK 3 freq:9615
# PRED: 3 [96.0%] (true,exec) 2 [100.0%] (fallthru,exec)
# ivtmp.29_79 = PHI
# ivtmp.31_76 = PHI
# ivtmp.32_73 = PHI
D.3140_11 = MEM[index: ivtmp.29_79];
D.3142_16 = MEM[index: ivtmp.31_76];
D.3143_17 = D.3142_16 * D.3140_11;
MEM[index: ivtmp.32_73] = D.3143_17;
D.3149_26 = MEM[index: ivtmp.29_79, offset: 4];
D.3151_31 = MEM[index: ivtmp.31_76, offset: 4];
D.3152_32 = D.3151_31 * D.3149_26;
MEM[index: ivtmp.32_73, offset: 4] = D.3152_32;
D.3157_41 = MEM[index: ivtmp.29_79, offset: 8];
D.3159_46 = MEM[index: ivtmp.31_76, offset: 8];
D.3160_47 = D.3159_46 * D.3157_41;
MEM[index: ivtmp.32_73, offset: 8] = D.3160_47;
D.3165_56 = MEM[index: ivtmp.29_79, offset: 12];
D.3167_61 = MEM[index: ivtmp.31_76, offset: 12];
D.3168_62 = D.3167_61 * D.3165_56;
MEM[index: ivtmp.32_73, offset: 12] = D.3168_62;
ivtmp.29_78 = ivtmp.29_79 + 16;
ivtmp.31_75 = ivtmp.31_76 + 16;
ivtmp.32_82 = ivtmp.32_73 + 16;
if (ivtmp.32_82 != D.3213_85)
goto ;
else
goto ;
# SUCC: 3 [96.0%] (true,exec) 4 [4.0%] (false,exec)
# BLOCK 4 freq:385
# PRED: 3 [4.0%] (false,exec)
return;
# SUCC: EXIT [100.0%]
}
Part of RTL
...
insn 40 39 41 4 sms-6.c:11 (set (reg:SI 157)
(mem:SI (reg:SI 151 [ ivtmp.31 ]) [2 S4 A32])) -1 (nil))
(insn 41 40 42 4 sms-6.c:11 (set (reg:SI 158)
(mem:SI (reg:SI 152 [ ivtmp.29 ]) [2 S4 A32])) -1 (nil))
(insn 42 41 43 4 sms-6.c:11 (set (reg:SI 159)
(mult:SI (reg:SI 157)
(reg:SI 158))) -1 (nil))
(insn 43 42 44 4 sms-6.c:11 (set (mem:SI (reg:SI 150 [ ivtmp.32 ]) [2 S4 A32])
(reg:SI 159)) -1 (nil))
(insn 44 43 45 4 sms-6.c:12 (set (reg:SI 160)
(mem:SI (plus:SI (reg:SI 151 [ ivtmp.31 ])
(const_int 4 [0x4])) [2 S4 A32])) -1 (nil))
(insn 45 44 46 4 sms-6.c:12 (set (reg:SI 161)
(mem:SI (plus:SI (reg:SI 152 [ ivtmp.29 ])
(const_int 4 [0x4])) [2 S4 A32])) -1 (nil))
(insn 46 45 47 4 sms-6.c:12 (set (reg:SI 162)
(mult:SI (reg:SI 160)
(reg:SI 161))) -1 (nil))
(insn 47 46 48 4 sms-6.c:12 (set (mem:SI (plus:SI (reg:SI 150 [ ivtmp.32 ])
(const_int 4 [0x4])) [2 S4 A32])
(reg:SI 162)) -1 (nil))
(insn 48 47 49 4 sms-6.c:13 (set (reg:SI 163)
(mem:SI (plus:SI (reg:SI 151 [ ivtmp.31 ])
(const_int 8 [0x8])) [2 S4 A32])) -1 (nil))
(insn 49 48 50 4 sms-6.c:13 (set (reg:SI 164)
(mem:SI (plus:SI (reg:SI 152 [ ivtmp.29 ])
(const_int 8 [0x8])) [2 S4 A32])) -1 (nil))
...
New Hyip - 15-30% Daily - Paid
New Hyip - 15-30% Daily - Paid
New Hyip - 15-30% Daily - Paid
Re: Restrict qualifier doesn't work in TRUNK.
On Fri, Sep 11, 2009 at 4:11 PM, Bingfeng Mei wrote:
> Hello,
> I notice the restrict qualifier doesn't work properly in trunk any more.
> In the following example, the memory accesses of a, b, c don't have different
> alias set attached any more. Instead, the generic alias set of 2 is used
> for all accesses.
>
> I remember alias analysis part had some big changes since 4.5 branched out.
> Is it still in unstable phase, or is there some new hooks I should use for
> my port?
restrict is no longer encoded in the type-based alias-sets but in
the points-to sets that are reachable from the mems MEM_EXPR.
In case of TARGET_MEM_REFs you are (at the moment) out of luck
though.
Richard.
> Cheers,
> Bingfeng Mei
>
>
> void foo (int * __restrict__ a, int * __restrict__ b, int * __restrict__ c)
> {
> int i;
> for(i = 0; i < 100; i+=4)
> {
> a[i] = b[i] * c[i];
> a[i+1] = b[i+1] * c[i+1];
> a[i+2] = b[i+2] * c[i+2];
> a[i+3] = b[i+3] * c[i+3];
> }
> }
>
> Before expand:
>
> foo (int * restrict a, int * restrict b, int * restrict c)
> {
> long unsigned int D.3213;
> long unsigned int ivtmp.32;
> long unsigned int ivtmp.31;
> long unsigned int ivtmp.29;
> int D.3168;
> int D.3167;
> int D.3165;
> int D.3160;
> int D.3159;
> int D.3157;
> int D.3152;
> int D.3151;
> int D.3149;
> int D.3143;
> int D.3142;
> int D.3140;
>
> # BLOCK 2 freq:385
> # PRED: ENTRY [100.0%] (fallthru,exec)
> ivtmp.29_77 = (long unsigned int) b_9(D);
> ivtmp.31_74 = (long unsigned int) c_14(D);
> ivtmp.32_83 = (long unsigned int) a_5(D);
> D.3213_85 = ivtmp.32_83 + 400;
> # SUCC: 3 [100.0%] (fallthru,exec)
>
> # BLOCK 3 freq:9615
> # PRED: 3 [96.0%] (true,exec) 2 [100.0%] (fallthru,exec)
> # ivtmp.29_79 = PHI
> # ivtmp.31_76 = PHI
> # ivtmp.32_73 = PHI
> D.3140_11 = MEM[index: ivtmp.29_79];
> D.3142_16 = MEM[index: ivtmp.31_76];
> D.3143_17 = D.3142_16 * D.3140_11;
> MEM[index: ivtmp.32_73] = D.3143_17;
> D.3149_26 = MEM[index: ivtmp.29_79, offset: 4];
> D.3151_31 = MEM[index: ivtmp.31_76, offset: 4];
> D.3152_32 = D.3151_31 * D.3149_26;
> MEM[index: ivtmp.32_73, offset: 4] = D.3152_32;
> D.3157_41 = MEM[index: ivtmp.29_79, offset: 8];
> D.3159_46 = MEM[index: ivtmp.31_76, offset: 8];
> D.3160_47 = D.3159_46 * D.3157_41;
> MEM[index: ivtmp.32_73, offset: 8] = D.3160_47;
> D.3165_56 = MEM[index: ivtmp.29_79, offset: 12];
> D.3167_61 = MEM[index: ivtmp.31_76, offset: 12];
> D.3168_62 = D.3167_61 * D.3165_56;
> MEM[index: ivtmp.32_73, offset: 12] = D.3168_62;
> ivtmp.29_78 = ivtmp.29_79 + 16;
> ivtmp.31_75 = ivtmp.31_76 + 16;
> ivtmp.32_82 = ivtmp.32_73 + 16;
> if (ivtmp.32_82 != D.3213_85)
> goto ;
> else
> goto ;
> # SUCC: 3 [96.0%] (true,exec) 4 [4.0%] (false,exec)
>
> # BLOCK 4 freq:385
> # PRED: 3 [4.0%] (false,exec)
> return;
> # SUCC: EXIT [100.0%]
>
> }
>
> Part of RTL
>
> ...
> insn 40 39 41 4 sms-6.c:11 (set (reg:SI 157)
> (mem:SI (reg:SI 151 [ ivtmp.31 ]) [2 S4 A32])) -1 (nil))
>
> (insn 41 40 42 4 sms-6.c:11 (set (reg:SI 158)
> (mem:SI (reg:SI 152 [ ivtmp.29 ]) [2 S4 A32])) -1 (nil))
>
> (insn 42 41 43 4 sms-6.c:11 (set (reg:SI 159)
> (mult:SI (reg:SI 157)
> (reg:SI 158))) -1 (nil))
>
> (insn 43 42 44 4 sms-6.c:11 (set (mem:SI (reg:SI 150 [ ivtmp.32 ]) [2 S4 A32])
> (reg:SI 159)) -1 (nil))
>
> (insn 44 43 45 4 sms-6.c:12 (set (reg:SI 160)
> (mem:SI (plus:SI (reg:SI 151 [ ivtmp.31 ])
> (const_int 4 [0x4])) [2 S4 A32])) -1 (nil))
>
> (insn 45 44 46 4 sms-6.c:12 (set (reg:SI 161)
> (mem:SI (plus:SI (reg:SI 152 [ ivtmp.29 ])
> (const_int 4 [0x4])) [2 S4 A32])) -1 (nil))
>
> (insn 46 45 47 4 sms-6.c:12 (set (reg:SI 162)
> (mult:SI (reg:SI 160)
> (reg:SI 161))) -1 (nil))
>
> (insn 47 46 48 4 sms-6.c:12 (set (mem:SI (plus:SI (reg:SI 150 [ ivtmp.32 ])
> (const_int 4 [0x4])) [2 S4 A32])
> (reg:SI 162)) -1 (nil))
>
> (insn 48 47 49 4 sms-6.c:13 (set (reg:SI 163)
> (mem:SI (plus:SI (reg:SI 151 [ ivtmp.31 ])
> (const_int 8 [0x8])) [2 S4 A32])) -1 (nil))
>
> (insn 49 48 50 4 sms-6.c:13 (set (reg:SI 164)
> (mem:SI (plus:SI (reg:SI 152 [ ivtmp.29 ])
> (const_int 8 [0x8])) [2 S4 A32])) -1 (nil))
> ...
>
Re: [gnat] stmt_group_free_list and gnu_stack_free_list in trans.c
oliver.kell...@t-online.de (Oliver Kellogg) writes: > What is the point of stmt_group_free_list and gnu_stack_free_list in > trans.c? Why not always allocate a fresh node? Just for speed, I assume. It's usually faster to keep a free list than to go back to the allocator each time. I don't know anything about the Ada compiler but I assume it needs to allocate a bunch of stmt_group structures. stmt_group_free_list is marked deletable which means that if a garbage collection occurs the memory taken up by the free list will be freed. Ian
Re: Add support for the Win32 hook prologue (try 3)
Stefan Dösinger writes: >On a partly related topic, I think the Win64 ABI requires that the first >function is two bytes long, and there at least 6 bytes of slack before >the function. Does gcc implement that? As far as I can tell the Win64 ABI doesn't have either of these requirements. Microsoft's compiler certainly doesn't guarantee that functions begin with two byte instructions, and the "x64 Software Conventions" document gives examples of prologues with larger initial instructions: http://msdn.microsoft.com/en-us/library/tawsa7cb(VS.80).aspx Mind you, last I checked, GCC didn't actually follow the ABI requirements for prologues and epilogues given in the link above, but that only breaks ABI unwinding. Ross Ridge
Re: Add support for the Win32 hook prologue (try 3)
2009/9/11 Ross Ridge :
> Stefan Dösinger writes:
>>On a partly related topic, I think the Win64 ABI requires that the first
>>function is two bytes long, and there at least 6 bytes of slack before
>>the function. Does gcc implement that?
>
> As far as I can tell the Win64 ABI doesn't have either of these
> requirements. Microsoft's compiler certainly doesn't guarantee that
> functions begin with two byte instructions, and the "x64 Software
> Conventions" document gives examples of prologues with larger initial
> instructions:
>
> http://msdn.microsoft.com/en-us/library/tawsa7cb(VS.80).aspx
>
> Mind you, last I checked, GCC didn't actually follow the ABI requirements
> for prologues and epilogues given in the link above, but that only breaks
> ABI unwinding.
Right, but even unwinding is still possible on x64 (so we don't break
the SEH2 unwinding support actually), as everything gcc does here in
prologue, can be expressed by chaininfo (if prologue size is bigger
then 255 bytes).
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
[lto] Merge from trunk rev 151592.
This merge uncovered a bug in cgraph node streaming. There were
several bitflags that were not being written out. I also removed
a few old patches that are no longer needed.
Once the EH changes are in mainline, we'll be ready to merge the
streamer, which is the only module left to merge.
Bootstrapped and tested on x86_64.
Diego.
2009-09-11 Diego Novillo
Mainline merge @151592.
* configure.ac (ACX_PKGVERSION): Update revision merge string.
* configure: Regenerate.
2009-09-11 Diego Novillo
* cgraph.c (cgraph_clone_input_node): Remove. Update all users to
call cgraph_clone_node instead.
(cgraph_is_clone_node): Remove unused function.
* ipa.c (cgraph_remove_unreachable_nodes): Do not set
disregard_inline_limits to false.
(gate_ipa_fun_and_var_visibility): Remove. Update
pass_ipa_function_and_variable_visibility.
* lto-cgraph.c (lto_output_node): Output field count.
Reorganize packing of node bitflags to follow the same
order that they're declared.
Add fields address_taken, abstract_and_needed, reachable,
process, alias and finalized_by_frontend.
(input_overwrite_node): Corresponding changes.
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 11a9ed2..3d49b8d 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1713,44 +1713,6 @@ cgraph_clone_node (struct cgraph_node *n, gcov_type
count, int freq,
return new_node;
}
-/* Create node representing clone of N during when reading the call-graph
- from an LTO stream. This is simpler than cgraph_clone_node. Additional
- information in the cloned node will be filled in later. */
-
-struct cgraph_node *
-cgraph_clone_input_node (struct cgraph_node *n)
-{
- struct cgraph_node *new_node = cgraph_create_node ();
-
- new_node->decl = n->decl;
- new_node->origin = n->origin;
- if (new_node->origin)
-{
- new_node->next_nested = new_node->origin->nested;
- new_node->origin->nested = new_node;
-}
- new_node->analyzed = n->analyzed;
- new_node->local = n->local;
- new_node->global = n->global;
- new_node->rtl = n->rtl;
-
- new_node->next_sibling_clone = n->clones;
- if (n->clones)
-n->clones->prev_sibling_clone = new_node;
- n->clones = new_node;
- new_node->clone_of = n;
-
- return new_node;
-}
-
-/* Return true if N is a cloned node. */
-
-bool
-cgraph_is_clone_node (struct cgraph_node *n)
-{
- return n->clone_of != NULL;
-}
-
/* Create a new name for omp child function. Returns an identifier. */
static GTY(()) unsigned int clone_fn_id_num;
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 3349a57..10617ec 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -422,7 +422,6 @@ struct cgraph_edge * cgraph_clone_edge (struct cgraph_edge
*,
unsigned, gcov_type, int, int, bool);
struct cgraph_node * cgraph_clone_node (struct cgraph_node *, gcov_type, int,
int, bool);
-struct cgraph_node * cgraph_clone_input_node (struct cgraph_node *);
void cgraph_redirect_edge_callee (struct cgraph_edge *, struct cgraph_node *);
@@ -432,7 +431,6 @@ bool cgraph_function_possibly_inlined_p (tree);
void cgraph_unnest_node (struct cgraph_node *);
enum availability cgraph_function_body_availability (struct cgraph_node *);
-bool cgraph_is_clone_node (struct cgraph_node *);
void cgraph_add_new_function (tree, bool);
const char* cgraph_inline_failed_string (cgraph_inline_failed_t);
struct cgraph_node * cgraph_create_virtual_clone (struct cgraph_node *old_node,
diff --git a/gcc/ipa.c b/gcc/ipa.c
index 3f7a3ee..9204caa 100644
--- a/gcc/ipa.c
+++ b/gcc/ipa.c
@@ -216,7 +216,6 @@ cgraph_remove_unreachable_nodes (bool before_inlining_p,
FILE *file)
node->analyzed = false;
node->local.inlinable = false;
}
- node->local.disregard_inline_limits = false;
}
else
cgraph_remove_node (node);
@@ -315,18 +314,12 @@ function_and_variable_visibility (void)
return 0;
}
-static bool
-gate_ipa_fun_and_var_visibility (void)
-{
- return true;
-}
-
struct simple_ipa_opt_pass pass_ipa_function_and_variable_visibility =
{
{
SIMPLE_IPA_PASS,
"visibility",/* name */
- gate_ipa_fun_and_var_visibility, /* gate */
+ NULL,/* gate */
function_and_variable_visibility,/* execute */
NULL,/* sub */
NULL,/* next */
diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
index 899e111..dc85a38 100644
--- a/gcc/lto-cgraph.c
+++ b/gcc/lto-cgraph.c
@@ -243,11 +243,9 @@ lto_output_node (struct lto_simple_output_block *ob,
struct cgraph_node *node,
bitmap_set_bit (written_decls, DECL_UID (node->decl));
lto_output_fn_decl_index (ob->decl_state, ob->main_strea
Re: i370 port - in search of hooks
I'm making quite good progress with cleaning up the 3.4.6 i370
port. I've even got optimization working to some degree.
Meanwhile, on a different machine (a Linux machine I program
on on the way to/from work), I have managed to build 4.4.0,
which means I have an environment to work on a more modern
version of GCC.
That modern version is what I would like to ask about today.
Leaving aside the issue of the actual target, I'm more interested
in the intrusive hooks I expect I will need (I won't know until
I start doing the work, and I can't do that until I find out whether
4.4 is good enough - chicken and egg). Here is what I needed
for 3.4.6:
1. Ability to build a standalone executable. Simply put, I need
gcc to do a function call like this:
#ifdef SINGLE_EXECUTABLE
{
int cnt = 0;
while (commands[i].argv[cnt] != NULL)
{
cnt++;
}
if (strcmp(string, "cc1") == 0)
{
ret_code = toplev_main(cnt, commands[i].argv);
if (ret_code != 0) break;
}
}
#else
Doesn't need to be exactly like that, but some sort of hook to be
made available so that I can bypass system() or any variation of
that. C90 doesn't guarantee that system() will do anything in
particular. And my C environment indeed doesn't work too well
if you try that. Can't have two programs opening and closing
the same DDNAME. Can only have 100 characters worth of
parameters too.
2. A completely different way of handling include files. After going
through the normal remap process, I then want the following
transformations:
#include "fred.h"
gets translated into an fopen("dd:include(fred)", "r")
#include
gets translated into an fopen("dd:sysincl(fred)", "r")
None of this checking to see if something is a directory etc. There's
no such call available in C90, nor my C library on MVS. The code
above looks trivial enough, but when it's time to actually find where
to put that, it's non-trivial.
3. There is some complicated parameter lookup facility - it does a binary
search on the parameters. This requires a whole lot of infrastructure to
be present to generate the code. Infrastructure which I don't have. I'd
like a simple sequential search to be available as an option I can
activate.
4. There are a whole lot of includes that don't exist, like sys/types.h, and
I'd like them to be masked out like all other includes are done (even
things that are part of C90 have masks!!!).
5. It'd be cool if some of the names could be unique in the first 8
characters
(C90 guarantees 6 for externals, but I have the luxury of 8). I have a
mostly non-intrusive way of remapping everything, but there are a few
that I need to do intrusively, because I can't #define away something
that is already #defined. Problem is compounded by the fact that
I link together code that normally isn't linked together. Note that I don't
need things like an assembler and linker linked in together - I just need
the stuff required for the "-S" option to work. ie text file (ie C code)
in,
and text file (ie assembler code) out - a text processing program that
should be (and in fact, has already been made that way) possible to
do in pure C90.
6. It would be nice if all the non-C90 Posix functions were masked out,
but so far I have been able to kludge around that without requiring a
lot of intrusive changes. It would be good to get the worst of them
out though.
My questions are:
1. Are changes like the above likely to be accepted into the head version
going forward?
2. If they are, what version should I work on to get that to happen?
Ideally I'd like to work on a stable version, perhaps 4.4, and later have
those changes merged onto the head. But I fear if I do that I will end
up in the same position I am in now with 3.4.6, ie too many changes
such that my patches are never actually relevant.
But it's quite daunting to get this working at all.
So I thought that what I might be able to do instead is get the hooks
in place first. Not necessarily all at once. Possibly over the course
of a year.
Eventually all the hooks will exist, there will be a stable release cut
containing all the hooks I need, and then I may be in with a chance of
getting i370 working on that environment. That would also be done
over the course of a year or whatever, as the GMP and MPFR need to
be set up on MVS too (just having a S/390 port is not sufficient - I
need S/370 HLASM).
Hopefully at the end of that process, I'll have an i370 port that is done
in a "standard" way so that updating to the latest GCC is fairly trivial
*regardless* of whether the i370 port is included in GCC proper due
to the yet more technical challenges that requires, another job for
another year. :-)
This is a parallel effort to my 3.4.6 work which is done on a different
PC at a different time. 3.4.6 is mostly about getting it to run on
real MVS. 4.4/x is simply to get a cross-compile to work for now.
Thanks. Paul.
Re: [lambda] Latest experimental polymorphic lambda patches
On Tue, Aug 11, 2009 at 7:05 AM, Jason Merrill wrote: > A few comments: > >> /* XXX: Any way to get current location? */ > > input_location Just a late comment: using input_location is generally not a good idea. Every token in the parser has a location. That should be the source of all location information. Using input_location generally gives you the wrong column and sometimes even gives you the wrong line. We should eventually eliminate it. Ian
Re: MPC 0.7 officially released, please test and report your results!
On Thu, 2009-09-10 at 18:06 -0400, Kaveh R. GHAZI wrote:
> Hi,
>
> mpc-0.7 now has been released, you can get the package here:
> http://www.multiprecision.org/index.php?prog=mpc&page=download
>
> Here's the official announcement:
> http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-September/000554.html
>
> Of particular interest in this release are bugfixes, especially for
> complex division, and the introduction of mpc_pow used for folding
> cpow{,f,l} inside GCC.
>
> Note the complex "arc" functions are still missing and are now projected
> to be available in a future release, probably 0.8.
>
> Please download, compile and run "make check" for this release and post
> your results as well your target triplet and the versions of your
> compiler, gmp and mpfr. All platform results are welcome, but I am
> especially interested in GCC's primary and secondary platform list.
I tested using both -m32 and -m64 versions of the libraries.
powerpc64-unknown-linux-gnu
gcc-4.4.1
gmp-4.2.4
mpfr-2.4.1
mpc-0.7
For both versions of the library:
===
All 45 tests passed
===
[lto] Merge from trunk rev 151592 (repost)
Reposting. Apparently gmail has been labelling messages from
google.com as spam. It should be fixed now.
Diego.
-- Forwarded message --
From: Diego Novillo
Date: Fri, Sep 11, 2009 at 11:37
Subject: [lto] Merge from trunk rev 151592.
To: gcc@gcc.gnu.org
Cc: rguent...@suse.de
This merge uncovered a bug in cgraph node streaming. There were
several bitflags that were not being written out. I also removed
a few old patches that are no longer needed.
Once the EH changes are in mainline, we'll be ready to merge the
streamer, which is the only module left to merge.
Bootstrapped and tested on x86_64.
Diego.
2009-09-11 Diego Novillo
Mainline merge @151592.
* configure.ac (ACX_PKGVERSION): Update revision merge string.
* configure: Regenerate.
2009-09-11 Diego Novillo
* cgraph.c (cgraph_clone_input_node): Remove. Update all users to
call cgraph_clone_node instead.
(cgraph_is_clone_node): Remove unused function.
* ipa.c (cgraph_remove_unreachable_nodes): Do not set
disregard_inline_limits to false.
(gate_ipa_fun_and_var_visibility): Remove. Update
pass_ipa_function_and_variable_visibility.
* lto-cgraph.c (lto_output_node): Output field count.
Reorganize packing of node bitflags to follow the same
order that they're declared.
Add fields address_taken, abstract_and_needed, reachable,
process, alias and finalized_by_frontend.
(input_overwrite_node): Corresponding changes.
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 11a9ed2..3d49b8d 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1713,44 +1713,6 @@ cgraph_clone_node (struct cgraph_node *n,
gcov_type count, int freq,
return new_node;
}
-/* Create node representing clone of N during when reading the call-graph
- from an LTO stream. This is simpler than cgraph_clone_node. Additional
- information in the cloned node will be filled in later. */
-
-struct cgraph_node *
-cgraph_clone_input_node (struct cgraph_node *n)
-{
- struct cgraph_node *new_node = cgraph_create_node ();
-
- new_node->decl = n->decl;
- new_node->origin = n->origin;
- if (new_node->origin)
- {
- new_node->next_nested = new_node->origin->nested;
- new_node->origin->nested = new_node;
- }
- new_node->analyzed = n->analyzed;
- new_node->local = n->local;
- new_node->global = n->global;
- new_node->rtl = n->rtl;
-
- new_node->next_sibling_clone = n->clones;
- if (n->clones)
- n->clones->prev_sibling_clone = new_node;
- n->clones = new_node;
- new_node->clone_of = n;
-
- return new_node;
-}
-
-/* Return true if N is a cloned node. */
-
-bool
-cgraph_is_clone_node (struct cgraph_node *n)
-{
- return n->clone_of != NULL;
-}
-
/* Create a new name for omp child function. Returns an identifier. */
static GTY(()) unsigned int clone_fn_id_num;
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 3349a57..10617ec 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -422,7 +422,6 @@ struct cgraph_edge * cgraph_clone_edge (struct
cgraph_edge *,
unsigned, gcov_type, int, int, bool);
struct cgraph_node * cgraph_clone_node (struct cgraph_node *, gcov_type, int,
int, bool);
-struct cgraph_node * cgraph_clone_input_node (struct cgraph_node *);
void cgraph_redirect_edge_callee (struct cgraph_edge *, struct cgraph_node *);
@@ -432,7 +431,6 @@ bool cgraph_function_possibly_inlined_p (tree);
void cgraph_unnest_node (struct cgraph_node *);
enum availability cgraph_function_body_availability (struct cgraph_node *);
-bool cgraph_is_clone_node (struct cgraph_node *);
void cgraph_add_new_function (tree, bool);
const char* cgraph_inline_failed_string (cgraph_inline_failed_t);
struct cgraph_node * cgraph_create_virtual_clone (struct cgraph_node *old_node,
diff --git a/gcc/ipa.c b/gcc/ipa.c
index 3f7a3ee..9204caa 100644
--- a/gcc/ipa.c
+++ b/gcc/ipa.c
@@ -216,7 +216,6 @@ cgraph_remove_unreachable_nodes (bool
before_inlining_p, FILE *file)
node->analyzed = false;
node->local.inlinable = false;
}
- node->local.disregard_inline_limits = false;
}
else
cgraph_remove_node (node);
@@ -315,18 +314,12 @@ function_and_variable_visibility (void)
return 0;
}
-static bool
-gate_ipa_fun_and_var_visibility (void)
-{
- return true;
-}
-
struct simple_ipa_opt_pass pass_ipa_function_and_variable_visibility =
{
{
SIMPLE_IPA_PASS,
"visibility", /* name */
- gate_ipa_fun_and_var_visibility, /* gate */
+ NULL, /* gate */
function_and_variable_visibility, /* execute */
NULL, /* sub */
NULL, /* next */
diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
index 899e111..dc85a38 100644
--- a/gcc/
Not using DECL_VALUE_EXPR for callee-copied parameters?
Hi, we sometimes currently mess up when compiling callee-copied parameters on architectures that use it (so, as far as I know, on hppa). The manifestation of the issue is e.g. PR 40464 but I believe there maight be others. The real problem is that even though a comment in tree.h says that declarations with a DECL_VALUE_EXPR "once this field has been set, the decl itself may not legitimately appear in the function," they do because gimplify_parameters() in function.c generates an explicit copy statements. This then has unintended wrong consequences when such a declaration is later fed to the gimplifier again (for example through force_gimple_operand) because they are replaced with their value_expr. For reference, this is PR 41250. Because DECL_VALUE_EXPRs affect debug info I attempted to simply not doing the replacements in gimplifier but ran into all sorts of asserts in expand and later even to execution failures which altogether looked too overwhelming and so I gave up. At the moment I intend to simply stop making these callee-copied parameters value_expr ones since the convention is implemented explicitly - this amounts to the two line patch below. Obviously, this will impair debug info but I hope that for this purpose we can represent the relationship in another way. Specifically, I was hoping to be able to use BLOCK_NONLOCALIZED_VARS in the form in which they are in pretty-ipa where they essentially map no longer existing decls to expressions evaluating their values. Honza, do you think they will work also for an existing PARM_DECL? I have run the testsuite on hppa with the following patch and I successfully bootstrapped and tested it on x86_64. Unless someone objects, I will bootstrap it on hppa and commit it in a week or two along with Richi's patch verifying such decls don't leak to the IL (and then try to use the mechanism above to keep the debug info). Thanks, Martin 2009-09-11 Martin Jambor * function.c (gimplify_parameters): Do not set a value-expr on callee-copied parm decls. Index: small/gcc/function.c === --- small.orig/gcc/function.c +++ small/gcc/function.c @@ -3425,9 +3425,6 @@ gimplify_parameters (void) } gimplify_assign (local, parm, &stmts); - - SET_DECL_VALUE_EXPR (parm, local); - DECL_HAS_VALUE_EXPR_P (parm) = 1; } } } PS: If you are interested what other purposes value_exprs are used to, here is a list of places where SET_DECL_VALUE_EXPR is called, it is such a weird thing in gimple that it might be a worthy goal to replace them all with BLOCK_NONLOCALIZED_VARS: *** function.c: gimplify_parameters[3429] SET_DECL_VALUE_EXPR (parm, local); *** gimplify.c: gimplify_vla_decl[1320]SET_DECL_VALUE_EXPR (decl, t); gimplify_var_or_parm_decl[1900] SET_DECL_VALUE_EXPR (copy, unshare_expr (value_expr)); *** omp-low.c: fixup_remapped_decl[1029] SET_DECL_VALUE_EXPR (new_decl, ve); lower_rec_input_clauses[2382] SET_DECL_VALUE_EXPR (new_var, x); lower_rec_input_clauses[2438] SET_DECL_VALUE_EXPR (new_var, x); lower_rec_input_clauses[2465] SET_DECL_VALUE_EXPR (placeholder, x); lower_reduction_clauses[2672] SET_DECL_VALUE_EXPR (placeholder, ref); *** tree-cfg.c: replace_block_vars_by_duplicates[6183] SET_DECL_VALUE_EXPR (t, DECL_VALUE_EXPR (*tp)); *** tree-nested.c: get_nonlocal_debug_decl[839] SET_DECL_VALUE_EXPR (new_decl, x); get_local_debug_decl[1324] SET_DECL_VALUE_EXPR (new_decl, x); remap_vla_decls[2159] SET_DECL_VALUE_EXPR (var, val); *** tree.c: copy_node_stat[955]SET_DECL_VALUE_EXPR (t, DECL_VALUE_EXPR (node));
Re: Not using DECL_VALUE_EXPR for callee-copied parameters?
Martin Jambor writes: > I have run the testsuite on hppa with the following patch and I > successfully bootstrapped and tested it on x86_64. Unless someone > objects, I will bootstrap it on hppa and commit it in a week or two > along with Richi's patch verifying such decls don't leak to the IL > (and then try to use the mechanism above to keep the debug info). Without meaning to criticize your investigation, I object on procedural grounds--some maintainer must approve such a patch to mainline. I don't think it qualifies as obvious. Ian
Re: The return of the bootstrap comparison failure on i386
On Thu, 10 Sep 2009 01:38:13 +0200 (CEST) Gerald Pfeifer wrote: > i386-unknown-freebsd7.2, specifically, now PR 41326, after it has > been originally fixed a few days ago. > > Gerald > > Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > warning: gcc/cc1plus-checksum.o differs > warning: gcc/cc1obj-checksum.o differs > Bootstrap comparison failure! > gcc/coverage.o differs > gcc/gcov.o differs > gcc/gcov-dump.o differs > gmake[2]: *** [compare] Error 1 > gmake[2]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0909-2216' > gmake[1]: *** [stage3-bubble] Error 2 > gmake[1]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0909-2216' > gmake: *** [bootstrap-lean] Error 2 I haven't been able to bootstrap x86_64-unknown-linux-gnu at all since this started. Latest attempt was with r151649. make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH" "TARGET_SUBDIR=x86_64-unknown-linux-gnu" "bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre" "datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre" "exec_prefix=/usr" "includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/include" "datarootdir=/usr/share" "docdir=/usr/share/doc/" "infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/info" "pdfdir=/usr/share/doc/" "htmldir=/usr/share/doc/" "libdir=/usr/lib" "libexecdir=/usr/libexec" "lispdir=" "localstatedir=/usr/var" "mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/man" "oldincludedir=/usr/include" "prefix=/usr" "sbindir=/usr/sbin" "sharedstatedir=/usr/com" "sysconfdir=/usr/etc" "tooldir=/usr/x86_64-unknown-linux-gnu" "build_tooldir=/usr/x86_64-unknown-linux-gnu" "target_alias=x86_64-unknown-linux-gnu" "AWK=gawk" "BISON=bison" "CC_FOR_BUILD=x86_64-unknown-linux-gnu-gcc" "CFLAGS_FOR_BUILD=-O2 -g -march=core2 -pipe" "CXX_FOR_BUILD=x86_64-unknown-linux-gnu-g++" "EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS_FOR_BUILD=-Wl,--as-needed -Wl,--hash-style=gnu -Wl,--no-as-needed" "LEX=flex" "M4=m4" "MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SED=/bin/sed" "SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-O2 -g -march=core2 -pipe" "BOOT_LDFLAGS=" "CFLAGS=-O2 -g -march=core2 -pipe" "CXXFLAGS=-O2 -g -march=core2 -pipe" "LDFLAGS=-Wl,--as-needed -Wl,--hash-style=gnu -Wl,--no-as-needed" "LIBCFLAGS=-O2 -g -march=core2 -pipe" "LIBCXXFLAGS=-O2 -g -march=core2 -pipe -fno-implicit-templates" "STAGE1_CHECKING=--enable-checking=yes,types" "STAGE1_LANGUAGES=c" "GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=/usr/x86_64-unknown-linux-gnu/bin/ar" "AS_FOR_TARGET=/usr/x86_64-unknown-linux-gnu/bin/as" "CC_FOR_TARGET=/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build/./gcc/" "CFLAGS_FOR_TARGET=-O2 -g -march=core2 -pipe" "CPPFLAGS_FOR_TARGET=" "CXX_FOR_TARGET=/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build/./gcc/g++ -B/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build/./gcc/ -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs" "CXXFLAGS_FOR_TARGET=-O2 -g -march=core2 -pipe -D_GNU_SOURCE" "DLLTOOL_FOR_TARGET=dlltool" "FLAGS_FOR_TARGET=-B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem /usr/x86_64-unknown-linux-gnu/sys-include" "GCJ_FOR_TARGET=" "GFORTRAN_FOR_TARGET=" "LD_FOR_TARGET=/usr/x86_64-unknown-linux-gnu/bin/ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-O2 -g -march=core2 -pipe" "LIBCXXFLAGS_FOR_TARGET=-O2 -g -march=core2 -pipe -D_GNU_SOURCE -fno-implicit-templates" "NM_FOR_TARGET=/usr/x86_64-unknown-linux-gnu/bin/nm" "OBJDUMP_FOR_TARGET=/usr/x86_64-unknown-linux-gnu/bin/objdump" "RANLIB_FOR_TARGET=/usr/x86_64-unknown-linux-gnu/bin/ranlib" "STRIP_FOR_TARGET=/usr/x86_64-unknown-linux-gnu/bin/strip" "WINDRES_FOR_TARGET=windres" "WINDMC_FOR_TARGET=windmc" "BUILD_CONFIG=bootstrap-debug" "`echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=:" "STAGE1_CFLAGS=-O" "STAGE1_TFLAGS=" "STAGE2_CFLAGS=-O2 -g -march=core2 -pipe -gtoggle" "STAGE2_TFLAGS=" "STAGE3_CFLAGS=-O2 -g -march=core2 -pipe" "STAGE3_TFLAGS=" "STAGE4_CFLAGS=-O2 -g -march=core2 -pipe" "STAGE4_TFLAGS=" "STAGEprofile_CFLAGS=-O2 -g -march=core2 -pipe -gtoggle -fprofile-generate" "STAGEprofile_TFLAGS=" "STAGEfeedback_CFLAGS=-O2 -g -march=core2 -pipe -fprofile-use" "STAGEfeedback_TFLAGS=" "TFLAGS=" "CONFIG_SHELL=/bin/sh" "MAKEINFO=makeinfo --split-size=500 --split-size=500" compare make[2]: Entering directory `/v
Re: [lto] Merge from trunk rev 151592 (repost)
On Fri, Sep 11, 2009 at 1:08 PM, Diego Novillo wrote: > Reposting. Apparently gmail has been labelling messages from > google.com as spam. It should be fixed now. > > LTO branch failed to bootstrap on Linux/ia32 due to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41324 It has been fixed in mainline. -- H.J.
