On Mar 22, 2013, at 6:36 PM, "Iyer, Balaji V" wrote:
> I can confirm that renaming scripts to something unique fixed the issue.
That's what others have said, I've not see it first hand.
BOOL_BITFIELD isn't defined when building libgcc. I checked in this
patch to restore GCC 4.7 bootstrap on x86. GCC 4.6 is OK.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 196998)
+++ ChangeLog (working copy)
@@ -1,5 +1
On 03/22/2013 06:44 PM, Steven Bosscher wrote:
On Fri, Mar 22, 2013 at 8:09 PM, Steven Bosscher wrote:
Hello,
This is an almost completely mechanical replacement of GET_CODE(thing)
== ... with the equivalent predicate macro from rtl.h. This particular
set of files fell victim to my plans for GC
From: gcc-patches-ow...@gcc.gnu.org [gcc-patches-ow...@gcc.gnu.org] on behalf
of Mike Stump [m...@mrs.kithrup.com]
Sent: Friday, March 22, 2013 6:36 PM
To: Aldy Hernandez
Cc: Jakub Jelinek; Jeff Law; Joseph S. Myers; Iyer, Balaji V; gcc-patches
Subject: Re
On 23/03/2013 00:57, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 23/03/2013 00:24, Kai Tietz wrote:
>>> 2013/3/23 Dave Korn :
On 23/03/2013 00:16, Kai Tietz wrote:
> welcome, too. It would be even better if we could rethink actual the
> need of loading java-library within libg
On 23/03/2013 00:41, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 22/03/2013 09:56, Kai Tietz wrote:
>>> Hi,
>>>
>>> this patch adds required configure changes for new cygwin x64 target.
>>> Index: gcc/configure.ac
>>> ===
>>> --- gc
2013/3/23 Dave Korn :
> On 23/03/2013 00:24, Kai Tietz wrote:
>> 2013/3/23 Dave Korn :
>>> On 23/03/2013 00:16, Kai Tietz wrote:
>>>
welcome, too. It would be even better if we could rethink actual the
need of loading java-library within libgcc's cygwin's/mingw's crtbegin
at all. I
On Fri, Mar 22, 2013 at 8:09 PM, Steven Bosscher wrote:
> Hello,
>
> This is an almost completely mechanical replacement of GET_CODE(thing)
> == ... with the equivalent predicate macro from rtl.h. This particular
> set of files fell victim to my plans for GCC 4.9 to make
> JUMP_TABLE_DATA_P a separ
2013/3/23 Dave Korn :
> On 22/03/2013 09:56, Kai Tietz wrote:
>> Hi,
>>
>> this patch adds required configure changes for new cygwin x64 target.
>
>> Index: gcc/configure.ac
>> ===
>> --- gcc/configure.ac (Revision 196898)
>> +++ gcc/
On 23/03/2013 00:27, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 23/03/2013 00:08, Kai Tietz wrote:
>>> 2013/3/23 Dave Korn :
Also, can you explain the motivation for this change? I don't see how
it's
going to work right; from what I remember, we don't have weak definitions
>
On 23/03/2013 00:24, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> On 23/03/2013 00:16, Kai Tietz wrote:
>>
>>> welcome, too. It would be even better if we could rethink actual the
>>> need of loading java-library within libgcc's cygwin's/mingw's crtbegin
>>> at all. I am actual not that sure, if w
2013/3/23 Dave Korn :
> On 23/03/2013 00:08, Kai Tietz wrote:
>> 2013/3/23 Dave Korn :
>
>>> Also, can you explain the motivation for this change? I don't see how
>>> it's
>>> going to work right; from what I remember, we don't have weak definitions in
>>> PE-COFF, just weak references. How do
On 22/03/2013 09:56, Kai Tietz wrote:
> Hi,
>
> this patch adds required configure changes for new cygwin x64 target.
> Index: gcc/configure.ac
> ===
> --- gcc/configure.ac (Revision 196898)
> +++ gcc/configure.ac (Arbeitskopie)
>
2013/3/23 Dave Korn :
> On 23/03/2013 00:16, Kai Tietz wrote:
>
>> welcome, too. It would be even better if we could rethink actual the
>> need of loading java-library within libgcc's cygwin's/mingw's crtbegin
>> at all. I am actual not that sure, if we need this at all.
>
>
> Somebody has to r
On 23/03/2013 00:16, Kai Tietz wrote:
> welcome, too. It would be even better if we could rethink actual the
> need of loading java-library within libgcc's cygwin's/mingw's crtbegin
> at all. I am actual not that sure, if we need this at all.
Somebody has to register the default classes at s
2013/3/23 Dave Korn :
> On 22/03/2013 09:00, Kai Tietz wrote:
>
>> (CXX_WRAP_SPEC_LIST): Undefine before define.
>
>> @@ -73,6 +82,7 @@
>>
>> /* To implement C++ function replacement we always wrap the cxx
>> malloc-like operators. See N2800 #17.6.4.6 [replacement.functions] */
>> +#und
On 23/03/2013 00:08, Kai Tietz wrote:
> 2013/3/23 Dave Korn :
>> Also, can you explain the motivation for this change? I don't see how it's
>> going to work right; from what I remember, we don't have weak definitions in
>> PE-COFF, just weak references. How does the correct definition get chos
2013/3/23 Dave Korn :
> On 22/03/2013 09:00, Kai Tietz wrote:
>
>> (LIBGCJ_SONAME): Make name minor-build-version dependent.
>>
>> Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please
>> especially a look to LIBGCJ_SONAME change. I think we should include
>> MAJOR_VERSION here, too.
On 22/03/2013 09:00, Kai Tietz wrote:
> (CXX_WRAP_SPEC_LIST): Undefine before define.
> @@ -73,6 +82,7 @@
>
> /* To implement C++ function replacement we always wrap the cxx
> malloc-like operators. See N2800 #17.6.4.6 [replacement.functions] */
> +#undef CXX_WRAP_SPEC_LIST
> #defin
2013/3/23 Dave Korn :
> On 22/03/2013 08:44, Kai Tietz wrote:
>> Hi,
>>
>> this change is actual used by cygwin and is required for upcoming x64
>> cygwin target.
>>
>> ChangeLog
>>
>> 2013-03-22 Kai Tietz
>>
>> * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
>>
On 22/03/2013 09:00, Kai Tietz wrote:
> (LIBGCJ_SONAME): Make name minor-build-version dependent.
>
> Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please
> especially a look to LIBGCJ_SONAME change. I think we should include
> MAJOR_VERSION here, too. Ok for apply?
I'm not sur
On 22/03/2013 08:44, Kai Tietz wrote:
> Hi,
>
> this change is actual used by cygwin and is required for upcoming x64
> cygwin target.
>
> ChangeLog
>
> 2013-03-22 Kai Tietz
>
> * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
> (__deregister_frame_info): Like
While testing GCC on a 74k MIPS chip I noticed that by default the -mtune=74k*
flags cause GCC to not use the integer madd/msub instructions. According to
the checkin comments these were found to cause a performance hit over using
individual mult and add/sub instructions. I think there are some p
ok.
David
On Fri, Mar 22, 2013 at 3:58 PM, Dehao Chen wrote:
> forgot to attach the patch...
>
> Index: gcc/ipa-prop.c
> ===
> --- gcc/ipa-prop.c (revision 196984)
> +++ gcc/ipa-prop.c (working copy)
> @@ -2473,7 +2473,6 @@
>bas
On Mar 21, 2013, at 7:08 AM, Sebastian Huber
wrote:
> This patch should be applied to GCC 4.8 and 4.9.
Ok for trunk.
Ok for 4.8.1. 4.8.0 would require RM approval I think.
forgot to attach the patch...
Index: gcc/ipa-prop.c
===
--- gcc/ipa-prop.c (revision 196984)
+++ gcc/ipa-prop.c (working copy)
@@ -2473,7 +2473,6 @@
base = gimple_call_arg (stmt, adj->base_index);
loc = DECL_P (base) ? DECL_SOUR
Hi,
This patch fixes the error in r193861, which backported r193857 from trunk.
Bootstrapped and passed all gcc regression tests.
Is it okay for google-4_7?
Thanks,
Dehao
On Mar 21, 2013, at 4:33 PM, Aldy Hernandez wrote:
> I can look into this later on, but this problem happened even when I replaced
> cilkplus' compile.exp, errors.exp, and execute.exp into just an "exit". So
> it seems unrelated to the cilk patch set.
Ah, I withdraw my objection. The bug can'
On Mar 21, 2013, at 7:08 AM, Sebastian Huber
wrote:
> This patch should be applied to GCC 4.8 and 4.9.
Ok for trunk.
Ok for 4.8.1. 4.8.0 would require RM approval I think.
On Fri, 22 Mar 2013 09:13:17 +0100, Janne Blomqvist
wrote:
On Fri, Mar 22, 2013 at 12:52 AM, Tilo Schwarz
wrote:
Hi,
this patch fixes PR 52512.
Built and regtested on Linux 3.2.0-4-686-pae.
Ok for trunk (4.9). Thanks for the patch!
PS: Common procedure is to report the target triplet
gcc/testsuite/ChangeLog
2013-03-22 Sebastian Huber
* gcc.c-torture/execute/builtins/builtins.exp: Sort targets
alphabetically.
---
gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/
Slight update to links, reflecting more attempts by libstdc++ to blend
in with the native layout and compression choices for gcc releases.
Links check so seems fine.
While at this, I figured I might as well do the GDL/GPL dupe for the
libstdc++-api XML file, as discussed at Cauldron last year.
We were treating a constant VAR_DECL as non-dependent because it has a
non-dependent type, even though it has a value-dependent initializer.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d3a8f99d0ae9caf8d344b44a8e66632181a20157
Author: Jason Merrill
Date: Fri Mar 22 12:27:01 2013 -040
On Mar 22, 2013, at 1:31 AM, Kai Tietz wrote:
> this patch adds option dg-additional-options for libstdc++-v3's testsuite and
> make use of this option for some mingw-tests. Those tests are just possible
> for
> pe-coff for static-library use. The shared version for pe-coff is
> finally linked
On Mar 22, 2013, at 1:17 AM, Kai Tietz wrote:
> this patch fixes an LLP64 issue in g++.dg's testsuite.
>
> ChangeLog
>
> 2013-03-22 Kai Tietz
>
>* g++.dg/torture/20121105-1.C: Adjust for LLP64 targets.
>
> Ok for apply?
Ok.
On Fri, Mar 22, 2013 at 9:58 AM, Michael Zolotukhin
wrote:
>> You can't use aligned vector move if alignment is unknown or
>> not properly aligned.
> Yes, sure. But I just emit V2DI move for an operands, which are
> aligned to 64-bit (not 128-bit!) - and it's encoded into movdqa which
Can you try
I committed some notes on Go to the GCC 4.8 changes file.
Ian
Index: gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.109
diff -u -r1.109 changes.html
--- gcc-4.8/changes.html 22
Hello!
Attached patch merges _rex64 MMX move patterns with base MMX move
patters using x64 and nox64 isa attribute. Additionally, the patch
rewrites MMX move patterns to look like DImove move pattern (keeping
all decorations of various alternatives), introducing all recent
improvements. The patch
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Thursday, March 21, 2013 8:04 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
>
> Thanks, this is almost there now.
I am committing the following changes as obvious. They include some
wrapping issues, as well as some minor wording issues I found while
peeking around.
Joseph, I am posting this as an incremental patch, to avoid posting a 7k
line patch for everything. I have also asked Balaji to post increme
> You can't use aligned vector move if alignment is unknown or
> not properly aligned.
Yes, sure. But I just emit V2DI move for an operands, which are
aligned to 64-bit (not 128-bit!) - and it's encoded into movdqa which
is obviously incorrect. The compiler knows, that operands are
misaligned, but
On Fri, Mar 22, 2013 at 5:49 AM, Michael Zolotukhin
wrote:
>> Do you have a testcase to show there is a problem?
>> The misaligned case should only be generated from
>> ix86_avx256_split_vector_move_misalign.
> I faced it when playing with optimized expanding of memmov (with
> vector instructions)
On 30/01/13 15:54, Kyrylo Tkachov wrote:
Hi all,
This patch implements the atomic built-ins using the new ARMv8 load-acquire
and store-release instructions.
They allow us to generate barrier-free code for a variety of atomic
operations such as: atomic load, atomic store, atomic compare and swap,
On 03/22/2013 01:03 AM, Kai Tietz wrote:
> * config/i386/predicates.md (local_symbolic_operand):
> Interprete dll-imported symbols
> as none-local.
Ok.
r~
On 01/02/13 17:38, Kyrylo Tkachov wrote:
Ummm... forgot the patch, sorry!
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
Sent: 01 February 2013 17:37
To: gcc-patches@gcc.gnu.org
Cc: Ramana Radhakrishnan; Richard
Richard Biener writes:
| On Fri, Mar 22, 2013 at 1:44 PM, Gabriel Dos Reis wrote:
| > Richard Biener writes:
| >
| > [...]
| >
| > | > in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
| > | > except that it returns a typed pointer instead of a boolean value.
| > |
| > | H
Hi!
Ugh, this hit us again, going to note it into releasing.html later.
libsanitizer Makefiles/configure are owned by GCC, so we can use no-dist
here on the trunk too. Committed as obvious.
2013-03-22 Jakub Jelinek
PR other/43620
libsanitizer/
* configure.ac (AM_INIT_AUTOMAK
On Fri, 22 Mar 2013, Ian Lance Taylor wrote:
> On Fri, Mar 22, 2013 at 3:27 AM, Richard Biener wrote:
> >
> > I think the wrong-code fix is orthogonal to code improvements
> > which will also trigger on the GIMPLE level (and where they
> > will have a bigger impact).
>
> I agree. I think the pa
On Fri, Mar 22, 2013 at 3:27 AM, Richard Biener wrote:
>
> I think the wrong-code fix is orthogonal to code improvements
> which will also trigger on the GIMPLE level (and where they
> will have a bigger impact).
I agree. I think the patch to calls is fine unless Jakub objects.
> We can for ex
Committed as obvious.
Richard.
2013-03-22 Richard Biener
* is-a.h (as_a): Use gcc_checking_assert.
Index: gcc/is-a.h
===
--- gcc/is-a.h (revision 196955)
+++ gcc/is-a.h (working copy)
@@ -181,7 +181,7 @@ template
in
On Fri, Mar 22, 2013 at 1:44 PM, Gabriel Dos Reis wrote:
> Richard Biener writes:
>
> [...]
>
> | > in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
> | > except that it returns a typed pointer instead of a boolean value.
> |
> | Hm? So you are replacing TREE_CODE (t) == I
> Do you have a testcase to show there is a problem?
> The misaligned case should only be generated from
> ix86_avx256_split_vector_move_misalign.
I faced it when playing with optimized expanding of memmov (with
vector instructions). There I generated v2di-move with emit_strmov,
which later used "*
Richard Biener writes:
[...]
| > in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
| > except that it returns a typed pointer instead of a boolean value.
|
| Hm? So you are replacing TREE_CODE (t) == IDENTIFIER_NODE
| with kind-of dynamic_cast (t) (in C++ terms)?
It woul
Jakub Jelinek writes:
| On Fri, Mar 22, 2013 at 10:21:05AM +0100, Richard Biener wrote:
| > On Fri, Mar 22, 2013 at 4:50 AM, Gabriel Dos Reis
wrote:
| > >
| > > This patch introduces identified_p (t) in lieu of
| > >
| > >TREE_CODE (t) == IDENTIFIER_NODE
| >
| > Generally we have macros li
The following patch finally removes the reference dependence check cache.
Its benefit is too low for its cost. LIM Compile-time for PR39326
improves from 100s to 50s and LIMs memory use drops to unnoticable
(from 915MB memory use after LIM to 380MB memory use after LIM).
Bootstrapped on x86_64-u
This removes the all_refs_in_loop bitmaps. They add a O(loop-depth)
memory cost to the refs_in_loop bitmaps. It removes the last
user, a query that is used to avoid walking subloops. But that
query is costly compared to just walking the subloops.
No observable memory usage difference for PR393
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01441.html
I thought this was ok'd for 4.9 but I can't seem to find the ok email in the
archives.
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tk
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00023.html
I thought this was ok'd for 4.9 but I can't seem to find the ok email in the
archives
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tka
This re-organizes the toplevel LIM dependence query which is
to ask whether a reference is independent in a whole loop nest.
The patch makes it compute the answer for all sub-loops of the
nest and compute an overall answer based on the answers from
the sub-loops. This avoids repeated dependence t
On Mar 22 2013, Tobias Burnus wrote:
The front end and the backend are both compiled with the same compiler
and in the same binary. Even without bootstrapping, trying to compile
them with different compilers, will require some heavy editing of
makefiles. Thus, it seems to be extremely unlikel
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.8-b20130224.de.po', h
N.M. Maclaren wrote:
On Mar 22 2013, Miles Bader wrote:
That is another matter entirely. The code of gcc/gfortran is supposed
to be compilable with other compilers, and it is foolish to make
unnecessary assumptions by relying on undefined behaviour.
The simple facts are that C++ does NOT def
On Fri, 22 Mar 2013, Jakub Jelinek wrote:
> Hi!
>
> This new warning switch hasn't been mentioned in changes.html, the following
> patch fixes that. Is this ok, or do you have better wording?
No, looks ok to me.
Richard.
> --- htdocs/gcc-4.8/changes.html 14 Mar 2013 01:13:56 -
On Fri, 22 Mar 2013, Jakub Jelinek wrote:
> On Fri, Mar 22, 2013 at 11:06:53AM +0100, Richard Biener wrote:
> > This fixes PR56434 - the use of BIGGEST_ALIGNMENT to annotate
> > the pointer returned by malloc is wrong - BIGGEST_ALIGNMENT
> > has nothing to do with the alignment guaranteed by the A
Hi!
This new warning switch hasn't been mentioned in changes.html, the following
patch fixes that. Is this ok, or do you have better wording?
--- htdocs/gcc-4.8/changes.html 14 Mar 2013 01:13:56 - 1.108
+++ htdocs/gcc-4.8/changes.html 22 Mar 2013 10:22:37 -
@@ -32,7 +32,12 @@ the nu
On Fri, Mar 22, 2013 at 11:06:53AM +0100, Richard Biener wrote:
> This fixes PR56434 - the use of BIGGEST_ALIGNMENT to annotate
> the pointer returned by malloc is wrong - BIGGEST_ALIGNMENT
> has nothing to do with the alignment guaranteed by the ABI
> for allocated memory. For example on x86_64 i
This fixes PR56434 - the use of BIGGEST_ALIGNMENT to annotate
the pointer returned by malloc is wrong - BIGGEST_ALIGNMENT
has nothing to do with the alignment guaranteed by the ABI
for allocated memory. For example on x86_64 it depends on
-mavx and thus can result in wrong code being generated.
Il 18/03/2013 01:01, Steven Bosscher ha scritto:
>> > someone else DF aware anyway. If it is 4.9 material perhaps
>> > it is simpler to place it after the patches that kill the basic
>> > block argument.
> Here is the updated patch. Bootstrapped&tested on
> powerpc64-unknown-linux-gnu. OK for trun
Hi,
this patch adds required configure changes for new cygwin x64 target.
ChangeLog gcc/
* config.build: Add support for cygwin x64 target.
* config.gcc: Likewise.
* config.host: Likewise.
* configure.ac: Likewise
* configure: Regenerated.
ChangeLog confi
On Mon, Mar 18, 2013 at 1:01 AM, Steven Bosscher wrote:
> On Thu, Feb 21, 2013 at 1:33 PM, Paolo Bonzini wrote:
>> someone else DF aware anyway. If it is 4.9 material perhaps
>> it is simpler to place it after the patches that kill the basic
>> block argument.
>
> Here is the updated patch. Bootst
On Thu, Mar 21, 2013 at 5:24 PM, Eric Botcazou wrote:
> Hi,
>
> this fixes an ICE on the mainline at -O1:
>
> eric@polaris:~/gnat/bugs/M129-026> ~/install/gcc/bin/gcc -S p.adb -O
> +===GNAT BUG DETECTED==+
> | 4.9.0 20130320 (experimental) [trunk
On Fri, Mar 22, 2013 at 10:21:05AM +0100, Richard Biener wrote:
> On Fri, Mar 22, 2013 at 4:50 AM, Gabriel Dos Reis wrote:
> >
> > This patch introduces identified_p (t) in lieu of
> >
> >TREE_CODE (t) == IDENTIFIER_NODE
>
> Generally we have macros like IDENTIFIER_P for this kind of checks.
Hi,
this patch fixes PR/52790 and supports for x64 Windows targets the use
of large and medium code-model.
This feature is required for upcoming new cygwin x64 target, which
uses full 48-bit available address-space of x64 Windows.
The cygwin-target depends on pseudo-relocation-feature, which opera
On Fri, Mar 22, 2013 at 4:50 AM, Gabriel Dos Reis wrote:
>
> This patch introduces identified_p (t) in lieu of
>
>TREE_CODE (t) == IDENTIFIER_NODE
Generally we have macros like IDENTIFIER_P for this kind of checks.
> in the C++ front-end. identifier_p is effectively LANG_IDENTIFIER_CAST
> e
On 03/22/2013 07:42 AM, Kai Tietz wrote:
> Tested for x86_64-w64-mingw32, and for upcoming x86_64-pc-cygwin
> target. Ok for apply?
Yes, that's fine.
Andrew.
On Mar 22 2013, Miles Bader wrote:
That is another matter entirely. The code of gcc/gfortran is supposed
to be compilable with other compilers, and it is foolish to make
unnecessary assumptions by relying on undefined behaviour.
The simple facts are that C++ does NOT define bool to be compati
On 03/22/2013 08:13 AM, Kai Tietz wrote:
> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
> x86_64-unknown-linux-gnu. Ok for apply?
Yes, thanks.
Andrew.
Hi,
Hi,
the first part of required code-changes for upcoming cygwin x64 target.
ChangeLog
2013-03-22 Kai Tietz
* config/i386/cygwin-stdint.h: Add support for cygwin x64 target.
* config/i386/t-cygwin-w64: New file.
* config/i386/cygwin-w64.h: New file.
* confi
Hi,
this change is actual used by cygwin and is required for upcoming x64
cygwin target.
ChangeLog
2013-03-22 Kai Tietz
* config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
(__deregister_frame_info): Likewise.
Tested for i686-pc-cygwin, and x86_64-pc-cygwin.
Hi,
this patch replaces use of _WIN64 by __x86_64__ so mingw x64 and
cygwin x64 version can share same source.
ChangeLog
2013-03-22 Kai Tietz
* config/i386/cygwin.S: Replace use of _WIN64 by __x86_64__.
Tested for x86_64-w64-mingw32, x86_64-pc-cygwin, and i686-w64-mingw32.
I will a
Hi,
this patch adds option dg-additional-options for libstdc++-v3's testsuite and
make use of this option for some mingw-tests. Those tests are just possible for
pe-coff for static-library use. The shared version for pe-coff is
finally linked and therefore
no override of operators is possible wi
"N.M. Maclaren" writes:
> That is another matter entirely. The code of gcc/gfortran is supposed
> to be compilable with other compilers, and it is foolish to make
> unnecessary assumptions by relying on undefined behaviour.
>
> The simple facts are that C++ does NOT define bool to be compatible w
On Mar 21 2013, Joseph S. Myers wrote:
>
> > now that the Fortran frontend is C++ we can use the primitive bool
> > type instead of inventing our own.
>
> Well, C99's "bool" (_Bool) was already used before. ...
Er, that is making a serious mistake or, at least, running the risk of
one. C++'s
Hi,
this patch fixes an LLP64 issue in g++.dg's testsuite.
ChangeLog
2013-03-22 Kai Tietz
* g++.dg/torture/20121105-1.C: Adjust for LLP64 targets.
Ok for apply?
Regards,
Kai
Index: gcc/testsuite/g++.dg/torture/20121105-1.C
==
On Fri, Mar 22, 2013 at 12:52 AM, Tilo Schwarz wrote:
> Hi,
>
> this patch fixes PR 52512.
>
> Built and regtested on Linux 3.2.0-4-686-pae.
Ok for trunk (4.9). Thanks for the patch!
PS: Common procedure is to report the target triplet you regtested on
rather than the Linux kernel version. You c
Hi,
this patch makes sure we don't walk in put_decl_node of the
end_params_node element.
ChangeLog
2013-03-22 Kai Tietz
* lang.c (put_decl_node): Don't iterate over end_params_node.
Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
x86_64-unknown-linux-gnu. Ok for apply?
Regard
Hi,
this patch enables the POSIX-printf variant for mingw-hosts by default.
ChangeLog
2013-03-22 Kai Tietz
* config/i386/xm-mingw32.h (__USE_MINGW_ANSI_STDIO): Enable POSIX-printf
for mingw-hosted builds.
Tested for i686-w64-mingw32, and x86_64-w64-mingw32. I will apply
to
Hi,
A dllimported symbol is always external. So treat that proper in
local_symbolic_operand.
ChangeLog
2013-03-22 Kai Tietz
* config/i386/predicates.md (local_symbolic_operand):
Interprete dll-imported symbols
as none-local.
Tested for x86_64-w64-mingw32, i686-w64-mingw32,
Hi,
this patch fixes the Win64-code so that we use only pc-relative
addressing. This
is of importance if code gets linked to an pe-image with an image-base
above 2GB.
ChangeLog
2013-03-22 Kai Tietz
* src/x86/win64.S: Make use of ffi_closure_win64_inner
symbol pc-relative.
T
89 matches
Mail list logo
