Hmm, this seems to be something I haven't noticed until now. It might
be new ...
I see that cp-tree.h is part of gtfiles in config-lang.in. So the
warning about being not tagged for that language is weird. Issue
might be not directly within gcc.
Instead it might be a make issue.
You could ask on
Hi Tom,
- Ursprüngliche Mail -
> Hi Kai,
>
> I encountered a test failure in boehm-gc (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 'FAIL: boehm-gc.c/gctest.c
> -O2 execution test' ).
>
> I would like to ask somebody to confirm the PR, which hopefully should be as
> simple as p
2014-05-01 17:23 GMT+02:00 Jeff Law :
> On 04/30/14 21:56, Wolf wrote:
>>
>> Since the original MinGW refuses to support 64-bit, I would like to
>> discuss whether we should remove i686-mingw32 from the secondary
>> platforms list and replace it with MinGW-w64.
>
> Kai should probably chime in here
2014-03-04 14:14 GMT+01:00 Richard Biener :
> On Mon, 3 Mar 2014, Kai Tietz wrote:
>
>> 2014-03-03 12:33 GMT+01:00 Richard Biener :
>> > On Fri, 28 Feb 2014, Kai Tietz wrote:
>> >
>> >> Hmm, this all reminds me about the approach Andrew Pinski and I came
2014-03-03 12:33 GMT+01:00 Richard Biener :
> On Fri, 28 Feb 2014, Kai Tietz wrote:
>
>> Hmm, this all reminds me about the approach Andrew Pinski and I came
>> up with two years ago.
>
> You are talking about the gimple folding interface? Yes, but it's
> more s
Hmm, this all reminds me about the approach Andrew Pinski and I came
up with two years ago. All in all I think it might be worth to
express folding-patterns in a more abstract way. So the md-like Lisp
syntax for this seems to be just stringent. We make use of such a
script-language already for
2013/10/30 Andrew Haley :
> On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>
>>>
>> The reasons of adding builtins is performance. Without that one can
>> write a simple template to generically check overflows like
>>
>> template class overflow {
>> public:
>> C val;
>> overflow operator + (ov
2013/5/20 Eli Zaretskii :
>> Date: Sun, 19 May 2013 17:48:06 -0700
>> From: Ian Lance Taylor
>> Cc: gcc@gcc.gnu.org
>>
>> It is not a fundamental bug to depend on libgcc as a shared library.
>> The libgcc code is trying to do the right thing when the library is
>> unloaded. I don't see any obviou
2013/4/8 Angelo Graziosi :
> Usually I do weekly builds of GCC snapshots on Cygwin, but current
> snapshot (http://gcc.gnu.org/ml/gcc/2013-04/msg00091.html) fails with:
>
> ...
> g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wal
Hi,
I am a bit in doubt that the fix of PR 55171 will help you for 64-bit.
The patch modifies thunk-code for 32-bit "thiscall"
calling-convention. So it can't affect 64-bit code path.
Kai
2012/11/22 niXman :
> 2012/11/22 Kai Tietz:
>> Well, __SEH__ is defined for x64 in any case. There is no way to have
>> for x64 no SEH-support - at least not in a way it would work in a
>> general way, as SEH is part of the ABI of x64.
> I.e. SJLJ can't be used for
2012/11/22 niXman :
> 2012/11/22 niXman:
>> I once asked a similar question, but didn't understand, whether sjlj
>> use will be available for 4.8?
>
> Because I a few months can not build trunk with sjlj successfully.
> I wrote about this in the gcc-help mailing list, I think twice.
Well, __SEH__
Hi,
the cause for this is that SEH exceptions are only present for x64
64-bit target. There is no such support for 32-bit (mainly caused by
patent issues). Therefore if you want to build multilib for mingw,
then please switch back to SjLj-exception mechanism.
Regards,
Kai
Hi,
well, those failures are caused by -Werror switch. You should turn it
off. Nevertheless there is already a bug report about this. See bug
53912 with title "[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap
fails using default c++ mode in stage 2 and 3 for native
x86_64-w64-mingw32"
Rega
2012/5/24 niXman :
> 2012/5/24 Kai Tietz:
>> There is no option to disable this, as thiscall is part of the Windows
>> ABI.
>
> Could you please tell me, in what revision is added this change, so
> that I could have made the reverting patch?
Hmm, no idea. see revision
2012/5/24 niXman :
> Hello!
>
> http://gcc.gnu.org/ml/gcc-help/2012-05/msg00043.html
>
> ping?
>
>
> --
> Regards,
> niXman
There is no option to disable this, as thiscall is part of the Windows
ABI. But you can switch via that -mabi=(sysv|ms) option.
Regards,
Kai
2012/4/14 Nicolai Josuttis:
> Hi,
>
> I am currently trying to build
> gcc-4.8-20120401.tar.bz2
> on my Windows 7 Pro system using CygWin.
> I am using the following configuration settings:
> configure \
> --enable-languages=c++ \
> --disable-bootstrap \
> --prefix=/cygdrive/p/gcc$VERSION \
>
2011/12/7 Joern Rennecke :
> Quoting Richard Henderson :
>
>>> I can fix this in libgcc/config/epiphany/t-epiphany with:
>>>
>>> unwind-sjlj.o : CFLAGS += -fno-exceptions
>>> unwind-sjlj.o : c_flags := $(filter-out -fexceptions,$(cflags))
>>>
>>> Is that the right way to do it? Or should we more g
2011/10/24 Bob Breuer :
> Kai Tietz wrote:
>> Hi,
>>
>> For trunk-version I have a tentative patch for this issue. On 4.6.x
>> and older branches this doesn't work, as here we can't differenciate
>> that easy between ms- and sysv-abi.
>>
>>
2011/10/22 xunxun :
> 于 2011/10/22 13:13, xunxun 写道:
>>
>> Hi, all
>>
>> It seems that gcc's auto-omit-frame-pointer has other problems.
>>
>> The example is from mingw bug tracker:
>> http://sourceforge.net/tracker/?func=detail&aid=3426555&group_id=2435&atid=102435
>>
>> g++ -O3 main.cpp
Hi,
For trunk-version I have a tentative patch for this issue. On 4.6.x
and older branches this doesn't work, as here we can't differenciate
that easy between ms- and sysv-abi.
But could somebody give this patch a try?
Regards,
Kai
ChangeLog
* config/i386/i386.c (ix86_frame_pointer_re
05 AM, Bob Breuer wrote:
>> Kai Tietz wrote:
>>> 2011/10/18 Bob Breuer :
>>>> Kai Tietz wrote:
>>>>> 2011/10/17 Bob Breuer :
>>>>>> Richard Henderson wrote:
>>>>>>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>>&g
2011/10/18 Bob Breuer :
> Kai Tietz wrote:
>> 2011/10/17 Bob Breuer :
>>> Richard Henderson wrote:
>>>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>>>> I don't think this is a free/g_free issue. If I use the following
>>>>> patch,
2011/10/17 Bob Breuer :
> Richard Henderson wrote:
>> On 10/17/2011 07:09 AM, Bob Breuer wrote:
>>> I don't think this is a free/g_free issue. If I use the following
>>> patch, then I at least get the openbios messages:
>>>
>>> diff --git a/cpu-exec.c b/cpu-exec.c
>>> index a9fa608..dfbd6ea 100644
2011/4/3 Gerald Pfeifer :
> I'm a bit surprised I'm not seeing other notes on this on the list,
> but all of my automated tests (on i386-unknown-freebsd9.0 and
> amd64-unknown-freebsd8.2) exhibit comparision failures since yesterday:
>
> Comparing stages 2 and 3
> warning: gcc/cc1obj-checksum.o d
2011/4/1 Andrew Haley :
> On 04/01/2011 10:05 AM, Kai Tietz wrote:
>
>> I would like to update boehm-gc in gcc's tree to more recent version
>> (7.2 - alpha 5). It has shown now that we wait for x64 windows
>> support of boehm-gc more then one year. This blocks the w
Hello,
I would like to update boehm-gc in gcc's tree to more recent version
(7.2 - alpha 5). It has shown now that we wait for x64 windows
support of boehm-gc more then one year. This blocks the waiting
patches for libjava support for this target and some other features
depending on boehm-gc. Add
2011/3/28 Piotr Wyderski :
> Jakub Jelinek :
>
>> The GNU Compiler Collection version 4.6.0 has been released.
>
> Compilation failure on Cygwin:
>
> ../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error:
> fenv.h:
> No such file or directory
> compilation terminated.
> make[3]: *
2010/10/8 Jonathan Wakely :
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the libstdc++-v3/testsuite/libstd
2010/10/3 FX :
> Hi all,
>
> I'm trying to bootstrap trunk on i686-pc-mingw32. I configure with
> --disable-werror --enable-threads --disable-nls --build=i686-pc-mingw32
> --enable-libgomp --with-dwarf2 --disable-sjlj-exceptions
>
> During stage 1, bootstrap fails when comparing trunk tm.texi and
2010/9/28 Richard Henderson :
> On 09/28/2010 03:09 AM, Kai Tietz wrote:
>> * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
>> addition zero for padding of secrel32 requested for 8 bytes.
>>
>> I will apply this today, if there aren
unsigned
> and thus using .secrel 32 ref; .long 0 is IMHO just fine, and
> implicit pointer currently will never reference anything outside of the
> current executable's or shared library's CU.
So I suggest the following patch. I tested it for x86_64-w64-mingw32
and didn'
2010/9/28 Kai Tietz :
> 2010/9/28 Richard Henderson :
>> The 64-bit PEI format has a SECREL32 relocation type. It
>> does not, however, have a SECREL64 relocation type. Which
>> means that for
>>
>>> #define DWARF_REF_SIZE \
>>> (dwarf_versio
2010/9/28 Richard Henderson :
> The 64-bit PEI format has a SECREL32 relocation type. It
> does not, however, have a SECREL64 relocation type. Which
> means that for
>
>> #define DWARF_REF_SIZE \
>> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
>
> we don't really have something
;>>> I can see I can support one person financially (trip from Europe to
>>>> Ottawa
>>>> vice versa and stay in "Les Suites").
>>>
>>> Only a gfortran person? Because I'd like to nominate Kai Tietz for
>>> that, if he's
Hi,
What's about the "friend"s in C++.. I think it should be forbidden by
C++ coding-style, as it is mainly a sign of weak OO design to use
them.
Kai
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
2010/6/3 Uros Bizjak :
> Hello!
>
> I'm looking into i386.md, where we have a bunch of instances of
> following comment:
>
> ; Current assemblers are broken and do not allow @GOTOFF in
> ; ought but a memory context.
>
> Code, following this comment disables or special-cases
2010/4/23 Heinz Riener :
> Dear all,
>
> I'm using the native GCC version[1] of my GNU/Linux distribution. I wonder
> whether GCC's optimization behavior is in the following case correct.
> Consider the following two programs:
>
> (1)
> int test(int n) {
> if (n > 0)
> return 1;
> return 0;
2010/1/29 Richard Earnshaw :
>
> On Fri, 2010-01-29 at 12:25 +, Dave Korn wrote:
>> On 29/01/2010 12:02, Richard Earnshaw wrote:
>>
>> > We have three categories of users of BZ: RMs, Developers, and the rest.
>> > Developers are *not* the same as the rest and that extends beyond the
>> > abilit
2010/1/10 Kai Tietz :
> 2010/1/10 Andrew Hutchinson :
>>
>>
>> Kai Tietz wrote:
>>>
>>> Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
>>> handled). For O_BINARY the common approach here is to do the following
>&g
2010/1/10 Andrew Hutchinson :
>
>
> Kai Tietz wrote:
>>
>> Well, on linux (libc) fopen/freopen/etc the "b" is an nop (but
>> handled). For O_BINARY the common approach here is to do the following
>> condifition before use:
>>
>> #ifndef O
2010/1/10 Andrew Hutchinson :
> I think "rb" is nop. However, O_BINARY is less portable.
>
> There is another way. If MinGW hosted build is linked with binmode.o - the
> default for files become binary
> Some other methods are here:
>
> http://oldwiki.mingw.org/index.php/binary
>
>
>
>
> Rafael
2009/12/3 Dave Korn :
> Joseph S. Myers wrote:
>> On Thu, 3 Dec 2009, Arnaud Charlet wrote:
>>
Are rpaths as portable as shared libraries or do we support a host
architecture that has shared libraries but no equivalent to rpath?
>>> Windows (mingw) comes to mind at least.
>>
>> If the hyp
2009/11/20 Piotr Wyderski :
> An attempt to build either gcc-trunk or the most recent
> snapshot (20091119) with Cygwin (the build compiler
> is either GCC 4.4.0 or 4.5-20090604), configured as:
>
> $ ../configure --prefix=/opt/gcc-4.5-20091119 -v --enable-bootstrap
> --enable-ve
> rsion-specific-
2009/11/19 Frederic Weisbecker :
> I would really like this. So that we can forget about other possible
> further suprises due to sophisticated function prologues beeing before
> the mcount call.
>
> And I guess that would fix it in every archs.
My 5 cent for this, too.
> That said, Linus had a g
2009/11/9 Kai Ruottu :
> I myself would be more interested to get these tests for MinGW-hosted
> tools to work on Linux because that is
> the "preferred build platform for MinGW-hosted tools" for me. Some years
> ago I produced more than 100
> binutils+GCC+GDB/Insight toolchains for all kind of tar
2009/11/9 徐持恒 :
>
> Thank you, I'll give it a try.
>
> But can you tell me why there are no testresult of MinGW or Cygwin on
> gcc-testresults mailinglist ?
There are, but as a full testsuite run for cygwin/mingw needs round
about 25-35 hours, they are sent not regular. But if there would be
someb
2009/11/9 Dave Korn :
> 徐持恒 wrote:
>
>> Finally, I found, that, to run test, you must first install guile, autogen,
>> tck/tk, expect, dejagnu.
>> In Msys+MinGW and Cygwin environments, these tools are missing or outdated.
>
> The ones in the cygwin distro may be outdated, but they work just fine
2009/10/10 Sergey Sadovnikov :
> Hello.
>
> There is linkage problem with recent gcc 4.5 in MinGW configuration
> build. Executables which are produced by gcc with default options set
> treated as 'not a valid win32 application' by the system (Win2008 x64
> server). After stripping with the 'strip'
2009/9/19 H.J. Lu :
> On Sat, Sep 19, 2009 at 7:58 AM, Eric Botcazou wrote:
>>> I need to get run baseline test results on 4.3 and 4.4 for C and
>>> C++. But the GNAT/RTEMS Ada results show a large number of
>>> failures on the head that were not present in 4.3 and 4.4.
>>>
>>> SPARC and MIPS wen
2009/9/11 Ross Ridge :
> Stefan Dösinger writes:
>>On a partly related topic, I think the Win64 ABI requires that the first
>>function is two bytes long, and there at least 6 bytes of slack before
>>the function. Does gcc implement that?
>
> As far as I can tell the Win64 ABI doesn't have either of
2009/9/3 Paolo Bonzini :
> if (TARGET_64BIT
> ? !is_attribute_p ("msvc_prologue", name))
> : is_attribute_p ("msvc_prologue", name))
> {
> warning (OPT_Wattributes, "%qE attribute not available for "
> "%d-bit", name, TARGET_64BIT ? 64 : 32);
> *no_add_a
2009/7/29 Richard Guenther :
> On Wed, 29 Jul 2009, Dave Korn wrote:
>
>> Richard Guenther wrote:
>> > A release candidate for the GCC 4.3.4 is now available at
>> >
>> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.4-RC-20090727
>> >
>> > I plan to roll out the final release at the beginning of next we
Hello,
This patch adds dummy implementation for
gnu/java/security/jce/prng/natVMSecureRandomWin32.cc file for Win32 build.
It throws just an exception for not supporting this method.
ChangeLog
2009-07-24 Kai Tietz
* gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: New Win32
Hello,
Possibly somebody could give me a hint what the issue here is. In the
patch I attached, I enable multilib for x86 default mingw target
(i686-w64-mingw32). The core compilers are translating nicely. But
when it tries to build libgcc by -m64 it throws always the same error
message for any arr
2009/7/19 Dave Korn :
>
> Hi team,
>
> I'd like to have some basic BZ perms if I may, so I can help out with
> cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at
> least ones that I created myself, depending how fine-grained it is), and
> perhaps be allowed to change st
2009/7/19 Dave Korn :
> Kai Tietz wrote:
>> 2009/7/19 Dave Korn :
>>> Kai Tietz wrote:
>>>
>>>> There are a lot of issues about casting HANDLE values into jint types,
>>>> which is for x86 valid, but for x64 can lead potential to pointer
>&
2009/7/19 Dave Korn :
> Kai Tietz wrote:
>
>> There are a lot of issues about casting HANDLE values into jint types,
>> which is for x86 valid, but for x64 can lead potential to pointer
>> truncations. Those part need some review by libjava maintainers. My
>> pa
2009/7/18 Andrew Pinski :
> On Sat, Jul 18, 2009 at 12:22 PM, Kai Tietz wrote:
>> Well, uintptr_t/intptr_t are available to most (but not all hosts).
>> IIRC there is a gcc version of stdint.h (gstdint.h), which could be
>> used here. The mode version is fine too, as long
2009/7/18 Dave Korn :
> Andrew Pinski wrote:
>> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>>> Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This
>>> is built-in to gcc, not a dependency on the host libc which might not
>>> be c99..'
>>
>> Except uintptr_t is required
2009/7/18 Andrew Pinski :
> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>> Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This
>> is built-in to gcc, not a dependency on the host libc which might not
>> be c99..'
>
> Except uintptr_t is required to be provided by a non
2009/7/18 Dave Korn :
> Kai Tietz wrote:
>
>> * gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: Implementation
>> for native win32.
>>
>> Tested for x86 and x64 mingw targets. Ok for apply?
>
> + for (a = 0; a < length; a++, count++)
>
2009/7/18 Dave Korn :
> Kai Tietz wrote:
>> Hello,
>>
>> I noticed, while trying to build libjava for x64 windows, that the
>> configure script fails to generate link to
>> 'libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc'. This
>
2009/6/26 Tim Prince :
> Kai Tietz wrote:
>>
>> 2009/6/26 Seiji Kachi :
>>
>>>
>>> Angelo Graziosi wrote:
>>>
>>>>
>>>> Dave Korn ha scritto:
>>>>
>>>>>
>>>>> Angelo Graziosi wrote
2009/6/26 Seiji Kachi :
> Angelo Graziosi wrote:
>>
>> Dave Korn ha scritto:
>>>
>>> Angelo Graziosi wrote:
I want to flag the following failure I have seen on Cygwin 1.5 trying to
build current 4.5-20090625 gcc snapshot:
>>>
>>> So what's in config.log? And what binutils are you u
2009/6/16 Rafael Espindola :
>> At revision 148493 decl_one_only was changed to take 2 arguments.
>> Looks like I missed winnt.c.
>
> 148492 actually. Fixed in revision 148523:
>
>
> 2009-06-16 Rafael Avila de Espindola
>
> * config/i386/winnt.c (i386_pe_encode_section_info): Update call
2009/6/16 Rafael Espindola :
> 2009/6/15 Aldy Hernandez :
>>> ../../gcc/gcc/config/i386/winnt.c: In function
>>> ?i386_pe_encode_section_info?:
>>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>>> function ?make_decl_one_only?
>>
>> make_decl_one_only expects one argument, an
2009/5/29 Kai Tietz :
> 2009/5/29 Mahesh Basavaraj Shavari :
>> Hi,
>> I am trying to build a MinGW toolchain for M16CM32C target using the
>> following sources:
>>
>> GCC-4.4.0
>> Binutils-2.19
>> Newlib-1.17
>>
>> The linux toolch
2009/5/29 Mahesh Basavaraj Shavari :
> Hi,
> I am trying to build a MinGW toolchain for M16CM32C target using the
> following sources:
>
> GCC-4.4.0
> Binutils-2.19
> Newlib-1.17
>
> The linux toolchain was built successfully, however MinGW toolchain build
> failed.
> During make, I get the follo
2009/4/4 Danny Smith :
>> Hi all,
>>
>> Please find attached a patch I built to add stdint-related
>> information
>> to GCC configuration for the mingw target (see
>> http://gcc.gnu.org/ml/gcc/2009-04/msg0.html
>> for more details about why).
>
> Thanks for this. I am just in the process of
2009/4/3 Ian Lance Taylor :
> "Vincent R." writes:
>
>> Once again what I describe above is simplified because when seh is used,
>> there is a mechanism
>> called virtual unwiding that I didn't explained but that is the reason to
>> store the prologue length.
>
> It's worth noting that in gcc the
2009/3/21 Joseph S. Myers :
> Apart from new features, the x86_64 long double union ABI issue needs
> mentioning in the caveats section. Are there any other ABI changes
> missing from there?
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
The abi switching patch for x86_64 is still missing i
2009/3/19 Ozkan Sezer :
> On Thu, Mar 19, 2009 at 8:04 PM, Vincent R. wrote:
>> On Thu, 19 Mar 2009 19:58:13 +0200, Ozkan Sezer wrote:
>>> I'm a bit amazed that the prototype for VirtualProtect() is known to the
>>> compiler but the definition of DWORD is not.. In any case, it should be
>>> fixed
Hi Ross,
[EMAIL PROTECTED] wrote on 27.11.2008 23:36:22:
> Kai Tietz writes:
> >Well, you mean the SEH tables on stack.
>
> No, I mean the ABI required unwind information.
So you speak about .pdata and .xdata. Well, those aren't implemented.
First step would be to teach g
2008/11/27 Ross Ridge <[EMAIL PROTECTED]>:
> Kai Tietz writes:
>>I am very interested to learn, which parts in calling convention aren't
>>implemented for w64?
>
> Well, maybe I'm missing something but I can't any see code in GCC for
> generating
Hi Ross,
I am very interested to learn, which parts in calling convention aren't
implemented for w64? Do you mean the SEH stack reservation? If you could
specify it more detailed, I could correct it for 4.5. I am a bit curious,
as I found that the unwind mechanism of Windows itself working quit
2008/11/26 Tobias Burnus <[EMAIL PROTECTED]>:
> Emmanuel Fleury wrote:
>>> Username : (**)
>>> Password : (**)
>>> Date of Birth :
>>> Future Password : ()(Option)
>>
>> Do they really think that it will succeed ???
>> I guess not.
>
> I guess they do. For spam, the repl
Hello Steering Committee,
I want to sent my application for the role of a maintainer for the
mingw targets in gcc. I spoke with Christopher Faylor and he said that
he would support my application.
Best regards,
Kai Tietz
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny
> > The following ports haven't been converted yet:
> >
> > arc m32c m68hc11 mmix pdp11 score vax
>
> DJ has reported problems on the list for m32c.
>
> Regarding ARC and MMIX we might expect some action from Joern and H-P
> respectively, but nobody is probably going to do the work for the other
e submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Thanks in advance,
Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Hi,
The issue is, that for x86_64 the call for a w64 abi function should be
supported. The problem is, that va_list has always the type of the target
and there is no abi specific switching supported. My first idea was to
make the define for va_list_type_node in tree.h overridable for targets,
Hi,
While writing some testcases for the call abi switching for x86_64<->w64 I
came to the point, that it would be may good to add the builtin types and
functions for the different calling abi, too.
For the target default abi it would be
Index: gcc/gcc/testsuite/gcc.dg/callabi/callabi.h
==
Hi,
As I noticed are some parts in i386.md existing for just for 32-bit,
but will be used in 64-bit, too.
For example:
(define_split
[(set (match_operand:XF 0 "push_operand" "")
(float_extend:XF (match_operand:SF 1 "fp_register_operand" "")))]
""
[(set (reg:SI SP_REG) (plus:SI (reg
t; Andrew Haley <[EMAIL PROTECTED]> writes:
> >>>
> >>>> Richard Guenther wrote:
> >>>>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz [EMAIL PROTECTED]> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>
Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 12:07:49:
> Richard Guenther wrote:
> > On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]>
wrote:
> >> Hi,
> >>
> >> as I noticed, most hash value calculations are trying to us
Andrew,
Andrew Haley <[EMAIL PROTECTED]> wrote on 30.05.2008 11:45:50:
> Kai Tietz wrote:
>
> > as I noticed, most hash value calculations are trying to use pointer
> > values for building the value and assume that a long/unsigned long
scalar
> > is wide en
Hi,
as I noticed, most hash value calculations are trying to use pointer
values for building the value and assume that a long/unsigned long scalar
is wide enough for a pointer. This is at least for w64 target not true. So
I want to know, if it would be good to introduce an gcc specific type for
2008/5/23 Art Haas <[EMAIL PROTECTED]>:
> On Thu, 2008-05-22 at 21:12, Kai Tietz wrote:
>> Art,
>>
>> 2008/5/22 Art Haas <[EMAIL PROTECTED]>:
>> >
>> > On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
>> >> Ok, fixed on gcc trunk revisi
Art,
2008/5/22 Art Haas <[EMAIL PROTECTED]>:
> Hi.
>
> I've been unable to successfully bootstrap on my i386-pc-solaris2.10
> system since this set of changes made it into the repository:
>
> 2008-05-20 Kai Tietz <[EMAIL PROTECTED]>
>
>* config/
Hi,
it seems, that the compilation of libiberty for x86_64-pc-mingw32 leads to
an ICE in cp-demangle.c:2905: internal compiler error verify_cgraph_node
failed breaks bootstrap.
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domi
"James Courtier-Dutton" <[EMAIL PROTECTED]> wrote on 28.04.2008
15:28:56:
> 2008/4/28 Kai Tietz <[EMAIL PROTECTED]>:
> > [EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
> >
> >
> >
> > > I am trying to look at assembler code, and represe
mp;
MSB(myscalar ||
( ~(savea & MSB(myscalar)) & ~(b&MSB(myscalar)) & (a&MSB(myscalar
/* overflow */
...
}
For signed integers you can ease this as follow
savea = a;
a+=b;
if ( (savea<0 && b<0 && a>=0)) ||
(savea>=0 &&
"H.J. Lu" <[EMAIL PROTECTED]> wrote on 27.04.2008 21:31:14:
> Is this related to
>
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01951.html
>
>
> H.J.
> On Sun, Apr 27, 2008 at 11:47 AM, FX <[EMAIL PROTECTED]> wrote:
> >
> > > Cygwin native built gfortran 4.4 was already broken, even when it
Ross,
> Kai Tietz writes:
> >I read that too, but how can I teach gcc to do this that registers are
> >callee-saved? I tried it by use of call_used part in regclass.c, but
> >this didn't worked as expected.
>
> I think you need to modify CALL_USED_REGISTERS and/or
Hi,
I found, that the problem for an optimized build (by -O2) is broken for
the x86_64-pc-mingw32 target, because the runtime functions from msvcrt
are clobbering registers (%r10 upto %r15). I tried to get it solved by
call_used and fixed_regs, but it seems not to work. May somebody could
give
FX <[EMAIL PROTECTED]> wrote on 15.04.2008 15:21:30:
> > I remember that modification. This is related to a patch in
> > config/i386/mingw32.h to include for libgcc2 the windows header.
>
> OK. Bootstrap does proceed with the prototype removed, of course (it's
> not yet finished).
>
> Question i
D *PDWORD;
> > typedef void *PVOID;
> >
> >
> > Does that ring a bell to anyone? Any idea why it's showing up now even
> > though it looks like this code wasn't modified in the recent past (and
> > my winbase.h hasn't changed since my last succes
This is related to a patch in
config/i386/mingw32.h to include for libgcc2 the windows header. Danny
said he tested this patch, but for this the libgcc2.c prototype is no
longer necessary for mingw targets.
Regards,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 04.04.2008 16:53:53:
> Kai Tietz <[EMAIL PROTECTED]> writes:
>
> > While running testsuite for target x86_64-pc-mingw32, I noticed that
the
> > stack segement has for this target no execution permission. May
someb
Hi,
While running testsuite for target x86_64-pc-mingw32, I noticed that the
stack segement has for this target no execution permission. May somebody
could help me, how to avoid the use of stack based trampoline code.
Do you know how to avoid this HJ?
Thanks in advance,
Kai
| (\_/) This is
1 - 100 of 160 matches
Mail list logo
