On Mon, 26 Oct 2009, Steve Ellcey wrote:
> I have tried:
> /* { dg-final { scan-assembler-times "(byte|data1).*?0x3.*? DW_AT_inline" 3 }
> } */
> /* { dg-final { scan-assembler-times "(byte\|data1).*?0x3.*? DW_AT_inline" 3
> } } */
> /* { dg-final { scan-assembler-times "\(byte\|data1\).*?0x3.*?
Hi,
I am writing a new pass for gcc that uses the GTY markers,
1. I have included the source file in GTFILES_H in gcc/Makefile.in.
2. I have the gt-path.h mentioned in the compilation for source file
3. I have the #include "gt-path.h" at the very end of the code of source file.
I see the gt-path.
On Mon, Oct 26, 2009 at 06:10:06PM -0400, Hans-Peter Nilsson wrote:
> On Fri, 23 Oct 2009, Ian Lance Taylor wrote:
> > Steven Bosscher writes:
> > > I was just wondering why this is not a -f* flag, e.g. -fuse-linker-plugin?
> > Any opinions on the best user interface for this?
>
> The color that
palpar writes:
> 1. How can I tell from the RTL declaration of a function if it is
> declared INLINE of not?
You have to look at the tree decl, at DECL_DECLARED_INLINE_P.
> 2. Where is the code responsible for allocating those variables on the
> stack which don't fit in registers (needed to fix
I am looking at a failure of gcc.dg/debug/dwarf2/inline2.c on IA64
HP-UX. The problem I have is with the assembler scan:
/* { dg-final { scan-assembler-times "byte.*?0x3.*? DW_AT_inline" 3 } } */
IA64 HP-UX is using 'data1' instead of 'byte' in the output. Now that
should be easy to fix and if
On Fri, 23 Oct 2009, Ian Lance Taylor wrote:
> Steven Bosscher writes:
> > I was just wondering why this is not a -f* flag, e.g. -fuse-linker-plugin?
> Any opinions on the best user interface for this?
The color that spells -fuse-linker-plugin seems better, in line
with other options. How it's i
On Mon, Oct 26, 2009 at 10:42 PM, Aldy Hernandez wrote:
>> Certainly better. But I fail to see why a different location would be
>> better than the original here. I assume all tokens have a correct initial
>> location. Then why is for example for int i; in (int) i the location of
>> the conver
> Certainly better. But I fail to see why a different location would be
> better than the original here. I assume all tokens have a correct initial
> location. Then why is for example for int i; in (int) i the location of
> the conversion a better location than the one of i in the folded result
On Mon, Oct 26, 2009 at 6:28 PM, Aldy Hernandez wrote:
>> That wasn't my question.
>>
>> tem = fold_build2_loc (loc, code, type,
>> fold_convert_loc (loc, TREE_TYPE (op0),
>> TREE_OPERAND (arg0, 1)), op1);
>> prote
Basile STARYNKEVITCH writes:
> May I respectfully suggest to the person maintaining the bugzilla a
> notice in the login page saying something like:
>
> GCC maintainers having write after approval (or better) access to the
> GCC trunk should preferably login with their xx...@gcc.gnu.org email
Go
Ian Lance Taylor wrote:
Basile STARYNKEVITCH writes:
Did I understand correctly that GCC bugzilla treats magically the
*...@gcc.gnu.org email adresses matching accounts usable for SVN write
access? This is great news!
Yes, that is how it works.
May I respectfully suggest to the person mai
On Mon, 2009-10-26 at 12:57 +0100, Christian Joensson wrote:
> 2009/10/26 Christian Joensson :
> > I noticed on http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02488.html
> > (trunk revision 153541) that the acats test suite was not run... and
> > looking into acats.log I see this:
> >
> > compila
> That wasn't my question.
>
> tem = fold_build2_loc (loc, code, type,
> fold_convert_loc (loc, TREE_TYPE (op0),
> TREE_OPERAND (arg0, 1)), op1);
> protected_set_expr_location (tem, loc);
>
> here tem is built by
On Mon, Oct 26, 2009 at 5:37 PM, Aldy Hernandez wrote:
>> > ? ? ?tem = fold_build2_loc (loc, code, type,
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? fold_convert_loc (loc, TREE_TYPE (op0),
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_OPERAND (arg0, 1)),
>> > op1);
>> > ? ? ?protected_set_expr_loc
On Mon, Oct 26, 2009 at 9:37 AM, Aldy Hernandez wrote:
> We have two options:
>
> a) Allow locus changes in fold_checksum_tree.
> b) Fix fold-const throughout to make a copy of the result of fold_build*
> calls if we're about to change it's location-- in case fold is returning
> any of the origina
> > ? ? ?tem = fold_build2_loc (loc, code, type,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? fold_convert_loc (loc, TREE_TYPE (op0),
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_OPERAND (arg0, 1)), op1);
> > ? ? ?protected_set_expr_location (tem, loc);
> >
> > When --enable-checking=fold, fold verifi
On Mon, Oct 26, 2009 at 4:39 PM, Aldy Hernandez wrote:
> Hi folks.
>
> In this PR the problem is that a call to fold_build2_loc() returns one
> of the original arguments unchanged. In the code below we take this
> result and change its location before returning it.
>
> tem = fold_build2_loc
Hi all,
I'd have two questions needed for work on porting gcc-3.2.3.
1. How can I tell from the RTL declaration of a function if it is
declared INLINE of not?
2. Where is the code responsible for allocating those variables on the
stack which don't fit in registers (needed to fix debug info
generat
Hi folks.
In this PR the problem is that a call to fold_build2_loc() returns one
of the original arguments unchanged. In the code below we take this
result and change its location before returning it.
tem = fold_build2_loc (loc, code, type,
fold_convert_loc (lo
On Tue, Sep 8, 2009 at 2:38 PM, Heiko Harders wrote:
> Hello,
>
> (first of all: sorry to post this message to a second list, I've sent it to
> the wrong list at first)
>
> I am using g++ in MinGW-w64 running in a Windows environment. I'm especially
> interested in the c++0x threads because it all
On Mon, Oct 26, 2009 at 3:39 PM, Basile STARYNKEVITCH
wrote:
> Richard Guenther wrote:
>>
>> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor wrote:
>>>
>>> Basile STARYNKEVITCH writes:
>>>
Are you suggesting me to upload to bugzilla the nearly 3000
preprocessed forms of the files? I
Richard Guenther wrote:
On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor wrote:
Basile STARYNKEVITCH writes:
Are you suggesting me to upload to bugzilla the nearly 3000
preprocessed forms of the files? I could do that, but the *.i files
totalize more than one gigabyte. A bzip2 compressed ta
On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor wrote:
> Basile STARYNKEVITCH writes:
>
>> Are you suggesting me to upload to bugzilla the nearly 3000
>> preprocessed forms of the files? I could do that, but the *.i files
>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>
Basile STARYNKEVITCH writes:
> Are you suggesting me to upload to bugzilla the nearly 3000
> preprocessed forms of the files? I could do that, but the *.i files
> totalize more than one gigabyte. A bzip2 compressed tar archive of
> them is almost 80Mbytes.
That is a difficulty, but without a sel
On 10/26/2009 07:14 AM, Jakub Jelinek wrote:
-/* Generate the mangled representation of TYPE for the typeinfo name.
*/
+/* Generate the mangled representation of TYPE. */
const char *
-mangle_type_string_for_rtti (const tree type)
+mangle_type_string (const tree type)
Why this change?
Thi
2009/10/26 Christian Joensson :
> I noticed on http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02488.html
> (trunk revision 153541) that the acats test suite was not run... and
> looking into acats.log I see this:
>
> compilation abandoned
> /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/supp
Hi!
Just some random comments:
On Sat, Oct 24, 2009 at 12:10:52AM -0400, Jerry Quinn wrote:
> + if (mark_private)
> +{
> + /* Inject '*' at beginning of name to force pointer comparison.
> */
> + char* buf = (char*) XNEWVEC (char, length + 1);
> + buf[0] = '*';
> + memcpy
Joseph S. Myers wrote:
On Sun, 25 Oct 2009, Basile STARYNKEVITCH wrote:
I cannot understand when should I use or not bugzilla. More precisely, I have
several examples of "bugs" but I didn't use bugzilla for them
A big thanks to your reply. However, you did not answer to my example 1.
J.Pitra
28 matches
Mail list logo
