On Tue, Jul 29, 2008 at 5:17 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
>> Here's my first cut at trying to tell how well or how bad we perform
>> in terms of debug info, that can be dropped into the GCC run-time test
>> infrastructure and used b
On Tue, Jul 29, 2008 at 7:26 AM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Michael Matz wrote:
>>
>> You must be doing something wrong. If the compiler decides to inline the
>> string ops it either knows the size or you told it to do it anyway
>> (-minline-all-stringops or -minline-stringops-dynamica
On Tue, Jul 29, 2008 at 11:26 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>> g++ (v. 4.2.3) without any options converts memcpy with unknown size to rep
>> movsb
>
> Make sure to use -D__NO_STRING_INLINES to not get glibcs inline
> implementation.
Why is this not the default?
Gr.
Steven
Hello.
We have set up a new mirror. This is our information:
URL:
- http://mirror-fpt-telecom.fpt.net/gcc/
- ftp://mirror-fpt-telecom.fpt.net/mirror/gcc/
Location:
- Company: FPT Telecom
- City: HoChiMinh
- Country: Viet Nam
Contact:
- Name: Minh Vu Tong
- email: [EMAIL PR
Hello,
I found something rather strange with the unsigned comparison warnings
in GCC.
If i had,
unsigned char
a;
Hello.
the autovectorizer is enabled by default in g++ 4.3 and does a fine
job most of the time. Except it gets mightily pissed off if you dare
to tweak the alignment and after much experimentation i haven't yet
devised how to plug all the holes.
This silly example shows where things start to get u
Paolo Bonzini wrote:
Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof(X) in the code will return a value as
On Tue, 29 Jul 2008, Steven Bosscher wrote:
> On Tue, Jul 29, 2008 at 11:26 AM, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
> >> g++ (v. 4.2.3) without any options converts memcpy with unknown size to
> >> rep
> >> movsb
> >
> > Make sure to use -D__NO_STRING_INLINES to not get glibcs inline
>
On Tue, 29 Jul 2008, Paolo Bonzini wrote:
> Mark Mitchell wrote:
> > For that matter, "print sizeof(X)" should print the same value when
> > debugging optimized code as when debugging unoptimized code, even if the
> > compiler has optimized X away to an empty structure!
>
> I disagree. sizeof(X)
Hi,
On Tue, 29 Jul 2008, Agner Fog wrote:
> g++ (v. 4.2.3) without any options converts memcpy with unknown size to rep
> movsb
Use newer GCCs. They will (1) not expand memcpy inline for unknown sizes
(without special options, also make sure you don't get the glibc inlines)
and (2) won't exp
Agner Fog wrote:
Michael Matz wrote:
You must be doing something wrong. If the compiler decides to inline
the string ops it either knows the size or you told it to do it anyway
(-minline-all-stringops or -minline-stringops-dynamically). In both
cases will it use wider than byte moves when po
Hariharan <[EMAIL PROTECTED]> writes:
> I found something rather strange with the unsigned comparison warnings
> in GCC.
This is the wrong mailing list. The mailing list gcc@gcc.gnu.org is
for gcc developers. The mailing list [EMAIL PROTECTED] is for
questions about using gcc. Please take any
Kenneth Zadeck wrote:
Paolo Bonzini wrote:
Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof(X) in the code
On Jul 27, 2008, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> In that case, I'm not sure that *type* ought to be modified at all,
> from the debug perspective. To the extent there's still an object of
> type "struct X" around, it's type is still what it was. And other
> things you might do in a de
On Jul 29, 2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> Here's my first cut at trying to tell how well or how bad we perform
>> in terms of debug info, that can be dropped into the GCC run-time test
>> infrastructure and used by means of #inclu
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof(X) in the code will return a value as small as
possible in that case (so that
On Jul 29, 2008, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> why not pair the testcase with a gdb script directly?
Mostly a matter of convenience. Writing code and adding "test this
here, etc", and not having to adjust a testcase all over just because
you have to add an #include feels so muc
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of functi
Ken,
Thanks a lot for your feedback. Somehow your email fell through the
cracks and I didn't notice it until a colleague of mine reminded me.
Sorry for my delay in replying.
Here are my answers to your questions.
>
> All the examples seem to be C++ oriented; is it, in fact, a goal for the
> anno
On Tue, Jul 29, 2008 at 11:20 AM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> For that matter, "print sizeof(X)" should print the same value when
> debugging optimized code as when debugging unoptimized code, even if the
> compiler has optimized X away to an empty structure!
Daniel Berlin wrote:
If you built an AST that included sizeof before doing template
instantiation (which may not even be possible), you could at least
determine whether sizeof was used on a given type other than in a
malloc/new call (which we replace anyway).
Even if you did, I am allowed to k
On Tue, Jul 29, 2008 at 8:45 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
>> If you built an AST that included sizeof before doing template
>> instantiation (which may not even be possible), you could at least
>> determine whether sizeof was used on a given type other than
Daniel Berlin wrote:
The problem that sizeof creates is different, in that you have no way
to tell where it's been used.
The point is that even if you *did* know, that wouldn't help you.
Nothing in the language says that "sizeof (X)" is any different from a
constant that has that ABI-specifi
23 matches
Mail list logo
