> From: Alexandre Oliva
> Date: Tue, 2 Jun 2020 13:29:03 +0200
> Hello, Anthony, H-P,
>
> On May 27, 2020, Anthony Green wrote:
>
> > Hans-Peter Nilsson via Gcc-patches writes:
> >> And here's an improper bug report.
> >>
> >> One of the commits between cfdff3eeb90..5c8344e7289 caused every
Hello, Anthony, H-P,
On May 27, 2020, Anthony Green wrote:
> Hans-Peter Nilsson via Gcc-patches writes:
>> And here's an improper bug report.
>>
>> One of the commits between cfdff3eeb90..5c8344e7289 caused every
>> single *linked* test to fail for cris-elf, like:
> I can confirm that the mox
On May 27, 2020, Hans-Peter Nilsson wrote:
>> I ask because this error suggests an empty argument passed to
>> GCC.
> And ignored before your rewrite?
Or absent. It turned out my massaging of ldflags et al turned
consecutive blanks into empty arguments. I posted a patch for that and
most of t
Hans-Peter Nilsson via Gcc-patches writes:
> And here's an improper bug report.
>
> One of the commits between cfdff3eeb90..5c8344e7289 caused every
> single *linked* test to fail for cris-elf, like:
I can confirm that the moxie-elf test cases don't link either.
It looks like setting ldscript i
> From: Alexandre Oliva
> Date: Wed, 27 May 2020 16:30:07 +0200
> On May 26, 2020, Hans-Peter Nilsson wrote:
>
> >> Here's a proper patch submission.
>
> > And here's an improper bug report.
>
> :-)
>
> Thanks, H-P,
>
> > xgcc: error: : No such file or directory
>
> Interesting... If you
On May 26, 2020, Hans-Peter Nilsson wrote:
>> Here's a proper patch submission.
> And here's an improper bug report.
:-)
Thanks, H-P,
> xgcc: error: : No such file or directory
Interesting... If you cut&paste the command line that you included in
your so-called improper bug report ;-) do yo
> From: Alexandre Oliva
> Date: Tue, 26 May 2020 15:52:57 +0200
> On May 26, 2020, Richard Biener wrote:
>
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
>
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
>
> Here's a proper patch submission.
And he
On Wed, Feb 12, 2014 at 10:16:37AM +0100, Marek Polacek wrote:
> On Wed, Feb 12, 2014 at 01:43:39PM +0530, Senthil Kumar Selvaraj wrote:
> > The below patch fixes the build for AVR and SPU targets, which got broken
> > when the signature of build_function_call_vec changed. The patch passes
> > vNUL
On Wed, Feb 12, 2014 at 01:43:39PM +0530, Senthil Kumar Selvaraj wrote:
> The below patch fixes the build for AVR and SPU targets, which got broken
> when the signature of build_function_call_vec changed. The patch passes
> vNULL for the extra parameter added (arg_loc), which I hope is ok for
> bui
The below patch fixes the build for AVR and SPU targets, which got broken
when the signature of build_function_call_vec changed. The patch passes
vNULL for the extra parameter added (arg_loc), which I hope is ok for
builtins?
If ok, could someone commit please? I don't have commit access.
Regards
Thanks for catching this, and the fix.
OK for google branch.
-Rong
On Fri, Jan 31, 2014 at 2:46 PM, Hán Shěn (沈涵) wrote:
> Hi Rong, while building for arm toolchain on chromeos, GCOV_LOCKED is
> not defined, which leads to redefinition of cs_all, this is observed
> on google/gcc-4_8 branch.
>
>
Hi Rong, while building for arm toolchain on chromeos, GCOV_LOCKED is
not defined, which leads to redefinition of cs_all, this is observed
on google/gcc-4_8 branch.
Patch below, tested on chromeos for arm and x86_64 arch.
Ok for google/gcc-4_8 branch?
diff --git a/libgcc/libgcov-driver.c b/libgc
On Wed, 2013-08-07 at 15:25 +0200, Eric Botcazou wrote:
> Looks good, please install if not already done.
Thanks; I've now committed this to trunk as r201569.
> I think it's r201508, but in any case, I'm attaching a patch which fixes
> this build error. Only very lightly tested so far, with configure
> --target=sparc-linux with build&host x86_64. Was able to build a cc1
> and step through the changed code in the debugger, though am getting
> "cc1: erro
On Tue, 2013-08-06 at 14:12 +0200, Jan-Benedict Glaw wrote:
> On Tue, 2013-08-06 14:10:11 +0200, Jan-Benedict Glaw
> wrote:
> > And probably also for sparc{,64}-linux:
> >
> > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> > -fno-rtti -fasynchronous-unwind-tables -W -Wa
On Sun, 2012-07-08 at 20:51 +0200, Steven Bosscher wrote:
> On Sun, Jul 8, 2012 at 5:43 PM, Oleg Endo wrote:
> > Hello,
> >
> > The recent change that removed the inclusion of tree.h in several places
> > broke the SH target in one place in sh.md, where stuff from tree.h was
> > used directly. I'
Oleg Endo wrote:
> The recent change that removed the inclusion of tree.h in several places
> broke the SH target in one place in sh.md, where stuff from tree.h was
> used directly. I've moved those lines in question into a new function
> in sh.c.
> Tested with make all-gcc.
>
> OK to install?
On Sun, Jul 8, 2012 at 5:43 PM, Oleg Endo wrote:
> Hello,
>
> The recent change that removed the inclusion of tree.h in several places
> broke the SH target in one place in sh.md, where stuff from tree.h was
> used directly. I've moved those lines in question into a new function
> in sh.c.
I sup
Hello,
The recent change that removed the inclusion of tree.h in several places
broke the SH target in one place in sh.md, where stuff from tree.h was
used directly. I've moved those lines in question into a new function
in sh.c.
Tested with make all-gcc.
OK to install?
Cheers,
Oleg
ChangeLog:
19 matches
Mail list logo
