I am working on a gcc-plugin where I need to create a structure at compile time.
I have gleaned over one of the front ends to learn more about creating
structures at compile time. What I have thus far is a type node for my struct.
I now need to create an instance of this struct. For exemplary pu
Zdenek,
I'm looking at a missed optimizations in combine and it is similar to the one
you've fixed in PR18942 (http://thread.gmane.org/gmane.comp.gcc.patches/81504).
I'm trying to make GCC optimize
(leu:SI
(plus:SI (reg:SI) (const_int -1))
(const_int 1))
into
(leu:SI
(reg:SI)
(const_in
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: Monday, November 28, 2011 9:07 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
> Hi,
>
> On Mon, 28 Nov 2011, Jiangning Liu wrote:
>
> > > > One more question...
> > >
On Thu, 1 Dec 2011, Steven Bosscher wrote:
> On Thu, Dec 1, 2011 at 7:42 PM, Joseph S. Myers
> wrote:
> > On Thu, 1 Dec 2011, Steven Bosscher wrote:
> >
> >> Is it valid in dialects older than C99 to declare a function static
> >> inline after calling it? Should the warnings be brought back in t
Snapshot gcc-4.5-20111201 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111201/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Georg-Johann Lay writes:
> Ian Lance Taylor wrote:
>
>> It's a case that will never ordinarily arise. It only
>> arises for you because you are specifically trying to combine a volatile
>> MEM. I don't know if it makes sense for the general purpose combine to
>> try to handle such an unusual sp
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
If general_operand can be perceived as
(define_predicate "general_operand"
(ior (match_operand 0 "memory_operand")
(match_operand 0 "register_operand")
(match_operand 0 "immediate_operand")))
how can low_io_mem ever match?
Oh
For the past couple of years I've simply ignored these problems by
ritually adding 'echo .NOTPARALLEL: >> Makefile' to my top-level
issue-the-long-configure-option scripts.
But I suppose the reason why these never get fixed is no one reporting...
This one happened shockingly early.
$ make -j4 al
> Today I ran into a problem building today's GCC trunk with an older
> GCC 4.3. There is a warning in libcpp/macro.c about
> tokens_buff_remove_last_token declared inline after being called.
A previous instance: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01426.html
--
Eric Botcazou
On Thu, Dec 1, 2011 at 7:42 PM, Joseph S. Myers wrote:
> On Thu, 1 Dec 2011, Steven Bosscher wrote:
>
>> Is it valid in dialects older than C99 to declare a function static
>> inline after calling it? Should the warnings be brought back in the
>> compiler?
>
> Older dialects didn't have inline.
N
On Thu, 1 Dec 2011, Steven Bosscher wrote:
> Is it valid in dialects older than C99 to declare a function static
> inline after calling it? Should the warnings be brought back in the
> compiler?
Older dialects didn't have inline.
> One reason to bring the warnings back could be that there is now
On 11/30/2011 10:07 AM, Andrew MacLeod wrote:
> PS. Reflecting upon it, I wonder if it could be a part of the gcc
> libraries like libgomp or libitm are. During configuration we could
> check to see if there is an existing libatomic in the system, and if
> there is NOT, enable building libatomic
Hello,
Today I ran into a problem building today's GCC trunk with an older
GCC 4.3. There is a warning in libcpp/macro.c about
tokens_buff_remove_last_token declared inline after being called.
(This is apparently valid C99 but is it also valid C89?) After some
digging and diffing, it turns out tha
On Thu, Dec 1, 2011 at 11:12 AM, Amker.Cheng wrote:
> On Sat, Nov 26, 2011 at 3:41 PM, Amker.Cheng wrote:
>> Hi,
>> I looked into PR43491 a while and found in this case the gimple
>> generated before pre
>> is like:
>>
>> reg.0_12 = reg
>> ...
>> c()
>> reg.0_1 = reg
>> D.xxx = MEM[reg.0_1 + 8B]
On Sat, Nov 26, 2011 at 3:41 PM, Amker.Cheng wrote:
> Hi,
> I looked into PR43491 a while and found in this case the gimple
> generated before pre
> is like:
>
> reg.0_12 = reg
> ...
> c()
> reg.0_1 = reg
> D.xxx = MEM[reg.0_1 + 8B]
>
> The pre pass transforms it into:
>
> reg.0_12 = reg
> ...
> c
15 matches
Mail list logo