> I understand and can support (up to a point) the desire of distributors to
> continue working within GPLv2 and I know that's why the 4.1 branch is in
> this situation. However IMHO this position is in tension with the
> interests of users who don't get gcc from distributors (think
> non-linux-gn
On Sun, 16 Mar 2008, Zdenek Dvorak wrote:
> Hi,
>
> > > > A statistics event consists of a function (optional), a statement
> > > > (optional) and the counter ID. I converted the counters from
> > > > tree-ssa-propagate.c as an example, instead of
> > > >
> > > > prop_stats.num_
On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Sat, 15 Mar 2008, NightStrike wrote:
>
> > On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > > I support the final-release-then-close approach. But can we get a
> > > volunteer to convert that branch to GPLv3... ?
> >
> > How compl
On 3/16/08, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I understand and can support (up to a point) the desire of distributors to
> > continue working within GPLv2 and I know that's why the 4.1 branch is in
> > this situation. However IMHO this position is in tension with the
> > interests of us
* Basile STARYNKEVITCH wrote on Wed, Mar 12, 2008 at 07:57:33AM CET:
> So I tried to add to gcc/configure.ac the following lines (which exist
> in libmudflap/configure.ac)
>
> AC_LIBTOOL_DLOPEN
> AM_PROG_LIBTOOL
> AC_SUBST(enable_shared)
> AC_SUBST(enable_static)
>
> and it does not work:
On Sun, Mar 16, 2008 at 9:33 AM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I understand and can support (up to a point) the desire of distributors to
> > continue working within GPLv2 and I know that's why the 4.1 branch is in
> > this situation. However IMHO this position is in tension with
Now lets take a simple built.
gcc -c test1.c
gcc -c test2.c
gcc test1.o test2.o -o final
--test1.c--
/* of course in real world this would be some complex but solveable function */
int test (int a) {
a=a+1;
}
--test2.c--
#include
int test(int a); /* normally in a header somewhere not bothering t
Richard Guenther wrote:
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
I too think that it would be a bad idea to switch the 4.1 branch to
GPLv3, and, therefore, I think
Manuel López-Ibáñez wrote:
That is a good point. The underlying mechanism can be fine tuned
later. What would be the main problems to get caret diagnostics in
trunk? The most common issue is probably bad locations but I don't see
that as a major problem. On the contrary, the only reliable way to
This command
$(CC) -M $(HOST_CFLAGS) $(CPPFLAGS) -MQ $@ include/common.h > [EMAIL PROTECTED]
is generating following error:
here cc is xscale-elf-gcc
and target is autoconf.mk
Generating include/autoconf.mk
xscale-elf-gcc: compilation of header file requested
any tips.
Regards
On 3/16/08, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> I support the final-release-then-close approach. But can we get a
> >> volunteer to convert that branch to GPLv3... ?
> >
> > I strongly object to moving the 4.1 brach to GPLv3.
>
> I too think that it would be
Jeff, DJ and Richard,
Richard Sandiford and I have taken on the task of trying to fully
explain subregs in the gcc docs. This is an area where that
traditionally has been very confusing to outsiders and even insiders who
were not rtl maintainers. As the community of active developers has
NightStrike wrote:
> What exactly is the downside to upgrading the license? I'm not
> familiar with the implications of doing so.
As I understand it, the concern is that many distros use the 4.1 branch
as the base for their main gcc system compiler. If suddenly the branch
gets upgraded to GPLv3
I have been working on AVR port and have come across many instances
where poor code is produced due to the absence of effective forward
propagation of operands before register allocation.
The AVR target in particular benefits from register lowering pass as
many physical registers and instructi
> It is seldom necessary to wrap hard registers in @code{subreg}s;
> such registers would normally reduce to a single @code{reg} rtx.
Are these valid? I know we've gone back and forth, but I thought the
current position is that SUBREGs of hard regs are only allowed
transitorily (e.g., during relo
"Peter Dolding" <[EMAIL PROTECTED]> writes:
> Since test is in a different object file it gets completely skiped
> from optimising even that it should be optimised out.
http://gcc.gnu.org/wiki/LTO_Driver
Ian
Ian Lance Taylor wrote:
"Peter Dolding" <[EMAIL PROTECTED]> writes:
Since test is in a different object file it gets completely skiped
from optimising even that it should be optimised out.
http://gcc.gnu.org/wiki/LTO_Driver
Ian
Ok that is half my idea. Let it sort out at link sta
On Sun, 16 Mar 2008, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> I support the final-release-then-close approach. But can we get a
> >> volunteer to convert that branch to GPLv3... ?
> >
> > I strongly object to moving the 4.1 brach to GPLv3.
>
> I too think that it would be a bad ide
On Sun, 16 Mar 2008, Kaveh R. GHAZI wrote:
> However there is a class of users who don't get their compiler from
> distributors, but who also want the safety of using official releases and
> not some random svn checkout. These users are missing one year's worth of
> bugfixes. They may not want to
On Wed, Mar 12, 2008 at 10:44:48PM +1100, Greg Schafer wrote:
> Currently, -B doesn't add the multilib search paths when processing
> startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in
> $prefix/lib/../lib64
>
> Most other calls to add_prefix() in gcc.c that refer to star
20 matches
Mail list logo
