Re: Copyright assignment wiki page

[FX Coudert]

Moreover, our contribute page says "the GCC maintainer that is  
taking care of your contributions" and there is no documentation  
to maintainers, so that part at least is wrong: maintainers don't  
know what to do. Or else, I just didn't receive the maintainer  
welcome package including the appropriate documentation :)


The FSF defines maintainer a bit differently than the gcc project.   
In the FSF view, the GCC SC is the maintainer of GCC, and no one else.


Then I suggest changing our contribute page from
contact us (either via the gcc@gcc.gnu.org list or the GCC  
maintainer that is taking care of your contributions) to obtain the  
relevant forms



to
contact us (either via the gcc@gcc.gnu.org list or a GCC Steering  
Commitee member) to obtain the relevant forms




to reflect this.

FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Copyright assignment wiki page

[Paolo Bonzini]

Then I suggest changing our contribute page from
contact us (either via the gcc@gcc.gnu.org list or the GCC maintainer 
that is taking care of your contributions) to obtain the relevant forms



to
contact us (either via the gcc@gcc.gnu.org list or a GCC Steering 
Commitee member) to obtain the relevant forms




to reflect this.


It's not so hard actually.  Any person who has a GNU account can get 
them.  I just checked and, among people who are not SC members and are 
usually on IRC I counted 6-7 people.  Just ask them and they will 
forward you the administrivia form.


Paolo

Re: m32c build fails

[Richard Guenther]

On Mon, 7 Apr 2008, DJ Delorie wrote:

> 
> > I will apply the following if you confirm this fixes m32c-elf.
> 
> It fixed that particular bug, but another one elsewhere stopped the
> build and I don't know what caused the other one.
> 
> m32c-elf is easily cross-build with newlib and binutils if you want to
> see for yourself.

Sorry, I don't have time to dive into that.  I'll apply the patch.

Richard.

Re: Doubt about filling delay slot

[Mohamed Shafi]

On Thu, Apr 3, 2008 at 8:28 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>  > On Thu, Apr 3, 2008 at 7:35 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>  >> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>  >>
>  >>
>  >> > Say the target has two delay slots for call instructions.
>  >>  > So we can have something like this
>  >>  > (define_attr "slottable" "no,yes,has_slot" (const_string "yes"))
>  >>  >
>  >>  > (define_delay (eq_attr "slottable" "has_slot")
>  >>  >   [(eq_attr "slottable" "yes") (nil) (nil)
>  >>  >(eq_attr "slottable" "yes") (nil) (nil)])
>  >>  >
>  >>  > So in define_insn for call i can have
>  >>  > (set_attr "slottable" "has_slot")
>  >>  >
>  >>  >
>  >>  > Now imagine that i have 3 patterns : Pattern A with two instructions
>  >>  > in its template, Pattern B and Pattern C with only one instruction in
>  >>  > its template.
>  >>  > When it comes to filling the call instruction delay slot if slot 1 is
>  >>  > filled with Pattern A then there is no need to fill slot 2. But if its
>  >>  > filled with Pattern C or Pattern B, then slot 2 should be filled with
>  >>  > Pattern B or Pattern C, but not Pattern A.
>  >>  > Will i be able to do this in the back-end?
>  >>
>  >>  Ah, OK.  It's easy enough to say that you can't put pattern A in slot
>  >>  2.  But there is no way to say that if pattern A is in slot 1, then
>  >>  slot 2 is not available.
>  >>
>  > Ok i guess you are saying that this is not possible.
>  > But then this should be something that all the targets should deal
>  > with. How are they doing it?
>
>  It's not a standard problem.  On most machines a single insn does not
>  take up two slots.
>
>  To put it another way, you say that pattern A has two instructions in
>  its template, and I assumed that that was a requirement for some
>  reason.  If the instructions can be executed independently, then the
>  normal approach would be to use a define_split which runs after reload
>  to produce two insns for scheduling and delay slot filling.
>
In order to load immediate values, the target that i am working on
uses two instructions - liu and lil.
'lil' will load the immediate value into the lower byte of the
specified register. The upper byte is set to zero.
'liu' will load the immediate value into the upper byte of the
specified register. The lower byte of the register is unaffected.

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?

For delay slots will i be able to control filling of delay slots based
on the instruction cycles required for the instructions ?

Regards,
Shafi

RE: US-CERT Vulnerability Note VU#162289

[Dave Korn]

Mark Mitchell wrote on :

> Mark Mitchell wrote:
> 
>> I've been told that Intel's ICC compiler also does this optimization:
> 
> Apparently, IAR's Atmel AVR compiler does this optimization as well.


  Say, how do I get gcc to actually do this?  I can't reproduce this in a
real-world test.  I would have thought that the call to bar should be
optimised away in the example below, but it doesn't seem to be (tested on a
cygwin host with a recent gcc built from trunk rev.133266):


~ $ gcc -O3 -S -xc -o 2.s -
extern void foo (char *buf, int len);
extern void bar (char *buf);

void foo (char *buf, int len)
{
  if (buf+len < buf)
  {
bar (buf);
  }
  return;
}

void delay (int time)
{
  int i;
  for (i = 0; i < time; i++) ;
}

~ $ cat 2.s
.file   ""
.text
.p2align 4,,15
.globl _delay
.def_delay; .scl2;  .type   32; .endef
_delay:
pushl   %ebp
movl%esp, %ebp
popl%ebp
ret
.p2align 4,,15
.globl _foo
.def_foo;   .scl2;  .type   32; .endef
_foo:
pushl   %ebp
movl%esp, %ebp
movl12(%ebp), %eax
testl   %eax, %eax
js  L7
popl%ebp
ret
.p2align 4,,7
L7:
popl%ebp
jmp _bar
.def_bar;   .scl2;  .type   32; .endef
~ $ gcc --version
gcc (GCC) 4.4.0 20080316 (experimental)
Copyright (C) 2008 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.

~ $


  It looks to me like it got changed into a test if len is negative, which is
right, isn't it?

  Does this optimisation perhaps *only* happen in artificial testcases like
the one at the start of the thread, where 'len' is a compile-time constant
that gcc *knows* is positive?  Because if so, surely the CERT alert is
more-or-less spurious, rather than
perhaps-at-least-a-bit-useful-to-people-who-write-invalid-code?

  BTW, as you might also notice in that example, Gcc now optimises away empty
'delay' loops.  Unlike the impossible-range-check optimisation, this really is
new behaviour, at least since 3.x series.  Theoretically, this too could have
security implications for incorrect code.  Maybe there should be another
warning issued?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

gcc4.x handling of switch(enum)

[Pjotr Kourzanov]

Dear gcc developers,

 I have found a weird discrepancy in error/warning reporting in
GCC4.x. The following fragment:

enum e { A, B, C };
struct u { enum e e:2; };
void bar(struct u u) {
   switch (u.e) {
   case A:;
   }
}

 It does (rightfully) trigger a -Wswitch warning on gcc-3.3 and
gcc-3.4 but not on gcc-4.x.

 Note that the presence of the bitwidth specifier is essential for
this bug. My estimate is that the specifier makes the field to lose
its enum typedness, preventing further passes to from recognising
this (rather important) error.

 This is a bit weird, since giving the specifier a value that does
not match the range of the enum (e.g., :1) does trigger a warning
(`e' is narrower than values of its type).

  I am using Debian-packaged compilers.

Regards,

Pjotr Kourzanov

Re: US-CERT Vulnerability Note VU#162289

[Daniel Jacobowitz]

On Tue, Apr 08, 2008 at 01:09:18PM +0100, Dave Korn wrote:
> ~ $ gcc -O3 -S -xc -o 2.s -
> extern void foo (char *buf, int len);
> extern void bar (char *buf);
> 
> void foo (char *buf, int len)
> {
>   if (buf+len < buf)
>   {
> bar (buf);
>   }
>   return;
> }

Note that if buf is a char *, there's no way to know that it's the
start of an object.  So you're not testing the same thing they were
talking about; calling foo (&str[2], -1) is completely valid C.


-- 
Daniel Jacobowitz
CodeSourcery

Re: US-CERT Vulnerability Note VU#162289

[Marc Lehmann]

On Mon, Apr 07, 2008 at 02:15:14PM -0400, "Robert C. Seacord" <[EMAIL 
PROTECTED]> wrote:
> >The advisory suggests that people not use GCC.  
> no, it does not.  it suggests they may not want to use the latest 
> versions.  this is one possible work around.  we never say "use another 
> compiler".

Yes, it does, you are twisting words, let me quote:

   Avoid newer versions of gcc

   Application developers and vendors of large codebases that cannot be audited
   for use of the defective length checks are urged to avoiding the use of gcc
   versions 4.2 and later.

While using an older version of gcc is a way to follow that suggestion,
using another compiler is as well. So the advisory certainly *does*
suggest to not use GCC as _one_ way of working around this "vulnerability"
("not strictly speaking") in gcc.

If you think that the advisory should not suggest that users not use gcc,
then it should not say so.

As it is written, it clearly suggests that swiching compilers will help
to avoid this problem, and this is a great disservice for people, as it
might drive people to another compiler that cert *knows* does the same
optimisation but doesn't feel mentioning because it is not a "recent
change" or the compiler is "not popular enough" (some of the compilers
certainly are very popular, though, so this all sounds very hypocritical).

In any case, if the intention of the advisory was to make people go to
older rleases of gcc and not switch to other compilers, then it clearly
fails to say so. Instead, it *does* suggets that switching compilers is
one way around this issue.

> >"Some compilers (including, at least, GCC, PathScale, and xlc) 
> >optimize away incorrectly coded checks for overflow.  Applications 
> >containing these incorrectly coded checks may be vulnerable if 
> >compiled with these compilers."
> ok, i'll review again for tone.  generally we don't try to make these 
> notes overly broad; they are only meant to draw attention to a specific 
> issue.

But the specific issue is that compilers do that optimisation, and that the
code is buggy. The issue here is clearly not gcc - about every optimising
compiler does this optimisation, and by singling out gcc it seems as if
somehow gcc would be the problem, when clearly the code is.

The biggets problem is that cert knows that this is a common problem, but
suggests that, among othersa, switching compilers would somehow solve this
- a greta disservice to people who rely on accurate information.

Again, the issue here is buggy code, not gcc.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  [EMAIL PROTECTED]
  -=/_/_//_/\_,_/ /_/\_\

Problem with Fix for PR 35163 ?

[Pranav Bhandarkar]

Hi,

Consider the attached testcase.

Working on a private port (Infact I see this problem on
arm-none-eabi-gcc too). I see the following in test.c.003t.original

fail = (short int) usi <= ssi;

And then in test.c.025t.ssa
 usi.2_5 = (short int) usi_4;
 fail.3_6 = usi.2_5 <= ssi_2;

Now ccp1 does constant propagation and we are left with
usi.2_5 = -256;

This causes the test to fail.

Clearly the problem seems to be that since usi is unsigned short int a
short int cant represent all the possible values of usi

I reverted the following patch and the test passed.
 PR middle-end/35163
* fold-const.c (fold_widened_comparison): Use get_unwidened in
value-preserving mode.  Disallow final truncation.

Now with the patch reverted, test.c.003t.original has

 fail = (int) ssi >= (int) usi;

And this problem vanished.


Am I missing something here ?

Thanks,
Pranav
int fail;
short fs2(void)
{
return 126;
}

unsigned short ufs1(void)
{
return 65280;
}
int main ()
{

short  ssi;
unsigned short  usi;

ssi = fs2();
usi = ufs1();
fail = !(ssi < usi);

if (fail)
	printf ("Failed\n");
else
	printf ("Successful\n");

return 0;

}

Re: Doubt about filling delay slot

[Ian Lance Taylor]

"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.

Ian

Re: improving auto increment expressions detection across basic blocks.

[Kenneth Zadeck]

The auto-increment code was a quick hack based on the code that
existed in flow.c.  I moved it to a new pass and generalized it quite
a bit, but it is at its core, basicly the same local code.

The right way to implement this is as a global, or at least loop by
loop problem where du or ud chains guide the process.

Unfortunately, du and ud chains are expensive, and we need to and plan
to move to fuds in the near future.  then it will be reasonable to
consider upgrading many of the local optimizations to have a larger
context.  

I will point out one caveat with doing an extensive upgrading of this
code.   We fixed a LOT of bugs when i added this pass: well beyond the
number of bugs that just came with the pass itself.   

The majority of the new bugs were places where the rest of the
compiler was just not expecting to see auto inc or dec instructions. 
If you want to take on doing this kind of extension, be prepared for
the additional cost.  


> Hi Andrew,
> 
> On Mon, Apr 7, 2008 at 4:41 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 7, 2008 at 3:31 AM, Ramana Radhakrishnan <[EMAIL PROTECTED]> 
> > wrote:
> >  >  The basic case is as explained below.
> >  >
> >  >  for (i = 0; i < 100; i ++)
> >  >  {
> >  >   if ()
> >  >  {
> >  >   a[i] = something;
> >  >  }
> >  >  else
> >  >   a[i] = something else..
> >  >
> >  >  }
> >
> >  If it is this case, I think the store to a[i] should really sinked
> >  below the if statement instead of doing anything fancy with
> >  autoincrement.
> 
> In this case I agree that sinking the store would take care of the
> auto increment because you'd then have the store and the increment in
> the same block and hence things should theoretically work. Ofcourse
> the a[i] in both edges of the if need not exist and the else could
> instead be an update to a b[i] in which case there might be a need for
> something fancy with auto-increments.
> 
> Cheers
> Ramana
> 
> 
> >
> >  Thanks,
> >  Andrew Pinski
> >
> -- 
> Ramana Radhakrishnan
> 

Re: gcc4.x handling of switch(enum)

[Richard Guenther]

On Tue, Apr 8, 2008 at 2:32 PM, Pjotr Kourzanov
<[EMAIL PROTECTED]> wrote:
> Dear gcc developers,
>
>   I have found a weird discrepancy in error/warning reporting in
>  GCC4.x. The following fragment:
>
>  enum e { A, B, C };
>  struct u { enum e e:2; };
>  void bar(struct u u) {
>switch (u.e) {
>case A:;
>}
>  }
>
>   It does (rightfully) trigger a -Wswitch warning on gcc-3.3 and
>  gcc-3.4 but not on gcc-4.x.
>
>   Note that the presence of the bitwidth specifier is essential for
>  this bug. My estimate is that the specifier makes the field to lose
>  its enum typedness, preventing further passes to from recognising
>  this (rather important) error.
>
>   This is a bit weird, since giving the specifier a value that does
>  not match the range of the enum (e.g., :1) does trigger a warning
>  (`e' is narrower than values of its type).
>
>   I am using Debian-packaged compilers.

This is due to a fix that switch arguments need to be promoted properly.
The warning then likely fell through the cracks due to lack of a testcase
in the testsuite.

Please file a bugreport in bugzilla for this.

Thanks,
Richard.

Re: Problem with Fix for PR 35163 ?

[Richard Guenther]

On Tue, Apr 8, 2008 at 4:46 PM, Pranav Bhandarkar
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Consider the attached testcase.
>
>  Working on a private port (Infact I see this problem on
>  arm-none-eabi-gcc too). I see the following in test.c.003t.original
>
>  fail = (short int) usi <= ssi;
>
>  And then in test.c.025t.ssa
>   usi.2_5 = (short int) usi_4;
>   fail.3_6 = usi.2_5 <= ssi_2;
>
>  Now ccp1 does constant propagation and we are left with
>  usi.2_5 = -256;
>
>  This causes the test to fail.
>
>  Clearly the problem seems to be that since usi is unsigned short int a
>  short int cant represent all the possible values of usi
>
>  I reverted the following patch and the test passed.
>   PR middle-end/35163
> * fold-const.c (fold_widened_comparison): Use get_unwidened in
> value-preserving mode.  Disallow final truncation.
>
>  Now with the patch reverted, test.c.003t.original has
>
>   fail = (int) ssi >= (int) usi;
>
>  And this problem vanished.
>
>
>  Am I missing something here ?

Please file a bugreport about this.

Richard.

Re: Doubt about filling delay slot

[Jim Wilson]

Mohamed Shafi wrote:

'liu' will load the immediate value into the upper byte of the
specified register. The lower byte of the register is unaffected.


The liu pattern should be something like
(set (regX) (ior:HI (and:HI (regX) (const_int 255)) (const_int Y)))

Jim

KwGdOwMp 4329040559400834703

[frederigo hee]

dck 4008
nRLSKwG 653394
EZGO 559
QjgknRLSKwGdOwMp 4329040
krAQjgknRL 912265339432904055
AQjgknRLSKwGd 5339432904055940

Re: US-CERT Vulnerability Note VU#162289

[Mark Mitchell]

Daniel Jacobowitz wrote:

On Tue, Apr 08, 2008 at 01:09:18PM +0100, Dave Korn wrote:

~ $ gcc -O3 -S -xc -o 2.s -
extern void foo (char *buf, int len);
extern void bar (char *buf);

void foo (char *buf, int len)
{
  if (buf+len < buf)
  {
bar (buf);
  }
  return;
}


Note that if buf is a char *, there's no way to know that it's the
start of an object.  So you're not testing the same thing they were
talking about; calling foo (&str[2], -1) is completely valid C.


Exactly.

Dave, that's why my test example had the:

  len = 1 << 30;

line.  The compiler has to know that the value of len is non-negative in 
order to do the optimization.  Using an "unsigned int len" parameter 
should also give it that information, but the version I had was designed 
to closely resemble the case shown to my by CERT, which used a signed 
variable.


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

[Mark Mitchell]

Mark Mitchell wrote:

Mark Mitchell wrote:


I've been told that Intel's ICC compiler also does this optimization:


Apparently, IAR's Atmel AVR compiler does this optimization as well. 
That CPU has 16-bit addresses, so the tester changed the test case to 
use "1 << 14" instead of "1 << 30".


I've also been told that Microsoft Visual C++ 2005 compiler does this 
optimization.


Chad, Robert, are you going to update the CERT notice to reflect all of 
this additional information about other compilers that also do this 
optimization?


Here is the code generated:

; Listing generated by Microsoft (R) Optimizing Compiler Version 
14.00.50727.762

...
; Function compile flags: /Ogtpy

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

xor eax, eax

; 8: }

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

[Robert C. Seacord]

Mark,

I will update the CERT C Secure Coding rule with a list of compilers, 
once we complete a fact check.  Chad is responsible for updating the vul 
note, so I'll need to discuss this with him.


Specifically with regards to MSVC 2005, I thought Chad had already 
checked this and found that it did not exhibit this behavior.  I just 
tested the following program.


#include 

void f(char *buf)  {
 unsigned int len = len = 0xFF00;

 if (buf+len < buf) puts("true");

}

int main(void)
{
   char buffer[100];
   f(buffer);
   return 0;
}

and compiled it with Microsoft Visual Studio 2005 Version 8.0.50727.42 
with the following flags:


/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm 
/EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W4 /nologo /c /Wp64 
/ZI /TC /errorReport:prompt


And on the dissembly view I see:

 if (buf+len < buf) puts("true");
004113CB  mov eax,dword ptr [buf]
004113CE  add eax,dword ptr [len]
004113D1  cmp eax,dword ptr [buf]
004113D4  jae f+4Dh (4113EDh)
004113D6  mov esi,esp
004113D8  pushoffset string "true" (41563Ch)
004113DD  calldword ptr [__imp__puts (4182B8h)]
004113E3  add esp,4
004113E6  cmp esi,esp
004113E8  call@ILT+305(__RTC_CheckEsp) (411136h)

And the program prints out "true".

Any explanation why I am getting different behavior? 


If I change the flags to

/O2 /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm 
/EHsc /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W4 /nologo /c /Wp64 /TC 
/errorReport:prompt


with /O2 optimization, "true" is still printed although it is harder to 
examine the dissembly .


rCs



Mark Mitchell wrote:

Mark Mitchell wrote:


I've been told that Intel's ICC compiler also does this optimization:


Apparently, IAR's Atmel AVR compiler does this optimization as well. 
That CPU has 16-bit addresses, so the tester changed the test case to 
use "1 << 14" instead of "1 << 30".


I've also been told that Microsoft Visual C++ 2005 compiler does this 
optimization.


Chad, Robert, are you going to update the CERT notice to reflect all 
of this additional information about other compilers that also do this 
optimization?


Here is the code generated:

; Listing generated by Microsoft (R) Optimizing Compiler Version 
14.00.50727.762

...
; Function compile flags: /Ogtpy

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

xoreax, eax

; 8: }

Re: US-CERT Vulnerability Note VU#162289

[Mark Mitchell]

Robert C. Seacord wrote:

I will update the CERT C Secure Coding rule with a list of compilers, 
once we complete a fact check.  Chad is responsible for updating the vul 
note, so I'll need to discuss this with him.


Thanks.

Specifically with regards to MSVC 2005, I thought Chad had already 
checked this and found that it did not exhibit this behavior.  I just 
tested the following program.


I should clarify that I didn't personally do the test with MSVC -- or 
the other compilers mentioned.  (I tried to suggest that in the wording 
of my email, but I should have been more explicit.)  I was reporting 
information that had been given to me.



#include 

void f(char *buf)  {
 unsigned int len = len = 0xFF00;

 if (buf+len < buf) puts("true");

}


That's a little different that my test case, in that in your case len is 
unsigned.  Your case should make the optimization easier for the 
compiler to do, not harder -- but it would be worth trying with signed 
int.  I'd also eliminate the double-assignment to "len".  My test case was:


  int f(char *buf, int len) {
len = 1 << 30;
if (buf + len < buf)
  return 1;
return 0;
  }

which is what the person who emailed me about MSVC tested.  I did 
include the optimization flags they used in that email; they appeared in 
a comment in the MSVC output.  I don't know what those flags mean, 
though; I'm not an expert on MSVC usage.


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

RE: US-CERT Vulnerability Note VU#162289

[Dave Korn]

Robert C. Seacord wrote on :

> Specifically with regards to MSVC 2005, I thought Chad had already
> checked this and found that it did not exhibit this behavior.  I just
> tested the following program. 
> 
> #include 
> 
> void f(char *buf)  {
>   unsigned int len = len = 0xFF00;

  I'm sure you didn't mean to do that, but I doubt it affects the results.

  BTW, that's a very different number from (1 << 30).  How about trying again
with a 'u' suffix?  Or with something that doesn't have the sign bit set?

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: improving auto increment expressions detection across basic blocks.

[Mark Mitchell]

Kenneth Zadeck wrote:


The majority of the new bugs were places where the rest of the
compiler was just not expecting to see auto inc or dec instructions. 
If you want to take on doing this kind of extension, be prepared for
the additional cost. 


Kenny, do you have any pointers to autoincrement algorithms in the 
literature?  I can see how using some of the obvious global analysis can 
spot things like a store followed on all paths by an add to the pointer, 
and prove that there are no intervening uses of the pointer, and 
therefore note that could could merge the addition with the store to do 
a post-increment -- but is there anything especially clever out there?


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Copyright assignment wiki page

[Florian Weimer]

* Richard Kenner:

>> This is probably true for a country like the USA, but like FX
>> the FSF didn't ask a disclaimer from my employer: in France
>> as long as you don't use your employer ressources to contribute
>> your employer has absolutely no say on what you do outside your work.
>
> That's true in the US as well, but what happens later on if your employer
> comes by later on and claims you DID use employer resources?  Where would
> that leave the FSF?  Very few employees have deep enough pockets to
> indemnify the FSF from their employer!

The employer may even sue if someone from the company has signed a
disclaimer, on the basis that the disclaimer wasn't signed by someone
who clearly wasn't authorized to make such statements on behalf of the
organization (e.g., a dean at a typical German university).

My understanding is that the employer disclaimer is mainly intended for
protecting the contributor, and not the FSF.

Re: US-CERT Vulnerability Note VU#162289

[Florian Weimer]

* Robert C. Seacord:

> I agree with you that the behavior that gcc exhibits in this case is
> permitted by the ISO/IEC 9899:1999 C specification
> 
> (§6.5.6p8).   I believe the vulnerability is that gcc may *silently*
> discard the overflow checks and that this is a recent change in
> behavior. 

The problem is that there is no overflow check in the code.  At a purely
syntactic level, it appears that there is an overflow check.  But this
is true for integer overflows, too.

There are some issues that are debatable, like non-two's-complement
arithmetic for signed integers (also a feature of GCC and other
compilers)--or operator new[] overflows, for which I'd really like to
see run-time checks.

But treating C pointers as machine addresses is pretty clearly flawed
code.  For instance, are pointers compared as signed or unsigned
integers at the instruction level?  Which behavior do you need so that
your checks actually work as expected?

Re: improving auto increment expressions detection across basic blocks.

[Kenneth Zadeck]

Mark Mitchell wrote:

Kenneth Zadeck wrote:


The majority of the new bugs were places where the rest of the
compiler was just not expecting to see auto inc or dec instructions. 
If you want to take on doing this kind of extension, be prepared for
the additional cost. 


Kenny, do you have any pointers to autoincrement algorithms in the 
literature?  I can see how using some of the obvious global analysis 
can spot things like a store followed on all paths by an add to the 
pointer, and prove that there are no intervening uses of the pointer, 
and therefore note that could could merge the addition with the store 
to do a post-increment -- but is there anything especially clever out 
there?


Thanks,

Remember that we are not really talking about pointers here, even though 
the values that are computed are used as pointers.   The things that are 
combined are pseudo register expressions, so there is no rocket science 
here, not any involvement with aliases.   

Given that kind of simplification, this is a simple meet over all paths 
problem.   If all paths that reach some "suitable point" (the load or 
store that can accommodate the inc or dec) increment or decrement the 
register in the same way and moving that inc or dec will not create an 
inc or dec free path, you are free to move combine the inc into the 
suitable point. 

This is a very simplified instance of code motion or commoning.   The 
simplification is that it is goal directed.  The goal is to move the inc 
insns to the "suitable points".   

As far as literature, i do not know any off the top of my head, but this 
is a classic meet over all paths kind of dataflow problem.  I would 
rather solve it in ssa form than using dataflow equations but that is my 
bias and unfortunately is not an option until we get fuds put into the 
back end.


Kenny

Problem with reloading in a new backend...

[Stelian Pop]

Hi,

I'm working on a GCC (4.3.0) backend for a custom 16 bit microcontroller
we're designing at work, and I'm facing a reload problem. After having
lost many hours trying to make it work, I decided to ask for some
help :)

I'll try to summarize the situation below, but by all means please ask
for more if something is missing.

The error I'm encountering happens when compiling _divdi3 in libgcc
(note that before compiling this one, several functions from libgcc
compiled fine):

../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function ‘__divhi3’:
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:1106: error: insn does not 
satisfy its constraints:
(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))
../../../../src/gcc-4.3.0/libgcc/../gcc/libgcc2.c:1106: internal compiler 
error: in reload_cse_simplify_operands, at postreload.c:395

The microcontroller in question is a 16 bit one, and addresses the
memory only in 16 bit words:
#define BITS_PER_UNIT   16
#define UNITS_PER_WORD  1

This microcontroller has 32 hard registers. Immediate constants can only
be loaded into the first 8 registers. There are no index registers. All
the even registers can serve as a base register. However, the base
register addressing is reduced to its simplest form, where the offset is
always 0.

Based on the above, I have defined:
enum reg_class
{
  NO_REGS,
  STACK_REGS,
  EIGHT_REGS,
  EVEN_REGS,
  ALL_REGS,
  LIM_REG_CLASSES
};

#define GENERAL_REGS ALL_REGS

...

#define REG_CLASS_CONTENTS  \
{   \
  { 0x },   \
  { 0x8000 },   \
  { 0x00FF },   \
  { 0x },   \
  { (1LL << FIRST_PSEUDO_REGISTER) - 1 }\
}

#define REGNO_REG_CLASS(REGNO)  \
  ((REGNO) > 30   ? STACK_REGS  \
   : (REGNO) < 8  ? EIGHT_REGS  \
   : (REGNO % 2) == 0  ? EVEN_REGS  \
   : GENERAL_REGS)

#define BASE_REG_CLASS EVEN_REGS

#define INDEX_REG_CLASS NO_REGS

#define REGNO_OK_FOR_BASE_P(NUM) (NUM % 2 == 0)

#define REGNO_OK_FOR_INDEX_P(NUM) 0

#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)

...

#define STACK_POINTER_REGNUM 31

#define FRAME_POINTER_REGNUM 30



#ifdef REG_OK_STRICT
#define REG_OK_FOR_BASE_P(X)\
(REGNO_OK_FOR_BASE_P (REGNO (X)) && (REGNO (X) 
= 
FIRST_PSEUDO_REGISTER)
#endif

#define GO_IF_LEGITIMATE_ADDRESS(MODE, X, LABEL)\
do {\
  if (GET_CODE (X) == REG && (REG_OK_FOR_BASE_P(X)))\
goto LABEL; \
  else if (GET_CODE(X) == PLUS &&   \
   REG_OK_FOR_BASE_P (XEXP (X, 0)) &&   \
   GET_CODE(XEXP(X,1)) == CONST_INT &&  \
   INTVAL(XEXP(X,1)) == 0)  \
goto LABEL; \
} while (0)


I also defined some constraints for the register classes:

(define_register_constraint "x" "STACK_REGS"
  "Stack registers (r30--r31)")

(define_register_constraint "y" "EIGHT_REGS"
  "Low eight registers (r0--r7)")

(define_register_constraint "z" "EVEN_REGS"
  "Even registers (r0,r2,r4, @dots{} r30)")


The movqi_imm pattern which constraints doesn't match has been defined
with (note the 'y' constrant):

(define_insn "*movqi_imm"
  [(set (match_operand:QI 0 "register_operand" "=y")
(match_operand:QI 1 "const_int_operand" ""))]
  ""  
  {
output_asm_insn ("ldih %0, hi(%1)", operands);
output_asm_insn ("ldil %0, lo(%1)", operands);
return "";
  }
  [(set_attr "cc" "none")]
)

Now, I'm trying to figure out why the error happens, with GCC choosing
to put an immediate into r10 instead of an EIGHT_REGS. It all seems to
come (I do not know why) from insn 16 in libgcc2.c.175r.lreg:

Register 453 costs: EIGHT_REGS:0 EVEN_REGS:0 ALL_REGS:0 MEM:4175
Register 466 costs: EIGHT_REGS:600 EVEN_REGS:600 ALL_REGS:600 MEM:5200

Re: Problem with Fix for PR 35163 ?

[Richard Guenther]

On Tue, Apr 8, 2008 at 5:36 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 8, 2008 at 4:46 PM, Pranav Bhandarkar
>  <[EMAIL PROTECTED]> wrote:
>  > Hi,
>  >
>  >  Consider the attached testcase.
>  >
>  >  Working on a private port (Infact I see this problem on
>  >  arm-none-eabi-gcc too). I see the following in test.c.003t.original
>  >
>  >  fail = (short int) usi <= ssi;
>  >
>  >  And then in test.c.025t.ssa
>  >   usi.2_5 = (short int) usi_4;
>  >   fail.3_6 = usi.2_5 <= ssi_2;
>  >
>  >  Now ccp1 does constant propagation and we are left with
>  >  usi.2_5 = -256;
>  >
>  >  This causes the test to fail.
>  >
>  >  Clearly the problem seems to be that since usi is unsigned short int a
>  >  short int cant represent all the possible values of usi
>  >
>  >  I reverted the following patch and the test passed.
>  >   PR middle-end/35163
>  > * fold-const.c (fold_widened_comparison): Use get_unwidened in
>  > value-preserving mode.  Disallow final truncation.
>  >
>  >  Now with the patch reverted, test.c.003t.original has
>  >
>  >   fail = (int) ssi >= (int) usi;
>  >
>  >  And this problem vanished.
>  >
>  >
>  >  Am I missing something here ?
>
>  Please file a bugreport about this.

Btw, I have a fix.

Richard.

Re: RFC: A new meta intrinsic header file for x86 intrinsics

[Mark Mitchell]

H.J. Lu wrote:


We will implement meta intrinsic header file for AVX intrinsics.
However, I am not sure if  is the best name for it.
Does anyone have any suggestions, how about ?


I think there's value in using the same name as icc.  It's set a 
precedent, let's keep it.  That makes it easy for people to move code 
from icc to GCC.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: US-CERT Vulnerability Note VU#162289

[Robert C. Seacord]

Dave,

I made at least one change you suggested:

#include 

void f(char *buf)  {
 unsigned int len = 0xFF00u;

 if (buf+len < buf) puts("true");

}

int main(void) {
   char buffer[100];
   printf("buffer addr = %p.\n", buffer);
   f(buffer);
   return 0;
}

And compiled with flags:

/O2 /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" 
/FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W4 /nologo /c /Wp64 
/Zi /TC /errorReport:prompt


The output of this program is:

buffer addr = 0012FF18.
true

The reason the len is so high is to force an overflow when added to 
0x0012FF18.


BTW, I also tried compiling this as a C++ program under visual studio 
and got the same result.


rCs



Robert C. Seacord wrote on :

  

Specifically with regards to MSVC 2005, I thought Chad had already
checked this and found that it did not exhibit this behavior.  I just
tested the following program. 


#include 

void f(char *buf)  {
  unsigned int len = len = 0xFF00;



  I'm sure you didn't mean to do that, but I doubt it affects the results.

  BTW, that's a very different number from (1 << 30).  How about trying again
with a 'u' suffix?  Or with something that doesn't have the sign bit set?

cheers,
  DaveK
  

Re: GCC 4.3.0 compilation error

[Mark Mitchell]

Jim Wilson wrote:

Wirawan Purwanto wrote:
I tried to compile GCC 4.3.0 on a Red Hat Linux 9.0 box, it stopped at 
stage 1:


Compiling new gcc versions on old linux versions may not always work, 
and is unlikely to be fixed.  You are probably on your own here if you 
run into a non-trivial problem.


However, I think we should accept patches for such problems, if they're 
otherwise good.  (I'm not suggesting that you, Jim, are saying 
otherwise; I'm just expandng.)


In this case, for example, the fix might be to add something like:

#ifndef SSIZE_MAX
#define SSIZE_MAX LONG_MAX
#endif

to host-linux.c.  Or some autoconf check that determines whether 
SSIZE_MAX is available and defines it if it is not, based on the size of 
 size_t.  Or something.  (I don't know Linux well enough to how 
consistent these things are across targets.)


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

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

[Andy H]

Take at look at AVR target which is very similar.

Here onluy "d" constrained register accept constants (they are call used 
registers too)


The AVR move pattern (*reloadinqi) has multiple constrain options "d" 
against "i" being relevant. So check you have all the combinations 
defined. You omitted "i" constraint but I dont know if that is relevant.


When "costing " is done, it walks thru constraints. You don't seem to 
have many constrain combinations (since costs are lower than I typically 
see for AVR).  It will score on both EVEN and EIGHT and likely pick EVEN 
because its bigger class. So I think that is perhaps reason. I think 
order of classes maybe need to be changed or something else to prevent 
problem with overlap (LOWER_EVEN? UPPER_EVEN)


But I could be completely wrong!

Andy

Re: GCC 4.3.0 compilation error

[Joe Buck]

On Tue, Apr 08, 2008 at 04:46:16PM -0700, Mark Mitchell wrote:
> Jim Wilson wrote:
> >Wirawan Purwanto wrote:
> >>I tried to compile GCC 4.3.0 on a Red Hat Linux 9.0 box, it stopped at 
> >>stage 1:
> >
> >Compiling new gcc versions on old linux versions may not always work, 
> >and is unlikely to be fixed.  You are probably on your own here if you 
> >run into a non-trivial problem.
> 
> However, I think we should accept patches for such problems, if they're 
> otherwise good.  (I'm not suggesting that you, Jim, are saying 
> otherwise; I'm just expandng.)
> 
> In this case, for example, the fix might be to add something like:
> 
> #ifndef SSIZE_MAX
> #define SSIZE_MAX LONG_MAX
> #endif
> 
> to host-linux.c.  Or some autoconf check that determines whether 
> SSIZE_MAX is available and defines it if it is not, based on the size of 
>  size_t.  Or something.  (I don't know Linux well enough to how 
> consistent these things are across targets.)

Something like this might be worthwhile if enough patches could be
put together to get a given older Linux distro to boot.  But this
might be only the first error for Red Hat 9.

I don't have anything around of sufficient age to test on, though we
still have RHEL 3 machines around here.

more m32c brokenness

[DJ Delorie]

Continuation of the last one, different bug, building libstdc++ ...
Look familiar to anyone?  If not, I'll try to hunt down the cause.
The culprit is this line:

D.25530 = (unsigned int) D.25529;

For m32cm, "int" is 16 bits, "long" is 32 bits, and "void*" is 24
bits.  A cast to unsigned int truncates a pointer.

[ gdb ] up
#3  0x085588ec in verify_gimple_2 (stmts=0xb6e7c738) at 
../../gcc/gcc/tree-cfg.c:4126
4126bool err2 = verify_gimple_stmt (stmt);

[ gdb ] call debug_generic_expr (stmts)
D.25526 = &this->D.17063._vptr.basic_ostream;
D.25527 = *D.25526;
D.25528 = D.25527 + -12;
D.25529 = *D.25528;
D.25530 = (unsigned int) D.25529;
D.25531 = this + D.25530;
*.LTHUNK0 (D.25531);

 
./cc1plus  -fpreprocessed strstream.ii -quiet -dumpbase strstream.cc 
-mcpu=m32cm -auxbase-strip strstream.o -g -O2 -Wall -Wextra -Wwrite-strings 
-Wcast-qual -Wno-deprecated -version -fno-implicit-templates 
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o 
strstream.s

#0  verify_gimple_expr (expr=0xb6e79e80) at ../../gcc/gcc/tree-cfg.c:3653
#1  0x08557d3b in verify_gimple_modify_stmt (stmt=0xb6e7c7c4) at 
../../gcc/gcc/tree-cfg.c:4012
#2  0x08557ed7 in verify_gimple_stmt (stmt=0xb6e7c7c4) at 
../../gcc/gcc/tree-cfg.c:4045
#3  0x085588ec in verify_gimple_2 (stmts=0xb6e7c738) at 
../../gcc/gcc/tree-cfg.c:4126
#4  0x08558943 in verify_gimple_1 (stmts=0xb6e7c738) at 
../../gcc/gcc/tree-cfg.c:4143
#5  0x0840a079 in gimplify_body (body_p=0xb738da68, fndecl=0xb738da10, 
do_parms=1 '\001')
at ../../gcc/gcc/gimplify.c:6536
#6  0x0840a5b5 in gimplify_function_tree (fndecl=0xb738da10) at 
../../gcc/gcc/gimplify.c:6576
#7  0x08214aee in c_genericize (fndecl=0xb738da10) at 
../../gcc/gcc/c-gimplify.c:105
#8  0x081cc445 in cp_genericize (fndecl=0xb738da10) at 
../../gcc/gcc/cp/cp-gimplify.c:774
#9  0x0807e438 in finish_function (flags=0) at ../../gcc/gcc/cp/decl.c:11923
#10 0x081759e7 in use_thunk (thunk_fndecl=0xb738da10, emit_p=1 '\001') at 
../../gcc/gcc/cp/method.c:525
#11 0x081829cd in emit_associated_thunks (fn=0xb738d850) at 
../../gcc/gcc/cp/semantics.c:3157
#12 0x08762f00 in cgraph_expand_function (node=0xb743bc80) at 
../../gcc/gcc/cgraphunit.c:1156
#13 0x08765c77 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1220
#14 0x0810a7fd in cp_write_global_declarations () at 
../../gcc/gcc/cp/decl2.c:3471
#15 0x08539e6b in toplev_main (argc=23, argv=0xbfad1944) at 
../../gcc/gcc/toplev.c:971
#16 0x08225332 in main (argc=Cannot access memory at address 0x1
) at ../../gcc/gcc/main.c:35

Re: RFC: A new meta intrinsic header file for x86 intrinsics

[H.J. Lu]

On Tue, Apr 08, 2008 at 02:10:55PM -0700, Mark Mitchell wrote:
> H.J. Lu wrote:
>
>> We will implement meta intrinsic header file for AVX intrinsics.
>> However, I am not sure if  is the best name for it.
>> Does anyone have any suggestions, how about ?
>
> I think there's value in using the same name as icc.  It's set a precedent, 
> let's keep it.  That makes it easy for people to move code from icc to GCC.
>

Icc and gcc will use the same filename. The question is what filename
to use.


H.J.

Re: RFC: A new meta intrinsic header file for x86 intrinsics

[Mark Mitchell]

H.J. Lu wrote:


Icc and gcc will use the same filename. The question is what filename
to use.


Oh, OK.  If we get to pick, then, yes, I think  is nice.

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: improving auto increment expressions detection across basic blocks.

[Kenneth Zadeck]

Kenneth Zadeck wrote:

Mark Mitchell wrote:

Kenneth Zadeck wrote:


The majority of the new bugs were places where the rest of the
compiler was just not expecting to see auto inc or dec instructions. 
If you want to take on doing this kind of extension, be prepared for
the additional cost. 


Kenny, do you have any pointers to autoincrement algorithms in the 
literature?  I can see how using some of the obvious global analysis 
can spot things like a store followed on all paths by an add to the 
pointer, and prove that there are no intervening uses of the pointer, 
and therefore note that could could merge the addition with the store 
to do a post-increment -- but is there anything especially clever out 
there?


Thanks,

Remember that we are not really talking about pointers here, even 
though the values that are computed are used as pointers.   The things 
that are combined are pseudo register expressions, so there is no 
rocket science here, not any involvement with aliases.  
Given that kind of simplification, this is a simple meet over all 
paths problem.   If all paths that reach some "suitable point" (the 
load or store that can accommodate the inc or dec) increment or 
decrement the register in the same way and moving that inc or dec will 
not create an inc or dec free path, you are free to move combine the 
inc into the suitable point.
This is a very simplified instance of code motion or commoning.   The 
simplification is that it is goal directed.  The goal is to move the 
inc insns to the "suitable points".  
As far as literature, i do not know any off the top of my head, but 
this is a classic meet over all paths kind of dataflow problem.  I 
would rather solve it in ssa form than using dataflow equations but 
that is my bias and unfortunately is not an option until we get fuds 
put into the back end.


Kenny

there is actually one nit of this that makes a dataflow solution easier 
than a fud or ssa version.

uses of the index variable kill it.

consider the straight line code

a <- a + 1

...<- a

x[a]  

you would like to combine the a<-a+1 with the x[a], but you cannot 
because it would mean changing the use of   ...<-a into ...<-a-1.   This 
is a loss.  ssa and fuds are not good at detecting this kind of thing 
without futzing with statement numbers and and domination and such where 
if you solve it as a dataflow problem, you can make the ...<-a be in the 
kill set.



kenny

Re: Problem with Fix for PR 35163 ?

[Pranav Bhandarkar]

>  Btw, I have a fix.

oh gr8. I just saw your post on the gcc-patches. Do you still want me
to add this to PR35163 for the record ?

Cheers!
Pranav