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
cessary before actually joining the basic blocks/headers/footers to
a chain again. And you could create predicates that say yes/no on the
question "do I need to end this basic block (in cfglayout mode) with a
jump or not?"
Gr.
Steven
pulate the cfg ensure that the
insn stream and the CFG match. For cfglayout mode you have to do it by
hand. See the earlier discussion about the insn_added hook.
Gr.
Steven
But there've been several other mails about gcc 5.0 since then, too.
Maybe LTO is user-visible and lord-knows-what-breaking enough for a
major version number bump 5.0. Caret diagnostics could piggyback on
that :-)
Gr.
Steven
t;normal" instructions, you have to
somehow make the side-effects of your instructions clear. Otherwise,
dead code elimination will just remove the instructions (no
dependencies -> dead).
But you'd have to show what you're doing and what you're trying to
achieve, exactly, for a more helpful answer ;-)
Gr.
Steven
? make_signed_type (CHAR_TYPE_SIZE)
- : make_unsigned_type (CHAR_TYPE_SIZE));
+ ? build_distinct_type_copy (signed_char_type_node)
+ : build_distinct_type_copy (unsigned_char_type_node));
TYPE_STRING_FLAG (char_type_node) = 1;
short_integer_type_node = make_signed_type (SHORT_TYPE_SIZE);
Gr.
Steven
On Sun, Sep 21, 2008 at 2:28 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Index: tree.c
> ===
> --- tree.c (revision 140524)
> +++ tree.c (working copy)
> @@ -7364,8 +7364,8 @@
> bu
hat hasn't hampered either to be quite successful. And
w.r.t. GCC development - I don't know where/how the money flows, but
at least the publicly the contributions from Apple to the FSF GCC are
pretty marginal.
Gr.
Steven
g very much, not
> providing details on which SPEC tests regress in compile time is bad.
> Can you manually identify the worst offender, ideally by file? Or is it
> just overall regressing?
>
I can guess it is mostly overall regression.
It is. There are a few known common bottlenecks that still need fixing.
Gr.
Steven
cmp(r59:SI,0x7f)
22 pc={(flags:CCGC<=0x0)?L20:pc}
REG_BR_PROB: 0x238c
Note how the result of the second __tls_get_addr libcall is now unused
(this is done in CSE1 I think). So the second libcall is dead.
But without libcall notes, we just see a call_insn and a set to a hard
register, and we have no way to tell that the call_insn is dead and
can safely be removed.
So AFAIK we still need libcall notes to remove dead libcalls.
Gr.
Steven
't know, but in any case __tls_get_addr is neither pure nor const
(and for non-TLS libcalls, we don't have to know because we never make
them dead anyway ;-).
Gr.
Steven
gs that are confusing to me.
Your message is itself also a bit confusing. Fix what? What did you
mean in the "an and" sentence?
Gr.
Steven
r secondary
platform. So there is no reason to wait with the release because of
this PR, according to the release criteria (xf.
http://gcc.gnu.org/gcc-4.2/criteria.html).
Gr.
Steven
evelop.html#timeline
Being tentative, the timeline tends to be wrong ;-)
Gr.
Steven
/* Nor exit the loop. */
if ((then_edge->flags & EDGE_LOOP_EXIT)
|| (else_edge->flags & EDGE_LOOP_EXIT))
return NULL;
To prevent ifcvt from moving computations into loops. See this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01864.html
Gr.
Steven
already which has mentioned like 5 time already.
Let's make a guess: Mike still sees loop.c in GCC 4.2
*His* GCC 4.2 tree that is (Apple's)
Just like the last minute GCC 4.2 bug that wasn't an FSF GCC 4.2 bug ;-)
Joke joke...
Gr.
Steven
en.
I hope the list is useful for someone who wishes to improve GCC's
optimizations for code size.
Gr.
Steven
[1] http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00077.html
On 10/20/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> On Oct 20, 2007, at 4:48 AM, Steven Bosscher wrote:
>
> > I hope the list is useful for someone who wishes to improve GCC's
> > optimizations for code size.
>
> Is there a meta bug for code size op
in the entries to common.opt:
>
> -fipa-cp steven
I may have moved it around, I don't recall. But I did not add this option.
Gr.
Steven
, and makes it
harder to implement new ones safely.
The same issues arise with DEBUG_STMT for tree-ssa.
Is this really a design that has the necessary support to make the
branch eligible for merging into the trunk? What are the reasons for
using a fake insn instead of a note for DEBUG_INSN?
Thanks,
Gr.
Steven
ex has invented DEBUG_STMT, which has the same properties as
DEBUG_INSN in RTL (with one noteworthy difference, namely that having
note-like GIPMLE statements is a totally new concept while DEBUG_INSN
is just a wannabe-real-insn INSN_NOTE).
Gr.
Steven
r ask help from others)
if it is a priori not acceptable for stage 3.
Thus, thoughts please! :-)
(FWIW I have almost complete rewrites of half the passes in gcse.c,
and the attached patch is a kind-of back port of the ideas from my new
implementations...)
Gr.
Steven
* gcse.c (uid_cuid, max_uid, INSN
On Nov 18, 2007 7:28 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Nov 2007, Steven Bosscher wrote:
>
> > Question is, whether this kind of rather large changes is acceptable
> > for stage 3 or not. Me, I call it a "regression fix" if it reduces
>
On Nov 18, 2007 8:32 PM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Sun, 18 Nov 2007, Steven Bosscher wrote:
>
> > 2. But *I will not work on it* now (or ask help from others) if it is *a
> > priori* not acceptable for stage 3.
>
> As I parse your sentence, you w
a deleted insn). The removal of compute_sets() is
quite safe, because compute_sets() computes exactly the same
information as df-scan does.
> So, I don't want to promise that we would accept the patch in
> Stage 3, either.
OK, then, all things considered, I think I can better spend my time
modify. And the benefit, well, let's just say I'm not
convinced that less elaborate efforts are not sufficient.
(And to be perfectly honest, I think GCC has bigger issues to solve
than getting perfect debug info -- such as getting compile times of a
linux kernel down ;-))
Gr.
Steven
re is another "extremist" point of view:
Correctness for a optimization algorithm means that it does not miss
optimization opportunities that it is designed to catch. Therefore if
an optimization algorithm implementation misses an optimization that
it should catch, then this is a correctness issue.
;-)
You said you now get the same code with and without
-fvar-tracking-assignments on your branch. Can you also prove that
the branch does not introduce new missed optimizations wrt. the latest
revision that you merged from the trunk?
Gr.
Steven
d persue the idea. If sufficient people thing this is
a good idea, we can think about how to implement it. Or the idea can
be rejected. In either case, the enhancement can finally be closed.
Gr.
Steven
I'm asking for a policy here that says when it is OK to resolve old
bug without progress as WONTFIX or SUSPENDED. Start shooting.
Gr.
Steven
On Dec 19, 2007 4:32 PM, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 19, 2007 at 01:59:51AM +0100, Steven Bosscher wrote:
> > The current list of "All regressions" should be a list of bugs that
> > people are actively trying to resolve, prefe
On Dec 20, 2007 9:00 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
>
> > Alex, maybe you could add a Wiki page about this project
>
> Done, at last! :-)
>
> http://gcc.gnu.org/wiki/Va
Greetings.
I have a working MIPS cross toolchain with:
binutils-2.15
gcc-3.4.2
glibc-2.3.4
linux-2.6.12
and then decided to work with gcc-4.1.0 out of the cvs head. I am now
getting build problems with glibc-2.3.4 with the first major snafu
being:
../sysdeps/ieee754/dbl-64/s_isinf.c:
Greetings.
While I am getting closer to full toolchain build, GCC-4.1.0 is still
not behaving the way it should. Below is the output that I am running
up against. I attempted to define a stack variable to hold the value
of zero and tried using that instead of the actual value, but nothing
worked. I
Vincent Lefevre wrote:
You may be interested in my web page "Linux and the Extended Precision
on x86 Processors":
http://www.vinc17.org/research/extended.en.html
Also, comments are welcome.
William Kahan seems to take the opposite viewpoint. See e.g.:
http://www.cs.berkeley.edu/~w
zouqiong wrote:
i am surprised about it.
You seem surprised, and I am terrified you are using a compiler that
old. Please go look at:
http://kegel.com/crosstool/
which automatically builds cross toolchains and even still has
scripts to build your ancient (IMHO) combination.
-Steve
Greetings.
I have discovered what appears to be an optimization bug with '-Os'
in GCC-4.1.0 for the MIPS architecture. It appears that functions
which are declared as 'inline' are being ignored and instead turned
into to function calls which is breaking the dynamic linker loader
for uClibc on MIP
Richard Henderson wrote:
Not a bug. The inline marker is merely suggestive. You told
the compiler to optimize for size, and it is doing that.
If you absolutely have to have the function inlined, then you
need to use __attribute__((__always_inline__)).
This makes sense, but I also have a bin
Greetings.
I attempted to search through Bugzilla, but I did not find anything that
matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0,
I get an executable that will segfault. If I use all the other optimizations of
-O1, -O2 or -Os I do not have this problem. I am usi
Eric Christopher wrote:
I've not seen it, but do you see it with, say, those options and the
simulator testsuite? (I don't have one built at the moment or I'd check
myself.)
I assume you mean using the gdb simulator, or what? Sorry for my ignorance.
Otherwise, what's the code look like
Joe Buck wrote:
You might want to first make sure that your program has no memory
access errors. You could try building it for x86 and debugging
with valgrind, to see if that catches anything.
A good idea. I built it for x86. Unfortunately, from the output it
appears that 'clone' is not suppo
The interesting thing to note is that if I edit this and only do one
clone call, things work. As soon as I attempt to do a second clone,
things fall apart when debugging symbols with '-O0 -g' are compiled.
Again, the source link is below. I am going to have to make a note
of this bug and come back
I have spent the last couple of hours groking code and I am coming up
empty on this one. I ran into this problem when trying to build the
'tst-tls10' test program from glibc. This is not a glibc problem, rather
an issue with my library and kernel header files, I think. I have ported
NPTL support f
Jim Wilson wrote:
Those aren't symbolic registers. Those are variable names. Try looking
at the input file tst-tls10.c, and notice that it has variable names a1,
a2, and a3. So somehow, in your output, the variable name a1 got
replaced with the register name $5, which won't work.
*blush
When I compile this using gcc rev 3.4.5 (m68k-elf):
struct A { charB;
unsigned char & C; } __attribute__((packed));
unsigned char D;
A E = { 'F', D };
I get:
testpp.cpp:2: warning: ignoring packed attribute on unpacked non-POD
field `unsigned char&A::C'
sizeof( E ) == 6
Sent: Wednesday, December 07, 2005 8:03 AM
To: Steven L. Zook
Cc: gcc@gcc.gnu.org
Subject: Re: C++ 3.4.5 packed reference warning
Steven L. Zook wrote:
> When I compile this using gcc rev 3.4.5 (m68k-elf):
>
> struct A { charB;
>unsigned char & C; } __attribute_
On Thu, Aug 18, 2016 at 09:25:41AM +0100, Jonathan Wakely wrote:
> On 18 August 2016 at 08:59, Richard Biener wrote:
> > No, but you can try --enable-version-specific-runtime-libs
>
> But be aware that for multilib targets that's been broken for years, PR32415
Richi, Thanks for the pointer to the
Hello List,
I'm new to gcc internals. As part of an experiment, I copied the i386 back-end
in gcc 4.2.2 to create my own i386-like target arch. At some point, my hacking
caused my i386 to produce assembly with two memory touching operands in one
instruction, like this:
movl12(%eb
GSEGV signal. I coded up a small
illustration of how the exec strategy would work.
Thank you,
Steven Stewart-Gallus
#include
#include
#include
#include
/*
* In a real implementation this would be a real crash reporting
* program. It would use /proc to examine debugging information such
*
Thank you, I must then apologize to the GCC mailing list for bringing up
something off topic.
About GCC's _stack_chk_fail. Yeah, it's much simpler. Personally, I wouldn't
trust syslog but I'm not sure of a good alternative. I'll go bother the GLibc
people.
Thank you,
S
In the c++11 headers for the random number generation (random.h), the function
"discard" for the linear_congruential has been implemented in a very
inefficient manner. Many modern Monte Carlo codes require this function to
work efficiently across large strides through the random number stream.
Hello,
I want to take part in this project.
b. Write a plugin to add checking for usage of the CPython API (e.g.
reference-counting); see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646
I know the deadline is arriving, but this idea just came to me now.
Self-intro:
I am a fan of C++, and
Hi, Eric, Malcom,
Sorry that I didn't check this thread before.
It sounds like there are a lot of things to do. I want to offer some help.
Let me add some backgrounds of memory management in python here.
## Intro (for people unfamiliar with CPython)
Unlike programs written in C++, where the c
ogsal/cpython/pull/63
I will submit a proposal on (b) as soon as possible. And by the way, I can get
to work long before the start-coding timepoint of GSoC timeline.
From: David Malcolm
Sent: Monday, April 3, 2023 7:41
To: Sun Steven ; gcc@gcc.gnu.org
Subject: Re:
ion bugs.
CC me the relevant changes. I will review them when I am available.
Best,
Steven
Hi Eric, I am Steven (now) from the CPython team.
How is the project going? Do you have any prototypes
or ideas that can be discussed? Which part will you start at?
I recently debugged dozens of Python bugs, some involving
C APIs. I can provide some test cases for you.
For the ref count part
hole function definitions.
So it depends on the extension maintainer. I am observing this pattern
that popular libraries are gradually upgrading. 3.9 and 3.10 is definitely
the current mainstream.
Saying so, I think 3.9 is fine for now, but it will be outdated after 2 to 3
years.
Best,
Steven
1001 - 1056 of 1056 matches
Mail list logo
