Re: A doubt about constraint modifiers

[Ian Lance Taylor]

"Mohamed Shafi" <[EMAIL PROTECTED]> writes:

> I have noticed that when strict_low_part is used in a patten we need
> to use '+' as the constraint modifier if any constraints are used in
> the patterns.
> Why is this so?

Using strict_low_part implies that the register or memory location is
neither a pure input nor a pure output.  It is both an input and an
output.  Therefore a '+' constraint is appropriate.

Ian

Re: A doubt about constraint modifiers

[Mohamed Shafi]

On Fri, Apr 11, 2008 at 12:41 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>  > I have noticed that when strict_low_part is used in a patten we need
>  > to use '+' as the constraint modifier if any constraints are used in
>  > the patterns.
>  > Why is this so?
>
>  Using strict_low_part implies that the register or memory location is
>  neither a pure input nor a pure output.  It is both an input and an
>  output.  Therefore a '+' constraint is appropriate.

Thanks for the reply.

In cris i saw this patten

(define_insn "*andhi_lowpart"
  [(set (strict_low_part
 (match_operand:HI 0 "register_operand""=r,r, r,r,r,r"))
(and:HI (match_operand:HI 1 "register_operand" "%0,0, 0,0,0,r")
(match_operand:HI 2 "general_operand"   "r,Q>,L,O,g,!To")))]

Here = is used.
So when you say appropriate you mean to say that its not mandatory to
use '+' but '=' also suffices?

Regards,
Shafi

Getting host and target size and alignment information at build time?

[Tim Josling]

I need to find out the alignment and size information for the standard
integral types and pointer types at GCC build time. 

The information is needed to work out the sizes of data structures so
that warnings about size mismatches can be produced.

The information is needed at build time because the parser and validator
do not have access to the gcc back end code when the compiler runs. So
this information needs to be worked out earlier and generated as Lisp
code ie in the build phase.

I have found tm.h, and also bconfig.h, config.h and tconfig.h. The sizes
are more or less OK as there are macros for sizes, apart from pointer
sizes in some cases. The alignment is the main problem; the alignments
for i386 are not constants but function calls and vary in certain
scenarios.

My current attempt at doing this is below. I fully acknowledge that it
is not correct. That is the reason for this posting. Does anyone have
any suggestions about how to get this information at build time?

Apart from some simple solution which I hope someone will come up with I
have two other possible avenues to solve the problem

1. Have some sort of install process which compiles and that extracts
the information out of the target compiler. Eg I could write a small
program which prints out the __alignof__ values and sizeof values for
various data items. This information then gets stored somewhere that it
can be used by the Lisp code.

2. Turn GCC into a libgccbackend and call it from my lisp code at run
time using a foreign function interface. This would make it unnecessary
to get the information at build time because the Lisp code could get it
from the compiler back end when compiling the program. This would be a
last resort at this stage due to possibilities for misuse of a
libgccbackend and also the foreign function interface overheads.

Tim Josling

/* -*- C -*- */

/*

Copyright ...

FILE Generate target-info file, - data item attributes for target time. 

Output goes to standard output.

*/
#include 
#include 
#include 
#define IN_GCC
#include "tconfig.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"

/* We don't want fancy_abort */
#undef abort

#ifndef BIGGEST_FIELD_ALIGNMENT
#define BIGGEST_FIELD_ALIGNMENT 32
#endif

#ifndef BITS_PER_UNIT
#define BITS_PER_UNIT 8
#endif

#ifndef POINTER_SIZE
#ifdef TARGET_64BIT
#define POINTER_SIZE 64
#else
#define POINTER_SIZE 32
#endif
#endif

/* Fake because some macro needs it. */
int ix86_isa_flags = 0;

static int
maxint (int a, int b)
{
  return (a>b?a:b);
}

static void
print_one_item (char *name, char *actual_usage, char *basic_type, int
size_bits)
{
  printf ("(defconstant %s-attributes\n"
  "   (gcb:make-usage-attributes\n"
  "   :usage cbt:%s\n"
  "   :basic-type cbt:%s\n"
  "   :size %d\n"
  "   :default-alignment %d\n"
  "   :sync-alignment %d))\n",
  name, actual_usage, basic_type, size_bits/BITS_PER_UNIT, 1,
  maxint (size_bits/BITS_PER_UNIT, 
/* This alignment is all wrong but there doesn't seem to be any way
   to get the true figure out of GCC short of doing a cross-build
   and then running a program on the target machine. */
  BIGGEST_FIELD_ALIGNMENT/BITS_PER_UNIT));
}

int
main (int argc, char **argv)
{
  fprintf (stderr, "TARGET_64BIT %d\n", TARGET_64BIT);
  fprintf (stderr, "POINTER_SIZE %d\n", POINTER_SIZE);
  if (argc != 1)
{
  fprintf (stderr, "Unexpected number of parameters - should be none
\n");
  abort ();
}
  printf ("...file header stuff");

  print_one_item ("char", "binary-char", "binary", BITS_PER_UNIT);
  print_one_item ("short", "binary-short", "binary", SHORT_TYPE_SIZE);
  print_one_item ("int", "binary-int", "binary", INT_TYPE_SIZE);
  print_one_item ("long", "binary-long", "binary", LONG_TYPE_SIZE);
  print_one_item ("long-long", "binary-long-long", "binary",
LONG_LONG_TYPE_SIZE);
  print_one_item ("sizet", "binary-size", "binary", POINTER_SIZE);
  print_one_item ("ptr", "binary-ptr", "binary", POINTER_SIZE);
  print_one_item ("ptr-diff", "binary-ptr-diff", "binary",
POINTER_SIZE);
  print_one_item ("display", "display", "display", BITS_PER_UNIT);
  print_one_item ("binary", "binary", "binary", INT_TYPE_SIZE);
  print_one_item ("binary1", "binary1", "binary", 1 * BITS_PER_UNIT);
  print_one_item ("binary2", "binary2", "binary", 2 * BITS_PER_UNIT);
  print_one_item ("binary4", "binary4", "binary", 4 * BITS_PER_UNIT);
  print_one_item ("binary8", "binary8", "binary", 8 * BITS_PER_UNIT);
  print_one_item ("pointer", "binary-pointer", "pointer", POINTER_SIZE);
  print_one_item ("function-pointer", "function-pointer", "pointer",
POINTER_SIZE);
  print_one_item ("program-pointer", "program-pointer", "pointer",
POINTER_SIZE);
  printf ("(defconstant usage-attributes-ht\n"
  "  (gcbc-utils:list2ht 'eql\n"
  "   (mapcar #'(lambda (el) (list (gcb:usage-attributes-usage
el) el))\n"
  "   (list char-att

GCC-4.3.0 fails to compile SPECint-2006 with control speculation on itanium processor

[吴曦]

Hi:

I am working on gcc-4.3.0 and Redhat ES 4. When I uses the compiler to
build specint-2006 benchmarks,
none passes the make with compiler option: -msched-control-spec
(enable control speculation on IA-64)

Here is part of the error log:

# Error 400.perlbench: Error with make!  #
# Error 401.bzip2: Error with make!  #
# Error 403.gcc: Error with make!#
# Error 429.mcf: Error with make!#
# Error 445.gobmk: Error with make!  #
# Error 456.hmmer: Error with make!  #
# Error 458.sjeng: Error with make!  #
# Error 462.libquantum: Error with make! #
# Error 464.h264ref: Error with make!#
# Error 471.omnetpp: Error with make!#
# Error 473.astar: Error with make!  #
# Error 483.xalancbmk: Error with make!  #

So any help ? Thanks

Fwd: GCC-4.3.0 fails to compile SPECint-2006 with control speculation on itanium processor

[吴曦]

-- Forwarded message --
From: 吴曦 <[EMAIL PROTECTED]>
Date: 2008/4/11
Subject: Re: GCC-4.3.0 fails to compile SPECint-2006 with control
speculation on itanium processor
To: Eljay Love-Jensen <[EMAIL PROTECTED]>


2008/4/11 Eljay Love-Jensen <[EMAIL PROTECTED]>:
> Hi 吴曦,
>
> What version of GNU Make are you using?
>
> make --version
>
> Is it at least GNU Make 3.80?
>
> --Eljay

[EMAIL PROTECTED] benchspec]$ make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Fwd: GCC-4.3.0 fails to compile SPECint-2006 with control speculation on itanium processor

[吴曦]

-- Forwarded message --
From: 吴曦 <[EMAIL PROTECTED]>
Date: 2008/4/11
Subject: Re: GCC-4.3.0 fails to compile SPECint-2006 with control
speculation on itanium processor
To: Eljay Love-Jensen <[EMAIL PROTECTED]>


I turn on the verbose mode of spec, it really fails to compile the code.

Something like internal compiler error, etc.

It seems that this support is rather inmature


2008/4/11 吴曦 <[EMAIL PROTECTED]>:

> 2008/4/11 Eljay Love-Jensen <[EMAIL PROTECTED]>:
> > Hi 吴曦,
> >
> > What version of GNU Make are you using?
> >
> > make --version
> >
> > Is it at least GNU Make 3.80?
> >
> > --Eljay
>
> [EMAIL PROTECTED] benchspec]$ make --version
> GNU Make 3.80
> Copyright (C) 2002  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>

Re: Getting host and target size and alignment information at build time?

[Daniel Jacobowitz]

Please don't reply to an existing thread to post a new question.

On Fri, Apr 11, 2008 at 08:52:11PM +1000, Tim Josling wrote:
> I have found tm.h, and also bconfig.h, config.h and tconfig.h. The sizes
> are more or less OK as there are macros for sizes, apart from pointer
> sizes in some cases. The alignment is the main problem; the alignments
> for i386 are not constants but function calls and vary in certain
> scenarios.

Simply put, you can't do this.  All of these things can depend on
command line options.

Why not get it out of GCC later?  You don't need to hack up GCC to do
that.

> 1. Have some sort of install process which compiles and that extracts
> the information out of the target compiler. Eg I could write a small
> program which prints out the __alignof__ values and sizeof values for
> various data items. This information then gets stored somewhere that it
> can be used by the Lisp code.

Yes.  Or you can do it without execution in a number of ways, either
by assigning these to constants or using the negative array size error
that autoconf uses to determine sizes by binary search (int foo[4 -
sizeof(int)], et cetera).

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC-4.3.0 fails to compile SPECint-2006 with control speculation on itanium processor

[Andrey Belevantsev]

吴曦 wrote:

Hi:

I am working on gcc-4.3.0 and Redhat ES 4. When I uses the compiler to
build specint-2006 benchmarks,
none passes the make with compiler option: -msched-control-spec
(enable control speculation on IA-64)
Control speculation is disabled by default on IA-64, so I think one of 
the scheduler patches accidentally broke it.  This can be Maxim's 
rewrite of dependence lists.  We will take a look.  Meanwhile you can 
try 4.2 series, they should work.


Andrey

Re: A doubt about constraint modifiers

[Bernd Schmidt]

Mohamed Shafi wrote:

In cris i saw this patten

(define_insn "*andhi_lowpart"
  [(set (strict_low_part
 (match_operand:HI 0 "register_operand"  "=r,r, r,r,r,r"))
(and:HI (match_operand:HI 1 "register_operand" "%0,0, 0,0,0,r")
(match_operand:HI 2 "general_operand"   "r,Q>,L,O,g,!To")))]

Here = is used.


This is incorrect since when the last alternative matches, nothing tells 
the compiler that operand 0 is also an input.



Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: Doubt about filling delay slot

[Mohamed Shafi]

On Tue, Apr 8, 2008 at 8:32 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>
> > Like you said i tried to split the move_immediate pattern after
>  > reload. This is how i did this :
>  >
>  > (define_split
>  >   [(set (match_operand:HI 0 "register_operand"  "")
>  > (match_operand:HI 1 "immediate_operand" ""))]
>  >   "reload_completed"
>  >   [(set (match_dup 0) (unspec:HI [(match_dup 2)] UNSPEC_LIL))
>  >(set (match_dup 0) (unspec:HI [(match_dup 3)] UNSPEC_LIU))]
>  >   "
>  >   {
>  > operands[2] = GEN_INT (INTVAL (operands[1]) & 0x00ff);
>  > operands[3] = GEN_INT ((INTVAL (operands[1]) >> 8) & 0x00ff);
>  >   }"
>  > )
>  >
>  > But after the instruction is split 'lil_pattern' get deleted for every
>  > split. This is because both the newly generated patterns are
>  > same, even though the value of the immediate constant is different for
>  > the patterns. This happens in the 'CSA'  pass.
>  > How can i make this work?
>
>  You are writing insns that look like they set the whole register, but
>  they don't.  Don't do that.  I also don't see why you need an unspec
>  here.  Write something like
>
>  (set (strict_low_part (match_dup 4)) (match_dup 2))
>
>  operands[2] = GEN_INT (...)
>  operands[4] = simplify_gen_subreg (QImode, operands[0], HImode, 0);
>
>  That is, express in the RTL what the instruction is really doing.

Thanks for the reply.
I did like what you suggested i.e in define_split i generated this pattern
(set (strict_low_part (match_dup 4)) (match_dup 2))
where
operands[2] = GEN_INT ((int)((INTVAL (operands[1])) & 0xff)); and
operands[4] = simplify_gen_subreg (QImode, operands[0], HImode, 0);

The define_insn pattern that matches this is something like this:

(define_insn "mov_const_lil"
  [(set (strict_low_part (match_operand:QI 0 "register_operand" "+r"))
(match_operand:QI 1 "immediate_operand" "i"))]
  ""
  "lil\\t%0, %1"
)

I get unrecognized error when the operands[1] is define_split pattern is say -6.
That was because the immediate_operand predicate in the define_insn is
rejecting the values which in this case is 250.
How will i be able to resolve this issue ?

Thanks for your time.

Regards,
Shafi

RE: US-CERT Vulnerability Note VU#162289

[Gerald.Williams]

Robert C. Seacord wrote:
> Here is another version of the program (same compiler version/flags).
[...]
> void test_signed(char *buf) {
> signed int len;
[...]
> if((buf+len < buf) != ((uintptr_t)buf+len < (uintptr_t)buf))
> printf(" BUG!");
[...]
> void test_unsigned(char *buf) {
> unsigned int len;
[...]
> if((buf+len < buf) != ((uintptr_t)buf+len < (uintptr_t)buf))
> printf(" BUG!");
[...]
> The unsigned test was one we performed on the gcc versions.  I added
the
> signed test, but it didn't make a difference on Visual Studio.  My
> understanding is that it shouldn't, because the real issue here is
> pointer arithmetic and the resulting type should always be a pointer.

I'm not sure what you mean by that last statement.

I think we've already established that those tests that would
print "BUG" aren't actually finding bugs in the compiler. It
is not correct to assume that adding a value to a char pointer
will wrap around in the same way as if you added a value to an
unsigned number. You also cannot assume that adding a value to
a signed number will cause it to wrap. (GCC had optimized away
checks for the latter already. There are now reports that many
other compilers may optimize away both tests.)

Are we in agreement on this? The fact that your example prints
"BUG!" seems to imply that it is invalid to optimize away these
tests, which it isn't.

I was under the impression that the only issue here is that
there is a change in behavior. That's a very fine line to walk
when many other compilers do this. In fact, you can run into
the same change of behavior when switching from unoptimized
debug versions to optimized release versions. Recommending not
using a recent GCC as a possible remedy is dangerous (some
would probably say irresponsible). What you really mean is,
"Use an older GCC or some other compiler that is known not to
take advantage of this optimization."

-Jerry

P.S. Has anyone checked how far back in the line of Microsoft
compilers you have to go to before they don't do this same
optimization (i.e., can we show irrefutably that this warning
should apply in the same degree to their compilers as well,
even without the "debug" versus "release" version argument)?
I suppose you only have to go as far back as the free version,
by inferring from the debug vs. release argument. :-)

Re: US-CERT Vulnerability Note VU#162289

[Robert C. Seacord]

Gerald,

Comments below.

 My
understanding is that it shouldn't, because the real issue here is
pointer arithmetic and the resulting type should always be a pointer.



I'm not sure what you mean by that last statement.
  
my understanding of the C99 standard is that adding an integer and a 
pointer always results in a pointer.  i'm not a compiler expert, but i 
would think that the rules that apply to adding a pointer and an integer 
of any signedness would be the same, and are different from the rules 
that would apply to adding signed or unsigned integers. 

VU#162289 only applies to pointer arithmetic.  I need to go back and 
check, but I don't believe the signedness of the integer involved is a 
factor.

I think we've already established that those tests that would
print "BUG" aren't actually finding bugs in the compiler.
Sorry about the string literal "Bug".  This was just an artifact from 
the original program.  I should have changed it to "optimization detected".

 It
is not correct to assume that adding a value to a char pointer
will wrap around in the same way as if you added a value to an
unsigned number. 

i think this depends on what you mean by "value".

You also cannot assume that adding a value to
a signed number will cause it to wrap. (GCC had optimized away
checks for the latter already. There are now reports that many
other compilers may optimize away both tests.)
  

ditto.

Are we in agreement on this? The fact that your example prints
"BUG!" seems to imply that it is invalid to optimize away these
tests, which it isn't.
  
i agree that the optimization is allowed by C99.  i think this is a 
quality of implementation issue,  and that it would be preferable for 
gcc to emphasize security over performance, as might be expected.

I was under the impression that the only issue here is that
there is a change in behavior. That's a very fine line to walk
when many other compilers do this. In fact, you can run into
the same change of behavior when switching from unoptimized
debug versions to optimized release versions. Recommending not
using a recent GCC as a possible remedy is dangerous (some
would probably say irresponsible).
this was only one of several solutions listed, and not the first one 
listed.  You will see that the Compliant Solution provided in the 
referenced secure coding rule:
ARR38-C. Do not add or subtract an integer to a pointer if the resulting 
value does not refer to an element within the array 


recommends modifying the code.

 What you really mean is,
"Use an older GCC or some other compiler that is known not to
take advantage of this optimization."
  
i think we mean what we say, which is "*Avoid newer versions of gcc" and 
*"avoiding the use of gcc versions 4.2 and later."  i don't see any 
verbiage that says "use a different compiler".

P.S. Has anyone checked how far back in the line of Microsoft
compilers you have to go to before they don't do this same
optimization 
our tests shows that the 2005 version of the compiler does not perform 
this optimization.  i have not yet tested a newer version of the compiler.


rCs

RE: US-CERT Vulnerability Note VU#162289

[Gerald.Williams]

Robert C. Seacord wrote:
> this was only one of several solutions listed, and not the first one
> listed.

Yes, CERT did the right thing by recommending first that the
code be changed (kudos for that).

>>  What you really mean is,
>> "Use an older GCC or some other compiler that is known not to
>> take advantage of this optimization."
> i think we mean what we say, which is "*Avoid newer versions of gcc"
and
> *"avoiding the use of gcc versions 4.2 and later."  i don't see any
> verbiage that says "use a different compiler".

I hope you can understand why that particular phrasing would be
viewed with some scorn, at least on the GCC list. Presumably,
the intent really is to suggest using a compiler that doesn't
have that optimization, not "don't use recent GCC versions".

> our tests shows that the 2005 version of the compiler does not perform
> this optimization.  i have not yet tested a newer version of the
compiler.

There was a report (forwarded by Mark Mitchell) of Microsoft
Visual C++ 2005 performing that optimization (the resultant
object code was shown). Have you verified that this report
was false? If not, it may be that you were using a different
set of options or a different version of that compiler.

-Jerry

Re: US-CERT Vulnerability Note VU#162289

[Ian Lance Taylor]

"Robert C. Seacord" <[EMAIL PROTECTED]> writes:

>>  What you really mean is,
>> "Use an older GCC or some other compiler that is known not to
>> take advantage of this optimization."
>>   
> i think we mean what we say, which is "*Avoid newer versions of gcc"
> and *"avoiding the use of gcc versions 4.2 and later."  i don't see
> any verbiage that says "use a different compiler".

I know I'm biased, but I think "use a different compiler" is clearly
implied by the text of the advisory.  If the advisory mentioned that
other compilers also implement the same optimization, then that
implication would not be there.

Ian

Re: Problem with reloading in a new backend...

[Jim Wilson]

Stelian Pop wrote:

#define PREFERRED_RELOAD_CLASS(X, CLASS)\
  ((CONSTANT_P(X)) ? EIGHT_REGS :   \
   (MEM_P(X)) ? EVEN_REGS : CLASS)

#define PREFERRED_OUTPUT_RELOAD_CLASS(X, CLASS) \
  ((CONSTANT_P(X)) ? EIGHT_REGS :   \
   (MEM_P(X)) ? EVEN_REGS : CLASS)


I think most of your trouble is here.  Suppose we are trying to reload a 
constant into an even-reg.  We call PREFERRED_RELOAD_CLASS, which says 
to use eight_regs instead, and you get a fatal_insn error because you 
didn't get the even-reg that the instruction needed.


PREFERRED_RELOAD_CLASS must always return a class that is a strict 
subset of the class that was passed in.


So define another register class which is the intersection of eight regs 
and even regs, and when we call PREFERRED_RELOAD_CLASS with a constant 
and even regs, then return the eight/even intersection class.


Likewise in all of the other cases you are trying to handle.

Fix this problem, and you probably don't need most of the other changes 
you have made recently.


Jim

Re: US-CERT Vulnerability Note VU#162289

[David Miller]

From: Ian Lance Taylor <[EMAIL PROTECTED]>
Date: Fri, 11 Apr 2008 11:04:38 -0700

> "Robert C. Seacord" <[EMAIL PROTECTED]> writes:
> 
> >>  What you really mean is,
> >> "Use an older GCC or some other compiler that is known not to
> >> take advantage of this optimization."
> >>   
> > i think we mean what we say, which is "*Avoid newer versions of gcc"
> > and *"avoiding the use of gcc versions 4.2 and later."  i don't see
> > any verbiage that says "use a different compiler".
> 
> I know I'm biased, but I think "use a different compiler" is clearly
> implied by the text of the advisory.  If the advisory mentioned that
> other compilers also implement the same optimization, then that
> implication would not be there.

I completely agree.

Re: Where is scheduling going wrong? - GCC-4.1.2

[Jim Wilson]

Mohamed Shafi wrote:

This looks like reordering is proper. When schedule-insn2 is run for
the above region/block the no:of instructions in the region
(rgn_n_insns) is 3.


Maybe bb reorder got the basic block structure wrong, and the barrier is 
not supposed to be part of the basic block.  In fact, looking at 
bb-reorder.c, I see this
  /* Make BB_END for cur_bb be the jump instruction (NOT 
the

 barrier instruction at the end of the sequence...).  */

  BB_END (cur_bb) = jump_insn;
Maybe it is getting this wrong someplace else in the file.  This might 
already be fixed in current sources, so you could try looking for an 
existing patch to fix it.


Jim

Re: address taken problem

[Jim Wilson]

Dasarath Weeratunge wrote:

In the following code I marked the tree 'node.0' as address taken using
'c_mark_addressable'. Now in the assembly code, isn't the return value of the
second call to malloc completely discarded?


c_mark_addressable is meant to be called during parsing.  It may affect 
the IL that will be generated, so you can't expect to be able to call it 
during optimization.


You haven't given us a copy of your patch, or the C code for your 
testcase.  It is difficult to say much definitive when we are lacking 
detailed info about what you are doing.


Jim

Re: US-CERT Vulnerability Note VU#162289

[Robert C. Seacord]

Gerald,

There was a report (forwarded by Mark Mitchell) of Microsoft
Visual C++ 2005 performing that optimization (the resultant
object code was shown). Have you verified that this report
was false? 


both chad and i have tested this with various options on Visual C++ 2005 
and we have not found any combination of options that will cause this 
optimization to occur.


rCs

--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC 


Work: 412-268-7608
FAX: 412-268-6989

Re: US-CERT Vulnerability Note VU#162289

[Robert C. Seacord]

Ian,

I know I'm biased, but I think "use a different compiler" is clearly
implied by the text of the advisory.  If the advisory mentioned that
other compilers also implement the same optimization, then that
implication would not be there.
  
yes, i agree we should make this change, and warn against assuming this 
optimization is not performed on other compilers.


if i understand you correctly (and based on our own tests) none of the 
compilation flags we've discussed address this issue, so we should also 
remove this as a "solution".


thanks,
rCs


--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC 


Work: 412-268-7608
FAX: 412-268-6989

Re: US-CERT Vulnerability Note VU#162289

[Paul Koning]

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:

 Ian> "Robert C. Seacord" <[EMAIL PROTECTED]> writes:
 >>> What you really mean is, "Use an older GCC or some other compiler
 >>> that is known not to take advantage of this optimization."
 >>> 
 >> i think we mean what we say, which is "*Avoid newer versions of
 >> gcc" and *"avoiding the use of gcc versions 4.2 and later."  i
 >> don't see any verbiage that says "use a different compiler".

 Ian> I know I'm biased, but I think "use a different compiler" is
 Ian> clearly implied by the text of the advisory.  If the advisory
 Ian> mentioned that other compilers also implement the same
 Ian> optimization, then that implication would not be there.

I don't know if you're biased, actually.  

My reading is the same.  If the recommendation is "avoid GCC 4.2 or
later" that translates to "use a compiler other than GCC 4.2 or later"
(that's just standard set algebra).  Clearly that set includes:

a. GCC 4.1 or before
b. Compilers other than GCC

So the CERT note as worded is recommending (a) or (b) as workarounds.
And it is clear that (b) is NOT a correct workaround.  

Therefore the text of the note as currently worded is wrong and has to
be repaired.

   paul

Re: Getting host and target size and alignment information at build time?

[Tim Josling]

On Fri, 2008-04-11 at 09:07 -0400, Daniel Jacobowitz wrote:
> Please don't reply to an existing thread to post a new question.

Sorry, I didn't realize that would cause a problem.

> Simply put, you can't do this.  All of these things can depend on
> command line options.

It does seem you can only get this information in the context of an
actual compile on the target machine.

> 
> Why not get it out of GCC later?  You don't need to hack up GCC to do
> that.

Later is too late. I need to make decisions before the GCC back end gets
involved (the back end is in a separate OS process). For example "Is
this literal too long for this group data item?". Or "Is a redefine
larger than the original (which is not allowed)?". If the literal is too
long I need to truncate it and give an error message; if a redefine is
too large I need to extend the original and give an error message.

While this can all be done, it means I am duplicating more logic into
the C code, and this has a 4X negative productivity impact versus Lisp.
It also makes it extremely difficult to output error messages in line#
sorted order, because they are issued by different processes.

Still if that's how GCC operates I will need to find some way to deal
with it. Maybe a cut down libgccbackend that doesn't generate code, it
just gives me the information I want.

Tim Josling

Re: Getting host and target size and alignment information at build time?

[Daniel Jacobowitz]

On Sat, Apr 12, 2008 at 06:59:28AM +1000, Tim Josling wrote:
> > Why not get it out of GCC later?  You don't need to hack up GCC to do
> > that.
> 
> Later is too late. I need to make decisions before the GCC back end gets
> involved (the back end is in a separate OS process). For example "Is
> this literal too long for this group data item?". Or "Is a redefine
> larger than the original (which is not allowed)?". If the literal is too
> long I need to truncate it and give an error message; if a redefine is
> too large I need to extend the original and give an error message.

That's not what I meant.  You don't need it _during the GCC build
process_.  You can fork GCC and run it and have it tell you the answer
based on the current command line arguments, read its output, and
go on with what you were doing.  Which presumably involves further
compilation.

(You didn't say what you are trying to do, so I'm guessing at the
context a bit.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: US-CERT Vulnerability Note VU#162289

[Mark Mitchell]

Robert C. Seacord wrote:

Gerald,

There was a report (forwarded by Mark Mitchell) of Microsoft
Visual C++ 2005 performing that optimization (the resultant
object code was shown). Have you verified that this report
was false? 


both chad and i have tested this with various options on Visual C++ 2005 
and we have not found any combination of options that will cause this 
optimization to occur.


I have not personally confirmed the VC++ 2005 report.  However, the code 
that I posted was pretty explicit about the optimization options used 
and the resulting code.  I've attached the entire listing here to try to 
give you more information; it includes the exact version of the compiler 
and shows the source code tested in comments.


Another user wrote to me regarding an unnamed version of MSVC that:


It appears that when adding large values (like 0xf000)
the if() check isn't optimized away, but for smaller
values it is (same as with gcc).
Small test:
char *buf="test";
unsigned int len = 0x4000;
if(buf+len < buf) {
LOG_MSG("1");
} else {
LOG_MSG("2");
}

It doesn't matter if len is int or unsigned int.
A maybe relevant thing is that everything up to
0x7fff for len will trigger the optimization,
whereas larger values (larger in terms of unsigned
32bit int) don't.


Presumably, when MSVC thinks the value is negative (when cast to a 
signed type), then it doesn't do the optimization, but, for positive 
values it does.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
; Listing generated by Microsoft (R) Optimizing Compiler Version 
14.00.50727.762 

TITLE   d:\src\prova\cert\cert.cpp
.686P
.XMM
include listing.inc
.model  flat


$SG-5   DB  00H
PUBLIC  ?f@@[EMAIL PROTECTED]   ; f
; Function compile flags: /Ogtpy
; File d:\src\prova\cert\cert.cpp
_TEXT   SEGMENT
?f@@[EMAIL PROTECTED] PROC  ; f

; 2:   len = 1 << 30;
; 3:   if (buf + len < buf)
; 4: return 1;
; 5: 
; 6: 
; 7:   return 0;

xor eax, eax

; 8: }

ret 0
?f@@[EMAIL PROTECTED] ENDP  ; f
_TEXT   ENDS
PUBLIC  _main
; Function compile flags: /Ogtpy
_TEXT   SEGMENT
_main   PROC

; 12   :char * b = "";
; 13   :for ( int l = 0; l < 1 << 30; ++l )
; 14   :f(b, l);
; 15   : }

xor eax, eax
ret 0
_main   ENDP
_TEXT   ENDS
END

Re: Problem with reloading in a new backend...

[Stelian Pop]

Le vendredi 11 avril 2008 à 11:14 -0700, Jim Wilson a écrit :
> Stelian Pop wrote:
> > #define PREFERRED_RELOAD_CLASS(X, CLASS)\
> >   ((CONSTANT_P(X)) ? EIGHT_REGS :   \
> >(MEM_P(X)) ? EVEN_REGS : CLASS)
> > 
> > #define PREFERRED_OUTPUT_RELOAD_CLASS(X, CLASS) \
> >   ((CONSTANT_P(X)) ? EIGHT_REGS :   \
> >(MEM_P(X)) ? EVEN_REGS : CLASS)
> 
> I think most of your trouble is here.  Suppose we are trying to reload a 
> constant into an even-reg.  We call PREFERRED_RELOAD_CLASS, which says 
> to use eight_regs instead, and you get a fatal_insn error because you 
> didn't get the even-reg that the instruction needed.
> 
> PREFERRED_RELOAD_CLASS must always return a class that is a strict 
> subset of the class that was passed in.
> 
> So define another register class which is the intersection of eight regs 
> and even regs, and when we call PREFERRED_RELOAD_CLASS with a constant 
> and even regs, then return the eight/even intersection class.

Ah thanks, this does indeed seem to solve a lot of problems I had !

> Likewise in all of the other cases you are trying to handle.
> 
> Fix this problem, and you probably don't need most of the other changes 
> you have made recently.

I will still have the problems with the fact that my indirect addressing
doesn't allow displacements, no ? (so I would need to implement
LEGITIMIZE_RELOAD_ADDRESS, in which I'll need a special reserved
register to compute the full address by adding the base and the
displacement). Or do you imply that I won't need this anymore ?

Thanks,

-- 
Stelian Pop <[EMAIL PROTECTED]>

Re: Problem with reloading in a new backend...

[Jim Wilson]

On Sat, 2008-04-12 at 00:06 +0200, Stelian Pop wrote:
> I will still have the problems with the fact that my indirect addressing
> doesn't allow displacements, no ? (so I would need to implement
> LEGITIMIZE_RELOAD_ADDRESS, in which I'll need a special reserved
> register to compute the full address by adding the base and the
> displacement). Or do you imply that I won't need this anymore ?

I didn't see an obvious explanation for your troubles here.

There are other targets like IA-64 that do not have base+offset
addressing modes.  It should just work.

LEGITIMIZE_RELOAD_ADDRESS is a hack.  It should never be necessary for
correct code generation, in theory, though I think there are some rare
corner cases where it may be required for correct results.  Long term
this is something that should be fixed.  Meanwhile, I can point out that
the IA-64 port does not define LEGITIMIZE_RELOAD_ADDRESS, and does not
have base+offset addressing modes, and it works.

IA-64 does have auto-increment addressing modes, but those shouldn't
matter here.  Reload won't generate such addressing modes for a stack
slot reference.

Jim

gcc-4.4-20080411 is now available

[gccadmin]

Snapshot gcc-4.4-20080411 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080411/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 134207

You'll find:

gcc-4.4-20080411.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20080411.tar.bz2 C front end and core compiler

gcc-ada-4.4-20080411.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20080411.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20080411.tar.bz2  C++ front end and runtime

gcc-java-4.4-20080411.tar.bz2 Java front end and runtime

gcc-objc-4.4-20080411.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20080411.tar.bz2The GCC testsuite

Diffs from 4.4-20080404 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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: Problem with reloading in a new backend...

[Jim Wilson]

Stelian Pop wrote:

I will still have the problems with the fact that my indirect addressing
doesn't allow displacements, no ? (so I would need to implement
LEGITIMIZE_RELOAD_ADDRESS, in which I'll need a special reserved
register to compute the full address by adding the base and the
displacement). Or do you imply that I won't need this anymore ?


In your original message, the right thing happens.  The stack slot 
address gets reloaded.



(insn 1117 16 1118 2 
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:1090 (set (reg:QI 10 r10)
(const_int 24 [0x18])) 1 {*movqi_imm} (nil))
(insn 1118 1117 1119 2 
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:1090 (set (reg:QI 10 r10)
(plus:QI (reg:QI 10 r10)
(reg/f:QI 30 r30))) 13 {addqi3} (expr_list:REG_EQUIV 
(plus:QI (reg/f:QI 30 r30)
(const_int 24 [0x18]))
(nil)))
(insn 1119 1118 21 2 
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:1090 (set (mem/c:QI (reg:QI 
10 r10) [31 S1 A16])
(reg:QI 14 r14)) 8 {*movqi_tomem} (nil))


The only problem here is that the register choice is wrong, and I 
already explained why it is wrong.


It is only after you started making some changes that this apparently 
broke.  It isn't clear why.  I can only suggest that you try to debug 
it.  Put a breakpoint in find_reloads() conditional on the instruction 
number.  Then step through to see what happens.  It should call 
finds_reloads_address or find_reloads_toplev at some point, which will 
see that we don't have a strictly valid address, and then reload it.


Jim

Re: A doubt about constraint modifiers

[Joe Buck]

On Fri, Apr 11, 2008 at 11:28:04AM +0530, Mohamed Shafi wrote:
> [ another "doubt" ]

You seem to be using the word "doubt" a lot whenever you don't completely
understand something, but this is not what the word means.

It means "to consider questionable or unlikely; to hesitate to believe; to
distrust", as in "I doubt that she is telling the truth".  So it makes it
sound, not like you don't understand something, but that you think it is
bad or wrong (not trustworthy).  I know that this isn't your intention.

Re: US-CERT Vulnerability Note VU#162289

[Joe Buck]

On Fri, Apr 11, 2008 at 03:00:14PM -0400, Robert C. Seacord wrote:
> Ian,
> >I know I'm biased, but I think "use a different compiler" is clearly
> >implied by the text of the advisory.  If the advisory mentioned that
> >other compilers also implement the same optimization, then that
> >implication would not be there.
> >  
> yes, i agree we should make this change, and warn against assuming this 
> optimization is not performed on other compilers.

Thanks.  I hope that you will correct the advisory promptly to avoid any
implication that one should switch from GCC to a different compiler based
on this issue, since we've already established that most of GCC's
competitors perform similar optimizations under some cicumstances (even if
the particular example that appears in the CERT report is not affected,
other, similar examples will be, particularly if they appear in a loop).

Both CERT and GCC have their reputations to consider here, and I think
that this advisory has damaged the reputations of *both*.

> if i understand you correctly (and based on our own tests) none of the 
> compilation flags we've discussed address this issue, so we should also 
> remove this as a "solution".

The advisory should emphasize the solution of auditing buffer overflow
checks to make sure that they are correct C, and should help people
write such checks correctly.

There is no forums except HyipArena

[chan timothy]

Hello and welcome to the most advanced High Yield Investments portal:
hyipparena.com

Find different articles, strategies, hyip analitics, money exchange services 
and more.

Update:
We're presenting new version of our famous product: ArenaPack.

Create your own HYIP in 15 minutes.
You will find everything you need inside:
-Flexible plan manager
-Smarty design templates
-Liberty Reserve and V-money merchants
-E-gold mass-pay working with 5xx accounts
Try free version or buy full package for 339 usd