Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 22, 2007, at 1:41 AM, Sergei Organov wrote:
>
>> Herman Geza <[EMAIL PROTECTED]> writes:
>>
>> [...]
>>
>>> What is the correct way to do this:
>>>
>>> void setNaN(float &v)
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
> What is the correct way to do this:
>
> void setNaN(float &v) {
> reinterpret_cast(v) = 0x7f81;
> }
>
> without a type-prunning warning? I cannot use the union trick here
Why? Won't the following work?
void setNaN(float &v) {
union {
"Bokhanko, Andrey S" <[EMAIL PROTECTED]> writes:
> Hi,
>
> As I learned from experience, gcc always assume independence between
> memory references in the following program:
>
> typedef struct {
> int m1;
> int m2;
> } S1;
>
> void foo(S1 *p1, S1 *p2) {
> ... = p1->m1;
> ... = p2->
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> On 30 May 2007 16:12:12 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> Joe Buck <[EMAIL PROTECTED]> writes:
>>
>> > How about: have -Wall still set warn_strict_overflow
>> > to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow
Hello,
The same programming error gives very different diagnostic using member
function and stand-alone function:
$ cat err1.cc
struct C {
static void f(char const*& p);
};
void b(char* p) {
C::f(const_cast(p));
}
$ cat err2.cc
extern void f(char const*& p);
void b(char* p) {
f(const_cast
Hello,
$ g++ -c err.cc
err.cc:7: error: prototype for 'void C::foo(const int&)' does not match
any in class 'C'
err.cc:3: error: candidate is: void C::foo(const T&) [with T = int]
err.cc:7: error: template definition of non-template 'void C::foo(const
int&)'
$
Note that substituting 'int' for '
[EMAIL PROTECTED] writes:
> Hi everybody,
>
> I'm currently working in a company, as embedded developper, which use gnu
> tools. I have a good experience about non gnu compiler tools and i need
> help because the most disavantage of gcc compiler is the almost unexistant
> support for developper.
R
Andrew Walrond <[EMAIL PROTECTED]> writes:
> On Tuesday 13 March 2007 14:32:38 Andrew Haley wrote:
>> ... a little tip. Add this to your c-mode-hook:
>>
>>(set-variable 'show-trailing-whitespace t)
>>
>> And you'll see all the trailing whitespace. On my system it appears
>> bright red.
>>
>
>
Kai Tietz <[EMAIL PROTECTED]> writes:
> Hi,
>
> I noticed while editing gcc files, that there are a lot of *useless*
> whitespaces at the end of lines or within empty lines, which are getting
> automatic removed by some *smarter* editors as I am common to use
> *sigh*.
Well, really smart editor
[EMAIL PROTECTED] (Richard Kenner) writes:
>> It also forbids embedded horizontal tabs for similar reasons (avoiding
>> junk difs).
>
> That would be a problem with GCC, due to emacs being so heavily used,
> but a similar convention *requiring* horizontal tabs would solve the
> issue in question.
Jan Hubicka <[EMAIL PROTECTED]> writes:
[...]
>> static inline void __attribute__((noreturn)) BUG(void)
>> {
>> __asm__ __volatile__("trap");
>> __builtin_unreached();
>
> This is bit dificult to do in general since it introduces new kind of
> control flow construct. It would be better t
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> > > Sergei Organov writes:
> > >
> > > > If we come back to strict aliasing rules, then I will have to refer
> once
>
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> >
> > BTW, I've tried once to raise similar aliasing question in
> > comp.std.c++. The result was that somebody started to talk about
> > validity of pointers conversions that IMHO has n
Silvius Rus <[EMAIL PROTECTED]> writes:
[...]
> I am about to submit a patch that implements -Wstrict-aliasing in the
> backend based on flow-sensitive points-to information, which is
> computed by analyzing the entire source of each function. It is not
> perfect (the problem is undecidable), but
Mike Stump <[EMAIL PROTECTED]> writes:
> On Jan 11, 2007, at 6:30 AM, Sergei Organov wrote:
>> So "h1.f" is not an object? If it is not, it brings us back to the
>> validity of my boo() function from the initial post, for which 2
>> persons
>> (3 inclu
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
>
> > If we come back to strict aliasing rules, then I will have to refer once
> > again to already cited place in the standard that says that I'm
> > permitted to access an object not
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > Sergei Organov writes:
> > > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > > >
> > > &
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > Sergei Organov writes:
> > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > > Sergei Org
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > Sergei Organov <[EMAIL PROTECTED]> writes:
> > >
> >
> > >> $ cat alias.c
> > &g
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> writes:
>
>> Below are two example functions foo() and boo(), that I think both are
>> valid from the POV of strict aliasing rules. GCC 4.2 either warns about
>> both (with -Wstri
Hello,
[I apologize for posting this question here, but I've tried to ask at
gcc-help, got no response, and don't actually know where else to ask]
Below are two example functions foo() and boo(), that I think both are
valid from the POV of strict aliasing rules. GCC 4.2 either warns about
both (w
Ian Lance Taylor writes:
> Sergei Organov <[EMAIL PROTECTED]> writes:
>
> > Laurent GUERBY <[EMAIL PROTECTED]> writes:
> > > If we add a library function to handle this we might want to
> > > add a GNU-style argument equivalent like
> > >
>
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> If we add a library function to handle this we might want to
> add a GNU-style argument equivalent like
>
> gcc --arguments-from-file=file
AFAIK gcc doesn't support any GNU-style arguments, isn't it?
I'd consider
gcc @file
gcc -@ file
gcc -args-from-
Index: invoke.texi
===
RCS file: /cvsroot/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.637
diff -u -r1.637 invoke.texi
--- invoke.texi 15 Jun 2005 12:53:41 - 1.637
+++ invoke.texi 1 Jul 2005 14:52:13 -
@@ -5225,7 +5
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
>
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FL
Michael Meissner <[EMAIL PROTECTED]> writes:
> On Mon, Jun 20, 2005 at 07:57:17PM +0400, Sergei Organov wrote:
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> > > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
> > >
> > > > Andr
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
>
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FL
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
>
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FL
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
>
> > so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
>
> > is turned on. Seems to be something at tree-to-RTX conversion time.
> > Constan
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:
>
> > 2. The resulting assembly is different from what I get with -O1 and
> >doesn't contain the mis-optimization I'm trying to debug though it
> >doesn&
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
> >> How one finds out what optimization pass misbehaves?
> >
> > Look at the dumps. If you use the gcc option -da you'll get a full
> > set of RTL dump files.
>
> And -fdump-tree-all for the tree dumps.
Andrew Haley <[EMAIL PROTECTED]> writes:
> Sergei Organov writes:
> > Hi,
> >
> > Using gcc compiled from gcc-4_0-branch, in an attempt to see which
> > particular optimization option makes my test case to be mis-optimized, I
> > try to replace
Hi,
Using gcc compiled from gcc-4_0-branch, in an attempt to see which
particular optimization option makes my test case to be mis-optimized, I
try to replace -O1 (which toggles on the problem) with corresponding set
of -fxxx optimization options. I first compile my code like this:
gcc -v -save-t
Mike Stump <[EMAIL PROTECTED]> writes:
> On Friday, June 17, 2005, at 07:13 AM, Sergei Organov wrote:
> > The first thing I'd like to get some advice on is which codebase do I
> > use, gcc-4_0-branch?
>
> No, mainline. If it doesn't work there, is won'
Hi,
The gcc-2.95.x seems to be the last GCC version that have usable support
for small data sections (.sdata & .sdata2) on PowerPC, see PRs 9571,
17337(resolved), and finally 21571.
As my embedded project heavily relies on the advantages of using small
data sections, it makes it impossible for me
35 matches
Mail list logo
