After -Werror is triggered, we are now emitting an extra blank line
that we were not emitting before. Was this change intentional? Does
anyone recognize this?
$ cat a.cc
char c = 257;
$ g++-4.4.3 -c -o /dev/null -Werror a.cc
cc1plus: warnings being treated as errors
a.cc:1: error: overflow in im
Mark Mitchell 写于 2011-03-02 07:20:46:
> Liqin --
>
> The GCC SC has appointed you the maintainer of the SCORE back-end.
>
* MAINTAINERS: Update myself as score backend maintainer, update my
e-mail address.
committed to trunk.
Thanks,
--liqin
Index: MAINTAINERS
On Tue, 15 Feb 2011, DJ Delorie wrote:
>
> pr45055 tests a scheduling fix, but on targets that don't support
> scheduling (like m32c-elf), gcc emits a warning that scheduling is not
> supported. This warning causes the test to fail. How do we bypass
> these types of test cases? I don't see a sui
Snapshot gcc-4.5-20110310 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110310/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> From: Eric Botcazou
> Date: Thu, 10 Mar 2011 18:42:14 +0100
> SPARC had exactly the same pattern as the 'U' constraint of MMIX. It now
> uses
> reload_in_progress || reload_completed instead (in memory_ok_for_ldd).
Nathan suggested that; great confirmation! Thanks.
brgds, H-P
> I haven't ran into that problem; all the targets I've converted to
> constraints.md haven't had constraints that changed based on strictness.
> I think the right thing to do is depend on
> reload_{in_progress,completed}
> (cf. rs6000/predicates.md:volatile_memory_operand), but I freely admit
> th
> Date: Thu, 10 Mar 2011 17:55:38 +0100
> From: Paolo Bonzini
> On 03/10/2011 04:47 PM, Nathan Froyd wrote:
> > [moving to gcc@ to get input from a wider audience]
> >
> > On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
> >>> From: Nathan Froyd
> >>> On Thu, Mar 10, 2011 at 04
> And I think the adjustments should not be done after the fact in
> finish_record_layout, but rather right in place_field, where also
> the fields alignment and mode are properly tracked.
It would be a lot harder to keep track of which bits are allocated and
which aren't if we do it in place_fie
On 03/10/2011 04:47 PM, Nathan Froyd wrote:
[moving to gcc@ to get input from a wider audience]
On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
From: Nathan Froyd
On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
PS. If you really feel for it, I won't stop
[moving to gcc@ to get input from a wider audience]
On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
> > From: Nathan Froyd
> > On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
> > > PS. If you really feel for it, I won't stop you converting MMIX. :)
> >
> >
Olivier Hainque wrote:
> do we still have a latent problem in this case ?
I believe we do. Here is a C testcase recreating one problematic
situation artificially
char mysym;
char * volatile g;
void foo (long x)
{
char volatile s [x];
register char * volatile
Hi,
On Wed, 9 Mar 2011, DJ Delorie wrote:
> To avoid having two completely independent definitions of the
> peripheral register structures, would it be acceptable to add a target
> hook to tell gcc to reverse the bitfields? This can be done in
> finish_record_layout() by adjusting bit offsets, b
12 matches
Mail list logo
