http://www.kb.cert.org/vuls/id/162289
Any comments?
Rainer Emrich wrote:
http://www.kb.cert.org/vuls/id/162289
Any comments?
See http://www.airs.com/blog/archives/120 for a good blog post by Ian
Lance Taylor about this issue. -Wstrict-overflow=5 can be used to find
cases where optimizations break not standard specified overflow cases,
sinc
On Mon, Apr 7, 2008 at 1:16 AM, Tan, Jeffri <[EMAIL PROTECTED]> wrote:
>
>
>
> Would you happen to know which file the fix is in, so I can apply it as a
> patch to 4.2.2? Thanks.
It is in the "complete alias analysis rewrite" in tree-ssa-alias.c and
tree-ssa-structalias.c. No chance of backportin
Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 04.04.2008 16:53:53:
> Kai Tietz <[EMAIL PROTECTED]> writes:
>
> > While running testsuite for target x86_64-pc-mingw32, I noticed that
the
> > stack segement has for this target no execution permission. May
somebody
> > could help me, how to avoi
Hi ,
I've been looking to sort out a case where one sees the possibility of
doing some kind of redundancy elimination with auto-increment
expressions across basic blocks. I understand based on earlier
conversations as well as looking at auto-inc-dec.c that all
infrastructure for auto-inc-dec works
Hi DJ,
I agree that an infinite loop isn't exactly helpful. I believe the
original code for that aspect of contrib/gcc_update was contributed
by Alexandre; perhaps he's got an idea?
Gerald
On Tue, 1 Apr 2008, DJ Delorie wrote:
> we use the following logic:
>
> ... :
> @for f in $? $@; d
Laurent GUERBY wrote:
On Fri, 2008-04-04 at 15:07 -0500, Joel Sherrill wrote:
Beyond those, I am left with:
All targets had the following three failures:
c64005c - "WRONG ITERATIVE TRACE LENGTH."
c64005d - "WRONG ITERATIVE TRACE LENGTH."
c953002
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] shoul
The web page documentation at http://gcc.gnu.org/contribute.html
doesn't really have the specifics of getting a copyright assignment
done in the simple case of an individual contributing on his free
time. I've set up a wiki page that we can refer people to, at
http://gcc.gnu.org/wiki/CopyrightAssig
Hi,
It seems to me that as of ARMv6, the arm family supports the REV*
instructions, in order to endian swap 32 and 16 bit values.
Would it be complicated to implement e.g. __builtin_bswap32 on armv6
with inline semantics (I mean, without generating a library call)?
Thanks,
Alexandre
Paolo Bonzini wrote:
http://www.kb.cert.org/vuls/id/162289
The GCC SC was aware of this CERT posting before it was public. Our
feeling is that this is not a GCC bug, although it is something that we
would like GCC to warn about. I talked to Ian Taylor and he agreed to
work on the warning.
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> in reorg.c:3155 there is the following code:
>
> /* If we reach a CALL which is not calling a const function
> or the callee pops the arguments, then give up. */
> if (CALL_P (our_prev)
> && (! CONST_OR_PURE_CALL_P (our_prev)
>
On Mon, Apr 07, 2008 at 05:09:35PM +0100, FX wrote:
> The web page documentation at http://gcc.gnu.org/contribute.html
> doesn't really have the specifics of getting a copyright assignment
> done in the simple case of an individual contributing on his free
> time. I've set up a wiki page that we ca
On Mon, Apr 07, 2008 at 05:09:35PM +0100, FX wrote:
> > The web page documentation at http://gcc.gnu.org/contribute.html
> > doesn't really have the specifics of getting a copyright assignment
> > done in the simple case of an individual contributing on his free
> > time. I've set up a wiki page th
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
> This page has a major problem. The FSF wants the employer disclaimer
> in all cases.
The process that I describe is the one I went through, and other
people as well to my knowledge. If you (truthfully) answer "no" to the
question about employer/university ownership claims, I don't think
they
Mark,
Comments below.
The GCC SC was aware of this CERT posting before it was public. Our
feeling is that this is not a GCC bug, although it is something that
we would like GCC to warn about. I talked to Ian Taylor and he agreed
to work on the warning.
I agree with you that the behavior that
On Mon, Apr 7, 2008 at 10:28 AM, Robert C. Seacord <[EMAIL PROTECTED]> wrote:
> I believe the vulnerability is that gcc may *silently* discard the overflow
> checks and that this is a recent change in behavior.
No it is not recent, unless you consider 1998 recent :). I don't know
how many times
> Would it be complicated to implement e.g. __builtin_bswap32 on armv6
> with inline semantics (I mean, without generating a library call)?
Probably not.
Paul
Andrew,
We'll also add:
-Wstrict-overflow=5
As a work around.
You are right, I don't regularly read the GCC mailing lists as GCC is not our
only concern. This problem came to our attention because it affected one of
your users. We did consult with Mark before publishing.
rCs
On Mon,
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> On Mon, Apr 7, 2008 at 10:28 AM, Robert C. Seacord <[EMAIL PROTECTED]> wrote:
>> I believe the vulnerability is that gcc may *silently* discard the overflow
>> checks and that this is a recent change in behavior.
>
> No it is not recent, unless you co
On Mon, Apr 07, 2008 at 01:28:21PM -0400, Robert C. Seacord wrote:
> You are also right that the popularity of gcc is one of the reasons we
> decided to publish on this. If you identify other compilers that a) are
> relatively popular, b) have changed their behavior recently, and c)
> silently
Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons we
decided to publish on this. If you identify other compilers that a) are
relatively popular, b) have changed their behavior recently, and c)
silently optimize out overflow checks we will consider pu
Joe,
Response below.
On Mon, Apr 07, 2008 at 01:28:21PM -0400, Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons we
decided to publish on this. If you identify other compilers that a) are
relatively popular, b) have changed their behavior recently
> Robert C Seacord writes:
Robert> I believe the vulnerability is that gcc may *silently*
Robert> discard the overflow checks and that this is a recent change in
behavior.
Robert> You are also right that the popularity of gcc is one of the reasons we
Robert> decided to publish on this.
Mark,
comments below.
Robert C. Seacord wrote:
You are also right that the popularity of gcc is one of the reasons
we decided to publish on this. If you identify other compilers that
a) are relatively popular, b) have changed their behavior recently,
and c) silently optimize out overflow ch
Mark Mitchell wrote:
"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."
I've now been told that the LLVM compiler also
Robert C. Seacord 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".
Fair enough. However, it does suggest that recent versions of GCC ar
> Robert C Seacord writes:
Robert> my thinking is that if this behavior has been in place for many years,
Robert> for example, users will have had the opportunity to discover the
changed
Robert> behavior.
This explanation seems to be premised on users never moving an
application to
On Mon, Apr 07, 2008 at 02:10:04PM -0400, Robert C. Seacord wrote:
> Joe,
>
> Response below.
> >On Mon, Apr 07, 2008 at 01:28:21PM -0400, Robert C. Seacord wrote:
> >
> >>You are also right that the popularity of gcc is one of the reasons we
> >>decided to publish on this. If you identify oth
On Mon, Apr 7, 2008 at 2:15 PM, Robert C. Seacord <[EMAIL PROTECTED]> wrote:
> Mark,
>
> >
> 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.
Speaking as a completely random observer who has had
Hi,
I created an x86 gcc 4.3 branch to backport upcoming AMD and Intel
processor support from mainline:
svn://gcc.gnu.org/svn/gcc/branches/ix86/gcc-4_3-branch
The initial backports will be AES/PCLMUL, amdfam10 and sse5. Michael
and I are maintainers of the branch.
H.J.
---
Index: svn.html
On Mon, 7 Apr 2008, FX wrote:
> The web page documentation at http://gcc.gnu.org/contribute.html
> doesn't really have the specifics of getting a copyright assignment
> done in the simple case of an individual contributing on his free
> time. I've set up a wiki page that we can refer people to, at
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
ICC 10.0 and earlier releases perform
the same optimization, but not on straight-line code, such as the
testcase. ICC performs the transformation inside loops.
Thanks,
--
Mark Mitchell
CodeSourcery
[E
Here is an unintended bug I encountered recently, hopefully the "cert" warning
will catch this one too.
int okay_to_increment (int i)
{
if (i + 1 < i)
return 0; /* adding 1 would cause overflow */
return 1;/* adding 1 is safe */
}
Any sort of bug can cause a sec
Tom Truscott <[EMAIL PROTECTED]> writes:
> Here is an unintended bug I encountered recently, hopefully the "cert"
> warning will catch this one too.
>
>int okay_to_increment (int i)
>{
> if (i + 1 < i)
> return 0; /* adding 1 would cause overflow */
> return 1;/*
Tom Truscott wrote:
Here is an unintended bug I encountered recently, hopefully the "cert" warning
will catch this one too.
int okay_to_increment (int i)
{
if (i + 1 < i)
return 0; /* adding 1 would cause overflow */
return 1;/* adding 1 is safe */
}
Any sort
Oops, sorry! That is a very nice warning (apparently in gcc newer than 4.2).
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: Monday, April 07, 2008 4:40 PM
To: Tom Truscott
Cc: gcc@gcc.gnu.org
Subject: Re: US-CERT Vulnerability Note VU#162289
Tom Truscott <[EMAI
On Mon, Apr 7, 2008 at 1:44 PM, Tom Truscott <[EMAIL PROTECTED]> wrote:
> Oops, sorry! That is a very nice warning (apparently in gcc newer than 4.2).
It was added in at least 4.2.3.
-- Pinski
On Mon, 2008-04-07 at 09:40 -0700, Joe Buck wrote:
> On Mon, Apr 07, 2008 at 05:09:35PM +0100, FX wrote:
> > The web page documentation at http://gcc.gnu.org/contribute.html
> > doesn't really have the specifics of getting a copyright assignment
> > done in the simple case of an individual contribu
> 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
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!
Then, I think the FSF has no solution
On Mon, 2008-04-07 at 17:03 -0400, Richard Kenner wrote:
> > 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 w
I'm afraid I have to ask to remove the form from that Wiki. :-(
You're welcome to remove it yourself, but please replace them with
appropriate, *clear* documentation of the copyright assignment
process. The recent past (including my own experience some years ago)
has shown that http://gcc.
On Sat, 2008-04-05 at 06:57 -0400, Andy H wrote:
> There are several test in testsuite that use trampolines that are still
> run with dejagnu switch set to no_trampolines.
>
> Its on my TODO list for AVR target but a recent email reminded me that
> it affects testing of other targets than can'
> If you know of a non-GCC compiler that optimizes away
> the test (so that the function always returns 0), please
> post here, and let me know the name, version number,
> command-line options, etc. you used to demonstrate that.
The lovely TI Code Composer Studio compiler does the same optimiza
FX Coudert <[EMAIL PROTECTED]> writes:
>> 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 th
Paul Brook escreveu:
Would it be complicated to implement e.g. __builtin_bswap32 on armv6
with inline semantics (I mean, without generating a library call)?
Probably not.
Paul
Also, it would be interesting to have an inline version for
architectures older than armv6, when optimizin
On 07/04/2008, FX Coudert <[EMAIL PROTECTED]> wrote:
>
> Then, I think the FSF has no solution but to discard contributions from
> quite a few people. How many employers actually are going to issue such a
> disclaimer? In all academic places I know, at least, you'll never get
> anything like that,
Snapshot gcc-4.1-20080407 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080407/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Thank you so much.
I can test it easily and will let you know of any divergence from
original other than the those you mention.
Andy
Janis Johnson wrote:
On Sat, 2008-04-05 at 06:57 -0400, Andy H wrote:
There are several test in testsuite that use trampolines that are still
run with de
FX Coudert wrote:
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
inc
> 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.
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".
The generated code is:
It now dies here:
In file included from ../../../../../gcc/libstdc++-v3/src/strstream.cc:49:
/greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/libstdc++-v3/include/backward/strstream:
In member function 'void std::ostrstream::_ZTv0_n12_NSt10ostrstreamD0Ev()':
/greed/dj/m32c/gcc/m32c-elf/m32c-elf/m32cm/
55 matches
Mail list logo
