Hello,
After a good night's sleep, I think I've found a way to write down more
clearly the rationale that motivates me.
It's about the semantics gcc can derive from the command line arguments.
It's a very efficient way of specifying about the desired result of the
compilation, but less about
陳韋任 writes:
> I am looking into config/arch which defines TARGET_MACHINE_DEPENDENT_REORG
> and
> trying to figure out what kind of operations might change the CFG.
When I want to look for a backend that does something crazy, I usually
start with sh. And sure enough, sh_reorg calls split_bran
Quoting "H.J. Lu" :
Do you have a testcase for i386?
struct args { int i0, i1; };
union args_u { struct args *a; } __attribute__((transparent_union));
union args_u
f (union args_u in)
{
union args_u out;
out.a = in.a + 1;
return out;
}
> >> Different targets use the machine reorg pass for all sorts of different
> >> things. Most of the code in reorg.c is actually not the machine reorg
> >> pass, it is the delay slots pass (pass_delay_slots). The machine reorg
> >> pass (pass_machine_reorg) simply calls targetm.machine_dependent
On Tue, Jun 14, 2011 at 5:44 PM, Joern Rennecke wrote:
> Quoting Bernd Schmidt :
>
>> * Most sane ABIs pass single-word structs in registers
>
> Unfortunately, the i386 SYSV ABI (used generally for i386 elf toolchains)
> is half-way insane in that respect: function return of small aggregates also
Quoting Bernd Schmidt :
* Most sane ABIs pass single-word structs in registers
Unfortunately, the i386 SYSV ABI (used generally for i386 elf toolchains)
is half-way insane in that respect: function return of small aggregates also
goes via a caller-passed pointer to a stack slot. (You can avoi
On 14 June 2011 23:53, Quentin Neill wrote:
> I wrote http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49411, and I have
> some general questions:
>
> 1. I left it as normal P3, is that appropriate for an obvious ICE like this?
The GCC release managers set the priorities, not bug reporters.
> 2. Shoul
This brings google/gcc-4_6 up to rev 175007.
Validated on x86_64.
Diego.
I wrote http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49411, and I have
some general questions:
1. I left it as normal P3, is that appropriate for an obvious ICE like this?
2. Should I open another bug for 4.6?
3. What's the best/right way to specify testcases in GCC bugs?
And the specific question
Snapshot gcc-4.4-20110614 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110614/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, Jun 14, 2011 at 2:51 PM, wrote:
>
>> We are working on a patch which will improve decimal
>> itoa by up to 10X. It will take a while to finish it.
>
> What's the method?
>
We use SSSE3 and SSE4 instructions for shift and multiply.
--
H.J.
> We are working on a patch which will improve decimal
> itoa by up to 10X. It will take a while to finish it.
What's the method?
I have a function converting 32 bit unsigneds to decimal which costs one
32x32->64 multiply with a constant (a single constant, not a look-up
table) plus a max. 8-ti
Hi Jakub,
On Tue, 14 Jun 2011, Jakub Jelinek wrote:
You'd use it as:
void
puthexl (unsigned long value, FILE *f)
{
char buf[2 + CHAR_BIT * sizeof (value) / 4];
if (value == 0)
putc ('0', f);
else
{
char *p = buf + sizeof (buf);
do
*--p = "0123456789abcdef"[value % 16];
Georg-Johann Lay writes:
> Ian Lance Taylor schrieb:
>> Georg-Johann Lay writes:
>>
>>> Am I something missing? Adding fragments to LIB1ASMFUNCS should filter
>>> them out in filter-out.
>>
>> I think the problem is that libgcc/config/avr/t-avr does not filter
>> LIB1ASMFUNCS out of the lists
Ian Lance Taylor schrieb:
> Georg-Johann Lay writes:
>
>> Am I something missing? Adding fragments to LIB1ASMFUNCS should filter
>> them out in filter-out.
>
> I think the problem is that libgcc/config/avr/t-avr does not filter
> LIB1ASMFUNCS out of the lists it generates. You will need to adju
On Tue, Jun 14, 2011 at 9:26 AM, Joseph S. Myers
wrote:
> On Tue, 14 Jun 2011, Matt Turner wrote:
>
>> I say this mail http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html
>> suggesting the addition of a --multilib= configure option. Has such a
>> thing been added? Is there a way to configure gcc to bu
I'm more relying on a hunch right now, than on a sound analysis. Maybe I'm
wrong...
I have to take a closer look at how ccache proceeds to speed up compilation
and precisely at how gcc internally uses I/O functions, to be more
articulate on the subject.
Maybe I could slowly and publicly form
Georg-Johann Lay schrieb:
> Hi, I intend to add some assembler sources to libgcc build.
>
> Using the straight forward way in ./gcc/config/avr/t-avr
>
> @ -52,7 +50,30 @@ LIB1ASMFUNCS = \
> ...
> + _ffssi2 \
> + _ffshi2 \
> + _loop_ffsqi2 \
> + _ctzsi2 \
> + _ctzhi2
Georg-Johann Lay writes:
> Am I something missing? Adding fragments to LIB1ASMFUNCS should filter
> them out in filter-out.
I think the problem is that libgcc/config/avr/t-avr does not filter
LIB1ASMFUNCS out of the lists it generates. You will need to adjust it
one way or another.
Ian
On Tue, 14 Jun 2011, Matt Turner wrote:
> I say this mail http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html
> suggesting the addition of a --multilib= configure option. Has such a
> thing been added? Is there a way to configure gcc to build only n32
No, the project has not yet reached that stage (r
Hi, I intend to add some assembler sources to libgcc build.
Using the straight forward way in ./gcc/config/avr/t-avr
@ -52,7 +50,30 @@ LIB1ASMFUNCS = \
...
+ _ffssi2 \
+ _ffshi2 \
+ _loop_ffsqi2 \
+ _ctzsi2 \
+ _ctzhi2 \
+ _clzdi2 \
+ _clzsi2 \
+ _c
On Tue, Jun 14, 2011 at 8:21 AM, Jakub Jelinek wrote:
> On Tue, Jun 14, 2011 at 05:59:47PM +0300, Dimitrios Apostolou wrote:
>> >>static void puthexl (unsigned long value, FILE *f)
>> >>{
>> >> static char hex_repr[16]= {'0', '1', '2', '3', '4', '5', '6', '7',
>> >> '8', '
Hi,
I'd like to ship multilib Gentoo/MIPS installations with only n32 and
n64 ABIs (ie, no o32). The reasoning is that if your system can use
either 64-bit ABI you don't have any reason to run o32, given that
o32-only installation media also exists.
I say this mail http://gcc.gnu.org/ml/gcc/2010-
Hello!
> This patch for AMD64 targets running GNU/kFreeBSD has been approved
> already, would anyone be so kind to commit it? I'm afraid I don't have
> write perms currently.
I have committed your patch to SVN mainline after bootstrapping it on
x86_64-pc-linux-gnu.
Thanks,
Uros.
On Tue, Jun 14, 2011 at 05:59:47PM +0300, Dimitrios Apostolou wrote:
> >>static void puthexl (unsigned long value, FILE *f)
> >>{
> >> static char hex_repr[16]= {'0', '1', '2', '3', '4', '5', '6', '7',
> >> '8', '9', 'a', 'b', 'c', 'd', 'e', 'f'};
> >> static char buf[2 +
"Franck Z" writes:
> In your opinion, could it be of any use in the project if I tried to
> merge ccache into gcc, so as to assess this "intelligent agent"
> approach ?
I didn't really understand your description, but there have been a
couple of gcc projects in this general space: compiler serve
Hi Jakub,
On Tue, 14 Jun 2011, Jakub Jelinek wrote:
On Tue, Jun 14, 2011 at 03:13:00PM +0300, Dimitrios Apostolou wrote:
parsing overhead and the hex conversion (implemented suboptimally in
Can you back that up? glibc conversion to hex representation is fairly
heavily optimized, see _itoa_wo
陳韋任 writes:
>> Different targets use the machine reorg pass for all sorts of different
>> things. Most of the code in reorg.c is actually not the machine reorg
>> pass, it is the delay slots pass (pass_delay_slots). The machine reorg
>> pass (pass_machine_reorg) simply calls targetm.machine_dep
On Tue, Jun 14, 2011 at 03:13:00PM +0300, Dimitrios Apostolou wrote:
> parsing overhead and the hex conversion (implemented suboptimally in
Can you back that up? glibc conversion to hex representation is fairly
heavily optimized, see _itoa_word in stdio-common/_itoa.h. In fact, I'd
say it is muc
This patch for AMD64 targets running GNU/kFreeBSD has been approved
already, would anyone be so kind to commit it? I'm afraid I don't have
write perms currently.
See: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00884.html
Thank you very much :-)
2011/6/10 Richard Henderson :
> On 06/10/2011 01
Hello list,
I've been working on my project full time since last week, and on a
part-time basis before then. Hopefully I'll be posting updates/patches
more often now that my exams are over. For anyone that wants to talk to
me, I'm jimis on the IRC.
I've looked a little into hash tables, symt
On Mon, 13 Jun 2011, Jason Merrill wrote:
> On 06/13/2011 06:51 AM, Richard Guenther wrote:
> > But I suppose you want the array-ref be folded to a constant eventually?
>
> Right.
>
> I'm not going to keep arguing about VIEW_CONVERT_EXPR, but that brings me back
> to my original question: is it
In your opinion, could it be of any use in the project if I tried to merge
ccache into gcc, so as to assess this "intelligent agent" approach ?
I can't really tell if, as for an underlying object-oriented structure that
is already present for serialization technique in gcc's source code, despit
> Sure: the document source is gcc/doc/cfg.texi. Thanks.
Already sent to gcc-patches. :-)
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01003.html
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-37
> Different targets use the machine reorg pass for all sorts of different
> things. Most of the code in reorg.c is actually not the machine reorg
> pass, it is the delay slots pass (pass_delay_slots). The machine reorg
> pass (pass_machine_reorg) simply calls targetm.machine_dependent_reorg,
> wh
35 matches
Mail list logo
