This merge brings every change in gcc-4_6-branch up to rev
173632.
Validated on x86_64.
Diego.
Snapshot gcc-4.4-20110510 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110510/
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
This merge brings all the changes in google/main up to rev
173605.
Validated on x86_64.
Diego.
Merged revisions
173258,173353,173395,173398,173411,173416,173499,173504,173526,173605 via
svnmerge from
svn+ssh://gcc.gnu.org/svn/gcc/branches/google/main
r173258 | cgd | 2011-05-02 12
On Tue, 2011-05-10 at 17:33 +0200, Michael T wrote:
> Hello all,
>
> I was wondering if it is possible to improve the debugging information
> generated by gcc when resolving C macros? Just as an example, when I
> preprocessed the following C file:
>
Have you tried '-g3'?
R.
On 05/06/2011 10:21 AM, Hari Sandanagobalane wrote:
Hi Vlad,
I found a problem with your IRA improvement checkin r171649 on
29-3-2011. I can't get picochip port to build with this change. The
problem is in the function "clarify_prohibited_class_mode_regs" in
ira.c:1413. The code reproduced her
> "Michael" == Michael T writes:
Michael> I was wondering if it is possible to improve the debugging
Michael> information generated by gcc when resolving C macros?
It could be done, but nobody has tried.
Michael> I wonder whether this couldn't be done by the gcc preprocessor?
Michael> Or do
> From: rasel...@hotmail.com
> > From: bas...@starynkevitch.net
> > On Tue, 10 May 2011 17:33:57 +0200
> > Michael T wrote:
> > > I was wondering if it is possible to improve the debugging information
> > > generated by gcc when resolving C macros? Just as an example, when I
> > > preprocessed the
> From: bas...@starynkevitch.net
> On Tue, 10 May 2011 17:33:57 +0200
> Michael T wrote:
> > I was wondering if it is possible to improve the debugging information
> > generated by gcc when resolving C macros? Just as an example, when I
> > preprocessed the following C file:
[...]
> I am not a st
On Tue, 10 May 2011 17:33:57 +0200
Michael T wrote:
> I was wondering if it is possible to improve the debugging information
> generated by gcc when resolving C macros? Just as an example, when I
> preprocessed the following C file:
>
> extern int printf (__const char *__restrict __format, ...);
Hello all,
I was wondering if it is possible to improve the debugging information
generated by gcc when resolving C macros? Just as an example, when I
preprocessed the following C file:
extern int printf (__const char *__restrict __format, ...);
#define my_macro(i) \
do { \
*(i) = 1; \
On Tue, May 10, 2011 at 4:20 PM, Ian Lance Taylor wrote:
> fanqifei writes:
>
Which file or fucntion should I look into? Maybe I can work around in 4.3.2
>>>
>>> Look into tree-ssa-alias.c and tree-ssa-structalias.c
>>>
What change in 4.5 fixed it?
>>>
>>> A complete rewrite of the abov
Pierre Vittet writes:
> I am working on a plugin at the GIMPLE state, I am parsing basic
> blocks and I need to check that a call to foo() is only present once
> in a function. Howerver, it can be present several times if it is in
> different basic blocks and only one is executed at execution tim
fanqifei writes:
>>> Which file or fucntion should I look into? Maybe I can work around in 4.3.2
>>
>> Look into tree-ssa-alias.c and tree-ssa-structalias.c
>>
>>> What change in 4.5 fixed it?
>>
>> A complete rewrite of the above ...
>>
>> Richard.
> So is there easy way to work around in 4.3.2
Hello,
I am working on a plugin at the GIMPLE state, I am parsing basic blocks
and I need to check that a call to foo() is only present once in a
function. Howerver, it can be present several times if it is in
different basic blocks and only one is executed at execution time.
I think the mos
> uname -a :
> SunOS devsolx86 5.10 Generic_139556-08 i86pc i386 i86pc Solaris
>
> config.guess output:
> i386-pc-solaris2.10
>
> gcc -v output:
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/export/usr_local/gcc4/bin/../libexec/gcc/i386-pc-solaris2.10/4.5.3/lto-wrapper
> Target:
>> Which file or fucntion should I look into? Maybe I can work around in 4.3.2
>
> Look into tree-ssa-alias.c and tree-ssa-structalias.c
>
>> What change in 4.5 fixed it?
>
> A complete rewrite of the above ...
>
> Richard.
So is there easy way to work around in 4.3.2 to disable the randomization?
Liu writes:
> I write a pattern like this:
> (define_insn "extrv4di"
> [(set (match_operand:V4DI 0 "register_operand" "=Z")
> (unspec:V4DI
> [(match_operand:V4DI 1 "register_operand" "Z")
> (match_operand:SI 2 "immediate_operand" "")]
> UNSPEC_EXTR))]
> "TARGET_V
On Tue, May 10, 2011 at 1:43 PM, fanqifei wrote:
> On Tue, May 10, 2011 at 6:23 PM, Richard Guenther
> wrote:
>> On Tue, May 10, 2011 at 12:08 PM, fanqifei wrote:
>>> Hi all,
>>>
>>> I am poring gcc 4.3.2 for a micro-controller and use it to compile C
>>> source code.
>>> I found that gcc is ver
On Tue, May 10, 2011 at 6:23 PM, Richard Guenther
wrote:
> On Tue, May 10, 2011 at 12:08 PM, fanqifei wrote:
>> Hi all,
>>
>> I am poring gcc 4.3.2 for a micro-controller and use it to compile C
>> source code.
>> I found that gcc is very sensitive to small changes in C source code
>> even if the
On Tue, May 10, 2011 at 12:08 PM, fanqifei wrote:
> Hi all,
>
> I am poring gcc 4.3.2 for a micro-controller and use it to compile C
> source code.
> I found that gcc is very sensitive to small changes in C source code
> even if the change doesn't affect any function of the source code.
> For exam
Hi all,
I am poring gcc 4.3.2 for a micro-controller and use it to compile C
source code.
I found that gcc is very sensitive to small changes in C source code
even if the change doesn't affect any function of the source code.
For example, a source file foo.c includes a header file foo.h.
If one ma
On Tue, May 10, 2011 at 10:28 AM, Ian Bolton wrote:
> Does anyone have some thoughts they'd like to share on this:
>
> "When you compile anything using @file support, the driver assumes @file
> (at_file_supplied is true) is allowed and may pass options to the linker via
> @file using a *temporary*
Does anyone have some thoughts they'd like to share on this:
"When you compile anything using @file support, the driver assumes @file
(at_file_supplied is true) is allowed and may pass options to the linker via
@file using a *temporary* file.
When -save-temps is also used, the temporary @file pas
23 matches
Mail list logo
