On 03/03/14 11:35, David Brown wrote:
> On 02/03/14 19:24, Denis Chertykov wrote:
>> I would remove two maintainers for AVR port:
>> 1. Anatoly Sokolov
>> 2. Eric Weddington
>>
>> I have discussed the removal with Anatoly Sokolov and he is agree with it.
>> I can't discuss the removal with Eric W
On Wed, Mar 05, 2014 at 10:39:51AM +0400, Yury Gribov wrote:
> >What is volatile instructions? Can you give us an example?
>
> Check volatile_insn_p. AFAIK there are two classes of volatile instructions:
> * volatile asm
> * unspec volatiles (target-specific instructions for e.g. protecting
> func
Hello,
In an attempt to test some optimization I destroyed the loop property in
pass_tree_loop_done and reinstated it in pass_rtl_loop_init, however then I
noticed that pass_dominator started generating wrong code.
My guess is that we should mark pass_dominator with PROP_loops as a required
pro
On 10/03/14 11:29, Jeremy Bennett wrote:
> On 03/03/14 11:35, David Brown wrote:
>> On 02/03/14 19:24, Denis Chertykov wrote:
>>> I would remove two maintainers for AVR port:
>>> 1. Anatoly Sokolov
>>> 2. Eric Weddington
>>>
>>> I have discussed the removal with Anatoly Sokolov and he is agree wi
Hello All,
I am a bit confused (or unhappy) about the current_pass variable
(in GCC 4.9 svn rev.208447); I believe we have some incoherency about it.
It is generally (as it used to be in previous versions of GCC)
a global pointer to some opt_pass, declared in gcc/tree-pass.h line 590.
It is a
Hi,
First, let me say that I'm not subscribed to the mailing list, so
please CC myself when responding.
This post is to discuss a possible extension to the GNU C language.
Note that this is still an idea and not refined.
Background
==
In C, the following code structure is ubiquitous:
On Mon, 10 Mar 2014 15:27:06 +0100
Shahbaz Youssefi wrote:
> Feedback
>
>
> Please let me know what you think. In particular, what would be the
> limitations of such a syntax? Would you be interested in seeing this
> extension to the GNU C language? What alternative symbols do you think
Hi Julian,
Thanks for the feedback.
Regarding C++ exceptions: exceptions are not really nice. They can
just make your function return without you even knowing it (forgetting
a `try/catch` or not knowing it may be needed, which is C++'s fault
and probably could have been done better). Also, they r
On Mon, Mar 10, 2014 at 03:27:06PM +0100, Shahbaz Youssefi wrote:
> Hi,
>
> First, let me say that I'm not subscribed to the mailing list, so
> please CC myself when responding.
>
> This post is to discuss a possible extension to the GNU C language.
> Note that this is still an idea and not refin
Hi,
The code produced by GCC for the RL78 target is around twice as large as that
produced by IAR and I've been trying to find out why.
The project I'm working on uses an RL78/F12 with 16KB of code flash. As I have
to get a bootloader and an application into that, I have to pay close attention
10.03.2014 18:27, Shahbaz Youssefi пишет:
FILE *fin = fopen("filename", "r") !! goto exit_no_file;
Or maybe permission denied? ;-)
Thanks for the hint. I would try to learn how to do that and
experiment on the idea if/when I get the time. I could imagine why the
community isn't interested in new syntax in general. Still, you may
never know if an idea would be attractive enough to generate some
attention! :)
On Mon, Mar 10, 20
On 03/10/2014 03:09 PM, Shahbaz Youssefi wrote:
> Regarding C++ exceptions: exceptions are not really nice. They can
> just make your function return without you even knowing it (forgetting
> a `try/catch` or not knowing it may be needed, which is C++'s fault
> and probably could have been done bet
I'm mostly interested in C. Nevertheless, you can of course also do
the same in C:
struct option_float
{
float value;
int error_code;
bool succeeded;
};
struct option_float inverse(int x) {
if (x == 0)
return (struct option_float){ .succeeded = false, .error_code = EDOM };
ret
On 03/10/2014 05:26 PM, Shahbaz Youssefi wrote:
> I'm mostly interested in C. Nevertheless, you can of course also do
> the same in C:
>
> struct option_float
> {
> float value;
> int error_code;
> bool succeeded;
> };
>
> struct option_float inverse(int x) {
> if (x == 0)
> ret
On Fri, Mar 7, 2014 at 2:38 PM, Richard Biener
wrote:
> On Thu, Mar 6, 2014 at 7:17 PM, Prathamesh Kulkarni
> wrote:
>> On Thu, Mar 6, 2014 at 6:13 PM, Richard Biener
>> wrote:
>>> On Thu, Mar 6, 2014 at 1:11 PM, Prathamesh Kulkarni
>>> wrote:
On Mon, Mar 3, 2014 at 3:32 PM, Richard Biener
> I've managed to build GCC myself so that I could experiment a bit
> but as this is my first foray into compiler internals, I'm
> struggling to work out how things fit together and what affects
> what.
The key thing to know about the RL78 backend, is that it has two
"targets" it uses. For the f
On 10/03/14 22:37, DJ Delorie wrote:
I've managed to build GCC myself so that I could experiment a bit
but as this is my first foray into compiler internals, I'm
struggling to work out how things fit together and what affects
what.
The key thing to know about the RL78 backend, is that it has tw
> Ah, that certainly explains a lot. How exactly would the fixing be
> done? Is there an example I could look at for one of the other processors?
No, RL78 is the first that uses this scheme.
> I calculated a week or two ago that we could make a code-saving of
> around 8% by using near or rel
DJ,
On Mon, 2014-03-10 at 20:17 -0400, DJ Delorie wrote:
> > Ah, that certainly explains a lot. How exactly would the fixing be
> > done? Is there an example I could look at for one of the other processors?
>
> No, RL78 is the first that uses this scheme.
I'm curious. Have you tried out othe
> I'm curious. Have you tried out other approaches before you decided
> to go with the virtual registers?
Yes. Getting GCC to understand the "unusual" addressing modes the
RL78 uses was too much for the register allocator to handle. Even
when the addressing modes are limited to "usual" ones, G
Hi,
I read LLVM code for a while,and a question raise:Whose scheduler is
better?
LLVM brings in the DAG,and make it look important just like IR or
MachineInst.But is that necessary?I don't see what kind of problem
it tries to solve.
From the pipeline of the compiler, LLVM ca
On Mon, Mar 10, 2014 at 6:59 PM, lin zuojian wrote:
>
> Hi,
> I read LLVM code for a while,and a question raise:Whose scheduler is
> better?
> LLVM brings in the DAG,and make it look important just like IR or
> MachineInst.But is that necessary?I don't see what kind of problem
>
On Mon, Mar 10, 2014 at 07:11:43PM -0700, Chandler Carruth wrote:
> On Mon, Mar 10, 2014 at 6:59 PM, lin zuojian wrote:
> >
> > Hi,
> > I read LLVM code for a while,and a question raise:Whose scheduler is
> > better?
> > LLVM brings in the DAG,and make it look important just like IR or
On Mon, Mar 10, 2014 at 7:33 PM, lin zuojian wrote:
> Hi,
> I just ask for opinions.I think many GCC developers do familiar with
> the opponent.If I ask in the LLVM mailing list, I have to worry
> about If they are familiar with GCC, too(what's sched2 pass?).
I suspect you will have t
Hi Chandler,
Thanks a lot for your answer.It is pretty misleading to find out
that DAG has schedule unit.
--
Regards
lin zuojian
26 matches
Mail list logo
