This tidies endian selection. Prior to this change, if you gave a
little-endian gcc the -mcall-aixdesc option, gcc would operate
big-endian but the assembler in little-endian. Which was confusing to
say the least.
The sysv4.h changes below don't actually make any substantive changes
in the spec
Hi Iain!
Joseph pointed out that I didn't include you, the libgcc and fp-bit
maintainer, in my mails' recipient lists. I'm waiting for approval for
the following changes:
On Mon, 22 Apr 2013 11:52:23 +0200, I wrote:
> On Fri, 5 Apr 2013 23:55:37 +0100, "Maciej W. Rozycki"
> wrote:
> > On Fri,
On 05/04/2013 06:30 PM, Steve Kargl wrote:
> On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
>>
>> CASE_SEPARATORS:/* Not a repeat count. */
>> case EOF:
>> +case '!':
>
> if (c == '!')
> gfc_warning("GNU Fortran extension: accepting a possibl
This fixes a couple more little-endian bugs. bswapdi stores when
!TARGET_LDBRX were being split to two bswapsi but written to the wrong
words because we word swapped twice. ashrdi3 resulted in a libcall.
I think I have ashrdi3_no_power correct. For LE, the first reg of a
register pair is the lo
On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
>
> CASE_SEPARATORS:/* Not a repeat count. */
> case EOF:
> + case '!':
if (c == '!')
gfc_warning("GNU Fortran extension: accepting a possibly "
"corrupted namelist");
>
On 05/04/2013 05:13 PM, Jerry DeLisle wrote:
> The attached patch resolves this PR by treating '!', the Fortran comment mark,
> as a valid separator between values. Thus, when encountered while reading a
> value, the read is ended normally with whatever value was encountered. This
> is
> an exte
The attached patch resolves this PR by treating '!', the Fortran comment mark,
as a valid separator between values. Thus, when encountered while reading a
value, the read is ended normally with whatever value was encountered. This is
an extension beyond the Standards which require a separator bef
OK.
Jason
"Joseph S. Myers" writes:
> On Tue, 30 Apr 2013, Rainer Orth wrote:
>
>> * gcc.c (LINK_COMPRESS_DEBUG_SPEC, ASM_COMPRESS_DEBUG_SPEC):
>> Define.
>> (LINK_COMMAND_SPEC): Invoke LINK_COMPRESS_DEBUG_SPEC.
>> (asm_options): Invoke ASM_COMPRESS_DEBUG_SPEC.
>
> Note that there are s
David Edelsohn wrote:
All uses of "value" are protected by
#if defined HAVE_GFC_REAL_16 || defined HAVE_GFC_REAL_10
so it may be unused, which generates a warning on some platforms.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
* io/read.c (si_max): Annotate value with attribu
David Edelsohn wrote:
environ.c is referencing functions like getuid(), geteuid(), getgid()
and getegid(), but it does not include the header file that declares
them.
I also noticed that libgfortran is not consistent about checking that
unistd.h exists.
You can add io/unix.c and io/open.c to t
All uses of "value" are protected by
#if defined HAVE_GFC_REAL_16 || defined HAVE_GFC_REAL_10
so it may be unused, which generates a warning on some platforms.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
Thanks, David
* io/read.c (si_max): Annotate value with attribute unu
environ.c is referencing functions like getuid(), geteuid(), getgid()
and getegid(), but it does not include the header file that declares
them.
I also noticed that libgfortran is not consistent about checking that
unistd.h exists.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
Thanks,
The revised version of hash_pointer() produces warnings when compiled
on a 32 bit host because it shift a 32 bit variable by 32 bits.
+ intptr_t v = (intptr_t)p;
...
+ b += v & 0x;
The code is not executed when intptr_t is 32 bits, but it still is
present in the function, causing a
On Sat, May 4, 2013 at 2:37 PM, Segher Boessenkool
wrote:
> It's just INTVAL now, which is shorter and clearer.
>
> Bootstrapped and tested on powerpc64-linux --enable-languages=c,c++,fortran
> --disable-libsanitizer, -m64,-m32,-m32/-mpowerpc64, no regressions. Okay
> to apply?
>
>
> gcc/
> 2013-
On Sat, May 4, 2013 at 2:37 PM, Segher Boessenkool
wrote:
> We always have HOST_BITS_PER_WIDE_INT >= 64, so remove the code testing
> for == 32, and remove the tests testing for >= 64. Also remove the tests
> testing for == 64 that should really have been testing for >= 64.
>
> DImode constants a
It's just INTVAL now, which is shorter and clearer.
Bootstrapped and tested on powerpc64-linux --enable-languages=c,c++,fortran
--disable-libsanitizer, -m64,-m32,-m32/-mpowerpc64, no regressions. Okay
to apply?
gcc/
2013-05-04 Segher Boessenkool
* config/rs6000/rs6000.c (INT_LOWPART
We always have HOST_BITS_PER_WIDE_INT >= 64, so remove the code testing
for == 32, and remove the tests testing for >= 64. Also remove the tests
testing for == 64 that should really have been testing for >= 64.
DImode constants are always CONST_INT, never CONST_DOUBLE. Simplify the
old code that
Hi!
Segher reported on IRC that stdarg-6.c testcase leaves *.stdarg files behind
it. Fixed thusly, committed to trunk/4.8 as obvious.
2013-05-04 Jakub Jelinek
PR tree-optimization/56205
* gcc.dg/tree-ssa/stdarg-6.c: Add cleanup-tree-dump "stdarg".
--- gcc/testsuite/gcc.dg/tr
Hi Tobias,
TS29113 permits the allocatable/pointer attribute with BIND(C); this
patch allows it now with -std=f2008ts.
Build and regtested on x86-84-gnu-linux.
OK for the trunk?
OK. Thanks for the patch!
Thomas
Compiling libgconv.c with gthr-single.h current generates warnings
because __GTHREAD_MUTEX_INIT_FUNCTION may be empty. The following
patch avoids the warnings.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
Okay for trunk?
Thanks, David
* libgcov.c (__gcov_fork): Add ATTRIBUTE_UNUSED to __gco
Hi!
Ping.
On Mon, 29 Apr 2013 10:16:52 +0200, I wrote:
> Ping.
>
> On Mon, 22 Apr 2013 11:52:23 +0200, I wrote:
> > On Fri, 5 Apr 2013 23:55:37 +0100, "Maciej W. Rozycki"
> > wrote:
> > > On Fri, 5 Apr 2013, Thomas Schwinge wrote:
> > > > > Index: gcc/config/fp-bit.c
> > > > >
Hi,
in this issue (and its duplicate) the complain is that for cases like:
enum E : unsigned { e = -1 };
saying in the error message that the enumerator is *too large* can be
rather misleading. It seems to me that replacing that with "... outside
the range..." (we already use this form in at
Hi,
This is another version of my old patch, changed to use target hooks as
requested by Steven Bosscher.
Tested on i686-w64-mingw32, x86_64-w64-mingw32 and
x86_64-unknown-linux-gnu, bootstrapped on x86_64-unknown-linux-gnu.
Disclaimer: the patch is in public domain.
(because I don't have
Hi,
committed to mainline.
Thanks,
Paolo.
//
2013-05-04 Paolo Carlini
PR c++/51927
* g++.dg/cpp0x/lambda/lambda-nsdmi4.C: New.
Index: g++.dg/cpp0x/lambda/lambda-nsdmi4.C
===
--- g++.dg/cpp0x/lam
On Sat, May 04, 2013 at 12:31:31PM +0200, Eric Botcazou wrote:
> > Good to hear. I wasn't sure whether the sizes were even supposed to
> > agree. Assuming Jakub's second patch fixes java for us (testing now),
> > that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> > size a3 and a
On Sat, May 04, 2013 at 09:20:24AM +0200, Jakub Jelinek wrote:
> 2013-05-04 Jakub Jelinek
>
> PR libgcj/57074
> * class.c (emit_symbol_table): Use array type of the
> right size for the_syms_decl and its DECL_INITIAL, instead
> of symbols_array_type. Set TREE_TYPE (the_
> Good to hear. I wasn't sure whether the sizes were even supposed to
> agree. Assuming Jakub's second patch fixes java for us (testing now),
> that just leaves gcc.c-torture/execute/20010924-1.c which fails to
> size a3 and a4 properly. Both of these vars have DECL_SIZE_UNIT of 1.
>
> struct {
On Sat, May 04, 2013 at 10:34:52AM +0200, Eric Botcazou wrote:
> > I believe the real problem here is in place_block_symbol() and
> > output_object_block(). If DECL_INITIAL is given for an array, then
> > shouldn't we be taking the size from the initializer?
>
> This means that the size of the ar
Latest results for gcc 4.6.x.
-tgc
Testresults for 4.6.4
i386-pc-solaris2.8
powerpc-apple-darwin8.11.0
sparc-sun-solaris2.9
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v
retrieving revisi
Latest results for gcc 4.7.x.
-tgc
Testresults for 4.7.3
arm-unknown-linux-gnueabi
i386-pc-solaris2.8
i686-pc-linux-gnu (2)
mips-sgi-irix6.5
powerpc-apple-darwin8.11.0
sparc-sun-solaris2.9
Index: buildstat.html
===
RCS f
Latest results for gcc 4.8.x.
-tgc
Testresults for 4.8.0
hppa64-hp-hpux11.00
i686-pc-linux-gnu
powerpc-apple-darwin8.11.0
powerpc-ibm-aix6.1.0.0
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.h
Steve Ellcey writes:
> On Thu, 2013-05-02 at 23:26 +0100, Richard Sandiford wrote:
>> > 2013-05-02 Steve Ellcey
>> >
>> >* config/mips/mips.c (mips_promote_prototypes) :New.
>> >(TARGET_PROMOTE_PROTOTYPES): Change to use mips_promote_prototypes.
>> >* config/mips/mips.opt (mpromote-
Hi Tobias,
Instead of using the return "size" value directly, the code converted it
first to an int and then back into a GMP number. This patch now directly
uses the mpz value.
Additionally, I added range checks - to print the proper function name
(SHAPE instead of SIZE), I split the worker cod
Jakub Jelinek writes:
> On Thu, May 02, 2013 at 06:53:31PM +0100, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > When working on PR57130, I've wondered why we don't simplify it much
>> > earlier
>> > and end up with creating such weirdness.
>> >
>> > The following patch fixes that, by us
> I believe the real problem here is in place_block_symbol() and
> output_object_block(). If DECL_INITIAL is given for an array, then
> shouldn't we be taking the size from the initializer?
This means that the size of the array and the size of the initializer don't
agree, right? IMO this should
On Sat, May 04, 2013 at 09:33:34AM +0930, Alan Modra wrote:
> On Fri, May 03, 2013 at 07:10:15PM +0200, Jakub Jelinek wrote:
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, but
> > not tested on powerpc32 where it actually caused runtime issues, can
> > somebody please try
37 matches
Mail list logo
