Re: use of %n in genmodes.c causes trouble on Vista
* Ian Lance Taylor:
> What is the security issue here?
The issue arrases in programs that pass attacker-controlled data as
the format string. They use
printf(some_string);
syslog(LOG_INFO, some_string);
instead of
printf("%s", some_string);
syslog(LOG_INFO, "%s", some_string);
The main point of this attack is to embed target addresses in the
format string and add conversion specifications so that "%n" picks up
these addresses. On a machine that supports unaligned memory
accesses, you can use a sequence of overlapping writes to put
arbitrary contents into arbitrary memory locations.
Re: use of %n in genmodes.c causes trouble on Vista
On Thu, Jun 07, 2007 at 10:36:43AM +0200, Florian Weimer wrote:
> * Ian Lance Taylor:
>
> > What is the security issue here?
>
> The issue arrases in programs that pass attacker-controlled data as
> the format string. They use
>
> printf(some_string);
> syslog(LOG_INFO, some_string);
>
> instead of
>
> printf("%s", some_string);
> syslog(LOG_INFO, "%s", some_string);
>
> The main point of this attack is to embed target addresses in the
> format string and add conversion specifications so that "%n" picks up
> these addresses. On a machine that supports unaligned memory
> accesses, you can use a sequence of overlapping writes to put
> arbitrary contents into arbitrary memory locations.
FYI, glibc limits %n as well in -D_FORTIFY_SOURCE=2 mode, though %n
is only barfed on if the format string containing it is in writable
memory. So
printf ("%s%n", some_string, &n);
or
printf (_("foo %s%n"), some_string, &n);
is ok even with -D_FORTIFY_SOURCE=2, but e.g.
char buf[20];
strcpy (buf, "%s%n");
printf (buf, some_string, &n);
will result with -D_FORTIFY_SOURCE=2 into immediate program termination.
This violates ISO C, but a) -D_FORTIFY_SOURCE=2 (unlike =1) is meant
to impose additional restrictions b) having %n in writable memory
is rarely needed (of course unless you are trying to exploit something)
Jakub
Re: use of %n in genmodes.c causes trouble on Vista
printf (_("foo %s%n"), some_string, &n);
is ok even with -D_FORTIFY_SOURCE=2
How is this considered ok? Is _("abc") placing the translation in
non-writable memory?
Paolo
Re: use of %n in genmodes.c causes trouble on Vista
On Thu, Jun 07, 2007 at 12:09:46PM +0200, Paolo Bonzini wrote:
>
> >printf (_("foo %s%n"), some_string, &n);
> >is ok even with -D_FORTIFY_SOURCE=2
>
> How is this considered ok? Is _("abc") placing the translation in
> non-writable memory?
Yes, the *.mo file is mmaped and gettext either returns the passed
pointer if no translation is found, or a pointer into the read-only
mmaping of the *.mo file.
Jakub
[rfc] Moving bbs back to pools
Hello,
as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html,
it might be a good idea to try moving cfg to alloc pools. The patch
below does that for basic blocks (each function has a separate pool
from that its basic blocks are allocated). At the moment, the patch
breaks precompiled headers, but otherwise bootstraps and passes
regtesting.
The problem is, that it does not give any speedups (it is almost
completely compile-time neutral for compilation of preprocessed
gcc sources). I will check whether moving also edges to pools
changes anything, but so far it does not seem very promising :-(
Zdenek
Index: doc/gty.texi
===
*** doc/gty.texi(revision 125526)
--- doc/gty.texi(working copy)
*** reachable. This routine should not chang
*** 292,297
--- 292,304
routine. Its only argument is a pointer to the just marked (const)
structure or union.
+ @findex custom_mark
+ @item custom_mark ("@var{marking-routine-name}")
+
+ If provided for a structure or union type, the given
+ @var{marking-routine-name} (between double-quotes) is the name of a
+ routine called to mark the object instead of ggc_set_mark.
+
@findex maybe_undef
@item maybe_undef
Index: gengtype.c
===
*** gengtype.c (revision 125526)
--- gengtype.c (working copy)
*** walk_type (type_p t, struct walk_type_da
*** 1916,1921
--- 1916,1923
desc = oo->info;
else if (strcmp (oo->name, "mark_hook") == 0)
;
+ else if (strcmp (oo->name, "custom_mark") == 0)
+ ;
else if (strcmp (oo->name, "nested_ptr") == 0)
nested_ptr_d = (const struct nested_ptr_data *) oo->info;
else if (strcmp (oo->name, "dot") == 0)
*** write_func_for_structure (type_p orig_s,
*** 2418,2423
--- 2420,2426
const char *chain_next = NULL;
const char *chain_prev = NULL;
const char *mark_hook_name = NULL;
+ const char *marker_routine = wtd->marker_routine;
options_p opt;
struct walk_type_data d;
*** write_func_for_structure (type_p orig_s,
*** 2437,2442
--- 2440,2449
chain_prev = opt->info;
else if (strcmp (opt->name, "mark_hook") == 0)
mark_hook_name = opt->info;
+ else if (strcmp (opt->name, "custom_mark") == 0
+/* FIXME -- this will break pch. */
+&& !wtd->param_prefix)
+ marker_routine = opt->info;
if (chain_prev != NULL && chain_next == NULL)
error_at_line (&s->u.s.line, "chain_prev without chain_next");
*** write_func_for_structure (type_p orig_s,
*** 2473,2479
s->kind == TYPE_UNION ? "union" : "struct", s->u.s.tag);
if (chain_next == NULL)
{
! oprintf (d.of, " if (%s (x", wtd->marker_routine);
if (wtd->param_prefix)
{
oprintf (d.of, ", x, gt_%s_", wtd->param_prefix);
--- 2480,2486
s->kind == TYPE_UNION ? "union" : "struct", s->u.s.tag);
if (chain_next == NULL)
{
! oprintf (d.of, " if (%s (x", marker_routine);
if (wtd->param_prefix)
{
oprintf (d.of, ", x, gt_%s_", wtd->param_prefix);
*** write_func_for_structure (type_p orig_s,
*** 2484,2490
}
else
{
! oprintf (d.of, " while (%s (xlimit", wtd->marker_routine);
if (wtd->param_prefix)
{
oprintf (d.of, ", xlimit, gt_%s_", wtd->param_prefix);
--- 2491,2497
}
else
{
! oprintf (d.of, " while (%s (xlimit", marker_routine);
if (wtd->param_prefix)
{
oprintf (d.of, ", xlimit, gt_%s_", wtd->param_prefix);
*** write_func_for_structure (type_p orig_s,
*** 2516,2523
oprintf (d.of, ");\n");
oprintf (d.of, "if (xprev == NULL) break;\n");
oprintf (d.of, "x = xprev;\n");
! oprintf (d.of, "(void) %s (xprev",
! wtd->marker_routine);
if (wtd->param_prefix)
{
oprintf (d.of, ", xprev, gt_%s_", wtd->param_prefix);
--- 2523,2529
oprintf (d.of, ");\n");
oprintf (d.of, "if (xprev == NULL) break;\n");
oprintf (d.of, "x = xprev;\n");
! oprintf (d.of, "(void) %s (xprev", marker_routine);
if (wtd->param_prefix)
{
oprintf (d.of, ", xprev, gt_%s_", wtd->param_prefix);
Index: final.c
===
*** final.c (revision 125526)
--- final.c (working copy)
*** rest_of_handle_final (void)
*** 3996,4004
if (! quiet_flag)
fflush (asm_out_file);
- /* Release all memory allocated by flow. */
- free_basic_block_vars ();
-
/* Write DBX symbols if requested. */
/* Note that for those i
Any interest in i586-pc-interix3 configuration improvements?
Is there anyone interested in i586-pc-interix3 (Interix 3.x) configuration improvements? I have just started a little work to update the configuration for recent GCC versions. If you have any interests, please let me know. -- XMPP (Jabber): [EMAIL PROTECTED] .NET Messenger: [EMAIL PROTECTED]
Re: A problem with the loop structure
Hi, The problem with the ICE after the loop versioning in SMS was caused because the header of the versioned loop was at the same time the latch of the outer loop. After the versioning the nodes of the newly created loop could not be accessed by a DFS traversal of the outer loop starting from its latch (header of the versioned loop), leading to the ICE on assert that the number of nodes reported by DFS is nloop->outer->num_nodes. Solution (for the case of the call in SMS): call canon_loop(loop->outer) before the call to versioning in the sms_schedule so that a new empty latch is created for the outer loop. Thanks, Vladimir On 5/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, > ii) > In loop_version there are two calls to loop_split_edge_with > 1. loop_split_edge_with (loop_preheader_edge (loop), NULL); > 2. loop_split_edge_with (loop_preheader_edge (nloop), NULL); > nloop is the versioned loop, loop is the original. > > loop_split_edge_with has the following: > new_bb = split_edge (e); > add_bb_to_loop (new_bb, loop_c); > > 1) When we get to the fist call, nloop->outer->num_nodes = 8 while dfs > returns 6. then the problem is before this call; you need to check which two blocks that are marked as belonging to nloop->outer in fact do not belong to this loop, and why. Zdenek
Re: [rfc] Moving bbs back to pools
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html, it might be a good idea to try moving cfg to alloc pools. The patch below does that for basic blocks (each function has a separate pool from that its basic blocks are allocated). At the moment, the patch breaks precompiled headers, but otherwise bootstraps and passes regtesting. The problem is, that it does not give any speedups (it is almost completely compile-time neutral for compilation of preprocessed gcc sources). It was mainly on sources that allocate a lot of bb's that this mattered. If you have a small number of bb's, it just doesn't matter how you allocate them. None of the gcc sources (except for insn-*) ever end up with that many basic blocks.
Re: libjava is a train wreck.
On 6/6/07, Ben Elliston <[EMAIL PROTECTED]> wrote: On Wed, 2007-06-06 at 08:29 -0400, Diego Novillo wrote: > You should not have conflicts in libjava. You may have botched a merger > earlier. I never ran into this with the branches I've maintained. Try > copying libjava out of trunk again. Out of interest, what happens if you have svn file properties that are changed in both branches? Will that lead to a merge conflict? If by "file properties" you mean svn properties, then yes, it will lead to a conflict that needs resolving.
Re: use of %n in genmodes.c causes trouble on Vista
Florian Weimer <[EMAIL PROTECTED]> writes:
> The issue arrases in programs that pass attacker-controlled data as
> the format string. They use
>
> printf(some_string);
> syslog(LOG_INFO, some_string);
>
> instead of
>
> printf("%s", some_string);
> syslog(LOG_INFO, "%s", some_string);
>
> The main point of this attack is to embed target addresses in the
> format string and add conversion specifications so that "%n" picks up
> these addresses. On a machine that supports unaligned memory
> accesses, you can use a sequence of overlapping writes to put
> arbitrary contents into arbitrary memory locations.
This is off-topic, but:
There are many other difficulties when the attacker can control the
format string, so that is what should be prevented, which you can do
with compiler analysis and runtime checks.
At the very least there should be a compiler option for standard
conformant behaviour in this area. I didn't see one in the MSDN docs.
I would say that gets is much more dangerous than %n in printf, but
presumably Microsoft does not disable gets.
Ian
hash_rtx and volatile subexpressions
Hello,
I would like to use some sort of hashing to speed up searching for an
insn in an availability set in the selective scheduler. It seems
natural using hash_rtx for this purpose. However, hash_rtx will not
hash any volatile subexpressions, returning 0 in this case. This is
fine by me, but together with the recursion optimization it has near
line 2345...
for (; i >= 0; i--)
{
switch (fmt[i])
...
/* If we are about to do the last recursive call
needed at this level, change it into iteration.
This function is called enough to be worth it. */
if (i == 0)
{
x = XEXP (x, i);
goto repeat;
}
...one does not get a hash e.g. for any conditional jump like
(set (pc)
(if_then_else (ne (reg:BI 262 p6 [360])
(const_int 0 [0x0]))
(label_ref:DI 191)
(pc)))
...because the pc subexpression is always the first one, and the
recursive call for it gets optimized by the above code, which results in
a zero hash for the whole pattern.
Is this intentional, or do we want to have 'return hash;' instead of
'return 0;' in all places when *do_not_record_p is set to 1? Is there a
better hash_rtx somewhere, which I don't know about?
Andrey
Re: use of %n in genmodes.c causes trouble on Vista
> I would say that gets is much more dangerous than %n in printf, but > presumably Microsoft does not disable gets Actually, for gets, and essentially the entire stdio.h, Visual Studio 2005 generates: warning C4996: 'gets': This function or variable may be unsafe. Consider using gets_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. - Matt
Re: [rfc] Moving bbs back to pools
Zdenek Dvorak <[EMAIL PROTECTED]> writes: > The problem is, that it does not give any speedups (it is almost > completely compile-time neutral for compilation of preprocessed > gcc sources). I will check whether moving also edges to pools > changes anything, but so far it does not seem very promising :-( Does it make any difference for gcc.c-torture/compile/20001226-1.c? And of course it won't make any difference if you have enough memory that you never need to garbage collect without your patch. I would like to see us implement this general GC approach even if we don't wind up moving the basic blocks into it today. But we'll have to figure out what to do for PCH. I guess the general approach would be to provide an optional swizzling routine as well as the marking routine. Then abort if gt_pch_save finds an object with a marking routine but no swizzling routine. The swizzling routine would do something involving gt_pch_note_object and/or relocate_ptrs. Or maybe we would need two routines, one to note and one to relocate. Ian
Re: hash_rtx and volatile subexpressions
Andrey Belevantsev <[EMAIL PROTECTED]> writes: > Is this intentional, or do we want to have 'return hash;' instead of > 'return 0;' in all places when *do_not_record_p is set to 1? Is there > a better hash_rtx somewhere, which I don't know about? It should be fine to "return hash" instead of "return 0" in those cases. Give that a try. Ian
Re: use of %n in genmodes.c causes trouble on Vista
Matt Fago <[EMAIL PROTECTED]> writes: > > I would say that gets is much more dangerous than %n in printf, but > > presumably Microsoft does not disable gets > > Actually, for gets, and essentially the entire stdio.h, Visual Studio 2005 > generates: > > warning C4996: 'gets': This function or variable may be unsafe. Consider > using gets_s instead. To disable deprecation, use > _CRT_SECURE_NO_WARNINGS. See online help for details. Sure, glibc issues a warning too. But issuing a warning is very different from disabling. Apparently Visual Studio does not warn about %n; it simply disables it. Ian
Re: [rfc] Moving bbs back to pools
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > Zdenek Dvorak <[EMAIL PROTECTED]> writes: > > > The problem is, that it does not give any speedups (it is almost > > completely compile-time neutral for compilation of preprocessed > > gcc sources). I will check whether moving also edges to pools > > changes anything, but so far it does not seem very promising :-( > > Does it make any difference for gcc.c-torture/compile/20001226-1.c? > And of course it won't make any difference if you have enough memory > that you never need to garbage collect without your patch. I was wrong to say that. It could make a difference even if you don't garbage collect, since the allocation will be cheaper. But that is likely to be a relatively small effect. Ian
Re: PATCH COMMITTED: Don't break tests for enum in range
[Moved to gcc list from gcc-patches].
> > So now objects can have values outside of their type?
>
> If we accept that it is correct that TYPE_PRECISION is not synonymous
> with TYPE_MIN_VALUE and TYPE_MAX_VALUE, then, yes, objects can have
> values outside of their type (isn't that the whole point of
> check'valid, or whatever it is called?).
As you say, I think we need to define the *precise* semantics of what it
means if a value of a variable is outside the range of TYPE_{MIN,MAX}_VALUE.
The simplest example of that is an uninitialized variable.
It can conceivably mean a number of things:
(1) The effect of such a value is undefined and the compiler may assume
any consequences when this occurs.
(2) The compiler can treat the variable as having any value in the range
given by its TYPE_PRECISION that is convenient, but need not choose the same
value every time.
(3) The same as (2) except that the same value must be chosen every
time (for example the actual value or one of the bounds).
I think the best approach is to use flags set by the front end to indicate
which of these is to be the case. For C, I believe (1) is always the
proper meaning. I don't know what it is for C++, Fortran, and Java. For
Ada, (3) is the normal case, but there are many situation where the front
end can prove that (2) or (1) is acceptable.
Re: [rfc] Moving bbs back to pools
Hello, > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > Zdenek Dvorak <[EMAIL PROTECTED]> writes: > > > > > The problem is, that it does not give any speedups (it is almost > > > completely compile-time neutral for compilation of preprocessed > > > gcc sources). I will check whether moving also edges to pools > > > changes anything, but so far it does not seem very promising :-( > > > > Does it make any difference for gcc.c-torture/compile/20001226-1.c? > > And of course it won't make any difference if you have enough memory > > that you never need to garbage collect without your patch. > > I was wrong to say that. It could make a difference even if you don't > garbage collect, since the allocation will be cheaper. But that is > likely to be a relatively small effect. actually, the expected speedup was mostly supposed to come from better locality. The speed of garbage collection should be about unchanged. Regarding the speed of allocation, pool_alloc might be slightly faster, but probably not significantly. Zdenek
DWARF-2 unwinder versus MIPS n32
I'm trying to track down why unwinding through a signal frame crashes on MIPS n32. David, I'm pretty sure you introduced the crash here: 2006-11-20 David Daney <[EMAIL PROTECTED]> * config/mips/linux-unwind.h (mips_fallback_frame_state): Adjust PC to point to following instruction. There's two problems with this patch. One is that it's just broken for N64; you're loading the PC as a u_int32_t. The other is that it triggers an assertion in the unwinder for n32. _Unwind_SetGRValue does this: 258 gcc_assert (dwarf_reg_size_table[index] == sizeof (_Unwind_Ptr)); 259 260 context->by_value[index] = 1; 261 context->reg[index] = (void *) (_Unwind_Internal_Ptr) val; context->reg[index] is a void *. On N32, general registers are 64-bit but pointers are 32-bit. So if we get here, the assertion is almost sure to trigger. REG_SAVED_VAL_OFFSET brings us here. Does anyone see a way to fix this that doesn't involve making context->reg big enough - and is _Unwind_Word always at least as large as _Unwind_Ptr (i.e. mode(word) always at least as large as mode(pointer))? -- Daniel Jacobowitz CodeSourcery
Re: PATCH COMMITTED: Don't break tests for enum in range
On 6/7/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
[Moved to gcc list from gcc-patches].
> > So now objects can have values outside of their type?
>
> If we accept that it is correct that TYPE_PRECISION is not synonymous
> with TYPE_MIN_VALUE and TYPE_MAX_VALUE, then, yes, objects can have
> values outside of their type (isn't that the whole point of
> check'valid, or whatever it is called?).
As you say, I think we need to define the *precise* semantics of what it
means if a value of a variable is outside the range of TYPE_{MIN,MAX}_VALUE.
The simplest example of that is an uninitialized variable.
It can conceivably mean a number of things:
(1) The effect of such a value is undefined and the compiler may assume
any consequences when this occurs.
(2) The compiler can treat the variable as having any value in the range
given by its TYPE_PRECISION that is convenient, but need not choose the same
value every time.
(3) The same as (2) except that the same value must be chosen every
time (for example the actual value or one of the bounds).
I think the best approach is to use flags set by the front end to indicate
which of these is to be the case. For C, I believe (1) is always the
proper meaning. I don't know what it is for C++, Fortran, and Java. For
Ada, (3) is the normal case, but there are many situation where the front
end can prove that (2) or (1) is acceptable.
Note that types that have TYPE_MIN/MAX_VALUE different from the
natural values defined by the types signedness and precision also ask
for defining what happens if arithmetic on them is allowed. And if
it is allowed, what the semantics for overflow are. And even more
interesting, how to represent for example a + 1 for a of type int with
a range of [5, 10] -- note that 1 is _not_ in that range.
So, the most obvious answer to these points is that arithmetic is
always performed in a type where TYPE_MIN/MAX_VALUE is
naturally defined and so we can rely on two's complement arithmetic.
The question that is retained is, when we expose types with non-natural
TYPE_MIN/MAX_VALUE to the middle-end, how do we handle
conversions between the "base" and the "derived" type. Is it
value-preserving, even if the value is outside of the "derived" types
bounds? If not, how is it "truncated"?
(1) conversion is only defined if the result is within the target types range?
(this is what we assume now in VRP, if you don't use VIEW_CONVERT_EXPR)
(2) truncation happens explicitly (that is what we obviously don't want)
(3) we all values in the base types range, even for the derived type (this
is what we get with VIEW_CONVERT_EXPR now)
So from the last discussion(s) we agreed it only makes sense to define
arithmetic in "base" types. We also agreed to the current state of
using (1) for conversions.
Of course all previous discussion only mattered to Ada and 'Valid, but
as we see now it obviously applies to types from other frontends as well,
iff they set TYPE_MIN/MAX_VALUE to non-natural values.
Richard.
Re: [rfc] Moving bbs back to pools
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > Zdenek Dvorak <[EMAIL PROTECTED]> writes: > > > > > The problem is, that it does not give any speedups (it is almost > > > completely compile-time neutral for compilation of preprocessed > > > gcc sources). I will check whether moving also edges to pools > > > changes anything, but so far it does not seem very promising :-( > > > > Does it make any difference for gcc.c-torture/compile/20001226-1.c? > > And of course it won't make any difference if you have enough memory > > that you never need to garbage collect without your patch. > > I was wrong to say that. It could make a difference even if you don't > garbage collect, since the allocation will be cheaper. But that is > likely to be a relatively small effect. actually, the expected speedup was mostly supposed to come from better locality. The speed of garbage collection should be about unchanged. Regarding the speed of allocation, pool_alloc might be slightly faster, but probably not significantly. If you never gc collect, you will never reuse gc pages, and you will mostly have okay locality, since *most* bb's are allocated when we initially create the cfg.
Re: [rfc] Moving bbs back to pools
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > Zdenek Dvorak <[EMAIL PROTECTED]> writes: > > > > > The problem is, that it does not give any speedups (it is almost > > > completely compile-time neutral for compilation of preprocessed > > > gcc sources). I will check whether moving also edges to pools > > > changes anything, but so far it does not seem very promising :-( > > > > Does it make any difference for gcc.c-torture/compile/20001226-1.c? > > And of course it won't make any difference if you have enough memory > > that you never need to garbage collect without your patch. > > I was wrong to say that. It could make a difference even if you don't > garbage collect, since the allocation will be cheaper. But that is > likely to be a relatively small effect. actually, the expected speedup was mostly supposed to come from better locality. The speed of garbage collection should be about unchanged. Regarding the speed of allocation, pool_alloc might be slightly faster, but probably not significantly. Uh, structures as big as basic_block won't get better locality by placing them near each other. But maybe I'm missing something ;) Richard.
Re: [rfc] Moving bbs back to pools
On 6/7/07, Richard Guenther <[EMAIL PROTECTED]> wrote: On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > Hello, > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > > > Zdenek Dvorak <[EMAIL PROTECTED]> writes: > > > > > > > The problem is, that it does not give any speedups (it is almost > > > > completely compile-time neutral for compilation of preprocessed > > > > gcc sources). I will check whether moving also edges to pools > > > > changes anything, but so far it does not seem very promising :-( > > > > > > Does it make any difference for gcc.c-torture/compile/20001226-1.c? > > > And of course it won't make any difference if you have enough memory > > > that you never need to garbage collect without your patch. > > > > I was wrong to say that. It could make a difference even if you don't > > garbage collect, since the allocation will be cheaper. But that is > > likely to be a relatively small effect. > > actually, the expected speedup was mostly supposed to come from better > locality. The speed of garbage collection should be about unchanged. > Regarding the speed of allocation, pool_alloc might be slightly faster, > but probably not significantly. Uh, structures as big as basic_block won't get better locality by placing them near each other. But maybe I'm missing something ;) They did when we took a couple percent slowdown from moving them to GC. See the patch that did it :) Though i think they were smaller then :) Edges were also pool alloc'd, and i believe both were switched at the same time, so it's possible the locality came from the edges.
Re: DWARF-2 unwinder versus MIPS n32
Daniel Jacobowitz wrote: I'm trying to track down why unwinding through a signal frame crashes on MIPS n32. David, I'm pretty sure you introduced the crash here: 2006-11-20 David Daney <[EMAIL PROTECTED]> * config/mips/linux-unwind.h (mips_fallback_frame_state): Adjust PC to point to following instruction. I don't doubt that there are problems here. I was going to clean up the compiler warnings that are now generated in that code, but it looks like more major work is needed. There's two problems with this patch. One is that it's just broken for N64; you're loading the PC as a u_int32_t. The other is that it triggers an assertion in the unwinder for n32. _Unwind_SetGRValue does this: 258 gcc_assert (dwarf_reg_size_table[index] == sizeof (_Unwind_Ptr)); 259 260 context->by_value[index] = 1; 261 context->reg[index] = (void *) (_Unwind_Internal_Ptr) val; context->reg[index] is a void *. On N32, general registers are 64-bit but pointers are 32-bit. So if we get here, the assertion is almost sure to trigger. REG_SAVED_VAL_OFFSET brings us here. Does anyone see a way to fix this that doesn't involve making context->reg big enough - and is _Unwind_Word always at least as large as _Unwind_Ptr (i.e. mode(word) always at least as large as mode(pointer))? The main problem I have is that when I wrote the original MD_FALLBACK_FRAME_STATE_FOR I only had a mipsel-linux machine for testing. You added support for big-endian, but that it ever worked for n32 and n64 is pure luck. I continue to have the limitation of only being able to test on mipsel-linux, so it is unlikely that I will be able to help here. I have never tried running the qemu linux systems. Do you know if it currently supports 64bit? If so I will fix it, otherwise all I can do is wait for 64bit hardware to magically appear on my door step. David Daney
RE: testsuite trigraphs.c failure due to cygwin
On 06 June 2007 14:35, Tim Prince wrote: > I have patched stdio.h, but it may not be your latest recommendation. This does indeed turn out to be the problem. In your local patched stdio.h you have: #if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__) #define ELIDABLE_INLINE extern inline #else #define ELIDABLE_INLINE inline #endif which isn't valid in the case of -ansi. The patch as actually applied has: #if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__) /* We're using GCC, but without the new C99-compatible behaviour. */ #define _ELIDABLE_INLINE extern __inline__ _ATTRIBUTE ((__always_inline__)) #else /* We're using GCC in C99 mode, or an unknown compiler which we just have to hope obeys the C99 semantics of inline. */ #define _ELIDABLE_INLINE __inline__ #endif and for the reasons why, see: http://sourceware.org/ml/newlib/2007/msg00295.html http://sourceware.org/ml/newlib/2007/msg00296.html http://sourceware.org/ml/newlib/2007/msg00326.html Tim, please try replacing your hand-patched stdio.h with the version from newlib cvs HEAD and test again; I believe this will fix your problem. cheers, DaveK -- Can't think of a witty .sigline today
Re: DWARF-2 unwinder versus MIPS n32
David Daney wrote: Daniel Jacobowitz wrote: I'm trying to track down why unwinding through a signal frame crashes on MIPS n32. David, I'm pretty sure you introduced the crash here: 2006-11-20 David Daney <[EMAIL PROTECTED]> * config/mips/linux-unwind.h (mips_fallback_frame_state): Adjust PC to point to following instruction. I don't doubt that there are problems here. I was going to clean up the compiler warnings that are now generated in that code, but it looks like more major work is needed. I might add that something like this patch is required. The PC must be incremented so that proper unwinding is obtained if the fault occurs on the first instruction of a function. Before this patch there was a special o32 only hack in libgcj that adjusted the value of the PC in the sigcontext saved on the stack before calling the unwinder. The idea was to place all the code needed to unwind through signal frames into MD_FALLBACK_FRAME_STATE_FOR. David Daney
Re: DWARF-2 unwinder versus MIPS n32
On Thu, Jun 07, 2007 at 08:54:09AM -0700, David Daney wrote: > The main problem I have is that when I wrote the original > MD_FALLBACK_FRAME_STATE_FOR I only had a mipsel-linux machine for testing. > You > added support for big-endian, but that it ever worked for n32 and n64 is pure > luck. Well, not quite. I tested that it worked and would have fixed it before now if it did not :-) > I have never tried running the qemu linux systems. Do you know if it > currently > supports 64bit? If so I will fix it, otherwise all I can do is wait for > 64bit > hardware to magically appear on my door step. No, qemu has 64-bit support but I don't think it's mature enough to boot a Linux kernel yet. It might be; Thiemo and Aurelien were working on it. -- Daniel Jacobowitz CodeSourcery
[mingw] arm-elf-gcc build error with fixincludes file error
Hi,
I am compiling arm-elf-gcc using mingw on Windows XP through msys, and
although the C compiler compiles there is output near the end, which
includes a file error for fixincludes. The file doesn't exist after the
build.
...
sed: Couldn't open file C:\Temp\fxinc2;
FS error 2 (No such file or directory) reopening 'math.h' as stdin
sed: -e expression #10, char 39: Unterminated `s' command
sed: read error on {standard input}: Bad file number
Applying sun_malloc to malloc.h
Applying broken_cabs to math.h
Applying sysv68_stringto string.h
Applying stdio_va_list_clientsto wchar.h
...
When I try and run the compiler tests with make -k check I get the
following output:
...
$ make -k check
make[1]: Entering directory `/mingw/src/build-gcc'
make[2]: Entering directory `/mingw/src/build-gcc/fixincludes'
autogen -T ../../gcc-4.1-20070604/fixincludes/check.tpl
../../gcc-4.1-20070604/fixincludes/inclhack.def
/bin/sh ./check.sh ../../gcc-4.1-20070604/fixincludes/tests/base
FS error 2 (No such file or directory) reopening 'testing.h' as stdin
sed: -e expression #10, char 39: Unterminated `s' command
FS error 2 (No such file or directory) reopening 'testing.h' as stdin
sed: -e expression #10, char 39: Unterminated `s' command
FS error 2 (No such file or directory) reopening 'AvailabilityMacros.h'
as stdin
FS error 2 (No such file or directory) reopening 'X11/ShellP.h' as stdin
FS error 2 (No such file or directory) reopening 'X11/Xmu.h' as stdin
...
So I can't test the patch that I was previously enquiring about. The
trouble is, I cannot find any reference to sed commands which are
generating the errors - I just don't know where to start looking for
clues. Can anyone suggest where to start looking?
Make -k check finally exits with:
...
/bin/sh: runtest: command not found
make[2]: [check-gcc] Error 127 (ignored)
make[2]: Leaving directory `/mingw/src/build-gcc/gcc'
make[2]: Entering directory `/mingw/src/build-gcc/intl'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/mingw/src/build-gcc/intl'
make[2]: Entering directory `/mingw/src/build-gcc/libcpp'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/mingw/src/build-gcc/libcpp'
make[2]: Entering directory `/mingw/src/build-gcc/libiberty'
make[3]: Entering directory `/mingw/src/build-gcc/libiberty/testsuite'
./test-demangle <
../../../gcc-4.1-20070604/libiberty/testsuite/demangle-expected
c:\msys\1.0\mingw\src\build-gcc\libiberty\testsuite\test-demangle.exe:
748 tests, 0 failures
./test-pexecute
make[3]: Leaving directory `/mingw/src/build-gcc/libiberty/testsuite'
make[2]: Leaving directory `/mingw/src/build-gcc/libiberty'
make[1]: Target `check-host' not remade because of errors.
make[1]: Nothing to be done for `check-target'.
make[1]: Leaving directory `/mingw/src/build-gcc'
make: *** [do-check] Error 2
make: Target `check' not remade because of errors.
...
Any pointers are much appreciated!
Best Regards,
Brian Sidebotham.
Re: PATCH COMMITTED: Don't break tests for enum in range
> So, the most obvious answer to these points is that arithmetic is > always performed in a type where TYPE_MIN/MAX_VALUE is > naturally defined and so we can rely on two's complement arithmetic. Right. In the Ada case, that's required by the language anyway. > The question that is retained is, when we expose types with non-natural > TYPE_MIN/MAX_VALUE to the middle-end, how do we handle > conversions between the "base" and the "derived" type. Is it > value-preserving, even if the value is outside of the "derived" types > bounds? If not, how is it "truncated"? I think it goes to the same question as before, which is what's meant if the value is out of range. The answer to that question (which I tried to propose a solution to in my last email) is the answer to this one, the way I see it.
TeX sources for tuples document uploaded to the wiki
Since we've been making random changes to the document as the implementation comes along, it's easier if we put the source code on the wiki. Eventually this document will be turned into texinfo format and put in gcc/doc, but for now this seems easier. Please make sure you send me patches if you modify the document. I'm keeping the master copy on my machine. Thanks.
RE: use of %n in genmodes.c causes trouble on Vista
Ian Lance Taylor Friday, 8 June 2007 1:52 a.m. > > At the very least there should be a compiler option for standard > conformant behaviour in this area. I didn't see one in the MSDN docs. > I would say that gets is much more dangerous than %n in printf, but > presumably Microsoft does not disable gets. > The MSVCRT version of printf is non-conformant in several ways. In addition to the new '%n' behaviour, there is the old problems with the requirement to use 'I64' format flag in place of 'll', failure to handle long double, non-C99-conformant return value for vsnprintf. I believe that thef first two of these are represented by open GCC Bugzilla PR's. A GCC target option (say, -malt-ISO-printf) for mingw that causes calls to printf family to be mapped to a mingw_printf, mingw_snprintf, etc is one possibilty. I have an experimntal a ISO-C99 compliant mingw_vsnprintf that I was planning to contribute to mingw's libmingex.a runtime extension library. The main reason for writing this was to allow long double output in libstdc++ and libgfortran. Wrapping that in _set_printf_count_output (or adding a ctor that calls _set_printf_count_output to a new startfile object) if we are using Vista's MSVCRT.dll would avoid this problem in genmodes. Although, the alternate versions of *printf could be enabled in other ways, having a compiler switch take care of it would be nice. Danny > Ian >
Re: [OT] Re: Git repository with full GCC history
On 6/4/07, David Woodhouse <[EMAIL PROTECTED]> wrote: On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote: > If I can reproduce it I'll see if I can find some webspace. I figured out my operator error with git gc. The final results of a repository holding a clone of trunk: Size of git packs: pack + index - 286344kB git svn metadata - nearly 13MB, allows incremental updates as more commits made in svn. I'm in touch with David getting some space to upload it. Cheers, Harvey Harrison
Writing to Subversion via Git
As an aside to the ongoing git repository discussion, I'm curious if anyone has experimented with committing changes to the GCC repository via git-svn's dcommit command. I'm curious to know if it plays nicely with GCC's svn commit machinery. Ollie
Re: Fixed-point branch?
Fu, Chao-Ying wrote: > I attached a diff file for 14 files of the new structures > and documents. You and other maintainers are welcome to > check it. Thanks a lot! Thank you for posting this. Things about which I am clueless: What is the difference between a _Fract type and an _Accum type? I'm gathering that _Fract types have no integer part, i.e., they always represent a number between (-1,1), whereas _Accum types contain both an integer and a fractional part. Is there any other difference? Substantive issues: + unsigned saturating_flag : 1; /* FIXME. This new flag increases the size of + tree_common by a full word. */ We need to fix that, if it's true. Grab a bit out of tree_base::spare, if need be. + /* Fixed-point types. */ + if (targetm.fixed_point_supported_p ()) I thought there was an emulation library for fixed-point operations? So, why would this be supported only on some targets? Is there a harm in supporting it everywhere? If there is, should it be enabled per-target, or via a configure-time option? I don't see any constant-folding code for fixed-point; is there no need for that? Is it somewhere else in the codebase? Stylistic points: Every function needs a comment saying what it does, what every argument is, and what the return value is. You have some new functions that are missing comments. + fixed-point <- real, Please write as "real to fixed point" to avoid ambiguity with the errors. +DEF_RTL_EXPR(FIXED_ALL, "fixed_all", "e", RTX_UNARY) Why FIXED_ALL? That doesn't seem mnemonic. > + sat_short_fract_type_node = make_sat_signed_fract_type > (SHORT_FRACT_TYPE_SIZE); > + sat_fract_type_node = make_sat_signed_fract_type (FRACT_TYPE_SIZE); > + sat_long_fract_type_node = make_sat_signed_fract_type > (LONG_FRACT_TYPE_SIZE); > + sat_long_long_fract_type_node = make_sat_signed_fract_type > (LONG_LONG_FRACT_TYPE_SIZE); Can we macroize some of this goo? There are several places in the patch where you have very long sequences of types, modes, etc. I would hope that by naming things consistently, we might be able to compact this a lot, and reduce the chance that we've got something wrong in just one place. Like: #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \ set_##WIDTH_##KIND_type_node = make_##SAT_... and then: #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \ MAKE_FIXED_TYPE_NODE(_short, KIND); \ MAKE_FIXED_TYPE_NODE(_, KIND); \ MAKE_FIXED_TYPE_NODE(_long, KIND); \ MAKE_FIXED_TYPE_NODE(_long_long, KIND); and then: MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract); MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum); etc. That's not right, but you get the idea. :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [OT] Re: Git repository with full GCC history
Harvey Harrison wrote: The final results of a repository holding a clone of trunk: With or without branches? (shouldn't matter that much, just for the record) Size of git packs: pack + index - 286344kB git svn metadata - nearly 13MB, allows incremental updates as more commits made in svn. That's great, but... could you tell us how you did it? -- // Bernardo Innocenti \X/ http://www.codewiz.org/
GCC 4.3.0 Status Report (2007-06-07)
I am aware of three remaining projects which are or might be appropriate for Stage 1: * Dataflow branch. Kenny et. al. plan to merge this Monday. * PTR_PLUS branch. I believe that this branch should be included in GCC 4.3. Andrew, would you please update me as to its status? In particular, are there any regressions on primary or secondary targets at this point? * Fixed-point branch. I've looked at the general infrastructure for this branch. While I have some questions and/or concerns, it appears to me that the changes I reviewed are unlikely to affect anything except fixed-point. In other words, the only risk is that the quality of the fixed-point code itself is unsatisfactory, in which case we can always disable it in 4.3. Therefore, I'm inclined to include this branch as well. Are there any objections to that course of action? In the interests of moving forwards, I therefore plan to close this exceptionally long Stage 1 as of next Friday, June 15th. The projects named above may be merged, even though we will be in Stage 2 -- but no other functionality of Stage 1 scope may be included after this point. I am also considering a "lockdown" period beginning June 15th during which we would go into a regressions-only mode (other than possible merges of the functionality above) in order to begin eliminating some of the problems that have come in with the exciting new infrastructure. Any comments on that course of action? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: [...] In the interests of moving forwards, I therefore plan to close this exceptionally long Stage 1 as of next Friday, June 15th. The projects named above may be merged, even though we will be in Stage 2 -- but no other functionality of Stage 1 scope may be included after this point. An additional project, which is not on your list and perhaps should be: Several members of the GFortran team (primarily Chris Rickett and Steve Kargl) have been working on a project to add the BIND(C) functionality from the Fortran 2003 standard. This provides for a standard means of linking Fortran code with code that uses standard C linkage conventions, as well as adding some other useful features. This work has been done on the "fortran-experiments" branch; my impression is that it is essentially ready to go into the review process, though there may be some small final bits of debugging remaining to be done. I've cc'ed this to the fortran@ list for comment from the people working on it. I don't believe this project has been documented very well (if at all) on the standard Wiki page for Stage-1 projects, but I haven't looked at it in a while. I am also not entirely certain whether this qualifies as a Stage 1 or a Stage 2 project, since it produces fairly pervasive changes but only within the Fortran front end (and libgfortran library); however, the assumption on the Fortran list has been that it ought be merged during the Stage 1 period. In any case, I very strongly believe that this should be included in 4.3, and would hope that if the review process takes a couple of weeks that it can still be merged in. I am also considering a "lockdown" period beginning June 15th during which we would go into a regressions-only mode (other than possible merges of the functionality above) in order to begin eliminating some of the problems that have come in with the exciting new infrastructure. Any comments on that course of action? IMO, for the Fortran front end, "regressions-only" is an inappropriate criterion for this sort of mode, given that the front end does not have a long history for the wrong-code and ICE-on-valid bugs to be regressions against. Thus, at least for the Fortran front end, I think that a "wrong-code, ICE, and regressions" limit is much more appropriate, with an understanding that the spirit of the thing is to avoid large risky patches even if they meet the letter of that criterion. However, with that caveat (and with the presumption that the BIND(C) projects gets merged in), from a Fortran perspective I would agree that this is a good idea; the bug numbers have been creeping upwards of late, and could use a coordinated effort at reductions. - Brooks
