Small Device C Compiler suite

The URL of the SDCC 2.8.0 Release page was wrong in my previous post.
The correct one is: http://sdcc.wiki.sourceforge.net/SDCC+2.8.0+Release.
But you already know it...

Borut


Borut Razem wrote:
> Dear sdcc developers,
>
> please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.
>
> The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.
>
> Borut
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>
>

On Sun, 9 Mar 2008, Borut Razem wrote:

> Dear sdcc developers,
> 
> please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.
> 
> The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.
> 
> Borut

May I suggest to apply the patch in
  http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811

thats an uggly bug, which was very easy to fix.

Robert Larice

Hi,

> May I suggest to apply the patch in
>   http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811
> 
> thats an ugly bug, which was very easy to fix.

Although the report focuses on the PIC16 port, the bug itself is not 
port-specific and probably affects all ports.

I'd support fixing this, but I am not familiar enough with the front-end 
to judge this one. Could one of the more involved developers review the 
patch and possibly apply it (with Borut's consent)?

Thanks,
Raphael

Bug 1505811 is indeed nothing PIC specific and fails on all targets. 
The patch by Robert also seems to fix it. But I think it is too 
strict. IMO it should check if this sym is used to find the function 
it wants to call. I propose:

    case CALL:
        /* if local & not passed as parameter &
           not used to find the function then ok */
        if (sym->level && !astHasSymbol (pbody->right, sym) &&
            !astHasSymbol (pbody->left, sym))
          {
            return TRUE;
          }
      return FALSE;

Borut, what do you say? Shall I fix it or will it have to wait?

Maarten

> On Sun, 9 Mar 2008, Borut Razem wrote:
> 
> > Dear sdcc developers,
> > 
> > please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.
> > 
> > The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.
> > 
> > Borut
> 
> May I suggest to apply the patch in
>   http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811
> 
> thats an uggly bug, which was very easy to fix.
> 
> Robert Larice

Maarten,

I didn't look into details, but if you think that it is OK, I'd say let 
do it.

Borut


Maarten Brock wrote:
> Bug 1505811 is indeed nothing PIC specific and fails on all targets. 
> The patch by Robert also seems to fix it. But I think it is too 
> strict. IMO it should check if this sym is used to find the function 
> it wants to call. I propose:
>
>     case CALL:
>         /* if local & not passed as parameter &
>            not used to find the function then ok */
>         if (sym->level && !astHasSymbol (pbody->right, sym) &&
>             !astHasSymbol (pbody->left, sym))
>           {
>             return TRUE;
>           }
>       return FALSE;
>
> Borut, what do you say? Shall I fix it or will it have to wait?
>
> Maarten
>
>   
>> On Sun, 9 Mar 2008, Borut Razem wrote:
>>
>>     
>>> Dear sdcc developers,
>>>
>>> please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.
>>>
>>> The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.
>>>
>>> Borut
>>>       
>> May I suggest to apply the patch in
>>   http://sourceforge.net/tracker/index.php?func=detail&group_id=599&atid=100599&aid=1505811
>>
>> thats an uggly bug, which was very easy to fix.
>>
>> Robert Larice
>>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html  xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head>
<title></title>
<meta http-equiv="content-type" content="text/html;charset=utf-8"/>
<meta http-equiv="Content-Style-Type" content="text/css"/>
</head>
<body>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
Let me first do some extensive testing. If it turns out 
OK I will commit then.</span></font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
<br />
</span>
</font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
Maarten</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
<br />
</span>
</font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Maarten,</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; I didn't look into details, but if you think that it is OK, I'd say let </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; do it.</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Borut</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Maarten Brock wrote:</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; Bug 1505811 is indeed nothing PIC specific and fails on all targets. </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; The patch by Robert also seems to fix it. But I think it is too </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; strict. IMO it should check if this sym is used to find the function </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; it wants to call. I propose:</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160; case CALL:</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; /* if local &amp; not passed as parameter &amp;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; not used to find the function then ok */</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; if (sym-&gt;level &amp;&amp; !astHasSymbol (pbody-&gt;right, sym) &amp;&amp;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; !astHasSymbol (pbody-&gt;left, sym))</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; {</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; return TRUE;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; }</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160;&#160;&#160;&#160;&#160; return FALSE;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; Borut, what do you say? Shall I fix it or will it have to wait?</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; Maarten</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&#160;&#160; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt; On Sun, 9 Mar 2008, Borut Razem wrote:</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&#160;&#160;&#160;&#160; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt; Dear sdcc developers,</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt; please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt; The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt; Borut</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&gt;&#160;&#160;&#160;&#160;&#160;&#160; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt; May I suggest to apply the patch in</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;&#160;&#160; http://sourceforge.net/tracker/index.php?func=detail&amp;group_id=599&amp;atid=100599&amp;aid=1505811</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt; thats an uggly bug, which was very easy to fix.</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;&gt; Robert Larice</span></font>
</div>
<div align="left">
&nbsp;</div>
</body>
</html>

On Sun, 9 Mar 2008, Maarten Brock wrote:

> Bug 1505811 is indeed nothing PIC specific and fails on all targets. 
> The patch by Robert also seems to fix it. But I think it is too 
> strict. IMO it should check if this sym is used to find the function 
> it wants to call. I propose:
> 
>     case CALL:
>         /* if local & not passed as parameter &
>            not used to find the function then ok */
>         if (sym->level && !astHasSymbol (pbody->right, sym) &&
>             !astHasSymbol (pbody->left, sym))
>           {
>             return TRUE;
>           }
>       return FALSE;
> 

Hello Maarten,

  are you sure checking for the symbol not occuring in pbody->left is
  enough ?  Its a long time ago, i think i was nervous back then
    thinking about the possibility of something like
       for(local_i = ...) {
          another_local = local_i + 42;
          array[another_local]();
       }
  just checking for the left side of the CALL beeing a symbol
    is much easier to understand, safer, and propably would
    very seldom influence optimisation.

Robert Larice

Robert

Thanks for the comment. But IMO 'another_local = local_i + 42;' should be
caught by the '=' and the '+' cases in isConformingBody (and is in my
preliminary tests).

Maarten

> On Sun, 9 Mar 2008, Maarten Brock wrote:
>
>> Bug 1505811 is indeed nothing PIC specific and fails on all targets.
>> The patch by Robert also seems to fix it. But I think it is too
>> strict. IMO it should check if this sym is used to find the function
>> it wants to call. I propose:
>>
>>     case CALL:
>>         /* if local & not passed as parameter &
>>            not used to find the function then ok */
>>         if (sym->level && !astHasSymbol (pbody->right, sym) &&
>>             !astHasSymbol (pbody->left, sym))
>>           {
>>             return TRUE;
>>           }
>>       return FALSE;
>>
>
> Hello Maarten,
>
>   are you sure checking for the symbol not occuring in pbody->left is
>   enough ?  Its a long time ago, i think i was nervous back then
>     thinking about the possibility of something like
>        for(local_i = ...) {
>           another_local = local_i + 42;
>           array[another_local]();
>        }
>   just checking for the left side of the CALL beeing a symbol
>     is much easier to understand, safer, and propably would
>     very seldom influence optimisation.
>
> Robert Larice

On Mon, 10 Mar 2008, Maarten Brock wrote:

> Robert
> 
> Thanks for the comment. But IMO 'another_local = local_i + 42;' should be
> caught by the '=' and the '+' cases in isConformingBody (and is in my
> preliminary tests).
> 
> Maarten

Thank you Maarten for fixing that one.

I've found another bug report
   #1717943  wrong optimized flow 
perhaps you have time to have look on that one too ?
  I think it is of somewhat similiar complexity.

This bug has to to do with
  moving "loop invariants" to the outside of a loop.

If there is something like

  while(...) {
    global = expr ....;
    if(...)
      fun_call();
  }

sdcc eronously considers the
   global = 
assignment to be a candidate for such movement to the outside of the loop.
But of course if fun_call() somehow modfies that global 
  this will lead to incorrect code.

Robert Larice

Robert,

We are at a code freeze. The bug you mention was on my 
(rather long) shortlist of which I fixed some and others 
I knew would have to wait until after the release.

I care more about a timely release than a total bugfree 
one. The longer we wait, the longer the users (or 
distribution maintainers) who rely on a released version 
have to wait for all the other bug fixes.

So unless the release manager asks me to try and fix it 
before the release, I will not. I hope you understand.

Maarten

> On Mon, 10 Mar 2008, Maarten Brock wrote:
> 
> > Robert
> > 
> > Thanks for the comment. But IMO 'another_local = local_i + 42;' should be
> > caught by the '=' and the '+' cases in isConformingBody (and is in my
> > preliminary tests).
> > 
> > Maarten
> 
> Thank you Maarten for fixing that one.
> 
> I've found another bug report
>    #1717943  wrong optimized flow 
> perhaps you have time to have look on that one too ?
>   I think it is of somewhat similiar complexity.
> 
> This bug has to to do with
>   moving "loop invariants" to the outside of a loop.
> 
> If there is something like
> 
>   while(...) {
>     global = expr ....;
>     if(...)
>       fun_call();
>   }
> 
> sdcc eronously considers the
>    global = 
> assignment to be a candidate for such movement to the outside of the loop.
> But of course if fun_call() somehow modfies that global 
>   this will lead to incorrect code.
> 
> Robert Larice

On Tue, 11 Mar 2008, Maarten Brock wrote:

> Robert,
> 
> We are at a code freeze. The bug you mention was on my 
> (rather long) shortlist of which I fixed some and others 
> I knew would have to wait until after the release.
> 
> I care more about a timely release than a total bugfree 
> one. The longer we wait, the longer the users (or 
> distribution maintainers) who rely on a released version 
> have to wait for all the other bug fixes.
> 
> So unless the release manager asks me to try and fix it 
> before the release, I will not. I hope you understand.
> 
> Maarten

of course i understand, especially if you have it on a list anyway.

Robert Larice

Borut,

I have a question about the release wiki. On te tasks 
list two bugs are still open. Are they now officially 
postponed (if so please update the list) or is it still 
desired to work on these bugs to try and fix them before 
RC2?

Maarten

> Dear sdcc developers,
> 
> please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.
> 
> The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.
> 
> Borut

Dear fellow developers,

After below announcement of a code freeze some have still commited 
bug fixes to the subversion repository without discussing them first 
on the developer list. Fortunately they were low risk and probably 
would have been blessed anyway but it undermines the task of the 
release manager. Please try to play by the rules during this 
exciting period of making a release.

When RC2 is created I strongly recommend not to do any commit 
without asking for consent first, because it could result in another 
RC-period.

Thanks,
Maarten

> Dear sdcc developers, 
> 
> please consider the svn main branch as frozen, which means that only
> fixes for high severity bugs (after an agreement on this mailing list)
> and changes in the documentation can be committed. 
> 
> The SDCC 2.8.0 release schedule is published at
> http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release. 
> 
> Borut

Opps, sorry.  That was me.  I hadn't followed all these messages carefully.

That commit only effects the library function printf_fast_f, which is 
only on mcs51.  Briefly, negative floating point numbers weren't being 
handled properly in a couple places.

Again, I'm sorry.  I should have been paying closer attention.


-Paul

SDCC 2.8.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2 and http://sdcc.sourceforge.net/snap.php

If you find a mistake, please send a mail to sdcc-devel mailing list sdcc-devel@....

I would appreciate any reports about a success or failure of running pre-compiled binary packages.

Borut

Dear sdcc developers,

the sdcc RC2 is released. Thanks to anybody helped to bring it to the life.

Please consider the svn main branch as DEEPLY FROZEN, which means 
NOTHING can be committed without the agreement between adcc developers 
and release manager.

The SDCC 2.8.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.8.0+Release.


Borut


Borut Razem wrote:
> SDCC 2.8.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2 and http://sdcc.sourceforge.net/snap.php
>
> If you find a mistake, please send a mail to sdcc-devel mailing list sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running pre-compiled binary packages.
>
> Borut
>
>

Hello Borut,

I wanted to bring you good news, but alas. I installed 
the W32 version on both XP and W98. XP looks ok, but on 
W98 the path is not set. It had RC1 on it and that was 
uninstalled first by the installer. Afterwards it 
requested a reboot and the SDCC-path was removed! I 
reran the RC2 installer several times and sometimes it 
asked to add the path, but never did it appear in 
autoexec.bat. Finally I reinstalled RC1 and this 
correctly added the path (but forgot to ask for reboot).

Maarten

> SDCC 2.8.0 Release Candidate 2 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available at:
> http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2 and
> http://sdcc.sourceforge.net/snap.php 
> 
> If you find a mistake, please send a mail to sdcc-devel mailing list
> sdcc-devel@.... 
> 
> I would appreciate any reports about a success or failure of running
> pre-compiled binary packages. 
> 
> Borut

Maarten,

I uploaded the new Win setup at:
http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2/sdcc-2.8.0-rc2a-setup.exe

Can you please test it?

Thanks for the report,
Borut


Maarten Brock wrote:
> Hello Borut,
>
> I wanted to bring you good news, but alas. I installed 
> the W32 version on both XP and W98. XP looks ok, but on 
> W98 the path is not set. It had RC1 on it and that was 
> uninstalled first by the installer. Afterwards it 
> requested a reboot and the SDCC-path was removed! I 
> reran the RC2 installer several times and sometimes it 
> asked to add the path, but never did it appear in 
> autoexec.bat. Finally I reinstalled RC1 and this 
> correctly added the path (but forgot to ask for reboot).
>
> Maarten
>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html  xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head>
<title></title>
<meta http-equiv="content-type" content="text/html;charset=utf-8"/>
<meta http-equiv="Content-Style-Type" content="text/css"/>
</head>
<body>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
Borut,</span></font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
<br />
</span>
</font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
There is a difference. I had RC1 installed and then ran 
the RC2a setup. It uninstalled RC1 and after copying the 
new files it only asked for reboot, no request for 
adding the path (which should not be necessary because 
it already was in autoexec.bat). It removed the path 
however and thus required the reboot I guess. Still in 
the end I had no path set.</span></font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
<br />
</span>
</font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
So I reran the RC2a setup to see if it would fix the 
path for me. This time it does ask to add it and now I 
do see it in autoexec.bat. So it only works after 
double-install.</span></font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
<br />
</span>
</font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
Now my question is: could something be wrong in RC1 that 
causes this and should I retry with 2.7.0 installed 
first?</span></font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
<br />
</span>
</font>
</div>
<div align="left">
<font face="Courier New" size="2">
<span style=" font-size:10pt">
Maarten</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
<br />
</span>
</font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Maarten,</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; I uploaded the new Win setup at:</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2/sdcc-2.8.0-rc2a-setup.exe</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Can you please test it?</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Thanks for the report,</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Borut</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; Maarten Brock wrote:</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; Hello Borut,</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; I wanted to bring you good news, but alas. I installed </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; the W32 version on both XP and W98. XP looks ok, but on </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; W98 the path is not set. It had RC1 on it and that was </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; uninstalled first by the installer. Afterwards it </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; requested a reboot and the SDCC-path was removed! I </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; reran the RC2 installer several times and sometimes it </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; asked to add the path, but never did it appear in </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; autoexec.bat. Finally I reinstalled RC1 and this </span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; correctly added the path (but forgot to ask for reboot).</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt;</span></font>
</div>
<div align="left">
<font face="Arial" color="#7f0000" size="2">
<span style=" font-size:10pt">
&gt; &gt; Maarten</span></font>
</div>
<div align="left">
&nbsp;</div>
</body>
</html>

Borut,

I tried anyway with 2.7.0 pre-installed. This time the 
uninstall did not remove the path and RC2a asks to add 
it. Now I only hope that this is not influenced by the 
fact that RC1, RC2 & RC2a all were on the system before 
and maybe one of them left something behind during 
uninstall.

Maarten

> Borut, 
> 
> There is a difference. I had RC1 installed and then ran the RC2a setup. 
> It uninstalled RC1 and after copying the new files it only asked for 
> reboot, no request for adding the path (which should not be necessary 
> because it already was in autoexec.bat). It removed the path however and 
> thus required the reboot I guess. Still in the end I had no path set. 
> 
> So I reran the RC2a setup to see if it would fix the path for me. This 
> time it does ask to add it and now I do see it in autoexec.bat. So it 
> only works after double-install. 
> 
> Now my question is: could something be wrong in RC1 that causes this and 
> should I retry with 2.7.0 installed first? 
> 
> Maarten 
> 
> > Maarten, 
> > 
> > I uploaded the new Win setup at: 
> > http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2/sdcc-2.8.0-rc2a-setup.exe 
> > 
> > Can you please test it? 
> > 
> > Thanks for the report, 
> > Borut 
> > 
> > 
> > Maarten Brock wrote: 
> > > Hello Borut, 
> > > 
> > > I wanted to bring you good news, but alas. I installed 
> > > the W32 version on both XP and W98. XP looks ok, but on 
> > > W98 the path is not set. It had RC1 on it and that was 
> > > uninstalled first by the installer. Afterwards it 
> > > requested a reboot and the SDCC-path was removed! I 
> > > reran the RC2 installer several times and sometimes it 
> > > asked to add the path, but never did it appear in 
> > > autoexec.bat. Finally I reinstalled RC1 and this 
> > > correctly added the path (but forgot to ask for reboot). 
> > > 
> > > Maarten 
>

Maarten Brock wrote:
> Borut,
>
> I tried anyway with 2.7.0 pre-installed. This time the 
> uninstall did not remove the path and RC2a asks to add 
> it.
Due to a bug in 2.7.0 setup the path is not removed from autoexec.bat.
The setup always asks to add the path, even if it is already there. In 
this case is intelligent enough not to add it once more.

> Now I only hope that this is not influenced by the 
> fact that RC1, RC2 & RC2a all were on the system before 
> and maybe one of them left something behind during 
> uninstall.
>
> Maarten
>
>   
The setup chages the following places on Win98:
- creates the SDCC directory in C:\Program Files
- adds the path to the autoexec.bat, if selected
- adds the SDCC entry to the Start Menu/Programs
- adds the application registry keys:
[HKEY_LOCAL_MACHINE\Software\SDCC]
  @="C:\\Program Files\\SDCC"
  "VersionMajor"=dword:00000002
  "VersionMinor"=dword:00000008
  "VersionRevision"=dword:00000000
  "VersionBuild"=dword:000013fd
- adds the uninstall registry keys:
  
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\SDCC]
  "NSIS:StartMenuDir"="SDCC"
  "UninstallString"="C:\Program Files\SDCC\uninstall.exe"
  "InstallLocation"="C:\Program Files\SDCC"
  "DisplayName"="SDCC"
  "Publisher"="sdcc.sourceforge.net"
  "URLInfoAbout"="http://sdcc.sourceforge.net/"
  "HelpLink"="http://sdcc.sourceforge.net/"
  "URLUpdateInfo"="http://sdcc.sourceforge.net/"

You can check manually if any of this information remained after the 
uninstallations.

I found an other problem with hiding the installer windows during the 
uninstallation. I prepared an other version:
http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2/sdcc-2.8.0-rc2b-setup.exe

Borut


>> Borut, 
>>
>> There is a difference. I had RC1 installed and then ran the RC2a setup. 
>> It uninstalled RC1 and after copying the new files it only asked for 
>> reboot, no request for adding the path (which should not be necessary 
>> because it already was in autoexec.bat). It removed the path however and 
>> thus required the reboot I guess. Still in the end I had no path set. 
>>
>> So I reran the RC2a setup to see if it would fix the path for me. This 
>> time it does ask to add it and now I do see it in autoexec.bat. So it 
>> only works after double-install. 
>>
>> Now my question is: could something be wrong in RC1 that causes this and 
>> should I retry with 2.7.0 installed first? 
>>
>> Maarten 
>>

Ok, I just uninstalled RC2a and it did not remove the 
sdcc directory and still had sdcc.url in it. The rest is 
clean.


> Maarten Brock wrote:
> > Borut,
> >
> > I tried anyway with 2.7.0 pre-installed. This time the 
> > uninstall did not remove the path and RC2a asks to add 
> > it.
> Due to a bug in 2.7.0 setup the path is not removed from autoexec.bat.
> The setup always asks to add the path, even if it is already there. In 
> this case is intelligent enough not to add it once more.
> 
> > Now I only hope that this is not influenced by the 
> > fact that RC1, RC2 & RC2a all were on the system before 
> > and maybe one of them left something behind during 
> > uninstall.
> >
> > Maarten
> >
> >   
> The setup chages the following places on Win98:
> - creates the SDCC directory in C:\Program Files
> - adds the path to the autoexec.bat, if selected
> - adds the SDCC entry to the Start Menu/Programs
> - adds the application registry keys:
> [HKEY_LOCAL_MACHINE\Software\SDCC]
>   @="C:\\Program Files\\SDCC"
>   "VersionMajor"=dword:00000002
>   "VersionMinor"=dword:00000008
>   "VersionRevision"=dword:00000000
>   "VersionBuild"=dword:000013fd
> - adds the uninstall registry keys:
>   
> [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\SDCC]
>   "NSIS:StartMenuDir"="SDCC"
>   "UninstallString"="C:\Program Files\SDCC\uninstall.exe"
>   "InstallLocation"="C:\Program Files\SDCC"
>   "DisplayName"="SDCC"
>   "Publisher"="sdcc.sourceforge.net"
>   "URLInfoAbout"="http://sdcc.sourceforge.net/"
>   "HelpLink"="http://sdcc.sourceforge.net/"
>   "URLUpdateInfo"="http://sdcc.sourceforge.net/"
> 
> You can check manually if any of this information remained after the 
> uninstallations.
> 
> I found an other problem with hiding the installer windows during the 
> uninstallation. I prepared an other version:
> http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2/sdcc-2.8.0-rc2b-setup.exe
> 
> Borut
> 
> 
> >> Borut, 
> >>
> >> There is a difference. I had RC1 installed and then ran the RC2a setup. 
> >> It uninstalled RC1 and after copying the new files it only asked for 
> >> reboot, no request for adding the path (which should not be necessary 
> >> because it already was in autoexec.bat). It removed the path however and 
> >> thus required the reboot I guess. Still in the end I had no path set. 
> >>
> >> So I reran the RC2a setup to see if it would fix the path for me. This 
> >> time it does ask to add it and now I do see it in autoexec.bat. So it 
> >> only works after double-install. 
> >>
> >> Now my question is: could something be wrong in RC1 that causes this and 
> >> should I retry with 2.7.0 installed first? 
> >>
> >> Maarten 
> >>     
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

After I cleaned and checked everything you pointed out, 
I installed RC2b. This went fine. Then I uninstalled it 
and that also went fine. Good job.

Now I will try once again with 2.7.0 pre-installed 
because it can be a typical situation.

> Ok, I just uninstalled RC2a and it did not remove the 
> sdcc directory and still had sdcc.url in it. The rest is 
> clean.
> 
> 
> > Maarten Brock wrote:
> > > Borut,
> > >
> > > I tried anyway with 2.7.0 pre-installed. This time the 
> > > uninstall did not remove the path and RC2a asks to add 
> > > it.
> > Due to a bug in 2.7.0 setup the path is not removed from autoexec.bat.
> > The setup always asks to add the path, even if it is already there. In 
> > this case is intelligent enough not to add it once more.
> > 
> > > Now I only hope that this is not influenced by the 
> > > fact that RC1, RC2 & RC2a all were on the system before 
> > > and maybe one of them left something behind during 
> > > uninstall.
> > >
> > > Maarten
> > >
> > >   
> > The setup chages the following places on Win98:
> > - creates the SDCC directory in C:\Program Files
> > - adds the path to the autoexec.bat, if selected
> > - adds the SDCC entry to the Start Menu/Programs
> > - adds the application registry keys:
> > [HKEY_LOCAL_MACHINE\Software\SDCC]
> >   @="C:\\Program Files\\SDCC"
> >   "VersionMajor"=dword:00000002
> >   "VersionMinor"=dword:00000008
> >   "VersionRevision"=dword:00000000
> >   "VersionBuild"=dword:000013fd
> > - adds the uninstall registry keys:
> >   
> > [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\SDCC]
> >   "NSIS:StartMenuDir"="SDCC"
> >   "UninstallString"="C:\Program Files\SDCC\uninstall.exe"
> >   "InstallLocation"="C:\Program Files\SDCC"
> >   "DisplayName"="SDCC"
> >   "Publisher"="sdcc.sourceforge.net"
> >   "URLInfoAbout"="http://sdcc.sourceforge.net/"
> >   "HelpLink"="http://sdcc.sourceforge.net/"
> >   "URLUpdateInfo"="http://sdcc.sourceforge.net/"
> > 
> > You can check manually if any of this information remained after the 
> > uninstallations.
> > 
> > I found an other problem with hiding the installer windows during the 
> > uninstallation. I prepared an other version:
> > http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2/sdcc-2.8.0-rc2b-setup.exe
> > 
> > Borut
> > 
> > 
> > >> Borut, 
> > >>
> > >> There is a difference. I had RC1 installed and then ran the RC2a setup. 
> > >> It uninstalled RC1 and after copying the new files it only asked for 
> > >> reboot, no request for adding the path (which should not be necessary 
> > >> because it already was in autoexec.bat). It removed the path however and 
> > >> thus required the reboot I guess. Still in the end I had no path set. 
> > >>
> > >> So I reran the RC2a setup to see if it would fix the path for me. This 
> > >> time it does ask to add it and now I do see it in autoexec.bat. So it 
> > >> only works after double-install. 
> > >>
> > >> Now my question is: could something be wrong in RC1 that causes this and 
> > >> should I retry with 2.7.0 installed first? 
> > >>
> > >> Maarten

And installing RC2b with 2.7.0 pre-installed went ok 
too. It did not ask for a reboot and left the path in 
place. And finally the uninstall was complete too.

Congratulations.

> After I cleaned and checked everything you pointed out, 
> I installed RC2b. This went fine. Then I uninstalled it 
> and that also went fine. Good job.
> 
> Now I will try once again with 2.7.0 pre-installed 
> because it can be a typical situation.
> 
> > Ok, I just uninstalled RC2a and it did not remove the 
> > sdcc directory and still had sdcc.url in it. The rest is 
> > clean.
> > 
> > 
> > > Maarten Brock wrote:
> > > > Borut,
> > > >
> > > > I tried anyway with 2.7.0 pre-installed. This time the 
> > > > uninstall did not remove the path and RC2a asks to add 
> > > > it.
> > > Due to a bug in 2.7.0 setup the path is not removed from autoexec.bat.
> > > The setup always asks to add the path, even if it is already there. In 
> > > this case is intelligent enough not to add it once more.
> > > 
> > > > Now I only hope that this is not influenced by the 
> > > > fact that RC1, RC2 & RC2a all were on the system before 
> > > > and maybe one of them left something behind during 
> > > > uninstall.
> > > >
> > > > Maarten
> > > >
> > > >   
> > > The setup chages the following places on Win98:
> > > - creates the SDCC directory in C:\Program Files
> > > - adds the path to the autoexec.bat, if selected
> > > - adds the SDCC entry to the Start Menu/Programs
> > > - adds the application registry keys:
> > > [HKEY_LOCAL_MACHINE\Software\SDCC]
> > >   @="C:\\Program Files\\SDCC"
> > >   "VersionMajor"=dword:00000002
> > >   "VersionMinor"=dword:00000008
> > >   "VersionRevision"=dword:00000000
> > >   "VersionBuild"=dword:000013fd
> > > - adds the uninstall registry keys:
> > >   
> > > [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\SDCC]
> > >   "NSIS:StartMenuDir"="SDCC"
> > >   "UninstallString"="C:\Program Files\SDCC\uninstall.exe"
> > >   "InstallLocation"="C:\Program Files\SDCC"
> > >   "DisplayName"="SDCC"
> > >   "Publisher"="sdcc.sourceforge.net"
> > >   "URLInfoAbout"="http://sdcc.sourceforge.net/"
> > >   "HelpLink"="http://sdcc.sourceforge.net/"
> > >   "URLUpdateInfo"="http://sdcc.sourceforge.net/"
> > > 
> > > You can check manually if any of this information remained after the 
> > > uninstallations.
> > > 
> > > I found an other problem with hiding the installer windows during the 
> > > uninstallation. I prepared an other version:
> > > http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc2/sdcc-2.8.0-rc2b-setup.exe
> > > 
> > > Borut
> > > 
> > > 
> > > >> Borut, 
> > > >>
> > > >> There is a difference. I had RC1 installed and then ran the RC2a setup. 
> > > >> It uninstalled RC1 and after copying the new files it only asked for 
> > > >> reboot, no request for adding the path (which should not be necessary 
> > > >> because it already was in autoexec.bat). It removed the path however and 
> > > >> thus required the reboot I guess. Still in the end I had no path set. 
> > > >>
> > > >> So I reran the RC2a setup to see if it would fix the path for me. This 
> > > >> time it does ask to add it and now I do see it in autoexec.bat. So it 
> > > >> only works after double-install. 
> > > >>
> > > >> Now my question is: could something be wrong in RC1 that causes this and 
> > > >> should I retry with 2.7.0 installed first? 
> > > >>
> > > >> Maarten 
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Dear sdcc developers,

please consider the svn main branch as frozen, which means that only fixes for high severity bugs (after an agreement on this mailing list) and changes in the documentation can be committed.

The SDCC 2.9.0 release schedule is published at http://sdcc.wiki.sourceforge.net/SDCC+2.9.0+Release.

Borut

SDCC 2.9.0 Release Candidate 2 source, doc and binary packages for x86 Linux, 32 bit Windows and universal Mac OS X are available at: http://sdcc.sourceforge.net/snap.php

If you find a mistake, please send a mail to sdcc-devel mailing list sdcc-devel@....

I would appreciate any reports about a success or failure of running pre-compiled binary packages.

Borut

Dear sdcc developers,

the sdcc RC2 is released. Thanks to anybody helped to bring it to the life.

Please consider the svn main branch as DEEPLY FROZEN, which means NOTHING can be committed without the agreement between sdcc developers and release manager.

The SDCC 2.9.0 release schedule is published at http://sdcc.sourceforge.net/release_wiki/index.php?page=SDCC+2.9.0+Release.


Borut


Borut Razem wrote:
> SDCC 2.9.0 Release Candidate 2 source, doc and binary packages for x86 
> Linux, 32 bit Windows and universal Mac OS X are available at: 
> http://sdcc.sourceforge.net/snap.php
>
> If you find a mistake, please send a mail to sdcc-devel mailing list 
> sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running 
> pre-compiled binary packages.
>
> Borut
>
>

Dear sdcc developers,

please consider the svn main branch as frozen, which means that only 
fixes for high severity bugs (after an agreement on this mailing list) 
and changes in the documentation can be committed.

The SDCC 3.0.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.0.0%20Release


Borut

Please review the documentation.

Raphael, please review / update the table of supported pic devices in 
sdccman.lyx

Borut


On 10/10/2010 05:15 PM, Borut Razem wrote:
> Dear sdcc developers,
>
> please consider the svn main branch as frozen, which means that only
> fixes for high severity bugs (after an agreement on this mailing list)
> and changes in the documentation can be committed.
>
> The SDCC 3.0.0 release schedule is published at
> http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.0.0%20Release
>
>
> Borut
>

Hi,

No regression for me on winxp, using mplab and mplab-sdcc. Just had to add
the --use-non-free for PIC libraries.

about the doc:
is the pic port still considered "in development"?
the -mavr option is still documented. Is that port still included?
there is a right-aligned extra "!" at the end of page 39. and also at the
first paragraph of "tips" page 82
at end of page 76 there is: on a single channel oscilloscope you could f.e.
if that means "for example", then I think the proper abbreviation is "e.g."

Thanks.
Sebastien

On Sun, Oct 10, 2010 at 5:24 PM, Borut Razem <borut.razem@...> wrote:

> Please review the documentation.
>
> Raphael, please review / update the table of supported pic devices in
> sdccman.lyx
>
> Borut
>
>
> On 10/10/2010 05:15 PM, Borut Razem wrote:
> > Dear sdcc developers,
> >
> > please consider the svn main branch as frozen, which means that only
> > fixes for high severity bugs (after an agreement on this mailing list)
> > and changes in the documentation can be committed.
> >
> > The SDCC 3.0.0 release schedule is published at
> > http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.0.0%20Release
> >
> >
> > Borut
> >
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

On 10/11/2010 06:12 PM, Sébastien Lorquet wrote:
> Hi,
>
> No regression for me on winxp, using mplab and mplab-sdcc. Just had to 
> add the --use-non-free for PIC libraries.
>

Great!

> about the doc:
> is the pic port still considered "in development"?

On my opinion it will be "in development" until it passes the regression 
tests.

> the -mavr option is still documented. Is that port still included?
> there is a right-aligned extra "!" at the end of page 39. and also at 
> the first paragraph of "tips" page 82
> at end of page 76 there is: on a single channel oscilloscope you could 
> f.e.
> if that means "for example", then I think the proper abbreviation is 
> "e.g."
>

Fixed.

Thanks,
Borut


> Thanks.
> Sebastien
>
> On Sun, Oct 10, 2010 at 5:24 PM, Borut Razem <borut.razem@... 
> <mailto:borut.razem@...>> wrote:
>
>     Please review the documentation.
>
>     Raphael, please review / update the table of supported pic devices in
>     sdccman.lyx
>
>     Borut
>
>
>     On 10/10/2010 05:15 PM, Borut Razem wrote:
>     > Dear sdcc developers,
>     >
>     > please consider the svn main branch as frozen, which means that only
>     > fixes for high severity bugs (after an agreement on this mailing
>     list)
>     > and changes in the documentation can be committed.
>     >
>     > The SDCC 3.0.0 release schedule is published at
>     > http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.0.0%20Release
>     >
>     >
>     > Borut
>     >
>
>     ------------------------------------------------------------------------------
>     Beautiful is writing same markup. Internet Explorer 9 supports
>     standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>     Spend less time writing and  rewriting code and more time creating
>     great
>     experiences on the web. Be a part of the beta today.
>     http://p.sf.net/sfu/beautyoftheweb
>     _______________________________________________
>     sdcc-devel mailing list
>     sdcc-devel@...
>     <mailto:sdcc-devel@...>
>     https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2&  L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Hi,

> there is a right-aligned extra "!" at the end of page 39. and also at the first paragraph of "tips" page 82

They are there on purpose:)  Maybe they some time will be some of those
exclamation marks enclosed in a yellow triangle at the far left or right
of a book.
They were meant for info that could be easily overread and that could
come as a surprise/trouble even for experienced users of other
embedded compilers. Well, at least this is my notion of the extra '!'.

Maybe not each ocurrence of this exclamation marks fits this criterion
but they should _not_ be removed alltogether.

(strictly speaking these exclamation marks are not right-aligned but
are intended to be  rendered right of the right margin (sorry if I
didn't use the right terms).

Note, these exclamation marks are not rendered in the html documentation,
(which likely is a shortcoming of latex2html).
But as html documentation presumably is not considered the primary
source of information if pdf documentation is available this should be
ignored for now?)

Greetings,
Frieder
___________________________________________________________
WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2

Hi,

I understand now!
But I do not think they are noticeable for what they are. A square box
enclosing the important text might be easier to notice.
I don't know if you can do that with latex, or if something else -- or the
current situation -- is better.

Sebastien

On Tue, Oct 12, 2010 at 12:11 AM, Frieder Ferlemann <
Frieder.Ferlemann@...> wrote:

> Hi,
>
> > there is a right-aligned extra "!" at the end of page 39. and also at the
> first paragraph of "tips" page 82
>
> They are there on purpose:)  Maybe they some time will be some of those
> exclamation marks enclosed in a yellow triangle at the far left or right
> of a book.
> They were meant for info that could be easily overread and that could
> come as a surprise/trouble even for experienced users of other
> embedded compilers. Well, at least this is my notion of the extra '!'.
>
> Maybe not each ocurrence of this exclamation marks fits this criterion
> but they should _not_ be removed alltogether.
>
> (strictly speaking these exclamation marks are not right-aligned but
> are intended to be  rendered right of the right margin (sorry if I
> didn't use the right terms).
>
> Note, these exclamation marks are not rendered in the html documentation,
> (which likely is a shortcoming of latex2html).
> But as html documentation presumably is not considered the primary
> source of information if pdf documentation is available this should be
> ignored for now?)
>
> Greetings,
> Frieder
> ___________________________________________________________
> WEB.DE DSL Doppel-Flat ab 19,99 &euro;/mtl.! Jetzt auch mit
> gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>

Dear sdcc developers,

> please consider the svn main branch as frozen, which means that only  
> fixes for high severity bugs (after an agreement on this mailing list)  
> and changes in the documentation can be committed.

The include paths to the pic14 headers is wrong: pic14 uses just "pic" is  
its include path suffix, but port->target (which is used in the current  
implementation) is "pic14". As a consequence, even using --use-non-free  
does not help SDCC to find the PIC headers.

I attached a patch that specifically handles this case for the pic14  
target -- which is not too beautiful, but introducing another helper like  
PORT.general.get_model seems to be too much of a change for now. A more  
pleasant side-effect of the special treatment in SDCCmain.c is that the  
additional include path generation in pic/main.c is superfluous once the  
correct path is setup in SDCCmain.c -- a true improvement  
maintainability-wise.

Alternatively, one could rename the pic directories (src/pic,  
device/include/pic, device/lib/pic) to pic14 -- which also seems to be too  
much for now.


Awaiting your approval (or commit).


Best regards

Raphael

On 10/12/2010 02:32 PM, Raphael Neider wrote:
> Dear sdcc developers,
>
>> please consider the svn main branch as frozen, which means that only 
>> fixes for high severity bugs (after an agreement on this mailing 
>> list) and changes in the documentation can be committed.
>
> The include paths to the pic14 headers is wrong: pic14 uses just "pic" 
> is its include path suffix, but port->target (which is used in the 
> current implementation) is "pic14". As a consequence, even using 
> --use-non-free does not help SDCC to find the PIC headers.

Thanks to finding it out.

>
> I attached a patch that specifically handles this case for the pic14 
> target -- which is not too beautiful, but introducing another helper 
> like PORT.general.get_model seems to be too much of a change for now. 
> A more pleasant side-effect of the special treatment in SDCCmain.c is 
> that the additional include path generation in pic/main.c is 
> superfluous once the correct path is setup in SDCCmain.c -- a true 
> improvement maintainability-wise.
>

I agree. I added a TODO comment.

> Alternatively, one could rename the pic directories (src/pic, 
> device/include/pic, device/lib/pic) to pic14 -- which also seems to be 
> too much for now.
>

This is what I intent to do after the release. It is not a low risk 
task, since it also affects the build & packaging process.

>
> Awaiting your approval (or commit).
>

Approved and committed.

Borut

Hi Borut,

Since the original release schedule has not been met, do 
you have an updated schedule?

I also have updated the manual a bit. Can I still commit 
that?

Greetings,
Maarten

> Dear sdcc developers,
> 
> please consider the svn main branch as frozen, which means that only 
> fixes for high severity bugs (after an agreement on this mailing list) 
> and changes in the documentation can be committed.
> 
> The SDCC 3.0.0 release schedule is published at 
> http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.0.0%20Release
> 
> 
> Borut

On 10/18/2010 09:42 PM, Maarten Brock wrote:
> Hi Borut,
>
> Since the original release schedule has not been met, do
> you have an updated schedule?
>    

I plan to release the RC2 latest during the next weekend. It seems that 
the current version is stable and we don't have show-stoppers, so I can 
make the RC2 from the tomorrow snapshot build, which will include your 
documentation changes.

> I also have updated the manual a bit. Can I still commit
> that?
>
>    

Yes, please! Documentation updates are always welcome and since they 
involve lo (no) risk we can include them in the late stages before the 
release.

> Greetings,
> Maarten
>
>    
>> Dear sdcc developers,
>>
>> please consider the svn main branch as frozen, which means that only
>> fixes for high severity bugs (after an agreement on this mailing list)
>> and changes in the documentation can be committed.
>>
>> The SDCC 3.0.0 release schedule is published at
>> http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.0.0%20Release
>>
>>
>> Borut
>>

It's in.

> On 10/18/2010 09:42 PM, Maarten Brock wrote:
> > Hi Borut,
> >
> > Since the original release schedule has not been met, do
> > you have an updated schedule?
> >    
> 
> I plan to release the RC2 latest during the next weekend. It seems that 
> the current version is stable and we don't have show-stoppers, so I can 
> make the RC2 from the tomorrow snapshot build, which will include your 
> documentation changes.
> 
> > I also have updated the manual a bit. Can I still commit
> > that?
> >
> >    
> 
> Yes, please! Documentation updates are always welcome and since they 
> involve lo (no) risk we can include them in the late stages before the 
> release.
> 
> > Greetings,
> > Maarten
> >
> >    
> >> Dear sdcc developers,
> >>
> >> please consider the svn main branch as frozen, which means that only
> >> fixes for high severity bugs (after an agreement on this mailing list)
> >> and changes in the documentation can be committed.
> >>
> >> The SDCC 3.0.0 release schedule is published at
> >> http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.0.0%20Release
> >>
> >>
> >> Borut
> >>      
> 
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

SDCC 3.0.0 Release Candidate 2 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available at:
http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.0.0-rc2

If you find a mistake, please send a mail to sdcc-devel mailing list 
sdcc-devel@....

I would appreciate any reports about a success or failure of running 
pre-compiled binary packages.

Borut

Borut,

I've installed RC2 on both WinXP and Win98 and it just 
works.

Maarten

> SDCC 3.0.0 Release Candidate 2 source, doc and binary packages for x86 
> Linux, 32 bit Windows and universal Mac OS X are available at:
> http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.0.0-rc2
> 
> If you find a mistake, please send a mail to sdcc-devel mailing list 
> sdcc-devel@....
> 
> I would appreciate any reports about a success or failure of running 
> pre-compiled binary packages.
> 
> Borut
> 
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Maarten, thanks for the report.

Has anybody tried it on i386 and ppc Mac OS X?

I'll be absent from tomorrow, 2010-10-26 until 2010-10-31. I won't be 
able to react if something urgent pops out, so please don't wait for me.

If everything goes well, I'll prepare the sdcc 3.0.0 final release on 
2010-11-01.

P.S.: Maarten, thanks to discover and correct all the typos I produced :-[


Borut



On 10/25/2010 08:32 PM, Maarten Brock wrote:
> Borut,
>
> I've installed RC2 on both WinXP and Win98 and it just
> works.
>
> Maarten
>
>    
>> SDCC 3.0.0 Release Candidate 2 source, doc and binary packages for x86
>> Linux, 32 bit Windows and universal Mac OS X are available at:
>> http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.0.0-rc2
>>
>> If you find a mistake, please send a mail to sdcc-devel mailing list
>> sdcc-devel@....
>>
>> I would appreciate any reports about a success or failure of running
>> pre-compiled binary packages.
>>
>> Borut
>>

Dear sdcc developers,

the sdcc RC1 is released. Thanks to anybody helped to bring it to the life.

Please consider the svn main branch as frozen, which means that only 
fixes for high severity bugs (after an agreement on this mailing list) 
and changes in the documentation can be committed.

The SDCC 3.1.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release.


Borut

SDCC 3.1.0 Release Candidate 2 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available at:
http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.1.0-rc2

If you find a mistake, please send a mail to sdcc-devel mailing list 
sdcc-devel@....

I would appreciate any reports about a success or failure of running 
pre-compiled binary packages.

Borut

Dear sdcc developers,

the sdcc RC2 is released. Thanks to anybody helped to bring it to the life.

Please consider the svn main branch as DEEPLY FROZEN, which means 
NOTHING can be committed without the agreement between sdcc developers 
and release manager.

The SDCC 3.1.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release 
<https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release>.


Borut

SDCC 3.1.0 Release Candidate 3 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available at:
http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.1.0-rc3

If you find a mistake, please send a mail to sdcc-devel mailing list 
sdcc-devel@....

I would appreciate any reports about a success or failure of running 
pre-compiled binary packages.

Borut

Dear sdcc developers,

the sdcc RC3 is released. This release candidate 3 was not originally 
planned, but we (Maarten, Philipp and me) decided to make it due to the 
fix of bug #3440327: wrong code for pointer to functions in a loop, z80 
port. The final sdcc 3.1.0 release is still planned for the next week end.

Please consider the svn main branch as DEEPLY FROZEN, which means 
NOTHING can be committed without the agreement between sdcc developers 
and release manager.

The SDCC 3.1.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release 
<https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release>.


Borut

SDCC 3.2.0 Release Candidate 1 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available at:
http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.2.0-rc1

If you find a mistake, please send a mail to sdcc-devel mailing list 
sdcc-devel@....

I would appreciate any reports about a success or failure of running 
pre-compiled binary packages.

Borut

Dear sdcc developers,

the sdcc 3.2.0 RC1 is released. Thanks to anybody helped to bring it to 
the life.

Please consider the svn main branch as frozen, which means that only 
fixes for high severity bugs (after an agreement on this mailing list) 
and changes in the documentation can be committed.

The SDCC 3.2.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.2.0%20Release.

Borut

I'm unable to download it from SF - there are 6 files in summary, but page 
seems to be empty (no links to files). Checked on 2 machines (XP and 7) with 
IE8.

Home / snapshot_builds / sdcc-3.2.0-rc1 Name Modified Size Status
      Parent folder
      Totals: 6 Items   31.3 MB


----- Original Message ----- 
From: "Borut Razem" <borut.razem@...>
To: "Sdcc-User" <sdcc-user@...>; "Sdcc-Devel" 
<sdcc-devel@...>
Sent: Sunday, June 17, 2012 5:07 PM
Subject: [sdcc-devel] SDCC 3.2.0 Release Candidate 1


> SDCC 3.2.0 Release Candidate 1 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available at:
> http://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.2.0-rc1
>
> If you find a mistake, please send a mail to sdcc-devel mailing list
> sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running
> pre-compiled binary packages.
>
> Borut
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

On 17. 06. 2012 22:59, Patryk wrote:
> I'm unable to download it from SF - there are 6 files in summary, but page
> seems to be empty (no links to files). Checked on 2 machines (XP and 7) with
> IE8.
>
> Home / snapshot_builds / sdcc-3.2.0-rc1 Name Modified Size Status
>        Parent folder
>        Totals: 6 Items   31.3 MB
>
The files are still in "This file will be ready for download shortly." 
state!??

I'll try to upload them again.

Borut

I uploaded the files again, but the problem is still the same. It seems to
be a general problem as there are quite some such reports in SourceForge
support tracker at https://sourceforge.net/apps/trac/sourceforge/report/12.
Let hope the the problem will be fixed soon. In the mean time you can
download the files using sftp (this works for me, hopefully for you too):

$ sftp <user_name>:@frs.sourceforge.net
cd /home/pfs/project/sdcc/snapshot_builds/sdcc-3.2.0-rc1
ls
get <file_name>

Borut

On Mon, Jun 18, 2012 at 10:07 AM, Borut Razem <borut.razem@...> wrote:

>  On 17. 06. 2012 22:59, Patryk wrote:
>
> I'm unable to download it from SF - there are 6 files in summary, but page
> seems to be empty (no links to files). Checked on 2 machines (XP and 7) with
> IE8.
>
> Home / snapshot_builds / sdcc-3.2.0-rc1 Name Modified Size Status
>       Parent folder
>       Totals: 6 Items   31.3 MB
>
>
>  The files are still in "This file will be ready for download shortly."
> state!??
>
> I'll try to upload them again.
>
> Borut
>

sdcc 3.2.0 RC1 files are now accessible from browser at
https://sourceforge.net/projects/sdcc/files/snapshot_builds/sdcc-3.2.0-rc1/

Borut

On Mon, Jun 18, 2012 at 11:47 AM, Borut Ražem <borut.razem@...> wrote:

> I uploaded the files again, but the problem is still the same. It seems to
> be a general problem as there are quite some such reports in SourceForge
> support tracker at https://sourceforge.net/apps/trac/sourceforge/report/12.
> Let hope the the problem will be fixed soon. In the mean time you can
> download the files using sftp (this works for me, hopefully for you too):
>
> $ sftp <user_name>:@frs.sourceforge.net
> cd /home/pfs/project/sdcc/snapshot_builds/sdcc-3.2.0-rc1
> ls
> get <file_name>
>
> Borut
>
> On Mon, Jun 18, 2012 at 10:07 AM, Borut Razem <borut.razem@...:
>
>>  On 17. 06. 2012 22:59, Patryk wrote:
>>
>> I'm unable to download it from SF - there are 6 files in summary, but page
>> seems to be empty (no links to files). Checked on 2 machines (XP and 7) with
>> IE8.
>>
>> Home / snapshot_builds / sdcc-3.2.0-rc1 Name Modified Size Status
>>       Parent folder
>>       Totals: 6 Items   31.3 MB
>>
>>
>>  The files are still in "This file will be ready for download shortly."
>> state!??
>>
>> I'll try to upload them again.
>>
>> Borut
>>
>
>

SDCC 3.2.0 Release Candidate 2 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available  in 
corresponding folders at:
http://sourceforge.net/projects/sdcc/files

If you find a mistake, please send a mail to sdcc-devel mailing list 
sdcc-devel@....

I would appreciate any reports about a success or failure of running 
pre-compiled binary packages.

Borut

Dear sdcc developers,

the sdcc 3.2.0 RC2 is released. Thanks to anybody helped to bring it to 
the life.

Please consider the svn main branch as frozen, which means that only 
fixes for high severity bugs (after an agreement on this mailing list) 
and changes in the documentation can be committed.

The SDCC 3.2.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.2.0%20Release.

Borut

I was able to successfully install and run RC1/RC2 on Win98. I have tested 
some previous 8051 project and after some tweeks it compiled and worked.

Here are 2 issues spotted, not present in SDCC 3.1.0:

1) this may be Win98 specific - slashes in paths have doubled:
SDCC 3.1.0
D:\MM\SiLabs_IDE\ADuC\main.c:116: warning 110: conditional flow changed by 
optimizer: so said EVELYN the modified DOG
SDCC 3.2.0
D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: warning 110: conditional flow changed 
by optimizer: so said EVELYN the modified DOG
SDCC 3.2.0 *.asm:
D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: ERROR: No such file or directory

2) extern __sfr16
sdcc -c test.c:
extern __sfr16 __at(0xCDCC) TMR2;
void f(void)
{
TMR2 = 0;
}
test.asm:108: Error: <r> relocation error

No such problem with 8bit __sfr, removing "extern" also helps.

Regards,
Patryk

----- Original Message ----- 
From: "Borut Razem" <borut.razem@...>
To: "Sdcc-User" <sdcc-user@...>; "Sdcc-Devel" 
<sdcc-devel@...>
Sent: Sunday, June 24, 2012 8:54 PM
Subject: [sdcc-devel] SDCC 3.2.0 Release Candidate 2


> SDCC 3.2.0 Release Candidate 2 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available  in
> corresponding folders at:
> http://sourceforge.net/projects/sdcc/files
>
> If you find a mistake, please send a mail to sdcc-devel mailing list
> sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running
> pre-compiled binary packages.
>
> Borut
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

On 25. 06. 2012 02:26, Patryk wrote:
> I was able to successfully install and run RC1/RC2 on Win98. I have tested
> some previous 8051 project and after some tweeks it compiled and worked.
>
> Here are 2 issues spotted, not present in SDCC 3.1.0:
>
> 1) this may be Win98 specific - slashes in paths have doubled:
> SDCC 3.1.0
> D:\MM\SiLabs_IDE\ADuC\main.c:116: warning 110: conditional flow changed by
> optimizer: so said EVELYN the modified DOG
> SDCC 3.2.0
> D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: warning 110: conditional flow changed
> by optimizer: so said EVELYN the modified DOG
> SDCC 3.2.0 *.asm:
> D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: ERROR: No such file or directory

Patryc, can you please provide a short c source file which reproduce the 
problem? Can you please add the -V sdcc command line option, run 
compilation and send the result? Specially the "No such file or 
directory" error makes me nervous: it seems that it didn't happen in 3.1.0.

I propose to open a bug report and supply / attach all the needed info 
there.

> 2) extern __sfr16
> sdcc -c test.c:
> extern __sfr16 __at(0xCDCC) TMR2;
> void f(void)
> {
> TMR2 = 0;
> }
> test.asm:108: Error: <r> relocation error
>
> No such problem with 8bit __sfr, removing "extern" also helps.

Maarten, will you take a look?

> Regards,
> Patryk

Thanks for the precious report,
Borut

Hi,

> On 25. 06. 2012 02:26, Patryk wrote:
> > I was able to successfully install and run RC1/RC2 on Win98. I have tested
> > some previous 8051 project and after some tweeks it compiled and worked.
> >
> > Here are 2 issues spotted, not present in SDCC 3.1.0:
> >
> > 1) this may be Win98 specific - slashes in paths have doubled:
> > SDCC 3.1.0
> > D:\MM\SiLabs_IDE\ADuC\main.c:116: warning 110: conditional flow changed by
> > optimizer: so said EVELYN the modified DOG
> > SDCC 3.2.0
> > D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: warning 110: conditional flow changed
> > by optimizer: so said EVELYN the modified DOG
> > SDCC 3.2.0 *.asm:
> > D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: ERROR: No such file or directory
> 
> Patryc, can you please provide a short c source file which reproduce the 
> problem? Can you please add the -V sdcc command line option, run 
> compilation and send the result? Specially the "No such file or 
> directory" error makes me nervous: it seems that it didn't happen in 3.1.0.
> 
> I propose to open a bug report and supply / attach all the needed info 
> there.

I also noticed the double backslashes when SDCC 
generates an error:
Source\\cmdintf.c:38: syntax error: token -> ';' ; 
column 20

But I don't know where the "No such file ..." comes 
from. I don't get that.

> > 2) extern __sfr16
> > sdcc -c test.c:
> > extern __sfr16 __at(0xCDCC) TMR2;
> > void f(void)
> > {
> > TMR2 = 0;
> > }
> > test.asm:108: Error: <r> relocation error
> >
> > No such problem with 8bit __sfr, removing "extern" also helps.
> 
> Maarten, will you take a look?

I'll take a look into this.

> > Regards,
> > Patryk
> 
> Thanks for the precious report,
> Borut

My projects compile clean now with RC2. Size is slightly 
different (some larger, some smaller). But BSEG symbols 
are missing from the .map file.

Maarten

On Mon, Jun 25, 2012 at 11:16 AM, Maarten Brock <sourceforge.brock@...:

> Hi,
>
> > On 25. 06. 2012 02:26, Patryk wrote:
> > > I was able to successfully install and run RC1/RC2 on Win98. I have
> tested
> > > some previous 8051 project and after some tweeks it compiled and
> worked.
> > >
> > > Here are 2 issues spotted, not present in SDCC 3.1.0:
> > >
> > > 1) this may be Win98 specific - slashes in paths have doubled:
> > > SDCC 3.1.0
> > > D:\MM\SiLabs_IDE\ADuC\main.c:116: warning 110: conditional flow
> changed by
> > > optimizer: so said EVELYN the modified DOG
> > > SDCC 3.2.0
> > > D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: warning 110: conditional flow
> changed
> > > by optimizer: so said EVELYN the modified DOG
> > > SDCC 3.2.0 *.asm:
> > > D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: ERROR: No such file or directory
> >
> > Patryc, can you please provide a short c source file which reproduce the
> > problem? Can you please add the -V sdcc command line option, run
> > compilation and send the result? Specially the "No such file or
> > directory" error makes me nervous: it seems that it didn't happen in
> 3.1.0.
> >
> > I propose to open a bug report and supply / attach all the needed info
> > there.
>
> I also noticed the double backslashes when SDCC
> generates an error:
> Source\\cmdintf.c:38: syntax error: token -> ';' ;
> column 20
>

I never noticed it:  usually I'm using the forward slashes. I'll take a
look where it is comming from.

But I don't know where the "No such file ..." comes
> from. I don't get that.


Hopefully Patryk will explain it.

> > 2) extern __sfr16
> > > sdcc -c test.c:
> > > extern __sfr16 __at(0xCDCC) TMR2;
> > > void f(void)
> > > {
> > > TMR2 = 0;
> > > }
> > > test.asm:108: Error: <r> relocation error
> > >
> > > No such problem with 8bit __sfr, removing "extern" also helps.
> >
> > Maarten, will you take a look?
>
> I'll take a look into this.


Thanks.


> > > Regards,
> > > Patryk
> >
> > Thanks for the precious report,
> > Borut
>
> My projects compile clean now with RC2. Size is slightly
> different (some larger, some smaller). But BSEG symbols
> are missing from the .map file.
>

What the hack?????

 Borut

On Mon, Jun 25, 2012 at 11:47 AM, Borut Ražem <borut.razem@...> wrote:

> I also noticed the double backslashes when SDCC
>> generates an error:
>> Source\\cmdintf.c:38: syntax error: token -> ';' ;
>> column 20
>>
>
> I never noticed it:  usually I'm using the forward slashes. I'll take a
> look where it is comming from.
>

They are comming from the preprocessor: sdcc -E  Source\cmdintf.c

It seems that multiple backslashes in path are treated as one on WinNT
derivates and probably treated as an error on Win95 derivates, for example:

dir .\\t.c

is OK and treated as dir .\t.c on WinXP (verified); is treated as an error
on Win98 (speculation).

Can enybody confirm my speculation about Win98 behaviour?

In the mean time I'll try to fix the problem by "unescaping" the file names
coming from the preprocessor.

Borut

Dnia 25-06-2012 o godz. 11:47 Borut RaĹžem napisał(a):
> On Mon, Jun 25, 2012 at 11:16 AM, Maarten Brock <sourceforge.brock@...> wrote:
> 
> > Hi,
> > 
> > > On 25. 06. 2012 02:26, Patryk wrote:
> > > > I was able to successfully install and run RC1/RC2 on Win98. I have tested
> > > > some previous 8051 project and after some tweeks it compiled and worked.
> > > >
> > > > Here are 2 issues spotted, not present in SDCC 3.1.0:
> > > >
> > > > 1) this may be Win98 specific - slashes in paths have doubled:
> > > > SDCC 3.1.0
> > > > D:\MM\SiLabs_IDE\ADuC\main.c:116: warning 110: conditional flow changed by
> > > > optimizer: so said EVELYN the modified DOG
> > > > SDCC 3.2.0
> > > > D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: warning 110: conditional flow changed
> > > > by optimizer: so said EVELYN the modified DOG
> > > > SDCC 3.2.0 *.asm:
> > > > D:\\MM\\SiLabs_IDE\\ADuC\\main.c:109: ERROR: No such file or directory
> > >
> > > Patryc, can you please provide a short c source file which reproduce the
> > > problem? Can you please add the -V sdcc command line option, run
> > > compilation and send the result? Specially the "No such file or
> > > directory" error makes me nervous: it seems that it didn't happen in 3.1.0.
> > >
> > > I propose to open a bug report and supply / attach all the needed info
> > > there.

I mean any SDCC warning/error during compilation, as Maarten confirmed below. It causes some confusion to SiLabs IDE.
As of "No such file or directory" - it's just a line from *.asm file generated by SDCC. There should be source code cited, but double slashes seems to prevent SDCC access to the source file under Win98 during *.asm generating phase. Borut - I'm sorry to make you nervous, please rest assured that it's nothing serious :-)

> > I also noticed the double backslashes when SDCC
> > generates an error:
> > Source\\cmdintf.c:38: syntax error: token -> ';' ;
> > column 20
> I never noticed it:  usually I'm using the forward slashes. I'll take a look where it is comming from.
> > But I don't know where the "No such file ..." comes
> > from. I don't get that.
> Hopefully Patryk will explain it.
> > > > 2) extern __sfr16
> > > > sdcc -c test.c:
> > > > extern __sfr16 __at(0xCDCC) TMR2;
> > > > void f(void)
> > > > {
> > > > TMR2 = 0;
> > > > }
> > > > test.asm:108: Error: <r> relocation error
> > > >
> > > > No such problem with 8bit __sfr, removing "extern" also helps.
> > >
> > > Maarten, will you take a look?
> > 
> > I'll take a look into this.
> Thanks.
>  
> > > > Regards,
> > > > Patryk
> > >
> > > Thanks for the precious report,
> > > Borut
> > 
> > My projects compile clean now with RC2. Size is slightly
> > different (some larger, some smaller). But BSEG symbols
> > are missing from the .map file.
> What the hack?????
>  Borut

> > > 2) extern __sfr16
> > > > sdcc -c test.c:
> > > > extern __sfr16 __at(0xCDCC) TMR2;
> > > > void f(void)
> > > > {
> > > > TMR2 = 0;
> > > > }
> > > > test.asm:108: Error: <r> relocation error
> > > >
> > > > No such problem with 8bit __sfr, removing "extern" also helps.
> > >
> > > Maarten, will you take a look?
> >
> > I'll take a look into this.
> 
> 
> Thanks.

extern __sfr   __at(0x80)   P0;
extern __sfr16 __at(0xCDCC) TMR2;

Both these lines are treated as extern declarations, not 
definitions. As such they do not create the symbols under .globl but 
should be assumed externally defined symbols (sdas -g flag).

Now SDCC 3.1.0 generates
;	genAssign
	mov	_TMR2,#0x00
	mov	(_TMR2 >> 8),#0x00
and recognizes _TMR2 as an undefined global.

But SDCC 3.2.0 generates
;	genAssign
	mov	((_TMR2 >> 0) & 0xFF),#0x00
	mov	((_TMR2 >> 8) & 0xFF),#0x00
and this time the assembler no longer recognizes _TMR2 as an 
undefined global.

For 8 bit __sfr both generate
;	genAssign
	mov	_P0,#0x01
and it is easy for the assembler to recognize the undefined global.

I find it awkward to make an extern declaration but to include the 
full address. But leaving out the __at() part doesn't change 
anything. I suggest not to use extern with __sfrxx definitions for 
now and file a bug report about it to be fixed later.

Maarten

> > I also noticed the double backslashes when SDCC
> >> generates an error:
> >> Source\\cmdintf.c:38: syntax error: token -> ';' ;
> >> column 20
> >
> They are comming from the preprocessor: sdcc -E  Source\cmdintf.c
> 
> It seems that multiple backslashes in path are treated as one on WinNT
> derivates and probably treated as an error on Win95 derivates, for example:
> 
> dir .\\t.c
> 
> is OK and treated as dir .\t.c on WinXP (verified); is treated as an error
> on Win98 (speculation).
> 
> Can enybody confirm my speculation about Win98 behaviour?

Yes, dir .\\t.c generates an error on Win98 and not on 
WinXP.

Maarten

On Mon, Jun 25, 2012 at 2:10 PM, <patjank@...> wrote:

> Dnia 25-06-2012 o godz. 11:47 Borut RaĹžem napisał(a):
> > > > Patryc, can you please provide a short c source file which reproduce
> the
> > > > problem? Can you please add the -V sdcc command line option, run
> > > > compilation and send the result? Specially the "No such file or
> > > > directory" error makes me nervous: it seems that it didn't happen in
> 3.1.0.
> > > >
> > > > I propose to open a bug report and supply / attach all the needed
> info
> > > > there.
>
> I mean any SDCC warning/error during compilation, as Maarten confirmed
> below. It causes some confusion to SiLabs IDE.
> As of "No such file or directory" - it's just a line from *.asm file
> generated by SDCC. There should be source code cited, but double slashes
> seems to prevent SDCC access to the source file under Win98 during *.asm
> generating phase. Borut - I'm sorry to make you nervous, please rest
> assured that it's nothing serious :-)


It is not you making me nervous, it is the fact that we have a regression
an that I'm probably guilty for it. :-(

I would still appreciate if you can send me the output with -V option.

Borut

On Mon, Jun 25, 2012 at 3:59 PM, Borut Ražem <borut.razem@...> wrote:

> On Mon, Jun 25, 2012 at 2:10 PM, <patjank@...> wrote:
>
>> Dnia 25-06-2012 o godz. 11:47 Borut RaĹžem napisał(a):
>> > > > Patryc, can you please provide a short c source file which
>> reproduce the
>> > > > problem? Can you please add the -V sdcc command line option, run
>> > > > compilation and send the result? Specially the "No such file or
>> > > > directory" error makes me nervous: it seems that it didn't happen
>> in 3.1.0.
>> > > >
>> > > > I propose to open a bug report and supply / attach all the needed
>> info
>> > > > there.
>>
>> I mean any SDCC warning/error during compilation, as Maarten confirmed
>> below. It causes some confusion to SiLabs IDE.
>> As of "No such file or directory" - it's just a line from *.asm file
>> generated by SDCC. There should be source code cited, but double slashes
>> seems to prevent SDCC access to the source file under Win98 during *.asm
>> generating phase. Borut - I'm sorry to make you nervous, please rest
>> assured that it's nothing serious :-)
>>
>
> It is not you making me nervous, it is the fact that we have a regression
> an that I'm probably guilty for it. :-(
>
> I would still appreciate if you can send me the output with -V option.
>

I have the solution. I'll run regression tests locally and if everything
goes well I'll commit the change. If anybody has concerns, please let me
know ASAP.

P.S.: I confirm that I'm gulty: I removed the call to "unescape" function
copyStr() since it seemed wrong to me. Now I added a comment so it won't
happen again :-(

Borut

----- Original Message ----- 
From: "Maarten Brock" <sourceforge.brock@...>
To: "Development chatter about sdcc" <sdcc-devel@...>
Sent: Monday, June 25, 2012 2:53 PM
Subject: Re: [sdcc-devel] SDCC 3.2.0 Release Candidate 2


>> > I also noticed the double backslashes when SDCC
>> >> generates an error:
>> >> Source\\cmdintf.c:38: syntax error: token -> ';' ;
>> >> column 20
>> >
>> They are comming from the preprocessor: sdcc -E  Source\cmdintf.c
>>
>> It seems that multiple backslashes in path are treated as one on WinNT
>> derivates and probably treated as an error on Win95 derivates, for 
>> example:
>>
>> dir .\\t.c
>>
>> is OK and treated as dir .\t.c on WinXP (verified); is treated as an 
>> error
>> on Win98 (speculation).
>>
>> Can enybody confirm my speculation about Win98 behaviour?
>
> Yes, dir .\\t.c generates an error on Win98 and not on
> WinXP.
>
> Maarten

I got no error with cd c:\\Windows on my Win98, but it may be due to 
unofficial SP 2.1b installed.

>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

----- Original Message ----- 
From: "Borut Ražem" <borut.razem@...>
To: "Development chatter about sdcc" <sdcc-devel@...>
Sent: Monday, June 25, 2012 3:59 PM
Subject: Re: [sdcc-devel] SDCC 3.2.0 Release Candidate 2


On Mon, Jun 25, 2012 at 2:10 PM, <patjank@...> wrote:

> Dnia 25-06-2012 o godz. 11:47 Borut RaĹžem napisał(a):
> > > > Patryc, can you please provide a short c source file which reproduce
> the
> > > > problem? Can you please add the -V sdcc command line option, run
> > > > compilation and send the result? Specially the "No such file or
> > > > directory" error makes me nervous: it seems that it didn't happen in
> 3.1.0.
> > > >
> > > > I propose to open a bug report and supply / attach all the needed
> info
> > > > there.
>
> I mean any SDCC warning/error during compilation, as Maarten confirmed
> below. It causes some confusion to SiLabs IDE.
> As of "No such file or directory" - it's just a line from *.asm file
> generated by SDCC. There should be source code cited, but double slashes
> seems to prevent SDCC access to the source file under Win98 during *.asm
> generating phase. Borut - I'm sorry to make you nervous, please rest
> assured that it's nothing serious :-)


It is not you making me nervous, it is the fact that we have a regression
an that I'm probably guilty for it. :-(

I would still appreciate if you can send me the output with -V option.

[Patryk] Here it is (RC2):
SDCC : 
mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 
3.2.0 #7964 (Jun 24 2012) (MINGW32)

Borut

Patryk,

I meant uppercase "-V", not lowercase "-v".

Borut

On Mon, Jun 25, 2012 at 9:33 PM, Patryk <patjank@...> wrote:

>
> ----- Original Message -----
> From: "Borut Ražem" <borut.razem@...>
> To: "Development chatter about sdcc" <sdcc-devel@...>
> Sent: Monday, June 25, 2012 3:59 PM
> Subject: Re: [sdcc-devel] SDCC 3.2.0 Release Candidate 2
>
>
> On Mon, Jun 25, 2012 at 2:10 PM, <patjank@...> wrote:
>
> > Dnia 25-06-2012 o godz. 11:47 Borut RaĹžem napisał(a):
> > > > > Patryc, can you please provide a short c source file which
> reproduce
> > the
> > > > > problem? Can you please add the -V sdcc command line option, run
> > > > > compilation and send the result? Specially the "No such file or
> > > > > directory" error makes me nervous: it seems that it didn't happen
> in
> > 3.1.0.
> > > > >
> > > > > I propose to open a bug report and supply / attach all the needed
> > info
> > > > > there.
> >
> > I mean any SDCC warning/error during compilation, as Maarten confirmed
> > below. It causes some confusion to SiLabs IDE.
> > As of "No such file or directory" - it's just a line from *.asm file
> > generated by SDCC. There should be source code cited, but double slashes
> > seems to prevent SDCC access to the source file under Win98 during *.asm
> > generating phase. Borut - I'm sorry to make you nervous, please rest
> > assured that it's nothing serious :-)
>
>
> It is not you making me nervous, it is the fact that we have a regression
> an that I'm probably guilty for it. :-(
>
> I would still appreciate if you can send me the output with -V option.
>
> [Patryk] Here it is (RC2):
> SDCC :
> mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08
> 3.2.0 #7964 (Jun 24 2012) (MINGW32)
>
> Borut
>

On Mon, Jun 25, 2012 at 5:05 PM, Borut Ražem <borut.razem@...> wrote:

> On Mon, Jun 25, 2012 at 3:59 PM, Borut Ražem <borut.razem@...:
>
>> On Mon, Jun 25, 2012 at 2:10 PM, <patjank@...> wrote:
>>
>>>  Dnia 25-06-2012 o godz. 11:47 Borut RaĹžem napisał(a):
>>> > > > Patryc, can you please provide a short c source file which
>>> reproduce the
>>> > > > problem? Can you please add the -V sdcc command line option, run
>>> > > > compilation and send the result? Specially the "No such file or
>>> > > > directory" error makes me nervous: it seems that it didn't happen
>>> in 3.1.0.
>>> > > >
>>> > > > I propose to open a bug report and supply / attach all the needed
>>> info
>>> > > > there.
>>>
>>> I mean any SDCC warning/error during compilation, as Maarten confirmed
>>> below. It causes some confusion to SiLabs IDE.
>>> As of "No such file or directory" - it's just a line from *.asm file
>>> generated by SDCC. There should be source code cited, but double slashes
>>> seems to prevent SDCC access to the source file under Win98 during *.asm
>>> generating phase. Borut - I'm sorry to make you nervous, please rest
>>> assured that it's nothing serious :-)
>>>
>>
>> It is not you making me nervous, it is the fact that we have a regression
>> an that I'm probably guilty for it. :-(
>>
>> I would still appreciate if you can send me the output with -V option.
>>
>
> I have the solution. I'll run regression tests locally and if everything
> goes well I'll commit the change. If anybody has concerns, please let me
> know ASAP.
>
> P.S.: I confirm that I'm gulty: I removed the call to "unescape" function
> copyStr() since it seemed wrong to me. Now I added a comment so it won't
> happen again :-(
>

The problem is hopefully fixed in svn revision #7984.

Patryk, can you please verify it?

Borut

On 26.06.2012 22:49, Borut Ražem wrote:

> 
> The problem is hopefully fixed in svn revision #7984.
> 
> Patryk, can you please verify it?

This is a rather big change, which looks like it affects all ports.

svn diff -r 7983:7984 | wc -l

gives 343 for me.

I suggest a RC3 as soon as Patryk confirms the issue as fixed.

Philipp

Hi,

> > The problem is hopefully fixed in svn revision #7984.
> > 
> > Patryk, can you please verify it?
> 
> This is a rather big change, which looks like it affects all ports.
> 
> svn diff -r 7983:7984 | wc -l
> 
> gives 343 for me.
> 
> I suggest a RC3 as soon as Patryk confirms the issue as fixed.
> 
> Philipp

I have done a small test and found that instead of 
double backslashes I now get single forward slashes. I'm 
not sure if a regular windows editor or IDE can pick up 
on those to open the right file with the error when SDCC 
is called from within.

Maarten

On Wed, Jun 27, 2012 at 9:59 AM, Maarten Brock <sourceforge.brock@...:

> Hi,
>
> > > The problem is hopefully fixed in svn revision #7984.
> > >
> > > Patryk, can you please verify it?
> >
> > This is a rather big change, which looks like it affects all ports.
> >
> > svn diff -r 7983:7984 | wc -l
> >
> > gives 343 for me.
> >
> > I suggest a RC3 as soon as Patryk confirms the issue as fixed.
> >
> > Philipp
>
> I have done a small test and found that instead of
> double backslashes I now get single forward slashes. I'm
> not sure if a regular windows editor or IDE can pick up
> on those to open the right file with the error when SDCC
> is called from within.


Maarten, I found a bug in my "fix" :-(.  I already commited the 2nd fix and
restarted x86 build on derna.

Unfortunately it seems that this fix has nothing to do with the backslash
to slash conversion you reported.

I couldn't reproduce the behaviour you reported. Can you please  give me
more info about the plaform (probably Win98?), the shell (cygwin bash or
cmd.exe), command line and program you are compiling?

Borut

> On Wed, Jun 27, 2012 at 9:59 AM, Maarten Brock <sourceforge.brock@...:
> 
> > Hi,
> >
> > > > The problem is hopefully fixed in svn revision #7984.
> > > >
> > > > Patryk, can you please verify it?
> > >
> > > This is a rather big change, which looks like it affects all ports.
> > >
> > > svn diff -r 7983:7984 | wc -l
> > >
> > > gives 343 for me.
> > >
> > > I suggest a RC3 as soon as Patryk confirms the issue as fixed.
> > >
> > > Philipp
> >
> > I have done a small test and found that instead of
> > double backslashes I now get single forward slashes. I'm
> > not sure if a regular windows editor or IDE can pick up
> > on those to open the right file with the error when SDCC
> > is called from within.
> 
> 
> Maarten, I found a bug in my "fix" :-(.  I already commited the 2nd fix and
> restarted x86 build on derna.
> 
> Unfortunately it seems that this fix has nothing to do with the backslash
> to slash conversion you reported.
> 
> I couldn't reproduce the behaviour you reported. Can you please  give me
> more info about the plaform (probably Win98?), the shell (cygwin bash or
> cmd.exe), command line and program you are compiling?
> 
> Borut

Hi,

I used todays SDCC #7984 and just did sdcc -c Source\file.c which includes 
defines.h from the same Source directory. There is a warning from defines.h 
reported with Source/defines.h.

I guess the ''bug' was that there was no slash at all anymore when the error 
is in the source itself as I just found out.

Maarten

On Wed, Jun 27, 2012 at 12:07 PM, Maarten Brock <sourceforge.brock@...:

> > On Wed, Jun 27, 2012 at 9:59 AM, Maarten Brock <sourceforge.brock@...
> >wrote:
> >
> > > Hi,
> > >
> > > > > The problem is hopefully fixed in svn revision #7984.
> > > > >
> > > > > Patryk, can you please verify it?
> > > >
> > > > This is a rather big change, which looks like it affects all ports.
> > > >
> > > > svn diff -r 7983:7984 | wc -l
> > > >
> > > > gives 343 for me.
> > > >
> > > > I suggest a RC3 as soon as Patryk confirms the issue as fixed.
> > > >
> > > > Philipp
> > >
> > > I have done a small test and found that instead of
> > > double backslashes I now get single forward slashes. I'm
> > > not sure if a regular windows editor or IDE can pick up
> > > on those to open the right file with the error when SDCC
> > > is called from within.
> >
> >
> > Maarten, I found a bug in my "fix" :-(.  I already commited the 2nd fix
> and
> > restarted x86 build on derna.
> >
> > Unfortunately it seems that this fix has nothing to do with the backslash
> > to slash conversion you reported.
> >
> > I couldn't reproduce the behaviour you reported. Can you please  give me
> > more info about the plaform (probably Win98?), the shell (cygwin bash or
> > cmd.exe), command line and program you are compiling?
> >
> > Borut
>
> Hi,
>
> I used todays SDCC #7984 and just did sdcc -c Source\file.c which includes
> defines.h from the same Source directory. There is a warning from defines.h
> reported with Source/defines.h.
>

I tried it on WinXP with the following file.c content:

----8<----
#include "Source/defines.h"

void
main (void)
{
  c
}
---->8----

the result with revision #7984:

C:\>sdcc -c Source\file.c
Source\file.c:1:28: error: Source/defines.h: No such file or directory
      # reported by sdcpp, OK
Sourcefile.c:6: syntax error: token -> 'char' ; column 6
                 # reported bs sdcc, missing '/' between Source and file.c

the result with revision #7986:

C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -c Source\file.c
Source\file.c:1:28: error: Source/defines.h: No such file or directory
      # reported by sdcpp, OK
Source\file.c:7: syntax error: token -> '}' ; column 1
                     # reported bs sdcc, OK

Is this the same as what you get?

I guess the ''bug' was that there was no slash at all anymore when the error
> is in the source itself as I just found out.


Right, I skipped one char too much :-(.

Borut

> On Wed, Jun 27, 2012 at 12:07 PM, Maarten Brock <sourceforge.brock@...:
> 
> > > On Wed, Jun 27, 2012 at 9:59 AM, Maarten Brock <sourceforge.brock@...
> > >wrote:
> > >
> > > > Hi,
> > > >
> > > > > > The problem is hopefully fixed in svn revision #7984.
> > > > > >
> > > > > > Patryk, can you please verify it?
> > > > >
> > > > > This is a rather big change, which looks like it affects all ports.
> > > > >
> > > > > svn diff -r 7983:7984 | wc -l
> > > > >
> > > > > gives 343 for me.
> > > > >
> > > > > I suggest a RC3 as soon as Patryk confirms the issue as fixed.
> > > > >
> > > > > Philipp
> > > >
> > > > I have done a small test and found that instead of
> > > > double backslashes I now get single forward slashes. I'm
> > > > not sure if a regular windows editor or IDE can pick up
> > > > on those to open the right file with the error when SDCC
> > > > is called from within.
> > >
> > >
> > > Maarten, I found a bug in my "fix" :-(.  I already commited the 2nd fix
> > and
> > > restarted x86 build on derna.
> > >
> > > Unfortunately it seems that this fix has nothing to do with the backslash
> > > to slash conversion you reported.
> > >
> > > I couldn't reproduce the behaviour you reported. Can you please  give me
> > > more info about the plaform (probably Win98?), the shell (cygwin bash or
> > > cmd.exe), command line and program you are compiling?
> > >
> > > Borut
> >
> > Hi,
> >
> > I used todays SDCC #7984 and just did sdcc -c Source\file.c which includes
> > defines.h from the same Source directory. There is a warning from defines.h
> > reported with Source/defines.h.
> >
> 
> I tried it on WinXP with the following file.c content:
> 
> ----8<----
> #include "Source/defines.h"
> 
> void
> main (void)
> {
>   c
> }
> ---->8----
> 
> the result with revision #7984:
> 
> C:\>sdcc -c Source\file.c
> Source\file.c:1:28: error: Source/defines.h: No such file or directory
>       # reported by sdcpp, OK
> Sourcefile.c:6: syntax error: token -> 'char' ; column 6
>                  # reported bs sdcc, missing '/' between Source and file.c
> 
> the result with revision #7986:
> 
> C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -c Source\file.c
> Source\file.c:1:28: error: Source/defines.h: No such file or directory
>       # reported by sdcpp, OK
> Source\file.c:7: syntax error: token -> '}' ; column 1
>                      # reported bs sdcc, OK
> 
> Is this the same as what you get?
> 
> I guess the ''bug' was that there was no slash at all anymore when the error
> > is in the source itself as I just found out.
> 
> 
> Right, I skipped one char too much :-(.
> 
> Borut
> 

Sorry, I was not clear enough. The file is:

8<---- *file.c*
#include "defines.h"

void main (void)
{
}
8<---- *defines.h*
struct TChapter
{
  char  Name[14];
  char* Sets[];  //generates warning 187
};
8<----

And the output of sdcc -c Source\file.c on WinXP gives:

Source/defines.h:4: warning 187: ISO C90 does not 
support flexible array members

Maarten

On Wed, Jun 27, 2012 at 2:12 PM, Maarten Brock <sourceforge.brock@...:

> > On Wed, Jun 27, 2012 at 12:07 PM, Maarten Brock <
> sourceforge.brock@...:
> >
> > > > On Wed, Jun 27, 2012 at 9:59 AM, Maarten Brock <
> sourceforge.brock@...
> > > >wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > > > The problem is hopefully fixed in svn revision #7984.
> > > > > > >
> > > > > > > Patryk, can you please verify it?
> > > > > >
> > > > > > This is a rather big change, which looks like it affects all
> ports.
> > > > > >
> > > > > > svn diff -r 7983:7984 | wc -l
> > > > > >
> > > > > > gives 343 for me.
> > > > > >
> > > > > > I suggest a RC3 as soon as Patryk confirms the issue as fixed.
> > > > > >
> > > > > > Philipp
> > > > >
> > > > > I have done a small test and found that instead of
> > > > > double backslashes I now get single forward slashes. I'm
> > > > > not sure if a regular windows editor or IDE can pick up
> > > > > on those to open the right file with the error when SDCC
> > > > > is called from within.
> > > >
> > > >
> > > > Maarten, I found a bug in my "fix" :-(.  I already commited the 2nd
> fix
> > > and
> > > > restarted x86 build on derna.
> > > >
> > > > Unfortunately it seems that this fix has nothing to do with the
> backslash
> > > > to slash conversion you reported.
> > > >
> > > > I couldn't reproduce the behaviour you reported. Can you please
>  give me
> > > > more info about the plaform (probably Win98?), the shell (cygwin
> bash or
> > > > cmd.exe), command line and program you are compiling?
> > > >
> > > > Borut
> > >
> > > Hi,
> > >
> > > I used todays SDCC #7984 and just did sdcc -c Source\file.c which
> includes
> > > defines.h from the same Source directory. There is a warning from
> defines.h
> > > reported with Source/defines.h.
> > >
> >
> > I tried it on WinXP with the following file.c content:
> >
> > ----8<----
> > #include "Source/defines.h"
> >
> > void
> > main (void)
> > {
> >   c
> > }
> > ---->8----
> >
> > the result with revision #7984:
> >
> > C:\>sdcc -c Source\file.c
> > Source\file.c:1:28: error: Source/defines.h: No such file or directory
> >       # reported by sdcpp, OK
> > Sourcefile.c:6: syntax error: token -> 'char' ; column 6
> >                  # reported bs sdcc, missing '/' between Source and
> file.c
> >
> > the result with revision #7986:
> >
> > C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -c Source\file.c
> > Source\file.c:1:28: error: Source/defines.h: No such file or directory
> >       # reported by sdcpp, OK
> > Source\file.c:7: syntax error: token -> '}' ; column 1
> >                      # reported bs sdcc, OK
> >
> > Is this the same as what you get?
> >
> > I guess the ''bug' was that there was no slash at all anymore when the
> error
> > > is in the source itself as I just found out.
> >
> >
> > Right, I skipped one char too much :-(.
> >
> > Borut
> >
>
> Sorry, I was not clear enough. The file is:
>
> 8<---- *file.c*
> #include "defines.h"
>
> void main (void)
> {
> }
> 8<---- *defines.h*
> struct TChapter
> {
>  char  Name[14];
>  char* Sets[];  //generates warning 187
> };
> 8<----
>
> And the output of sdcc -c Source\file.c on WinXP gives:
>
> Source/defines.h:4: warning 187: ISO C90 does not
>

With my latest fix is even worse:

C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -c Source\file.c
Source\/defines.h:5: warning 187: ISO C90 does not support flexible array
members support flexible array members

But the problem is in sdcpp (and cpp) not in sdcc:

C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -E Source\file.c
# 1 "Source\\file.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "Source\\file.c"
# 1 "Source\\/defines.h" 1   <-- Note the extra slash!!!!!
...

Cygwin gcc has the same problem:

C:\>gcc-3 -std=c89 -c Source\file.c
In file included from Source\file.c:1:
Source\/defines.h:4: error: parse error before '/' token
Source\/defines.h:4: warning: no semicolon at end of struct or union
Source\file.c: In function `main':
Source\file.c:6: error: parse error before '/' token
Source\file.c:5: warning: return type of 'main' is not `int'

C:\>gcc-3 -std=c89 -E Source\file.c
# 1 "Source\\file.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "Source\\file.c"
# 1 "Source\\/defines.h" 1   <-- Note the extra slash!!!!!
...

Since the problem is not in sdcc I suggest to leave it as it is for SDCC
3.2.0 release, fix it in sdcpp after the release and suggest the fix to
cygwin gcc and/or gcc teams.

Borut

Borut,

> With my latest fix is even worse:
> 
> C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -c Source\file.c
> Source\/defines.h:5: warning 187: ISO C90 does not support flexible array
> members support flexible array members
> 
> But the problem is in sdcpp (and cpp) not in sdcc:
> 
> C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -E Source\file.c
> # 1 "Source\\file.c"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "Source\\file.c"
> # 1 "Source\\/defines.h" 1   <-- Note the extra slash!!!!!
> ...
> 
> Cygwin gcc has the same problem:
> 
> C:\>gcc-3 -std=c89 -c Source\file.c
> In file included from Source\file.c:1:
> Source\/defines.h:4: error: parse error before '/' token
> Source\/defines.h:4: warning: no semicolon at end of struct or union
> Source\file.c: In function `main':
> Source\file.c:6: error: parse error before '/' token
> Source\file.c:5: warning: return type of 'main' is not `int'
> 
> C:\>gcc-3 -std=c89 -E Source\file.c
> # 1 "Source\\file.c"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "Source\\file.c"
> # 1 "Source\\/defines.h" 1   <-- Note the extra slash!!!!!
> ...
> 
> Since the problem is not in sdcc I suggest to leave it as it is for SDCC
> 3.2.0 release, fix it in sdcpp after the release and suggest the fix to
> cygwin gcc and/or gcc teams.
> 
> Borut

I agree.

Maarten

Oh oh! And now I see that the regression tests are 
failing with these modifications!


> Borut,
> 
> > With my latest fix is even worse:
> > 
> > C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -c Source\file.c
> > Source\/defines.h:5: warning 187: ISO C90 does not support flexible array
> > members support flexible array members
> > 
> > But the problem is in sdcpp (and cpp) not in sdcc:
> > 
> > C:\>\svn_snapshots\sdcc.build_cygwin\bin\sdcc.exe -E Source\file.c
> > # 1 "Source\\file.c"
> > # 1 "<built-in>"
> > # 1 "<command line>"
> > # 1 "Source\\file.c"
> > # 1 "Source\\/defines.h" 1   <-- Note the extra slash!!!!!
> > ...
> > 
> > Cygwin gcc has the same problem:
> > 
> > C:\>gcc-3 -std=c89 -c Source\file.c
> > In file included from Source\file.c:1:
> > Source\/defines.h:4: error: parse error before '/' token
> > Source\/defines.h:4: warning: no semicolon at end of struct or union
> > Source\file.c: In function `main':
> > Source\file.c:6: error: parse error before '/' token
> > Source\file.c:5: warning: return type of 'main' is not `int'
> > 
> > C:\>gcc-3 -std=c89 -E Source\file.c
> > # 1 "Source\\file.c"
> > # 1 "<built-in>"
> > # 1 "<command line>"
> > # 1 "Source\\file.c"
> > # 1 "Source\\/defines.h" 1   <-- Note the extra slash!!!!!
> > ...
> > 
> > Since the problem is not in sdcc I suggest to leave it as it is for SDCC
> > 3.2.0 release, fix it in sdcpp after the release and suggest the fix to
> > cygwin gcc and/or gcc teams.
> > 
> > Borut
> 
> I agree.
> 
> Maarten
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

On Wed, Jun 27, 2012 at 6:59 PM, Maarten Brock <sourceforge.brock@...:

> Oh oh! And now I see that the regression tests are
> failing with these modifications!


I can't understand how souch a general change can affect only the float.c
test on ucr2k target.

I'm investigating it...

Borut

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27.06.2012 19:20, Borut Ražem wrote:
> On Wed, Jun 27, 2012 at 6:59 PM, Maarten Brock
> <sourceforge.brock@... <mailto:sourceforge.brock@...>>
> wrote:
> 
> Oh oh! And now I see that the regression tests are failing with
> these modifications!
> 
> 
> I can't understand how souch a general change can affect only the 
> float.c test on ucr2k target.

The difference between r2k and r3ka ports currently is only in code
generation for built-in memset(), and the handling of uma / ums
instructions in peep.c (uma and ums would have to be created by inline
asm, as they are not yet used by code generation). So any failure of
exactly one out of r2k and r3ka should be related to memset().

Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/rRowACgkQbtUV+xsoLpoYgACg7ltcdFO/UY7TTUskNO19SQ/s
0aAAoLVb4bUeyghI3gbVs5DsWU/pZ5DO
=H7PP
-----END PGP SIGNATURE-----

On Wed, Jun 27, 2012 at 7:44 PM, Philipp Klaus Krause <pkk@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 27.06.2012 19:20, Borut Ražem wrote:
> > On Wed, Jun 27, 2012 at 6:59 PM, Maarten Brock
> > <sourceforge.brock@... <mailto:sourceforge.brock@...>>
> > wrote:
> >
> > Oh oh! And now I see that the regression tests are failing with
> > these modifications!
> >
> >
> > I can't understand how souch a general change can affect only the
> > float.c test on ucr2k target.
>
> The difference between r2k and r3ka ports currently is only in code
> generation for built-in memset(), and the handling of uma / ums
> instructions in peep.c (uma and ums would have to be created by inline
> asm, as they are not yet used by code generation). So any failure of
> exactly one out of r2k and r3ka should be related to memset().
>

It was (obviously, only I made changes from the last successfull build) my
fault after all: I freed the dynamically allocated file name each time the
it was changed in the header file, but some pointers still referenced the
deallocated memory.

This is the 3rd fix, hopefully it will last this time...

Borut

Borut,

I have some modifications that I'd like to commit. They 
are mainly fixes for warnings, renaming asrab to sdasrab 
in asrab.vcxproj and removal of the double-build of 
SDCCy.h in sdcc.vcxproj. See attached patch. Can you 
have a look and give permission or not?

Thanks,
Maarten

After all the mess I created with my changes is difficult to prohibit 
the commits to anyone :-[

I just quickly looked to the patch file without applying it. My only 
concern is "double-build of SDCCy.h": I tried several times to solve 
this mess but I never succeeded. Hopefully you did it in the right way...

Maarten, please go ahead an apply the patch.

Borut


On 28. 06. 2012 12:03, Maarten Brock wrote:
> Borut,
>
> I have some modifications that I'd like to commit. They
> are mainly fixes for warnings, renaming asrab to sdasrab
> in asrab.vcxproj and removal of the double-build of
> SDCCy.h in sdcc.vcxproj. See attached patch. Can you
> have a look and give permission or not?
>
> Thanks,
> Maarten

Hi,

> After all the mess I created with my changes is difficult to prohibit 
> the commits to anyone :-[

No worries. It was a problem that needed to be fixed. 
All your work is appreciated.

> I just quickly looked to the patch file without applying it. My only 
> concern is "double-build of SDCCy.h": I tried several times to solve 
> this mess but I never succeeded. Hopefully you did it in the right way...

Well, what I've done is remove it from the sdcc project 
since it already is in the yacc project. And all 
projects that need it (should) depend on the yacc 
project. While it was also in the sdcc project it would 
recreate SDCCy.h in the last steps of the build and thus 
the next build would start all over again compiling 
everything that depended on it.

It's still not completely ok, but now it only wants to 
rebuild the sdcc and version projects and not 
everything. But I also suspect a problem in Visual 
Studio with the checking of dependencies. Maybe I'll 
have another look after the release or when VS2012 is 
out.

Btw. is there a particular reason you modified the 
vcxproj files by hand instead of using the properties in 
the IDE? Now the special build events are not visible in 
the IDE. Or is this a result of upgrading?

> Maarten, please go ahead an apply the patch.
> 
> Borut

Ok, I will.

Maarten

> On 28. 06. 2012 12:03, Maarten Brock wrote:
> > Borut,
> >
> > I have some modifications that I'd like to commit. They
> > are mainly fixes for warnings, renaming asrab to sdasrab
> > in asrab.vcxproj and removal of the double-build of
> > SDCCy.h in sdcc.vcxproj. See attached patch. Can you
> > have a look and give permission or not?
> >
> > Thanks,
> > Maarten
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

On Thu, Jun 28, 2012 at 3:48 PM, Maarten Brock <sourceforge.brock@...:

> Hi,
>
> > After all the mess I created with my changes is difficult to prohibit
> > the commits to anyone :-[
>
> No worries. It was a problem that needed to be fixed.
> All your work is appreciated.
>
> > I just quickly looked to the patch file without applying it. My only
> > concern is "double-build of SDCCy.h": I tried several times to solve
> > this mess but I never succeeded. Hopefully you did it in the right way...
>
> Well, what I've done is remove it from the sdcc project
> since it already is in the yacc project. And all
> projects that need it (should) depend on the yacc
> project. While it was also in the sdcc project it would
> recreate SDCCy.h in the last steps of the build and thus
> the next build would start all over again compiling
> everything that depended on it.


If I remember well, I had problems when I tried to build the "all" project
vs. building only sdcc project: or yacc was not built at all or it was
built two times, which ruined dependencies as you explained above.


> It's still not completely ok, but now it only wants to
> rebuild the sdcc and version projects and not
> everything. But I also suspect a problem in Visual
> Studio with the checking of dependencies. Maybe I'll
> have another look after the release or when VS2012 is
> out.
>

The problem is that I read somewhere that VS2012 Express edition won't
include C/C++ compiler any more. In this case we will have to remain on
VS2010 ;-(


> Btw. is there a particular reason you modified the
> vcxproj files by hand instead of using the properties in
> the IDE? Now the special build events are not visible in
> the IDE. Or is this a result of upgrading?
>

I don't remember that I modified vcproj files by hand (this doesn't mean
that I didn't ;-). I notices that in your patch some lines in project files
just changed the position. Is this the problem?


> > Maarten, please go ahead an apply the patch.
> >
> > Borut
>
> Ok, I will.


Hopefully this will be the last changes for RC3.

I would like to make the RC3 build ASAP as Philipp proposed, probably
tomorrow after the snapshot builds are cooked.

Patryc, in case you are reading this, can you please confirm if the "doble
backslashes on Win98" probelm is fixed?

Borut

On Jun 28, 2012, at 8:11, "Borut Ražem" <borut.razem@...> wrote:

On Thu, Jun 28, 2012 at 3:48 PM, Maarten Brock <sourceforge.brock@...:

> Hi,
>
> > After all the mess I created with my changes is difficult to prohibit
> > the commits to anyone :-[
>
> No worries. It was a problem that needed to be fixed.
> All your work is appreciated.
>
> > I just quickly looked to the patch file without applying it. My only
> > concern is "double-build of SDCCy.h": I tried several times to solve
> > this mess but I never succeeded. Hopefully you did it in the right way...
>
> Well, what I've done is remove it from the sdcc project
> since it already is in the yacc project. And all
> projects that need it (should) depend on the yacc
> project. While it was also in the sdcc project it would
> recreate SDCCy.h in the last steps of the build and thus
> the next build would start all over again compiling
> everything that depended on it.


If I remember well, I had problems when I tried to build the "all" project
vs. building only sdcc project: or yacc was not built at all or it was
built two times, which ruined dependencies as you explained above.


> It's still not completely ok, but now it only wants to
> rebuild the sdcc and version projects and not
> everything. But I also suspect a problem in Visual
> Studio with the checking of dependencies. Maybe I'll
> have another look after the release or when VS2012 is
> out.
>

The problem is that I read somewhere that VS2012 Express edition won't
include C/C++ compiler any more. In this case we will have to remain on
VS2010 ;-(

Not sure where you heard that, this article from the VS team says it will.
http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx



> Btw. is there a particular reason you modified the
> vcxproj files by hand instead of using the properties in
> the IDE? Now the special build events are not visible in
> the IDE. Or is this a result of upgrading?
>

I don't remember that I modified vcproj files by hand (this doesn't mean
that I didn't ;-). I notices that in your patch some lines in project files
just changed the position. Is this the problem?


> > Maarten, please go ahead an apply the patch.
> >
> > Borut
>
> Ok, I will.


Hopefully this will be the last changes for RC3.

I would like to make the RC3 build ASAP as Philipp proposed, probably
tomorrow after the snapshot builds are cooked.

Patryc, in case you are reading this, can you please confirm if the "doble
backslashes on Win98" probelm is fixed?

Borut

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
sdcc-devel mailing list
sdcc-devel@...
https://lists.sourceforge.net/lists/listinfo/sdcc-devel

On Thu, Jun 28, 2012 at 5:18 PM, Brennan Ashton
<bashton@...:

> On Jun 28, 2012, at 8:11, "Borut Ražem" <borut.razem@...> wrote:
>
> On Thu, Jun 28, 2012 at 3:48 PM, Maarten Brock <sourceforge.brock@...:
>
>> It's still not completely ok, but now it only wants to
>
> rebuild the sdcc and version projects and not
>> everything. But I also suspect a problem in Visual
>> Studio with the checking of dependencies. Maybe I'll
>> have another look after the release or when VS2012 is
>> out.
>>
>
> The problem is that I read somewhere that VS2012 Express edition won't
> include C/C++ compiler any more. In this case we will have to remain on
> VS2010 ;-(
>
> Not sure where you heard that, this article from the VS team says it will.
>
> http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx
>

So they changed their minds. Great!


> Patryc, in case you are reading this, can you please confirm if the "doble
> backslashes on Win98" probelm is fixed?
>
> Patryk, I misspelled your name again, sorry :-(

Borut

SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available  in 
corresponding folders at:
http://sourceforge.net/projects/sdcc/files

If you find a mistake, please send a mail to sdcc-devel mailing list 
sdcc-devel@....

I would appreciate any reports about a success or failure of running 
pre-compiled binary packages. I'm specially interested on Mac OS X ppc 
architecture since I can not test it. Please let me know if the 
pre-built binaries run on this platform.

Bout

Dear sdcc developers,

the sdcc RC3 is released. This release candidate 3 was not originally 
planned, but we decided to make it due to changes after RC2. The final 
sdcc 3.2.0 release is still planned for the next week end.

Please consider the svn main branch as DEEPLY FROZEN, which means 
NOTHING can be committed without the agreement between sdcc developers 
and release manager.

The SDCC 3.2.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.2.0%20Release 
<https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release>.

Borut

PIC16 (18F4550) tested on linux x86. Exactly the same code generated than
RC2.

Regards,
Diego

On Fri, Jun 29, 2012 at 6:56 PM, Borut Ražem <borut.razem@...> wrote:

> SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available  in
> corresponding folders at:
> http://sourceforge.net/projects/sdcc/files
>
> If you find a mistake, please send a mail to sdcc-devel mailing list
> sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running
> pre-compiled binary packages. I'm specially interested on Mac OS X ppc
> architecture since I can not test it. Please let me know if the
> pre-built binaries run on this platform.
>
> Bout
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Hi,

> > Btw. is there a particular reason you modified the
> > vcxproj files by hand instead of using the properties in
> > the IDE? Now the special build events are not visible in
> > the IDE. Or is this a result of upgrading?
> 
> I don't remember that I modified vcproj files by hand (this doesn't mean
> that I didn't ;-). I notices that in your patch some lines in project files
> just changed the position. Is this the problem?

Well, I did change them by hand, because I could not 
find the settings from within the IDE. And thus the line 
position changes are for my readability. They are not 
the problem. Can you please explain how you get the 
build events from within Visual Studio?

Maarten

----- Original Message ----- 
From: "Borut Ražem" <borut.razem@...>
To: "Development chatter about sdcc" <sdcc-devel@...>
Sent: Monday, June 25, 2012 9:58 PM
Subject: Re: [sdcc-devel] SDCC 3.2.0 Release Candidate 2


Patryk,

I meant uppercase "-V", not lowercase "-v".

Borut

[Patryk] Here it is:
D:\MM\SiLabs_IDE\ADuC>sdcc -c D:\MM\SiLabs_IDE\ADuC\test.c -V
+ 
C:\PROGRA~1\SDCC\BIN\SDCPP.EXE -nostdinc -Wall -obj-ext=.rel -D__SDCC_MODEL_SM
ALL -DSDCC_MODEL_SMALL -D__SDCC_FLOAT_REENT -DSDCC_FLOAT_REENT -D__SDCC=3_2_0 
 -D
SDCC=320 -D__SDCC_REVISION=7964 -DSDCC_REVISION=7964 -D__SDCC_mcs51 -DSDCC_mcs51
 -D__mcs51 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ 
 -D_
_STDC_NO_VLA__ -isystem "C:\PROGRA~1\SDCC\BIN\..\include\mcs51" -isystem 
"C:\PRO
GRA~1\SDCC\BIN\..\include"  "D:\MM\SiLabs_IDE\ADuC\test.c"
+ C:\PROGRA~1\SDCC\BIN\SDAS8051.EXE -plosgffw "test.rel" "test.asm"
test.asm:108: Error: <r> relocation error
test.asm:109: Error: <r> relocation error
removing test.rel

On Mon, Jun 25, 2012 at 9:33 PM, Patryk <patjank@...> wrote:

>
> ----- Original Message -----
> From: "Borut Ražem" <borut.razem@...>
> To: "Development chatter about sdcc" <sdcc-devel@...>
> Sent: Monday, June 25, 2012 3:59 PM
> Subject: Re: [sdcc-devel] SDCC 3.2.0 Release Candidate 2
>
>
> On Mon, Jun 25, 2012 at 2:10 PM, <patjank@...> wrote:
>
> > Dnia 25-06-2012 o godz. 11:47 Borut RaĹžem napisał(a):
> > > > > Patryc, can you please provide a short c source file which
> reproduce
> > the
> > > > > problem? Can you please add the -V sdcc command line option, run
> > > > > compilation and send the result? Specially the "No such file or
> > > > > directory" error makes me nervous: it seems that it didn't happen
> in
> > 3.1.0.
> > > > >
> > > > > I propose to open a bug report and supply / attach all the needed
> > info
> > > > > there.
> >
> > I mean any SDCC warning/error during compilation, as Maarten confirmed
> > below. It causes some confusion to SiLabs IDE.
> > As of "No such file or directory" - it's just a line from *.asm file
> > generated by SDCC. There should be source code cited, but double slashes
> > seems to prevent SDCC access to the source file under Win98 during *.asm
> > generating phase. Borut - I'm sorry to make you nervous, please rest
> > assured that it's nothing serious :-)
>
>
> It is not you making me nervous, it is the fact that we have a regression
> an that I'm probably guilty for it. :-(
>
> I would still appreciate if you can send me the output with -V option.
>
> [Patryk] Here it is (RC2):
> SDCC :
> mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08
> 3.2.0 #7964 (Jun 24 2012) (MINGW32)
>
> Borut
>



--------------------------------------------------------------------------------


> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


--------------------------------------------------------------------------------


> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

----- Original Message ----- 
From: "Borut Razem" <borut.razem@...>
To: <sourceforge.brock@...>; "Development chatter about sdcc" 
<sdcc-devel@...>; <patjank@...>
Sent: Thursday, June 28, 2012 5:10 PM
Subject: Re: [sdcc-devel] SDCC 3.2.0 Release Candidate 2


> On Thu, Jun 28, 2012 at 3:48 PM, Maarten Brock 
> <sourceforge.brock@...:
>
>> Hi,
>>
>> > After all the mess I created with my changes is difficult to prohibit
>> > the commits to anyone :-[
>>
>> No worries. It was a problem that needed to be fixed.
>> All your work is appreciated.
>>
>> > I just quickly looked to the patch file without applying it. My only
>> > concern is "double-build of SDCCy.h": I tried several times to solve
>> > this mess but I never succeeded. Hopefully you did it in the right 
>> > way...
>>
>> Well, what I've done is remove it from the sdcc project
>> since it already is in the yacc project. And all
>> projects that need it (should) depend on the yacc
>> project. While it was also in the sdcc project it would
>> recreate SDCCy.h in the last steps of the build and thus
>> the next build would start all over again compiling
>> everything that depended on it.
>
>
> If I remember well, I had problems when I tried to build the "all" project
> vs. building only sdcc project: or yacc was not built at all or it was
> built two times, which ruined dependencies as you explained above.
>
>
>> It's still not completely ok, but now it only wants to
>> rebuild the sdcc and version projects and not
>> everything. But I also suspect a problem in Visual
>> Studio with the checking of dependencies. Maybe I'll
>> have another look after the release or when VS2012 is
>> out.
>>
>
> The problem is that I read somewhere that VS2012 Express edition won't
> include C/C++ compiler any more. In this case we will have to remain on
> VS2010 ;-(
>
>
>> Btw. is there a particular reason you modified the
>> vcxproj files by hand instead of using the properties in
>> the IDE? Now the special build events are not visible in
>> the IDE. Or is this a result of upgrading?
>>
>
> I don't remember that I modified vcproj files by hand (this doesn't mean
> that I didn't ;-). I notices that in your patch some lines in project 
> files
> just changed the position. Is this the problem?
>
>
>> > Maarten, please go ahead an apply the patch.
>> >
>> > Borut
>>
>> Ok, I will.
>
>
> Hopefully this will be the last changes for RC3.
>
> I would like to make the RC3 build ASAP as Philipp proposed, probably
> tomorrow after the snapshot builds are cooked.
>
> Patryc, in case you are reading this, can you please confirm if the "doble
> backslashes on Win98" probelm is fixed?

Sorry to respond so late. I have tested RC3, it installs and works fine, the 
double backslashes issue is fixed. Thank you for putting the effort to 
resolve such minor issue on such old and rarely used OS.

>
> Borut
>

Tested RC3 on Win98, it installs and works fine with 8051 project.

----- Original Message ----- 
From: "Borut Razem" <borut.razem@...>
To: "Sdcc-User" <sdcc-user@...>; "Sdcc-Devel" 
<sdcc-devel@...>
Sent: Friday, June 29, 2012 6:56 PM
Subject: [sdcc-devel] SDCC 3.2.0 Release Candidate 3


> SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available  in
> corresponding folders at:
> http://sourceforge.net/projects/sdcc/files
>
> If you find a mistake, please send a mail to sdcc-devel mailing list
> sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running
> pre-compiled binary packages. I'm specially interested on Mac OS X ppc
> architecture since I can not test it. Please let me know if the
> pre-built binaries run on this platform.
>
> Bout
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Patryk,

I'm glad that the "double backslashes" problem is solved.

Thaks for the report.

Borut


On 30. 06. 2012 01:10, Patryk wrote:
> Tested RC3 on Win98, it installs and works fine with 8051 project.
>
> ----- Original Message -----
> From: "Borut Razem" <borut.razem@...>
> To: "Sdcc-User" <sdcc-user@...>; "Sdcc-Devel"
> <sdcc-devel@...>
> Sent: Friday, June 29, 2012 6:56 PM
> Subject: [sdcc-devel] SDCC 3.2.0 Release Candidate 3
>
>
>> SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86
>> Linux, 32 bit Windows and universal Mac OS X are available  in
>> corresponding folders at:
>> http://sourceforge.net/projects/sdcc/files
>>
>> If you find a mistake, please send a mail to sdcc-devel mailing list
>> sdcc-devel@....
>>
>> I would appreciate any reports about a success or failure of running
>> pre-compiled binary packages. I'm specially interested on Mac OS X ppc
>> architecture since I can not test it. Please let me know if the
>> pre-built binaries run on this platform.
>>
>> Bout

On 30. 06. 2012 01:08, Patryk wrote:
> ----- Original Message -----
> From: "Borut Razem" <borut.razem@...>
> To: <sourceforge.brock@...>; "Development chatter about sdcc"
> <sdcc-devel@...>; <patjank@...>
> Sent: Thursday, June 28, 2012 5:10 PM
> Subject: Re: [sdcc-devel] SDCC 3.2.0 Release Candidate 2
>
>
>> On Thu, Jun 28, 2012 at 3:48 PM, Maarten Brock
>> <sourceforge.brock@...:
>>
>>> Hi,
>>>
>>>> After all the mess I created with my changes is difficult to prohibit
>>>> the commits to anyone :-[
>>> No worries. It was a problem that needed to be fixed.
>>> All your work is appreciated.
>>>
>>>> I just quickly looked to the patch file without applying it. My only
>>>> concern is "double-build of SDCCy.h": I tried several times to solve
>>>> this mess but I never succeeded. Hopefully you did it in the right
>>>> way...
>>> Well, what I've done is remove it from the sdcc project
>>> since it already is in the yacc project. And all
>>> projects that need it (should) depend on the yacc
>>> project. While it was also in the sdcc project it would
>>> recreate SDCCy.h in the last steps of the build and thus
>>> the next build would start all over again compiling
>>> everything that depended on it.
>>
>> If I remember well, I had problems when I tried to build the "all" project
>> vs. building only sdcc project: or yacc was not built at all or it was
>> built two times, which ruined dependencies as you explained above.
>>
>>
>>> It's still not completely ok, but now it only wants to
>>> rebuild the sdcc and version projects and not
>>> everything. But I also suspect a problem in Visual
>>> Studio with the checking of dependencies. Maybe I'll
>>> have another look after the release or when VS2012 is
>>> out.
>>>
>> The problem is that I read somewhere that VS2012 Express edition won't
>> include C/C++ compiler any more. In this case we will have to remain on
>> VS2010 ;-(
>>
>>
>>> Btw. is there a particular reason you modified the
>>> vcxproj files by hand instead of using the properties in
>>> the IDE? Now the special build events are not visible in
>>> the IDE. Or is this a result of upgrading?
>>>
>> I don't remember that I modified vcproj files by hand (this doesn't mean
>> that I didn't ;-). I notices that in your patch some lines in project
>> files
>> just changed the position. Is this the problem?
>>
>>
>>>> Maarten, please go ahead an apply the patch.
>>>>
>>>> Borut
>>> Ok, I will.
>>
>> Hopefully this will be the last changes for RC3.
>>
>> I would like to make the RC3 build ASAP as Philipp proposed, probably
>> tomorrow after the snapshot builds are cooked.
>>
>> Patryc, in case you are reading this, can you please confirm if the "doble
>> backslashes on Win98" probelm is fixed?
> Sorry to respond so late. I have tested RC3, it installs and works fine, the
> double backslashes issue is fixed. Thank you for putting the effort to
> resolve such minor issue on such old and rarely used OS.

Actually the bug was on all Windows architectures but cased problems 
only on Win98 (command.com).

During analysis of this problem I found that there other bugs when 
dealing with file names which include special characters. This will be 
fixed after the 3.2.0 release.

Thanks for your help.

Borut

On 2012-06-24 14:54, Borut Ražem wrote:

>
> SDCC 3.2.0 Release Candidate 2 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available  in
> corresponding folders at:
> http://sourceforge.net/projects/sdcc/files
>
> If you find a mistake, please send a mail to sdcc-devel mailing list
> sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running
> pre-compiled binary packages.
>

- Installed SDCC 3.2.0 RC3 (not RC2) on a Windows 7 Professional
   64-bit computer, and the result is the following:

	- Installer suggest "C:\Program Files\SDCC" instead
	  of "C:\Program Files (x86)\SDCC".
	  Have to modify manually to "C:\Program Files (x86)\SDCC" to
	  have SDCC installed in 32-bit programs directory.


- Done functional tests, using SDCC to build for a Z80
   based target, and the result is the following:

	- When building the project for debugging, with the
	  following tools options, all is correct.
				      +++
CPPFLAGS =  --debug -D_DEBUG
OPTFLAGS = --nooverlay --nogcse --noinvariant --noinduction --nojtbound 
--noloopreverse --no-peep --no-reg-params
				      +++

	- When building the project for release, with the
	  following tools options, "failed" messages are displayed.
				      +++
CPPFLAGS =
OPTFLAGS = --opt-code-size
				      +++

	  These "failed" messages look like the following:

				      +++
z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node     rst 0x10
z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node     rst 0x18
z80instructionSize() failed to parse line node
...
z80instructionSize() failed to parse line node  di
z80instructionSize() failed to parse line node  di
				      +++

	- Will do another tests to try to track down these
	  "failed" messages.


 From a SDCC user,
Claude

On 2012-06-30 10:49, Claude Sylvain wrote:

 >
 > - Done functional tests, using SDCC to build for a Z80
 >    based target, and the result is the following:
 >
 >      - When building the project for debugging, with the
 >        following tools options, all is correct.
 >                        +++
 > CPPFLAGS =  --debug -D_DEBUG
 > OPTFLAGS = --nooverlay --nogcse --noinvariant --noinduction --nojtbound
 > --noloopreverse --no-peep --no-reg-params
 >                        +++
 > ...
 > ...
 >
 > z80instructionSize() failed to parse line node
 > z80instructionSize() failed to parse line node     rst 0x18
 > z80instructionSize() failed to parse line node
 > ...
 > z80instructionSize() failed to parse line node  di
 > z80instructionSize() failed to parse line node  di
 >                        +++
 >
 >      - Will do another tests to try to track down these
 >        "failed" messages.
 >

- Forget results about the functional tests in the previous
   E-mail.

   I made a mistake when setting up the tools.


Sorry,
Claude

Claude Sylvain found an error in sdcc installer: installer suggests 
"C:\Program Files\SDCC" instead of "C:\Program Files (x86)\SDCC". I 
repacked the sdcc 3.2.0 RC3 Windows setup package and renamed it to 
sdcc-3.2.0-rc3a-setup.exe. You can find the package at: 
http://sourceforge.net/projects/sdcc/files/sdcc-win32/3.2.0/sdcc-3.2.0-rc3a-setup.exe/download.

P.S.: the Windows setup package content is exactly the same as for RC3. 
This change does not affect packages for other platforms.

Borut

On 29. 06. 2012 18:56, Borut Ražem wrote:
> SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86 
> Linux, 32 bit Windows and universal Mac OS X are available  in 
> corresponding folders at:
> http://sourceforge.net/projects/sdcc/files
>
> If you find a mistake, please send a mail to sdcc-devel mailing list 
> sdcc-devel@....
>
> I would appreciate any reports about a success or failure of running 
> pre-compiled binary packages. I'm specially interested on Mac OS X ppc 
> architecture since I can not test it. Please let me know if the 
> pre-built binaries run on this platform.
>
> Bout

If you make this change to the setup, you should split it out for a 
Windows 7 installers vs.
win98/2k/xp installer.

Windows 7 / 64-bit is the point in time that microsoft introduce the 
"C:\Program Files (x86)\" for
32-bit programs.  The previous version of windows don't have that folder 
(because they are entirely 32-bit).
Maybe we can setup determine the windows version, and split the setting 
based on that, but
I don't know how to configure the setup program to do that.

-Lee

On 6/30/2012 4:56 PM, Borut Ražem wrote:
> Claude Sylvain found an error in sdcc installer: installer suggests
> "C:\Program Files\SDCC" instead of "C:\Program Files (x86)\SDCC". I
> repacked the sdcc 3.2.0 RC3 Windows setup package and renamed it to
> sdcc-3.2.0-rc3a-setup.exe. You can find the package at:
> http://sourceforge.net/projects/sdcc/files/sdcc-win32/3.2.0/sdcc-3.2.0-rc3a-setup.exe/download.
>
> P.S.: the Windows setup package content is exactly the same as for RC3.
> This change does not affect packages for other platforms.
>
> Borut
>
> On 29. 06. 2012 18:56, Borut Ražem wrote:
>> SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86
>> Linux, 32 bit Windows and universal Mac OS X are available  in
>> corresponding folders at:
>> http://sourceforge.net/projects/sdcc/files
>>
>> If you find a mistake, please send a mail to sdcc-devel mailing list
>> sdcc-devel@....
>>
>> I would appreciate any reports about a success or failure of running
>> pre-compiled binary packages. I'm specially interested on Mac OS X ppc
>> architecture since I can not test it. Please let me know if the
>> pre-built binaries run on this platform.
>>
>> Bout
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>

On 01. 07. 2012 19:02, Leland Morrison wrote:
> If you make this change to the setup, you should split it out for a
> Windows 7 installers vs.
> win98/2k/xp installer.
>
> Windows 7 / 64-bit is the point in time that microsoft introduce the
> "C:\Program Files (x86)\" for
> 32-bit programs.  The previous version of windows don't have that folder
> (because they are entirely 32-bit).
> Maybe we can setup determine the windows version, and split the setting
> based on that, but
> I don't know how to configure the setup program to do that.

The .nsi script detects the windows version (32 or 46 bit) and which 
version of sdcc binaries (32 or 46 bit) it is installing (-DWIN64 
command line argument) . When installing 32 bit binaries on 64 bit 
windows it installs in "C:\Program Files (x86)" directory. The 32/64 bit 
registry is also selected accordingly. I hope that the bug is fixed in 
rc3a version.

Borut

> -Lee
>
> On 6/30/2012 4:56 PM, Borut Ražem wrote:
>> Claude Sylvain found an error in sdcc installer: installer suggests
>> "C:\Program Files\SDCC" instead of "C:\Program Files (x86)\SDCC". I
>> repacked the sdcc 3.2.0 RC3 Windows setup package and renamed it to
>> sdcc-3.2.0-rc3a-setup.exe. You can find the package at:
>> http://sourceforge.net/projects/sdcc/files/sdcc-win32/3.2.0/sdcc-3.2.0-rc3a-setup.exe/download.
>>
>> P.S.: the Windows setup package content is exactly the same as for RC3.
>> This change does not affect packages for other platforms.
>>
>> Borut
>>
>> On 29. 06. 2012 18:56, Borut Ražem wrote:
>>> SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86
>>> Linux, 32 bit Windows and universal Mac OS X are available  in
>>> corresponding folders at:
>>> http://sourceforge.net/projects/sdcc/files
>>>
>>> If you find a mistake, please send a mail to sdcc-devel mailing list
>>> sdcc-devel@....
>>>
>>> I would appreciate any reports about a success or failure of running
>>> pre-compiled binary packages. I'm specially interested on Mac OS X ppc
>>> architecture since I can not test it. Please let me know if the
>>> pre-built binaries run on this platform.
>>>
>>> Bout

Hi SDCC developers!

Herbert Pötzl found a nasty pic16 bug: #3539804 - "#pragma config and 
certain string constants". This bug makes the pic16 target unusable when 
#pragma config is defined and there are string constants defined in 
functions (it does not affect string constants defined outside 
functions). Herbert proposed a patch sdcc-3.2.0-config_fix.diff which 
just switches to code section after generating the CONFIG directive. I 
believe that this fix solves the problem quite elegantly and without 
introducing any additional risk. After the 3.2.0 release the more 
appropriate 'config' Map approach can be implemented.

I'd like to include the fix into 3.2.0 release since the bug and fix 
affect only pic16 target (change in file src/pic16/main.c) and IMHO the 
risk is low. I'm also thinking to make an other release candidate: RC4 
today, so that developers & users can do some testsing during the 
weekend and, if everything is OK, make the final 3.2.0 release on Monday.

Please let me know if you have concerns or disagree wit the proposal ASAP.

Borut

Borut,

Please go ahead.

Maarten

> Hi SDCC developers!
> 
> Herbert Pötzl found a nasty pic16 bug: #3539804 - "#pragma config and 
> certain string constants". This bug makes the pic16 target unusable when 
> #pragma config is defined and there are string constants defined in 
> functions (it does not affect string constants defined outside 
> functions). Herbert proposed a patch sdcc-3.2.0-config_fix.diff which 
> just switches to code section after generating the CONFIG directive. I 
> believe that this fix solves the problem quite elegantly and without 
> introducing any additional risk. After the 3.2.0 release the more 
> appropriate 'config' Map approach can be implemented.
> 
> I'd like to include the fix into 3.2.0 release since the bug and fix 
> affect only pic16 target (change in file src/pic16/main.c) and IMHO the 
> risk is low. I'm also thinking to make an other release candidate: RC4 
> today, so that developers & users can do some testsing during the 
> weekend and, if everything is OK, make the final 3.2.0 release on Monday.
> 
> Please let me know if you have concerns or disagree wit the proposal ASAP.
> 
> Borut
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Am 06.07.2012 09:58, schrieb Borut Ražem:
> Hi SDCC developers!
> 
> Herbert Pötzl found a nasty pic16 bug: #3539804 - "#pragma config and 
> certain string constants". This bug makes the pic16 target unusable when 
> #pragma config is defined and there are string constants defined in 
> functions (it does not affect string constants defined outside 
> functions). Herbert proposed a patch sdcc-3.2.0-config_fix.diff which 
> just switches to code section after generating the CONFIG directive. I 
> believe that this fix solves the problem quite elegantly and without 
> introducing any additional risk. After the 3.2.0 release the more 
> appropriate 'config' Map approach can be implemented.
> 
> I'd like to include the fix into 3.2.0 release since the bug and fix 
> affect only pic16 target (change in file src/pic16/main.c) and IMHO the 
> risk is low. I'm also thinking to make an other release candidate: RC4 
> today, so that developers & users can do some testsing during the 
> weekend and, if everything is OK, make the final 3.2.0 release on Monday.

OK, if it only affects pic targets.

Philipp

SDCC 3.2.0 Release Candidate 4 source, doc and binary packages for x86 
Linux, 32 bit Windows and universal Mac OS X are available  in 
corresponding folders at:
http://sourceforge.net/projects/sdcc/files

If you find a mistake, please send a mail to sdcc-devel mailing list 
sdcc-devel@....

I would appreciate any reports about a success or failure of running 
pre-compiled binary packages. I'm specially interested on Mac OS X ppc 
architecture since I can not test it. Please let me know if the 
pre-built binaries run on this platform.

Bot

Dear sdcc developers,

the sdcc RC4 is released. This release candidate 4 was not originally 
planned, but we decided to make it due to changes after RC3. The final 
sdcc 3.2.0 release is planned for 2012-07-09.

Please consider the svn main branch as DEEPLY FROZEN, which means 
NOTHING can be committed without the agreement between sdcc developers 
and release manager.

The SDCC 3.2.0 release schedule is published at 
http://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.2.0%20Release 
<https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.1.0%20Release>.

Borut

Borut,

> > I don't remember that I modified vcproj files by hand (this doesn't mean
> > that I didn't ;-). I notices that in your patch some lines in project files
> > just changed the position. Is this the problem?
> 
> Well, I did change them by hand, because I could not 
> find the settings from within the IDE. And thus the line 
> position changes are for my readability. They are not 
> the problem. Can you please explain how you get the 
> build events from within Visual Studio?

Nevermind, I found it myself. And I also found out it 
was still not cleared of IMO unnecessary rebuilding. 
I'll commit some modified project files again soon.

Maarten