Re: Vector alignment tracking
On Thu, Oct 13, 2011 at 6:57 PM, Andi Kleen wrote: >> Or I am missing someting? > > I often see the x86 vectorizer with -mtune=generic generate a lot of > complicated code just to adjust for potential misalignment. > > My thought was just if the alias oracle knows what the original > declaration is, and it's available for changes (e.g. LTO), it would be > likely be better to just add an __attribute__((aligned())) > there. > > In the general case it's probably harder, you would need some > cost model to decide when it's worth it. > > Your approach of course would still be needed for cases where this > isn't possible. But it sounded like the infrastructure you're building > could in principle do both. The vectorizer already does that. Richard. > -Andi >
RE: Question about default_elf_asm_named_section function
Can I submit a patch for it? Or is it a small thing that patch is not necessary?
Thanks,
Balaji V. Iyer.
-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com]
Sent: Friday, October 14, 2011 12:38 AM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Question about default_elf_asm_named_section function
"Iyer, Balaji V" writes:
> This email is in reference to the "default_elf_asm_named_section"
> function in the varasm.c file.
>
> This function is defined like this:
>
> void
> default_elf_asm_named_section (const char *name, unsigned int flags,
>tree decl ATTRIBUTE_UNUSED)
>
>
> But, inside the function, there is this if-statement:
>
>
> if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
> {
> if (TREE_CODE (decl) == IDENTIFIER_NODE)
> fprintf (asm_out_file, ",%s,comdat", IDENTIFIER_POINTER (decl));
> else
> fprintf (asm_out_file, ",%s,comdat",
> IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
> }
>
>
> The decl is set with "ATTRIBUTE_UNUSED" but the if-statement is using "decl."
> Should we remove the attribute unused tag near the "tree decl" or is the
> if-statement a deadcode that should never be ?
ATTRIBUTE_UNUSED does not mean "this parameter is never used." It means "this
parameter may not be used." The difference is due to #ifdefs--if a parameter
is only used in code that is something #ifdef'ed out, then the parameter should
be marked as ATTRIBUTE_UNUSED.
In this case the parameter is always used, so we might as well remove the
ATTRIBUTE_UNUSED.
Ian
[BUG?] GCC 4.5.2 produces deprecated ARM relocation
I was recently trying to test GCC's behavior in producing various types of ARM relocations. In particular, I was trying to produce an R_ARM_JUMP24 relocation, which requires veneer. It was suggested that the code most likely to produce this relocation would involve some sort of tail recursion. I wrote up a small test[1] involving interworking and tail recursion to see what the produced object might look like. To my surprise, I found that the compiler instead[2] produced the deprecated R_ARM_PLT32 relocation. Considering the deprecated state of this relocation type, should this be considered a bug? Being a linker implementer, I for one would greatly appreciate it if GCC tried to only use non-deprecated relocation types. I apologize if this has already been fixed upstream. Cheers, - Ben [1] https://github.com/bgamari/arm-interworking-test [2] $ make cc -marm -fPIC -c -o main.o main.c cc -mthumb -fPIC -c -o thumb.o thumb.c gcc main.o thumb.o -o test.o $ objdump -r main.o main.o: file format elf32-littlearm RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0008 R_ARM_PLT32 hi
Handling R_ARM_JUMP24 with inter-working
Recently I've been taking a foray into the ARM ABI to port the Glasgow Haskell Compiler's internal linker to ARM. One question I've run into is how to handle the case of interworking with R_ARM_JUMP24. This particular relocation could be generated often by GHC as a result of tail call optimization. According to the ELF for ARM specification, this case requires the generation of veneer code to handle the instruction set switch. My question is where can one reliably place this veneer such that it is within the 2^11 window permitted by the relevant instructions. This is made difficult considering the fact that in the general case .text itself may be over 2^11 bytes long. It seems that the ELF for ARM specification gives a format for veneer symbol naming in appendix B, but compilers are not required to support this. How does one generally handle placing these relocations? Also, I have seen references[1] to an INTERWORK flag encoded somewhere in the ELF, but I haven't been able to find any references to this in the specification. Could someone point me in the right direction here? It has been suggested that the compiler might include an 8 byte vacancy for veneer after functions where this relocation might be necessary. I have seen that GCC has an -mthumb-interwork option and while the documentation does not directly say this is the option's effect, it is suggestive. Can someone explain exactly what this option does? Cheers, - Ben [1] http://gcc.gnu.org/ml/gcc/2004-03/msg00373.html
Re: Handling R_ARM_JUMP24 with inter-working
On 14/10/11 17:40, Ben Gamari wrote: > According to the ELF for ARM specification, this case requires the > generation of veneer code to handle the instruction set switch. My > question is where can one reliably place this veneer such that it is > within the 2^11 window permitted by the relevant instructions. This is > made difficult considering the fact that in the general case .text > itself may be over 2^11 bytes long. It seems that the ELF for ARM > specification gives a format for veneer symbol naming in appendix B, but > compilers are not required to support this. How does one generally handle > placing these relocations? You might have to put such veneers *between* the components of the .text section (I really wouldn't expect a single *input* .text to be this large, and it's reasonable to just say "sorry, I can't do that" if anybody tries). R.
Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
On 14/10/11 17:40, Ben Gamari wrote: > I was recently trying to test GCC's behavior in producing various types > of ARM relocations. In particular, I was trying to produce an > R_ARM_JUMP24 relocation, which requires veneer. It was suggested that > the code most likely to produce this relocation would involve some sort > of tail recursion. I wrote up a small test[1] involving interworking and > tail recursion to see what the produced object might look like. To my > surprise, I found that the compiler instead[2] produced the deprecated > R_ARM_PLT32 relocation. Considering the deprecated state of this > relocation type, should this be considered a bug? Being a linker > implementer, I for one would greatly appreciate it if GCC tried to only > use non-deprecated relocation types. I apologize if this has already > been fixed upstream. > The compiler doesn't produce relocations, but the assembler does. You need to make sure your binutils is up-to-date. R.
Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation
On Fri, 14 Oct 2011 18:38:26 +0100, Richard Earnshaw wrote: > On 14/10/11 17:40, Ben Gamari wrote: > > I was recently trying to test GCC's behavior in producing various types > > of ARM relocations. In particular, I was trying to produce an > > R_ARM_JUMP24 relocation, which requires veneer. It was suggested that > > the code most likely to produce this relocation would involve some sort > > of tail recursion. I wrote up a small test[1] involving interworking and > > tail recursion to see what the produced object might look like. To my > > surprise, I found that the compiler instead[2] produced the deprecated > > R_ARM_PLT32 relocation. Considering the deprecated state of this > > relocation type, should this be considered a bug? Being a linker > > implementer, I for one would greatly appreciate it if GCC tried to only > > use non-deprecated relocation types. I apologize if this has already > > been fixed upstream. > > > > The compiler doesn't produce relocations, but the assembler does. You > need to make sure your binutils is up-to-date. > Fair enough. I suppose that makes more sense. $ as -v GNU assembler version 2.21.0 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.21.0.20110327 Seems that this is the latest stable release. Cheers, - Ben
Re: Question about default_elf_asm_named_section function
"Iyer, Balaji V" writes:
> Can I submit a patch for it? Or is it a small thing that patch is not
> necessary?
I will preapprove such a patch for anybody with commit access.
Ian
> -Original Message-
> From: Ian Lance Taylor [mailto:i...@google.com]
> Sent: Friday, October 14, 2011 12:38 AM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'
> Subject: Re: Question about default_elf_asm_named_section function
>
> "Iyer, Balaji V" writes:
>
>> This email is in reference to the "default_elf_asm_named_section"
>> function in the varasm.c file.
>>
>> This function is defined like this:
>>
>> void
>> default_elf_asm_named_section (const char *name, unsigned int flags,
>>tree decl ATTRIBUTE_UNUSED)
>>
>>
>> But, inside the function, there is this if-statement:
>>
>>
>> if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
>> {
>> if (TREE_CODE (decl) == IDENTIFIER_NODE)
>> fprintf (asm_out_file, ",%s,comdat", IDENTIFIER_POINTER (decl));
>> else
>> fprintf (asm_out_file, ",%s,comdat",
>> IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
>> }
>>
>>
>> The decl is set with "ATTRIBUTE_UNUSED" but the if-statement is using
>> "decl." Should we remove the attribute unused tag near the "tree decl" or is
>> the if-statement a deadcode that should never be ?
>
>
> ATTRIBUTE_UNUSED does not mean "this parameter is never used." It means
> "this parameter may not be used." The difference is due to #ifdefs--if a
> parameter is only used in code that is something #ifdef'ed out, then the
> parameter should be marked as ATTRIBUTE_UNUSED.
>
> In this case the parameter is always used, so we might as well remove the
> ATTRIBUTE_UNUSED.
>
> Ian
RE: Question about default_elf_asm_named_section function
Attached, please find a patch fixing this issue.
2011-10-14 Balaji V. Iyer
* varasm.c (default_elf_asm_named_section): Removed ATTRIBUTE_UNUSED
tag
before decl.
Thanks,
Balaji V. Iyer.
-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com]
Sent: Friday, October 14, 2011 4:29 PM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Question about default_elf_asm_named_section function
"Iyer, Balaji V" writes:
> Can I submit a patch for it? Or is it a small thing that patch is not
> necessary?
I will preapprove such a patch for anybody with commit access.
Ian
> -Original Message-
> From: Ian Lance Taylor [mailto:i...@google.com]
> Sent: Friday, October 14, 2011 12:38 AM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'
> Subject: Re: Question about default_elf_asm_named_section function
>
> "Iyer, Balaji V" writes:
>
>> This email is in reference to the "default_elf_asm_named_section"
>> function in the varasm.c file.
>>
>> This function is defined like this:
>>
>> void
>> default_elf_asm_named_section (const char *name, unsigned int flags,
>>tree decl ATTRIBUTE_UNUSED)
>>
>>
>> But, inside the function, there is this if-statement:
>>
>>
>> if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
>> {
>> if (TREE_CODE (decl) == IDENTIFIER_NODE)
>> fprintf (asm_out_file, ",%s,comdat", IDENTIFIER_POINTER (decl));
>> else
>> fprintf (asm_out_file, ",%s,comdat",
>> IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
>> }
>>
>>
>> The decl is set with "ATTRIBUTE_UNUSED" but the if-statement is using
>> "decl." Should we remove the attribute unused tag near the "tree decl" or is
>> the if-statement a deadcode that should never be ?
>
>
> ATTRIBUTE_UNUSED does not mean "this parameter is never used." It means
> "this parameter may not be used." The difference is due to #ifdefs--if a
> parameter is only used in code that is something #ifdef'ed out, then the
> parameter should be marked as ATTRIBUTE_UNUSED.
>
> In this case the parameter is always used, so we might as well remove the
> ATTRIBUTE_UNUSED.
>
> Ian
diff --git a/gcc/varasm.c b/gcc/varasm.c
index e83bebb..94c865c 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -6142,7 +6142,7 @@ default_no_named_section (const char *name
ATTRIBUTE_UNUSED,
void
default_elf_asm_named_section (const char *name, unsigned int flags,
- tree decl ATTRIBUTE_UNUSED)
+ tree decl)
{
char flagchars[10], *f = flagchars;
gcc-4.6-20111014 is now available
Snapshot gcc-4.6-20111014 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20111014/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 180010 You'll find: gcc-4.6-20111014.tar.bz2 Complete GCC MD5=f43c607dca0241428b32d2df748031cc SHA1=1d45aae511ba59239ef5fb7fe7fde990b6cf548f Diffs from 4.6-20111007 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
ISO_IEC_14882-2011-5.1.2/10 - bug
Hello.
Quote from ISO_IEC_14882-2011, 5.1.2/10:
> The identifiers in a capture-list are looked up using the usual rules for
> unqualified name lookup (3.4.1); each
> such lookup shall find a variable with automatic storage duration declared in
> the reaching scope of the local
> lambda expression. An entity (i.e. a variable or this) is said to be
> explicitly captured if it appears in the
> lambda-expression’s capture-list.
But this code successfuly compiled on gcc-4.6.1:
#include
int main() {
using std::cout;
auto f = [&cout]() { cout << 1; }; // <<
f();
}
http://liveworkspace.org/code/ae698b7daf7b5b531beafd9faaa6a409
But Intel C++ 12.1 says: error : a variable with static storage
duration cannot be captured in a lambda
Thanks.
niXman.
