On 2/4/22 08:21, Thomas Schwinge wrote:
Hi Tom!
Taking this one to the mailing list; not directly related to PR104364:
On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs"
wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
I've tested this using (recommended) drive
Hi Tom!
Taking this one to the mailing list; not directly related to PR104364:
On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs"
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
> I've tested this using (recommended) driver 470.94 on boards:
(As not every user w
gt;> Columns"? The known-to-(work/fail) columns are available, i.e. this
> >> feature also works with custom fields.
> >
> > Yes, I'd be fine with that solution (thanks, for the reminder, I
> > should have mentioned that option in my initial mail).
> >
&g
ields.
>
> Yes, I'd be fine with that solution (thanks, for the reminder, I
> should have mentioned that option in my initial mail).
>
> If you reorder the "known to fail" column so it comes right before the
> Summary column you would get a clear list of regressions sh
il).
If you reorder the "known to fail" column so it comes right before the
Summary column you would get a clear list of regressions shown before
the rest of the summary (and nothing in that column for
non-regressions).
A possible downside is that would show all the branches the re
On Wed, 15 Dec 2021 at 12:15, Richard Earnshaw wrote:
>
>
>
> On 15/12/2021 11:39, Jonathan Wakely via Gcc wrote:
> > On IRC we've been discussing some changes to Bugzilla that would give
> > a bit more structure to how we label and process regressions.
> >
>
On 15.12.21 12:39, Jonathan Wakely via Gcc wrote:
Iain pointed out a drawback of not having the regression info in the
Summary. Currently it does draw your attention when looking at the
results of a bugzilla search. Andrew noted that bug aliases are
automatically added to the summary, e.g. https
On 15/12/2021 11:39, Jonathan Wakely via Gcc wrote:
On IRC we've been discussing some changes to Bugzilla that would give
a bit more structure to how we label and process regressions.
Currently we add something like "[9/10/11/12 Regression]" to the start
of the summary, and
On IRC we've been discussing some changes to Bugzilla that would give
a bit more structure to how we label and process regressions.
Currently we add something like "[9/10/11/12 Regression]" to the start
of the summary, and then edit that when it's fixed on a branch, when
f
there a reason why the Serious Regressions tables, displayed by
>> >> the links in the 'Release Series and Status' section at
>> >> https://gcc.gnu.org, no longer have a column for the priority
>> >> (importance) of each bug? We used to have that and it was quit
On Fri, Feb 13, 2015 at 03:31:22PM -0500, Jack Howarth wrote:
> On Fri, Feb 13, 2015 at 3:16 PM, Marek Polacek wrote:
> > On Fri, Feb 13, 2015 at 03:12:22PM -0500, Jack Howarth wrote:
> >> Is there a reason why the Serious Regressions tables, displayed by
> >> the l
On Fri, Feb 13, 2015 at 3:16 PM, Marek Polacek wrote:
> On Fri, Feb 13, 2015 at 03:12:22PM -0500, Jack Howarth wrote:
>> Is there a reason why the Serious Regressions tables, displayed by
>> the links in the 'Release Series and Status' section at
>> https:
On Fri, Feb 13, 2015 at 03:12:22PM -0500, Jack Howarth wrote:
> Is there a reason why the Serious Regressions tables, displayed by
> the links in the 'Release Series and Status' section at
> https://gcc.gnu.org, no longer have a column for the priority
> (importance) o
Is there a reason why the Serious Regressions tables, displayed by
the links in the 'Release Series and Status' section at
https://gcc.gnu.org, no longer have a column for the priority
(importance) of each bug? We used to have that and it was quite nice
to be able to click on th
Hi,
This patch fixes recent regressions in libgomp testsuite:
https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00343.html
They are reproducible only with ld from trunk, ld 2.24 works fine.
When GCC emits sections with offload IR, it should not emit "__gnu_lto_slim"
symbol, otherw
On 03/03/14 14:54, Richard Biener wrote:
> On Mon, Mar 3, 2014 at 1:53 PM, David Brown wrote:
>> On 03/03/14 11:49, Richard Biener wrote:
>>> On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
On 28/02/14 13:19, Richard Sandiford wrote:
> Georg-Johann Lay writes:
>> Notice that in
On Mon, Mar 3, 2014 at 1:53 PM, David Brown wrote:
> On 03/03/14 11:49, Richard Biener wrote:
>> On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
>>> On 28/02/14 13:19, Richard Sandiford wrote:
Georg-Johann Lay writes:
> Notice that in code1, func might contain such asm-pairs to impl
On 03/03/14 11:49, Richard Biener wrote:
> On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
>> On 28/02/14 13:19, Richard Sandiford wrote:
>>> Georg-Johann Lay writes:
Notice that in code1, func might contain such asm-pairs to implement
atomic operations, but moving costly_func acros
On Mon, Mar 3, 2014 at 11:41 AM, David Brown wrote:
> On 28/02/14 13:19, Richard Sandiford wrote:
>> Georg-Johann Lay writes:
>>> Notice that in code1, func might contain such asm-pairs to implement
>>> atomic operations, but moving costly_func across func does *not*
>>> affect the interrupt resp
On 28/02/14 13:19, Richard Sandiford wrote:
> Georg-Johann Lay writes:
>> Notice that in code1, func might contain such asm-pairs to implement
>> atomic operations, but moving costly_func across func does *not*
>> affect the interrupt respond times in such a disastrous way.
>>
>> Thus you must be
> But here too the point is that we don't assume the same thing at the
> tree level or during register allocation. It seems a bit silly for
> the scheduler to assume that all hard registers are clobbered when the
> register allocator itself doesn't assume that. And most rtl passes
> assume that c
Georg-Johann Lay writes:
> Notice that in code1, func might contain such asm-pairs to implement
> atomic operations, but moving costly_func across func does *not*
> affect the interrupt respond times in such a disastrous way.
>
> Thus you must be *very* careful w.r.t. optimizing against asm volati
Eric Botcazou writes:
>> One of the big grey areas is what should happen for floating-point ops
>> that depend on the current rounding mode. That isn't really modelled
>> properly yet though. Again, it affects calls as well as volatile asms.
>
> There is an explicit comment about this in the sch
On Fri, Feb 28, 2014 at 10:23 AM, Eric Botcazou wrote:
>> Of course if the GIMPLE level doesn't care about the barrier then it doesn't
>> make sense to be overly conservative at the RTL CSE level. Thus I think we
>> can just remove this barrier completely.
>
> Not clear to me, what happens e.g. f
> Of course if the GIMPLE level doesn't care about the barrier then it doesn't
> make sense to be overly conservative at the RTL CSE level. Thus I think we
> can just remove this barrier completely.
Not clear to me, what happens e.g. for register variables?
--
Eric Botcazou
Am 02/27/2014 06:03 PM, schrieb Richard Sandiford:
Yury Gribov writes:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
On Fri, Feb 28, 2014 at 9:51 AM, Eric Botcazou wrote:
>> So, the main question is not about triggering condition, but about the
>> behavior itself. Is it correct to flush and reload all constants ? They are
>> constants after all, they are even not stored in .data section but inlined
>> in the co
> So, the main question is not about triggering condition, but about the
> behavior itself. Is it correct to flush and reload all constants ? They are
> constants after all, they are even not stored in .data section but inlined
> in the code, and thus cannot be modified.
I'd think that everyone m
> I think part of the problem is that some parts of GCC (like the one you
> noted) are far more conservative than others. E.g. take:
>
> void foo (int x, int *y)
> {
> y[0] = x + 1;
> asm volatile ("# asm");
> y[1] = x + 1;
> }
>
> The extra-paranoid check you pointed out means
Hello!
> > This code (introduced in
> > http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193802) aborts
> > CSE after seeing a volatile inline asm.
>
> Note that "introduced" is not really correct here, the code had been
> there for a long time but it was treating some volatile asms as
> ba
> asm volatile + memory clobber should be the last resort barrier, if you skip
> this out of the compiler or change its semantics (pinned by the current
> documentation) at will, it's not unlikely you break existing code in favour
> or saving some poor instructions.
Problem is that there is no cur
Yury Gribov schrieb:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting point
Hi,
On Thu, 27 Feb 2014, Richard Sandiford wrote:
> [... many cases where 'volatile' in asm doesn't inhibit optimizations
> ...]
>
> We do nothing this draconian for a normal function call, which could
> easily use a volatile asm internally. IMO anything that isn't flushed
> for a call shouldn
On 27/02/14 16:36, Yury Gribov wrote:
> Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
>
Yury Gribov writes:
> Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
>>>
>>> That could
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting point though.
Though with
On Thu, Feb 27, 2014 at 4:02 PM, Eric Botcazou wrote:
>> After some investigation, we discovered that this behavior is caused by
>> big hammer in gcc/cse.c:
>> /* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */
>> if (NONJUMP_INSN_P (insn)
>> && volatile_insn_p (PA
> After some investigation, we discovered that this behavior is caused by
> big hammer in gcc/cse.c:
> /* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */
> if (NONJUMP_INSN_P (insn)
> && volatile_insn_p (PATTERN (insn)))
> flush_hash_table ();
> This code (int
Hi all,
We have recently ran into a performance/code size regression on ARM
targets after transition from GCC 4.7 to GCC 4.8 (this regression is
also present in 4.9).
The following code snippet uses Linux-style compiler barriers to protect
memory writes:
#define barrier() __asm__ __volat
> >>
> > >> sorry it the issue is by now well known but... I see many libstdc++-v3
> > >> regressions on at least x86_64-linux. When running the libstdc++-v3
> > >> testsuite (which uses PCHs) one gets tons of new fails like the below.
> > >> T
On Tue, 2013-08-20 at 17:02 +0200, Paolo Carlini wrote:
> Hi,
>
> On 08/20/2013 04:41 PM, David Malcolm wrote:
> > On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote:
> >> Hi,
> >>
> >> sorry it the issue is by now well known but... I see many libstd
On Tue, 2013-08-20 at 10:41 -0400, David Malcolm wrote:
> On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote:
> > Hi,
> >
> > sorry it the issue is by now well known but... I see many libstdc++-v3
> > regressions on at least x86_64-linux. When running the libstdc
Hi,
On 08/20/2013 04:41 PM, David Malcolm wrote:
On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote:
Hi,
sorry it the issue is by now well known but... I see many libstdc++-v3
regressions on at least x86_64-linux. When running the libstdc++-v3
testsuite (which uses PCHs) one gets tons of
On Tue, 2013-08-20 at 14:03 +0200, Paolo Carlini wrote:
> Hi,
>
> sorry it the issue is by now well known but... I see many libstdc++-v3
> regressions on at least x86_64-linux. When running the libstdc++-v3
> testsuite (which uses PCHs) one gets tons of new fails like the b
Hi Paolo,
> sorry it the issue is by now well known but... I see many libstdc++-v3
> regressions on at least x86_64-linux. When running the libstdc++-v3
> testsuite (which uses PCHs) one gets tons of new fails like the
> below. That's annoying, a lot of confusing noise.
Hi,
sorry it the issue is by now well known but... I see many libstdc++-v3
regressions on at least x86_64-linux. When running the libstdc++-v3
testsuite (which uses PCHs) one gets tons of new fails like the below.
That's annoying, a lot of confusing noise.
Thanks!
Paolo.
PS: CC-in
Alexander Pyhalov writes:
> While building different c++ projects with gcc 4.7 on OpenIndiana I've
> faced several problems with Solaris standard headers (including stdlib.h,
> iso/stdlib_iso.h, iso/stdio_iso.h and other)
>
> https://www.illumos.org/issues/3787
>
> The prolem was introduced by fi
Hello.
While building different c++ projects with gcc 4.7 on OpenIndiana I've
faced several problems with Solaris standard headers (including
stdlib.h, iso/stdlib_iso.h, iso/stdio_iso.h and other)
https://www.illumos.org/issues/3787
The prolem was introduced by fixing
http://gcc.gnu.org/bugz
regressions
by introducing dependencies,
hurting cprop_hardreg pass.
Take below code as an example:
typedef struct
{
double X, Y;
} Point;
typedef struct
{
Point p1;
Point c1;
Point c2;
Point p2;
} Curve;
double bar(double t, double p0, double p1, double p2, double p3);
void foo
On 07/29/2011 12:13 PM, Vladimir Makarov wrote:
On 07/27/2011 05:59 PM, Sandra Loosemore wrote:
[snip]
So, here's my question. Is it worthwhile for me to continue this
approach of trying to make the MIPS backend smarter? Or is the way IRA
deals with CANNOT_CHANGE_MODE_CLASS fundamentally broke
On 07/27/2011 05:59 PM, Sandra Loosemore wrote:
Consider this bit of code:
extern double a[20];
double test1 (int n)
{
double accum = 0.0;
int i;
for (i=0; imipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops
-march=74kf1_1 -S abstest.c
With a GCC 4.6 compiler, this produces:
..
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/28/11 08:33, Sandra Loosemore wrote:
>
> I picked up when trying to analyze this problem, that seems scarier than
> just fixing it in the MIPS backend, but certainly not as scary as adding
> stuff to split live ranges to IRA. :-)
Splitting liv
On 07/28/2011 02:11 AM, Richard Guenther wrote:
On Wed, Jul 27, 2011 at 11:59 PM, Sandra Loosemore
wrote:
[snip]
So, here's my question. Is it worthwhile for me to continue this approach
of trying to make the MIPS backend smarter? Or is the way IRA deals with
CANNOT_CHANGE_MODE_CLASS fundam
On Wed, Jul 27, 2011 at 11:59 PM, Sandra Loosemore
wrote:
> Consider this bit of code:
>
> extern double a[20];
>
> double test1 (int n)
> {
> double accum = 0.0;
> int i;
>
> for (i=0; i accum = fabs (accum);
> return accum;
> }
>
> which is compiled for MIPS using
>
> mipsisa32r2-sde-elf-gc
Consider this bit of code:
extern double a[20];
double test1 (int n)
{
double accum = 0.0;
int i;
for (i=0; imipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops -march=74kf1_1
-S abstest.c
With a GCC 4.6 compiler, this produces:
...
.L3:
mtc1$3,$f2
ldc1$f0
On Thu, Feb 10, 2011 at 3:13 AM, Jonathan Wakely wrote:
> On 10 February 2011 05:18, Quentin Neill wrote:
>> On Wed, Feb 9, 2011 at 2:42 AM, Jonathan Wakely
>> wrote:
>>> On 9 February 2011 08:34, Sebastian Pop wrote:
For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
>>
On 10 February 2011 05:18, Quentin Neill wrote:
> On Wed, Feb 9, 2011 at 2:42 AM, Jonathan Wakely wrote:
>> On 9 February 2011 08:34, Sebastian Pop wrote:
>>>
>>> For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
>>> building this benchmark with CFLAGS="-O2" would have no effect.
>
On Wed, Feb 9, 2011 at 2:42 AM, Jonathan Wakely wrote:
> On 9 February 2011 08:34, Sebastian Pop wrote:
>>
>> For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
>> building this benchmark with CFLAGS="-O2" would have no effect.
>
> Why not?
>
> Ignoring the fact -O3 is the highest l
performance boost I was hoping for).
I had been trying for the last few weeks to strip down my application
into a mini-benchmark I could create a PR out of, however it is
tougher than expected and was hoping the Phoronix article was going to
offer a quicker route to finding performance regressio
had been trying for the last few weeks to strip down my application
> into a mini-benchmark I could create a PR out of, however it is
> tougher than expected and was hoping the Phoronix article was going to
> offer a quicker route to finding performance regressions than my code
> - as thei
On Wed, Feb 09, 2011 at 08:42:05AM +, Jonathan Wakely wrote:
> On 9 February 2011 08:34, Sebastian Pop wrote:
> >
> > For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
> > building this benchmark with CFLAGS="-O2" would have no effect.
>
> Why not?
>
> Ignoring the fact -O3 is
On 9 February 2011 08:34, Sebastian Pop wrote:
>
> For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
> building this benchmark with CFLAGS="-O2" would have no effect.
Why not?
Ignoring the fact -O3 is the highest level for GCC, the manual says:
"If you use multiple -O options, wit
een trying for the last few weeks to strip down my application
> into a mini-benchmark I could create a PR out of, however it is
> tougher than expected and was hoping the Phoronix article was going to
> offer a quicker route to finding performance regressions than my code
> - as thei
On 9 February 2011 06:20, Tony Poppleton wrote:
>
> Out of interest, has their been much communication in the past between
> GCC and Phoronix to address any of these issues in their previous
> benchmarks?
I signed up to their forum to point out that snapshots have additional
checking turned on by
te a PR out of, however it is
tougher than expected and was hoping the Phoronix article was going to
offer a quicker route to finding performance regressions than my code
- as their coverage was a lot wider. Anyway, apparently this is not
the case, so back to my original work...
Would it not be in the
Jonathan Wakely writes:
>> Because phoronix uses make -j the compile times are highly random.
>
> Don't they know how to use 'time' to measure something more useful?
> I wouldn't be entirely surprised, last time I looked they didn't seem
> to know to use --enable-checking=release when comparing co
On 8 February 2011 22:49, Sebastian Pop wrote:
>
> Because phoronix uses make -j the compile times are highly random.
Don't they know how to use 'time' to measure something more useful?
I wouldn't be entirely surprised, last time I looked they didn't seem
to know to use --enable-checking=release w
On Tue, Feb 8, 2011 at 16:14, Xinliang David Li wrote:
> What are the base option set used in all the comparison? O2, O3? Some
The flags are those set by the Makefiles of the different benchmarks
(as downloaded from the web).
Setting different flags with CFLAGS=... is painful.
> of the build t
there are also some performance
> regressions, some of which are fairly significant.
>
> I have a few questions regarding these regressions;
> 1. Can any of these results be logged as 4.6 regressions in bugzilla,
> or are they too general as they stand to be of any use to anyone?
> 2. I
's) RTEMS build farm. :)
Well, I did manage to trigger a couple regressions on the sparc native
build using the farm, so I'll focus on those first and hope they're the
root cause of the rtems issue. Once I've got something for you to spin,
I'll pass it along.
jeff
-BEGIN PGP S
ge=article&item=intel_avx_gcc&num=1
>
> There are some great results for 4.6.0 in there, which is very good
> news (congratulations!). However there are also some performance
> regressions, some of which are fairly significant.
>
> I have a few questions regarding these regr
ood
news (congratulations!). However there are also some performance
regressions, some of which are fairly significant.
I have a few questions regarding these regressions;
1. Can any of these results be logged as 4.6 regressions in bugzilla,
or are they too general as they stand to be of any use to anyon
On 02/08/2011 09:34 AM, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/11 12:47, Joel Sherrill wrote:
On 02/07/2011 01:46 PM, Jeff Law wrote:
On 02/07/11 11:51, Joel Sherrill wrote:
On 02/07/2011 09:32 AM, Jeff Law wrote:
On 02/02/11 07:19, Joel Sherrill wrote:
Hi,
In
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/11 12:47, Joel Sherrill wrote:
> On 02/07/2011 01:46 PM, Jeff Law wrote:
> On 02/07/11 11:51, Joel Sherrill wrote:
On 02/07/2011 09:32 AM, Jeff Law wrote:
On 02/02/11 07:19, Joel Sherrill wrote:
>>> Hi,
>>>
>>> In the pas
On 02/07/2011 01:46 PM, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/11 11:51, Joel Sherrill wrote:
On 02/07/2011 09:32 AM, Jeff Law wrote:
On 02/02/11 07:19, Joel Sherrill wrote:
Hi,
In the past few days, something has regressed
on the sparc. Revision 169143 only ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/11 11:51, Joel Sherrill wrote:
> On 02/07/2011 09:32 AM, Jeff Law wrote:
> On 02/02/11 07:19, Joel Sherrill wrote:
Hi,
In the past few days, something has regressed
on the sparc. Revision 169143 only had 699 failures
a
On 02/07/2011 09:32 AM, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/11 07:19, Joel Sherrill wrote:
Hi,
In the past few days, something has regressed
on the sparc. Revision 169143 only had 699 failures
and ~100 of those were LTO related. David Korn's
patch seems to h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/11 07:19, Joel Sherrill wrote:
> Hi,
>
> In the past few days, something has regressed
> on the sparc. Revision 169143 only had 699 failures
> and ~100 of those were LTO related. David Korn's
> patch seems to have resolved those. Revision 16
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/11 07:19, Joel Sherrill wrote:
> Hi,
>
> In the past few days, something has regressed
> on the sparc. Revision 169143 only had 699 failures
> and ~100 of those were LTO related. David Korn's
> patch seems to have resolved those. Revision 16
Hi,
In the past few days, something has regressed
on the sparc. Revision 169143 only had 699 failures
and ~100 of those were LTO related. David Korn's
patch seems to have resolved those. Revision 169504
has 2231 failures.
http://www.rtems.org/pipermail/rtems-tooltestresults/2011-January/000407.
David Miller wrote:
> You said you would fix this several nights ago, but I still
> haven't seen any changes to fixincludes since then.
>
> When will you get around to fixing these regressions you
> introduced?
>
> Thank you.
Done. Terribly sorry for the delay. I b
You said you would fix this several nights ago, but I still
haven't seen any changes to fixincludes since then.
When will you get around to fixing these regressions you
introduced?
Thank you.
The intent was to clear up some stuff in the README.
When I noticed that I had affected other files, I had tried to put
everything back. Obviously a glitch. I'll fix it when I get home
tonight.
On Mon, Mar 15, 2010 at 11:00 PM, David Miller wrote:
>
> Ever since your changes installed on March
Ever since your changes installed on March 12th, I've been getting
fixincludes testsuite failures of the form below.
I also notice that none of these changes added ChangeLog entries, and
furthermore the SVN commit messages were extremely terse so it was
hard to diagnose the intent or reasoning be
Joern Rennecke writes:
> Quoting Ian Lance Taylor :
>
>> I'm not surprised that plugins don't work
>
> For Milepost we need both the --enable-build-with-cxx configure option
> and plugins.
> How is this supposed to work?
> Should the person compiling the plugins use C++ to compile the plugin?
> O
Quoting Ian Lance Taylor :
I'm not surprised that plugins don't work
For Milepost we need both the --enable-build-with-cxx configure option
and plugins.
How is this supposed to work?
Should the person compiling the plugins use C++ to compile the plugin?
Or should the cc1 / cc1plus dso export u
Joern Rennecke writes:
> I've tested mainline r156055 with the patch for PR42798 both
> with and without --enable-build-with-cxx; a number of testsuites
> show additional failures for --enable-build-with-cxx.
>
> I've attached simple diffs from the gcc to g++ bootstrap regtest
> summaries.
>
> Di
I've tested mainline r156055 with the patch for PR42798 both
with and without --enable-build-with-cxx; a number of testsuites
show additional failures for --enable-build-with-cxx.
I've attached simple diffs from the gcc to g++ bootstrap regtest
summaries.
Did this ever work properly?
i686-pc-lin
Hi,
I have re-run GNAT/RTEMS on a number of targets
for 4.3.4, 4.4.1 and the SVN head. I kept the
binutils, gdb, newlib and RTEMS the same. The SVN head
has a lot of new failures for SPARC, MIPS, and x86.
The SPARC and MIPS have the same number of failures
(319) so I assume the same underlying
On Sun, 5 Apr 2009, Laurent GUERBY wrote:
>>> I'm thinking of changing my auto tester to report a broken bootstrap
>>> (the first time a bootstrap fails), is there a normalized way to
>> report such failures to gcc-testresults@ or g...@?
>> I report it to gcc-regress...@.
> It's documented by http:
On Sat, Jun 13, 2009 at 08:14:36PM -0700, Steve Kargl wrote:
> Someone has broken gfortran on FreeBSD with dwarf debugging.
> This is a regression. Please fix!
I just wrote a patch to fix this:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01097.html
--
Michael Meissner, IBM
4 Technology Place D
Someone has broken gfortran on FreeBSD with dwarf debugging.
This is a regression. Please fix!
Testing debug/trivial.f, -gdwarf-21
Executing on host: /usr/home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../gfortr
an -B/usr/home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../ /usr/home/kargl/gcc
/gcc
On Sun, 2009-04-05 at 08:25 -0700, H.J. Lu wrote:
> On Sun, Apr 5, 2009 at 2:25 AM, Laurent GUERBY wrote:
> > I'm thinking of changing my auto tester to report a broken bootstrap
> > (the first time a bootstrap fails), is there a normalized way to
> > report such failures to gcc-testresults@ or g
On Jan 21, 2009, at 3:43 PM, Jack Howarth wrote:
So that invalidates your previously proposed patch? Or should I
still test it?
No need to test, I was wrong about that being the bit that causes it.
The description I last posted should be about right however, one just
needs a bit of time i
On Wed, Jan 21, 2009 at 11:59:09AM -0800, Mike Stump wrote:
> On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote:
>>> Sure, in i386/darwin.h we have:
>>>
>>> /* Since we'll never want a stack boundary less aligned than 128 bits
>>> we need the extra work here otherwise bits of gcc get very grumpy
>>>
On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote:
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values less
than 12
On Jan 21, 2009, at 11:40 AM, Uros Bizjak wrote:
Hello!
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values le
Hello!
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values less
than 128 bits for Darwin, but it's easier to
On Jan 20, 2009, at 11:22 PM, Jack Howarth wrote:
Are there any observations that you could make concerning
the thread...
http://gcc.gnu.org/ml/gcc/2009-01/msg00297.html
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extr
On Tue, Jan 20, 2009 at 6:21 PM, Jack Howarth wrote:
> On Tue, Jan 20, 2009 at 05:50:35PM -0800, H.J. Lu wrote:
>> On Tue, Jan 20, 2009 at 3:29 PM, Jack Howarth
>> wrote:
>> > Currently i686-apple-darwin9 appears in very good shape for
>> > gcc 4.4 with the exception of one new set of testsuite
1 - 100 of 301 matches
Mail list logo
