On Tue, Mar 27, 2012 at 8:59 PM, Mike Stump wrote:
>> and errors from the middle end are mostly for exotic
>> code (involving asm()s and the like). Bailing out after parse errors
>> is therefore IMHO the right thing to do for the common case.
>
> Some are for very exotic things, yes, but not all o
Hello,
If I move GIMPLE_SWITCH lowering from stmt.c to somewhere in the
GIMPLE pass pipeline, I run into an issue with SJLJ exceptions. The
problem is that except.c:sjlj_emit_dispatch_table() builts a
GIMPLE_SWITCH and calls expand_case on it. If I move all non-casesi,
non-tablejump code out of st
Hello,
I ported the code to expand switch() statements with bit tests from
stmt.c to GIMPLE, and looked at the resulting code to verify that the
transformation applies correctly, when I noticed this strange PHI-OPT
transformation that results in worse code for the test case of PR45830
which looks
On Mon, Apr 23, 2012 at 2:27 PM, Richard Guenther
wrote:
> int foo (_Bool b)
> {
> if (b)
> return 1;
> else
> return 0;
> }
Indeed PHI-OPT performs the transformation on this code, too. But the
resulting code on powerpc64 is fine:
[stevenb@gcc1-power7 gcc]$ cat t.c.149t.optimized
;; Fu
On Mon, Apr 23, 2012 at 4:43 PM, Alan Modra wrote:
> On Mon, Apr 23, 2012 at 02:50:13PM +0200, Steven Bosscher wrote:
>> csui = (ONEUL << a);
>> b = ((csui & cst) != 0);
>> if (b)
>> return 1;
>> else
>> return 0;
>
> We
On Mon, Apr 23, 2012 at 2:50 PM, Steven Bosscher wrote:
> I will file a PR for this later today, maybe after trying on a few
> other targets to see if this is a middle-end problem or a target
> issue.
This is now PR target/53087 (http://gcc.gnu.org/PR53087).
Actually the poor code lo
Hello,
GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
for targets to be deprecated. I have one I would like to put on the
list, so here's something to start a discussion with:
Deprecate all support for 32-bits HP-PA. This includes HP-UX10, and
PA-7000 and older.
To name
On Mon, May 7, 2012 at 7:42 PM, Jeff Law wrote:
> On 05/07/2012 11:33 AM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
>> for targets to be deprecated. I have one I would like to put on the
&
On Mon, May 7, 2012 at 9:14 PM, John David Anglin wrote:
> The maintenance problems that occur are usually not related to the code
> generation. They largely occur because the target is big endian, strict
> alignment, callee copies, etc. The delayed branch support has caused
> many subtle bugs.
Hi,
I noticed gcc predicts huge sizes for asm statements on ix86. This is
due to define_asm_attributes in i386.md, where the length *per single
instruction* in the asm is set to 128. That doesn't look realistic to
me. Is there a good reason for this large value? Or should something
like the patch
On Tue, May 8, 2012 at 1:28 AM, Jan Hubicka wrote:
> The idea here was originally to prevent LOOP instruction to get out of bounds.
> ASM statement even if they are single line may be arbitrary long and thus can
> run out of the limits.
Arbitrary long, but interrupted by semi-colons? From the
def
On Tue, May 8, 2012 at 1:56 PM, Ulrich Weigand wrote:
> Steven Bosscher wrote:
>
>> 2. HP-UX 10 is also the last target that only supports SJLJ exceptions.
>
> Hmm, SPU also supports only SJLJ exceptions ...
Then why is force_sjlj_exceptions not set for it?
Ciao!
Steven
On Wed, Apr 18, 2012 at 2:44 PM, Richard Henderson wrote:
> On 04/18/2012 05:39 AM, Jan Hubicka wrote:
>> Well, if SJLJ lowering happens as gimple pass somewhere near the end of
>> gimple
>> queue, this should not be problem at all. (and implementation would be
>> cleaner)
>
> If you can find a
On Sat, May 12, 2012 at 3:49 PM, Jan Hubicka wrote:
>> On Wed, Apr 18, 2012 at 2:44 PM, Richard Henderson wrote:
>> > On 04/18/2012 05:39 AM, Jan Hubicka wrote:
>> >> Well, if SJLJ lowering happens as gimple pass somewhere near the end of
>> >> gimple
>> >> queue, this should not be problem at a
On Mon, May 14, 2012 at 4:23 PM, Richard Henderson wrote:
> On 05/12/12 06:00, Steven Bosscher wrote:
>> * toplev.c (process_options): Fail for sjlj exceptions if the
>> target machine
>> has no casesi insn and no tablejump insn.
>
> Looks good. How man
Hello,
In gcse.c:insert_insn_end_basic_block() I found the following code:
#ifdef HAVE_cc0
/* FIXME: 'twould be nice to call prev_cc0_setter here but it aborts
if cc0 isn't set. */
note = find_reg_note (insn, REG_CC_SETTER, NULL_RTX);
if (note)
insn = XEXP (not
Hello,
In a perfect world, front ends would not be writing out anything to
the assembler output. GCC is not part of this perfect world, at least
not yet. It should be possible, with a little help from front-end
maintainers, especially for Ada and ObjC and someone knowledgeable of
PCH, to enforce a
On Mon, Jun 4, 2012 at 2:40 PM, Steven Bosscher wrote:
> asm_out_file for PCH:
> c-family/c-pch.c:#include "output.h" /* for asm_out_file */
> c-family/c-pch.c: fprintf (asm_out_file, "%s ", ASM_COMMENT_START);
> c-family/c-pch.c: c_common_print_pch_check
On Mon, Jun 4, 2012 at 3:34 PM, Richard Guenther
wrote:
>> have_global_bss_p:
>> cp/decl.c: && !have_global_bss_p ())
>> ada/gcc-interface/utils.c: && !have_global_bss_p ())
>>
>> I don't even know what this is. Help welcome. :-)
>
> Looks like premature optimization to me, better done i
On Mon, Jun 4, 2012 at 4:47 PM, Richard Guenther
wrote:
> OTOH, I suppose including target.h from the FEs is against what you
> want to achieve, too.
Yes, that would be the ideal case. But some target dependencies are
inevitable, e.g. the target CPP macros. What I'd like to see
eventually, is tha
On Mon, Jun 4, 2012 at 3:34 PM, Richard Guenther
wrote:
>> first_global_object_name:
>> ada/gcc-interface/trans.c: first_global_object_name = ggc_strdup
>> (IDENTIFIER_POINTER (t));
>> ada/gcc-interface/utils.c: ASM_FORMAT_PRIVATE_NAME (label,
>> first_global_object_name, 0);
>>
>> This come
On Mon, Jun 4, 2012 at 4:52 PM, Richard Guenther
wrote:
>>> I suppose make ASM_OUTPUT_IDENT a target hook instead.
>>
>> This doesn't really help: You'd now have a target hook called from the
>> front end that writes to asm_out_file. I want front ends to stop
>> writing to asm_out_file at all.
>
>
On Mon, Jun 4, 2012 at 4:55 PM, Richard Guenther
wrote:
>> I mean make the whole "write #ident" a target hook.
>
> Another possibility would be to generate a toplevel asm at this point ...
Yes, that might work, I'll try that. Thanks for the ideas and suggestions!
Ciao!
Steven
On Mon, Jun 4, 2012 at 4:58 PM, Manuel López-Ibáñez
wrote:
>> Yes, that would be the ideal case. But some target dependencies are
>> inevitable, e.g. the target CPP macros. What I'd like to see
>> eventually, is that targetm will be split up in front end and
>> middle/back end specific parts.
>
>
On Mon, Jun 4, 2012 at 7:20 PM, Eric Botcazou wrote:
>> The code for the case in Ada is this:
>>
>> /* Ada doesn't feature Fortran-like COMMON variables so we shouldn't
>> try to fiddle with DECL_COMMON. However, on platforms that don't
>> support global BSS sections, uninitialized gl
On Mon, Jun 4, 2012 at 10:04 PM, David Edelsohn wrote:
> On Mon, Jun 4, 2012 at 3:53 PM, Steven Bosscher wrote:
>
>> What I don't understand, is whether this is still something GNAT has
>> to support, or whether this code can be deprecated/removed. And I ask
>> for
On Mon, Jun 4, 2012 at 11:08 PM, Eric Botcazou wrote:
>> Hmm, Mach-O does have BSS.
>
> OK, bad memory, this was for Tru64.
... which has been deprecated for GCC 4.7 (see
http://gcc.gnu.org/gcc-4.7/changes.html). Support for Tru64 has
already been removed on trunk. Tru64 was ECOFF, right? That me
On Mon, Jun 4, 2012 at 11:08 PM, Eric Botcazou wrote:
>> Hmm, Mach-O does have BSS.
>
> OK, bad memory, this was for Tru64.
Could it be that there is a bug in the way .bss section selection
works? Looking through the documentation, it seems actually rather
hard to miss the .bss section:
@defmac
On Tue, Jun 5, 2012 at 7:57 AM, Eric Botcazou wrote:
>> ... which has been deprecated for GCC 4.7 (see
>> http://gcc.gnu.org/gcc-4.7/changes.html). Support for Tru64 has
>> already been removed on trunk. Tru64 was ECOFF, right? That means that
>> Tru64 also has BSS
>> (http://h30097.www3.hp.com/do
On Tue, Jun 5, 2012 at 1:07 PM, Eric Botcazou wrote:
>> Part of the problem why it isn't put there by gcc 4.7 because the
>> initializer is not a bss_initializer_p initializer. And this is
>> because GNAT explicitly disables this in misc.c:
>>
>> /* Initialize options structure OPTS. */
>>
>> sta
On Tue, Jun 5, 2012 at 3:47 PM, David Edelsohn wrote:
> On Tue, Jun 5, 2012 at 7:07 AM, Eric Botcazou wrote:
>
>>> The same happens for rs6000-ibm-aix6.1, which also doesn't have
>>> BSS_SECTION_ASM_OP, even though there should be BSS support for XCOFF
>>> (http://pic.dhe.ibm.com/infocenter/aix/v
On Tue, Jun 5, 2012 at 4:15 PM, Iain Sandoe wrote:
> As it happens, the code should be as well-tested as for V1 as V2 ABI -
> since it is conventional to test ObjC/NeXT at m32(V1) and m64(V2) [[and
> also the GNU runtime (on Darwin)]].
>
> So whilst Darwin is not as well-tested as linux, at least
On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe wrote:
> I would welcome a simple solution if one is available, although I don't quite
> see what you have in mind at present.
This is what I have in mind. Untested, but it shows the idea. What do
you think of this?
Ciao!
Steven
gcc/
* config/
On Wed, Jun 6, 2012 at 10:07 PM, Iain Sandoe wrote:
> Hi Steven,
> The attached patch survives normal and lto bootstrap on i686-darwin9 and
> x86_64-darwin10.
> No regressions for ObjC or Obj-C++.
> Otherwise, lightly tested, but appears to solve PR 48109 on the way.
>
> changes:
>
> o [minor] t
Hello,
I am confused by the following code in
ifcvt.c:noce_mem_write_may_trap_or_fault_p():
static bool
noce_mem_write_may_trap_or_fault_p (const_rtx mem)
{
rtx addr;
if (MEM_READONLY_P (mem))
return true;
(...)
addr = XEXP (mem, 0);
/* Call target hook to avoid the effects of -fpi
Hello,
By my count, there are a lot of undocumented target macro defines that
are darwin specific. In total there are 59 undocumented cases, and 16
of them are darwin specific.
(To get to this count, I've simply looked at all #defines in config/*
+ config/*/*, looked up the ones that are used in t
Hello,
Since r188786, expmed.c has this code:
bool is_neg;
(...)
if (CONST_INT_P (scalar_op1))
{
coeff = INTVAL (scalar_op1);
is_neg = coeff < 0;
}
else if (CONST_DOUBLE_P (scalar_op1))
{
if (CONST_DOUBLE_HIGH (scalar_op1) ==
On Wed, Jul 4, 2012 at 4:25 PM, Uros Bizjak wrote:
> Hello!
>
>> Since r188786, expmed.c has this code:
>
>> This results in warnings for expmed.c during bootstrap on
>> powerpc64-unknown-linux-gnu:
>>
>> ../../trunk/gcc/expmed.c: In function ‘rtx_def* expand_mult(machine_mode,
>> rtx,
>> rtx, rt
Andreas Enge wrote:
> Unfortunately, several primary and secondary gcc targets are still missing:
Have you looked at the MAINTAINERS file and contacted some maintainers directly?
> mipsis64-elf,
No idea who could do this for you.
> sparc-sun-solaris2.10,
Perhaps Rainer Orth can help?
> hppa
Hello Joseph,
In revision 175064 you introduced a new subdirectory: gcc/common.
This directory is not documented in sourcebuild.texi. Can you please
add documentation for it?
Thanks,
Ciao!
Steven
Bin Cheng wrote:
> I have already worked out an initial patch to extend the pass in two ways:
> 1. extend it into a global pass;
> 2. make it handle const propagation;
You'll find this is not quite so easy as what you describe. Changing
constants after reload is harder and less effective than befo
Bin Cheng wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
You could foster-parent and fix the attached patch to address this issue.
(I'm not interested in pursuing this further myself.)
Ciao!
Steven
cse_uncprop.diff
Description: Binary data
On Wed, Jul 25, 2012 at 3:35 AM, Bin.Cheng wrote:
> On Wed, Jul 25, 2012 at 2:14 AM, Steven Bosscher
> wrote:
>> Bin Cheng wrote:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
>>
>> You could foster-parent and fix the attached patch to address this
On Tue, Jul 31, 2012 at 4:06 PM, Bin.Cheng wrote:
>>
>> For the other PR you mentioned, that looks like a register allocation
>> regression, that should be addresses in IRA rather than in regcprop.
>
> not sure whether this is a RA regression.
Well, it worked before, and now it doesn't. Maybe RA
Hello,
There are ~1000 uses of gen_rtx_SET in gcc, excluding generated files.
The vast majority generate a SET with VOIDmode, but a few (less than
100) use a non-VOIDmode SET.
What is the meaning of the mode on a SET?
Ciao!
Steven
Hello Richi,
After a frustrating few days of trying to figure out what *I* was
doing wrong trying to speed up rewrite_into_loop_closed_ssa(), I
finally gave up and looked at the rest of GCC. One wouldn't expect
anything to be very broken in an unpatched tree, after all, but the
kind of failures I
On Sat, Aug 11, 2012 at 11:16 PM, Steven Bosscher wrote:
> Lots of test cases fail with the attached patch.
Lots still fail after correcting the verifier :-)
920723-1.c: In function 'f':
920723-1.c:14:1: error: bb 13 has loop depth 2, should be 1
f (int count, vector_t * pos, dou
On Mon, Aug 13, 2012 at 1:27 PM, Richard Guenther
wrote:
> I wonder why we cache loop-depth at all ... given that it is a "simple"
> dereference bb->loop_father->superloops->base.prefix.num. For all
> the hassle to keep that cache up-to-date, that is.
The cached bb->loop_depth saves two indirect
Hello,
Bootstrap is currently broken on x86 targets with binutils 2.20 (from
2009) and older (PR54419) because the rdrand instruction is emitted
but that instruction is only supported in binutils 2.21 and later.
This means bootstrap is broken on almost all x86_64 machines in the
compile farm for e
Hello Vlad,
Is it intentional that DF_LR_IN and DF_LR_OUT are not updated after
"Updating elimination of equiv for reg..."? I have some checking in
place in process_bb_lives at the end of the function, and it triggers
on the test case. (Checking code and test case is at the end of this
e-mail.) It
Andrew Pinski Wrote:
>> I figured out that ifcvt.c uses alloca to reserve mem on the stack. this is
>> the point where the segmentation fault occurs.
>
> It is also a regression from what I can tell too from 4.1.x.
And one that's fixed for GCC 4.8.
See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg
On Tue, Oct 16, 2012 at 7:20 PM, Andi Kleen wrote:
> Vladimir Makarov writes:
>>>
>> As I remember, the performance improvement from this optimization was
>> very small. There were problems in reviewing IRA and I decided to
>> simplify this task.
>>
>> May be it is worth to return to this work.
>
Bin. Cheng wrote:
> Quoting from GCCINT, section "9.5 RTL passes":
> "When optimizing for size, GCSE is done using Morel-Renvoise Partial
> Redundancy Elimination, with the exception that it does not try to
> move invariants out of loops—that is left to the loop optimization
> pass. If MR PRE GCSE
Bin.Cheng wrote:
> It is possible to have register pressure decreased when hoisting an
> expression up in flow graph because of shrunk live range of input
> register operands.
> To accurately simulating the change of register pressure, I have to
> check the change of live range of input operands du
On Tue, Oct 23, 2012 at 5:17 AM, Bin.Cheng wrote:
> Thanks for your explanation.
> Now I understand how df_insn_info is updated when
> deleting/modifying/creating insn. One more question is when and how
> IN/OUT information is updated. GCC calls df_set_bb_dirty when handling
> insns, but I did not
On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon
wrote:
> Well, both of these functions appear to check that the 2 blocks to
> merge belong to the same partition, so it should be OK.
In your first email, you said if-convert was merging two blocks from
different partitions. can_merge_block_p() wo
On Wed, Oct 24, 2012 at 6:11 PM, Christophe Lyon wrote:
> On 24 October 2012 00:42, Steven Bosscher wrote:
>> On Tue, Oct 23, 2012 at 10:29 PM, Christophe Lyon wrote:
>>> Well, both of these functions appear to check that the 2 blocks to
>>> merge belong to the same pa
Hello,
../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
rs6000_density_test(rs6000_cost_data*)':
../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
was not declared in this scope
This is due to:
2012-10-24 Sharad Singhai
* dumpfile.c (dump_enabled_p): Make
On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote:
> It looks like something is wrong with the CFG:
>
>|
>19 (COLD)
> / \
>/ \
> 20 (COLD) 21 (COLD)
>\ /
> \ /
> 22 (HOT)
So the partitioning is messed up, the above makes no sense. Where do
On Fri, Oct 26, 2012 at 12:14 AM, Steven Bosscher wrote:
> On Thu, Oct 25, 2012 at 4:10 PM, Christophe Lyon wrote:
>> It looks like something is wrong with the CFG:
>>
>>|
>>19 (COLD)
>> / \
>>/ \
>> 20 (COLD) 21 (COLD)
&
On Fri, Oct 26, 2012 at 12:26 AM, Andrew Pinski wrote:
> The official wording from SPEC is that the sources are under the same
> license as they are provided to them. It is the data files which are
> under the SPEC license.
Good. So the only things needed to reproduce the problem can be
shared: t
On Fri, Oct 26, 2012 at 2:16 PM, Christophe Lyon wrote:
> I also use some patches posted by Matthew Gretton-Dann, which are
> still under discussion: I will open a PR, and attach these patches
> too. Is it OK?
Yes, that'd be all that's needed to reproduce the bug.
Ciao!
Steven
On Fri, Nov 2, 2012 at 11:01 AM, Bin.Cheng wrote:
> Hi Steven,
> You mentioned the flag_gcse_las may be very useful for RISC machines in
> thread : http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00031.html
>
> I took some time to understand the code and think it should be workable with
> hoist. Howev
On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote:
>
> Say, why don't we reserve GCC 5.0 for the first version that gets rid of
> reload? Then let's see if we can get there while the X in 4.X is still in
> single digits!
(see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html)
I suppose
On Tue, Nov 6, 2012 at 1:17 AM, Ian Lance Taylor wrote:
> On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher wrote:
>> On Wed, 24 Mar 2010 04:34:15 +, Dave Korn wrote:
>>>
>>> Say, why don't we reserve GCC 5.0 for the first version that gets rid of
>>&
(sorry for breaking threads... re.
http://gcc.gnu.org/ml/gcc/2012-11/msg00304.html)
On Tue, 20 Nov 2012 09:57:35 +0100, Eric Botcazou wrote:
> > I wouldn't jump to that conclusion too quickly.I think we should be
> > GC free as well, and I doubt I am the only other one.
>
> Dropping the GC mea
On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote:
> Richi, ping?
Just guessing... isn't he simply out on Honeymoon?
Those functions were introduced to handle alias sets for spill slots
better, but IIRC this never worked properly. The whole path through
dse_step2_spill is dead.
The code
Hello,
A "Not yet implemented" comment in reorg.c discusses conditional
execution. The comment already existed in the earliest revision in the
repository (r99) so it pre-dates the conditional execution framework
now used by the "Acorn RISC Machine" (better known as ARM nowadays :-)
and how HP-PA c
On Sun, Nov 25, 2012 at 4:44 PM, John David Anglin wrote:
> On 24-Nov-12, at 9:19 PM, Steven Bosscher wrote:
>
>> +;; This machine description is inspired by sparc.md and (to a lesser
>> +;; extend) mips.md.
>
>
> Change "extend" to "extent". D
On Sun, Dec 2, 2012 at 12:59 AM, John David Anglin wrote:
> On 1-Dec-12, at 6:45 PM, Steven Bosscher wrote:
>
>>
>> How about this?
>
>
> PA part looks good. Thanks.
Great, thanks! I've committed the PA part with a few typo fixes, and
the reorg.c part as obviou
Hello,
Someone broke bootstrap on powerpc64-linux between r194084 and
r194141. Anyone else seeing this?
Ciao!
Steven
../../../../../trunk/libstdc++-v3/src/c++98/locale-inst.cc:338:8:
error: 'void
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intItEES3_S3_S3_RSt8ios
On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
> Hello,
>
> Someone broke bootstrap on powerpc64-linux between r194084 and
> r194141. Anyone else seeing this?
>
> Ciao!
> Steven
Looks like someone used a broken editor replacing tabs with spaces:
2012-1
On Tue, Dec 4, 2012 at 4:47 PM, Steven Bosscher wrote:
> On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
>> Hello,
>>
>> Someone broke bootstrap on powerpc64-linux between r194084 and
>> r194141. Anyone else seeing this?
>>
>> Ciao!
>> Steve
On Tue, Dec 4, 2012 at 5:22 PM, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152
>
> I think if you had changed to it would have a
> better chance to survive broken editors.
I only put back wha
Hello,
While trying to bootstrap with GCAC checking enabled and some
instrumentation to measure how often objects are being marked, I
noticed that a lot of cache misses happen because already-marked
objects are being tested again (e.g. via ggc_marked_p). This struck me
as rather odd, until I looke
On Tue, Dec 11, 2012 at 5:11 PM, Diego Novillo wrote:
> On Mon, Dec 10, 2012 at 1:25 PM, Steven Bosscher wrote:
>> This all made me wonder why we can't use the known hierarchy of the
>> intermediate representations. Ideally, there should be only two
>> classes of objec
On Tue, Dec 11, 2012 at 6:55 PM, Martin Jambor wrote:
> some IPA passes do have on-the side vectors with their information
> about each cgraph node or edge and those are independent GC roots.
> Not all, but many (e.g. inline_summary_vec or ipa_edge_args_vector) do
> have pointers to other GC data,
Hello,
Linux support for i386 has been removed. Should we do the same for GCC?
The "oldest" ix86 variant that'd be supported would be i486.
The benefit would be a few good cleanups:
* PROCESSOR_I386 / TARGET_386 can be removed
* X86_TUNE_DOUBLE_WITH_ADD can be removed (always true)
* X86_ARCH_C
On Wed, Dec 12, 2012 at 8:39 PM, Robert Dewar wrote:
> On 12/12/2012 1:01 PM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> Linux support for i386 has been removed. Should we do the same for GCC?
>> The "oldest" ix86 variant that'd be supported would
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote:
> I don't speak for FreeBSD, but dropping them from Tier 1 support because
> they don't use a GPLv3 *BASE* compiler is a bit vindictive.
FreeBSD has dropped GCC for future releases so there's no reason for
it to be a primary platform.
Ciao!
Ste
On Thu, Dec 13, 2012 at 12:38 PM, David Brown wrote:
> Dropping bsd as a target architecture just because the BSD distributions
> don't use it is a bit like dropping support for targeting windows just
> because Microsoft didn't use gcc to compile Windows 8.
You're confused. Dropping something as a
On Thu, Dec 13, 2012 at 12:59 PM, Robert Dewar wrote:
>
>> Intel stopped producing embedded 386 chips in 2007.
>
>
> Right, but this architecture is not protected, so the
> question is whether there are other vendors producing
> compatible chips. I don't know the answer.
Ralf has found one such a
On Thu, Dec 13, 2012 at 1:21 PM, John Marino wrote:
> Which clause are you invoking to remove it from the primary tier list?
> Richard claimed "they are not at all happy with GPLv3". That's not a reason
> listed on your reference. He also claimed they "not using still maintained
> compilers" whic
On Thu, Dec 13, 2012 at 2:19 PM, Richard Biener wrote:
> Gerald runs regression tests on both i386 and x86_64 freebsd (though some old
> versions of it). We do have a listed maintainer for freebsd. Apart from
> build
> issues I am not aware of frequent freebsd specific bugs.
Gerald's test for i
On Thu, Dec 13, 2012 at 2:40 PM, John Marino wrote:
> Everything I have said is a fact, please illustrate which statement I made
> seems emotional.
Joining in this discussion at all? I wish *bsd people were just as
responsive to bug reports...
Ciao!
Steven
Hello,
I've bootstrapped&tested the LRA branch on ia64 and posted the results
to gcc-testresults
(http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg01782.html).
Unfortunately there's nothing in the message that shows that this
wasn't a trunk checkout but the LRA branch.
Is it possible to identify
On Fri, Dec 21, 2012 at 1:09 AM, David Daney wrote:
> The last time I checked, gcc/REVISION is only set to the proper value by
> running contrib/gcc_update.
Right. Well, that makes things easy :-)
Vlad, I've set up auto-testers for the lra-branch on gcc110
(powerpc64) and gcc66 (ia64). They run w
On Sat, Dec 22, 2012 at 5:15 PM, Steven Bosscher wrote:
> Vlad, I've set up auto-testers for the lra-branch on gcc110
> (powerpc64) and gcc66 (ia64). They run within 24 hours after something
> changes on the lra-branch, and post test results to gcc-testresults if
> build+test was
On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
>>> It would be nice to finally move
>>> the call to cgraph_finalize_compilation_unit to the
Hello,
Consider the following test case:
void bar (void);
int foo (int b, int c, int d)
{
int r = 0;
if (b)
res = b * 2 + 4;
if (c)
{
if (d)
r = res;
else
__builtin_unreachable ();
}
return r;
}
This is typical for code in GCC itself in places wher
Hello,
Consider this test case:
-- 8<
int a;
__attribute__((__noinline__,__noclone__,__pure__))
int use (int b)
{
return b * 2 + 4 + a;
}
int foo (int b, int c, int d)
{
int res, r = 0;
res = use (b);
if (c)
r = res;
return r;
}
Hello,
In this stabs vs. dwarf discussion, so far it's more been about
assumptions than numbers. So let's throw in some numbers!
The following debug sizes are for CSiBE-v2.1.1 on mipsisa64-elf, with
the LRA branch at r195108. All CSiBE test cases are packages written
in C.
Debug size is computed
On Tue, Jan 15, 2013 at 6:53 PM, Jan Kratochvil wrote:
> On Tue, 15 Jan 2013 11:09:46 +0100, Steven Bosscher wrote:
>> Unless someone can shoot holes in this test approach,
>
> While the sum of *.o files sizes may make sense in some cases I would find
> more useful to measure it
Hello Diego,
There still appears to be an issue with the vec.h changes, the
detailed memory stats are not very informative. The allocation lines
are shown in vec.h without further details:
t8000.log:vec.h:1268 ((null)) 0:
0.0% 40 4: 0.0
On Mon, Jan 28, 2013 at 4:47 PM, Diego Novillo wrote:
> On Sun, Jan 27, 2013 at 7:09 AM, Steven Bosscher wrote:
>
>> Is this a known issue?
>
> No, thanks for the report. I'll try to see what's going on (though
> you may need to ping me in a few days).
http://www.
Hello Vlad,
Back in October, you added a patch to remove extra clobbers introduced by LRA:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02531.html
This also disables some -frename-registers opportunities (a few 100 on
x86-64 for my collection of cc1-i files).
Do you think it's be possible (and w
Hello,
Is it necessary for an insn to have REG_UNUSED notes for a CLOBBER?
There are lots such notes on x86 for the flags register:
11: {r68:DI=r61:DI<<0x8;clobber flags:CC;}
REG_DEAD r61:DI
REG_UNUSED flags:CC
In most places where the compiler looks at REG_UNUSED notes, it is for
On Mon, Feb 25, 2013 at 10:48 AM, Eric Botcazou wrote:
>> It seems to me that a REG_UNUSED note on a CLOBBER is unnecessary, and
>> it also goes against the documented purpose of a REG_UNUSED note in
>> reg-notes.def:
>>
>> /* Identifies a register set in this insn and never used. */
>> REG_NOTE (
On Mon, Feb 25, 2013 at 10:51 PM, Eric Botcazou wrote:
>> That's what I believe, too. Still, combine appears to add REG_UNUSED
>> notes for clobbers intentionally. Do you know why it does that?
>
> Hmm, right, it apparently clearly wants to immediately close the "live" ranges
> it creates by addin
really. There seems always to be something that prevents them from
> being deleted, and I have no time to spend on GCC at work right now. I
> believe Steven Bosscher has more detail on that than I do.
We had this discussion last year. The only reason to still have
libcalls was for TLS address
801 - 900 of 961 matches
Mail list logo
