On Mon, Jan 30, 2012 at 8:20 PM, Zoltán Kócsi wrote:
> On Mon, 30 Jan 2012 19:51:47 -0600
> Gabriel Dos Reis wrote:
>
>> On Mon, Jan 30, 2012 at 4:59 PM, Zoltán Kócsi wrote:
>> > David Brown wrote:
>> >
>> >> Until gcc gets a feature allowing it to whack the programmer on the back
>> >> of the
Sergei Dyshel writes:
> I need to profile a C++ program with 'gprof' but I'm only interested in
> virtual functions. Is it possible to get indication of virtual function in
> flat profile? As of now, virtual functions aren't marked in any special
> way inside demangled names.
Correct: the ma
On Mon, 30 Jan 2012 19:51:47 -0600
Gabriel Dos Reis wrote:
> On Mon, Jan 30, 2012 at 4:59 PM, Zoltán Kócsi wrote:
> > David Brown wrote:
> >
> >> Until gcc gets a feature allowing it to whack the programmer on the back
> >> of the head with Knuth's "The Art of Computer Programming" for writing
On Tue, 31 Jan 2012 00:38:15 +0100
Georg-Johann Lay wrote:
> A warning would be much of a help to write unambiguous, robust code.
> So the question is rather why user refuses to write robust code in the
> first place once there is a warning.
The user (me, in this case) does not refuse writing r
On Mon, Jan 30, 2012 at 4:59 PM, Zoltán Kócsi wrote:
> David Brown wrote:
>
>> Until gcc gets a feature allowing it to whack the programmer on the back
>> of the head with Knuth's "The Art of Computer Programming" for writing
>> such stupid code that relies on the behaviour of volatile "a = b = 0
glibc 2.15 won't build with GCC 4.7ish on ppc64: -fno-inline-functions
is no longer enough to prevent call_gmon_start from being inlined into
initfini.c's _init, as required by glibc's somewhat convoluted
compilation of initfini.c into crt*.o. As a result of the inlining, a
branch and its target l
Zoltán Kócsi schrieb:
paul_kon...@dell.com> wrote:
I would prefer this to generate a warning. The C language standard change
you refer to is a classic example of a misguided change, and any code whose
behavior depends on this deserves a warning message, NOT an option to work
one way or the oth
paul_kon...@dell.com> wrote:
> I would prefer this to generate a warning. The C language standard change
> you refer to is a classic example of a misguided change, and any code whose
> behavior depends on this deserves a warning message, NOT an option to work
> one way or the other.
Sure. Howeve
David Brown wrote:
> Until gcc gets a feature allowing it to whack the programmer on the back
> of the head with Knuth's "The Art of Computer Programming" for writing
> such stupid code that relies on the behaviour of volatile "a = b = 0;",
> then a warning seems like a good idea.
a = b = 0;
On 30/01/12 23:22, paul_kon...@dell.com wrote:
I would prefer this to generate a warning. The C language standard
change you refer to is a classic example of a misguided change, and
any code whose behavior depends on this deserves a warning message,
NOT an option to work one way or the other.
I would prefer this to generate a warning. The C language standard change you
refer to is a classic example of a misguided change, and any code whose
behavior depends on this deserves a warning message, NOT an option to work one
way or the other.
paul
-Original Message-
From:
Now that the new C standard is out, is there any chance that gcc's behaviour
regarding to volatile lhs in an assignment changes?
This is what it does today:
volatile int a, b;
a = b = 0;
translates to
b = 0;
a = b;
because the standard (up to and including C99) stated that the value of
Hello everyone,
Just a quick followup. This problem is now resolved. There is no
breakage in gcc, just a problem in the Fedora icu package. That package
contains some sed scripts in the "SPEC" (build description meta) file
that intentionally were munging the Makefiles used to build ICU such
that "
On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote:
> Hello,
>
> Chris Lattner skribis:
>
>> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote:
>>
>>> On 21 January 2012 00:32, Vincent Lefevre wrote:
On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
> May I politely suggest that
On 01/30/2012 05:26 PM, Jon Masters wrote:
>
> On Mon, 2012-01-30 at 08:50 +, Ramana Radhakrishnan wrote:
>
>> Therefore I'm assuming this is a breakage you face when building for
>> armv5te
>
> It is indeed. Thanks for noting that.
>
>>> The icu package contains a direct call to __sync_sy
Hi Ramana,
Thanks very much for getting back to me!
On Mon, 2012-01-30 at 08:50 +, Ramana Radhakrishnan wrote:
> On Mon, Jan 30, 2012 at 6:56 AM, Jon Masters wrote:
> > The __sync_synchronize "legacy" sync function is intended to be used to
> > perform an expensive data memory barrier operat
Hello,
Chris Lattner skribis:
> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote:
>
>> On 21 January 2012 00:32, Vincent Lefevre wrote:
>>> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
May I politely suggest that this is the wrong place to complain about
other compilers pret
essage is still there:
Int 2 foo (void)
{
return 1;
}
or here:
int foo 1(void)
{
return 1;
}
So the pain-to-the-eyes diagnose is still hanging around in the sources of
GNU C (GCC) version 4.7.0 20120130 (experimental) (avr)
Johann
>
> -Miles
>
This patchlet fixes length computation of "std %0,%1" and "st %0,%1" that
reported 2 instead of 1. The reason is that the insn length was accumulated and
added to the length of 1 already set in the caller.
These length are unconditionally set to 1 now because there is no code emit
before these ins
On Mon, Jan 30, 2012 at 6:56 AM, Jon Masters wrote:
> The __sync_synchronize "legacy" sync function is intended to be used to
> perform an expensive data memory barrier operation. It is defined within
> libgcc in such a way that I *believe* means that, on most architectures,
> it is replaced with
20 matches
Mail list logo
