On 06/05/2013 17:41, Jason Merrill wrote:
> On 05/05/2013 09:57 AM, Dave Korn wrote:
>> This sounds like a bad idea to me, and not just because the locking
>> mechanism is dodgy. Is the problem more widespread than just your laptop?
>> Does it affect other host OSs? Linking
On 01/05/2013 03:02, Jason Merrill wrote:
> Since GNU Make doesn't support anything like the .MUTEX directive
> (http://savannah.gnu.org/bugs/?func=detailitem&item_id=17873), and
> accidentally doing "make -j8 -l4" makes my laptop useless for several
> minutes while it tries to link all the front e
On 12/04/2013 19:47, Janne Blomqvist wrote:
> As I don't have a Windows system to test on, I would appreciate if somebody
> more familiar with that platform could take a quick look. In particular, I
> *think* it should be Ok to use win32 API functions on Cygwin (that is,
> cygwin-gcc ships the win
On 09/04/2013 11:37, Kai Tietz wrote:
> Hmm, well in standard-case you are right. But well there is still a
> chance that GetProcAddress returns NULL-pointer ...
How would that actually happen? Removing any of those functions from libgcc
or libjava would be a very serious ABI breakage; we'r
On 22/03/2013 08:44, Kai Tietz wrote:
> 2013-03-22 Kai Tietz
>
> * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
> (__deregister_frame_info): Likewise.
Hi Kai,
I read your explanation of the problem relating to x86-64 memory models over
on the Cygwin de
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 ret
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
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
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 crt
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)
>
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
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.
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
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
On 12/03/2013 08:59, Richard Biener wrote:
> On Tue, Mar 12, 2013 at 2:44 AM, Dave Korn wrote:
>> Hello list,
>>
>> The attached patch makes -shared-libgcc the default for Cygwin. This is
>> something that I should have done some time ago, as shared libgcc on
o use my target maintainer's discretion to apply
it even at this late stage, but I figure it's so close to RC1 that I should
ask the RM's permission anyway.
I'd also like to backport it to all the currently-open branches.
gcc/ChangeLog
2013-03-12 Dave Korn
* confi
On 08/03/2013 00:11, Jonathan Wakely wrote:
> On 7 March 2013 23:53, Caroline Tice wrote:
>> I believe this patch addresses all of your comments; I modified the
>> configure.ac files to generate the configures, and I fixed the
>> spelling mistakes in the comments. I still get the warnings when
>>
On 21/02/2013 19:35, Anthony Green wrote:
> This patch looks fine, thanks. I don't plan to merge back into GCC
> for at least a week or two, so I think you should commit it to the GCC
> tree independently.
Committed to GCC revision 196527. Thanks!
cheers,
DaveK
On 27/02/2013 21:52, Tom Tromey wrote:
> I'm posting this now to get reactions to the probe before cleaning up
> the corresponding gdb patches for submission. I've built it both with
> and without sys/sdt.h, but I haven't yet run the test suite.
How did it build in the without sys/sdt.h case?
On 27/02/2013 19:53, Ludovic Courtès wrote:
> Dave Korn skribis:
>
>> On 26/02/2013 22:07, Ludovic Courtès wrote:
>>
>>> * Makefile.in (LDFLAGS): New variable.
>> "Import from automake" might be more informative.
>
> Automake has not
On 26/02/2013 22:07, Ludovic Courtès wrote:
> * Makefile.in (LDFLAGS): New variable.
"Import from automake" might be more informative.
cheers,
DaveK
On 12/02/2013 16:11, Sebastian Huber wrote:
> This patch from Alan Modra fixes a section type conflict error. See also
>
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02172.html
The Windows part is OK. I ran the g++ testsuite (gcc/, not libstdc) with no
change before and after.
cheers,
On 21/02/2013 19:35, Anthony Green wrote:
> On Thu, Feb 21, 2013 at 2:22 PM, Dave Korn wrote:
>> Gcc-patches: Assuming AG approves, can we commit this without waiting for
>> an
>> upstream libffi release and doing a full merge? Currently GCC HEAD won't
>>
suming AG approves, can we commit this without waiting for an
upstream libffi release and doing a full merge? Currently GCC HEAD won't
build libffi (and hence libjava) without it.
2013-02-21 Dave Korn
* src/closures.c (is_emutramp_enabled [!FFI_MMAP_EXEC_EMUTRAMP_PAX]):
On 22/02/2012 16:25, Pascal Obry wrote:
> Dave,
>
>> Pascal, ping?
>
> Sorry for the delay, these message has fallen into the crack!
No problem, I had plenty to be getting on with in the meantime :)
> Anyway, with these explanations I'm ok with the patch.
Thanks. Committed revision 1845
On 09/01/2012 11:56, Eric Botcazou wrote:
>> Sorry for the delay guys, I got rather busy over the holidays. I see
>> we're now discussing a patch for next stage 1.
>
> No, not necessarily, the patch is specific to Ada on Windows so the risk is
> quite low.
>
>> It does however solve the pro
On 09/02/2012 18:55, Kai Tietz wrote:
> Hmm, I interpret 'ifeq ($(strip $(filter-out alpha64 ia64 dec hp vms%
> openvms% alphavms%,$(host))),)' as anthing not mentioned here.
"If, after removing alpha64 ia64 dec hp vms% openvms% alphavms% (and stray
whitespace) from the host, what remains is equ
On 25/01/2012 03:27, Rafael Ávila de Espíndola wrote:
> Sorry, one more case that gcc accepts where it is not clear what the
> result should be:
>
> -
> #pragma GCC visibility push(protected)
>
> int x;
> class __attribute__((visibility("hidden"))) foo {
> static i
On 17/12/2011 10:06, Christian Joensson wrote:
> I can add that I also, manually, copy the
> lto-plugin/.libs/cyglto_plugin-0.dll into $bindir too.
Why? It deliberately installs into libexecsubdir rather than bindir because
it's only ever invoked by the gcc driver, which passes the full explic
On 17/12/2011 11:07, Eric Botcazou wrote:
>> I am happily using this patch and await this to be committed.
>
> Only after the import library issue is addressed. What do the other
> libraries
> bundled with GCC do here?
Sorry for the delay guys, I got rather busy over the holidays. I see we'
On 16/12/2011 09:01, Kai Tietz wrote:
> 2011/12/15 Dave Korn:
>> { dg-options "-mno-align-double" { target i?86-*-cygwin* i?86-*-mingw* } }
>> { dg-additional-options "-mno-ms-bitfields" { target i?86-*-mingw* } }
>>
>> ... so that MinGW gets both a
On 15/12/2011 17:44, Mike Stump wrote:
> On Dec 15, 2011, at 1:43 AM, Kai Tietz wrote:
>> This patch takes care that we are using for operator new/delete
>> replacement test static version on mingw-targets. As the shared (DLL)
>> version isn't able to have operator overload within DLL itself, as
On 15/12/2011 10:33, Kai Tietz wrote:
> -// { dg-options "-mno-align-double" { target i?86-*-cygwin* i?86-*-mingw* } }
> +// As for mingw target the the ms-bitfield switch is activated by default,
> +// make sure for this test that it is disabled.
> +// { dg-options "-mno-align-double -mno-ms-bitf
Hi again guys,
After the previous patch, there's still another bug remaining in the Ada
makefile, relating to how it builds and installs the gnat/gnarl shared
libraries.
Windows doesn't have any concept of an rpath in executables, nor of
LD_LIBRARY_PATH; all required DLLs must be found
On 04/12/2011 17:34, Eric Botcazou wrote:
> Ouch. :-) Please do something like this:
Righto, tweaked as you ask, updated patch attached for reference.
gcc/ada/ChangeLog:
2011-12-06 Dave Korn Index: gcc-interface/Makefile
On 23/11/2011 08:43, Eric Botcazou wrote:
> On 23/11/2011 07:28, Eric Botcazou wrote:
>>> /usr/local/src/trunk/objdir.withada/./gcc/xgcc
>>> -B/usr/local/src/trunk/objdir.withada/./gcc/
>>> -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem
>>> /usr/i686-pc-cygwin/include -isystem /usr/
On 13/04/2011 11:49, Pedro Alves wrote:
> On Wednesday 13 April 2011 11:43:43, Kai Tietz wrote:
>>> This is a default ABI change (IIRC, when the option was
>>> introduced, it was left off as default so to not break the ABI).
>>>
>>> Shouldn't we advertise it somewhere?
>
>> Yes, I did recently a l
On 08/11/2011 18:12, Rainer Orth wrote:
> Dave Korn writes:
>
>> Notice how in your additions, you prepend the t-mingw-pthread file to the
>> list in $tmake_file rather than append it as the existing code does.
>> Ordering
>> of t-* files in $tmake_file
On 30/10/2011 21:30, Gerald Pfeifer wrote:
> On Mon, 14 Jun 2010, Dave Korn wrote:
>> * htdocs/gcc-4.5/changes.html: Remove explicit mentions of ELF
>> format from LTO documentation.
>
> Ouch, I noticed this patch of yours never was applied, perhaps
> some misund
On 07/11/2011 18:39, Rainer Orth wrote:
> Christian Joensson
>> xgcc: error: unrecognized command line option ‘-pthread’
> [...]
>> Note the --enable-threads=posix.
>>
>> Backing off to revision 180766 does not yield this problem, while
>> 180767 has the problem.
>
> I erroneously moved the
have it defined. I'll do
a proper fix to parse the info out of the libjava/libtool-version file next
stage 1 but at least this keeps it up-to-date for forthcoming 4.7
Committed revision 181055, with the following changelog:
2011-11-06 Dave Korn Index: gcc/config/i38
On 24/03/2011 17:11, Paolo Bonzini wrote:
> The cygwin host fragment is using obsolete variables and constructs,
> modernize it.
>
> Committed to gcc and (shortly) src.
Thanks, top-level stuff is a bit of a mystery to me :)
cheers,
DaveK
On 22/03/2011 11:00, Kai Tietz wrote:
> I noticed this issue while working on those directory-separator thing
> for DOSish file-systems, and somehow this looks odd to me. For some
> reason the filenames.h header assumes for cygwin DOSish file-system,
> but in fact cygwin uses POSIXish file-system.
On 03/03/2011 23:00, Mike Stump wrote:
> On Mar 3, 2011, at 2:26 PM, Michael Snyder wrote:
>> DJ Delorie wrote:
As written, the function will access element [30] of a 30-element array.
>>> Um, no?
>> Y-uh-huh!
>
> fight fight fight... :-) There can be only one.
I was just wondering wheth
45 matches
Mail list logo
