Problem with reg_equiv_alt_mem
In a private port I had the problem that reg_equiv_alt_mem_list did contain the same RTL as reg_equiv_memory_loc. This caused an assert in delete_output_reload, where these are compared with equal_rtx_p. The list is build with push_reg_equiv_alt_mem, but only when "tem != orig". The value tem is build with find_reloads_address. Within that function we have some code which simply unshares the RTL. The return value will be the new RTL, even in some cases where the RTL did not change. I think the test in front of push_reg_equiv_alt_mem should be done via rtx_equal_p. This would match the assert in delete_output_reload. My private port is based on GCC 4.1.0, but the code looks the same in 4.3. I do not have papers on file so someone else should prepare a patch. Erwin
Re: Problem with reg_equiv_alt_mem
On 3/12/07, Unruh, Erwin <[EMAIL PROTECTED]> wrote: In a private port I had the problem that reg_equiv_alt_mem_list did contain the same RTL as reg_equiv_memory_loc. This caused an assert in delete_output_reload, where these are compared with equal_rtx_p. The list is build with push_reg_equiv_alt_mem, but only when "tem != orig". The value tem is build with find_reloads_address. Within that function we have some code which simply unshares the RTL. The return value will be the new RTL, even in some cases where the RTL did not change. I think the test in front of push_reg_equiv_alt_mem should be done via rtx_equal_p. This would match the assert in delete_output_reload. My private port is based on GCC 4.1.0, but the code looks the same in 4.3. I do not have papers on file so someone else should prepare a patch. For sufficiently small patches (usually less than 10 lines changed is used as the norm) you don't need to have a copyright assignment on file. Such small changes are apparently not covered by copyright. So if you could send a patch, that'd be quite helpful ;-) Gr. Steven
RE: gcc 4.2 branch build failure on powerpc-apple-darwin8
It would seem we need to change... Index: gcc/config/darwin.c === /usr/local/bin/gccdiff: line 1: i#!/bin/bash: No such file or directory --- gcc/config/darwin.c (revision 122839) +++ gcc/config/darwin.c (working copy) @@ -1112,7 +1112,7 @@ machopic_select_section (tree exp, int r else base_section = weak_p ? darwin_sections[text_coal_section] : text_section; } - else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT)) + else if (decl_readonly_section (exp, reloc)) base_section = weak_p ? darwin_sections[const_coal_section] : darwin_sections[const_section]; else if (TREE_READONLY (exp) || TREE_CONSTANT (exp)) base_section = weak_p ? darwin_sections[const_data_coal_section] : darwin_sections[const_data_section]; to cope with the removal of decl_readonly_section_1 by revision 122782. Jack
Manipulating the tree Structure
Hi all, i have a very little question for you. I have a basic block and by a statement iterator i can obtain a tree structure in the following manner: tree stmt = bsi_stmt (si); I want to use this tree structure to manipulate the statement, for example i 'd like to know if statement is an assignement or another instruction type. And if the statement is an assignement i'd like to know wich is the name of the variable. I have serchead too much but i have not found any information. Thanks to all, Andrea Callia D'Iddio
RE: Problem with reg_equiv_alt_mem
>On 3/12/07, Unruh, Erwin <[EMAIL PROTECTED]> wrote: >> In a private port I had the problem that reg_equiv_alt_mem_list did >> contain the same RTL as reg_equiv_memory_loc. This caused an assert in >> delete_output_reload, where these are compared with equal_rtx_p. >> The list is build with push_reg_equiv_alt_mem, but only when "tem != >> orig". The value tem is build with find_reloads_address. Within that >> function we have some code which simply unshares the RTL. The return >> value will be the new RTL, even in some cases where the RTL did not >> change. >> >> I think the test in front of push_reg_equiv_alt_mem should be done via >> rtx_equal_p. This would match the assert in delete_output_reload. >> >> My private port is based on GCC 4.1.0, but the code looks the same in >> 4.3. >> >> I do not have papers on file so someone else should prepare a patch. > >For sufficiently small patches (usually less than 10 lines changed is >used as the norm) you don't need to have a copyright assignment on file. >Such small changes are apparently not covered by copyright. > >So if you could send a patch, that'd be quite helpful ;-) Well, here is the patch, but ... - it is based on my (modified) version of GCC 4.1.0 - it is only tested with my private port - the test is not with the GCC testsuite I have only limited time and currently no machine where I can bootstrap full GCC. It misses GMP and MPFR to bootstrap more than C. So someone else should apply the patch to 4.3 and test it. Erwin --- reload.c-oldMon Mar 12 15:45:37 2007 +++ reload.cMon Mar 12 15:47:53 2007 @@ -4576,7 +4576,7 @@ find_reloads_toplev (rtx x, int opnum, e x = mem; i = find_reloads_address (GET_MODE (x), &x, XEXP (x, 0), &XEXP (x, 0), opnum, type, ind_levels, insn); - if (x != mem) + if (!rtx_equal_p (x, mem)) push_reg_equiv_alt_mem (regno, x); if (address_reloaded) *address_reloaded = i; @@ -4789,7 +4789,7 @@ find_reloads_address (enum machine_mode find_reloads_address (GET_MODE (tem), &tem, XEXP (tem, 0), &XEXP (tem, 0), opnum, ADDR_TYPE (type), ind_levels, insn); - if (tem != orig) + if (!rtx_equal_p (tem, orig)) push_reg_equiv_alt_mem (regno, tem); } /* We can avoid a reload if the register's equivalent memory @@ -5554,7 +5554,7 @@ find_reloads_address_1 (enum machine_mod RELOAD_OTHER, ind_levels, insn); - if (tem != orig) + if (!rtx_equal_p (tem, orig)) push_reg_equiv_alt_mem (regno, tem); /* Then reload the memory location into a base @@ -5620,7 +5620,7 @@ find_reloads_address_1 (enum machine_mod find_reloads_address (GET_MODE (tem), &tem, XEXP (tem, 0), &XEXP (tem, 0), opnum, type, ind_levels, insn); - if (tem != orig) + if (!rtx_equal_p (tem, orig)) push_reg_equiv_alt_mem (regno, tem); /* Put this inside a new increment-expression. */ x = gen_rtx_fmt_e (GET_CODE (x), GET_MODE (x), tem); @@ -5811,7 +5811,7 @@ find_reloads_address_1 (enum machine_mod find_reloads_address (GET_MODE (x), &x, XEXP (x, 0), &XEXP (x, 0), opnum, ADDR_TYPE (type), ind_levels, insn); - if (x != tem) + if (!rtx_equal_p (x, tem)) push_reg_equiv_alt_mem (regno, x); } } @@ -6033,7 +6033,7 @@ find_reloads_subreg_address (rtx x, int &XEXP (tem, 0), opnum, type, ind_levels, insn); /* ??? Do we need to handle nonzero offsets somehow? */ - if (!offset && tem != orig) + if (!offset && !rtx_equal_p (tem, orig)) push_reg_equiv_alt_mem (regno, tem); /* If this is not a toplevel operand, find_reloads doesn't see
Re: Manipulating the tree Structure
[EMAIL PROTECTED] wrote on 12/03/2007 16:56:53: > Hi all, > i have a very little question for you. I have a basic block and by a > statement iterator i can obtain a tree structure in the following > manner: > tree stmt = bsi_stmt (si); > I want to use this tree structure to manipulate the statement, for > example i 'd like to know if statement is an assignement or another > instruction type. And if the statement is an assignement i'd like to > know wich is the name of the variable. > I have serchead too much but i have not found any information. > Thanks to all, You can use the TREE_CODE of stmt to know that instruction type. Almost all the tree-* files manipulate the stmt tree so you can grep in those files to find more examples. Revital > Andrea Callia D'Iddio
Re: Manipulating the tree Structure
Andrea Callia D'Iddio wrote on 12/03/2007 16:56:53:
> Hi all,
> i have a very little question for you. I have a basic block and by a
> statement iterator i can obtain a tree structure in the following
> manner:
> tree stmt = bsi_stmt (si);
> I want to use this tree structure to manipulate the statement, for
> example i 'd like to know if statement is an assignement or another
> instruction type. And if the statement is an assignement i'd like to
> know wich is the name of the variable.
The key is whether the tree_code is "MODIFY_EXPR", which is (copied from
tree.def):
/* Assignment expression. Operand 0 is the what to set; 1, the new value.
*/
DEFTREECODE (MODIFY_EXPR, "modify_expr", tcc_expression, 2)
So, I think you should do something like:
enum tree_code code = TREE_CODE (stmt);
switch (code)
{
case MODIFY_EXPR:
...
}
Good luck,
Tehila.
> I have serchead too much but i have not found any information.
> Thanks to all,
>
> Andrea Callia D'Iddio
S/390 Bootstrap failure: ICE in cse_find_path, at cse.c:5930
Hi,
gcc currently doesn't boostrap on s390 and s390x:
/build2/gcc-4.3-build/s390x-ibm-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:2025:
internal compiler error: in cse_find_path, at cse.c:5930
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
The problem looks related to [Bug middle-end/30149].
The ICE is issued in cse_find_path by the following code:
if (e && e->dest != EXIT_BLOCK_PTR
&& single_pred_p (e->dest))
{
basic_block bb2 = e->dest;
/* We should only see blocks here that we have not
visited yet. */
gcc_assert (!TEST_BIT (cse_visited_basic_blocks, bb2->index));
...
This code is executed when cse_follow_jumps is enabled. The check for
predecessor
edges does not look sufficient to me since cse itself might remove edges what
could lead to loops not connected to any of the other basic blocks. These
loops can't
be recognized with that check.
E.g.:
1 ---> 2 --|
| ^ |
| |---|
|
|--> 3
Lets consider that bb 1 ends with a conditional jump insn to bb 3. cse'ing that
insn via cse_extended_basic_block -> cse_insn now replaces the cond. jump with
an
unconditional one and deletes the edge 1->2. Afterwards cse_find_path for bb 2
is called
and since single_pred_p now returns true the assertion is triggered.
The problem is that removing edges in cse may create dead basic blocks which
are still
mentioned in rc_order array computed when the edges were still in place.
Bye,
-Andreas-
Re: S/390 Bootstrap failure: ICE in cse_find_path, at cse.c:5930
On 3/12/07, Andreas Krebbel <[EMAIL PROTECTED]> wrote: Hi, gcc currently doesn't boostrap on s390 and s390x: See http://gcc.gnu.org/ml/gcc-bugs/2007-03/msg00930.html Gr. Steven
Re: gcc 4.2 branch build failure on powerpc-apple-darwin8
On Mon, Mar 12, 2007 at 08:32:43AM -0400, Jack Howarth wrote:
> - else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT))
> + else if (decl_readonly_section (exp, reloc))
Not just that. Try this.
* config/darwin.c (machopic_reloc_rw_mask): New.
(machopic_select_section): Use decl_readonly_section.
* config/darwin-protos.h (machopic_reloc_rw_mask): Declare.
* config/darwin.h (TARGET_ASM_RELOC_RW_MASK): New.
--- config/darwin-protos.h (revision 122852)
+++ config/darwin-protos.h (local)
@@ -52,6 +52,7 @@ extern void darwin_set_default_type_attr
extern void machopic_finish (FILE *);
+extern int machopic_reloc_rw_mask (void);
extern section *machopic_select_section (tree, int, unsigned HOST_WIDE_INT);
extern section *machopic_select_rtx_section (enum machine_mode, rtx,
unsigned HOST_WIDE_INT);
--- config/darwin.c (revision 122852)
+++ config/darwin.c (local)
@@ -1093,6 +1093,12 @@ darwin_mark_decl_preserved (const char *
fputc ('\n', asm_out_file);
}
+int
+machopic_reloc_rw_mask (void)
+{
+ return MACHOPIC_INDIRECT ? 3 : 0;
+}
+
section *
machopic_select_section (tree exp, int reloc,
unsigned HOST_WIDE_INT align ATTRIBUTE_UNUSED)
@@ -1112,7 +1118,7 @@ machopic_select_section (tree exp, int r
else
base_section = weak_p ? darwin_sections[text_coal_section] :
text_section;
}
- else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT))
+ else if (decl_readonly_section (exp, reloc))
base_section = weak_p ? darwin_sections[const_coal_section] :
darwin_sections[const_section];
else if (TREE_READONLY (exp) || TREE_CONSTANT (exp))
base_section = weak_p ? darwin_sections[const_data_coal_section] :
darwin_sections[const_data_section];
--- config/darwin.h (revision 122852)
+++ config/darwin.h (local)
@@ -679,6 +679,8 @@ extern GTY(()) section * darwin_sections
#define TARGET_ASM_UNIQUE_SECTION darwin_unique_section
#undef TARGET_ASM_FUNCTION_RODATA_SECTION
#define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section
+#undef TARGET_ASM_RELOC_RW_MASK
+#define TARGET_ASM_RELOC_RW_MASK machopic_reloc_rw_mask
#define ASM_DECLARE_UNRESOLVED_REFERENCE(FILE,NAME)\
Re: Massive SPEC failures on trunk
On 3/3/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote: Hi, Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level. Regression introduced somewhere between revision 122487 and 122478. There are three checkins, candidates for the root of regression: http://gcc.gnu.org/viewcvs?view=rev&revision=122487 http://gcc.gnu.org/viewcvs?view=rev&revision=122484 http://gcc.gnu.org/viewcvs?view=rev&revision=122479 Here is the list of failures: CPU2006/464.h264ref: GCC ICE image.c: In function 'UnifiedOneForthPix': image.c:1407: internal compiler error: in set_value_range, at tree-vrp.c:267 CPU2006/447.dealII: GCC ICE fe_tools.cc: In static member function 'static void FETools::get_projection_matrix(const FiniteElement&, const FiniteElement&, FullMatrix&) [with int dim = 3, number = double]': fe_tools.cc:322: error: definition in block 47 does not dominate use in block 49 for SSA_NAME: NMT.4199_484 in statement: NMT.4199_645 = PHI PHI argument NMT.4199_484 for PHI node NMT.4199_645 = PHI fe_tools.cc:322: internal compiler error: verify_ssa failed Most of the problems are fixed, dealII remains with: /gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/g++ -c -o quadrature.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3 -O2 -DSPEC_CPU_LP64 quadrature.cc quadrature.cc: In constructor 'Quadrature::Quadrature(const std::vector, std::allocator > >&)': quadrature.cc:64: error: 'atof' is not a member of 'std' I guess that's a fallout from Paolos include streamlining in libstdc++. Looks like dealII sources need a fix for that. bzip2 fails with: compress.c: In function 'BZ2_compressBlock': compress.c:711: internal compiler error: in cse_find_path, at cse.c:5930 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. specmake: *** [compress.o] Error 1 a known problem. (x86_64, -O3 -funroll-loops -fpeel-loops -ftree-vectorize) Richard.
Re: Manipulating the tree Structure
Great! thank you! I tested with your code and it works... but I'm
still a bit confused.
Could you help me with this simple example?
Suppose that I obtained a tree structure with the following command:
tree stmt = bsi_stmt (si);
and suppose I want to execute the following task:
For each tree statement t:
IF t is an assignment, then output variable name
ELSE IF t is an IF statement then output the IF condition
ELSE ...
how can I do this task?
Can you give me some reference?
Thanks to all,
Andrea
On 3/12/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote:
The key is whether the tree_code is "MODIFY_EXPR", which is (copied from
tree.def):
/* Assignment expression. Operand 0 is the what to set; 1, the new value.
*/
DEFTREECODE (MODIFY_EXPR, "modify_expr", tcc_expression, 2)
So, I think you should do something like:
enum tree_code code = TREE_CODE (stmt);
switch (code)
{
case MODIFY_EXPR:
...
}
Good luck,
Tehila.
Re: Massive SPEC failures on trunk
On Mon, Mar 12, 2007 at 05:27:21PM +0100, Richard Guenther wrote: > Most of the problems are fixed, dealII remains with: > > /gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/g++ -c -o > quadrature.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS > -Ddeal_II_dimension=3 -O2 -DSPEC_CPU_LP64 quadrature.cc > quadrature.cc: In constructor 'Quadrature::Quadrature(const > std::vector, std::allocator > >&)': > quadrature.cc:64: error: 'atof' is not a member of 'std' > > I guess that's a fallout from Paolos include streamlining in > libstdc++. Looks like dealII > sources need a fix for that. > I have reported it to SPEC with a patch. H.J.
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
Ross Ridge wrote: > Any library that needs to be able to be called from VisualBasic 6 or some > other "stdcall only" environment should explictly declare it's exported > functions with the stdcall calling convention. Tobias Burnus writes: > Thus, if I understood you correctly, you recommend that we add, e.g., > pragma support to gfortran with a pragma which adds the > __attribute__((stdcall)) to the tree? I have no idea what would be the best way to do it in Fortran, but yes, something that would add the stdcall attribute. Ross Ridge
We're out of tree codes: Now what?
Re: Manipulating the tree Structure
On 3/12/07, Andrea Callia D'Iddio <[EMAIL PROTECTED]> wrote:
Great! thank you! I tested with your code and it works... but I'm
still a bit confused.
Could you help me with this simple example?
Suppose that I obtained a tree structure with the following command:
tree stmt = bsi_stmt (si);
and suppose I want to execute the following task:
For each tree statement t:
IF t is an assignment, then output variable name
In 4.3 (earlier replace GIMPLE_MODIFY_STMT with MODIFY_EXPR)
if (TREE_CODE (t) == GIMPLE_MODIFY_STMT)
{
tree lhs = TREE_OPERAND (t, 0);
tree rhs = TREE_OPERAND (t, 1);
print_generic_expr (stderr, lhs, 0);
print_generic_expr (stderr, rhs, 0);
}
ELSE IF t is an IF statement then output the IF condition
else if TREE_CODE (t) == COND_EXPR)
{
tree condition = COND_EXPR_COND (t);
print_generic_expr (stderr, condition, 0);
}
ELSE ...
how can I do this task?
Really, this isn't that hard
Can you give me some reference?
Look at any existing tree-ssa-*.c pass
They all do this in a myriad of ways.
We're out of tree codes; now what?
[This is a re-send of my previous e-mail; my apologies, yet again, for
the e-mail mangling on my end. Those responsible have been sacked.]
With the introduction of the variadic templates patch, we now have
more than 255 tree codes in GCC. This causes the mainline
Objective-C++ compiler to fail to build:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31134
We've known for a long time that we would eventually hit the limit on
the number of tree codes in GCC, and the variadic templates patch
happened to win the 8-bit tree-code lottery. Reverting the variadic
templates patch is not a solution: we'll hit this limit again, and
next time it will be with a feature that you find crucial. Reducing
the number of tree codes we use also seems infeasible: combining two
somewhat-similar entities into a single tree code is a short-term fix
with long-term problems, including poor readability and a greater
likelihood of bugs.
We need more tree codes. With GCC's current structure, that means
increasing the number of bits allocated for tree codes in the
tree_base struct. This will increase GCC's memory footprint. It's
unfortunate, but is it avoidable? I suspect it is not, without a major
restructuring of the compiler.
The patch below makes the CODE field of the tree_base struct 16 bits,
and adds suitable padding to fill out a 32-bit word. Elsewhere, the
limit on tree codes is raised to 512. Tested i686-pc-linux-gnu; no
regressions with C, C++, Objective C, Objective-C++, or Java.
Note: I've also sent this to gcc-patches, because there is a patch in
it. However, let's keep the discussion on [EMAIL PROTECTED]
Cheers,
Doug
:ADDPATCH C:
2007-03-12 Douglas Gregor <[EMAIL PROTECTED]>
* tree.c (tree_contains_struct): Permit 512 tree codes.
* tree.h (tree_contains_struct): Ditto.
(MAX_TREE_CODES): Ditto.
(struct tree_base): Make CODE 16 bits, instead of 8 bits. Add
SPARE member to store remaining padding bits.
Index: tree.c
===
--- tree.c (revision 122840)
+++ tree.c (working copy)
@@ -168,7 +168,7 @@ static unsigned int attribute_hash_list
tree global_trees[TI_MAX];
tree integer_types[itk_none];
-unsigned char tree_contains_struct[256][64];
+unsigned char tree_contains_struct[512][64];
/* Number of operands for each OpenMP clause. */
unsigned const char omp_clause_num_ops[] =
Index: tree.h
===
--- tree.h (revision 122840)
+++ tree.h (working copy)
@@ -41,7 +41,7 @@ enum tree_code {
#undef DEFTREECODE
-extern unsigned char tree_contains_struct[256][64];
+extern unsigned char tree_contains_struct[512][64];
#define CODE_CONTAINS_STRUCT(CODE, STRUCT)
(tree_contains_struct[(CODE)][(STRUCT)])
/* Number of language-independent tree codes. */
@@ -80,7 +80,7 @@ extern const char *const tree_code_class
#define TREE_CODE_CLASS_STRING(CLASS)\
tree_code_class_strings[(int) (CLASS)]
-#define MAX_TREE_CODES 256
+#define MAX_TREE_CODES 512
extern const enum tree_code_class tree_code_type[];
#define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)]
@@ -363,7 +363,7 @@ union tree_ann_d;
struct tree_base GTY(())
{
- ENUM_BITFIELD(tree_code) code : 8;
+ ENUM_BITFIELD(tree_code) code : 16;
unsigned side_effects_flag : 1;
unsigned constant_flag : 1;
@@ -392,6 +392,8 @@ struct tree_base GTY(())
unsigned lang_flag_6 : 1;
unsigned visited : 1;
+ unsigned spare : 24;
+
/* FIXME tuples: Eventually, we need to move this somewhere external to
the trees. */
union tree_ann_d *ann;
Re: none
"Doug Gregor" <[EMAIL PROTECTED]> writes: Am I the only one to receive Doug's recent messages with empty body? -- Gaby
Re: We're out of tree codes; now what?
I thought that the Tuples conversion was suppose to address this in the long term. David
Import GCC 4.2.0 PRs
Here are some GCC 4.2.0 P1s which I think it would be good for GCC to have resolved before the release, together with names of people I'd like to volunteer to help. (Naturally, I have no command authority, and I'd encourage anyone else who wants to help to pitch in, but I'm trying to tap a few likely suspects.) * PR 27945 (Merill) -- layout of structures with packed fields. This is an ABI change. We've had the current behavior in 4.0 and 4.1, so it's not essential that this be fixed in 4.2.0, but from Jason's comments last November in the PR it doesn't sound that hard to fix. * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked to reload, but he's not sure what to do there. Perhaps Ulrich can help. * PR 29286 (Berlin, Taylor) -- This is the problem with our alias analysis not understanding placement new. Ignoring the full complexity of C/C++ object lifetimes, new vs. malloc vs. casts, etc., it's clear that the test case is being mishandled. Is there anything we can do? This is an unfortunate problem, and all our efforts to make the optimizers smarter will exacerbate this problem. * PR 29585 (Berlin) -- This is a crash in alias analysis with anonymous namespaces. I can't imagine that anonymous namespaces have any deep implications for aliasing, so I would hope this is an easy fix. * PR 29841 (Hubicka, Henderson) -- This is an oft-reported crash on __builtin_trap with a fix inside flow/scheduler. A quick review by someone familiar with the code should close this out. * PR 29906 (Oliva) -- This is a crash during DWARF generation for a small C++ test case. * PR 30132 (Pinksi, Berlin) -- This is an aliasing crash on complex numbers. Andrew, you mentioned you might have a patch. * PR 30221 (Sidwell, Mitchell) -- An ICE-on-valid for initializing arrays of pointer-to-member functions in C++. * PR 30590 (Guenther, Merill) -- Wrong code generated by NRV. * PR 30700 (Hubicka) -- Cgraph causes undefined references. * PR 30704 (Edelsohn) -- Bad code generation for long long on big-endian targets. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Import GCC 4.2.0 PRs
On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: * PR 30132 (Pinski, Berlin) -- This is an aliasing crash on complex numbers. Andrew, you mentioned you might have a patch. Yes I have a patch but I need to go back and look at the sources again, I can get to this bug tomorrow as the sources for this patch is on a computer at home which does not have internet access right now. IIRC I ran into another bug while fixing this one. Also this is not a aliasing crash. Thanks, Andrew Pinski
Re: Import GCC 4.2.0 PRs
On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Here are some GCC 4.2.0 P1s which I think it would be good for GCC to have resolved before the release, together with names of people I'd like to volunteer to help. (Naturally, I have no command authority, and I'd encourage anyone else who wants to help to pitch in, but I'm trying to tap a few likely suspects.) * PR 29585 (Berlin) -- This is a crash in alias analysis with anonymous namespaces. I can't imagine that anonymous namespaces have any deep implications for aliasing, so I would hope this is an easy fix. The bug report says that part is fixed, and only a ccp issue remains. "The testcase in comment #2 works for me on the 4.2 branch now, but the one in comment #7 fails with ... in tree-ssa-ccp.c"
Re: Import GCC 4.2.0 PRs
Mark Mitchell wrote: > * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked > to reload, but he's not sure what to do there. Perhaps Ulrich can help. This description doesn't appear to match the bugzilla record. Maybe you're referring to PR 28675? I can have a look at that one. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE [EMAIL PROTECTED]
Re: We're out of tree codes; now what?
On 3/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote: I thought that the Tuples conversion was suppose to address this in the long term. The tuples conversion is only going to make things worse in the short term. Doug, isn't there a lang_tree bit you can make available, and use it to make the tree code field 9 bits wide? I know this is also not quite optimal, but adding 24 bits like this is an invitation to everyone to start using those bits, and before you know it we're stuck with a larger-than-necessary tree structure... :-( (plus, it's not 32 bits but 64 bits extra on 64 bits hosts...) Gr. Steven
Re: Import GCC 4.2.0 PRs
Ulrich Weigand wrote: > Mark Mitchell wrote: > >> * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked >> to reload, but he's not sure what to do there. Perhaps Ulrich can help. > > This description doesn't appear to match the bugzilla record. Maybe you're > referring to PR 28675? I can have a look at that one. Indeed. Thanks for the detective work! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Quick FUNCTION_MODE doco query
Dave Korn wrote: Was this description perhaps written in pre-RISC days? Yes. You can find identical text in the gcc-1.42 documentation, when almost every port was a CISC. The docs in rtl.texi for the call expression is a bit clearer about the intent here for FUNCTION_MODE. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: We're out of tree codes; now what?
On Mar 12, 2007, at 11:13 AM, Doug Gregor wrote: With the introduction of the variadic templates patch, we now have more than 255 tree codes in GCC. I do wonder about compilation speed for C++ code. Barring some other innovative approach, even with a slow down, which I'd hate, I think this may be the best approach. Thanks for addressing this.
Re: We're out of tree codes; now what?
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 3/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote: > I thought that the Tuples conversion was suppose to address this > in the long term. The tuples conversion is only going to make things worse in the short term. Doug, isn't there a lang_tree bit you can make available, and use it to make the tree code field 9 bits wide? I know this is also not quite optimal, It's going to have a big performance impact. To extract a 9-bit value, the compiler will need to do a lot of masking every time it accesses the TREE_CODE. We need the size of CODE to match the size of a built-in integer type, which means we need to either expand the structure or find 8 (!) free bits to shuffle. but adding 24 bits like this is an invitation to everyone to start using those bits, and before you know it we're stuck with a larger-than-necessary tree structure... :-( Yep, that's what got us where we are today. We said, "oh, we'll never need more than 256 codes, let's use the other 24 bits for flags!" Cheers, Doug
Re: Import GCC 4.2.0 PRs
On Monday 12 of March 2007 19:47:21 Mark Mitchell wrote: > * PR 29906 (Oliva) -- This is a crash during DWARF generation for a > small C++ test case. += PR 29202. ps). the PR 30052 (aliasing related) is still unconfirmed.
Re: We're out of tree codes; now what?
Hi, just wanted to say explicitely that I'm supporting completely Doug' efforts at fixing this issue. Well, I'm a little biased, because I'm working on C++/26099 and I will need at least one new tree code, but that's not the point, the point is that where we are implementing C++0x features and improving the C++ front-end generally, we are unavoidably adding tree codes and we must solve the issue, one way or another. We should help Doug in any possible way in this task, not ask for reversions. Paolo.
Re: We're out of tree codes; now what?
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote: Hi, just wanted to say explicitely that I'm supporting completely Doug' efforts at fixing this issue. Well, I'm a little biased, because I'm working on C++/26099 and I will need at least one new tree code, but that's not the point, the point is that where we are implementing C++0x features and improving the C++ front-end generally, we are unavoidably adding tree codes and we must solve the issue, one way or another. We should help Doug in any possible way in this task, not ask for reversions. Can I recommend something just crazy, rewrite the C and C++ front-ends so they don't use the tree structure at all except when lowering until gimple like the rest of the GCC front-ends? This will cause us to get back a couple more free tree codes. There are a couple of unused tree codes also if you want to reduce the current number, the Objective-C++ front-end have a couple which no longer need to be trees also (at one point people just abused tree codes for lots of stuff). -- Pinski
Re: We're out of tree codes; now what?
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote: we are unavoidably adding tree codes and we must solve the issue, one way or another. Another real solution would perhaps be to not use 'tree' for front end specific data structures in C++, and instead just define g++ specific data structures to represent all the language details ;-) G++ needs 64 (!) language specific tree codes, almost 7 times more than any other front end, and in total more than twice as many as all other front ends (java, ada, and objc) together. IMHO, now all languages are going to suffer from a larger 'tree' and a slower compiler, because g++ basically abuses a shared data structure. Gr. Steven
Re: We're out of tree codes; now what?
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: Can I recommend something just crazy, rewrite the C and C++ front-ends so they don't use the tree structure at all except when lowering until gimple like the rest of the GCC front-ends? The C front end already emits generic, so there's almost no win in rewriting it (one lame tree code in c-common.def -- not worth the effort ;-). Gr. Steven
Re: We're out of tree codes; now what?
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: > Can I recommend something just crazy, rewrite the C and C++ front-ends > so they don't use the tree structure at all except when lowering until > gimple like the rest of the GCC front-ends? The C front end already emits generic, so there's almost no win in rewriting it (one lame tree code in c-common.def -- not worth the effort ;-). I was thinking to rewrite the C++ front-end not to use extra tree codes you would also need to rewrite the C front-end but now thinking about, you could use one tree code for all of C++ and then use subcodes or at least one tree code for types, one for expressions, one for decls and one for all others and then use subcodes. This seems more like good an inherience issue, right now we have a very flat class system, this change will then making it slightly higher inheianct chain but we should able to reduce some of the bloat from the middle-end that the C++ front-end abuses the tree structure wise. Thanks, Andrew Pinski
Re: We're out of tree codes; now what?
"Steven Bosscher" <[EMAIL PROTECTED]> writes: | On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote: | > we are unavoidably | > adding tree codes and we must solve the issue, one way or another. | | Another real solution would perhaps be to not use 'tree' for front end | specific data structures in C++, and instead just define g++ specific | data structures to represent all the language details ;-) that strickes me as a far better, long term solution; however, it requires much larger efforts. Traditional, we tend to favor short term solutions... | G++ needs 64 (!) language specific tree codes, almost 7 times more | than any other front end, and in total more than twice as many as all | other front ends (java, ada, and objc) together. yet, some of us think it does not have enough ;-) -- Gaby
Re: We're out of tree codes; now what?
On Mar 12, 2007, at 1:47 PM, Andrew Pinski wrote: Can I recommend something just crazy, rewrite the C++ front-end so they don't use the tree structure at all except when lowering until gimple like the rest of the GCC front-ends? :-) I don't have any objections, as long as people can keep the compilation speed up, though, sounds like a bit of work. I'd look towards a project architect to help steer us towards goodness and keep us out of trouble. I can see some advantage to having a cleaner boundary between the front-ends and the mid-end.
Re: We're out of tree codes; now what?
Steven Bosscher wrote: Another real solution would perhaps be to not use 'tree' for front end specific data structures in C++, and instead just define g++ specific data structures to represent all the language details ;-) When I said, let's support Doug, I meant let's support Doug from a *practical* point of view. Either we suggest something doable with a realistically sized effort or a little larger and at the same time we volunteer to actually do it. In my opinion, "visions" for a better future do not help here. Paolo.
Re: We're out of tree codes; now what?
Paolo Carlini <[EMAIL PROTECTED]> writes: | In my opinion, "visions" for a better future do not help here. And here we are. :-) -- Gaby
Re: We're out of tree codes; now what?
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: > On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > Can I recommend something just crazy, rewrite the C and C++ front-ends > > so they don't use the tree structure at all except when lowering until > > gimple like the rest of the GCC front-ends? > > The C front end already emits generic, so there's almost no win in > rewriting it (one lame tree code in c-common.def -- not worth the > effort ;-). I was thinking to rewrite the C++ front-end not to use extra tree codes you would also need to rewrite the C front-end but now thinking about, you could use one tree code for all of C++ and then use subcodes or at least one tree code for types, one for expressions, one for decls and one for all others and then use subcodes. This was part of the point of making decl nodes a hierarchy, to enable exactly this (even though it has not been split into subcodes yet) tree_contains_struct then allows you to exactly check things are still safe to access.
Re: We're out of tree codes; now what?
On Mon, 12 Mar 2007, Mike Stump wrote: > :-) I don't have any objections, as long as people can keep the compilation > speed up, though, sounds like a bit of work. I'd look towards a project > architect to help steer us towards goodness and keep us out of trouble. I can > see some advantage to having a cleaner boundary between the front-ends and the > mid-end. You won't get a very clean separation, given that back ends manipulate C and C++ structures for target-specific built-in functions (including overloaded ones), attributes, pragmas, etc., that layout information is needed in the front ends, and that debug info involves target-specific and languages-specific information. You can improve things, but the (language, target, debug format) combinations will always be there with the associated need for one part of the compiler to know about structures from others. If you want separation, I suggest starting by making one thing at a time that shouldn't be a tree cease to be a tree everywhere. Partial work on TREE_LIST elimination is on the LTO branch. The CALL_EXPR parts have been merged, work on merging the TYPE_ARG_TYPES parts is in progress, there are many smaller patches there not yet merged and many other TREE_LIST cases not yet eliminated. Where those cases are front-end-specific structures, they can become front-end-local types. Another case that shouldn't be trees is identifiers. Key here is that each incremental stage should reduce memory usage and be useful on its own. -- Joseph S. Myers [EMAIL PROTECTED]
Re: We're out of tree codes; now what?
Mike Stump wrote: On Mar 12, 2007, at 11:13 AM, Doug Gregor wrote: With the introduction of the variadic templates patch, we now have more than 255 tree codes in GCC. I do wonder about compilation speed for C++ code. Barring some other innovative approach, even with a slow down, which I'd hate, I think this may be the best approach. Thanks for addressing this. How about a variable size - huffman encode the most frequent codes in to one byte, relegate the less frequent to two bytes. Nick.
Re: We're out of tree codes; now what?
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote: In my opinion, "visions" for a better future do not help here. No, I fully agree. I mean, imagine we'd have a long term plan for GCC. That would be so out of line! ;-) I'm not arguing against a practical solution. But to me at least it is just *so* frustrating to know that this issue was known literally years ago, and yet nothing has happened to avoid the situation before it could occur. Now we're looking at another set of hacks to "fix" the issue. And you know just as well as I do, that we're going to be stuck with those hacks forever, because nobody will have any motivation to fix the real problem for once. But oh well. SEP. Gr. Steven
Re: We're out of tree codes; now what?
> It's going to have a big performance impact. To extract a 9-bit value, > the compiler will need to do a lot of masking every time it accesses > the TREE_CODE. "a lot masking" means at most two additional instructions, one if we put it in the right place. I'd be shocked if we could even measure this, let alone be a "big" performance impact.
Re: Import GCC 4.2.0 PRs
Mark Mitchell wrote: * PR 27945 (Merill) * PR 30590 (Guenther, Merill) I'll get on these. Jason
Re: We're out of tree codes; now what?
On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote: When I said, let's support Doug, I meant let's support Doug from a *practical* point of view. Either we suggest something doable with a realistically sized effort or a little larger and at the same time we volunteer to actually do it. In my opinion, "visions" for a better future do not help here. I'd disagree. It is nice to have a stated idea of where we want to go, even if we can't get there today. We can measures patch goodness by how closely each patch moves us in that direction. That said, we all realize we are _not_ asking Doug to please re-implement the C++ frontend to our design to fix this issue. I'd be against that. Making C++ use a few tree codes (a la the back end) and burying the `extended' code in the C++ frontend sounds enticing, sounds like less work than redoing the FE to not use trees entirely and a step in the right direction. I checked the Objective-C frontend, it seems possible to do it as well. The tree_contains_struct stuff seems the `hardest' to get right, though, for Objective-C I think we could get by with 2 tree codes, maybe. Those that have TS_DECL_NON_COMMON, TS_DECL_WITH_VIS, TS_DECL_WRTL, TS_DECL_MINIMAL and TS_DECL_COMMON and those without? I looked at all uses of the Objective-C specific tree codes, and they all seemed to come in two forms: TREE_CODE (t) == and build_routine (, ...) The first can be replaced with OBJ_TREE_CODE_P (t) and it could do (TREE_CODE (t) == OBJ_COMMON_CODE && OBJC_TREE_CODE (t) == ) or some such. The second can be almost left as is, and ultimately the builder can build with OBJ_COMMON_CODE and then stuff code into OBJC_TREE_CODE. I'm hoping that might allow us to reduce the pressure enough so that we can fit back down into 8 bits, so as to avoid the memory size increase and (the unmeasured) slowdowns that would result. Objective- C/C++ would slow down, but, faced with the slowdown that would be certain if we didn't do this, I don't see how we could not. The benefit, all other languages would not, which is still important to us. The good news, in Objective-C 2.0, we only need 1 more tree code. If we did do this, we'd have to put in a mandate, no more new tree codes (unless you rewrite the Objective or C++ FE to stop using a code). Thoughts? Is it rally worth trying to do this? What happens when we need 1 more unique (wrt tree_contains_struct) code for Objective-C?
gcc-4.1-20070312 is now available
Snapshot gcc-4.1-20070312 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070312/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 122870 You'll find: gcc-4.1-20070312.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070312.tar.bz2 C front end and core compiler gcc-ada-4.1-20070312.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070312.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070312.tar.bz2 C++ front end and runtime gcc-java-4.1-20070312.tar.bz2 Java front end and runtime gcc-objc-4.1-20070312.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070312.tar.bz2The GCC testsuite Diffs from 4.1-20070305 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Updating libtool in GCC and srctree
> So, you need to run aclocal with: > $ aclocal -I ../config -I .. > > -- > albert chin ([EMAIL PROTECTED]) Thanks, that helps a lot. For libstdc++-v3 I actually needed "-I ." as well in order to find linkage.m4 so maybe "-I . -I .. -I ../config" is the best option list to use on aclocal calls in the GCC tree. libjava is the only subdir I can't seem to get configured with the new libtool: $ aclocal -I . -I .. -I ../config $ autoconf configure:15448: error: possibly undefined macro: AM_PROG_GCJdnl If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. I am not sure why I get this, nothing else seems to be requiring m4_pattern_allow. If I don't use any -I options on aclocal it works and then I get a different error from autoconf (about TL_AC_GXX_INCLUDE_DIR being possibly undefined). I think I want the -I options though. Steve Ellcey [EMAIL PROTECTED]
Re: We're out of tree codes; now what?
On 3/12/07, Mike Stump <[EMAIL PROTECTED]> wrote: That said, we all realize we are _not_ asking Doug to please re-implement the C++ frontend to our design to fix this issue. I'd be against that. Thank you :) I'm hoping that might allow us to reduce the pressure enough so that we can fit back down into 8 bits, so as to avoid the memory size increase and (the unmeasured) slowdowns that would result. Objective- C/C++ would slow down, but, faced with the slowdown that would be certain if we didn't do this, I don't see how we could not. The benefit, all other languages would not, which is still important to us. The good news, in Objective-C 2.0, we only need 1 more tree code. If we did do this, we'd have to put in a mandate, no more new tree codes (unless you rewrite the Objective or C++ FE to stop using a code). That's the trick... I don't see how we're going to get away with not adding some more tree codes to the C++ FE to support C++0x features. I'll see if I can implement the 9-bit solution, to see what the actual performance impact is. Cheers, Doug
Re: We're out of tree codes; now what?
On 3/12/07, Mike Stump <[EMAIL PROTECTED]> wrote: On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote: > When I said, let's support Doug, I meant let's support Doug from a > *practical* point of view. Either we suggest something doable with > a realistically sized effort or a little larger and at the same > time we volunteer to actually do it. In my opinion, "visions" for a > better future do not help here. I'd disagree. It is nice to have a stated idea of where we want to go, even if we can't get there today. We can measures patch goodness by how closely each patch moves us in that direction. That said, we all realize we are _not_ asking Doug to please re-implement the C++ frontend to our design to fix this issue. I'd be against that. Making C++ use a few tree codes (a la the back end) and burying the `extended' code in the C++ frontend sounds enticing, sounds like less work than redoing the FE to not use trees entirely and a step in the right direction. I checked the Objective-C frontend, it seems possible to do it as well. The tree_contains_struct stuff seems the `hardest' to get right, though, for Objective-C I think we could get by with 2 tree codes, maybe. Those that have TS_DECL_NON_COMMON, TS_DECL_WITH_VIS, TS_DECL_WRTL, TS_DECL_MINIMAL and TS_DECL_COMMON and those without? Feel free to make TS_ structs that do what you need, and use them. They correspond to the structs that are contained into each decl node in tree.h How the decl hiearchy is organized is explained in the docs, as well as how to add a new "subclass". For non-DECL nodes (or anything else), you'd want to make up your own TS_ stuff. (tree_contains_struct not only made the checking easy, it bought us some bits that were stored on every DECL tree, like whether it could contain RTL or not)
ACC Release V 0.5: Get Aspect-oriented through acc!
Hi, We are pleased to announce the release of AspeCt-oriented C (ACC) V 0.5, formerly known as AspectC. Besides some new features, the ACC 0.5 release also includes a set of experimental weave adapters that help integrate aspeCts in the build process of large C-based software projects. For more details and download, please visit http://www.aspectc.net. Highlights of ACC V 0.5 include: o ACC demo at AOSD'07 this week (Wednesday & Friday) o A set of experimental weave adapters to integrate ACC into large builds o Debugging support and improved error reporting o A set of course assignments applying ACC in the curriculum of a 3rd year Operating Systems course (available from our web site). We appreciate feedback and support for AspeCt-oriented C. Regards, ACC Team www.aspectc.net March 12, 2007
A request for your input.
Hello My name is Lara Thynne and I am a PhD candidate at Deakin University Australia. I am currently researching the boundary between work and leisure activities directly related to the open source community and open source program development. As part of this I am running a survey at the following address. https://dcarf.deakin.edu.au/surveys/oss/ The survey is completely confidential and looks at your views and motivations to use Open Source software and to participate in the community. It will only take a five to ten minutes to complete and your contact details will not be recorded. You can withdraw your participation at any stage. I sincerely apologize for the spammish nature of this e-mail - I don't mean to abuse this list. I am trying to collect responses from as many open source developers and users as possible and a mailing list like can be the only way to reach many developers. Thanks again Lara P.S The program that I am using is open source, of course (www.phpsurveyor.org)!
Re: A request for your input.
[EMAIL PROTECTED] wrote: I sincerely apologize for the spammish nature of this e-mail - I don't mean to abuse this list. I am trying to collect responses from as many open source developers and users as possible and a mailing list like can be the only way to reach many developers. FWIW, one option to avoid the spam nature in a situation like this is to email the list administrator privately and ask for permission to post an off-topic message. It's an interesting survey, though. - Brooks
PATCH: make_relative_prefix oddity
I've noticed some behavior with make_relative_prefix that surprised
me. In particular, consider this program:
#include
extern char * make_relative_prefix (const char *progname,
const char *bin_prefix,
const char *prefix);
int main () {
char *reloc;
reloc = make_relative_prefix ("/some/where/include/c++/4.2",
"/opt/foo/include/c++/4.2",
"/opt/foo");
printf ("%s\n", reloc);
}
I expected it to print:
/some/where/../../..
but, instead, it prints:
/some/where/include/c++/../../../../foo
It treats only "/opt" as a common component of the two paths, rathe
than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for
the last argument, the answer is as I expected. This seems odd to me;
is it the intended behavior?
The patch below (which is against an older version of libiberty, and
might need updating) fixes it. Assuming you agree that this is a bug,
would this patch (with updating and testing) be OK?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Index: libiberty/make-relative-prefix.c
===
--- libiberty/make-relative-prefix.c(revision 165621)
+++ libiberty/make-relative-prefix.c(working copy)
@@ -340,7 +340,23 @@ make_relative_prefix (const char *progna
n = (prefix_num < bin_num) ? prefix_num : bin_num;
for (common = 0; common < n; common++)
{
- if (strcmp (bin_dirs[common], prefix_dirs[common]) != 0)
+ const char *bin_dir;
+ const char *prefix_dir;
+ size_t bin_len;
+ size_t prefix_len;
+
+ /* Strip any trailing directory separators from the directories
+before comparing them. */
+ bin_dir = bin_dirs[common];
+ bin_len = strlen (bin_dir);
+ if (IS_DIR_SEPARATOR (bin_dir[bin_len - 1]))
+ --bin_len;
+ prefix_dir = prefix_dirs[common];
+ prefix_len = strlen (prefix_dir);
+ if (IS_DIR_SEPARATOR (prefix_dir[prefix_len - 1]))
+ --prefix_len;
+ if (strncmp (bin_dir, prefix_dir,
+ (bin_len > prefix_len) ? bin_len : prefix_len) != 0)
break;
}
GCC 4.2 branch snapshots disabled
As I'm now building GCC 4.2.0 RC1 (*), and am thereby beginning the release cycle for 4.2.0, I've disabled the 4.2 branch snapshots. It seems confusing to have both the prereleases (which I build) and the snapshots (which robots build) available simultaneously, and I would prefer to focus testing on the actual prereleases, as those are most likely to contain any defects that I might introduce into the actual release as well. (*) I guess this should really be Beta 1; it's not quite a release candidate, yet, in that I fully expect changes after this point. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Error in checking compat.exp
Hello,
I get the following error while running
make check-gcc RUNTESTFLAGS="compat.exp"
with mainline gcc version 4.3.0 20070312
on PPC.
Revital
=== g++ tests ===
Schedule of variations:
unix
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description
file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file
for target.
Using
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp
...
ERROR: tcl error sourcing
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
ERROR: couldn't open
"/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C":
no such file or directory
while executing
"open $file r"
(procedure "grep" line 19)
invoked from within
"grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line"
(procedure "dg-get-options" line 4)
invoked from within
"dg-get-options $src"
(procedure "compat-get-options" line 12)
invoked from within
"compat-get-options $src2"
(procedure "compat-execute" line 34)
invoked from within
"compat-execute $src $sid $use_alt"
("foreach" body line 7)
invoked from within
"foreach src [lsort [find $srcdir/$subdir *_main.C]] {
# If we're only testing specific files and this isn't one of them, skip
it.
if 