public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
@ 2015-02-08 13:43 erik-gcc-bugzilla at vanpienbroek dot nl
  2015-02-11 15:54 ` [Bug libgomp/64972] " ktietz at gcc dot gnu.org
                   ` (17 more replies)
  0 siblings, 18 replies; 19+ messages in thread
From: erik-gcc-bugzilla at vanpienbroek dot nl @ 2015-02-08 13:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

            Bug ID: 64972
           Summary: Build failure in libgomp for i686-w64-mingw32 target
                    after latest merge from gomp-4_0-branch
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: erik-gcc-bugzilla at vanpienbroek dot nl
                CC: jakub at gcc dot gnu.org, ktietz at gcc dot gnu.org
            Target: i686-w64-mingw32

Recent snapshots of gcc 5 can not be built any more for the i686-w64-mingw32
target:

make[4]: Entering directory
'/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp'
/bin/sh ./libtool --tag=CC
--mode=compile
/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc
-B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/
-L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem
/usr/i686-w64-mingw32/include -isystem /usr/mingw/include
-B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem
/usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include   
-DHAVE_CONFIG_H -I. -I../../../libgomp  -I../../../libgomp/config/mingw32
-I../../../libgomp/config/posix -I../../../libgomp
-I../../../libgomp/../include  -Wall -Werror -Wc,-pthread -g -O2 -MT target.lo
-MD -MP -MF .deps/target.Tpo -c -o target.lo ../../../libgomp/target.c
libtool:
compile:  /home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc
-B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/
-L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem
/usr/i686-w64-mingw32/include -isystem /usr/mingw/include
-B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem
/usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include
-DHAVE_CONFIG_H -I. -I../../../libgomp -I../../../libgomp/config/mingw32
-I../../../libgomp/config/posix -I../../../libgomp
-I../../../libgomp/../include -Wall -pthread -Werror -g -O2 -MT target.lo -MD
-MP -MF .deps/target.Tpo -c ../../../libgomp/target.c  -DDLL_EXPORT -DPIC -o
.libs/target.o
../../../libgomp/target.c: In function 'gomp_map_vars':
../../../libgomp/target.c:440:21: error: unknown conversion type
character 'z' in format [-Werror=format=]
         gomp_fatal ("present clause: !acc_is_present (%p, "
                     ^
../../../libgomp/target.c:440:21: error: unknown conversion type
character 'z' in format [-Werror=format=]
../../../libgomp/target.c:440:21: error: too many arguments for format
[-Werror=format-extra-args]
cc1: all warnings being treated as errors
Makefile:613: recipe for target 'target.lo' failed
make[4]: *** [target.lo] Error 1
make[4]: Leaving directory
'/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp'


The offending line contains this piece of code:
    gomp_fatal ("present clause: !acc_is_present (%p, "
                "%zd (0x%zx))", (void *) k->host_start,
                size, size);

This piece of code was introduced in r219682 which was applied on January 15
2015.

This issue was also discussed at the mingw-w64 mailing list @ 
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/54CD7703.8080206@users.sourceforge.net/
and also contains some possible solutions


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
@ 2015-02-11 15:54 ` ktietz at gcc dot gnu.org
  2015-03-24  7:49 ` rainer@emrich-ebersheim.de
                   ` (16 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-02-11 15:54 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-11
     Ever confirmed|0                           |1

--- Comment #1 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Confirmed.  '%z' isn't valid for msvcrt as width-specifier.
Shouldn't we use here instead inttypes.h header and PRIxPTR?


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
  2015-02-11 15:54 ` [Bug libgomp/64972] " ktietz at gcc dot gnu.org
@ 2015-03-24  7:49 ` rainer@emrich-ebersheim.de
  2015-03-24  8:01 ` [Bug libgomp/64972] [5 Regression] " ktietz at gcc dot gnu.org
                   ` (15 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: rainer@emrich-ebersheim.de @ 2015-03-24  7:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #2 from Rainer Emrich <rainer@emrich-ebersheim.de> ---
Issue exists for target x86_64-w64-mingw32 too.
By the way, this is a regression.
At the moment gcc doesn't build for the *-w64-mingw32 targets.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
  2015-02-11 15:54 ` [Bug libgomp/64972] " ktietz at gcc dot gnu.org
  2015-03-24  7:49 ` rainer@emrich-ebersheim.de
@ 2015-03-24  8:01 ` ktietz at gcc dot gnu.org
  2015-03-24  8:11 ` ktietz at gcc dot gnu.org
                   ` (14 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-03-24  8:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.9.3
      Known to fail|                            |5.0

--- Comment #3 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Issue is that libgomp uses gnu-style printf formatters without checking, if
formatter is available on that platform.

Due it operates on size_t, the defines provided by inttypes.h are of not much
help.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (2 preceding siblings ...)
  2015-03-24  8:01 ` [Bug libgomp/64972] [5 Regression] " ktietz at gcc dot gnu.org
@ 2015-03-24  8:11 ` ktietz at gcc dot gnu.org
  2015-03-24 10:57 ` rainer@emrich-ebersheim.de
                   ` (13 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-03-24  8:11 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (3 preceding siblings ...)
  2015-03-24  8:11 ` ktietz at gcc dot gnu.org
@ 2015-03-24 10:57 ` rainer@emrich-ebersheim.de
  2015-03-24 11:01 ` jakub at gcc dot gnu.org
                   ` (12 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: rainer@emrich-ebersheim.de @ 2015-03-24 10:57 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #5 from Rainer Emrich <rainer@emrich-ebersheim.de> ---
(In reply to Jakub Jelinek from comment #4)
> And the suggested fix is just to cast to unsigned long and use %ld or %lx
> instead of %zd and %zx.  I can't test it on these targets, so it is better
> if somebody with M$ access writes and tests the patch.

Index: target.c
===================================================================
--- target.c    (Revision 221607)
+++ target.c    (Arbeitskopie)
@@ -439,8 +439,8 @@ gomp_map_vars (struct gomp_device_descr
                         was missing.  */
                      size_t size = k->host_end - k->host_start;
                      gomp_fatal ("present clause: !acc_is_present (%p, "
-                                 "%zd (0x%zx))", (void *) k->host_start,
-                                 size, size);
+                                 "%ld (0x%lx))", (void *) k->host_start,
+                                 (unsigned long) size, (unsigned long) size);
                    }
                    break;
                  case GOMP_MAP_FORCE_DEVICEPTR:

Something like this? At least that builds on x86_64-w64-mingw32.

But there is another issue with formatters in oacc-parallel.c.
Shall I append to this bug or open a new one?


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (4 preceding siblings ...)
  2015-03-24 10:57 ` rainer@emrich-ebersheim.de
@ 2015-03-24 11:01 ` jakub at gcc dot gnu.org
  2015-03-24 11:43 ` rainer@emrich-ebersheim.de
                   ` (11 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-03-24 11:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Rainer Emrich from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > And the suggested fix is just to cast to unsigned long and use %ld or %lx
> > instead of %zd and %zx.  I can't test it on these targets, so it is better
> > if somebody with M$ access writes and tests the patch.
> 
> Index: target.c
> ===================================================================
> --- target.c    (Revision 221607)
> +++ target.c    (Arbeitskopie)
> @@ -439,8 +439,8 @@ gomp_map_vars (struct gomp_device_descr
>                          was missing.  */
>                       size_t size = k->host_end - k->host_start;
>                       gomp_fatal ("present clause: !acc_is_present (%p, "
> -                                 "%zd (0x%zx))", (void *) k->host_start,
> -                                 size, size);
> +                                 "%ld (0x%lx))", (void *) k->host_start,
> +                                 (unsigned long) size, (unsigned long)
> size);
>                     }
>                     break;
>                   case GOMP_MAP_FORCE_DEVICEPTR:
> 
> Something like this? At least that builds on x86_64-w64-mingw32.

Yeah.

> But there is another issue with formatters in oacc-parallel.c.
> Shall I append to this bug or open a new one?

Please don't create a new bug, it is the same thing.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (5 preceding siblings ...)
  2015-03-24 11:01 ` jakub at gcc dot gnu.org
@ 2015-03-24 11:43 ` rainer@emrich-ebersheim.de
  2015-03-24 11:51 ` rainer@emrich-ebersheim.de
                   ` (10 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: rainer@emrich-ebersheim.de @ 2015-03-24 11:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #7 from Rainer Emrich <rainer@emrich-ebersheim.de> ---
Ok, here's the additional issue in oacc-parallel.c.

libtool: compile: 
/opt/devel/SCRATCH/tmp.UotBZukqBt/gcc-5.0.0/gcc-5.0.0/./gcc/xgcc
-B/opt/devel/SCRATCH/tmp.UotBZukqBt/gcc-5.0.0/gcc-5.0.0/./gcc/
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/lib
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/mingw/lib
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/mingw/include
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/bin/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/lib/
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/sys-include
-DHAVE_CONFIG_H -I.
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/config/mingw32
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/config/posix
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/../include
-Wall -pthread -Werror -g -O2 -MT oacc-parallel.lo -MD -MP -MF
.deps/oacc-parallel.Tpo -c
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c
 -DDLL_EXPORT -DPIC -o .libs/oacc-parallel.o
In file included from
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:30:0:
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:
In function 'GOACC_parallel':
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: unknown conversion type character 'z' in format [-Werror=format=]
   gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
                  ^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
       (gomp_debug) ((KIND), __VA_ARGS__); \
                             ^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: format '%p' expects argument of type 'void *', but argument 4 has type
'size_t {aka long long unsigned int}' [-Werror=format=]
   gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
                  ^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
       (gomp_debug) ((KIND), __VA_ARGS__); \
                             ^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: format '%d' expects argument of type 'int', but argument 7 has type
'short unsigned int *' [-Werror=format=]
   gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
                  ^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
       (gomp_debug) ((KIND), __VA_ARGS__); \
                             ^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: too many arguments for format [-Werror=format-extra-args]
   gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
                  ^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
       (gomp_debug) ((KIND), __VA_ARGS__); \
                             ^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:
In function 'GOACC_data_start':
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:181:18:
error: unknown conversion type character 'z' in format [-Werror=format=]
   gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
                  ^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
       (gomp_debug) ((KIND), __VA_ARGS__); \
                             ^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:181:18:
error: format '%p' expects argument of type 'void *', but argument 4 has type
'size_t {aka long long unsigned int}' [-Werror=format=]
   gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
                  ^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
       (gomp_debug) ((KIND), __VA_ARGS__); \
                             ^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:181:18:
error: too many arguments for format [-Werror=format-extra-args]
   gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
                  ^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
       (gomp_debug) ((KIND), __VA_ARGS__); \
                             ^
cc1.exe: all warnings being treated as errors


Issue at these two locations:

lines 102,103:
  gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
              __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async);

lines 181,182:
  gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
              __FUNCTION__, mapnum, hostaddrs, sizes, kinds);


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (6 preceding siblings ...)
  2015-03-24 11:43 ` rainer@emrich-ebersheim.de
@ 2015-03-24 11:51 ` rainer@emrich-ebersheim.de
  2015-03-24 15:05 ` mikpelinux at gmail dot com
                   ` (9 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: rainer@emrich-ebersheim.de @ 2015-03-24 11:51 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #8 from Rainer Emrich <rainer@emrich-ebersheim.de> ---
I'm testing the following on x86_64-w64-mingw32 at the moment.

Index: oacc-parallel.c
===================================================================
--- oacc-parallel.c     (Revision 221607)
+++ oacc-parallel.c     (Arbeitskopie)
@@ -99,8 +99,9 @@ GOACC_parallel (int device, void (*fn) (
     gomp_fatal ("num_workers (%d) different from one is not yet supported",
                num_workers);

-  gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
-             __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async);
+  gomp_debug (0, "%s: mapnum=%ld, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
+             __FUNCTION__, (unsigned long) mapnum, (void *) hostaddrs,
+             sizes, kinds, (int) async);

   select_acc_device (device);

@@ -178,8 +179,9 @@ GOACC_data_start (int device, size_t map
   bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK;
   struct target_mem_desc *tgt;

-  gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
-             __FUNCTION__, mapnum, hostaddrs, sizes, kinds);
+  gomp_debug (0, "%s: mapnum=%ld, hostaddrs=%p, sizes=%p, kinds=%p\n",
+             __FUNCTION__, (unsigned long) mapnum, (void *) hostaddrs,
+             sizes, kinds);

   select_acc_device (device);

Index: target.c
===================================================================
--- target.c    (Revision 221607)
+++ target.c    (Arbeitskopie)
@@ -439,8 +439,8 @@ gomp_map_vars (struct gomp_device_descr
                         was missing.  */
                      size_t size = k->host_end - k->host_start;
                      gomp_fatal ("present clause: !acc_is_present (%p, "
-                                 "%zd (0x%zx))", (void *) k->host_start,
-                                 size, size);
+                                 "%ld (0x%lx))", (void *) k->host_start,
+                                 (unsigned long) size, (unsigned long) size);
                    }
                    break;
                  case GOMP_MAP_FORCE_DEVICEPTR:


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (7 preceding siblings ...)
  2015-03-24 11:51 ` rainer@emrich-ebersheim.de
@ 2015-03-24 15:05 ` mikpelinux at gmail dot com
  2015-03-24 16:20 ` ktietz at gcc dot gnu.org
                   ` (8 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: mikpelinux at gmail dot com @ 2015-03-24 15:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #9 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Please note that sizeof(long) == 4 while sizeof(size_t) == sizeof(void*) == 8
on x86_64-w64-mingw32, so your patch changes the behaviour of the code. 
Perhaps the change is benign, but I'd use uintptr_t and PRIxPTR.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (8 preceding siblings ...)
  2015-03-24 15:05 ` mikpelinux at gmail dot com
@ 2015-03-24 16:20 ` ktietz at gcc dot gnu.org
  2015-03-24 16:21 ` jakub at gcc dot gnu.org
                   ` (7 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-03-24 16:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #10 from Kai Tietz <ktietz at gcc dot gnu.org> ---
I agree that suggested patch changes here behavior on non LP64 targets. 
Nevertheless it would be something to live by until we reach stage 1 to address
this more accurate.
To us uintptr_t is by idea ok, just have the weakness that size_t not
necessarily has same precision as uintptr_t.  If gomp maintainer will say that
inttypes.h header use and casting to uintptr_t would be ok for them, I agree.

A real solution would be to add in configure a test for used size_t
printf-formatter sign, and then use it in source.  For gnu-style
width-specifier is 'z', for ms-style it is 'I'.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (9 preceding siblings ...)
  2015-03-24 16:20 ` ktietz at gcc dot gnu.org
@ 2015-03-24 16:21 ` jakub at gcc dot gnu.org
  2015-03-24 18:52 ` tschwinge at gcc dot gnu.org
                   ` (6 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-03-24 16:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I wouldn't call %zd gnu-style, as it is POSIX.
Anyway, libgomp already uses inttypes.h, but only conditionally:
#ifdef HAVE_INTTYPES_H
      fprintf (stderr, "  GOMP_SPINCOUNT = '%"PRIu64"'\n",
               (uint64_t) gomp_spin_count_var);
#else
      fprintf (stderr, "  GOMP_SPINCOUNT = '%lu'\n",
               (unsigned long) gomp_spin_count_var);
#endif
So, if you'd like to do the same (but then cast to uint64_t and use PRIu64,
dunno how portable is PRIuPTR compared to PRIu64), that is also an option,
but IMNSHO not worth the trouble.
All these messages are unimportant OpenACC debugging messages or a fancy abort
that will very likely not have sizes of anything > 2GB - trying to offload 2GB+
of data to offloading device in one chunk is hardly a case to worry about.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (10 preceding siblings ...)
  2015-03-24 16:21 ` jakub at gcc dot gnu.org
@ 2015-03-24 18:52 ` tschwinge at gcc dot gnu.org
  2015-03-24 20:18 ` jakub at gcc dot gnu.org
                   ` (5 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2015-03-24 18:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |openacc
                 CC|                            |tschwinge at gcc dot gnu.org

--- Comment #12 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Sorry for introducing this breakage; and thanks for working on fixing it.

(In reply to Jakub Jelinek from comment #11)
> I wouldn't call %zd gnu-style, as it is POSIX.
> Anyway, libgomp already uses inttypes.h, but only conditionally:
> #ifdef HAVE_INTTYPES_H
>       fprintf (stderr, "  GOMP_SPINCOUNT = '%"PRIu64"'\n",
>                (uint64_t) gomp_spin_count_var);
> #else
>       fprintf (stderr, "  GOMP_SPINCOUNT = '%lu'\n",
>                (unsigned long) gomp_spin_count_var);
> #endif
> So, if you'd like to do the same (but then cast to uint64_t and use PRIu64,
> dunno how portable is PRIuPTR compared to PRIu64), that is also an option,
> but IMNSHO not worth the trouble.
> All these messages are unimportant OpenACC debugging messages or a fancy
> abort that will very likely not have sizes of anything > 2GB - trying to
> offload 2GB+ of data to offloading device in one chunk is hardly a case to
> worry about.

..., and »640 K ought to be enough for anybody«?  ;-)

Please do not change the code -- even if only "unimportant" debugging messages
-- so that it might print incorrect data.
>From gcc-bugs-return-481491-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 17:52:17 2015
Return-Path: <gcc-bugs-return-481491-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 127133 invoked by alias); 24 Mar 2015 17:52:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 126503 invoked by uid 48); 24 Mar 2015 17:52:11 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65536] LTO line number information garbled
Date: Tue, 24 Mar 2015 18:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65536-4-zNqHjvqWS2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65536-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65536-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02635.txt.bz2
Content-length: 4136

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536

--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #16)
> Other easier to implement idea for GCC 5 may be to simply collect locaiton

For GCC 5 you should just disable column numbers in line-maps. This will save
you a lot of source_locations before overflowing. If you don't overflow the
source_locations themselves, then the line numbers at least should come out
right.

Something like this (not even compiled):


Index: src/libcpp/include/line-map.h
===================================================================
--- src/libcpp/include/line-map.h       (revision 221557)
+++ src/libcpp/include/line-map.h       (working copy)
@@ -88,10 +88,14 @@ struct GTY(()) line_map_ordinary {

 /* This is the highest possible source location encoded within an
    ordinary or macro map.  */
 #define MAX_SOURCE_LOCATION 0x7FFFFFFF

+/* We do not track column numbers higher than this one.  */
+#define LINE_MAP_MAX_COLUMN_NUMBER 100000
+
+
 struct cpp_hashnode;

 /* A macro line map encodes location of tokens coming from a macro
    expansion.

Index: src/libcpp/line-map.c
===================================================================
--- src/libcpp/line-map.c       (revision 221557)
+++ src/libcpp/line-map.c       (working copy)
@@ -536,11 +536,11 @@ linemap_line_start (struct line_maps *se
   else
     max_column_hint = set->max_column_hint;
   if (add_map)
     {
       int column_bits;
-      if (max_column_hint > 100000 || highest > 0x60000000)
+      if (max_column_hint > LINE_MAP_MAX_COLUMN_NUMBER || highest >
0x60000000)
        {
          /* If the column number is ridiculous or we've allocated a huge
             number of source_locations, give up on column numbers. */
          max_column_hint = 0;
          if (highest > 0x70000000)
@@ -598,11 +598,11 @@ linemap_position_for_column (struct line
   linemap_assert
     (!linemap_macro_expansion_map_p (LINEMAPS_LAST_ORDINARY_MAP (set)));

   if (to_column >= set->max_column_hint)
     {
-      if (r >= 0xC000000 || to_column > 100000)
+      if (r >= 0xC000000 || to_column > LINE_MAP_MAX_COLUMN_NUMBER)
        {
          /* Running low on source_locations - disable column numbers.  */
          return r;
        }
       else
Index: src/gcc/lto-streamer-in.c
===================================================================
--- src/gcc/lto-streamer-in.c   (revision 221557)
+++ src/gcc/lto-streamer-in.c   (working copy)
@@ -198,21 +198,23 @@ lto_input_location (struct bitpack_d *bp
     current_line = bp_unpack_var_len_unsigned (bp);

   if (column_change)
     current_col = bp_unpack_var_len_unsigned (bp);

-  if (file_change)
+  if (file_change) 
     {
       if (prev_file)
-       linemap_add (line_table, LC_LEAVE, false, NULL, 0);
-
-      linemap_add (line_table, LC_ENTER, false, current_file, current_line);
+       linemap_add (line_table, LC_RENAME, false, current_file, current_line);
+      else
+       linemap_add (line_table, LC_ENTER, false, current_file, current_line);
     }
   else if (line_change)
-    linemap_line_start (line_table, current_line, current_col);
+    /* Enough column_hint to disable columns */
+    return linemap_line_start (line_table, current_line,
LINE_MAP_MAX_COLUMN_NUMBER + 1);

-  return linemap_position_for_column (line_table, current_col);
+  /* Enough column_hint to disable columns */
+  return linemap_position_for_column (line_table, LINE_MAP_MAX_COLUMN_NUMBER +
1);
 }


 /* Read a reference to a tree node from DATA_IN using input block IB.
    TAG is the expected node that should be found in IB, if TAG belongs
>From gcc-bugs-return-481492-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 18:21:12 2015
Return-Path: <gcc-bugs-return-481492-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 81702 invoked by alias); 24 Mar 2015 18:21:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 64450 invoked by uid 48); 24 Mar 2015 18:21:08 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65536] LTO line number information garbled
Date: Tue, 24 Mar 2015 19:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65536-4-AsBBnzHw9z@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65536-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65536-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02636.txt.bz2
Content-length: 4555

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #17)
> Something like this (not even compiled):

This version compiles 

Index: src/libcpp/include/line-map.h
===================================================================
--- src/libcpp/include/line-map.h       (revision 221557)
+++ src/libcpp/include/line-map.h       (working copy)
@@ -88,10 +88,14 @@ struct GTY(()) line_map_ordinary {

 /* This is the highest possible source location encoded within an
    ordinary or macro map.  */
 #define MAX_SOURCE_LOCATION 0x7FFFFFFF

+/* We do not track column numbers higher than this one.  */
+#define LINE_MAP_MAX_COLUMN_NUMBER 100000
+
+
 struct cpp_hashnode;

 /* A macro line map encodes location of tokens coming from a macro
    expansion.

Index: src/libcpp/line-map.c
===================================================================
--- src/libcpp/line-map.c       (revision 221557)
+++ src/libcpp/line-map.c       (working copy)
@@ -536,11 +536,12 @@ linemap_line_start (struct line_maps *se
   else
     max_column_hint = set->max_column_hint;
   if (add_map)
     {
       int column_bits;
-      if (max_column_hint > 100000 || highest > 0x60000000)
+      if (max_column_hint > LINE_MAP_MAX_COLUMN_NUMBER
+         || highest > 0x60000000)
        {
          /* If the column number is ridiculous or we've allocated a huge
             number of source_locations, give up on column numbers. */
          max_column_hint = 0;
          if (highest > 0x70000000)
@@ -598,11 +599,11 @@ linemap_position_for_column (struct line
   linemap_assert
     (!linemap_macro_expansion_map_p (LINEMAPS_LAST_ORDINARY_MAP (set)));

   if (to_column >= set->max_column_hint)
     {
-      if (r >= 0xC000000 || to_column > 100000)
+      if (r >= 0xC000000 || to_column > LINE_MAP_MAX_COLUMN_NUMBER)
        {
          /* Running low on source_locations - disable column numbers.  */
          return r;
        }
       else
Index: src/gcc/lto-streamer-in.c
===================================================================
--- src/gcc/lto-streamer-in.c   (revision 221557)
+++ src/gcc/lto-streamer-in.c   (working copy)
@@ -178,11 +178,10 @@ canon_file_name (const char *string)
 location_t
 lto_input_location (struct bitpack_d *bp, struct data_in *data_in)
 {
   static const char *current_file;
   static int current_line;
-  static int current_col;
   bool file_change, line_change, column_change;
   bool prev_file = current_file != NULL;

   if (bp_unpack_value (bp, 1))
     return UNKNOWN_LOCATION;
@@ -195,24 +194,31 @@ lto_input_location (struct bitpack_d *bp
     current_file = canon_file_name (bp_unpack_string (data_in, bp));

   if (line_change)
     current_line = bp_unpack_var_len_unsigned (bp);

+  /* FIXME: Disable columns for now until streaming of locations is
reimplemented.  
+  static int current_col;
   if (column_change)
     current_col = bp_unpack_var_len_unsigned (bp);
+  */

-  if (file_change)
+  if (file_change) 
     {
       if (prev_file)
-       linemap_add (line_table, LC_LEAVE, false, NULL, 0);
-
-      linemap_add (line_table, LC_ENTER, false, current_file, current_line);
+       linemap_add (line_table, LC_RENAME, false, current_file, current_line);
+      else
+       linemap_add (line_table, LC_ENTER, false, current_file, current_line);
     }
   else if (line_change)
-    linemap_line_start (line_table, current_line, current_col);
-
-  return linemap_position_for_column (line_table, current_col);
+    /* Enough column_hint to disable columns */
+    return linemap_line_start (line_table, current_line,
+                              LINE_MAP_MAX_COLUMN_NUMBER + 1);
+
+  /* Enough column_hint to disable columns */
+  return linemap_position_for_column (line_table,
+                                     LINE_MAP_MAX_COLUMN_NUMBER + 1);
 }


 /* Read a reference to a tree node from DATA_IN using input block IB.
    TAG is the expected node that should be found in IB, if TAG belongs
>From gcc-bugs-return-481493-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 18:40:59 2015
Return-Path: <gcc-bugs-return-481493-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2675 invoked by alias); 24 Mar 2015 18:40:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2345 invoked by uid 48); 24 Mar 2015 18:40:53 -0000
From: "t.poechtrager at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65544] New: LTO link fails with -static-libstdc++ + weak new/delete operators
Date: Tue, 24 Mar 2015 19:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: t.poechtrager at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65544-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02637.txt.bz2
Content-length: 7108

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide544

            Bug ID: 65544
           Summary: LTO link fails with -static-libstdc++ + weak
                    new/delete operators
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: t.poechtrager at gmail dot com

$ cat test.cpp
#include <malloc.h>
#include <stdlib.h>
#include <stddef.h>

#define WEAK __attribute__((weak))

WEAK void *operator new(size_t size) throw()
{
    void *p = malloc(size);
    if(!p) abort();
    return p;
}

WEAK void *operator new[](size_t size) throw()
{
    void *p = malloc(size);
    if(!p) abort();
    return p;
}

WEAK void operator delete(void *p) throw() { if(p) free(p); }
WEAK void operator delete(void *p, size_t) throw() { if(p) free(p); }

WEAK void operator delete[](void *p) throw() { if(p) free(p); }
WEAK void operator delete[](void *p, size_t) throw() { if(p) free(p); }


int main(){}



$ i686-w64-mingw32-g++ test.cpp -static-libstdc++  # works
$ i686-w64-mingw32-g++ test.cpp -flto              # works
$ g++ test.cpp -flto -static-libstdc++             # native g++ works too
$ g++ test.cpp -flto -static-libstdc++ -m32        # 32-bit is no problem
either

$ i686-w64-mingw32-g++ test.cpp -flto -static-libstdc++
`__ZdlPv' referenced in section `.text$_ZNSt9exceptionD0Ev' of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(eh_exception.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section `.text$_ZNSt13bad_exceptionD0Ev' of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(eh_exception.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section `.text$_ZN10__cxxabiv115__forced_unwindD0Ev' of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(eh_exception.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section
`.text$_ZN10__cxxabiv119__foreign_exceptionD0Ev' of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(eh_exception.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section
`.text$_ZN9__gnu_cxx24__concurrence_lock_errorD0Ev[__ZN9__gnu_cxx24__concurrence_lock_errorD0Ev]'
of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(eh_alloc.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section
`.text$_ZN9__gnu_cxx26__concurrence_unlock_errorD0Ev[__ZN9__gnu_cxx26__concurrence_unlock_errorD0Ev]'
of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(eh_alloc.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section
`.text$_ZN10__cxxabiv120__si_class_type_infoD0Ev' of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(si_class_type_info.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section `.text$_ZNSt9type_infoD0Ev' of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(tinfo.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
`__ZdlPv' referenced in section `.text$_ZN10__cxxabiv117__class_type_infoD0Ev'
of
/opt/compiler/mingw-w64/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/lib/../lib/libstdc++.a(class_type_info.o):
defined in discarded section `.text' of /tmp/cc4sS08t.o (symbol from plugin)
collect2: error: ld returned 1 exit status

Is this a bug?

Version:

$ i686-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/opt/compiler/mingw-w64/libexec/gcc/i686-w64-mingw32/4.9.2/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../configure --prefix=/opt/compiler/mingw-w64
--target=i686-w64-mingw32 --with-gnu-ld --with-gnu-as
--enable-languages=c,c++,lto --disable-multilib --enable-lto
--enable-threads=posix
Thread model: posix

$ i686-w64-mingw32-ld -v
GNU ld (GNU Binutils) 2.25

For the native one:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-10ubuntu10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu10)

$ ld -v
GNU ld (GNU Binutils for Ubuntu) 2.25


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (11 preceding siblings ...)
  2015-03-24 18:52 ` tschwinge at gcc dot gnu.org
@ 2015-03-24 20:18 ` jakub at gcc dot gnu.org
  2015-03-24 20:37 ` ktietz at gcc dot gnu.org
                   ` (4 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-03-24 20:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kai Tietz from comment #13)
> Rainer: does following patch works for you?
> 
> Index: oacc-parallel.c
> ===================================================================
> --- oacc-parallel.c	(Revision 221640)
> +++ oacc-parallel.c	(Arbeitskopie)
> @@ -31,6 +31,9 @@
>  #include "libgomp_g.h"
>  #include "gomp-constants.h"
>  #include "oacc-int.h"
> +#ifdef HAVE_INTTYPES_H
> +# include <inttypes.h>  /* For PRIu64.  */
> +#endif
>  #include <string.h>
>  #include <stdarg.h>
>  #include <assert.h>
> @@ -99,9 +102,14 @@ GOACC_parallel (int device, void (*fn) (void *),
>      gomp_fatal ("num_workers (%d) different from one is not yet supported",
>  		num_workers);
>  
> +#ifdef HAVE_INTTYPES_H
> +  gomp_debug (0, "%s: mapnum=%"PRIu64", hostaddrs=%p, size=%p, kinds=%p, "
> +		 "async = %d\n",
> +	      __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds, async);
> +#else
>    gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
> async=%d\n",
>  	      __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async);
> -
> +#endif
>    select_acc_device (device);
>  
>    thr = goacc_thread ();
> @@ -178,8 +186,13 @@ GOACC_data_start (int device, size_t mapnum,
>    bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK;
>    struct target_mem_desc *tgt;
>  
> +#ifdef HAVE_INTTYPES_H
> +  gomp_debug (0, "%s: mapnum=%"PRIu64", hostaddrs=%p, size=%p, kinds=%p\n",
> +	      __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds);
> +#else
>    gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
>  	      __FUNCTION__, mapnum, hostaddrs, sizes, kinds);
> +#endif
>  
>    select_acc_device (device);
>  
> Index: target.c
> ===================================================================
> --- target.c	(Revision 221640)
> +++ target.c	(Arbeitskopie)
> @@ -33,6 +33,9 @@
>  #include <limits.h>
>  #include <stdbool.h>
>  #include <stdlib.h>
> +#ifdef HAVE_INTTYPES_H
> +# include <inttypes.h>  /* For PRIu64.  */
> +#endif
>  #include <string.h>
>  #include <assert.h>
>  
> @@ -438,9 +441,16 @@ gomp_map_vars (struct gomp_device_descr *devicep,
>  		      /* We already looked up the memory region above and it
>  			 was missing.  */
>  		      size_t size = k->host_end - k->host_start;
> +#ifdef HAVE_INTTYPES_H
>  		      gomp_fatal ("present clause: !acc_is_present (%p, "
> +				  PRIu64" (0x"PRIx64"))",
> +				  (void *) k->host_start,
> +				  (uint64_t) size, (uint64_t) size);
> +#else
> +		      gomp_fatal ("present clause: !acc_is_present (%p, "
>  				  "%zd (0x%zx))", (void *) k->host_start,
>  				  size, size);
> +#endif
>  		    }
>  		    break;
>  		  case GOMP_MAP_FORCE_DEVICEPTR:

The fallback case really should use %ld or %lx and casts to (unsigned long).
Targets that have inttypes.h will (with the exception of M$ targets) likely
also support %zd / %zx.
>From gcc-bugs-return-481505-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 19:51:08 2015
Return-Path: <gcc-bugs-return-481505-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 37620 invoked by alias); 24 Mar 2015 19:51:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 37254 invoked by uid 55); 24 Mar 2015 19:51:03 -0000
From: "ian at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/65462] Use of 'go get' with gccgo is not finding dependencies correctly
Date: Tue, 24 Mar 2015 20:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ian at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65462-4-w0JyzH0UTS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65462-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65462-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02649.txt.bz2
Content-length: 1269

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide462

--- Comment #7 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Tue Mar 24 19:50:31 2015
New Revision: 221643

URL: https://gcc.gnu.org/viewcvs?rev"1643&root=gcc&view=rev
Log:
    PR go/65462
cmd: Fix dependencies for 'go get' with gccgo

Problem described in GCC BZ 65462.
Generate the list of the standard GO package names based on what was built into
libgo in the libgo Makefile.
Change the var name from reqPkgSrc to reqStdPkgSrc to clarify it only affects
standard GO packages.
Skip the attempted loading of a package only if it is a standard GO package and
the flag is set indicating its source is not required to be available.
This requires a corresponding change to gotools to build and link in the new
file containing the list of standard GO package names that was generated by the
libgo Makefile.

gotools/:
    PR go/65462
    * Makefile.am (go_cmd_go_files): Add $(libgodir)/zstdpkglist.go.
    * Makefile.in: Rebuild.

Modified:
    trunk/gotools/ChangeLog
    trunk/gotools/Makefile.am
    trunk/gotools/Makefile.in
    trunk/libgo/Makefile.am
    trunk/libgo/Makefile.in
    trunk/libgo/go/cmd/go/build.go
    trunk/libgo/go/cmd/go/pkg.go
    trunk/libgo/go/cmd/go/test.go


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (12 preceding siblings ...)
  2015-03-24 20:18 ` jakub at gcc dot gnu.org
@ 2015-03-24 20:37 ` ktietz at gcc dot gnu.org
  2015-03-24 20:56 ` jakub at gcc dot gnu.org
                   ` (3 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-03-24 20:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #15 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Ok, I am fine.  So patch should be something like:

Index: oacc-parallel.c
===================================================================
--- oacc-parallel.c    (Revision 221640)
+++ oacc-parallel.c    (Arbeitskopie)
@@ -31,6 +31,9 @@
 #include "libgomp_g.h"
 #include "gomp-constants.h"
 #include "oacc-int.h"
+#ifdef HAVE_INTTYPES_H
+# include <inttypes.h>  /* For PRIu64.  */
+#endif
 #include <string.h>
 #include <stdarg.h>
 #include <assert.h>
@@ -99,9 +102,15 @@ GOACC_parallel (int device, void (*fn) (void *),
     gomp_fatal ("num_workers (%d) different from one is not yet supported",
         num_workers);

-  gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
-          __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async);
-
+#ifdef HAVE_INTTYPES_H
+  gomp_debug (0, "%s: mapnum=%"PRIu64", hostaddrs=%p, size=%p, kinds=%p, "
+         "async = %d\n",
+          __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds, async);
+#else
+  gomp_debug (0, "%s: mapnum=%lu, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
+          __FUNCTION__, (unsigned long) mapnum, hostaddrs, sizes, kinds,
+          async);
+#endif
   select_acc_device (device);

   thr = goacc_thread ();
@@ -178,8 +187,13 @@ GOACC_data_start (int device, size_t mapnum,
   bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK;
   struct target_mem_desc *tgt;

-  gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
-          __FUNCTION__, mapnum, hostaddrs, sizes, kinds);
+#ifdef HAVE_INTTYPES_H
+  gomp_debug (0, "%s: mapnum=%"PRIu64", hostaddrs=%p, size=%p, kinds=%p\n",
+          __FUNCTION__, (uint64_t) mapnum, hostaddrs, sizes, kinds);
+#else
+  gomp_debug (0, "%s: mapnum=%lu, hostaddrs=%p, sizes=%p, kinds=%p\n",
+          __FUNCTION__, (unsigned long) mapnum, hostaddrs, sizes, kinds);
+#endif

   select_acc_device (device);

Index: target.c
===================================================================
--- target.c    (Revision 221640)
+++ target.c    (Arbeitskopie)
@@ -33,6 +33,9 @@
 #include <limits.h>
 #include <stdbool.h>
 #include <stdlib.h>
+#ifdef HAVE_INTTYPES_H
+# include <inttypes.h>  /* For PRIu64.  */
+#endif
 #include <string.h>
 #include <assert.h>

@@ -438,9 +441,16 @@ gomp_map_vars (struct gomp_device_descr *devicep,
               /* We already looked up the memory region above and it
              was missing.  */
               size_t size = k->host_end - k->host_start;
+#ifdef HAVE_INTTYPES_H
               gomp_fatal ("present clause: !acc_is_present (%p, "
-                  "%zd (0x%zx))", (void *) k->host_start,
-                  size, size);
+                  PRIu64" (0x"PRIx64"))",
+                  (void *) k->host_start,
+                  (uint64_t) size, (uint64_t) size);
+#else
+              gomp_fatal ("present clause: !acc_is_present (%p, "
+                  "%lu (0x%lx))", (void *) k->host_start,
+                  (unsigned long) size, (unsigned long) size);
+#endif
             }
             break;
           case GOMP_MAP_FORCE_DEVICEPTR:


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (13 preceding siblings ...)
  2015-03-24 20:37 ` ktietz at gcc dot gnu.org
@ 2015-03-24 20:56 ` jakub at gcc dot gnu.org
  2015-03-25 13:23 ` rguenth at gcc dot gnu.org
                   ` (2 subsequent siblings)
  17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-03-24 20:56 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kai Tietz from comment #15)
> Ok, I am fine.  So patch should be something like:

Patch preapproved for trunk with proper ChangeLog if it works on
i686-w64-mingw32, please post it to gcc-patches anyway.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (14 preceding siblings ...)
  2015-03-24 20:56 ` jakub at gcc dot gnu.org
@ 2015-03-25 13:23 ` rguenth at gcc dot gnu.org
  2015-03-25 15:41 ` ktietz at gcc dot gnu.org
  2015-03-25 15:43 ` ktietz at gcc dot gnu.org
  17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-03-25 13:23 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
           Priority|P3                          |P1


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (15 preceding siblings ...)
  2015-03-25 13:23 ` rguenth at gcc dot gnu.org
@ 2015-03-25 15:41 ` ktietz at gcc dot gnu.org
  2015-03-25 15:43 ` ktietz at gcc dot gnu.org
  17 siblings, 0 replies; 19+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-03-25 15:41 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

--- Comment #17 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Author: ktietz
Date: Wed Mar 25 15:05:02 2015
New Revision: 221665

URL: https://gcc.gnu.org/viewcvs?rev=221665&root=gcc&view=rev
Log:
    PR libgomp/64972
    * oacc-parallel.c (GOACC_parallel): Use PRIu64 if available.
    (GOACC_data_start): Likewise.
    * target.c (gomp_map_vars): Likewise.


Modified:
    trunk/libgomp/ChangeLog
    trunk/libgomp/oacc-parallel.c
    trunk/libgomp/target.c


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
  2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
                   ` (16 preceding siblings ...)
  2015-03-25 15:41 ` ktietz at gcc dot gnu.org
@ 2015-03-25 15:43 ` ktietz at gcc dot gnu.org
  17 siblings, 0 replies; 19+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-03-25 15:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #18 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Fixed on trunk.


^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2015-03-25 15:07 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-08 13:43 [Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch erik-gcc-bugzilla at vanpienbroek dot nl
2015-02-11 15:54 ` [Bug libgomp/64972] " ktietz at gcc dot gnu.org
2015-03-24  7:49 ` rainer@emrich-ebersheim.de
2015-03-24  8:01 ` [Bug libgomp/64972] [5 Regression] " ktietz at gcc dot gnu.org
2015-03-24  8:11 ` ktietz at gcc dot gnu.org
2015-03-24 10:57 ` rainer@emrich-ebersheim.de
2015-03-24 11:01 ` jakub at gcc dot gnu.org
2015-03-24 11:43 ` rainer@emrich-ebersheim.de
2015-03-24 11:51 ` rainer@emrich-ebersheim.de
2015-03-24 15:05 ` mikpelinux at gmail dot com
2015-03-24 16:20 ` ktietz at gcc dot gnu.org
2015-03-24 16:21 ` jakub at gcc dot gnu.org
2015-03-24 18:52 ` tschwinge at gcc dot gnu.org
2015-03-24 20:18 ` jakub at gcc dot gnu.org
2015-03-24 20:37 ` ktietz at gcc dot gnu.org
2015-03-24 20:56 ` jakub at gcc dot gnu.org
2015-03-25 13:23 ` rguenth at gcc dot gnu.org
2015-03-25 15:41 ` ktietz at gcc dot gnu.org
2015-03-25 15:43 ` ktietz at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).