Hello All,
I have committed the patch to 4.3 branch and mainline.
Thanks a lot for considering the removal of deprecation. Many thanks to
all who reviewed the patch.
Regards,
Pompa
Richard Guenther wrote:
On Mon, Apr 21, 2008 at 10:40 AM, Pompapathi V Gadad
<[EMAIL PROTECTED]> wrote:
Hello
Robert C. Seacord wrote on :
> I am getting tired with the personal/organizational attacks.
> If you expect a response, please keep your comments professional.
Will you address the methodological flaws in your study, or do you consider
them to be "personal/organizational attacks"?
cheers,
We (ARC) intend to contribute our improvements to the ARC gcc/binutils
support once our Copyright assignment is in place.
We are currently considering removing the ARCtangent-A4 support from
our sources, as we don't need it anymore. The only reason to keep the
code would be to facilitate merges wi
Mark Syddall wrote:
^
Should read "Dave Korn." Apologies all recipients, we had mailserver
trouble at this end and somehow some of the resends got the admin's From: line
on them by mistake.
> Robert C. Seacord wrote on :
>
>> I am getting tired with the personal/organizational at
apparently for all single-thread targets (like cris-elf).
Could it be that you forgot to actually test that this works on
single-thread targets? Or how did you test that?
Build worked with trunk 134647 and was broken with 134655 (still
broken with 134662 in the same way), yours being the only
su
One thing to realize in this discussion is that it is not
possible in general to warn when a programmer is depending
on undefined behavior, since by definition you cannot in
general guess what misunderstandings the programmer has
about C, and hence what behavior is expected.
There are some cases
Another general point is that conceptually this is not
an optimization issue at all.
The programmer writes code that is undefined according
to the standard.
Whatever expectation the programmer has for this code
is based on either a fundamental misunderstanding of
the semantics of C, or there is
Paul Koning wrote:
That said, it certainly is helpful if the compiler can detect some
undefined actions and warn about them. But that doesn't create a duty
to warn about all of them.
If it were reasonable to require a compiler to generate a warning
for a particular case, the standard would ha
Robert Dewar wrote:
Paul Koning wrote:
That said, it certainly is helpful if the compiler can detect some
undefined actions and warn about them. But that doesn't create a duty
to warn about all of them.
If it were reasonable to require a compiler to generate a warning
for a particula
Robert Dewar wrote on :
> One thing to realize in this discussion is that it is not
> possible in general to warn when a programmer is depending
> on undefined behavior, since by definition you cannot in
> general guess what misunderstandings the programmer has
> about C, and hence what behavior i
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Another general point is that conceptually this is not an
Robert> optimization issue at all.
Robert> The programmer writes code that is undefined according to the
Robert> standard. ...
Robert> To me, the whole notion of thi
On 4/24/08, Robert C. Seacord <[EMAIL PROTECTED]> wrote:
> If you are referring to VU#694123, this refers to an optimization that
> removes checks pointer arithmetic wrapping. The optimization doesn't
> actually eliminate the wrapping behavior; this still occurs. It does,
> however, eliminate cer
On Fri, Apr 25, 2008 at 11:45:25AM -0400, Paul Koning wrote:
> Robert> To me, the whole notion of this vulnerability node is flawed
> Robert> in that respect. You can write a lengthy and useful book on
> Robert> pitfalls in C that must be avoided, but I see no reason to
> Robert> turn such a bo
Daniel Jacobowitz wrote:
The R in CERT is "Response" (at least it used to be; I can't find an
expansion on their web site...). They're responding to a problem that
was reported to them, and alerting others to the problem. We can
argue about the details, but not about the need to respond.
I a
Daniel Jacobowitz wrote on :
> On Fri, Apr 25, 2008 at 11:45:25AM -0400, Paul Koning wrote:
>> Robert> To me, the whole notion of this vulnerability node is flawed
>> Robert> in that respect. You can write a lengthy and useful book on
>> Robert> pitfalls in C that must be avoided, but I see no
> apparently for all single-thread targets (like cris-elf).
>
> Could it be that you forgot to actually test that this works on
> single-thread targets? Or how did you test that?
Reverted on the branch, fixing on trunk. Sorry, you are correct. I did
not test single thread targets.
-benjamin
* Robert Dewar:
> To me, the whole notion of this vulnerability node
> is flawed in that respect. You can write a lengthy
> and useful book on pitfalls in C that must be
> avoided, but I see no reason to turn such a book
> into a cert advisory,
I think it's useful to point out in security advisor
http://gcc.gnu.org/onlinedocs/gccint/Back-End.html
This mentions a file "config.gcc" which I can't find in the GCC source.
This page tells too little I guess.
http://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html
This stuff would be useful if the GCC build process recognized that I
made s
http://gcc.gnu.org/onlinedocs/gccint/Back-End.html
This mentions a file "config.gcc" which I can't find in the GCC source.
This page tells too little I guess.
Its under the 'gcc' directory.
Aaron
> Mike writes:
Mike> Is there a short list of steps to get a very minimal machine specific
Mike> back end going? Please point me to some better documents? :)
http://gcc.gnu.org/wiki/GettingStarted
http://www.cfdvs.iitb.ac.in/~amv/gcc-int-docs/
Most new backends start by copying an exist
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
> Hi, Peter. The last time I looked at the conflict builder
> (ra-conflict.c), I did not see the compressed matrix. Is it in the
> trunk? What should I look at?
Yes, the compressed bit matrix was committed as revision 129037 on
Octobe
Snapshot gcc-4.4-20080425 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080425/
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
Doing a build of gcc from revision 134693 with
build=host=x86_64-pc-linux and target=i686-pc-mingw32 yields the
following mess of errors:
[EMAIL PROTECTED]:/var/tmp/g-tw64$ make > /dev/null
ctype_members.cc: In member function 'virtual char
std::ctype::do_narrow(wchar_t, char) const':
ctype_membe
23 matches
Mail list logo
