headers
Thomas Martitz | 1 Dec 2009 01:05
Picon

Re: Warning when using const pointer to fixed size array

Am 01.12.2009 00:46, schrieb me22:
> 2009/11/30 Thomas Martitz<thomas.martitz <at> student.htw-berlin.de>:
>    
>> What address are you taking? "array" already stands for the address of the
>> first element (and is hence sort of a pointer). I'm not sure you can take
>> the address of the array name as I think it doesn't have one.
>>
>>      
> You can, actually:
>
>      int main() {
>          int a[4];
>          int (*p)[4] =&a;
>      }
>    

I didn't try gcc, but visual studio compiler gives an error on that one.
Permalink | Reply | 10 comments |
headers
Thomas Martitz | 1 Dec 2009 01:08
Picon

Re: Warning when using const pointer to fixed size array

Am 01.12.2009 01:05, schrieb Thomas Martitz:
> Am 01.12.2009 00:46, schrieb me22:
>> 2009/11/30 Thomas Martitz<thomas.martitz <at> student.htw-berlin.de>:
>>> What address are you taking? "array" already stands for the address 
>>> of the
>>> first element (and is hence sort of a pointer). I'm not sure you can 
>>> take
>>> the address of the array name as I think it doesn't have one.
>>>
>> You can, actually:
>>
>>      int main() {
>>          int a[4];
>>          int (*p)[4] =&a;
>>      }
>
>
> I didn't try gcc, but visual studio compiler gives an error on that one.

Nevermind, I just tried copy&pasting yours and it worked. I guess I used 
something slightly different.
Permalink | Reply | 0 comments |
headers
me22 | 1 Dec 2009 01:08
Picon

Re: Warning when using const pointer to fixed size array

2009/11/30 Thomas Martitz <thomas.martitz <at> student.htw-berlin.de>:
>
> I didn't try gcc, but visual studio compiler gives an error on that one.
>

I tried it in gcc 4.3.2, where it worked fine.
Permalink | Reply | 8 comments |
headers
Aaron Rocha | 1 Dec 2009 01:24
Picon
Favicon

Re: Warning when using const pointer to fixed size array

This is the correct syntax when declaring a pointer to a fixed size array.
It is not something you usually see in C code but it is perfectly legal
syntax.

Back to my original question though. Why does gcc give that warning? It 
should be legal to point a const pointer to a non-const variable and use 
the pointer for read-only access, right? So why the warning? Is this a bug 
in GCC?

Cheers

--- On Mon, 11/30/09, me22 <me22.ca <at> gmail.com> wrote:

> From: me22 <me22.ca <at> gmail.com>
> Subject: Re: Warning when using const pointer to fixed size array
> To: "Thomas Martitz" <thomas.martitz <at> student.htw-berlin.de>
> Cc: gcc-help <at> gcc.gnu.org
> Received: Monday, November 30, 2009, 5:08 PM
> 2009/11/30 Thomas Martitz <thomas.martitz <at> student.htw-berlin.de>:
> >
> > I didn't try gcc, but visual studio compiler gives an
> error on that one.
> >
> 
> I tried it in gcc 4.3.2, where it worked fine.
> 

      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
(Continue reading)

Permalink | Reply | 7 comments |
headers
Lawrence Crowl | 1 Dec 2009 01:39
Picon
Favicon

Re: Efficient detection of signed overflow?

On 11/30/09, Florian Weimer <fw <at> deneb.enyo.de> wrote:
> * Mark Dickinson:
> > In practice, yes, I think so.  In theory, no: the result of the
> > conversion is implementation defined for numbers outside the
> > range of the signed type.  (C99 6.3.1.3).  But I'd be surprised
> > if any implementation on a two's complement machine does anything
> > other than just preserve the bit pattern, as you'd expect.
>
> It really depends on your compiler writer's meaning of
> "implementation-defined".  It's not too far-fetched that some
> think that the comparison against zero should be replaced with
> 0 because it can never be true.

Gcc does optimizations based on knowing that signed integer overflow
is undefined behavior.  It may not catch conversion right now,
but given time, it will.  Your best portability bet is to avoid the
overflow by first testing for the conditions under which overflow
will occur.

jmp_buf env;

long add( long a, long b )
{
    long x;
    if ( a > 0 )
        if ( LONG_MAX - a < b )
            longjmp( env, 1 );
        else
            x = a + b;
    else
(Continue reading)

Permalink | Reply | 12 comments |
headers
me22 | 1 Dec 2009 01:43
Picon

Re: Warning when using const pointer to fixed size array

2009/11/30 Aaron Rocha <hxdg21 <at> yahoo.com>:
>
> Back to my original question though. Why does gcc give that warning? It
> should be legal to point a const pointer to a non-const variable and use
> the pointer for read-only access, right? So why the warning? Is this a bug
> in GCC?
>

I'm unsure, but it's possible that the problem is that you're not
using a pointer to a const array of non-mutable elements, but a
pointer to non-const array with const elements.  (I have no idea how
"deep" const is with array types.)

It makes me think of this situation, though I don't know whether it applies:
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17

But that said, apparently this gives the warning too:

  int main() {
    typedef int atype[9];
    atype array = {};
    atype const* const p = &array;
    return (*p)[0];
  }

Which definitely wouldn't for a non-array type.
Permalink | Reply | 6 comments |
headers
He Yunlong-B20256 | 1 Dec 2009 03:29
Favicon

One question about gcc fix_includes

Hi, Experts,

	We are using one cross-compiler to compile native gcc, in out
test, we found that gcc will created "fixed includes" from host glibc
header files, I think they should come from the header files inside of
the cross-compiler, can anyone confirm that?

Thanks
Harry
Permalink | Reply | 5 comments |
headers
Sathish Kumar | 1 Dec 2009 07:26
Picon

Building an source code for an ARM processor

Dear Sir/Mam,

I am newbee to the ARM programming using GNU tools.

I had a Cygwin of version 2.95.2. Which is working well for normal c 
programs.

For ARM application, i downloaded the GNU ARM, and installed with 
default settings.

Unfortunately...the setup is not working...continuously i am getting 
the error saying "The procedure entry point __getreent could not be 
located in the dynamic link library cygwin1.dll."

Please kindly help me out.

Thanks &Regards,
Sathishkumar
Mail:sathishkumar.sigamani <at> aol.in
Permalink | Reply | 2 comments |
headers
Ira Rosen | 1 Dec 2009 08:28
Picon
Favicon

Re: "unhandled use" in vectorizing a dot product?


Benjamin Redelings <benjamin_redelings <at> ncsu.edu> wrote on 01/12/2009
01:24:15:

> Also, perhaps the documentation should explicitly say somewhere that
> vectorization can depend on flags like this.  "unhandled use in
> statement" certainly doesn't point the user to an idea of how to fix
> this :-P

The vectorizer prints:

 "unsafe fp math optimization: sum_18 = D.2721_17 + sum_26;"

But you are right, the bottom line printing:

 "not vectorized: unsupported use in stmt."

doesn't help much.

Ira

>
> -BenRI
>
>
Permalink | Reply | 5 comments |
headers
Ineiev | 1 Dec 2009 09:58
Picon

Re: Building an source code for an ARM processor

On 12/1/09, Sathish Kumar <sathishkumar.sigamani <at> aol.in> wrote:
> For ARM application, i downloaded the GNU ARM, and installed with
> default settings.
>
> Unfortunately...the setup is not working...continuously i am getting
> the error saying "The procedure entry point __getreent could not be
> located in the dynamic link library cygwin1.dll."

The problem is probably with GNU ARM or cygwin; if you want to use
these packages,
please ask their supporters.

In case if you don't mind to build the toolchain (GCC+binutils) from
their sources,
you may want to check this list archives; the topic was discussed no more
than a month or two ago.

Kind regards,
Ineiev
Permalink | Reply | 0 comments |

Gmane