Re: Implement C _FloatN, _FloatNx types [version 6]
On Aug 17 2016, Joseph Myers wrote:
> Index: gcc/testsuite/gcc.dg/torture/fp-int-convert-float128x-timode.c
> ===
> --- gcc/testsuite/gcc.dg/torture/fp-int-convert-float128x-timode.c
> (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/fp-int-convert-float128x-timode.c
> (working copy)
> @@ -0,0 +1,16 @@
> +/* Test floating-point conversions. _Float128x type with TImode. */
> +/* { dg-do run } */
> +/* { dg-options "" } */
> +/* { dg-add-options float128x } */
> +/* { dg-require-effective-target float128x_runtime } */
> +
> +#define __STDC_WANT_IEC_60559_TYPES_EXT__
> +#include
> +#include "fp-int-convert.h"
> +
> +int
> +main (void)
> +{
> + TEST_I_F(TItype, UTItype, _Float128, FLT128X_MANT_DIG, FLT128X_MAX_EXP);
s/_Float128/_Float128x/
> Index: gcc/testsuite/gcc.dg/torture/fp-int-convert-float32x-timode.c
> ===
> --- gcc/testsuite/gcc.dg/torture/fp-int-convert-float32x-timode.c
> (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/fp-int-convert-float32x-timode.c
> (working copy)
> @@ -0,0 +1,16 @@
> +/* Test floating-point conversions. _Float32x type with TImode. */
> +/* { dg-do run } */
> +/* { dg-options "" } */
> +/* { dg-add-options float32x } */
> +/* { dg-require-effective-target float32x_runtime } */
> +
> +#define __STDC_WANT_IEC_60559_TYPES_EXT__
> +#include
> +#include "fp-int-convert.h"
> +
> +int
> +main (void)
> +{
> + TEST_I_F(TItype, UTItype, _Float32, FLT32X_MANT_DIG, FLT32X_MAX_EXP);
s/_Float32/_Float32x/
> Index: gcc/testsuite/gcc.dg/torture/fp-int-convert-float64x-timode.c
> ===
> --- gcc/testsuite/gcc.dg/torture/fp-int-convert-float64x-timode.c
> (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/fp-int-convert-float64x-timode.c
> (working copy)
> @@ -0,0 +1,16 @@
> +/* Test floating-point conversions. _Float64x type with TImode. */
> +/* { dg-do run } */
> +/* { dg-options "" } */
> +/* { dg-add-options float64x } */
> +/* { dg-require-effective-target float64x_runtime } */
> +
> +#define __STDC_WANT_IEC_60559_TYPES_EXT__
> +#include
> +#include "fp-int-convert.h"
> +
> +int
> +main (void)
> +{
> + TEST_I_F(TItype, UTItype, _Float64, FLT64X_MANT_DIG, FLT64X_MAX_EXP);
s/_Float64/_Float64x/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [PATCH build/doc] Replacing libiberty with gnulib
Bootstrapped with multiple languages and multilib enabled for maximum coverage. Regression tested on x86_64-apple-darwin15.5.0 and x86_64-linux PFA the patch 2016-08-21 Ayush Goel * Makefile.def: Added gnulib as build & host library and dependency of all-gcc on gnulib * Makefile.in: regenerated * configure.ac: Added gnulib as build and host library * configure: regenerated * gcc/Makefile.in: Added path to gnulib static library (libgnu.a) and gnulib header files * gcc/mkconfig.sh: Included gnulib’s config.h * gcc/doc/sourcebuild.texi: Added gnulib and how to use the update script to update/import gnu lib modules * gnulib: created directory * gnulib/Makefile.in: new file * gnulib/configure.ac: new file * gnulib/update-gnulib.sh: script to import gnulib modules using gnulib-tool * gnulib/import: created by update-gnulib.sh * gnulib/import/Makefile.in: imported from gnulib * gnulib/import/alignof.h: Imported from gnulib * gnulib/import/exitfail.c: Imported from gnulib * gnulib/import/exitfail.h: Imported from gnulib * gnulib/import/extra: Imported from gnulib * gnulib/import/extra/snippet: Imported from gnulib * gnulib/import/extra/snippet/_Noreturn.h: Imported from gnulib * gnulib/import/extra/snippet/arg-nonnull.h: Imported from gnulib * gnulib/import/extra/snippet/c++defs.h: Imported from gnulib * gnulib/import/extra/snippet/warn-on-use.h: Imported from gnulib * gnulib/import/gettext.h: Imported from gnulib * gnulib/import/m4: Imported from gnulib * gnulib/import/m4/00gnulib.m4: Imported from gnulib * gnulib/import/m4/absolute-header.m4: Imported from gnulib * gnulib/import/m4/extern-inline.m4: Imported from gnulib * gnulib/import/m4/gnulib-cache.m4: Imported from gnulib * gnulib/import/m4/gnulib-common.m4: Imported from gnulib * gnulib/import/m4/gnulib-comp.m4: Imported from gnulib * gnulib/import/m4/gnulib-tool.m4: Imported from gnulib * gnulib/import/m4/include_next.m4: Imported from gnulib * gnulib/import/m4/longlong.m4: Imported from gnulib * gnulib/import/m4/multiarch.m4: Imported from gnulib * gnulib/import/m4/obstack.m4: Imported from gnulib * gnulib/import/m4/off_t.m4: Imported from gnulib * gnulib/import/m4/ssize_t.m4: Imported from gnulib * gnulib/import/m4/stddef_h.m4: Imported from gnulib * gnulib/import/m4/stdint.m4: Imported from gnulib * gnulib/import/m4/stdlib_h.m4: Imported from gnulib * gnulib/import/m4/sys_types_h.m4: Imported from gnulib * gnulib/import/m4/unistd_h.m4: Imported from gnulib * gnulib/import/m4/warn-on-use.m4: Imported from gnulib * gnulib/import/m4/wchar_t.m4: Imported from gnulib * gnulib/import/obstack.c: Imported from gnulib * gnulib/import/obstack.h: Imported from gnulib * gnulib/import/stddef.in.h: Imported from gnulib * gnulib/import/stdint.in.h: Imported from gnulib * gnulib/import/stdlib.in.h: Imported from gnulib * gnulib/import/sys: Imported from gnulib * gnulib/import/sys_types.in.h: Imported from gnulib * gnulib/import/unistd.c: Imported from gnulib * gnulib/import/unistd.in.h: Imported from gnulib * gnulib/stamp-h1: generated -Ayush On 20 August 2016 at 8:52:56 PM, Manuel López-Ibáñez (lopeziba...@gmail.com) wrote: > On 20 August 2016 at 11:22, ayush goel wrote: > >> > >> We're talking about a one-line change, but this is absolutely > >> crucial and central to use of gnulib. Until this is correct, > >> any previous host-specific testing is invalid, unfortunately. > >> > >> In the previous revision, you had: > >> > >> INCGNU = -I../gnulib -I$(srcdir)/../gnulib/import > >> > >> and I was expecting to see in the new revision something > >> like: > >> > >> INCGNU = -I../gnulib/import -I$(srcdir)/../gnulib/import > >> > >> or perhaps even better: > >> > >> INCGNU = -I$(build_libobjdir)/gnulib/import -I$(srcdir)/../gnulib/import > >> > >> Try hacking one of the generated replacement headers, one that gcc > >> is sure to include, to cause a compilation error. E.g. add an #error call > >> to the generated gnulib/import/unistd.h. If a gcc build, from scratch since > >> there are no Makefile dependencies, still compiles with that, then we're > >> still not picking the right headers. > > > > So your concern seems valid, however the build process seems to pick > > the correct headers. > > I did try to raise an error from the gnulib generated header unitstd.h > > and it gives me a compile time error: > > Perhaps adding #error is not the best way to test this, since gnulib > may still pick the correct headers, but gcc the wrong ones and the > error you showed happens when building gnulib. A better way, perhaps, > would be to add to unitsdt.h something like > > #define unitstd_h_gnulib > > then in some gcc/ file that includes this header, like gcov-tool.c or > system.h, you can do just after the #include > > #ifndef unitstd_h_gnulib > #error "unitstd_h_gnulib not defined" > #endif > > Test that it fails when not having the correct INCGNU and that it > works when having it. This should settle it, I hope. > > Cheers, > > Manuel. > importgnulib_8_21.patch Descript
Re: [PATCH] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects
On Fri, Jul 29, 2016 at 11:22:18AM -0600, Jeff Law wrote: > On 07/29/2016 11:19 AM, Gleb Natapov wrote: > > > > I'll table your patch on that assumption. > > OK. Can you ping him about it after he will back or should I (although in > > another week I will be on PTO :))? We are suffering from unwind > > scalability problems in C++ exceptions and although this one patch will > > not solve the issue it will leave only one lock in dl_iterate_phdr to > > deal with. > Jakub is quite good about monitoring his in-progress patches. I'm confident > he'll address it after he returns. > Jakub, is there a reason to not apply https://gcc.gnu.org/bugzilla/attachment.cgi?id=38852? -- Gleb.
Re: [PATCHv2] do not throw in std::make_exception_ptr
Jonathan,
Is this version OK with you?
On Fri, Aug 05, 2016 at 07:49:24AM +0300, Gleb Natapov wrote:
> Instead of throwing an exception allocate its memory and initialize it
> explicitly. Makes std::make_exception_ptr more efficient since no stack
> unwinding is needed.
>
> v1->v2:
> - fix indentation
> - drop static from __dest_thunk
> - use static_cast instead of reinterpret_cast
>
> * libsupc++/exception (std::exception): Move...
> * libsupc++/exception.h: ...here; New.
> * libsupc++/cxxabi.h (__cxa_allocate_exception): Move...
> * libsupc++/cxxabi_init_exception.h: ...here and add
> __cxa_init_primary_exception; New.
> * config/abi/pre/gnu-versioned-namespace.ver: add
> __cxa_init_primary_exception and std::exception_ptr(void*)
> * config/abi/pre/gnu.ver (CXXABI_1.3.11) : add
> __cxa_init_primary_exception and std::exception_ptr(void*)
> (CXXABI_1.3.11): New.
> * include/Makefile.am: add exception.h and cxxabi_init_exception.h
> * include/Makefile.in: Likewise.
> * libsupc++/Makefile.am: add exception.h and cxxabi_init_exception.h
> * libsupc++/Makefile.in: Likewise.
> * libsupc++/eh_throw.cc(__cxa_throw): add __cxa_init_primary_exception
> and use it
> * libsupc++/exception_ptr.h(std::make_exception_ptr): use
> __cxa_allocate_exception and __cxa_init_primary_exception to create
> exception pointer
> * libsupc++/typeinfo: include bits/exception.h instead of exception
>
>
> diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> index 8304dee..65866a3 100644
> --- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> @@ -179,6 +179,7 @@ CXXABI_2.0 {
> __cxa_free_exception;
> __cxa_free_dependent_exception;
> __cxa_get_exception_ptr;
> +__cxa_init_primary_exception;
> __cxa_get_globals;
> __cxa_get_globals_fast;
> __cxa_guard_abort;
> @@ -205,6 +206,7 @@ CXXABI_2.0 {
> # std::exception_ptr
> _ZNSt15__exception_ptr13exception_ptrC1Ev;
> _ZNSt15__exception_ptr13exception_ptrC2Ev;
> +_ZNSt15__exception_ptr13exception_ptrC1EPv;
> _ZNSt15__exception_ptr13exception_ptrC1ERKS0_;
> _ZNSt15__exception_ptr13exception_ptrC2ERKS0_;
> _ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE;
> diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
> b/libstdc++-v3/config/abi/pre/gnu.ver
> index b7f54e2..f51c6f9 100644
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2164,6 +2164,13 @@ CXXABI_1.3.10 {
>
> } CXXABI_1.3.9;
>
> +CXXABI_1.3.11 {
> +
> +__cxa_init_primary_exception;
> +_ZNSt15__exception_ptr13exception_ptrC1EPv;
> +
> +} CXXABI_1.3.10;
> +
> # Symbols in the support library (libsupc++) supporting transactional memory.
> CXXABI_TM_1 {
>
> diff --git a/libstdc++-v3/include/Makefile.am
> b/libstdc++-v3/include/Makefile.am
> index e2c4f63..b91453f 100644
> --- a/libstdc++-v3/include/Makefile.am
> +++ b/libstdc++-v3/include/Makefile.am
> @@ -205,6 +205,8 @@ bits_sup_headers = \
> ${bits_sup_srcdir}/cxxabi_forced.h \
> ${bits_sup_srcdir}/exception_defines.h \
> ${bits_sup_srcdir}/exception_ptr.h \
> + ${bits_sup_srcdir}/exception.h \
> + ${bits_sup_srcdir}/cxxabi_init_exception.h \
> ${bits_sup_srcdir}/hash_bytes.h \
> ${bits_sup_srcdir}/nested_exception.h
>
> diff --git a/libstdc++-v3/include/Makefile.in
> b/libstdc++-v3/include/Makefile.in
> index 882ff14..1259ad4 100644
> --- a/libstdc++-v3/include/Makefile.in
> +++ b/libstdc++-v3/include/Makefile.in
> @@ -495,6 +495,8 @@ bits_sup_headers = \
> ${bits_sup_srcdir}/cxxabi_forced.h \
> ${bits_sup_srcdir}/exception_defines.h \
> ${bits_sup_srcdir}/exception_ptr.h \
> + ${bits_sup_srcdir}/exception.h \
> + ${bits_sup_srcdir}/cxxabi_init_exception.h \
> ${bits_sup_srcdir}/hash_bytes.h \
> ${bits_sup_srcdir}/nested_exception.h
>
> diff --git a/libstdc++-v3/libsupc++/Makefile.am
> b/libstdc++-v3/libsupc++/Makefile.am
> index b45b5ae..ba4eac1 100644
> --- a/libstdc++-v3/libsupc++/Makefile.am
> +++ b/libstdc++-v3/libsupc++/Makefile.am
> @@ -35,7 +35,7 @@ std_HEADERS = \
>
> bits_HEADERS = \
> atomic_lockfree_defines.h cxxabi_forced.h \
> - exception_defines.h exception_ptr.h hash_bytes.h nested_exception.h
> + exception_defines.h exception_ptr.h hash_bytes.h nested_exception.h
> exception.h cxxabi_init_exception.h
>
> headers = $(std_HEADERS) $(bits_HEADERS)
>
> diff --git a/libstdc++-v3/libsupc++/Makefile.in
> b/libstdc++-v3/libsupc++/Makefile.in
> index f3648ac..3fb9d16 100644
> --- a/libstdc++-v3/libsupc++/Makefile.in
> +++ b/libstdc++-v3/libsupc++/Makefile.in
> @@ -395,7 +395,7 @@ std_HEADERS = \
>
> bits_HEADERS = \
> atomic_lockfree_defines.h cxxabi_forced.h \
> - exception_defines.h exception_ptr.h hash_bytes.h nested_exception.h
> + exception_defines.h exception_ptr.h hash
Re: [PATCH] Fix PR77290
$ gcc/gfortran -B gcc/ -B aarch64-suse-linux/libgfortran/ -std=legacy -floop-nest-optimize -O2 -S ../gcc/testsuite/gfortran.dg/graphite/pr68279.f90 isl_aff.c:1001: position out of bounds ../gcc/testsuite/gfortran.dg/graphite/pr68279.f90:8:0: SUBROUTINE stack_binning(params_in, params_out, stack_size) internal compiler error: Aborted 0xbb3e0f crash_signal ../../gcc/toplev.c:335 0x112a33b extract_affine_chrec ../../gcc/graphite-sese-to-poly.c:239 0x112a33b extract_affine ../../gcc/graphite-sese-to-poly.c:381 0x112a1d7 extract_affine ../../gcc/graphite-sese-to-poly.c:421 0x112a1d7 extract_affine ../../gcc/graphite-sese-to-poly.c:421 0x112b36b add_condition_to_pbb ../../gcc/graphite-sese-to-poly.c:458 0x112b36b add_conditions_to_domain ../../gcc/graphite-sese-to-poly.c:525 0x112b36b build_iteration_domains ../../gcc/graphite-sese-to-poly.c:1017 0x112b0fb build_iteration_domains ../../gcc/graphite-sese-to-poly.c:1040 0x112b957 build_poly_scop(scop*) ../../gcc/graphite-sese-to-poly.c:1364 0x1115abf graphite_transform_loops() ../../gcc/graphite.c:319 0x111600f graphite_transforms ../../gcc/graphite.c:356 0x111600f execute ../../gcc/graphite.c:433 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [patch, Fortran] Fix PR 71902
Le 18/08/2016 à 21:24, Thomas Koenig a écrit : Hello Mikael, This doesn't look correct, what about substrings following component or array references? You're right; corrected in the attached patch. I have also added a test case for this. PS: What about the original fix, wasn't it a dependency problem/inaccuracy after all? The main error was using the allocatable attribute on the symbol that we were dealing with a deferred length. Changing the test to check for expr->ts.deferred is the right thing to do. Seems sensible. However deferred length includes pointers as well, so I would still keep additionally the original test for allocatable-ness. Or even better replace it with gfc_expr_attr(expr1).allocatable. OK with that change. Thanks Mikael
[patch] [gsoc] [gimplefe] GIMPLE FE Project
Hi all, As a part of my gsoc project. I have completed the following tasks: * Parsed gimple-expression * Parsed gimple-labels * Parsed local declaration * Parsed gimple-goto statement * Parsed gimple-if-else statement * Parsed gimple-switch statement * Parsed gimple-return statement * Parsed gimple-PHI function * Parsed gimple ssa-names along with default def * Parsed gimple-call * Hacked pass manager to add support for startwith (pass-name) to skip early opt passes * Modified gimple dump for making it parsable I am willing to continue work on the project, some TODOs for the projects are: * Error handling * Parse more gimple syntax * Add startwith support for IPA passes The complete code of gimple fe project can be found at https://github.com/PrasadG193/gcc_gimple_fe PFA patch for complete project (rebased for latest trunk revision). I have successfully bootstrapped and tested on x86_64-pc-linux-gnu. Some testcases failed due to modified gimple dump as expected. Thanks, Prasad ChangeLog.patch Description: Binary data gimplefe.patch Description: Binary data testcases.patch Description: Binary data
Re: [ARM][PATCH] Add support for overflow add, sub, and neg operations
On 13 August 2016 at 00:00, Michael Collison wrote:
> Christophe,
>
> I have resolved the issue you identified. I had not update my upstream patch
> with a previous fix I had made to the usubv pattern. Tested and bootstrapped
> on arm hardware.
>
Hi Michael,
Indeed, I can confirm that I no longer see the regressions I reported
with the previous version. The new tests now pass.
Thanks
Christophe
> This patch improves code generations for builtin arithmetic overflow
> operations for the arm backend. As an example for a simple test case such as:
>
> Sure for a simple test case such as:
>
> int
> fn3 (int x, int y, int *ovf)
> {
> int res;
> *ovf = __builtin_sadd_overflow (x, y, &res);
> return res;
> }
>
> Current trunk at -O2 generates
>
> fn3:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> cmp r1, #0
> mov r3, #0
> add r1, r0, r1
> blt .L4
> cmp r1, r0
> blt .L3
> .L2:
> str r3, [r2]
> mov r0, r1
> bx lr
> .L4:
> cmp r1, r0
> ble .L2
> .L3:
> mov r3, #1
> b .L2
>
> With the patch this now generates:
>
>addsr0, r0, r1
>movvs r3, #1
>movvc r3, #0
>str r3, [r2]
>bx lr
>
> Ok for trunk?
>
> 2016-07-27 Michael Collison
> Michael Collison
>
> * config/arm/arm-modes.def: Add new condition code mode CC_V
> to represent the overflow bit.
> * config/arm/arm.c (maybe_get_arm_condition_code):
> Add support for CC_Vmode.
> (arm_gen_unlikely_cbranch): New function to generate common
> rtl conditional branches for overflow patterns.
> * config/arm/arm-protos.h: Add prototype for
> arm_gen_unlikely_cbranch.
> * config/arm/arm.md (addv4, add3_compareV,
> addsi3_compareV_upper): New patterns to support signed
> builtin overflow add operations.
> (uaddv4, add3_compareC, addsi3_compareV_upper):
> New patterns to support unsigned builtin add overflow operations.
> (subv4, sub3_compare1): New patterns to support signed
> builtin overflow subtract operations,
> (usubv4): New patterns to support unsigned builtin subtract
> overflow operations.
> (negvsi3, negvdi3, negdi2_compare, negsi2_carryin_compare): New
> patterns
> to support builtin overflow negate operations.
> * gcc.target/arm/builtin_saddl.c: New testcase.
> * gcc.target/arm/builtin_saddll.c: New testcase.
> * gcc.target/arm/builtin_uaddl.c: New testcase.
> * gcc.target/arm/builtin_uaddll.c: New testcase.
> * gcc.target/arm/builtin_ssubl.c: New testcase.
> * gcc.target/arm/builtin_ssubll.c: New testcase.
> * gcc.target/arm/builtin_usubl.c: New testcase.
> * gcc.target/arm/builtin_usubll.c: New testcase.
>
> -Original Message-
> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> Sent: Wednesday, August 03, 2016 6:00 AM
> To: Michael Collison
> Cc: gcc-patches@gcc.gnu.org; James Greenhalgh; Kyrylo Tkachov; nd
> Subject: Re: [ARM][PATCH] Add support for overflow add, sub, and neg
> operations
>
> On 2 August 2016 at 10:13, Michael Collison wrote:
>> Hi,
>>
>> This patch improves code generations for builtin arithmetic overflow
>> operations for the arm backend. As an example for a simple test case such as:
>>
>> int
>> fn3 (int x, int y, int *ovf)
>> {
>> int res;
>> *ovf = __builtin_sadd_overflow (x, y, &res);
>> return res;
>> }
>>
>> Current trunk at -O2 generates
>>
>> fn3:
>> @ args = 0, pretend = 0, frame = 0
>> @ frame_needed = 0, uses_anonymous_args = 0
>> @ link register save eliminated.
>> cmp r1, #0
>> mov r3, #0
>> add r1, r0, r1
>> blt .L4
>> cmp r1, r0
>> blt .L3
>> .L2:
>> str r3, [r2]
>> mov r0, r1
>> bx lr
>> .L4:
>> cmp r1, r0
>> ble .L2
>> .L3:
>> mov r3, #1
>> b .L2
>>
>> With the patch this now generates:
>>
>>addsr0, r0, r1
>>movvs r3, #1
>>movvc r3, #0
>>str r3, [r2]
>>bx lr
>>
>> Ok for trunk?
>>
>
> Hi Michael,
>
> I've run validations with your patch, and I am seeing several failures during
> tests execution:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/239008-bugzilla-69663-upstream-final/report-build-info.html
>
> I'm using qemu 2.6.0.
>
> Did you run validation on actual HW? It could be a qemu bug, but I haven't
> tried to manually reproduce the problem yet.
>
> Christophe.
>
>
>> 2016-07-27 Michael Collison
>> Michael Collison
>>
>> * config/arm/arm-modes.def: Add new condition code
Re: Importing gnulib into the gcc tree
Hi Ayush,
On Mon, 18 Jul 2016, ayush goel wrote:
> I’m attaching a patch just containing the changes made in the /doc.
a couple of comments.
Index: gnulib-import.texi
===
--- gnulib-import.texi (nonexistent)
+++ gnulib-import.texi (working copy)
@@ -0,0 +1,16 @@
+@c Copyright (C) 1988-2016 Free Software Foundation, Inc.
For a new file, just 2016 should be fine.
+In order to import a new module from gnulib, the following steps need to be
executed, in order.
This line is a bit long; try to avoid more than 78 columns (80 being the
strict maximum). Same also below.
+Enter the name of the module to be imported in src/gnulib/update-gnulib.sh
under IMPORTED_GNULIB_MODULES.
That is a filename, thus @file{src/gnulib/update-gnulib.sh}.
And @code{IMPORTED_GNULIB_MODULES}.
+@item
+Run the file update-gnulib.sh. Usage: update-gnulib.sh
I'm not completely sure whether @file{update-gnulib.sh} or
@command{update-gnulib.sh}; feels like a corner case.
And @var{path-to-gnulib-repository}.
Invocations usally are marked up as
@smallexample
gcc -o out -O2 in.c plus.c
@end smallexample
With those changes, the documentation changes seem fine.
Gerald
Re: [Patch] Disable text mode translation in ada for Cygwin
On Fri, 19 Aug 2016, Arnaud Charlet wrote: >>> Text mode translation should not be done for Cygwin, especially since >>> it does not support unicode setmode calls. This also fixes ada builds >>> for Cygwin. >> Ping? > Can you send the link to your original submission for easy retrieval? I'm not JonY, but here is the link: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02088.html Gerald
[PATCH, i386]: Fine tune prefetchw emission (PR 77270)
Hello!
Attached patch fine-tunes the condition when prefetchw write prefetch
insns are emitted. prefetchw is preferred for non-SSE2 K7 athlons
(this is covered by i386-prefetch.exp tests), on the other hand, SSE
prefetches are preferred for K8 targets, as measured and reported in
PR 77270.
For newer targets, PRFCHW cpuid bit is respected, and -march=native
correctly emits prefetchw, when PRFCHW cpuid bit is set. (on a related
note, PTA_PRFCHW should probably be set for amdfam10+ targets,
Venkataramanan is looking into this issue).
2016-08-21 Uros Bizjak
PR target/77270
* config/i386/i386.md (prefetch): When TARGET_PRFCHW or
TARGET_PREFETCHWT1 are disabled, emit 3dNOW! write prefetches for
non-SSE2 athlons only, otherwise prefer SSE prefetches.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: i386.md
===
--- i386.md (revision 239642)
+++ i386.md (working copy)
@@ -18634,20 +18634,24 @@
gcc_assert (IN_RANGE (locality, 0, 3));
/* Use 3dNOW prefetch in case we are asking for write prefetch not
- supported by SSE counterpart or the SSE prefetch is not available
- (K6 machines). Otherwise use SSE prefetch as it allows specifying
- of locality. */
+ supported by SSE counterpart (non-SSE2 athlon machines) or the
+ SSE prefetch is not available (K6 machines). Otherwise use SSE
+ prefetch as it allows specifying of locality. */
if (write)
{
if (TARGET_PREFETCHWT1)
operands[2] = GEN_INT (MAX (locality, 2));
- else if (TARGET_3DNOW || TARGET_PRFCHW)
+ else if (TARGET_PRFCHW)
operands[2] = GEN_INT (3);
+ else if (TARGET_3DNOW && !TARGET_SSE2)
+ operands[2] = GEN_INT (3);
+ else if (TARGET_PREFETCH_SSE)
+ operands[1] = const0_rtx;
else
{
- gcc_assert (TARGET_PREFETCH_SSE);
- operands[1] = const0_rtx;
+ gcc_assert (TARGET_3DNOW);
+ operands[2] = GEN_INT (3);
}
}
else
Re: [PATCH build/doc] Replacing libiberty with gnulib
On 08/20/2016 11:22 AM, ayush goel wrote: > So your concern seems valid, however the build process seems to pick > the correct headers. I tried it now and it does _not_ pick the correct headers. My concern is definitely valid. More below. > I did try to raise an error from the gnulib generated header unitstd.h > and it gives me a compile time error: > > -- > gcc -DHAVE_CONFIG_H -I. -I/Users/ayushgoel/gsoc/src/gnulib/import -I.. > -g -O2 -MT exitfail.o -MD -MP -MF .deps/exitfail.Tpo -c -o > exitfail.o /Users/ayushgoel/gsoc/src/gnulib/import/exitfail.c > gcc -DHAVE_CONFIG_H -I. -I/Users/ayushgoel/gsoc/src/gnulib/import -I.. > -g -O2 -MT unistd.o -MD -MP -MF .deps/unistd.Tpo -c -o unistd.o > /Users/ayushgoel/gsoc/src/gnulib/import/unistd.c > gcc -DHAVE_CONFIG_H -I. -I/Users/ayushgoel/gsoc/src/gnulib/import -I.. > -g -O2 -MT obstack.o -MD -MP -MF .deps/obstack.Tpo -c -o obstack.o > /Users/ayushgoel/gsoc/src/gnulib/import/obstack.c > In file included from /Users/ayushgoel/gsoc/src/gnulib/import/unistd.c:3: > ./unistd.h:18:2: error: “Unistd header file being invoked" > #error “unistd from gnulib being invoked" > ^ This is building _gnulib_ itself, which has its own configure/Makefile. We're talking about gcc/Makefile.in, and the need to confirm that we're picking the gnulib replacement headers when building _gcc/_ sources. I just tried it myself now. And as I was saying, the '-I../gnulib/import' really _is_ necessary. With the corrected: INCGNU = -I../gnulib/import -I$(srcdir)/../gnulib/import ... hacking the generated gnulib/import/unistd.h and then compiling any gcc/ file (simply cd gcc; make) errors out with: $ make g++ -fno-PIE -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g3 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I/home/pedro/src/gcc/src/gcc -I/home/pedro/src/gcc/src/gcc/c-family -I/home/pedro/src/gcc/src/gcc/../include -I/home/pedro/src/gcc/src/gcc/../libcpp/include -I/home/pedro/brno/pedro/src/gcc/build/./gmp -I/home/pedro/src/gcc/src/gmp -I/home/pedro/brno/pedro/src/gcc/build/./mpfr/src -I/home/pedro/src/gcc/src/mpfr/src -I/home/pedro/src/gcc/src/mpc/src -I/home/pedro/src/gcc/src/gcc/../libdecnumber -I/home/pedro/src/gcc/src/gcc/../libdecnumber/bid -I../libdecnumber -I/home/pedro/src/gcc/src/gcc/../libbacktrace -I../gnulib/import -I/home/pedro/src/gcc/src/gcc/../gnulib/import -o c-family/c-omp.o -MT c-family/c-omp.o -MMD -MP -MF c-family/.deps/c-omp.TPo /home/pedro/src/gcc/src/gcc/c-family/c-omp.c In file included from /home/pedro/src/gcc/src/gcc/system.h:294:0, from /home/pedro/src/gcc/src/gcc/c-family/c-omp.c:25: ../gnulib/import/unistd.h:1:2: error: #error gnulib header included #error gnulib header included ^ Makefile:1104: recipe for target 'c-family/c-omp.o' failed make: *** [c-family/c-omp.o] Error 1 ... which is good. However, with the original (incorrect): INCGNU = -I$(srcdir)/../gnulib/import (i.e., only point at the srcdir, and not at the generated headers) ... the #error doesn't trigger, and the gcc/ build finishes, meaning the system unistd.h was included directly, which is incorrect. BTW, a branch somewhere with the configure etc. regenerated plus gnulib/import already imported would have made it _so_ much easier for me to try this. Can you do that? As I explained before, that should make it easier for other people to try on others hosts as well. > config.status: creating config.h > 1 error generated. > make[5]: *** [unistd.o] Error 1 > > Also, I’m sure of the fact that gnulib headers are being used because > all the functions that I’ve replaced from libiberty, I locally removed > both the .c and .h files from libiberty to confirm that the gnulib’s > version is indeed being used, and it compiled just fine. That's most probably because you're replacing libiberty's obstack.h with gnulib's, and that gnulib header is found in gnulib's _source_ directory, not in the gnulib build directory. With your current patch, these are the files that are being generated, and that weren't picked up in the include path (but must be): $ find build/gnulib/import/ -name "*.h" build/gnulib/import/sys/types.h build/gnulib/import/stdlib.h build/gnulib/import/arg-nonnull.h build/gnulib/import/warn-on-use.h build/gnulib/import/c++defs.h build/gnulib/import/unistd.h as more gnulib modules get imported, more headers will appear here. > So my understanding of this is that the gnulib.h is also required to > be included inside bconfig.h? > Yes. Thanks, Pedro Alves
C++11? (Re: protected alloca class for malloc fallback)
On 08/20/2016 03:29 AM, Mike Stump wrote: > On Aug 10, 2016, at 10:03 AM, Oleg Endo wrote: >> >> Or just wait until people have agreed to switch to C++11 or C++14. I >> don't think in practice anybody uses an C++11-incapable GCC to build a >> newer GCC these days. gdb will drop support for building with a C compiler any week now, and even though we're starting out with C++03, just like gcc, it'd be great to require C++11 (or later). Having gcc itself switch to C++11 too would make proposing it for gdb so much easier... So +1 from me, FWIW. :-) > > I use the system gcc 4.4.7 on RHEL to build a newer cross compiler... I > could bootstrap a newer native compiler, if I had too. > Yeah. I wonder whether the community would in general be fine with that too. Thanks, Pedro Alves
Re: [PATCH] tree-optimization/71831 - __builtin_object_size poor results with no optimization
On 08/20/2016 01:26 AM, Jakub Jelinek wrote:
On Fri, Aug 19, 2016 at 04:30:47PM -0600, Martin Sebor wrote:
The patch looks bigger than it actually is because:
1) It modifies the return type of the function to bool rather than
unsigned HOST_WIDE_INT representing the object size (this was
necessary to avoid having its callers misinterpret zero as
unknown when it means zero bytes).
Can you explain why do you need this? I don't understand why do you need to
differentiate between unknown and maximum (or minimum for modes 2 and 3 that
nobody actually uses in real-world), the builtin after all returns the same
value for both. If you want to know if the compiler knows the size
precisely, you can request both mode 0 (or 1) and 2 (or 3) and compare, if
the values are the same, it is the exact size, if there is a range, then you
have minimum and maximum (and, if minimum is 0, but maximum non-zero, you
really don't know minimum, if maximum is -1, then you really don't know the
maximum (no object should be better that big). For the return value, I
don't see how you could reliably differentiate between the two even if it
made for whatever strange reason sense - for SSA_NAMEs etc. you have just
recorded the sizes, not also a flag whether it is unknown or known.
The change makes it possible to fold into constants even at -O0 type
2 and 3 calls to the built-in with zero-sized objects.
fold_builtin_object_size repeatedly calls compute_builtin_object_size
to compute the same result (zero) only to interpret it as a failure
and try over and over, never succeeding. The built-in call is
ultimately expanded into a zero but that's too late to eliminate code
that depends on it. For example, the following emits the call to abort
that's never executed.
char a[2];
void f (void)
{
if (__builtin_object_size (a + 2, 2) != 0)
__builtin_abort ();
}
With the change, compute_builtin_object_size is called just once and
the call to abort is not emitted.
The initial version of the test verified this folding but adding code
to work around the built-ins various idiosyncrasies inadvertently wound
up removing it. The attached patch adds a new test to exercise this
folding.
2) As a result of a small change to the conditional that controls
the main algorithm of the compute_builtin_object_size function
it changes the depth of its indentation (without actually
changing any of the code there).
If you've done lots of redindentation, then additionally diff -upb would be
appreciated.
Sure. The attached diff was created without regard to whitespace.
Martin
PR tree-optimization/71831 - __builtin_object_size poor results with no
optimization
gcc/testsuite/ChangeLog:
2016-08-21 Martin Sebor
PR tree-optimization/71831
* gcc.dg/builtin-object-size-16.c: New test.
* gcc.dg/builtin-object-size-17.c: New test.
gcc/ChangeLog:
2016-08-21 Martin Sebor
PR tree-optimization/71831
* tree-object-size.h: Return bool instead of the size and add
argument for the size.
* tree-object-size.c (compute_object_offset): Update signature.
(addr_object_size): Same.
(compute_builtin_object_size): Return bool instead of the size
and add argument for the size. Handle POINTER_PLUS_EXPR when
optimization is disabled.
(expr_object_size): Adjust.
(plus_stmt_object_size): Adjust.
(pass_object_sizes::execute): Adjust.
* builtins.c (fold_builtin_object_size): Adjust.
* doc/extend.texi (Object Size Checking): Update.
* ubsan.c (instrument_object_size): Adjust.
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 03a0dc8..5d0c1af 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -9610,7 +9610,7 @@ fold_builtin_object_size (tree ptr, tree ost)
if (TREE_CODE (ptr) == ADDR_EXPR)
{
- bytes = compute_builtin_object_size (ptr, object_size_type);
+ compute_builtin_object_size (ptr, object_size_type, &bytes);
if (wi::fits_to_tree_p (bytes, size_type_node))
return build_int_cstu (size_type_node, bytes);
}
@@ -9619,8 +9619,7 @@ fold_builtin_object_size (tree ptr, tree ost)
/* If object size is not known yet, delay folding until
later. Maybe subsequent passes will help determining
it. */
- bytes = compute_builtin_object_size (ptr, object_size_type);
- if (bytes != (unsigned HOST_WIDE_INT) (object_size_type < 2 ? -1 : 0)
+ if (compute_builtin_object_size (ptr, object_size_type, &bytes)
&& wi::fits_to_tree_p (bytes, size_type_node))
return build_int_cstu (size_type_node, bytes);
}
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5285e00..d9dc137 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10009,8 +10009,15 @@ __atomic_store_n(&lockvar, 0, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE);
@findex __builtin___fprintf_chk
@findex __builtin___vfprintf_chk
-GCC implements a limited buffer overflow protection mechanism
-that can prevent some buffer overflow attacks.
+GCC implements a limited buffer overflo
Re: [PATCH] Fix warning breaking profiled bootstrap
> Consider the case where sym1 results in a non-null return value (and > initializes neg1/inv1), but sym2 results in a null return value, leaving > neg2/inv2 undefined, but cst2 is can still be true (ADDR_EXPR with an > invariant address comes to mind). > > Thus we can get into these statements: > > >tree cst = cst1 ? val1 : val2; >tree inv = cst1 ? inv2 : inv1; > > > Note carefully how they test cst1 and depending on its value, they may > read val2 or inv2. The key here is that cst1 cannot be true if sym1 is non-null, same for cst2 and sym2. The code is guarded with: /* If one is of the form '[-]NAME + CST' and the other is constant, then it might be possible to say something depending on the constants. */ if ((sym1 && inv1 && cst2) || (sym2 && inv2 && cst1)) If this is the first case, then cst1 is false and val2 and inv1 are read. If this is the second case, then cst1 is true and val1 and inv2 are read. So inv2 is read only in the second case, and is initialized. -- Eric Botcazou
Re: [PATCH] Restrict jump threading statement simplifier to scalar types (PR71077)
On Sat, 20 Aug 2016, Uros Bizjak wrote:
> > Turning it into a compile test that counts the number of jumps threaded
> > seems potentially flaky but I'm not against it. And I'm not sure how to
> > reliably turn it into an execution test. Would the directives
> >
> > /* { dg-do run } */
> > /* { dg-require-effective-target avx2 } */
> > /* { dg-require-effective-target ia32 } */
> > /* { dg-options "-O3 -mavx2" } */
> >
> > work?
>
> No, this only checks that the target is able to compile the testcase.
> In gcc.target/i386, there is ialready present nfrastructure that
> handles runtime checks (avx2_test) in your case. You can see many
> examples there.
>
> Uros.
>
I see, thank you. Here's a version of the test case that should fail without
the patch and pass with the patch. I can't test it myself because I don't have
access to a machine with AVX2. But I can confirm that with the patch the two
bogus jump threads through the vector conditionals that were incorrectly folded
are no longered registered.
/* { dg-do run } */
/* { dg-require-effective-target avx2 } */
/* { dg-require-effective-target ia32 } */
/* { dg-options "-O3 -mavx2" } */
#include "avx2-check.h"
typedef unsigned int ui;
ui x[32*32];
ui y[32];
ui z[32];
void __attribute__ ((noinline, noclone)) foo (ui n, ui z)
{
ui i, b;
ui v;
for (i = 0; i< n; i++)
{
v = y[i];
if (v) {
for (b = 0; b < 32; b++)
if ((v >> b) & 1)
x[i*32 +b] = z;
y[i] = 0;
}
}
}
static void
avx2_test (void)
{
int i;
unsigned int val;
for (i = 0; i<32; i++)
{
val = 1U << i;
y[i] = (i & 1)? 0 : val;
z[i] = i;
}
foo (32, 10);
for (i=0; i<1024; i+=66)
if (x[i] != 10)
__builtin_abort ();
}
Re: [PATCH] tree-optimization/71831 - __builtin_object_size poor results with no optimization
On 08/20/2016 01:02 AM, Florian Weimer wrote:
* Martin Sebor:
As requested in the review of the following patch
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01363.html
attached is the small enhancement to compute_builtin_object_size to
make the function usable even without optimization without the full
overhead of the tree-object-size pass.
Is its overhead that significant?
That's a good question. I haven't measured it but having limited
access to object sizes beyond what my simple patch adds would make
it possible to improve the quality of other warnings as well (e.g.,
-Warray-bounds and -Wplacement-new) and improve buffer overflow
detection in libc function calls without optimization (if enabled
as suggested below).
Does this mean that with this patch, glibc should remove its
_FORTIFY_SOURCE warning for non-optimized builds when compiling under
GCC >= 7?
No, but I see no reason why GCC couldn't provide the same (limited)
overflow checking for other libc built-ins that the -Wformat-length
patch adds to __builtin_sprintf et al. The proof of concept patch
below shows that it would be nearly trivial to do (the warning
mentions memcpy and strcpy because that's what GCC has transformed
the strcpy call into by the time it's expanded but presumably that
could be fixed).
Martin
$ cat z.c && /build/gcc-71831/gcc/xgcc -B /build/gcc-71831/gcc -O0 -S
-Wall -Wextra z.c
char a[2];
extern char* strcpy (char*, const char*);
void f (void)
{
strcpy (a, "abc");
}
z.c: In function ‘f’:
z.c:7:3: warning: call to __builtin_memcpy writing 4 bytes into
destination of size 2
strcpy (a, "abc");
^
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2985,6 +2985,19 @@ expand_builtin_memcpy (tree exp, rtx target)
tree dest = CALL_EXPR_ARG (exp, 0);
tree src = CALL_EXPR_ARG (exp, 1);
tree len = CALL_EXPR_ARG (exp, 2);
+
+ unsigned HOST_WIDE_INT dstsize;
+ compute_builtin_object_size (dest, 0, &dstsize);
+
+ unsigned HOST_WIDE_INT srclen
+ = tree_fits_uhwi_p (len) ? tree_to_uhwi (len) : HOST_WIDE_INT_M1U;
+
+ if (dstsize <= srclen)
+ warning_at (tree_nonartificial_location (exp),
+ 0, "%Kcall to %D writing %wu bytes into destination "
+ "of size %wu",
+ exp, get_callee_fndecl (exp), srclen, dstsize);
+
return expand_builtin_memcpy_args (dest, src, len, target, exp);
}
}
Re: [PATCH] Restrict jump threading statement simplifier to scalar types (PR71077)
On Sun, Aug 21, 2016 at 11:04 PM, Patrick Palka wrote:
> On Sat, 20 Aug 2016, Uros Bizjak wrote:
>
>> > Turning it into a compile test that counts the number of jumps threaded
>> > seems potentially flaky but I'm not against it. And I'm not sure how to
>> > reliably turn it into an execution test. Would the directives
>> >
>> > /* { dg-do run } */
>> > /* { dg-require-effective-target avx2 } */
>> > /* { dg-require-effective-target ia32 } */
>> > /* { dg-options "-O3 -mavx2" } */
>> >
>> > work?
>>
>> No, this only checks that the target is able to compile the testcase.
>> In gcc.target/i386, there is ialready present nfrastructure that
>> handles runtime checks (avx2_test) in your case. You can see many
>> examples there.
>>
>> Uros.
>>
>
> I see, thank you. Here's a version of the test case that should fail without
> the patch and pass with the patch. I can't test it myself because I don't
> have
> access to a machine with AVX2. But I can confirm that with the patch the two
> bogus jump threads through the vector conditionals that were incorrectly
> folded
> are no longered registered.
Looks good to me (but I'm also not in the position to runtime test).
However, please remove ia32 effective target requirement, as the
testcase is able to compile and run on 64bit target.
Thanks,
Uros.
> /* { dg-do run } */
> /* { dg-require-effective-target avx2 } */
> /* { dg-require-effective-target ia32 } */
> /* { dg-options "-O3 -mavx2" } */
>
> #include "avx2-check.h"
>
> typedef unsigned int ui;
> ui x[32*32];
> ui y[32];
> ui z[32];
> void __attribute__ ((noinline, noclone)) foo (ui n, ui z)
> {
> ui i, b;
> ui v;
> for (i = 0; i< n; i++)
> {
> v = y[i];
> if (v) {
> for (b = 0; b < 32; b++)
> if ((v >> b) & 1)
> x[i*32 +b] = z;
> y[i] = 0;
> }
> }
> }
>
> static void
> avx2_test (void)
> {
> int i;
> unsigned int val;
> for (i = 0; i<32; i++)
> {
> val = 1U << i;
> y[i] = (i & 1)? 0 : val;
> z[i] = i;
> }
> foo (32, 10);
> for (i=0; i<1024; i+=66)
> if (x[i] != 10)
> __builtin_abort ();
> }
>
Re: [PATCH] remove HARD_FRAME_POINTER_IS_ARG_POINTER macro
On Sat, Aug 20, 2016 at 06:46:22PM +, Bernd Edlinger wrote: > > its kind of silly, and this allows us to remove a few more #ifdefs. > > > > bootstrapped + regtest x86_64-linux-gnu, ok? > > No, I don't think so, because: > > > #if FRAME_POINTER_REGNUM != ARG_POINTER_REGNUM > > -#if HARD_FRAME_POINTER_IS_ARG_POINTER > > +#if HARD_FRAME_POINTER_REGNUM == ARG_POINTER_REGNUM > >GR_ARG_POINTER = GR_HARD_FRAME_POINTER, > > #else > > will likely break arm and mips. > The only targets that define HARD_FRAME_POINTER_IS_ARG_POINTER > probably for some reason. > > see arm.h: > > #define HARD_FRAME_POINTER_REGNUM \ >(TARGET_ARM \ > ? ARM_HARD_FRAME_POINTER_REGNUM \ > : THUMB_HARD_FRAME_POINTER_REGNUM) > > #define FRAME_POINTER_REGNUM102 > > #define ARG_POINTER_REGNUM 103 > > > see mips.h: > > #define ARG_POINTER_REGNUM 77 > #define FRAME_POINTER_REGNUM 78 > > #define HARD_FRAME_POINTER_REGNUM \ >(TARGET_MIPS16 ? GP_REG_FIRST + 17 : GP_REG_FIRST + 30) > > > so #if HARD_FRAME_POINTER_REGNUM == ARG_POINTER_REGNUM > will not be evaluatable by the preprocessor. For some reason the first time I looked at those macros I thought TARGET_THUMB / TARGET_MIPS16 were constants, but obviously they aren't. Anyway I think its easily enough fixed by dropping the rtl.h and config/ changes, the rest should be good I believe. Trev
Re: [PATCH 2/4][Ada,DJGPP] Ada support for DJGPP
On 08/18/2016 12:40 PM, Arnaud Charlet wrote:
This patch (2nd of 4) includes various changes to Ada related C files
required for DJGPP support
ChangeLog entry:
2016-07-30 Andris Pavenis
* ada/ctrl_c.c: Do not use macro SA_RESTART for DJGPP.
* ada/gsocket.h: Do not support sockets for DJGPP.
* ada/init.c (timestruct_t): Define for DJGPP.
(nanosleep): Implement for DJGPP using usleep().
Why do you need to define nanosleep() here? I suspect this is no longer
needed. If it is, would be good to know why.
Arno
Thanks for notice. It is really no more needed.
Updated patch is in attachment. New changelog entry is also there
Andris
>From 6cf25bcc18b4c0b8945af55bb1d9d0719f7ee8a8 Mon Sep 17 00:00:00 2001
From: Andris Pavenis
Date: Sun, 21 Aug 2016 11:15:11 +0300
Subject: [PATCH 2/4] [DJGPP, Ada] DJGPP support
* ada/ctrl_c.c: Do not use macro SA_RESTART for DJGPP.
* ada/gsocket.h: Do not support sockets for DJGPP.
* ada/init.c (__gnat_install_handler): Implement for DJGPP
* ada/sysdep.c: Include for DJGPP
(_setmode): Define to setmode for DJGPP
(__gnat_set_mode): Add implementation for DJGPP
(__gnat_localtime_tzoff): Add implementation for DJGPP
* ada/terminals.c: Add DJGPP to list of unsupported platforms.
---
gcc/ada/ctrl_c.c| 4 ++--
gcc/ada/gsocket.h | 2 +-
gcc/ada/init.c | 8
gcc/ada/sysdep.c| 56 +++--
gcc/ada/terminals.c | 2 +-
5 files changed, 66 insertions(+), 6 deletions(-)
diff --git a/gcc/ada/ctrl_c.c b/gcc/ada/ctrl_c.c
index 7f8d177..d4fc551 100644
--- a/gcc/ada/ctrl_c.c
+++ b/gcc/ada/ctrl_c.c
@@ -92,8 +92,8 @@ __gnat_install_int_handler (void (*proc) (void))
if (sigint_intercepted == 0)
{
act.sa_handler = __gnat_int_handler;
-#if defined (__Lynx__) || defined (VMS)
- /* LynxOS and VMS do not support SA_RESTART. */
+#if defined (__Lynx__) || defined (VMS) || defined(__DJGPP__)
+ /* LynxOS, VMS or DJGPP do not support SA_RESTART. */
act.sa_flags = 0;
#else
act.sa_flags = SA_RESTART;
diff --git a/gcc/ada/gsocket.h b/gcc/ada/gsocket.h
index 31a3ccf..a979d3a 100644
--- a/gcc/ada/gsocket.h
+++ b/gcc/ada/gsocket.h
@@ -29,7 +29,7 @@
* *
/
-#if defined(VTHREADS) || defined(__PikeOS__)
+#if defined(VTHREADS) || defined(__PikeOS__) || defined(__DJGPP__)
/* Sockets not supported on these platforms. */
#undef HAVE_SOCKETS
diff --git a/gcc/ada/init.c b/gcc/ada/init.c
index 6d51896..cec968b 100644
--- a/gcc/ada/init.c
+++ b/gcc/ada/init.c
@@ -2516,6 +2516,14 @@ __gnat_install_handler (void)
__gnat_handler_installed = 1;
}
+#elif defined (__DJGPP__)
+
+void
+__gnat_install_handler ()
+{
+ __gnat_handler_installed = 1;
+}
+
#elif defined(__ANDROID__)
/***/
diff --git a/gcc/ada/sysdep.c b/gcc/ada/sysdep.c
index 465007e..bfabf30 100644
--- a/gcc/ada/sysdep.c
+++ b/gcc/ada/sysdep.c
@@ -126,7 +126,7 @@ extern struct tm *localtime_r(const time_t *, struct tm *);
*/
-#if defined (WINNT) || defined (__CYGWIN__)
+#if defined (WINNT) || defined (__CYGWIN__) || defined(__DJGPP__)
const char __gnat_text_translation_required = 1;
@@ -137,6 +137,11 @@ const char __gnat_text_translation_required = 1;
#define WIN_SETMODE _setmode
#endif
+#if defined(__DJGPP__)
+#include
+#define _setmode setmode
+#endif /* __DJGPP__ */
+
void
__gnat_set_binary_mode (int handle)
{
@@ -149,6 +154,30 @@ __gnat_set_text_mode (int handle)
WIN_SETMODE (handle, O_TEXT);
}
+#ifdef __DJGPP__
+void
+__gnat_set_mode (int handle, int mode)
+{
+ /* the values here must be synchronized with
+ System.File_Control_Block.Content_Encodding:
+
+ None = 0
+ Default_Text = 1
+ Text = 2
+ U8text = 3
+ Wtext= 4
+ U16text = 5 */
+
+ switch (mode) {
+case 0 : setmode(handle, O_BINARY); break;
+case 1 : setmode(handle, O_TEXT);break;
+case 2 : setmode(handle, O_TEXT);break;
+case 3 : setmode(handle, O_TEXT);break;
+case 4 : setmode(handle, O_BINARY); break;
+case 5 : setmode(handle, O_BINARY); break;
+ }
+}
+#else
void
__gnat_set_mode (int handle, int mode)
{
@@ -171,6 +200,7 @@ __gnat_set_mode (int handle, int mode)
case 5 : WIN_SETMODE (handle, _O_U16TEXT); break;
}
}
+#endif
#ifdef __CYGWIN__
@@ -603,7 +633,29 @@ long __gnat_invalid_tzoff = 259273;
/* Definition of __gnat_localtime_r used by a-calend.adb */
-#if defined (__MINGW32__)
+#if defined (__DJGPP__)
+
+/* FIXME: this is draft version only. Fix me if that is not correct */
+/*or not complete (AP) */
+
+extern void
+__gnat_localtime_tzoff (const time_t *, long *);
+
+void
+__gnat_localtime_tzoff (const time_t
Re: [PATCH 3/4][Ada,DJGPP] Ada support for DJGPP
On 08/18/2016 12:41 PM, Arnaud Charlet wrote: 2016-07-30 Andris Pavenis * ada/gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Define for DJGPP target (EH_MECHANISM): Define to -gcc for DJGPP * ada/system-djgpp.ads: New file Andris +++ b/gcc/ada/system-djgpp.ads @@ -0,0 +1,148 @@ +-- +-- -- +--GNAT RUN-TIME COMPONENTS -- +-- -- +-- S Y S T E M-- +-- -- +-- S p e c -- +--(DJGPP Version) -- Wrong formatting here. Fixed +-- -- +-- Copyright (C) 1992-2015, Free Software Foundation, Inc. -- Wrong copyright here. Also fixed. New patch is in attachment. Andris >From 3cfe377c3d5b798e39209518ebdf15752818e5ee Mon Sep 17 00:00:00 2001 From: Andris Pavenis Date: Sun, 21 Aug 2016 13:30:10 +0300 Subject: [PATCH 3/4] [DJGPP, Ada] DJGPP support * ada/gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Define for DJGPP target (EH_MECHANISM): Define to -gcc for DJGPP * ada/system-djgpp.ads: New file --- gcc/ada/gcc-interface/Makefile.in | 17 + gcc/ada/system-djgpp.ads | 148 ++ 2 files changed, 165 insertions(+) create mode 100644 gcc/ada/system-djgpp.ads diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in index 0df7f89..dcb7c93 100644 --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -1773,6 +1773,23 @@ ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),) indepsw.adbhttp://www.gnu.org/licenses/>. -- +-- -- +-- GNAT was originally developed by the GNAT team at New York University. -- +-- Extensive contributions were provided by Ada Core Technologies Inc. -- +-- -- +-- + +package System is + pragma Pure; + -- Note that we take advantage of the implementation permission to make + -- this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada + -- 2005, this is Pure in any case (AI-362). + + pragma No_Elaboration_Code_All; + -- Allow the use of that restriction in units that WITH this unit + + type Name is (SYSTEM_NAME_GNAT); + System_Name : constant Name := SYSTEM_NAME_GNAT; + + -- System-Dependent Named Numbers + + Min_Int : constant := Long_Long_Integer'First; + Max_Int : constant := Long_Long_Integer'Last; + + Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size; + Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1; + + Max_Base_Digits : constant := Long_Long_Float'Digits; + Max_Digits: constant := Long_Long_Float'Digits; + + Max_Mantissa : constant := 63; + Fine_Delta: constant := 2.0 ** (-Max_Mantissa); + + Tick : constant := 0.01; + + -- Storage-related Declarations + + type Address is private; + pragma Preelaborable_Initialization (Address); + Null_Address : constant Address; + + Storage_Unit : constant := 8; + Word_Size: constant := 32; + Memory_Size : constant := 2 ** 32; + + -- Address comparison + + function "<" (Left, Right : Address) return Boolean; + function "<=" (Left, Right : Address) return Boolean; + function ">" (Left, Right : Address) return Boolean; + function ">=" (Left, Right : Address) return Boolean; + function "=" (Left, Right : Address) return Boolean; + + pragma Import (Intrinsic, "<"); + pragma Import (Intrinsic, "<="); + pragma Import (Intrinsic, ">"); + pragma Import (Intrinsic, ">="); + pragma Import (Intrinsic, "="); + + -- Other System-Dependent Declarations + + type Bit_Order is (High_Order_First, Low_Order_First); + Default_Bit_Order : constant Bit_Order := Low_Order_First; + pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning + + -- Priority-related Declarations (RM D.1) + + Max_Priority : constant Positive := 30; + Max_Interrupt_Priority : constant Positive := 31; + + subtype Any_Priority is Integer range 0 .. 31; + subtype Priority is Any_Priority range 0 .. 30; + subtype Interrupt_Priority is Any_Priority range 31 .. 31; + + Default_Priority : constant Priority := 15; + +private + + type Add
