Hello libstdc++ developers and users,
(I cc-ed gcc@gcc.gnu.org for a larger audience as others may offer
suggestions not as library developers but as C++ programmers. Sorry
in advance if this is spam to you.)
I'm planning to add a set of new performance diagnostics to the
libstdc++ profile mode
On Fri, May 7, 2010 at 7:09 AM, Karel Gardas wrote:
> with recent fixes into profile mode I've succeed even using it for
> MICO[1] on OpenSolaris platform. Is there any tool which
> translates call stacks to humans or is there any documentation/hint
> how to use generated call stack information t
On Tue, Dec 1, 2009 at 2:25 AM, Paolo Bonzini wrote:
>
> On 11/30/2009 09:47 PM, Michael Witten wrote:
>>
>> On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI
>> wrote:
>>>
>>> The patch which makes the MPC library a hard requirement for GCC
>>> bootstrapping has been approved today.
>>
>> Out of
I'm thinking about adding bitwise dataflow analysis support to RTL.
Is this a good idea? Bad idea? Already done? Please review if interested.
Thank you,
Silvius
Motivation
==
int foo(int x)
{
int i = 100;
do
{
if (x > 0)
x = x & 1; /* After this insn, all bits
Benjamin Kosnik wrote:
Hi Silvius Rus and Lixia Liu! Thanks for posting this, asking for
advice, and being willing to help improve libstdc++!
Goal: Give performance improvement advice based on analysis of
dynamic STL usage.
Your project sounds intriguing, and something that could
Doug Gregor wrote:
On Mon, Jul 14, 2008 at 7:20 PM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
In particular, design. The using bits seem pretty straightforward. It
would be nice if you could provide some detail in terms of scope (what
are the algorithms or data structures you intend to ins
Paolo Carlini wrote:
... finally (for now ;), an apparently pedantic issue, but really I'm going to strongly
object to any use of "STL" together with our implementation of the ISO C++
Runtime Library: it's a *legacy* HP / SGI acronym which is not used anywhere in the ISO
Standard in force (C++
Paolo Carlini wrote:
Also, maybe it's just me, but the specific advantages over normal profiling /
existing tools, don't seem completely obvious, I'd like to see that point
discussed in better detail...
Paolo.
The effect of our instrumentation is a meaningful trace of the behavior
of co
Paolo Carlini wrote:
libstdc++-v3 maintainers, could you please comment/advise?
Can you explain which is the role of the debug-mode code, here? Because certainly the
*performance* of the debug-mode library have *nothing* to do with the performance of the
"real" library (whether that coul
Lixia Liu ([EMAIL PROTECTED]) and myself started to work on a tool to
recognize STL usage patterns that can be corrected to increase
application performance. We believe this tool should live in
libstdc++-v3. We want to start a GCC branch to share what we have so
far and invite contributors.
Herman Geza wrote:
aliasing when GCC (I think) incorrectly treats types different, but
they're the same. For example, I have:
struct Point {
float x, y, z;
};
struct Vector {
float x, y, z;
Point &asPoint() {
return reinterpret_cast(*this);
}
Herman Geza wrote:
void foo(float *a) {
int *b = (int*)a; // type-punning warning
// here, access to a and b shouldn't be optimized, as the compiler
knows that a and b point to the same address
}
Is this reasonable?
Even if it were trivial to implement, I would vote against it, be
Sergei Organov wrote:
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
Herman Geza wrote:
struct A {
float x, y;
};
struct B {
float x, y;
};
int main() {
A a;
B &b = reinterpret_cast(a);
}
I get a type-punned warning for this code. However, A & B is exactly the
same type. Is the warning appropriate here?
Unfortunately gcc 4.3
This may have been fixed by a recent patch to -Wstrict-aliasing. Let me
try to run the latest version of pre4.3 and will get back to you.
Herman Geza wrote:
Hi,
gcc's docs states that at -fstrict-aliasing:
"In particular, an object of one type is assumed never to reside at the
same address
Tim Prince wrote:
[EMAIL PROTECTED] wrote:
Where is gstdint.h ? Does it acctually exist ?
libdecnumber seems to use it.
decimal32|64|128.h's include decNumber.h which includes deccontext.h
which includes gstdint.h
When you configure libdecnumber (e.g. by running top-level gcc
configure), g
I am implementing -Wstrict-aliasing by catching simple cases in the
frontend and more complex ones in the backend. The frontend mechanism
is tree pattern matching. The backend one uses flow-sensitive points-to
information.
I want to avoid duplicate warnings. I thought of a few ways, but n
Andrew Pinski wrote:
Third, it only checks C programs (and not C++).
This has not been true for some time now (at least developmental wise).
-- Pinski
Oops, had not noticed that. Forget third argument then.
Silvius
Sergei Organov wrote:
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 -Wstrict-aliasing=2) o
Joe Buck wrote:
If you first prove that there is no cross-type aliasing, then turn on
-fstrict-aliasing, it seems to me that your alias sets won't change at
all. The reason is that if there is a change, it means that you
eliminated an aliasing possibility based on the fact that it's not
allowe
Joel Sherrill wrote:
Silvius Rus wrote:
I wrote some code (not released yet) that improves the accuracy of
-Wstrict-aliasing using tree-ssa-alias information. The primary idea
was to tell the programmer "go fix the types of variables x and y at
lines ..." when -fstrict-alias
I wrote some code (not released yet) that improves the accuracy of
-Wstrict-aliasing using tree-ssa-alias information. The primary idea
was to tell the programmer "go fix the types of variables x and y at
lines ..." when -fstrict-aliasing breaks their code.
It occurred to me that part of th
22 matches
Mail list logo
