Hello Michael,
thanks for description. I wasn't aware, that the upper 32 bits are zeroed.
Does this means that even the stack has to be in the first 4 Gb, too. Or
does this mov instruction does a sign-extention.
Best regards,
i.A. Kai Tietz
Hello Uros,
no the sizeof long is not always different. E.g. for future target 64bit
mingw the long type remains 4-byte size. But may we can use the
pointer-size ?
Because on i386 32-bit system sizeof(void *)==4 and on x86_64 64-bit
system sizeof(void *)==8 !
Regards,
i.A. Kai Tietz
/4.3.0.
The make command "make install-gcc" installs the toolchain as expected
under /usr/local/libexec/gcc/x86_64-pc-mingw32/4.3.0.
Can me somebody help ? Is this a bug or normal behaviour ?
Regards,
i.A. Kai Tietz
--------
Kai Tietz - Software e
to its gcc
tools defined. Under previous versions it worked. By the way, to make the
cross-compiler known via PATH would break my complete system.
Regards,
i.A. Kai Tietz
--------
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Thank you very much. I solved this problem (of my absent-mindedness). When
I use the binaries install in /usr/local/bin everything works well 8).
Sorry and best regards,
i.A. Kai Tietz
Daniel Jacobowitz <[EMAIL PROTECTED]>
19.02.2007 13:04
To
Kai Tietz <[EMAIL PROTECTED]&g
allready posted to
gcc-patch.
I would be very pleased, if somebody could give me a hint about the patch
needed.
Thank you very much,
i.A. Kai Tietz
passing ?
Regards,
i.A. Kai Tietz
not
defining it, one for targets allready using this define, and for
i386-target specific to the MS x86_64-mingw32 target. Otherwise, it
wouldn't be possible to have the x86_64 and the i386 compiler in one
executable anymore.
Regards,
i.A. Kai
think it would be nice to eliminate these *usesless* whitespaces.
Regards,
i.A. Kai Tietz
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
Phone: +49-941-78004-0
Thanks, that is what I want to hear. May it would be good point to run
over the source to be as the GNAT standard demands ?
Regards,
i.A. Kai Tietz
shadows.
Is there in gcc an example, which may can help ?
Regards,
i.A. Kai Tietz
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
Phone: +49-941-78004-0
FAX: +49
until now
in libc++, libiberty. There are ISO types defined for this case, as
intptr_t and uintptr_t. Is there something defined in the coding style ?
Regards,
i.A. Kai Tietz
int *status, struct pex_time *time, int done
ATTRIBUTE_UNUSED,
const char **errmsg, int *err)
{
Regards,
i.A. Kai Tietz
--------
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Dr.-Leo-Ritter-Str. 9,
isn't so for mingw ;(
Regards,
i.A. Kai Tietz
----
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
Phone: +49-941-78004-0
FAX: +49-941-78004-489
WW
Yes, for the hashtab.c it is more a cosmetic issue. But for pex-win32.c is
not. See method pex_win32_wait, there the pid is getting casted to the
type HANDLE, which is in fact declared as a void pointer.
Regards,
i.A. Kai Tietz
DJ Delorie <[EMAIL PROTECTED]>
08.03.2007 17:46
To
In gcc the file emutls.c assumes that a long has sizeof void * in function
emutls_destroy.
Regards,
i.A. Kai Tietz
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Ger
As I know, the types are declared in config/stdint.m4, which is part of
gcc, isn't it ?
Regards,
i.A. Kai Tietz
----
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, German
arr is in fact the integer value of a type with
sizeof(void *).
Wouldn't is better to have for this cast monster a structure. Something
like
struct sFieldArray {
size_t count;
void *arr[1];
}
?
Regards,
i.A. Kai Tietz
Richard Henderson &l
Hallo,
There is another point in libiberty, which has a problem with
integer-values and pointer sizes. This small patch should fix.
ChangeLog:
2007-03-06 Kai Tietz <[EMAIL PROTECTED]>
* splay-tree.h (splay_tree_key): type declared as ptrdiff_t
(splay_tree_value):
Hallo,
I detected, that ptrdiff_t is not declared in all places, therefore the
use of size_t seems to be more correct.
Regards,
i.A. Kai Tietz
:(
May somebody can give me an advice.
Regards,
i.A. Kai Tietz
Kai Tietz - Software engineering
OneVision Software Entwicklungs GmbH & Co KG
Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
Phone: +49-941-78004-0
FAX: +49-941-78004-489
Andrew Haley <[EMAIL PROTECTED]> wrote on 13.03.2007 16:03:57:
> Ian Lance Taylor writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > Kai Tietz writes:
> > >
> > > > I want to remove some trailing whitespaces from gcc s
Jakub Jelinek <[EMAIL PROTECTED]> wrote on 13.03.2007 16:37:34:
> On Tue, Mar 13, 2007 at 03:22:50PM +, Andrew Haley wrote:
> > Feel free to do it to your local copy. Don't do it to the gcc source
> > code repository.
>
> Well, please do it on all your checkings - all lines you have changed
s out of the MSVCRT and
has the name "__imp__malloc". But the import library has also the not
decored name stub function "_malloc". Did I something wrong or is there
something broken ?
Richard Henderson <[EMAIL PROTECTED]> wrote on 21.03.2007 17:09:26:
> On Wed, Mar 21, 2007 at 01:11:36PM +0100, Kai Tietz wrote:
> > #include
> > void *(my_malloc_hook)(size_t) = malloc;
> >
> > GCC tells me, that malloc isn't a constant symbol. Clea
Hello,
I noticed a seg-fault in gengtype on cygwin bootstap. Guilty seem to be,
that in method "oprintf" the standard c-library call "vsnprintf" is used,
which is on MSVCRT broken. By a patching it to use vasnprintf it seems to
work. Did somebody noticed this problem too ?
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
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
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
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]: *
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/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
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/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/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,
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
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
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
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/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
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/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 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 :
> 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: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/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/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 :
>
> 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
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
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
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
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/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/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/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/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/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 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/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/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/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
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
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 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/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/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;
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.
> > 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
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
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
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/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,
[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
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
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/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/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/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/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/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/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/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/26 Tim Prince :
> Kai Tietz wrote:
>>
>> 2009/6/26 Seiji Kachi :
>>
>>>
>>> Angelo Graziosi wrote:
>>>
>>>>
>>>> Dave Korn ha scritto:
>>>>
>>>>>
>>>>> Angelo Graziosi wrote
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
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
;>>> 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
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
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
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 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
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/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
,
i.A. Kai Tietz
PS: You can find the patch in the thread "Re: PE+ and new COFF format for
x86_64 target for XP64 and Vista binaries"
(I tested it with cygwin and linux environment)
--------
Kai Tietz - Software engineering
OneVision Software Entwick
ause
if the base adress of the code segment gets out-side of 2^32 the
relocation will be incorrect for sure. May somebody can help if my
thoughts are wrong or not ...
Regards,
i.A. Kai Tietz
mbolRef LC0 via ecx to function
foo. But function "foo" uses as input argument rcx for the pointer.
I think the definition of in i386.md is the reason for this incorrect
behaviour. I sent a small patch which seems to solve this problem quite
well without side-effect.
Regards,
i.A. Kai T
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
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/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
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
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
1 - 100 of 160 matches
Mail list logo
