Re: GCC 4.7 compiles with llvm-gcc-4.2 but not with GCC 4.6.2
On 17 Jan 2012, at 08:30, Ian Lance Taylor wrote: > > When looking at http://gcc.gnu.org/, there are some large links to the > > versions, but none for 4.7. > > GCC 4.7 has not been released yet. There is a development version. You might compare with the layout at http://lilypond.org/ A confusing thing is that one can get to the SVN version via the other versions links, but then one does not get the appropriate information about GCC 4.7. Hans
Re: GCC 4.7 compiles with llvm-gcc-4.2 but not with GCC 4.6.2
On 17 January 2012 09:12, Hans Aberg wrote: > On 17 Jan 2012, at 08:30, Ian Lance Taylor wrote: > >> > When looking at http://gcc.gnu.org/, there are some large links to the >> > versions, but none for 4.7. >> >> GCC 4.7 has not been released yet. > > There is a development version. You might compare with the layout at > http://lilypond.org/ That's not the same, the GCC trunk isn't just an "unstable" development version, it sometimes doesn't even build and may be completely unsuitable for end users. > A confusing thing is that one can get to the SVN version via the other > versions links, but then one does not get the appropriate information about > GCC 4.7. If you check out svn trunk then of course you would expect to get the latest, unreleased code, and you probably should have read the installation docs - a compiler isn't just another app. IMHO most people who try to build from source probably shouldn't be doing so, they should be installing a binary package supplied by their OS/distro vendor. Those who specifically want to test newer versions should look for and read the docs before rushing into building it, even if they have to spend an extra minute finding those docs (which as I've said, are linked to on the front page in the main menu.)
Problems with references in documentation
Trying to document some new options/name spaces, I ran into following problem
with hyperlinking inside the document.
It's best explained with an example from documentation:
Start at
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
and scroll to the end of the page to section "PowerPC Variable Attributes".
There is a link to "i386 Variable Attributes" written as @ref{i386 Variable
Attributes} in extend.texi that refers to @anchor{i386 Variable Attributes}.
This link targets
http://gcc.gnu.org/onlinedocs/gcc/i386-Variable-Attributes.html#i386-Variable-Attributes
a page that does not exists and redirected to
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#i386%20Variable%20Attributes
(%20 is blank) so that it ends up at the page top and not at the intended
target, which was
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#i386-Variable-Attributes
Actually any link in onlinedocs looks like "page.html#page" and I could not
find a single link that points to an url like "page.html#anchor".
Is this a bug in makeinfo/texinfo? First I thought my local version is too old
but the documents online show the same: Deep links are broken and you always
start at the top of the page.
Johann
Re: [4.7,trans-mem] Summary of unsolved known bugs
On 12/21/11 11:06, Patrick Marlier wrote: Wonderful! Thanks Aldy. On 12/21/2011 09:11 AM, Aldy Hernandez wrote: * ICE when lto1 does not have -fgnu-tm and object file uses TM http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 I believe I wasn't able to reproduce this. Arg really! For the openmp testcase, I was wrong but the tm testcase should show the problem. Please, can you (and maybe someone else) confirm that I am not the only one to see that? Yes, I can reproduce the problem now, as specified in the PR. (Note I have started a thread here about that: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01221.html) Patrick.
Re: GCC 4.7 compiles with llvm-gcc-4.2 but not with GCC 4.6.2
On 17 Jan 2012, at 13:35, Jonathan Wakely wrote: When looking at http://gcc.gnu.org/, there are some large links to the versions, but none for 4.7. >>> >>> GCC 4.7 has not been released yet. >> >> There is a development version. You might compare with the layout at >> http://lilypond.org/ > > That's not the same, the GCC trunk isn't just an "unstable" > development version, it sometimes doesn't even build and may be > completely unsuitable for end users. It is the same for LilyPond - there happens be volunteers building binaries, which require some package chasing. In fact, the GUI has not been working for awhile on my platform, and as it happens, the "unstable" branch has a fix. >> A confusing thing is that one can get to the SVN version via the other >> versions links, but then one does not get the appropriate information about >> GCC 4.7. > > If you check out svn trunk then of course you would expect to get the > latest, unreleased code, and you probably should have read the > installation docs - a compiler isn't just another app. > > IMHO most people who try to build from source probably shouldn't be > doing so, they should be installing a binary package supplied by their > OS/distro vendor. Those who specifically want to test newer versions > should look for and read the docs before rushing into building it, > even if they have to spend an extra minute finding those docs (which > as I've said, are linked to on the front page in the main menu.) Well, I read them for GCC 4.6, but the unusual part slipped my mind. It would have helped with a reminder. BTW, on my platform, the GC must be built from the archive, but here are some clear instructions: http://www.hpl.hp.com/personal/Hans_Boehm/gc/#where There is a similar snag for GMP. If building from without the directory is a requirement, I think you should ask the the config developers for a way to ensure that. One idea: ./configure might create a directory ../-build/ and configure for that. But you should consider what people in general do. This somewhat heated discussion perhaps suggests you have had a past history of people doing the same thing. GCC 4.7 was of interest to me because it supports the C++11 threads and atomic features, which it 4.6 doesn't on my platform. It could be that you see more trying this version because of that, better C++11 support. Hans
init-regs double initialization
Hi,
I have the very simple:
volatile unsigned int SOME_REGISTER;
volatile unsigned long ANOTHER_REGISTER;
void foo_bar(void)
{
SOME_REGISTER = 0;
ANOTHER_REGISTER = 0;
}
causing me some headaches: int is QImode, long is HImode.
Using gcc-4.6.2, in 175r.fwprop2 I have:
(insn 6 2 7 2 (parallel [
(set (mem/v/c/i:QI (symbol_ref:QI ("SOME_REGISTER")
) [2 SOME_REGISTER+0 S1 A16])
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:6 6 {*movqi}
(expr_list:REG_UNUSED (reg:CC 13 CC)
(nil)))
(insn 7 6 8 2 (parallel [
(set (subreg:QI (reg:HI 21) 0)
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:7 6 {*movqi}
(expr_list:REG_UNUSED (reg:CC 13 CC)
(nil)))
(insn 8 7 9 2 (parallel [
(set (subreg:QI (reg:HI 21) 1)
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:7 6 {*movqi}
(expr_list:REG_UNUSED (reg:CC 13 CC)
(nil)))
(insn 9 8 0 2 (set (mem/v/c/i:HI (symbol_ref:QI ("ANOTHER_REGISTER")
) [3 ANOTHER_REGISTER+0 S2 A16])
(reg:HI 21)) test.c:7 13 {*movhi_direct}
(expr_list:REG_DEAD (reg:HI 21)
(nil)))
After 177r.init-regs:
(insn 6 2 12 2 (parallel [
(set (mem/v/c/i:QI (symbol_ref:QI ("SOME_REGISTER")
) [2 SOME_REGISTER+0 S1 A16])
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:6 6 {*movqi}
(expr_list:REG_UNUSED (reg:CC 13 CC)
(nil)))
(insn 12 6 13 2 (parallel [
(set (subreg:QI (reg:HI 21) 0)
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:7 -1
(nil))
(insn 13 12 7 2 (parallel [
(set (subreg:QI (reg:HI 21) 1)
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:7 -1
(nil))
(insn 7 13 8 2 (parallel [
(set (subreg:QI (reg:HI 21) 0)
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:7 6 {*movqi}
(expr_list:REG_UNUSED (reg:CC 13 CC)
(nil)))
(insn 8 7 9 2 (parallel [
(set (subreg:QI (reg:HI 21) 1)
(const_int 0 [0]))
(clobber (reg:CC 13 CC))
]) test.c:7 6 {*movqi}
(expr_list:REG_UNUSED (reg:CC 13 CC)
(nil)))
(insn 9 8 0 2 (set (mem/v/c/i:HI (symbol_ref:QI ("ANOTHER_REGISTER")
) [3 ANOTHER_REGISTER+0 S2 A16])
(reg:HI 21)) test.c:7 13 {*movhi_direct}
(expr_list:REG_DEAD (reg:HI 21)
(nil)))
So insn, 12 and 13 were added to initialize reg21:HI which was already
initialized.
I am thinking many things could have gone wrong. First init-regs didn't
detect the initialization of reg21 because it's split into subregs but
then something should have checked for duplicate insn. However this
checking probably didn't work because of the clobbers of RCC in the insns.
Any hints of what might be going on? These duplicates reach register
allocation and cause unnecessary assembly instructions to be emitted.
Cheers,
--
PMatos
ICE building compiler
Hi,
I'm investigating an ICE building the Blackfin compiler from trunk.
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:
In function ‘eoshift1’:
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
error: unable to find a register to spill in class ‘CCREGS’
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
error: this is the insn:
(insn 546 540 479 46 (set (reg:BI 455)
(le:BI (reg/v:SI 6 R6 [orig:122 size ] [122])
(const_int 0 [0])))
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:212
119 {compare_le}
(nil))
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
internal compiler error: in spill_failure, at reload1.c:2123
The problem occurs when the ce2 pass does an IF-CASE-2 transformation, moving
an instruction which sets the condition code register into a block between
another instruction which sets the condition code register and its conditional
jump.
e.g.
block 44:
set cc = x;
if cc jump;
...
block 49:
set cc = y;
block 51:
if cc jump;
gets transformed into...
block 44:
set cc = x;
set cc = y;
if cc jump;
...
block 51:
if cc jump;
When we reach cc=y in the reload pass the CC reg is already in use from cc=x,
find_reg fails to find an alternative and we bomb out.
This seems like something IF-CASE-2 could do a lot, so is it supposed to avoid
such scenarios? or should reload handle the situation by finding the previous
use of CC and spilling it to memory?
Any pointers would be appreciated.
Thanks,
Stu
Re: comp_type_attributes
Marc Glisse writes:
> I am trying to understand comp_type_attributes, which checks whether
> attributes are compatible. From what I understand, on many platforms,
> that function can only ever return 1. Indeed, it does some checks to
> know whether it can answer 1, and if not it forwards to the target,
> which by default just returns 1. It looks like it could directly
> forward to the target. Which would leave the pretty printer as the
> only user of the affects_type_identity property of an attribute...
>
> Now the reason I looked at this is because I was expecting a different
> behavior. I added a new (function type) attribute in a front-end and
> specified that it affects type identity. When comp_type_attributes
> sees this attribute in one type but not the other, it can't answer
> yes, so it forwards to the target. The target just answers yes by
> default (some check for their own attributes, but they ignore the
> rest).
>
> Is that what's supposed to happen? I can use another mechanism than
> attributes, but this looks suspicious.
When COMP_TYPE_ATTRIBUTES was introduced, it was a macro which could be
set in tm.h to check type attributes.
Fri May 6 14:05:00 1994 Stephen R. van den Berg
(b...@pool.informatik.rwth-aachen.de)
* tree.h (TYPE_ATTRIBUTES): New macro.
(struct tree_type): attributes, new field.
(precision): Move this field up for better alignment.
(attribute_list_{equal,contained}): Prototype for new functions.
(build_type_attribute_variant): Prototype for new function.
* c-parse.in: Rewrite attribute parsing; update the expected
conflicts and state numbers.
* tree.c (TYPE_HASH): Move definition to top of file.
(make_node): Add support for SET_DEFAULT_TYPE_ATTRIBUTES.
(build_type_attribute_variant): New function.
(type_hash_lookup): Check if the attributes match.
(attribute_list_{equal,contained}): New functions.
* c-typeck.c (common_type): Add attribute merging.
(comp_types): Use COMP_TYPE_ATTRIBUTES macro.
* print-tree.c (print_node): Print attributes.
* c-common.c (decl_attributes): Move the attribute
recognition and rejection here from c-parse.in.
(decl_attributes): Use VALID_MACHINE_ATTRIBUTE macro.
This was before there was a affects_type_identity field. Given that,
and given the assumption that most attributes were backend specific, a
default of 1 made sense.
The default has carried forward since then. The affects_type_identity
field was added in March 2011 as part of the fix for PR 12171, in order
to produce a better error message. Kai followed with a change to test
affects_type_identity in the new comp_type_attributes function:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01318.html
At that point I think it would have made sense to change the default of
TARGET_COMP_TYPE_ATTRIBUTES. Or, it should be renamed, since it is no
longer simply serving as a comparison, but is now serving to handle the
special case for which it was introduced, x86 calling convention
attributes.
So, no real answers here, but I agree that this is an area that could
use some cleanup.
Ian
Re: trouble emilinating redundant compares
Thanks H-P, That worked first time ! For a few days I had been searching the non cc0 ports for hints. Two of the ports don't bother using the set CC side effect to avoid compares and the others are obfuscated by the fact that they (understandably) use custom CC modes and the reload conditions aren't obvious - even when I inspected the .c file CCmode tests. For example the i386 seems to use predicates and constraints of the form <*_operand> and for the reload versions of these instructions - and I haven't been able to find definitions of these or a mention in gcc_internals.pdf of any special meaning assigned to the <> notation. In any case - thanks again, with this blocker cleared I can proceed with lower stress levels :-) Cheers, Paul. On 17/01/12 15:19, Hans-Peter Nilsson wrote: On Mon, 16 Jan 2012, Paul S wrote: In the port I'm working on I have used the newer CC tracking technique (i.e. not cc0). I have followed the directions at the top of compare-elim.c and have the following pattern for addhi3 I'm clearly missing something... can anyone provide a hint ? You're running into one of the grievances with cc0 conversion: all the single_set users. Don't expose the CC register as being set until after reload, and in particular not from moves and adds, reload makes heavy use of those. Make a parallel with a clobber of it instead. Then have your pattern above with "reload_completed" instead of "" as its condition. (Or a shorter hint, do what other non-cc0 ports do. :) brgds, H-P
x86_64 -mcmodel=smallhigh, cont'd
I posted about this a few months ago, but I've been busy with higher-priority work until recently, so I've only just picked it back up, but I think I've fixed the last bug. To review: my goal is to give the x86 backend a code model where code and data reside within an arbitrary 2GiB of the address space, and where the loader/runtime is not required to support the ELF PIC facilities. The motivating example for this is the vSphere Hypervisor (ESXi) kernel and its modules, which are loaded outside the range of both the "small" and "kernel" models of the x86_64 ABI for technical reasons which, for the sake of brevity, I will not attempt to explain here. This being a kernel environment and not a "shared text" user program, text relocations are free; thus, the overhead of PLT/GOT indirection is unnecessary and, indeed, unwelcome. Implementing this code model appears to be relatively simple: legitimate addresses are computed as for CM_SMALL_PIC but treating every symbol as local, and any constant_address_p immediate can be loaded with lea instead of movabs. As before, if it sounds like I'm still doing this wrong, that would be nice to know; this project is more or less my first nontrivial exposure to GCC internals. Our legal department appears to be fine with contributing this back, although I want to wait until I get specific confirmation before mailing any diffs. At the moment I have diffs against 4.4.3 (yes, I know it's old) and HEAD, but they still need documentation changes and testcases before they'd be useful. But my other question is: is there interest in having this change contributed? It's not inherently vendor-specific, but I'm having trouble thinking of anyone else who'd want to use it, and I don't know what GCC's policy is on features like that. --Jed
gcc-4.4-20120117 is now available
Snapshot gcc-4.4-20120117 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20120117/ 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/gcc-4_4-branch revision 183262 You'll find: gcc-4.4-20120117.tar.bz2 Complete GCC MD5=42e2c57d40ccae2d5a57aa6c83daa8bc SHA1=6142da7cd32b71dff278959eacf4fcd4a7d8efa0 Diffs from 4.4-20120110 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
