Re: How to teach gcc, that registers are clobbered by api calls?
Ross,
> Kai Tietz writes:
> >I read that too, but how can I teach gcc to do this that registers are
> >callee-saved? I tried it by use of call_used part in regclass.c, but
> >this didn't worked as expected.
>
> I think you need to modify CALL_USED_REGISTERS and/or
> CONDITIONAL_REGISTER_USAGE in i386.h. Making any changes to regclass.c
> is probably not the right thing to do.
Hmm, the parts in CALL_USED_REGISTERS and CONDITIONAL_REGISTER_USAGE seems
to be ok (beside xmm6-xmm15).
If I change xmm6-xmm15 to be non-volatile, I get ICE's in float
initialize.
But the interesting part is, that by methods like memset/memcpy/ the
register r13 still get clobbered.
Could it be that on externals (or dll imported) symbols in optimization
the register clobbering of a call is not treated correctly?
Cheers,
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: I386.md: *_mixed and *_sse
Hello! > From i386.md, alternative 1 of *fop_sf_comm_mixed is duplicated with > *fop_sf_comm_sse. Why do we define a _mixed pattern here? > > (define_insn "*fop_sf_comm_mixed" > [(set (match_operand:SF 0 "register_operand" "=f,x") > (match_operator:SF 3 "binary_fp_operator" Register allocator is free to choose either x87 or SSE register in _mixed case, where only SSE reg alternative is available in _sse pattern. Uros.
GCC port on PIC18xxx MCUs
I'm interested in creating a backend port of gcc for the PIC18xxx MCUs and more specifically for PIC18F4550. If anyone has any past experience or working code I would be delighted to hear from. As I've seen by searching the mailing list archives there were some attempts in the past, any useful comment is greatly appreciated. ggeorgak -- The bigger they are, the harder they hit you. Giorgis Georgakoudis Department of Computer & Communication Engineering (www.inf.uth.gr) University of Thessaly Volos, Greece
Re: US-CERT Vulnerability Note VU#162289
Mark Mitchell wrote: However, I'm surprised that only GCC is listed as "vulnerable" at the bottom of the page. We've provided information about a lot of other compilers that do the same optimization. Why is the status for compilers from Microsoft, Intel, IBM, etc. listed as "Unknown" instead of "Vulnerable"? The vendors listed in that section are the ones we've contacted asking for a statement. The note gets updated as we get information from them. We won't include information about other vendors without either a statement from them or independent verification of their affectedness. -Chad
Re: US-CERT Vulnerability Note VU#162289
Brad Roberts wrote: Additionally, the linked to notes for GCC are reflective of the original innaccuracies: http://www.kb.cert.org/vuls/id/CRDY-7DWKWM Vendor Statement No statement is currently available from the vendor regarding this vulnerability. US-CERT Addendum Vendors and developers using the GNU C compiler should consider downgrading their version of gcc or sticking with versions of the gcc compiler (before version 4.1) that do not perform the offending optimization. In the case of gcc, it should be emphasized that this is a change of behavior in the later versions of the compiler. Why is this inaccurate? The objections to the original version of the note on this list were that it appeared to advocate dumping gcc in favor of another compiler that may do the same optimization. This addendum merely suggest considering using an older version of gcc. -Chad
Re: US-CERT Vulnerability Note VU#162289
From: Chad Dougherty <[EMAIL PROTECTED]> Date: Wed, 23 Apr 2008 07:52:26 -0400 > We won't include information about other vendors without either a > statement from them or independent verification of their affectedness. How, may I ask, did that policy apply to the GCC "vendor" when this all got started?
Re: US-CERT Vulnerability Note VU#162289
David Miller wrote: How, may I ask, did that policy apply to the GCC "vendor" when this all got started? Our own testing of multiple versions of gcc on multiple platforms and subsequent confirmation by Mark that it was intentional, desired behavior. This all occurred prior to even the initial version of the note. -Chad
Re: US-CERT Vulnerability Note VU#162289
From: Chad Dougherty <[EMAIL PROTECTED]> Date: Wed, 23 Apr 2008 08:37:11 -0400 > David Miller wrote: > > How, may I ask, did that policy apply to the GCC "vendor" > > when this all got started? > > Our own testing of multiple versions of gcc on multiple platforms and > subsequent confirmation by Mark that it was intentional, desired > behavior. This all occurred prior to even the initial version of the note. CERT is asking these vendors for "approval" for the text they will add mentioning anything about their product. That's the bit I'm talking about. They are getting protection and consideration that was not really afforded to GCC. CERT treated GCC differently.
Re: US-CERT Vulnerability Note VU#162289
David Miller wrote: CERT is asking these vendors for "approval" for the text they will add mentioning anything about their product. That's the bit I'm talking about. They are getting protection and consideration that was not really afforded to GCC. CERT treated GCC differently. This is not true. The "Statement" section of the vendor status is for official, usually verbatim, statements from the vendor. The "Addendum" section is reserved for our own comments, even those that may contradict the vendor's response if we have reason to do so. You'll note that the suggestion about _considering_ using older versions of gcc appears in the addendum. -Chad
Re: US-CERT Vulnerability Note VU#162289
On Wed, Apr 23, 2008 at 1:59 PM, Chad Dougherty <[EMAIL PROTECTED]> wrote: > Brad Roberts wrote: > > > Additionally, the linked to notes for GCC are reflective of the original > innaccuracies: > > http://www.kb.cert.org/vuls/id/CRDY-7DWKWM > > > > Vendor Statement > > No statement is currently available from the vendor regarding this > vulnerability. > > > > US-CERT Addendum > > Vendors and developers using the GNU C compiler should consider > downgrading their version of gcc or sticking with versions of the gcc > compiler (before version 4.1) that do not perform the offending > optimization. In the case of gcc, it should be emphasized that this is a > change of behavior in the later versions of the compiler. > > > > > > Why is this inaccurate? The objections to the original version of the note > on this list were that it appeared to advocate dumping gcc in favor of > another compiler that may do the same optimization. This addendum merely > suggest considering using an older version of gcc. Which is in general a bad advice as older gcc versions may have wrong-code bugs that are serious and have security implications if such bugs applies to your code. Richard.
Re: GCC port on PIC18xxx MCUs
On Wed, Apr 23, 2008 at 7:06 AM, Giorgis Georgakoudis <[EMAIL PROTECTED]> wrote: > I'm interested in creating a backend port of gcc for the PIC18xxx MCUs and > more specifically for PIC18F4550. If anyone has any past experience or > working code I would be delighted to hear from. As I've seen by searching > the mailing list archives there were some attempts in the past, any useful > comment is greatly appreciated. I had just asked if this was available a few days ago, so I would be greatly interested in your endeavours. Please keep me posted on your progress.
Re: US-CERT Vulnerability Note VU#162289
On Wed, Apr 23, 2008 at 09:06:56AM -0400, Chad Dougherty wrote: > David Miller wrote: > >CERT is asking these vendors for "approval" for the text they will add > >mentioning anything about their product. That's the bit I'm talking > >about. > > > >They are getting protection and consideration that was not really > >afforded to GCC. > > > >CERT treated GCC differently. > > This is not true. The "Statement" section of the vendor status is for > official, usually verbatim, statements from the vendor. The "Addendum" > section is reserved for our own comments, even those that may contradict > the vendor's response if we have reason to do so. I disagree; it is true. You did not ask for approval before adding GCC to "vulnerable". We have demonstrated to you by independent testing that other compilers are also vulnerable, and have provided the steps that you can use to confirm this. But you are dragging your feet on including other compilers on your "Vulnerable" list. Meanwhile, you still have an unfairly slanted advisory. If CERT is to maintain its reputation, it needs to do better. The warning is misdirected in any case; given the very large number of compilers that these coding practices cause trouble for, you need to focus on the bad coding practices, not on unfair demonization of new GCC releases.
dg-skip-if on powerpc when multiple cpu cflags specified
Hi,
I am returning to this issue and it is more
pressing testing powerpc on 4.3.0 and the trunk.
powerpc-rtems has gone from a relatively small
percentage of failures to >8300 and this warning
shows up a lot (5120334 times)!
Warning: /home/joel/work-gnat/svn/b-gcc1-powerpc/rtems_gcc_main.o uses
hard float,
/home/joel/work-gnat/svn/b-gcc1-powerpc/gcc/testsuite/gcc/20010124-1.x0
uses soft float
$ grep "hard float" ./gcc/testsuite/gcc/gcc.log | wc -l
5120334
The target is psim/603e.
rtems_gcc_main.o is the configuration file and RTEMS
initialization task setup for the gcc tests.
This file and the RTEMS library for were compiled with
hard float.
On this target, we really need to skip these tests to
get rid of all this noise. I can't even begin to tell what
else is broken.
I had the impression you weren't happy with the code
you proposed and didn't sweep it in. Is it an acceptable
solution? Or do you all have another idea?
Thanks.
--joel
Janis Johnson wrote:
On Fri, 2008-03-14 at 10:21 -0700, Janis Johnson wrote:
On Fri, 2008-03-14 at 10:18 -0500, Joel Sherrill wrote:
/* { dg-skip-if "" { *-*-* } { "-mcpu=405" } { "-mcpu=" } } */
I think this is doing what we want it to. It looks like it results
the tests getting run when -mcpu=405 and excluded when
-mcpu=603e is set on the board cflags.
The test directives are documented in the internals manual. From
sourcebuild.texi:
@item @{ dg-skip-if @var{comment} @{ @var{selector} @}
@{ @var{include-opts} @} @{ @var{exclude-opts} @} @}
Skip the test if the test system is included in @var{selector} and if
each of the options in @var{include-opts} is in the set of options with
which the test would be compiled and if none of the options in
@var{exclude-opts} is in the set of options with which the test would be
compiled.
The directive above says to skip the test on any target when
"-mcpu=450" is used and "-mcpu=" is not used. You'd actually
want "-mcpu=*", since "-mcpu=" isn't a full option, but then
the test will never be skipped whenever -mcpu=* is used.
Proc check_conditional_xfail from framework.exp in DejaGnu
processes the lists of included and excluded option and with
"--verbose --verbose" in RUNTESTFLAGS will print messages to
the test log (e.g. obj_dir/gcc/testsuite/gcc/gcc.log) about
its progress.
I think that dg-skip-if won't do what you need and you'll need
to add effective-target keywords.
On the other hand, to run a test for -mcpu=450 but no other -mcpu
option, this very ugly directive works (pattern matching is done
with globs):
/* { dg-skip-if "" { *-*-* } { "" } { "-mcpu=[0-35-9][0-46-9][1-9]*" } } */
That kind of thing could get ugly very quickly if there are
multiple cpus that would work.
Re: US-CERT Vulnerability Note VU#162289
On Wed, Apr 23, 2008 at 9:55 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 23, 2008 at 1:59 PM, Chad Dougherty <[EMAIL PROTECTED]> wrote: > > Brad Roberts wrote: > > Which is in general a bad advice as older gcc versions may have wrong-code > bugs that are serious and have security implications if such bugs applies to > your code. > Don't worry, they can issue advisories about those too
Re: US-CERT Vulnerability Note VU#162289
On Wed, Apr 23, 2008 at 12:25:06PM -0400, Daniel Berlin wrote: > On Wed, Apr 23, 2008 at 9:55 AM, Richard Guenther > <[EMAIL PROTECTED]> wrote: > > > > On Wed, Apr 23, 2008 at 1:59 PM, Chad Dougherty <[EMAIL PROTECTED]> wrote: > > > Brad Roberts wrote: > > > > Which is in general a bad advice as older gcc versions may have wrong-code > > bugs that are serious and have security implications if such bugs applies > > to > > your code. > > > > Don't worry, they can issue advisories about those too But not about any other compiler, at least not without the vendor's approval.
RE: US-CERT Vulnerability Note VU#162289
Mark Mitchell wrote on :
> Chad Dougherty wrote:
>
>> The vulnerability note has been significantly reworked to focus on the
>> issue of undefined behavior handling in the compiler and the fact that
>> conforming implementations are not required to warn of this condition.
>> I've tried to incorporate many of the valid concerns that were raise on
>> this list in response to the original vulnerability note.
>
> Thank you for making the update; this is a big improvement.
>
> However, I'm surprised that only GCC is listed as "vulnerable" at the
> bottom of the page. We've provided information about a lot of other
> compilers that do the same optimization. Why is the status for
> compilers from Microsoft, Intel, IBM, etc. listed as "Unknown" instead
> of "Vulnerable"?
I would like to see CERT publish a consistent and reliable methodology for
their assessment of this vulnerability in various compilers, and the full
results obtained from running this test methodology against the various listed
compilers, in enough detail that anyone can reproduce them. Consistency,
commensurability and reproducibility are at the heart of the scientific
method.
rCs has been trying very hard to address the issues raised with some code
examples, but what we've ended up seeing is differing and incommensurable code
examples that have been evaluated by differing and incommensurable standards
of validation - sometimes evaluating the generated assembly, sometimes just
looking at the output of the program (which is an indirect inference at best),
even in one notable case just throwing up his hands because he found the
generated assembly "harder to examine". I don't want to be mean about it, but
someone who is not utterly fluent in inspecting compiler-generated assembly
code should probably not be tasked with performing this analysis. It does not
inspire any confidence in whatever other results you have obtained without
"showing us your working".
Some cases appear to only be demonstrable in an artificial testcase where
the integer is a known constant at compile time, and vary with the value of
that constant.
These results are then presented in a table which simply lists a single
status for each vendor, when most vendors ship multiple products which may
differ in their behaviour.
This is not just trivium or pedantry. The procedures you have followed are
seriously flawed and unscientific, patchy, ad-hoc and inconsistent. The data
is fudged. The conclusions cannot be relied upon.
The flaws in your methodology are so severe, and yet CERT's insistence on
trying to draw invalid conclusions from these tests is so virulent, that your
actions seem inexplicably biased. The way in which you are operating a
blatant double standard, where you present a behaviour in gcc as a serious
flaw where you excuse, overlook or ignore the exact same behaviour in every
other vendor's compiler, gives credence to what would otherwise be a ludicrous
conspiracy theory: that CERT is acting under politically-inspired direction to
attack Open Source software by spreading FUD about it being insecure. Not
being paranoid, I can see the alternative ("cock-up not conspiracy")
explanation: that this VU was written in a hurry based only on the
notification you received relating to gcc, and was not planned properly, nor
researched properly, nor written accurately, in the course of its rushed
creation. However, the longer and more insistently you attempt to defend the
indefensible process through which you have arrived at this invalid outcome,
the more you undermine that line of defence and make the
politically-motivated-attack-on-OSS theory plausible, and you are after all a
government agency, and we do after all have a documented history in recent
years of the administration interfering with the publications of its agencies
and demanding the suppression of scientifically accurate facts and their
replacement by politically inspired factually incorrect information. There is
no reason that we know of to suppose CERT would be any more or less immune to
this sort of pressure than, for example, federally-funded scientific bodies
studying climate change.
But, damaging though that is to CERT as an organisation, it's still beside
the point, because regardless of your motivation, the fact is that your
procedures have been unscientific and do not support the conclusions you have
attempted to draw from them.
This VU falls massively far below the standards we have come to expect from
CERT, and should be withdrawn and reworked from scratch, before it causes
further damage to your reputation for professionalism and independence.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Official GCC git repository
> "Christopher" == Christopher Faylor <[EMAIL PROTECTED]> writes: Christopher> After consultation with Dan, I have set things up on Christopher> gcc.gnu.org so that the git repository is updated every Christopher> time an email message is received from the gcc-cvs Christopher> mailing list. Christopher> We'll be monitoring the system to see if there is a load Christopher> hit. If so, we'll probably drop back to Dan's original Christopher> method. It looks like the GIT repository hasn't been synced since yesterday. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/
RE: US-CERT Vulnerability Note VU#162289
Dave Korn wrote: [ ... lots of exciting commentary on scientific method/etc. that I leave out for the protection of the innocent ... ] Huzzah! Way to stick it to the man! :-) :-) > This VU falls massively far below the standards we have come to expect > from CERT, and should be withdrawn and reworked from scratch Good idea, although they already did rework it, and I doubt they're going to withdraw it when it really is a potential vulnerability that was apparently detected in the wild. Looking through the new version, it doesn't seem all that bad to me. The only problem is the GCC note, which has an untempered recommendation to consider old versions. That warning is still misguided, but you're not going to get very far trying to say it is entirely wrong. There *may be* someone that could be negatively affected by moving to a new version, and RCS has implied that they can name a case where this is true. Maybe we can convince them to temper the warning, I guess. [I mean really, changing the compiler in any way could trigger vulnerabilities if you have no idea what you're shoving into it. If you cannot depend at all on the quality of your code, test it well and never recompile it. But that path can easily devolve into a religious debate.] Meanwhile, there is an opportunity for a vendor response that will be added verbatim. Is anyone working on one for GCC? I think that would go a long way. gsw
Re: Official GCC git repository
On Wed, Apr 23, 2008 at 08:09:57PM +0200, Samuel Tardieu wrote: >> "Christopher" == Christopher Faylor <[EMAIL PROTECTED]> writes: > >Christopher> After consultation with Dan, I have set things up on >Christopher> gcc.gnu.org so that the git repository is updated every >Christopher> time an email message is received from the gcc-cvs >Christopher> mailing list. > >Christopher> We'll be monitoring the system to see if there is a load >Christopher> hit. If so, we'll probably drop back to Dan's original >Christopher> method. > >It looks like the GIT repository hasn't been synced since yesterday. > Yes: Apr 23 20:41:28 sourceware error: invalid object 6c380017b3c68b8efc917ae3447e62b0fd76b009 Apr 23 20:41:28 sourceware fatal: git-write-tree: error building trees; the index is unmerged? Apr 23 20:41:28 sourceware write-tree: command returned error: 128 What fun! cgf
Re: US-CERT Vulnerability Note VU#162289
From: Joe Buck <[EMAIL PROTECTED]> Date: Wed, 23 Apr 2008 08:24:44 -0700 > If CERT is to maintain its reputation, it needs to do better. The warning > is misdirected in any case; given the very large number of compilers that > these coding practices cause trouble for, you need to focus on the bad > coding practices, not on unfair demonization of new GCC releases. In my opinion CERT's advisory has been nothing but an unfair FUD campaign on compilers, and GCC specifically, and has seriously devalued CERT's advisories, in general, which were already of low value to begin with. It looks similar to a news article run by a newspaper that is losing money and has no real news to write about, but yet they have to write about something. The worst part of this fiasco is that GCCs reputation has been unfairly harmed in one way or another, and there is nothing CERT can do to rectify the damage they've caused.
gcc-4.2-20080423 is now available
Snapshot gcc-4.2-20080423 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080423/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 134604 You'll find: gcc-4.2-20080423.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080423.tar.bz2 C front end and core compiler gcc-ada-4.2-20080423.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080423.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080423.tar.bz2 C++ front end and runtime gcc-java-4.2-20080423.tar.bz2 Java front end and runtime gcc-objc-4.2-20080423.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080423.tar.bz2The GCC testsuite Diffs from 4.2-20080416 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Help me with the patterns
Hello all, The target that i am porting in gcc 4.1.2, has the following instructions setb Rx, bitno clrb Rx, bitno where bit bitno of Rx will either be set or reset. For statements like a |= (1 << 2); and b &= ~(1 << 2); I can use the above instructions directly. But i am not sure how to write the patterns for the above instructions. Can anybody help me with this? Thank you for your time. Regards, Shafi.
