[Bug c++/115371] New: Hard to decode error message when fixed underlying type of enum is not declared

[kamil_tym at wp dot pl via Gcc-bugs]

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

Bug ID: 115371
   Summary: Hard to decode error message when fixed underlying
type of enum is not declared
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kamil_tym at wp dot pl
  Target Milestone: ---

The following one line program forgot #include  for declaration of
std::uint64_t:

enum class E : std::uint64_t {};

g++ (with no extra diagnostic options) reports following errors and warnings
here:

:1:6: warning: elaborated-type-specifier for a scoped enum must not use
the 'class' keyword
1 | enum class E : std::uint64_t {};
  |  ^
  |  -
:1:12: error: use of enum 'E' without previous declaration
1 | enum class E : std::uint64_t {};
  |^
:1:14: error: expected unqualified-id before ':' token
1 | enum class E : std::uint64_t {};
  |  ^

The issue with the program is that std::uint64_t is not declared, but the error
messages make it really difficult to understand. clang for example produces a
more useful message: 'identifier std is not declared', correctly identifying
the issue.

Godbolt link to reproduction: https://godbolt.org/z/9fjjG9KE9

[CN] Request to join SkyWalking slack

[pl yan]

Re: AppStream-1.0.2-3.x86_64 brakujące symbole

[Bartek Szady via pld-devel-pl]

On 5/16/24 23:28, Jan Rękorajski wrote:


On Wed, 15 May 2024, Maciej Kędzierski wrote:


W dniu 8.05.2024 o 15:46, Bartek Szady via pld-devel-pl pisze:

On 5/8/24 14:15, Jan Palus wrote:


On 08.05.2024 09:03, Bartek Szady via pld-devel-pl wrote:

Cześć

W /usr/lib64/libappstream.so.1.0.2 brakuje symboli wymaganych przez
/usr/lib64/libAppStreamQt5.so.1.0.2 co wywala plasmashell przy próbie
wyszukiwania.

W test widzę nowszą wersję. Może wystarczy przenieść do main aby
problem
zniknął.


...

undefined symbol: g_once_init_leave_pointer
  (/usr/lib64/libappstream.so.5)
undefined symbol: g_once_init_enter_pointer
  (/usr/lib64/libappstream.so.5)

rpm -q glib2? Zgaduje ze < 2.80.0. Jezeli tak to upgrade glib2 powinien
pomoc.

Zgadza się. W main jest glib2-2.78.4-1. Upgrade robię tylko z main bo
test nie jest podpisany.

Przy okazji zauważyłem że python3-modules-3.10.14-1.x86_64 zostało
prawdopodobnie skompilowane z expat-2.6.2-1.x86_64, które też nie
trafiło do main. Co skutkuje:

[bszx@n7110 ~]$ ldd -r
/usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so|grep
-v Py
     linux-vdso.so.1 (0x7ffe986d)
     libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x7fc1deee5000)
     libc.so.6 => /lib64/libc.so.6 (0x7fc1decf8000)
     /lib64/ld-linux-x86-64.so.2 (0x7fc1def69000)
undefined symbol: XML_SetReparseDeferralEnabled
(/usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so)

Pozdrawiam

         Bartek



Potwierdzam.
Na przykład 'certbot' przestał działać.

# certbot renew
Traceback (most recent call last):

[...]

ImportError:
/usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so:
undefined symbol: XML_SetReparseDeferralEnabled

Przeniosłem nowy AppStream, glib2, python3 i expat do main.
Dajcie znać czy pomogło.


Jeszcze brakuje gobject-introspection bo:

poldek:/all-avail> install glib2-2.80.2-1.x86_64
Processing dependencies...
glib2-2.78.4-1.x86_64 obsoleted by glib2-2.80.2-1.x86_64
error: glib2-2.80.2-1.x86_64 (cnfl gobject-introspection < 1.79) 
conflicts with installed gobject-introspection-1.78.1-1.x86_64
error: glib2-2.80.2-1.x86_64 (cnfl gobject-introspection < 1.79) 
conflicts with installed gobject-introspection-1.78.1-1.x86_64

There are 1 package to install, 1 to remove:
U glib2-(2.78.4 => 2.80.2)-1.x86_64
This operation will use 1.1MB of disk space.
Need to get 2.7MB of archives (2.7MB to download).

error: 1 conflicts

Pozdrawiam

        Bartek

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: AppStream-1.0.2-3.x86_64 brakujące symbole

[Arkadiusz Miśkiewicz via pld-devel-pl]

On 16/05/2024 23:28, Jan Rękorajski wrote:


Przeniosłem nowy AppStream, glib2, python3 i expat do main.
Dajcie znać czy pomogło.


Ten python3 jest z podmienionym /usr/bin/python, a w sumie nie wiem czy 
w to chcemy w takiej formie wchodzić. Jeśli tak to trzeba też 
przebudować i przerzucić python-2...


--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug binutils/31475] binutils: Support CREL relocation format

[oset at superbox dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31475

oset  changed:

   What|Removed |Added

 CC||oset at superbox dot pl

--- Comment #2 from oset  ---
Sounds very interesting. Do you have binutils diff/patch to test it? I mean,
compiling llvm takes hours, and compiling binutils takes minutes. That's
'subtle' difference.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[ark] [Bug 487077] New: Ark keeps fucking up zip files

[Will Prince PL]

https://bugs.kde.org/show_bug.cgi?id=487077

Bug ID: 487077
   Summary: Ark keeps fucking up zip files
Classification: Applications
   Product: ark
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: elvis.angelac...@kde.org
  Reporter: will_prince...@protonmail.com
CC: rthoms...@gmail.com
  Target Milestone: ---

Ark keeps fucking up zip files. I have a folder with some files, usually audio,
I want to compress the folder to a zip so I right click to create archive, it
appears to start being made, when creating archive ends temporary archive file
disappears from the location, but final zip file doesn't appear. Happened on
multiple occasions, recently on ntfs partition, but could happened on ext4
before. Also when trying to create a zip with 7 files ark created a zip with
only one file, I managed to add another two files to that zip, but couldn't add
more, it looked like the file is being added to the zip, progress bar went to
the 100 percent, then the file didn't appear in the zip.
The OS is Nobara 39 default (KDE), not sure if this may be Nobara issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

donation

[PlusPl?ss Jo?l Pl?ss]

Hey there do you have some IBAN accounts I can use inside the EU / Swiss ? that 
would be easiest for me, thanks BR. joel

Re: AppStream-1.0.2-3.x86_64 brakujące symbole

[Bartek Szady via pld-devel-pl]

On 5/8/24 14:15, Jan Palus wrote:


On 08.05.2024 09:03, Bartek Szady via pld-devel-pl wrote:

Cześć

W /usr/lib64/libappstream.so.1.0.2 brakuje symboli wymaganych przez
/usr/lib64/libAppStreamQt5.so.1.0.2 co wywala plasmashell przy próbie
wyszukiwania.

W test widzę nowszą wersję. Może wystarczy przenieść do main aby problem
zniknął.


...

undefined symbol: g_once_init_leave_pointer
 (/usr/lib64/libappstream.so.5)
undefined symbol: g_once_init_enter_pointer
 (/usr/lib64/libappstream.so.5)

rpm -q glib2? Zgaduje ze < 2.80.0. Jezeli tak to upgrade glib2 powinien
pomoc.


Zgadza się. W main jest glib2-2.78.4-1. Upgrade robię tylko z main bo 
test nie jest podpisany.


Przy okazji zauważyłem że python3-modules-3.10.14-1.x86_64 zostało 
prawdopodobnie skompilowane z expat-2.6.2-1.x86_64, które też nie 
trafiło do main. Co skutkuje:


[bszx@n7110 ~]$ ldd -r 
/usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so|grep 
-v Py

    linux-vdso.so.1 (0x7ffe986d)
    libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x7fc1deee5000)
    libc.so.6 => /lib64/libc.so.6 (0x7fc1decf8000)
    /lib64/ld-linux-x86-64.so.2 (0x7fc1def69000)
undefined symbol: XML_SetReparseDeferralEnabled 
(/usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so)


Pozdrawiam

        Bartek


___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

AppStream-1.0.2-3.x86_64 brakujące symbole

[Bartek Szady via pld-devel-pl]

fad9000)

   libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x7f9c5fab)
   libp11-kit.so.0 => /usr/lib64/libp11-kit.so.0 (0x7f9c5f97c000)
   libtasn1.so.6 => /usr/lib64/libtasn1.so.6 (0x7f9c5f967000)
   libwind.so.0 => /lib64/libwind.so.0 (0x7f9c5f93d000)
   libhx509.so.5 => /lib64/libhx509.so.5 (0x7f9c5f8ee000)
   libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x7f9c5f77e000)
   libcrypt.so.2 => /lib64/libcrypt.so.2 (0x7f9c5f742000)
   libresolv.so.2 => /lib64/libresolv.so.2 (0x7f9c5f731000)
undefined symbol: g_once_init_leave_pointer 
(/usr/lib64/libappstream.so.5)
undefined symbol: g_once_init_enter_pointer 
(/usr/lib64/libappstream.so.5)


Pozdrawiam

    Bartek


___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

PL/Haskell v4.0 Released

[PL/Haskell via PostgreSQL Announce]

We are pleased to announce the release of version 4.0 of the [PL/Haskell 
extension](https://github.com/ed-o-saurus/PLHaskell/releases/4.0). This 
extension allows users to write PostgreSQL functions in the Haskell functional 
programming language. Instructions can be found 
[here](https://github.com/ed-o-saurus/PLHaskell/blob/main/README.md).

Version 4.0 adds the ability to work with arrays.

This release adds the ability to pass composite values to queries.

Note that there is a break of backwards comparability regarding composite types 
returned from queries. 

Users of Ubuntu and Fedora can install the extension directly from the rpm and 
apt 
[repositories](https://github.com/ed-o-saurus/PLHaskell/blob/main/README.md#package-repositories).

If you have problems with the extension or a feature request, please submit a 
Github issue.

Re: problem z kernelami 6.6-6.6.26-1 i 6.8.5-1

[Krzysztof Mrozowicz via pld-devel-pl]

Dnia 2024-04-13, o godz. 10:45:24
Peri Noid  napisał(a):
> Potwierdzam, mi 6.8.5-1 (x86_64) wiesza się w momencie ładowania
> RAMdysku. PO prostu staje i nie reaguje na nic, włącznie z
> Alt+Ctrl+Del, trzeba wyłączyć prądowo. 6.8.1-1 (mój poprzedni) działa
> bez problemu.

Kernele 6.6.27-1 i 6.8.6-1 w moim przypadku działają dobrze.
Fajnie, że szybko naprawione ;)


-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

problem z kernelami 6.6-6.6.26-1 i 6.8.5-1

[Krzysztof Mrozowicz via pld-devel-pl]

Po aktualizacji kerneli do 6.8.5-1 i 6.6.26-1 na obu z nich
komputer przestał się uruchamiać - restartuje się zaraz po ładowaniu
początkowego ramdysku. Nie jestem w stanie zobaczyć żadnego komunikatu
z błędem.
Powrót do 6.8.2 naprawił problem. Sprawdziłem też 6.1.85-1 i też jest w
porządku.

-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl via Gcc-bugs]

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

--- Comment #32 from Piotr Kubaj  ---
(In reply to Iain Sandoe from comment #31)
> what is the current situation with this 
>  - what input are we waiting for?
>  - is the problem now cleared for powerpc64-freebsd?
Probably not, but FreeBSD now uses ELFv2 and LLVM, GCC builds fine with LLVM
with one small patch:
Index: gcc/tree-vect-loop.cc
===
--- gcc/tree-vect-loop.cc   (revision 273856)
+++ gcc/tree-vect-loop.cc   (working copy)
@@ -55,6 +55,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "vec-perm-indices.h"
 #include "tree-eh.h"

+#define vec_step vec_step_
+
 /* Loop Vectorization Pass.

This pass tries to vectorize loops.


All the releases using GCC 4.2.1 are EOL now.

[Bug testsuite/114182] gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #3 from Jan Dubiec  ---
Wait a minute, shouldn't the conditions be opposite? I.e.:

/* { dg-final { scan-tree-dump "__(?:gnu_)?divdc3" "optimized" { target {
large_double } } } } */

/* { dg-final { scan-tree-dump "__(?:gnu_)?divsc3" "optimized" { target { ! {
large_double } } } } } */

[Bug testsuite/114222] New: gcc.c-torture/execute/builtin-bitops-1.c fails for H8/300

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 114222
   Summary: gcc.c-torture/execute/builtin-bitops-1.c fails for
H8/300
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: h8300-elf

Excerpt from gcc.log:
[...]
Executing on host: /home/jdx/testgcc/builddir/gcc/xgcc
-B/home/jdx/testgcc/builddir/gcc/
/home/jdx/testgcc/combosrc/gcc/testsuite/gcc.c-torture/execute/builtin-bitops-1.c
   -fdiagnostics-plain-output-O0  -w  -isystem
/home/jdx/testgcc/builddir/h8300-elf/./newlib/targ-include -isystem
/home/jdx/testgcc/combosrc/newlib/libc/include -L/home/jdx/testgcc/builddir/ld
-B/home/jdx/testgcc/builddir/h8300-elf/./newlib/
-L/home/jdx/testgcc/builddir/h8300-elf/./newlib  -lm  -o ./builtin-bitops-1.exe
   (timeout = 300)
spawn -ignore SIGHUP /home/jdx/testgcc/builddir/gcc/xgcc
-B/home/jdx/testgcc/builddir/gcc/
/home/jdx/testgcc/combosrc/gcc/testsuite/gcc.c-torture/execute/builtin-bitops-1.c
-fdiagnostics-plain-output -O0 -w -isystem
/home/jdx/testgcc/builddir/h8300-elf/./newlib/targ-include -isystem
/home/jdx/testgcc/combosrc/newlib/libc/include -L/home/jdx/testgcc/builddir/ld
-B/home/jdx/testgcc/builddir/h8300-elf/./newlib/
-L/home/jdx/testgcc/builddir/h8300-elf/./newlib -lm -o ./builtin-bitops-1.exe
PASS: gcc.c-torture/execute/builtin-bitops-1.c   -O0  (test for excess errors)
spawn /home/jdx/testgcc/builddir/sim/h8300/run ./builtin-bitops-1.exe
program stopped with signal 4 (Illegal instruction).
FAIL: gcc.c-torture/execute/builtin-bitops-1.c   -O0  execution test
[...]

Further investigation showed that:
 a) the test case fails at line 181, (most likely) inside __builtin_ffs();
other __builtins work as expected,
 b) it happens when the test case is compiled with default options, i.e. when
ints are 16 bit wide; when -mint32 is added to the options (i.e. ints are 32
bit wide), the test passes.

[Bug testsuite/114182] gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #2 from Jan Dubiec  ---
Unfortunately, large_double does not work.

[Bug testsuite/114221] New: gcc.c-torture/execute/20101011-1.c fails for H8/300

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 114221
   Summary: gcc.c-torture/execute/20101011-1.c fails for H8/300
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: h8300-elf

Excerpt from gcc.sum:
[...]
PASS: gcc.c-torture/execute/20101011-1.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c   -O0  execution test
PASS: gcc.c-torture/execute/20101011-1.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c   -O1  execution test
PASS: gcc.c-torture/execute/20101011-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c   -O2  execution test
PASS: gcc.c-torture/execute/20101011-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c   -O3 -g  execution test
PASS: gcc.c-torture/execute/20101011-1.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c   -Os  execution test
PASS: gcc.c-torture/execute/20101011-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
PASS: gcc.c-torture/execute/20101011-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.c-torture/execute/20101011-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
[...]

Excerpt from gcc.log:
[...]
spawn -ignore SIGHUP /home/jdx/testgcc/builddir/gcc/xgcc
-B/home/jdx/testgcc/builddir/gcc/
/home/jdx/testgcc/combosrc/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
-fdiagnostics-plain-output -O0 -fnon-call-exceptions -isystem
/home/jdx/testgcc/builddir/h8300-elf/./newlib/targ-include -isystem
/home/jdx/testgcc/combosrc/newlib/libc/include -L/home/jdx/testgcc/builddir/ld
-B/home/jdx/testgcc/builddir/h8300-elf/./newlib/
-L/home/jdx/testgcc/builddir/h8300-elf/./newlib -lm -o ./20101011-1.exe
PASS: gcc.c-torture/execute/20101011-1.c   -O0  (test for excess errors)
spawn /home/jdx/testgcc/builddir/sim/h8300/run ./20101011-1.exe
program stopped with signal 5 (Trace/breakpoint trap).
FAIL: gcc.c-torture/execute/20101011-1.c   -O0  execution test
[...]

This is because H8 MCUs do not throw a "divide by zero" exception.

Proposed solution:
diff --git a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
index d2c0f9ab7ec..9fa10309612 100644
--- a/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/20101011-1.c
@@ -26,6 +26,9 @@
 #elif defined (__RX__)
   /* On RX division by zero does not trap.  */
 # define DO_TEST 0
+#elif defined (__H8300H__) || defined (__H8300S__) || defined (__H8300SX__)
+  /* On H8/300H, H8S and H8SX division by zero does not trap.  */
+# define DO_TEST 0
 #elif defined (__aarch64__)
   /* On AArch64 integer division by zero does not trap.  */
 # define DO_TEST 0

[Bug testsuite/114182] New: gcc.c-torture/compile/attr-complex-method-2.c fails for H8/300

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 114182
   Summary: gcc.c-torture/compile/attr-complex-method-2.c fails
for H8/300
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: h8300-elf

Created attachment 57581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57581=edit
Dump file for attr-complex-method-2.c

[...]
PASS: gcc.c-torture/compile/attr-complex-method-2.c   -O0  (test for excess
errors)
FAIL: gcc.c-torture/compile/attr-complex-method-2.c   -O0   scan-tree-dump
optimized "__(?:gnu_)?divdc3"
PASS: gcc.c-torture/compile/attr-complex-method-2.c   -O1  (test for excess
errors)
FAIL: gcc.c-torture/compile/attr-complex-method-2.c   -O1   scan-tree-dump
optimized "__(?:gnu_)?divdc3"
PASS: gcc.c-torture/compile/attr-complex-method-2.c   -O2  (test for excess
errors)
FAIL: gcc.c-torture/compile/attr-complex-method-2.c   -O2   scan-tree-dump
optimized "__(?:gnu_)?divdc3"
PASS: gcc.c-torture/compile/attr-complex-method-2.c   -O3 -g  (test for excess
errors)
FAIL: gcc.c-torture/compile/attr-complex-method-2.c   -O3 -g   scan-tree-dump
optimized "__(?:gnu_)?divdc3"
PASS: gcc.c-torture/compile/attr-complex-method-2.c   -Os  (test for excess
errors)
FAIL: gcc.c-torture/compile/attr-complex-method-2.c   -Os   scan-tree-dump
optimized "__(?:gnu_)?divdc3"
UNSUPPORTED: gcc.c-torture/compile/attr-complex-method-2.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none 
UNSUPPORTED: gcc.c-torture/compile/attr-complex-method-2.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 
PASS: gcc.c-torture/compile/attr-complex-method.c   -O0  (test for excess
errors)
PASS: gcc.c-torture/compile/attr-complex-method.c   -O0   scan-tree-dump-not
optimized "__divdc3"
PASS: gcc.c-torture/compile/attr-complex-method.c   -O1  (test for excess
errors)
PASS: gcc.c-torture/compile/attr-complex-method.c   -O1   scan-tree-dump-not
optimized "__divdc3"
PASS: gcc.c-torture/compile/attr-complex-method.c   -O2  (test for excess
errors)
PASS: gcc.c-torture/compile/attr-complex-method.c   -O2   scan-tree-dump-not
optimized "__divdc3"
PASS: gcc.c-torture/compile/attr-complex-method.c   -O3 -g  (test for excess
errors)
PASS: gcc.c-torture/compile/attr-complex-method.c   -O3 -g   scan-tree-dump-not
optimized "__divdc3"
PASS: gcc.c-torture/compile/attr-complex-method.c   -Os  (test for excess
errors)
PASS: gcc.c-torture/compile/attr-complex-method.c   -Os   scan-tree-dump-not
optimized "__divdc3"
UNSUPPORTED: gcc.c-torture/compile/attr-complex-method.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none 
UNSUPPORTED: gcc.c-torture/compile/attr-complex-method.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
[...]

According to the attached dump file, I believe the end of
attr-complex-method-2.c should look like this:
/* { dg-final { scan-tree-dump "__(?:gnu_)?divdc3" "optimized" { target { ! {
avr-*-* h8300-*-* } } } } } */

/* { dg-final { scan-tree-dump "__(?:gnu_)?divsc3" "optimized" { target {
avr-*-* h8300-*-* } } } } */

Similarly, shouldn't attr-complex-method.c also search for __divsc3 for AVR,
H8/300 and possibly a few other architectures?

[Bug libstdc++/114085] New: Internal (cross) compiler error when building libstdc++ for the H8/300 family

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 114085
   Summary: Internal (cross) compiler error when building
libstdc++ for the H8/300 family
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: h8300-elf

Created attachment 57519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57519=edit
Preprocessed libstdc++-v3/src/c++11/cxx11-locale-inst.cc

I get the following error when I try to build rev. 98702303:

[...]
make[5]: Leaving directory
'/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/c++98'
Making all in c++11
make[5]: Entering directory
'/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/c++11'
[...]
/bin/bash ../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/jdx/testgcc/builddir/./gcc/xgcc -shared-libgcc
-B/home/jdx/testgcc/builddir/./gcc -nostdinc++
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/.libs
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/libsupc++/.libs -nostdinc
-B/home/jdx/testgcc/builddir/h8300-elf/newlib/ -isystem
/home/jdx/testgcc/builddir/h8300-elf/newlib/targ-include -isystem
/home/jdx/testgcc/combosrc/newlib/libc/include
-B/home/jdx/testgcc/installdir/h8300-elf/bin/
-B/home/jdx/testgcc/installdir/h8300-elf/lib/ -isystem
/home/jdx/testgcc/installdir/h8300-elf/include -isystem
/home/jdx/testgcc/installdir/h8300-elf/sys-include
-L/home/jdx/testgcc/builddir/./ld   
-I/home/jdx/testgcc/combosrc/libstdc++-v3/../libgcc
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/h8300-elf
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include
-I/home/jdx/testgcc/combosrc/libstdc++-v3/libsupc++   -std=gnu++11  
-fno-implicit-templates  -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 
-fdiagnostics-show-location=once   -ffunction-sections -fdata-sections 
-frandom-seed=cxx11-locale-inst.lo  -g -O2  -c -o cxx11-locale-inst.lo
../../../../../combosrc/libstdc++-v3/src/c++11/cxx11-locale-inst.cc
libtool: compile:  /home/jdx/testgcc/builddir/./gcc/xgcc -shared-libgcc
-B/home/jdx/testgcc/builddir/./gcc -nostdinc++
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/src/.libs
-L/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/libsupc++/.libs -nostdinc
-B/home/jdx/testgcc/builddir/h8300-elf/newlib/ -isystem
/home/jdx/testgcc/builddir/h8300-elf/newlib/targ-include -isystem
/home/jdx/testgcc/combosrc/newlib/libc/include
-B/home/jdx/testgcc/installdir/h8300-elf/bin/
-B/home/jdx/testgcc/installdir/h8300-elf/lib/ -isystem
/home/jdx/testgcc/installdir/h8300-elf/include -isystem
/home/jdx/testgcc/installdir/h8300-elf/sys-include
-L/home/jdx/testgcc/builddir/./ld
-I/home/jdx/testgcc/combosrc/libstdc++-v3/../libgcc
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/h8300-elf
-I/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include
-I/home/jdx/testgcc/combosrc/libstdc++-v3/libsupc++ -std=gnu++11
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cxx11-locale-inst.lo -g -O2 -c
../../../../../combosrc/libstdc++-v3/src/c++11/cxx11-locale-inst.cc -o
cxx11-locale-inst.o
In file included from
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.h:2069,
 from
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/locale:43,
 from
../../../../../combosrc/libstdc++-v3/src/c++11/locale-inst.cc:38,
 from
../../../../../combosrc/libstdc++-v3/src/c++11/cxx11-locale-inst.cc:37:
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc:
In member function '_InIter std::__cxx11::money_get<_CharT,
_InIter>::_M_extract(iter_type, iter_type, std::ios_base&,
std::ios_base::iostate&, std::string&) const [with bool _Intl = true; _CharT =
char; _InIter = std::istreambuf_iterator >]':
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc:350:7:
error: unable to generate reloads for:
  350 |   }
  |   ^
(insn 1414 10225 9370 143 (set (mem/c:QI (plus:SI (reg/f:SI 11 fp)
(const_int -157 [0xff63])) [112 %sfp+-157 S1 A8])
(xor:QI (mem/c:QI (plus:SI (reg/f:SI 11 fp)
(const_int -157 [0xff63])) [112 %sfp+-157 S1
A8])
(const_int 1 [0x1])))
"/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_nonio.tcc":207:12
discrim 2 358 {xorqi3_1}
 (nil))
during RTL pass: reload
/home/jdx/testgcc/builddir/h8300-elf/libstdc++-v3/include/bits/locale_facets_

Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1

[Witold Filipczyk via pld-devel-pl]

Dnia Sat, Feb 03, 2024 at 08:56:25PM +0100, Jakub Bogusz napisał(a):
> On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote:
> > commit 3b3013be1262989c7a7df78ffab6d797766b6486
> > Author: Witold Filipczyk 
> > Date:   Sat Feb 3 20:24:04 2024 +0100
> > 
> > - updated to 5.249.0; rel 0.1
> > 
> >  kf5-attica.spec | 41 -
> >  1 file changed, 20 insertions(+), 21 deletions(-)
> 
> Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now?

OK. What to do with plasma (now kp5-*) and KDE Gear (now ka5-*) ?

> 
> 
> -- 
> Jakub Boguszhttp://qboosh.pl/
> ___
> pld-devel-pl mailing list
> pld-devel-pl@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
_______
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug binutils/31333] New: Unused variable in binutils/sim/common/dv-sockser.c

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31333

Bug ID: 31333
   Summary: Unused variable in binutils/sim/common/dv-sockser.c
   Product: binutils
   Version: 2.43 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: h8300-elf

This is what happened when I tried to build rev. e58beedf for H8:

[...]
  CC   h8300/dv-sockser.o
../../../binutils/sim/common/dv-sockser.c: In function 'connected_p':
../../../binutils/sim/common/dv-sockser.c:221:14: error: unused variable
'flags' [-Werror=unused-variable]
  221 |   int numfds,flags;
  |  ^
cc1.exe: all warnings being treated as errors
make[3]: *** [Makefile:5359: h8300/dv-sockser.o] Error 1
make[3]: Leaving directory '/d/Works/xcomp/binutils-build/sim'
make[2]: *** [Makefile:3235: all] Error 2
make[2]: Leaving directory '/d/Works/xcomp/binutils-build/sim'
make[1]: *** [Makefile:10890: all-sim] Error 2
make[1]: Leaving directory '/d/Works/xcomp/binutils-build'
make: *** [Makefile:1045: all] Error 2

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights

[marcin.godlewski at onet dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31216

--- Comment #6 from Marcin Godlewski  ---
Just wanted to correct myself, not to mislead anyone reading. With lld, by
default, although executable sections are mapped to a separate segment, the
executable segment mapping may still contain content of adjacent sections in
runtime as they share the page-sized chunk of the executable file. In order to
avoid this, -zseparate-code is required, similarly as for GNU ld.

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  PHDR   0x40 0x0040 0x0040 0x000268
0x000268 R   0x8
  INTERP 0x0002a8 0x02a8 0x02a8 0x1b
0x1b R   0x1
  [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
  LOAD   0x00 0x 0x 0x000704
0x000704 R   0x1
  LOAD   0x01 0x0001 0x0001 0x0001d0
0x0001d0 R E 0x1
  LOAD   0x02 0x0002 0x0002 0x000228
0x000228 RW  0x1
  LOAD   0x020228 0x00030228 0x00030228 0x10
0x11 RW  0x1
  DYNAMIC0x020010 0x00020010 0x00020010 0x0001b0
0x0001b0 RW  0x8
  GNU_RELRO  0x02 0x0002 0x0002 0x000228
0x001000 R   0x1
  GNU_EH_FRAME   0x0005f8 0x05f8 0x05f8 0x3c
0x3c R   0x4
  GNU_STACK  0x00 0x 0x 0x00
0x00 RW  0
  NOTE   0x0002c4 0x02c4 0x02c4 0x38
0x38 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00 
   01 .interp 
   02 .interp .note.ABI-tag .note.gnu.build-id .dynsym .gnu.version
.gnu.version_r .gnu.hash .dynstr .rela.dyn .rela.plt .rodata .eh_frame_hdr
.eh_frame 
   03 .text .init .fini .plt 
   04 .fini_array .init_array .dynamic .got .got.plt 
   05 .data .bss 
   06 .dynamic 
   07 .fini_array .init_array .dynamic .got .got.plt 
   08 .eh_frame_hdr 
   09 
   10 .note.ABI-tag .note.gnu.build-id

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights

[marcin.godlewski at onet dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31216

--- Comment #5 from Marcin Godlewski  ---
Clear, thank you for the explanation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights

[marcin.godlewski at onet dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31216

--- Comment #3 from Marcin Godlewski  ---
Or is it GNU ld build time configuration parameter and the issue should be
addressed to debian/ubuntu GNU ld maintainers?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights

[marcin.godlewski at onet dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31216

--- Comment #2 from Marcin Godlewski  ---
(In reply to Andreas Schwab from comment #1)
> Try linking with -zseparate-code.

This fixes the problem. Does it mean -zseparate-code is enabled by default in
x86-64, but not in aarch64?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31216] On aarch64 several sections are unnecessarily mapped to segment with executable rights

[marcin.godlewski at onet dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31216

Marcin Godlewski  changed:

   What|Removed |Added

 CC||marcin.godlewski at onet dot pl

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ld/31216] New: On aarch64 several sections are unnecessarily mapped to segment with executable rights

[marcin.godlewski at onet dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31216

Bug ID: 31216
   Summary: On aarch64 several sections are unnecessarily mapped
to segment with executable rights
   Product: binutils
   Version: 2.38
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: marcin.godlewski at onet dot pl
  Target Milestone: ---

On Ubuntu 22.04 LTS, with GNU ld 2.38 for aarch64 (either native on Ubuntu
arm64 or cross-toolchain on Ubuntu amd64), building a classic 'Hello World"
program produces a binary with the following section to segment mappings:

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  PHDR   0x40 0x0040 0x0040 0x0001f8
0x0001f8 R   0x8
  INTERP 0x000238 0x0238 0x0238 0x1b
0x1b R   0x1
  [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
  LOAD   0x00 0x 0x 0x000884
0x000884 R E 0x1
  LOAD   0x000d90 0x00010d90 0x00010d90 0x000280
0x000288 RW  0x1
  DYNAMIC0x000da0 0x00010da0 0x00010da0 0x0001f0
0x0001f0 RW  0x8
  NOTE   0x000254 0x0254 0x0254 0x44
0x44 R   0x4
  GNU_EH_FRAME   0x000798 0x0798 0x0798 0x3c
0x3c R   0x4
  GNU_STACK  0x00 0x 0x 0x00
0x00 RW  0x10
  GNU_RELRO  0x000d90 0x00010d90 0x00010d90 0x000270
0x000270 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00 
   01 .interp 
   02 .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata
.eh_frame_hdr .eh_frame 
   03 .init_array .fini_array .dynamic .got .data .bss 
   04 .dynamic 
   05 .note.gnu.build-id .note.ABI-tag 
   06 .eh_frame_hdr 
   07 
   08 .init_array .fini_array .dynamic .got

The sections: .rodata .interp .note.gnu.build-id .note.ABI-tag .gnu.hash
.dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt seem to be
unnecessarily mapped to executable LOAD segment. Instead, there may be a
separate read-only LOAD segment dedicated for these sections. This is the way
GNU ld behaves on  x86-64 architecture. Also LLVM lld on aarch64 produces
dedicated separate segment for the sections in question. Hello World built with
gcc -fuse-ld=lld option produces the desired mapping:

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  PHDR   0x40 0x0040 0x0040 0x000268
0x000268 R   0x8
  INTERP 0x0002a8 0x02a8 0x02a8 0x1b
0x1b R   0x1
  [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
  LOAD   0x00 0x 0x 0x000704
0x000704 R   0x1
  LOAD   0x000740 0x00010740 0x00010740 0x0001d0
0x0001d0 R E 0x1
  LOAD   0x000910 0x00020910 0x00020910 0x000228
0x000228 RW  0x1
  LOAD   0x000b38 0x00030b38 0x00030b38 0x10
0x11 RW  0x1
  DYNAMIC0x000920 0x00020920 0x00020920 0x0001b0
0x0001b0 RW  0x8
  GNU_RELRO  0x000910 0x00020910 0x00020910 0x000228
0x0006f0 R   0x1
  GNU_EH_FRAME   0x0005f8 0x05f8 0x05f8 0x3c
0x3c R   0x4
  GNU_STACK  0x00 0x 0x 0x00
0x00 RW  0
  NOTE   0x0002c4 0x02c4 0x02c4 0x38
0x38 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00 
   01 .interp 
   02 .interp .note.ABI-tag .note.gnu.build-id .dynsym .gnu.version
.gnu.version_r .gnu.hash .dynstr .rela.dyn .rela.plt .rodata .eh_frame_hdr
.eh_frame 
   03 .text .init .fini .plt 
   04 .fini_array .init_array .dynamic .got .got.plt 
   05 .data .bss 
   06 .dynamic 
   07 .fini_array .init_array .dynamic .got .got.plt 
   08 .eh_frame_hdr 
   09 
   10 .note.ABI-tag .note.gnu.build-id

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug other/113147] Building a crosscompiler fails under MigW-W64/MSYS2 @ Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #2 from Jan Dubiec  ---
(In reply to Andrew Pinski from comment #1)
> Don't use `--disable-host-shared` basically.

OK, removal of this option seems to solve the problem, but... I had an
impression that the above set of options (including "--disable-host-shared")
used to work for me quite well earlier this year. I have checked out 13.1.0
(commit cc035c5d) and it has been built without problems. So, taking into
account your words, there used to be an issue then, or there is an issue *now*.

[Bug other/113147] New: Building a crosscompiler fails under MigW-W64/MSYS2 @ Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 113147
   Summary: Building a crosscompiler fails under MigW-W64/MSYS2 @
Windows 10
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: h8300-elf, arm-elf

The following error occurs when I try to build a crosscompiler under
MigW-W64/MSYS2:

[...]
rm -rf libcommon.a
ar  rc libcommon.a diagnostic-spec.o diagnostic.o diagnostic-color.o
diagnostic-format-json.o diagnostic-format-sarif.o diagnostic-show-locus.o
edit-context.o pretty-print.o intl.o json.o sbitmap.o vec.o input.o
hash-table.o ggc-none.o memory-block.o selftest.o selftest-diagnostic.o sort.o
text-art/box-drawing.o text-art/canvas.o text-art/ruler.o text-art/selftests.o
text-art/style.o text-art/styled-string.o text-art/table.o text-art/theme.o
text-art/widget.o
ranlib   libcommon.a
make[2]: *** No rule to make target '../libiberty/pic/libiberty.a', needed by
'cc1-checksum.cc'.  Stop.
make[2]: Leaving directory '/d/Works/xcomp/gcc-build/gcc'
make[1]: *** [Makefile:4683: all-gcc] Error 2
make[1]: Leaving directory '/d/Works/xcomp/gcc-build'
make: *** [Makefile:1049: all] Error 2

Configure options:
../../gcc/configure --prefix=/usr/local --with-sysroot=$CWD/sysroot
--target=h8300-elf --disable-nls --disable-threads --disable-tls
--enable-checking=release --enable-languages=c --with-newlib --without-headers
--enable-multilib --enable-lto --disable-shared --enable-static
--disable-host-shared --disable-bootstrap --disable-libatomic --disable-libgomp
--disable-libitm --disable-libquadmath --disable-libsanitizer --disable-libssp
--disable-libvtv --with-system-zlib

Everything is fine on Ubuntu with the same options.

Re: konflikty między pakietami x86_64 i i686

[Krzysztof Mrozowicz via pld-devel-pl]

Dnia 2023-12-05, o godz. 21:11:24
Peri Noid  napisał(a):

> Przyjrzyj się uważnie - to są różne pakiety. Automatyka pozwala
> zainstalować paczki dla różnych architektur ale wyłącznie w tej samej
> wersji. Lekarstwem na to jest ... poczekać, aż drugi builder
> przemiele paczki i wtedy zainstalować komplet. Owszem, czasami
> zdarzają się pojedyncze przypadki, gdzie konflikt rzeczywiście
> występuje. Ale to nie twój przypadek.

Dzięki za odpowiedź! Wydaje mi się, że masz rację, przynajmniej
częściowo. W moim przypadku pakiet był zbudowany przez oba buildery,
ale to poldek najpierw chciał aktualizować x86_64 (i wywalił błąd), a
potem osobno i686 (i również wywalił błąd).
Kiedy ręcznie mu dałem obie architektury do zaktualizowania za jednym
razem, to poszło prawidłowo.

> upgrade libuuid-2.39.3-1.x86_64 libuuid-2.39.3-1.i686

Pozdrawiam!

-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

konflikty między pakietami x86_64 i i686

[Krzysztof Mrozowicz via pld-devel-pl]

Hej,
używam PLD w wersji x86_64. Mam też zainstalowane wine-i686, które
oczywiście ma sporo zależności i686. Jak to instalowałem, to musiałem
sporo rzeczy zainstalować z opcją --force bo niektóre pakiety
konfliktowały ze sobą dostarczając te same pliki.
Potem przy kolejnych update'ach trzeba było ręcznie wymuszać niektóre
aktualizacje ze względu na te same konflikty.

No i tak sobie myślę żeby może te konfliktujące pliki wywalić do
osobnego podpakietu -data.noarch?

Np pliki z poniższego przykładu dać do pakietu
libuuid-data-%{version}.noarch?

Sprawdzanie poprawności…   # [100%]
Przygotowywanie…# [100%]
plik /usr/share/man/de/man1/uuidgen.1.gz z instalacji 
libuuid-2.39.3-1.x86_64 jest w konflikcie z plikiem z pakietu 
libuuid-2.39.2-1.i686
plik /usr/share/man/man1/uuidgen.1.gz z instalacji 
libuuid-2.39.3-1.x86_64 jest w konflikcie z plikiem z pakietu 
libuuid-2.39.2-1.i686
plik /usr/share/man/sr/man1/uuidgen.1.gz z instalacji 
libuuid-2.39.3-1.x86_64 jest w konflikcie z plikiem z pakietu 
libuuid-2.39.2-1.i686
plik /usr/share/man/uk/man1/uuidgen.1.gz z instalacji 
libuuid-2.39.3-1.x86_64 jest w konflikcie z plikiem z pakietu 
libuuid-2.39.2-1.i686

Było tego więcej, choć nie tak dużo. Zdaje się, że openssl i openssh
miały podobny problem. Swoją drogą, czy ktoś wie czemu /usr/bin/uuidgen
dostarczane przez oba pakiety nie pojawia się na liście konfliktów? Czy
to jakiś wewnętrzny mechanizm RPMa dba o to?

Pozdrawiam!

-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #6 from Jan Dubiec  ---
(In reply to Florian Weimer from comment #3)
> Jan, do you actually experience a build failure? The part you quoted only
> shows warnings.
Florian, it used to be just the warnings, but now (commit 1461b431) I am not
even able to reach emutls.c:
[...]
rm -rf libcommon.a
ar  rc libcommon.a diagnostic-spec.o diagnostic.o diagnostic-color.o
diagnostic-format-json.o diagnostic-format-sarif.o diagnostic-show-locus.o
edit-context.o pretty-print.o intl.o json.o sbitmap.o vec.o input.o
hash-table.o ggc-none.o memory-block.o selftest.o selftest-diagnostic.o sort.o
text-art/box-drawing.o text-art/canvas.o text-art/ruler.o text-art/selftests.o
text-art/style.o text-art/styled-string.o text-art/table.o text-art/theme.o
text-art/widget.o
ranlib   libcommon.a
make[2]: *** No rule to make target '../libiberty/pic/libiberty.a', needed by
'cc1-checksum.cc'.  Stop.
make[2]: Leaving directory '/d/works/xcomp/gcc-build/gcc'
make[1]: *** [Makefile:4645: all-gcc] Error 2
make[1]: Leaving directory '/d/works/xcomp/gcc-build'
make: *** [Makefile:1048: all] Error 2

Host: Windows/MSYS2, targets: ARM and H8

Re: [PRQ#44789] Orphan Request for crystalline

[hugo . pl]

Hi,

Do you want to be the new maintainer? I'm still maintain it, but in a 
low effort way... this is why I didn't solved the compilation problem 
it has since 0.7.0.


If you want to be the new maintainer, just tell me the steps I need to 
do.


Thanks,
Hugo Parente Lima

On Mon, Jul 17 2023 at 09:58:34 AM +00:00:00, not...@aur.archlinux.org 
wrote:

AlexWayfer [1] filed an orphan request for crystalline [2]:

I've emailed maintainer and haven't receive answer for more than 2
weeks.

[1] 
[2] 

[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work

[argothiel at interia dot pl via Gcc-bugs]

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

argothiel  changed:

   What|Removed |Added

 CC||argothiel at interia dot pl

--- Comment #5 from argothiel  ---
This issue still occurs in GCC 13.2 despite fixing PR53431:
https://godbolt.org/z/6xon1cTfh

[Bug c/111613] New: Bit field stores can be incorrectly optimized away when -fstore-merging is in effect

[gcc at kempniu dot pl via Gcc-bugs]

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

Bug ID: 111613
   Summary: Bit field stores can be incorrectly optimized away
when -fstore-merging is in effect
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at kempniu dot pl
  Target Milestone: ---

Created attachment 56002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56002=edit
Preprocessed reproducer

This is the simplest reproducer I could come up with:

$ cat bitfield.c
#include 
#include 

struct bitfield {
unsigned int field1 : 1;
unsigned int field2 : 1;
unsigned int field3 : 1;
};

__attribute__((noinline)) static void
set_field1_and_field2(struct bitfield *b) {
b->field1 = 1;
b->field2 = 1;
}

__attribute__((noinline)) static struct bitfield *
new_bitfield(void) {
struct bitfield *b = (struct bitfield *)malloc(sizeof(*b));
b->field3 = 1;
set_field1_and_field2(b);
return b;
}

int main(void) {
struct bitfield *b = new_bitfield();
printf("%d\n", b->field3);
return 0;
}
$ gcc -O2 -o bitfield bitfield.c
$ ./bitfield
0
$ gcc -O2 -fno-store-merging -o bitfield bitfield.c
$ ./bitfield
1

Removing one of the stores from set_field1_and_field2() makes the issue
go away.  Moving "b->field3 = 1;" below the call to
set_field1_and_field2() also makes the issue go away.

This was originally found for the following GCC version:

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC) 

However, I have subsequently confirmed that it also happens on the
current master branch.

A git bisect points at the following commit as the culprit (first
included in GCC 12.1.0):

commit 22c242342e38ebffa6bbf7e86e7a1e4abdf0d686
Author: Martin Liska 
Date:   Thu Nov 18 17:50:19 2021 +0100

IPA: fix reproducibility in IPA MOD REF

gcc/ChangeLog:

* ipa-modref.c (analyze_function): Do not execute the code
only if dump_file != NULL.

Reverting this change on top of current master makes the issue
disappear, so it looks legit to me.

Disassembly of new_bitfield() for "gcc -O2":

   0x1190 <+0>: sub$0x8,%rsp
   0x1194 <+4>: mov$0x4,%edi
   0x1199 <+9>: call   0x1040 
   0x119e <+14>:mov%rax,%rdi
   0x11a1 <+17>:call   0x1180 
   0x11a6 <+22>:add$0x8,%rsp
   0x11aa <+26>:ret

Disassembly of new_bitfield() for "gcc -O2 -fno-store-merging":

   0x1190 <+0>: sub$0x8,%rsp
   0x1194 <+4>: mov$0x4,%edi
   0x1199 <+9>: call   0x1040 
   0x119e <+14>:orb$0x4,(%rax)
   0x11a1 <+17>:mov%rax,%rdi
   0x11a4 <+20>:call   0x1180 
   0x11a9 <+25>:add$0x8,%rsp
   0x11ad <+29>:ret

Re: katalogi kde

[Krzysztof Mrozowicz via pld-devel-pl]

Dnia 2023-09-04, o godz. 12:05:40
Peri Noid  napisał(a):
> To może dodać do ka5-akonadi, do którego należy katalog nadrzędny
> $ rpm -qf /usr/lib64/qt5/plugins/pim5/
> ka5-akonadi-23.08.0-1.x86_64

Tak też zrobiłem. Dzięki!


-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

katalogi kde

[Krzysztof Mrozowicz via pld-devel-pl]

Hej,
w ramach ostatniej aktualizacji ka5-akonadi-contacts zniknął katalog
/usr/lib64/qt5/plugins/pim5/kcms. Okazuje się, że wymaga go sporo
innych pakietów, a że w PLD (nie wiem jak w innych dystrybucjach)
katalogi stanowią o zależnościach między pakietami to nie można raczej
dowolnie dodać tego katalogu do jednego z pozostałych pakietów go
wymagających. Można ewentualnie do każdego z nich, co też jest wg mnie
takim sobie pomysłem. No i ewentualnie można go dodać do
kde-common-dirs (albo kf5-dirs?).

Niech mi ktoś powie jak to najlepiej ugryźć, proszę.


-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug target/111170] New: Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library)

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 70
   Summary: Malformed manifest does not allow to run gcc on
Windows XP (Accessing a corrupted shared library)
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
CC: costas.argyris at gmail dot com
  Target Milestone: ---
Target: i686-w64-mingw32 @ Windows XP
 Build: i686-w64-mingw32 @ Windows 10

I wanted to build gcc 13.2 with intention to run it on an old Windows
XP/Pentium-M machine. My build environment is MSYS2/MinGW32 @ Windows 10.
Everything went fine and I could run resulting binaries on the build machine
under MinGW32 terminal. However when I tried to run them on the target machine,
I got "bash: ./mingw-gcc/bin/gcc: Accessing a corrupted shared library". After
a few days of heavy fight I found out that this is due to malformed manifest
embedded in some (not all!) gcc executables. Newer version of Windows are more
forgiving and can tolerate malformed manifests while Windows XP is not; that's
why I could run freshly built gcc on my Windows 10 box. Using a resource editor
I have replaced malformed manifests with a default one (taken from
https://packages.msys2.org/base/mingw-w64-windows-default-manifest) and now
everything runs fine on XP.

The malformed manifest comes from
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d11e088210a551235d3937f867ee1c8b19d02290
related to PR108865. I think the proper solution is to merge default manifest
from MSYS and the one mentioned in the diff above.

bug#65342: In Ubuntu 22.04 (unlike 20.04), sorting doesn't work properly

[Pl B]

Source file:
rs1009150173,100202244031
rs1009150172,13853975996
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150,171582090052

Ubuntu 20.04.5:
sort -t ',' /path/to/rs_srt_exp.txt
rs1009150,171582090052
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150172,13853975996
rs1009150173,100202244031
(correct order)

elementary OS 7 (Ubuntu 22.04.3):
sort -t ',' /path/to/rs_srt_exp.txt
rs1009150170,54321425962
rs1009150171,11378896079
rs1009150,171582090052
rs1009150172,13853975996
rs1009150173,100202244031
(wrong order)

Python 3.10.12:
with open('/path/to/rs_srt_exp.txt') as src_file_opened:
for elem in sorted(map(lambda line: line.rstrip().split(','),
src_file_opened)):
print(elem)
['rs1009150', '171582090052']
['rs1009150170', '54321425962']
['rs1009150171', '11378896079']
['rs1009150172', '13853975996']
['rs1009150173', '100202244031']
(correct order)

[Bug libstdc++/96733] std::clamp for floats and doubles produces worse code than a combo of std::min / std::max

[cosiekvfj at o2 dot pl via Gcc-bugs]

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

Kacper  changed:

   What|Removed |Added

 CC||cosiekvfj at o2 dot pl

--- Comment #10 from Kacper  ---
Still not fixed?
https://godbolt.org/z/1ehf9EsEa

PL/R 8.4.6 released

[PL/R via PostgreSQL Announce]

The PL/R team is proud to announce the release of version 8.4.6

This release is mainly to fix some issues building the code with version 16 of 
PostgreSQL and releasing windows builds with R version 4.1.3 and 4.2.3

PL/R is a procedural language which allows you to write PostgreSQL functions in 
R.

The code can be found at [PLR project](https://github.com/postgres-plr)

The most recent changes can be found in the 
[Changelog](https://github.com/postgres-plr/plr/blob/master/changelog.md)

We would like to thank everyone that contributed!

Dave

pldcpan.pl - potrzebna poprawka

[Arkadiusz Miśkiewicz via pld-devel-pl]

Mógłby fan perla zerknąć na nasz pldcpan i poprawić mu regułki parsujące 
nazwę by działał także z takimi przypadkami jak:


./pldcpan/pldcpan.pl IP::Country::DB_File

?

--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: problem z sudo 1.9.14

[Krzysztof Mrozowicz via pld-devel-pl]

W dniu: Wtorek, Lipiec 04, 2023 10:45 IST, Jan Palus  
napisał(a):

> On 04.07.2023 09:33, Krzysztof Mrozowicz via pld-devel-pl wrote:
> > Zauważyłem, że po aktualizacji sudo do wersji 1.9.14, w środowisku chroot, 
> > zwykły użytkownik stracił możliwość instalowania pakietów poldkiem. Pojawia 
> > się następujący komunikat:
> > sudo: nie udało się przydzielić pty: Nie ma takiego urządzenia
> 
> Polecam udać się do release notesów sudo 1.9.14:
> 
> https://www.sudo.ws/releases/stable/#1.9.14
> 
> i wyszukać "pty".

Dziękuję uprzejmie!
_______
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

problem z sudo 1.9.14

[Krzysztof Mrozowicz via pld-devel-pl]

Zauważyłem, że po aktualizacji sudo do wersji 1.9.14, w środowisku chroot, 
zwykły użytkownik stracił możliwość instalowania pakietów poldkiem. Pojawia się 
następujący komunikat:
sudo: nie udało się przydzielić pty: Nie ma takiego urządzenia

A poniżej log z poldka obrazujący problem.

Installing set #28
Przetwarzanie zależności...
sudo-1.9.13p3-1.x86_64 zostanie zastąpiony przez sudo-1.9.14-1.x86_64
Jest 1 pakiet do instalacji, 1 do usunięcia:
U sudo-(1.9.13p3 => 1.9.14)-1.x86_64
This operation will use 199.2KB of disk space.
Potrzeba pobrać 1.6MB archiwów (1.6MB do pobrania).

th-test::sudo-1.9.14-1.x86_64.rpm [1.6M (1.6M/s)]
sudo-1.9.14-1.x86_64.rpm: skróty OK
Uruchamianie sudo /usr/lib/poldek/pm-command.sh --upgrade -vh --root / --define 
_check_dirname_deps 0...
Sprawdzanie poprawności…   
Przygotowywanie…
Aktualizowanie/instalowanie…
sudo-1:1.9.14-1   
Czyszczenie/usuwanie…
sudo-1:1.9.13p3-1 
Installing set #29
Przetwarzanie zależności...
enchant2-2.3.3-2.x86_64 zostanie zastąpiony przez enchant2-2.3.3-3.x86_64
enchant2-devel-2.3.3-2.x86_64 zostanie zastąpiony przez 
enchant2-devel-2.3.3-3.x86_64
Są 2 pakiety do instalacji, 2 do usunięcia:
U enchant2-2.3.3-(2 => 3).x86_64  enchant2-devel-2.3.3-(2 => 3).x86_64
This operation will free 8.0B of disk space.
Potrzeba pobrać 57.4KB archiwów (57.4KB do pobrania).

[1/2] th-test::enchant2-2.3.3-3.x86_64.rpm [42.3K (42.3K/s)]
[2/2] th-test::enchant2-devel-2.3.3-3.x86_64.rpm [15.1K (15.1K/s)]
enchant2-2.3.3-3.x86_64.rpm: skróty OK
enchant2-devel-2.3.3-3.x86_64.rpm: skróty OK
Uruchamianie sudo /usr/lib/poldek/pm-command.sh --upgrade -vh --root / --define 
_check_dirname_deps 0...
sudo: nie udało się przydzielić pty: Nie ma takiego urządzenia
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

PL/Haskell v3.0 Released

[PL/Haskell via PostgreSQL Announce]

We are pleased to announce the release of version 3.0 of the [PL/Haskell 
extension](https://github.com/ed-o-saurus/PLHaskell/releases/3.0). This 
extension allows users to write PostgreSQL functions in the Haskell functional 
programming language. Instructions can be found 
[here](https://github.com/ed-o-saurus/PLHaskell/blob/main/README.md).

Version 3.0 adds the ability to execute untrusted code which allows for greater 
flexibility of functionality. 

Users of Ubuntu and Fedora can install the extension directly from the rpm and 
apt 
[repositories](https://github.com/ed-o-saurus/PLHaskell/blob/main/README.md#package-repositories).

If you have problems with the extension or a feature request, please submit a 
Github issue.

Re: zepsuł się firefox

[Krzysztof Mrozowicz via pld-devel-pl]

Dnia 2023-06-16, o godz. 10:24:44
Peri Noid  napisał(a):

> Wyglada jakby nie ładowały ci się sterowniki go GLX. To nie wina
> Firefoksa ale brakujących plików Mesa. Jaką masz kartę graficzną?
> Generalnie, odpal glxinfo i zobacz, co wyświetla.

Dzięki za odpowiedź, mimo że problem leżał gdzie indziej. Przy okazji
wyszło, że sterowniki mesa do procków Intela generacji 4-7 poprawiają
wydajność grafiki z i7 2. generacji :)


-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: zepsuł się firefox

[Krzysztof Mrozowicz via pld-devel-pl]

Dnia 2023-06-16, o godz. 22:02:06
Jan Palus  napisał(a):

> Z nss-3.90-2 powinno być już dobrze. nss 3.90 na x86_64 zaczął
> bezwarunkowo używać instrukcji ADX/BMI2 które to nie są obecne w
> starszych procesorach. w rel 2 zostało to całkiem wyłączone.

Rzeczywiście pomogło. Dziękuję bardzo!

-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: zepsuł się firefox

[Krzysztof Mrozowicz via pld-devel-pl]

Dnia 2023-06-16, o godz. 11:26:22
Jan Palus  napisał(a):
> 
> 1. Czy działa mozilla-firefox-bin?
Nie działa. Nie działa w taki sam sposób.

> 2. Czy na czystym profilu działa? (firefox -ProfileManager)
Nie działa. Startuje okno, i po chwili znika.
> 3. Czy jest coś w .xsession-errors bądź Xorg.0.log, chyba że to
> wayland?
Nie było tam nic użytecznego. W żadnym z powyższych plików.

Udało mi się (tymczasowo) rozwiązać problem poprzez przywrócenie nss do
wersji nss-1:3.89-1 razem z zależnościami. Mam teraz firefoksa 111, ale
lepszy taki niż niedziałający 114.

Pozdrawiam.

 ___
> pld-devel-pl mailing list
> pld-devel-pl@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl



-- 
Krzysiek
_______
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

zepsuł się firefox

[Krzysztof Mrozowicz via pld-devel-pl]

Hej,
zrobiłem wczoraj wieczorem "upgrade *" z włączonymi th, th-ready i
th-test. Potem reboot, po paru dniach uptime. No i mi się firefox
zepsuł.
Pojawia się okno programu na chwilę, a potem znika i sypie błędem:

[GFX1-]: FireTestProcess failed: Wywołanie procesu potomnego 
„/usr/lib64/firefox/glxtest” (Nie ma takiego pliku ani katalogu) się nie 
powiodło

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: 
ManageChildProcess failed
 (t=0.47527) [GFX1-]: glxtest: ManageChildProcess failed

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: 
ManageChildProcess failed
 (t=0.47527) |[1][GFX1-]: No GPUs detected via PCI
 (t=0.47532) [GFX1-]: No GPUs detected via PCI

console.error: ({})
Exiting due to channel error.
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: CompositorBridgeChild 
receives IPC close with reason=AbnormalShutdown (t=2.01031) [GFX1-]: 
CompositorBridgeChild receives IPC close with reason=AbnormalShutdown
[1]12583 illegal hardware instruction (core dumped)  firefox
Exiting due to channel error.

Ktoś ma pomysł co to się porobiło?

-- 
Krzysiek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

PL/Java 1.6.5 released

[PL/Java Project via PostgreSQL Announce]

1.6.5 is the latest PL/Java release, bringing functions, triggers, aggregates, 
types, operators, etc. in Java to PostgreSQL (15 back to 9.5). PL/Java 1.6.5 
will build and operate with Java versions 9 through (so far) 20. It need not 
operate with the same Java version used to build it, and can run application 
code ranging from pre-Java-9 legacy code, to code using the latest features of 
the Java version present at run time.

1.6.5 adds support for PostgreSQL 15, fixes several bugs, and will now permit 
methods declared on interfaces as well as on classes. More on some selected 
changes may be found below.

Current users of a 1.5.x release should thoroughly review the 1.6 series 
release notes for changes that may require attention before updating to a 1.6 
release.

Project site: [https://tada.github.io/pljava/](https://tada.github.io/pljava/)

Release notes: 
[https://tada.github.io/pljava/releasenotes.html](https://tada.github.io/pljava/releasenotes.html)

## Selected changes:

* Bugs affecting `install_jar` from http/https URLs fixed _-
* PL/Java functions can be declared on interfaces as well as classes  
* SQL generator source-version warnings suppressed, through Java 20

Please see the [release notes](https://tada.github.io/pljava/releasenotes.html) 
for a more complete list of changes.

##Availability:

1.6.5 is available from GitHub as a source release, which builds quickly using 
Maven:

Release page: 
[https://github.com/tada/pljava/releases/tag/V1_6_5](https://github.com/tada/pljava/releases/tag/V1_6_5)

This wiki page will add links to prebuilt packages that become available:

[https://github.com/tada/pljava/wiki/Prebuilt-packages](https://github.com/tada/pljava/wiki/Prebuilt-packages)

Re: Upgrade - umarła samba, ssh...

[Arkadiusz Miśkiewicz via pld-devel-pl]

On 9.05.2023 11:19, Jacek Osiecki wrote:

Hej,

nieopatrznie na lokalnym serwerze, na którym już w sumie niewiele się działo - 
zrobiłem „upgrade *”.


Jak już tak poszło do upewniłeś się, że masz wszystko aktualne?

rpm -qV glibc libxcrypt

Trochę szukanie w ciemno ale dodam że mam kilka maszyn z aktualnym th, 
kilkanaście z nieco starszym (z 2 tyg) i problemu nie odnotowałem.





No i kuczę… posypało się praktycznie wszystko.
Nie da się na serwer zaSSHować, od razu mam „connection closed by …”
Lokalnie można się zalogować na konsoli, ale „ssh localhost” daje identyczny 
efekt.

Próbowałem zwiększyć logi do poziomu debug - niewiele pomogło, poniżej widok 
próby logowania.

May  9 10:58:03 serwer sshd[3606]: debug1: Bind to port 22 on 0.0.0.0.
May  9 10:59:02 serwer sshd[3606]: debug1: Forked child 3964.
May  9 10:59:02 serwer sshd[3964]: debug1: Set /proc/self/oom_score_adj to 0
May  9 10:59:02 serwer sshd[3964]: debug1: rexec start in 5 out 5 newsock 5 
pipe 7 sock 8
May  9 10:59:02 serwer sshd[3964]: debug1: inetd sockets after dupping: 4, 4
May  9 10:59:02 serwer sshd[3964]: debug1: Local version string 
SSH-2.0-OpenSSH_9.3
May  9 10:59:02 serwer sshd[3964]: debug1: Remote protocol version 2.0, remote 
software version OpenSSH_9.0
May  9 10:59:02 serwer sshd[3964]: debug1: compat_banner: match: OpenSSH_9.0 
pat OpenSSH* compat 0x0400
May  9 10:59:02 serwer sshd[3964]: debug1: permanently_set_uid: 40/99 [preauth]
May  9 10:59:02 serwer sshd[3964]: debug1: list_hostkey_types: 
rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
May  9 10:59:02 serwer sshd[3964]: debug1: monitor_read_log: child log fd closed
May  9 10:59:02 serwer sshd[3964]: debug1: do_cleanup
May  9 10:59:02 serwer sshd[3964]: debug1: Killing privsep child 3965
May  9 10:59:02 serwer sshd[3964]: debug1: audit_event: unhandled event 12


Jaki kernel, glibc?


Do tego samba też się posypała. Moja wina, bo jakieś stare dyrektywy w 
smbd.conf - ale wywaliło się bardzo brzydko,
bo odpalenie /etc/init.d/samba restart po prostu przechodzi do następnej 
linijki - nawet nie pokazuje że próbowało parsować, startować, cokolwiek.


Wyzerowało plik init?

sh -x /etc/init.d/samba ...

--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

--- Comment #4 from Jamaika  ---
https://github.com/gabime/spdlog/blob/v1.x/example/example.cpp
```
for %%f in ("example.cpp") do g++.exe -v -std=gnu++20 -march=x86-64-v2
-ftree-vectorize -g0 -O3 -fPIC -mavx -mxsave -mpclmul -maes
-DSPDLOG_USE_STD_FORMAT=1 -c %%f -o %%~nf.o
```

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

--- Comment #3 from Jamaika  ---
SPDLOG claims that MSVC compiles.

[Bug c++/109688] New: Build fail with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

Bug ID: 109688
   Summary: Build fail with C++20 and -DSPDLOG_USE_STD_FORMAT=1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukaszcz18 at wp dot pl
  Target Milestone: ---

```
Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++
--with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target
--with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --enable-libssp
--prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230421 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=gnu++20' '-march=x86-64-v2' '-ftree-vectorize'
'-g0' '-O3' '-fPIC' '-mavx' '-mxsave' '-mpclmul' '-maes' '-D'
'SPDLOG_USE_STD_FORMAT=1' '-c' '-o' 'example.o'
 C:/gcc1301/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.1/cc1plus.exe -quiet -v
-iprefix C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/ -U_REENTRANT -D
SPDLOG_USE_STD_FORMAT=1 example.cpp -quiet -dumpbase example.cpp -dumpbase-ext
.cpp -march=x86-64-v2 -mavx -mxsave -mpclmul -maes -g0 -O3 -std=gnu++20
-version -ftree-vectorize -fPIC -o
C:\Users\KOMPUT~1\AppData\Local\Temp\ccxiMnxa.s
GNU C++20 (GCC) version 13.0.1 20230421 (prerelease) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.1 20230421 (prerelease), GMP version
6.2.1, MPFR version 4.2.0-p4, MPC version 1.3.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/x86_64-w64-mingw32"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/backward"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/include"
ignoring nonexistent directory
"/home/ma/m/target/home/ma/m/target/lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/include-fixed"
ignoring duplicate directory
"C:/gcc1301/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/home/ma/m/target/mingw/include"
#include "..." search starts here:
#include <...> search starts here:

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/x86_64-w64-mingw32

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../include/c++/13.0.1/backward
 C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/include
 C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/include-fixed

C:/gcc1301/bin/../lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../x86_64-w64-mingw32/include
End of search list.
Compiler executable checksum: c5bc1656e1b332d798c0577f7a3d2ab8
In file included from C:/gcc1301/include/c++/13.0.1/bits/chrono_io.h:39,
 from C:/gcc1301/include/c++/13.0.1/chrono:3330,
 from example.cpp:8:
C:/gcc1301/include/c++/13.0.1/format: In instantiation of 'static
std::__format::_Arg_store<_Context, _Args>::_Element_t
std::__format::_Arg_store<_Context, _Args>::_S_make_elt(_Tp&) [with _Tp =
spdlog::details::dump_info<__gnu_cxx::__normal_iterator > >; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}; _Element_t =
std::__format::_Arg_store,
char>,
std::basic_format_arg,
char> >::handle>::_Element_t]':
C:/gcc1301/include/c++/13.0.1/format:3252:23:   required from
'std::__format::_Arg_store<_Context, _Args>::_Arg_store(_Tp& ...) [with _Tp =
{spdlog::details::dump_info<__gnu_cxx::__normal_iterator > > >}; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}]'
C:/gcc1301/include/c++/13.0.1/format:3301:14:   required from 'auto
std::make_format_args(_Args&& ...) [with _Context =
basic_format_context<__format::_Sink_iter, char>; _Args =
{spdlog::details::dump_info<__gnu_cxx::__normal_iterator > > >}]'
C:/gcc1301/x86_64-w64-mingw32/include/spdlog/logger.h:372

[Bug other/109599] Query for merging files in ar.exe

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

--- Comment #3 from Jamaika  ---
I'm not referring to the GCC 11.3.1 comment itself. I meant why the .a file
automatically adds and compiles c files from the avx2 and sse2 directories that
I have not added.
I was surprised that ar.exe is not a gcc product. Who is the creator?

[Bug c/109599] New: Query for merging files in ar.exe

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

Bug ID: 109599
   Summary: Query for merging files in ar.exe
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukaszcz18 at wp dot pl
  Target Milestone: ---

Created attachment 54907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54907=edit
Added file object

I don't know how to get around the problem.
I add commands to ar.exe. GCC: (GNU) 13.0.1 20230421 (prerelease)
http://msystem.waw.pl/x265/mingw-gcc1301-20230421.7z
Codec directories
libxeve
libxeve/avx2
libxeve/sse2

cd libavcodec/libxeve
ar.exe rcs "../../lib/libxeve_x64.a" xeve_bsw.o xeve_df.o xeve_eco.o xeve_enc.o
xeve_fcst.o xeve_ipred.o xeve_itdq.o xeve_mc.o xeve_mode.o xeve_param_parse.o
xeve_picman.o xeve_pinter.o xeve_pintra.o xeve_port.o xeve_rc.o xeve_recon.o
xeve_sad.o xeve_tbl.o xeve_thread_pool.o xeve_tq.o xeve_util.o xevem.o
xevem_alf.o xevem_df.o xevem_dra.o xevem_eco.o xevem_ibc_hash.o xevem_ipred.o
xevem_itdq.o xevem_mc.o xevem_mode.o xevem_pibc.o xevem_picman.o xevem_pinter.o
xevem_pintra.o xevem_recon.o xevem_stat.o xevem_tbl.o xevem_tq.o xevem_util.o
cd ../..

The generated .a file contains GCC: (GNU) 11.3.1 20221227 in addition to the
sse2/avx2 files. Where did it come from and how do I get rid of it.

[Bug target/109324] Genrecog reports "source missing a mode?" for H8

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #2 from Jan Dubiec  ---
It seems that msp430-elf has similar problem:

build/genrecog.exe ../../../gcc/gcc/common.md
../../../gcc/gcc/config/msp430/msp430.md \
  insn-conditions.md > tmp-recog.cc
../../../gcc/gcc/config/msp430/msp430.md:204:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/msp430/msp430.md:241:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/msp430/msp430.md:453:1: warning: operand 2 missing
mode?
../../../gcc/gcc/config/msp430/msp430.md:1224:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/msp430/msp430.md:1241:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/msp430/msp430.md:1294:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/msp430/msp430.md:1602:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/msp430/msp430.md:1612:1: warning: operand 0 missing
mode?
Statistics for recog:
  Number of decisions:629
  longest path:32 (code:  2)
  longest backtrack:4 (code: 66)
Statistics for split_insns:
  Number of decisions: 15
  longest path:10 (code:  1)
  longest backtrack:1 (code:  2)
Statistics for peephole2_insns:
  Number of decisions: 13
  longest path:13 (code:  1)
  longest backtrack:0 (code:  1)
Shared 363 out of 1138 states by creating 118 new states, saving 245

[Bug target/109324] New: Genrecog reports "source missing a mode?" for H8

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109324
   Summary: Genrecog reports "source missing a mode?" for H8
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
Target: h8300-elf

Unfortunately, I barely understand .md files, but I think genrecog is a bit
overzealous. It would be nice if these warnings could be muted somehow.


build/genrecog.exe ../../../gcc/gcc/common.md
../../../gcc/gcc/config/h8300/h8300.md \
  insn-conditions.md > tmp-recog.cc
../../../gcc/gcc/config/h8300/testcompare.md:29:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:29:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:55:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:64:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:73:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:82:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:82:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:82:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:98:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:106:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:114:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:122:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:130:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:151:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:290:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:290:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:327:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:327:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:360:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:360:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:397:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:397:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/testcompare.md:175:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:175:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:175:1: warning: source missing a
mode?
Statistics for recog:
  Number of decisions:   3643
  longest path:76 (code:597)
  longest backtrack:9 (code:428)
Statistics for split_insns:
  Number of decisions:   1409
  longest path:58 (code:242)
  longest backtrack:4 (code:199)
Statistics for peephole2_insns:
  Number of decisions:119
  longest path:69 (code:  8)
  longest backtrack:3 (code: 10)
Shared 3609 out of 7559 states by creating 1052 new states, saving 2557

[Bug other/109293] [12 Regression] Missing memmem() prototype in fixincludes/fixfixes.c on Windows/MinGW-W64

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #9 from Jan Dubiec  ---
I can confirm that now everything is fine on this issue on Windows/MingW.

[Bug other/109293] New: Missing memmem() prototype in fixincludes/fixfixes.c on Windows/MinGW-W64

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109293
   Summary: Missing memmem() prototype in fixincludes/fixfixes.c
on Windows/MinGW-W64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32

Created attachment 54763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54763=edit
Proposed patch

gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wno-overlength-strings -pedantic -Wno-long-long   -DHAVE_CONFIG_H -I.
-I../../../gcc/fixincludes -I../include -I../../../gcc/fixincludes/../include
../../../gcc/fixincludes/fixfixes.c
../../../gcc/fixincludes/fixfixes.c: In function 'check_has_inc':
../../../gcc/fixincludes/fixfixes.c:490:12: warning: implicit declaration of
function 'memmem'; did you mean 'memset'? [-Wimplicit-function-declaration]
  490 |   for (p = memmem (begin, pos - begin, has_inc, has_inc_len);
  |^~
  |memset
../../../gcc/fixincludes/fixfixes.c:490:10: warning: assignment to 'const char
*' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  490 |   for (p = memmem (begin, pos - begin, has_inc, has_inc_len);
  |  ^
../../../gcc/fixincludes/fixfixes.c:492:10: warning: assignment to 'const char
*' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  492 |p = memmem (p, pos - p, has_inc, has_inc_len))
  |  ^

[Bug libgcc/109289] New: Conflicting types for built-in functions in libgcc/emutls.c

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109289
   Summary: Conflicting types for built-in functions in
libgcc/emutls.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---

Created attachment 54759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54759=edit
Proposed patch

For different hosts (Windows/MSYS2, Linux), different targets and for every
libgcc variant, the following messages are reported:

/d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include   
-isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2  -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -DDF=SF -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc -DDF=SF -I. -I. -I../../.././gcc
-I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/.
-I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include
-o emutls.o -MT emutls.o -MD -MP -MF emutls.dep -fexceptions -c
../../../../../gcc/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS
d:\works\gcc\libgcc\emutls.c:61:7: warning: conflicting types for built-in
function '__emutls_get_address'; expected 'void *(void *)'
[-Wbuiltin-declaration-mismatch]
   61 | void *__emutls_get_address (struct __emutls_object *);
  |   ^~~~
d:\works\gcc\libgcc\emutls.c:63:6: warning: conflicting types for built-in
function '__emutls_register_common'; expected 'void(void *, long unsigned int, 
long unsigned int,  void *)' [-Wbuiltin-declaration-mismatch]
   63 | void __emutls_register_common (struct __emutls_object *, word, word,
void *);
  |  ^~~~
d:\works\gcc\libgcc\emutls.c:140:1: warning: conflicting types for built-in
function '__emutls_get_address'; expected 'void *(void *)'
[-Wbuiltin-declaration-mismatch]
  140 | __emutls_get_address (struct __emutls_object *obj)
  | ^~~~
d:\works\gcc\libgcc\emutls.c:204:1: warning: conflicting types for built-in
function '__emutls_register_common'; expected 'void(void *, long unsigned int, 
long unsigned int,  void *)' [-Wbuiltin-declaration-mismatch]
  204 | __emutls_register_common (struct __emutls_object *obj,
  | ^~~~


Judging by the comment on line 138 the problem is known and acceptable,
therefore IMO it would be nice to mute the warnings by wrapping
declarations/definitions of these functions with "#pragma GCC diagnostic" e.g.
as shown in the attached patch.

[Bug libgcc/109286] Assembler warnings about .init/.fini sections defined without attributes

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #2 from Jan Dubiec  ---
$ h8300-elf-as --version
GNU assembler (GNU Toolchain for Renesas H8 Family [Built by jdx]) 2.40
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `h8300-elf'.

[Bug libgcc/109286] Assembler warnings about .init/.fini sections defined without attributes

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #1 from Jan Dubiec  ---
Created attachment 54758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54758=edit
crtend.S

[Bug libgcc/109286] New: Assembler warnings about .init/.fini sections defined without attributes

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109286
   Summary: Assembler warnings about .init/.fini sections defined
without attributes
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: inline-asm, internal-improvement
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: h8300-elf

Created attachment 54757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54757=edit
crtbegin.S

For every possible libgcc variant (H8/300H, H8S, etc) I get following warnings:

/d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include   
-isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc
-I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc
-I../../../../../gcc/libgcc/../include   -g0  -finhibit-size-directive
-fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
-fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector  -Dinhibit_libc  -I.
-I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/.
-I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include  -o
crtbegin.o -MT crtbegin.o -MD -MP -MF crtbegin.dep  -c
../../../../../gcc/libgcc/crtstuff.c -DCRT_BEGIN
R:\Users\jdx\AppData\Local\Temp\ccvtc9ju.s: Assembler messages:
R:\Users\jdx\AppData\Local\Temp\ccvtc9ju.s:101: Warning: new section '.fini'
defined without attributes - this might cause problems
R:\Users\jdx\AppData\Local\Temp\ccvtc9ju.s:124: Warning: new section '.init'
defined without attributes - this might cause problems
/d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include   
-isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc
-I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc
-I../../../../../gcc/libgcc/../include   -g0  -finhibit-size-directive
-fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
-fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector  -Dinhibit_libc  -I.
-I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/.
-I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include  -o
crtend.o -MT crtend.o -MD -MP -MF crtend.dep  -c
../../../../../gcc/libgcc/crtstuff.c -DCRT_END
R:\Users\jdx\AppData\Local\Temp\ccbb20TH.s: Assembler messages:
R:\Users\jdx\AppData\Local\Temp\ccbb20TH.s:48: Warning: new section '.init'
defined without attributes - this might cause problems

In the attachement there are crtbegin.S and crtend.S created "manually" with 

/d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include   
-isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc
-I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc
-I../../../../../gcc/libgcc/../include   -g0  -finhibit-size-directive
-fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
-fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector  -Dinhibit_libc  -I.
-I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/.
-I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include  -S
-o crtbegin.S -MT crtbegin.o -MD -MP -MF crtbegin.dep
../../../../../gcc/libgcc/crtstuff.c -DCRT_BEGIN

and

/d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include   
-isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem
/d/Works/xcomp/sysr

[Bug libgcc/109285] New: Unused variable in function __fixunssfdi

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109285
   Summary: Unused variable in function __fixunssfdi
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: h8300-elf

Created attachment 54756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54756=edit
Proposed patch

I get the following warning when I build master (but it also applies to 12.2):

[...]
/d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/
-B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem
/usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include   
-isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2  -isystem
/d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -DDF=SF -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc -DDF=SF -I. -I. -I../../.././gcc
-I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/.
-I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include
-o _fixunssfdi.o -MT _fixunssfdi.o -MD -MP -MF _fixunssfdi.dep -DL_fixunssfdi
-c ../../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
d:\works\gcc\libgcc\libgcc2.c: In function '__fixunssfdi':
d:\works\gcc\libgcc\libgcc2.c:1459:14: warning: unused variable 'msb'
[-Wunused-variable]
 1459 |   SFtype msb;
  |  ^~~

Re: [Freedos-user] DOS and PDFs (Was Re: Update wiki info on installing ftp on a virualbox guest?

[Hollowone PL]

There is Acrobat Reader 1.0 for MSDOS but it does not support modern PDF
format. I'm sure it has evolved so much that none of the current PDFs work
with it anyway.
It's available though on winworldpc for download and check.

If that doesn't work then I assume porting some open source to DOS is the
only option to get legitimate MS DOS support for the format with this or
that rendering option (VESA/SVGA based I assume)

-h1

On Thu, Mar 16, 2023 at 5:14 PM Michael Brutman 
wrote:

> I think it is pretty safe to assume that everybody using FreeDOS in the
> last 10 to 20 years has access to another, more capable device that can
> read PDFs.  Even low end cell phones have had this capability for the past
> 5 years.
>
> I started with pure TXT files, composed on the same DOS machine that I did
> my coding and testing on.  But even in 2013 those files were adding up to
> more than 210K across 16 files.  Just like I migrated from using a hardware
> 80386 to a cross compiler for the code in 2011, I migrated the documented
> for PDF in 2015.  The PDF format lets me do far better formatting and
> screen shots, which are useful for clear documentation.
>
> As cool as it would be to have everything self contained and self hosted
> within DOS, that's not our reality.  I think it's more important to use the
> appropriate tools for the job, PDF is very good for documentation - just
> not on DOS.  Given that everybody probably has access to something that can
> read PDFs, there is not much of a reason to downgrade carefully written and
> formatted documentation.
>
> I am concerned about these kinds of things because I do put a lot of
> energy into ensuring my work is properly packaged.  It's probably possible
> to export the PDF has HTML, but again I'd want to do that myself to ensure
> the formatting stays reasonable.  (And even then, the generated HTML is not
> going to be usable on the 16 bit machines with CGA that I target.)
>
>
> -Mike
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #13 from Jan Dubiec  ---
I have applied the patch posted yesterday on PR108865 and everything seems to
be fine.

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #12 from Jan Dubiec  ---
Yes, there is such a snippet in gcc/Makefile.in but I have completely no idea
what you mean.

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #10 from Jan Dubiec  ---
(In reply to Andrew Pinski from comment #9)
> Can you change $(COMPILERS) to cc1 in gcc/config/i386/x-mingw32-utf8 and see
> if that helps?
I have changed it and I can confirm that genmodes.exe has been successfully
built. However, the compilation is still in progress so I am not able to tell
what the result of the whole process is.

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #8 from Jan Dubiec  ---
Output of another important command:
$ uname -a
MINGW64_NT-10.0-19045 jdxpc 3.4.6.x86_64 2023-02-15 18:03 UTC x86_64 Msys

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #7 from Jan Dubiec  ---
Make version is 4.4.1 as comment #2 shows. Usually I call make from my bash
build script using "make 2>&1 | tee buildlog-gcc.txt", but I tried to build
native compiler by simply calling "make" from the bash command line. The "env"
output is as follows:

$ env
!D:=D:\
ProgramFiles(x86)=C:\Program Files (x86)
!::=::\
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
!C:=C:\Tools\MSYS
SHELL=/usr/bin/bash
NUMBER_OF_PROCESSORS=8
FPS_BROWSER_USER_PROFILE_STRING=Default
PROCESSOR_LEVEL=6
WD=C:\Tools\MSYS\usr\bin\
TERM_PROGRAM_VERSION=3.6.3
MINGW_PREFIX=/mingw64
PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig
USERDOMAIN_ROAMINGPROFILE=JDXPC
HOSTNAME=jdxpc
PROGRAMFILES=C:\Program Files
MSYSTEM=MINGW64
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
ORIGINAL_TEMP=/r/Users/jdx/AppData/Local/Temp
MINGW_CHOST=x86_64-w64-mingw32
OS=Windows_NT
HOMEDRIVE=D:
MSYSTEM_CARCH=x86_64
USERDOMAIN=JDXPC
PWD=/d/works/xcomp/gcc-build
USERPROFILE=D:\Users\jdx
MANPATH=/mingw64/local/man:/mingw64/share/man:/usr/local/man:/usr/share/man:/usr/man:/share/man
PRINTER=Microsoft Print to PDF
TZ=Europe/Warsaw
MINGW_PACKAGE_PREFIX=mingw-w64-x86_64
tmp=R:\Users\jdx\AppData\Local\Temp
ALLUSERSPROFILE=C:\ProgramData
ORIGINAL_PATH=/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/
CommonProgramW6432=C:\Program Files\Common Files
HOME=/home/jdx
USERNAME=jdx
VBOX_MSI_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\
OneDrive=D:\Users\jdx\OneDrive
COMSPEC=C:\Windows\system32\cmd.exe
APPDATA=D:\Users\jdx\AppData\Roaming
SYSTEMROOT=C:\Windows
LOCALAPPDATA=D:\Users\jdx\AppData\Local
PROMPT=$P$G
COMPUTERNAME=JDXPC
INFOPATH=/usr/local/info:/usr/share/info:/usr/info:/share/info
TERM=xterm
LOGONSERVER=\\JDXPC
ACLOCAL_PATH=/mingw64/share/aclocal:/usr/share/aclocal
USER=jdx
PSModulePath=C:\Program
Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules
TEMP=/r/Users/jdx/AppData/Local/Temp
temp=R:\Users\jdx\AppData\Local\Temp
MSYSTEM_CHOST=x86_64-w64-mingw32
ORIGINAL_TMP=/r/Users/jdx/AppData/Local/Temp
SHLVL=1
PROCESSOR_REVISION=3a09
DriverData=C:\Windows\System32\Drivers\DriverData
COMMONPROGRAMFILES=C:\Program Files\Common Files
CONICON=mingw64.ico
LC_CTYPE=en_US.UTF-8
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
SESSIONNAME=Console
PS1=\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[35m\]$MSYSTEM\[\e[0m\]
\[\e[33m\]\w\[\e[0m\]\n\$
PKG_CONFIG_SYSTEM_LIBRARY_PATH=/mingw64/lib
HOMEPATH=\Users\jdx
XDG_DATA_DIRS=/mingw64/share/:/usr/local/share/:/usr/share/
MSYSCON=mintty.exe
TMP=/r/Users/jdx/AppData/Local/Temp
CONFIG_SITE=/etc/config.site
PATH=/mingw64/bin:/mingw64/bin/site_perl/5.32.1:/mingw64/bin/vendor_perl:/mingw64/bin/core_perl:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/
ProgramW6432=C:\Program Files
MSYSTEM_PREFIX=/mingw64
LOGINSHELL=bash
CONTITLE=MinGW x64
WINDIR=C:\Windows
FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer
PROCESSOR_ARCHITECTURE=AMD64
PUBLIC=D:\Users\Public
PKG_CONFIG_SYSTEM_INCLUDE_PATH=/mingw64/include
SYSTEMDRIVE=C:
OLDPWD=/d/works/xcomp
TERM_PROGRAM=mintty
ProgramData=C:\ProgramData
_=/usr/bin/env

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #5 from Jan Dubiec  ---
I forgot to mention it in the first message – at least h8300-elf and mips-elf
are also affected. I have just even tried to build native compiler and,
strangely, it has the same issue.

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #3 from Jan Dubiec  ---
I have just finished painful "git bisect" and found the offending commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d11e088210a551235d3937f867ee1c8b19d02290.
However I do not know where the bug is.

[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #5 from Jan Dubiec  ---
I read that thread a few days ago and I understand concerns regarding SWP, in
particular on ARMv6 which has made SWP obsolete (AFAIR it is optional on
ARMv6-A/R, ARMv6-M has neither SWP nor LDREX/STREX). However I have never heard
of an ARMv4T based MCU which does not have SWP. So I do not understand why gcc
targeting various "bare metal" ARMs for ARMv4T a) emits non-atomic
__atomic_test_and_set, b) does not use SWP in that code. Especially that the
code attached to the linked message for ARMv4T uses SWP.

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #2 from Jan Dubiec  ---
jdx@jdxpc MINGW64 /d/works/xcomp
$ make --version
GNU Make 4.4.1
Built for x86_64-pc-msys
Copyright (C) 1988-2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug other/109189] Format string warnings in gcc/config/h8300/h8300.cc under MigW-W64/MSYS2

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #1 from Jan Dubiec  ---
BTW, it would be nice if someone experienced could inspect lines 1547–1553,
1572–1578 and 1751–1757 in that file. These ranges contain code which looks
like this:

case CONST_DOUBLE:
  {
long val;
REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), val);
fprintf (file, "#%ld", ((val >> 16) & 0x));
break;
  }

They seem kinda suspicious to me.

[Bug other/109189] New: Format string warnings in gcc/config/h8300/h8300.cc under MigW-W64/MSYS2

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109189
   Summary: Format string warnings in gcc/config/h8300/h8300.cc
under MigW-W64/MSYS2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: h8300-elf

Created attachment 54704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54704=edit
Proposed patch

I get the following messages when I build different gcc versions (12.2, master)
for H8/300:

[...]
g++  -fno-PIE -c   -g -O2 -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I../../../gcc/gcc/../libcody 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   -o h8300.o -MT h8300.o
-MMD -MP -MF ./.deps/h8300.TPo ../../../gcc/gcc/config/h8300/h8300.cc
../../../gcc/gcc/config/h8300/h8300.cc: In function 'void
h8300_print_operand(FILE*, rtx, int)':
../../../gcc/gcc/config/h8300/h8300.cc:1447:26: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1447 |   fprintf (file, "#%ld", (-INTVAL (x)) & 0xff);
  |  ^~  
  ||
  |long long int
../../../gcc/gcc/config/h8300/h8300.cc:1460:26: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1460 |   fprintf (file, "#%ld", ((-INTVAL (x)) & 0xff00) >> 8);
  |  ^~  ~
  |   |
  |   long long int
../../../gcc/gcc/config/h8300/h8300.cc:1468:22: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1468 |   fprintf (file, "#%ld", 0xff & (-INTVAL (x)));
  |  ^~  
  |   |
  |   long long int
../../../gcc/gcc/config/h8300/h8300.cc:1545:26: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1545 |   fprintf (file, "#%ld", ((INTVAL (x) >> 16) & 0x));
  |  ^~  ~
  |  |
  |  long long int
../../../gcc/gcc/config/h8300/h8300.cc:1570:26: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1570 |   fprintf (file, "#%ld", INTVAL (x) & 0x);
  |  ^~
../../../gcc/gcc/config/h8300/h8300.cc:1624:24: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1624 | fprintf (file, "#%ld", (INTVAL (x)) & 0xff);
  |^~  ~~~
  | |
  | long long int
../../../gcc/gcc/config/h8300/h8300.cc:1632:24: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1632 | fprintf (file, "#%ld", (INTVAL (x) >> 8) & 0xff);
  |^~  
  |  |
  |  long long int
../../../gcc/gcc/config/h8300/h8300.cc:1640:24: warning: format '%ld' expects
argument of type 'long int', but argument 3 has type 'long long int'
[-Wformat=]
 1640 | fprintf (file, "#%ld", INTVAL (x) & 0xff);
  |^~
../../../gcc/gcc/config/h8300/h8300.cc:1648:24: warning: format '%ld' expects
argument of

[Bug c/109188] New: Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109188
   Summary: Building genmodes under MinGW-W64/MSYS2 fails due to
undefined HOST_EXTRA_OBJS_SYMBOL
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: arm-eabi

I get the following error message when I try to build master (33fb1625):

make[2]: Entering directory '/d/works/xcomp/gcc-build/gcc'
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="" \
/bin/sh ../../../gcc/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="\"arm7tdmi\"" \
HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/elfos.h
config/arm/unknown-elf.h config/arm/elf.h config/arm/bpabi.h
config/newlib-stdint.h config/arm/aout.h config/arm/arm.h
config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2
LIBC_BIONIC=3 LIBC_MUSL=4" \
/bin/sh ../../../gcc/gcc/mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/arm/arm-flags.h config/arm/arm-protos.h
config/arm/aarch-common-protos.h tm-preds.h" DEFINES="" \
/bin/sh ../../../gcc/gcc/mkconfig.sh tm_p.h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="" \
/bin/sh ../../../gcc/gcc/mkconfig.sh bconfig.h
g++ -c   -g -O2 -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H 
-DGENERATOR_FILE -I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/genmodes.o ../../../gcc/gcc/genmodes.cc
g++ -c   -g -O2 -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H 
-DGENERATOR_FILE -I. -Ibuild -I../../../gcc/gcc -I../../../gcc/gcc/build
-I../../../gcc/gcc/../include  -I../../../gcc/gcc/../libcpp/include  \
-o build/errors.o ../../../gcc/gcc/errors.cc
../../../gcc/gcc/errors.cc: In function 'void warning(const char*, ...)':
../../../gcc/gcc/errors.cc:50:12: warning: function 'void warning(const char*,
...)' might be a candidate for 'gnu_printf' format attribute
[-Wsuggest-attribute=format]
   50 |   vfprintf (stderr, format, ap);
  |   ~^~~~
../../../gcc/gcc/errors.cc: In function 'void error(const char*, ...)':
../../../gcc/gcc/errors.cc:65:12: warning: function 'void error(const char*,
...)' might be a candidate for 'gnu_printf' format attribute
[-Wsuggest-attribute=format]
   65 |   vfprintf (stderr, format, ap);
  |   ~^~~~
../../../gcc/gcc/errors.cc: In function 'void fatal(const char*, ...)':
../../../gcc/gcc/errors.cc:82:12: warning: function 'void fatal(const char*,
...)' might be a candidate for 'gnu_printf' format attribute
[-Wsuggest-attribute=format]
   82 |   vfprintf (stderr, format, ap);
  |   ~^~~~
../../../gcc/gcc/errors.cc: In function 'void internal_error(const char*,
...)':
../../../gcc/gcc/errors.cc:97:12: warning: function 'void internal_error(const
char*, ...)' might be a candidate for 'gnu_printf' format attribute
[-Wsuggest-attribute=format]
   97 |   vfprintf (stderr, format, ap);
  |   ~^~~~
g++   -g -O2 -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H  -DGENERATOR_FILE -static-libstdc++
-static-libgcc -Wl,--stack,12582912
-Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL -o build/genmodes.exe \
build/genmodes.o build/errors.o
../build-x86_64-w64-mingw32/libiberty/libiberty.a
C:/Tools/MSYS/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
required symbol `HOST_EXTRA_OBJS_SYMBOL' not defined
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile:3042: build/genmodes.exe] Error 1
make[2]: Leaving directory '/d/works/xcomp/gcc-build/gcc'
make[1]: *** [Makefile:4613: all-gcc] Error 2
make[1]: Leaving directory '/d/works/xcomp/gcc-build'
make: **

[Bug target/109166] Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #3 from Jan Dubiec  ---
I do not get what "but that requires more" means in this context.

Lets assume that two threads test and set the same memory location which
initial value is 0 ("unlocked"/"false"). Now, when the first thread gets
preempted (a timer interrupt is requested) just after LDRB (i.e.
__atomic_test_and_set will return 0) and it happens that the second thread gets
its time slot, then it may happen that __atomic_test_and_set called by the
second thread also will return 0 and bam! – both threads will have "exclusive"
access to a shared resource. See get_lock() from sample libatomic as a typical
example of TAS usage:
https://gcc.gnu.org/wiki/Atomic/GCCMM?action=AttachFile=view=libatomic.c.

Re: błąd "signature verification failed" podczas instalacji pakietów

[Arkadiusz Miśkiewicz via pld-devel-pl]

On 17.03.2023 10:41, Adam Osuchowski wrote:

Arkadiusz Miśkiewicz via pld-devel-pl wrote:

Zrobione w main.


Dzięki wielkie, jest zdecydowanie lepiej.

Przy okazji jeszcze pytanie, czy można by było zmienić klucze PGP do
podpisywania paczek na bardziej współczesne? Obecne są sprzed 15 lat
i mają trochę stare parametry (1024-bitowe DSA i RSA). Poza tym, klucz
RSA chyba w ogóle nie jest używany, bo z tego co widzę, to chyba
wszystkie paczki są podpisane kluczem DSA.


Można. Kwestia tylko małego zaplanowania co gdzie pozmieniać 
(infrastruktura, paczki z tym kluczem, strona www),
procedura przejścia itd. Przetestować czy się rpmowi/poldkowi będzie 
podobało.


Jak chcesz się tym zająć to śmiało.

--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug target/109166] New: Built-in __atomic_test_and_set does not seem to be atomic on ARMv4T

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109166
   Summary: Built-in  __atomic_test_and_set does not seem to be
atomic on ARMv4T
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: arm-eabi

For the following source code:

bool tas(unsigned char *ptr)
{
return __atomic_test_and_set(ptr, __ATOMIC_SEQ_CST);
}

gcc -march=armv4t -marm -O3 -Wall -Wextra gives:

tas:
mov r3, r0
mov r2, #1
ldrbr0, [r0]@ zero_extendqisi2
strbr2, [r3]
bx  lr

I am not an ARM assembler expert, but I think that LDRB/STRB pair should be
replaced with SWPB as shown here: https://godbolt.org/z/116MbYK79.

See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567.

Re: błąd "signature verification failed" podczas instalacji pakietów

[Arkadiusz Miśkiewicz via pld-devel-pl]

On 12.03.2023 20:20, Adam Osuchowski wrote:


Można liczyć na przeprowadzenie takiej masowej operacji w repozytorium?


Zrobione w main.

--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug c/16186] gcc should have an option to warn about enumerations with duplicate values

[trashyankes at wp dot pl via Gcc-bugs]

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

trashyankes at wp dot pl changed:

   What|Removed |Added

 CC||trashyankes at wp dot pl

--- Comment #7 from trashyankes at wp dot pl ---
Should be way to disable/enable this warning per `enum`?
Like:

```
enum [[gnu::enum_unique]] X
{
  I = 1,
  J = 2,
};

enum [[gnu::enum_not_unique]] Y
{
  K = 1,
  L = 1,
};

```

Re: 2 problemy po ostatniej "dużej" aktualizacji

[Arkadiusz Miśkiewicz via pld-devel-pl]

On 9.03.2023 12:51, Maciej Kędzierski wrote:

Witam.

Po ostatniej większej aktualizacji zauważyłem 2 problemy.

Po zmianie shadow-4.8.1-2 na shadow-4.12.3-3 data zmiany hasła nie 
wyświetla się poprawnie.


Zepsuli w 4.12. 4.13 to poprawia.



# chage -l username
Last password change    : %b %d, %Y


Drugie, ważniejsze dla mnie i chyba związane z biblioteką libxcrypt 
(choć mogę się mylić).
System wymusza natychmiastową zmianę hasła jeśli hasło jest wygenerowane 
funkcjami skrótu, słabszymi niż SHA-512.


Wyłączone w pam 1.4.0-9+.

--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: błąd "signature verification failed" podczas instalacji pakietów

[Arkadiusz Miśkiewicz via pld-devel-pl]

On 5.03.2023 18:46, Adam Osuchowski wrote:

Od jakiegoś czasu nie da się zainstalować starych pakietów z repozytorium
(tj. takich zbudowanych 2-3 lata temu albo dawniej). Problem dotyczy wielu
różnych pakietów, ale ich wspólną cechą chyba jest właśnie wiek. Poldek
krzyczy, że "signature verification failed", ale co ciekawe, pozwala pobrać
taką paczkę.


Jako brzydki workaround spróbuj odinstalować nasz klucz gpg, bodaj:

rpm -q gpg-pubkey
rpm --erase --allmatches  gpg-pubkey-xyz

--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Bug gold/30171] Building gold fails under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=30171

--- Comment #4 from Jan Dubiec  ---
Created attachment 14734
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14734=edit
Preferred patch

This is my preferred patch. It uses load-time dynamic linking instead of
run-time dynamic linking, i.e. UuidCreate() is called directly. As a result,
built binaries will not run on some ancient versions of Windows.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gold/30171] Building gold fails under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=30171

--- Comment #3 from Jan Dubiec  ---
Created attachment 14733
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14733=edit
Proposed patch (Yoda style)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gold/30171] Building gold fails under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=30171

--- Comment #2 from Jan Dubiec  ---
Created attachment 14732
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14732=edit
Proposed patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libstdc++/109022] New: Low performance of std::map constructor for already sorted data of std::pair

[marekr22 at wp dot pl via Gcc-bugs]

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

Bug ID: 109022
   Summary: Low performance of std::map constructor for already
sorted data of std::pair
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marekr22 at wp dot pl
  Target Milestone: ---

Performance of constructor accepting iterators to sorted data of
std::pair is much lower then inserting same data for
std::pair (matches value_type of std::map).

Here is benchmark showing the issue:
```
#include 
#include 
#include 
#include 
#include 

constexpr size_t DataSizeStart = 8 << 0;
constexpr size_t DataSizeStop = 8 << 3;

using TestData = std::vector>;
using TestDataConst = std::vector>;

std::string makeStringFor(size_t x)
{
  std::ostringstream out;
  out << std::setfill('0') << std::setw(6) << x;
  return out.str();
}

TestData sortedData(size_t n)
{
  TestData r;
  r.reserve(n);
  size_t i = 0;
  std::generate_n(std::back_inserter(r), n, []() {
return std::pair{makeStringFor(++i), i};
  });
  return r;
}

TestData shuffledData(size_t n)
{
  auto data = sortedData(n);
  std::random_device rd;
  std::mt19937 g(rd());

  std::shuffle(data.begin(), data.end(), g);
  return data;
}

TestDataConst sortedConstData(size_t n)
{
  auto r = sortedData(n);
  return {r.begin(), r.end()};
}

TestDataConst shuffledConstData(size_t n)
{
  auto r = shuffledData(n);
  return {r.begin(), r.end()};
}

template
static void CreateMapInsert(benchmark::State& state) {
  auto n = state.range(0);
  auto data = Data(n);
  for (auto _ : state) {
benchmark::DoNotOptimize(data);
std::map m;

for (auto& p : data) {
  m.insert(m.end(), p);
}
benchmark::DoNotOptimize(m);
  }
}
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);

template
static void CreateMapDirectly(benchmark::State& state) {
  auto n = state.range(0);
  auto data = Data(n);
  for (auto _ : state) {
benchmark::DoNotOptimize(data);
std::map m{data.begin(), data.end()};
benchmark::DoNotOptimize(m);
  }
}
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
```

Live demo gcc 12.2: https://quick-bench.com/q/H8lqugNgMG-sWQ6cKBsdB7EBRpU
Note that CreateMapInsert performs best since it feeds to
constructos to iterators to std::pair while
CreateMapInsert performs badly (looks like time complexity is
worse) adn only diffrence is that it provides iterators to std::.

Same issue is observed for clang 14.0 and libstdc++:
https://quick-bench.com/q/6VA3vRdKmqPEYrvTnFFla4gxwXk
but it is not a problem on clang 14.0 and libc++:
https://quick-bench.com/q/-S-lX3N8Y-8vL9CCl-5bW5jolWA

here is result for sing size input data (easier to read):
https://quick-bench.com/q/kbDOPA8PNZFfrzUH_-70cJgApeE

Issue was observed when filing answer on
https://stackoverflow.com/a/75535056/1387438

[Bug gold/30170] Building gold fails on MinGW-W64/MSYS2 on indows 10

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=30170

Jan Dubiec   changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jan Dubiec   ---
Partially filed report.

*** This bug has been marked as a duplicate of bug 30171 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gold/30171] Building gold fails under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=30171

--- Comment #1 from Jan Dubiec   ---
*** Bug 30170 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gold/30171] New: Building gold fails under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=30171

Bug ID: 30171
   Summary: Building gold fails under MinGW-W64/MSYS2 on Windows
10
   Product: binutils
   Version: 2.41 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: jdx at o2 dot pl
CC: ian at airs dot com
  Target Milestone: ---
  Host: x86_64-w64-mingw32

I got the following error when I tried to build master (95ebc6fd):

make[4]: Entering directory '/d/Works/xcomp/binutils-build/gold'
  CXX  archive.o
  CXX  attributes.o
  CXX  binary.o
  CXX  common.o
  CXX  compressed_output.o
  CXX  copy-relocs.o
  CXX  cref.o
  CXX  defstd.o
  CXX  descriptors.o
  CXX  dirsearch.o
  CXX  dynobj.o
  CXX  dwarf_reader.o
  CXX  ehframe.o
  CXX  errors.o
  YACC yyscript.c
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:45.1-12:
warning: POSIX Yacc does not support %pure-parser [-Wyacc]
   45 | %pure-parser
  | ^~~~
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:45.1-12:
warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’
[-Wdeprecated]
   45 | %pure-parser
  | ^~~~
  | %define api.pure
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:52.1-14:
warning: POSIX Yacc does not support %error-verbose [-Wyacc]
   52 | %error-verbose
  | ^~
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:52.1-14:
warning: deprecated directive: ‘%error-verbose’, use ‘%define parse.error
verbose’ [-Wdeprecated]
   52 | %error-verbose
  | ^~
  | %define parse.error verbose
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: warning:
6 shift/reduce conflicts [-Wconflicts-sr]
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: warning:
1 reduce/reduce conflict [-Wconflicts-rr]
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: note:
rerun with option '-Wcounterexamples' to generate conflict counterexamples
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: warning:
fix-its can be applied.  Rerun with option '--update'. [-Wother]
updating yyscript.h
  CXX  expression.o
  CXX  fileread.o
  CXX  gc.o
  CXX  gdb-index.o
  CXX  gold.o
  CXX  gold-threads.o
  CXX  icf.o
  CXX  incremental.o
  CXX  int_encoding.o
  CXX  layout.o
../../../binutils/gold/layout.cc: In member function 'void
gold::Layout::create_build_id()':
../../../binutils/gold/layout.cc:3474:38: error: cast between incompatible
function types from 'FARPROC' {aka 'long long int (*)()'} to 'UuidCreateFn'
{aka 'long int (*)(GUID*)'} [-Werror=cast-function-type]
 3474 |   UuidCreateFn uuid_create = reinterpret_cast(
  |  ^~~
 3475 |   GetProcAddress(rpc_library, "UuidCreate"));
  |   ~~
cc1plus.exe: all warnings being treated as errors
make[4]: *** [Makefile:1144: layout.o] Error 1
make[4]: Leaving directory '/d/Works/xcomp/binutils-build/gold'
make[3]: *** [Makefile:1167: all-recursive] Error 1
make[3]: Leaving directory '/d/Works/xcomp/binutils-build/gold'
make[2]: *** [Makefile:907: all] Error 2
make[2]: Leaving directory '/d/Works/xcomp/binutils-build/gold'
make[1]: *** [Makefile:6898: all-gold] Error 2
make[1]: Leaving directory '/d/Works/xcomp/binutils-build'
make: *** [Makefile:1017: all] Error 2


Tested for arm-eabi and mips-elf. Binutils 2.40 is built without problems.

Configuration command:
../../binutils/configure --prefix=/ --target=arm-eabi --disable-nls
--enable-gold --enable-gprofng --enable-lto --disable-shared --enable-static
--disable-threads --with-system-zlib --with-pkgversion='GNU Toolchain for the
ARM Architecture [Built by jdx]'

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gold/30170] New: Building gold fails on MinGW-W64/MSYS2 on indows 10

[jdx at o2 dot pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=30170

Bug ID: 30170
   Summary: Building gold fails on MinGW-W64/MSYS2 on indows 10
   Product: binutils
   Version: 2.41 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: jdx at o2 dot pl
CC: ian at airs dot com
  Target Milestone: ---
  Host: x86_64-w64-mingw32

make[4]: Entering directory '/d/Works/xcomp/binutils-build/gold'
  CXX  archive.o
  CXX  attributes.o
  CXX  binary.o
  CXX  common.o
  CXX  compressed_output.o
  CXX  copy-relocs.o
  CXX  cref.o
  CXX  defstd.o
  CXX  descriptors.o
  CXX  dirsearch.o
  CXX  dynobj.o
  CXX  dwarf_reader.o
  CXX  ehframe.o
  CXX  errors.o
  YACC yyscript.c
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:45.1-12:
warning: POSIX Yacc does not support %pure-parser [-Wyacc]
   45 | %pure-parser
  | ^~~~
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:45.1-12:
warning: deprecated directive: ‘%pure-parser’, use ‘%define api.pure’
[-Wdeprecated]
   45 | %pure-parser
  | ^~~~
  | %define api.pure
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:52.1-14:
warning: POSIX Yacc does not support %error-verbose [-Wyacc]
   52 | %error-verbose
  | ^~
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y:52.1-14:
warning: deprecated directive: ‘%error-verbose’, use ‘%define parse.error
verbose’ [-Wdeprecated]
   52 | %error-verbose
  | ^~
  | %define parse.error verbose
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: warning:
6 shift/reduce conflicts [-Wconflicts-sr]
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: warning:
1 reduce/reduce conflict [-Wconflicts-rr]
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: note:
rerun with option '-Wcounterexamples' to generate conflict counterexamples
/d/Works/xcomp/binutils-build/gold/../../../binutils/gold/yyscript.y: warning:
fix-its can be applied.  Rerun with option '--update'. [-Wother]
updating yyscript.h
  CXX  expression.o
  CXX  fileread.o
  CXX  gc.o
  CXX  gdb-index.o
  CXX  gold.o
  CXX  gold-threads.o
  CXX  icf.o
  CXX  incremental.o
  CXX  int_encoding.o
  CXX  layout.o
../../../binutils/gold/layout.cc: In member function 'void
gold::Layout::create_build_id()':
../../../binutils/gold/layout.cc:3474:38: error: cast between incompatible
function types from 'FARPROC' {aka 'long long int (*)()'} to 'UuidCreateFn'
{aka 'long int (*)(GUID*)'} [-Werror=cast-function-type]
 3474 |   UuidCreateFn uuid_create = reinterpret_cast(
  |  ^~~
 3475 |   GetProcAddress(rpc_library, "UuidCreate"));
  |   ~~
cc1plus.exe: all warnings being treated as errors
make[4]: *** [Makefile:1144: layout.o] Error 1
make[4]: Leaving directory '/d/Works/xcomp/binutils-build/gold'
make[3]: *** [Makefile:1167: all-recursive] Error 1
make[3]: Leaving directory '/d/Works/xcomp/binutils-build/gold'
make[2]: *** [Makefile:907: all] Error 2
make[2]: Leaving directory '/d/Works/xcomp/binutils-build/gold'
make[1]: *** [Makefile:6898: all-gold] Error 2
make[1]: Leaving directory '/d/Works/xcomp/binutils-build'
make: *** [Makefile:1017: all] Error 2

-- 
You are receiving this mail because:
You are on the CC list for the bug.

PL/Haskell v2.0

[PL/Haskell via PostgreSQL Announce]

We are pleased to announce the release of version 2.0 of the [PL/Haskell 
extension](https://github.com/ed-o-saurus/PLHaskell/releases/2.0). This 
extension allows users to write PostgreSQL functions in the Haskell functional 
programming language. Instructions can be found 
[here](https://github.com/ed-o-saurus/PLHaskell/blob/main/README.md).

Version 2.0 adds the ability to execute queries from within PL/Haskell 
functions. In addition, the build and install procedures have been made simpler 
and more robust. 

Users of Ubuntu and Fedora can install the extension directly from the rpm and 
apt 
[repositories](https://github.com/ed-o-saurus/PLHaskell/blob/main/README.md#package-repositories).

If you have problems with the extension or a feature request, please submit a 
Github issue.

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

[pkubaj at anongoth dot pl via Gcc-bugs]

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

--- Comment #23 from Piotr Kubaj  ---
(In reply to Segher Boessenkool from comment #22)
> (In reply to Piotr Kubaj from comment #21)
> > I'm not sure whether it will help, but the issue only affects building
> > 32-bit multilib libraries on powerpc64. That is, building a full 32-bit gcc
> > for powerpc works just fine.
> 
> I can reproduce it with a simple testcase always.  It needs a
> powerpc64-freebsd
> compiler, built with all default options.  With -m32 it still uses the 64-bit
> processor, so equivalent to -mcpu=power4.  If you manually use -mcpu=7450 all
> works fine.

Wouldn't it be possible to just set -mcpu=7450 in the Makefile for multilib?

[Bug other/108662] Cast between incompatible function types in libiberty/physmem.c under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #1 from Jan Dubiec  ---
Created attachment 54410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54410=edit
Proposed patch

[Bug other/108662] New: Cast between incompatible function types in libiberty/physmem.c under MinGW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 108662
   Summary: Cast between incompatible function types in
libiberty/physmem.c under MinGW-W64/MSYS2 on Windows
10
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
  Host: x86_64-w64-mingw32
 Build: x86_64-w64-mingw32

The following warning appears when gcc is build under MinGW-W64/MSYS2:

gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../../gcc/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic
 -D_GNU_SOURCE  ../../../gcc/libiberty/physmem.c -o physmem.o
../../../gcc/libiberty/physmem.c: In function 'physmem_total':
../../../gcc/libiberty/physmem.c:161:18: warning: cast between incompatible
function types from 'FARPROC' {aka 'long long int (*)()'} to 'WINBOOL
(*)(lMEMORYSTATUSEX *)' {aka 'int (*)(lMEMORYSTATUSEX *)'}
[-Wcast-function-type]
  161 | if ((pfnex = (PFN_MS_EX) GetProcAddress (h,
"GlobalMemoryStatusEx")))
  |  ^
../../../gcc/libiberty/physmem.c: In function 'physmem_available':
../../../gcc/libiberty/physmem.c:262:18: warning: cast between incompatible
function types from 'FARPROC' {aka 'long long int (*)()'} to 'WINBOOL
(*)(lMEMORYSTATUSEX *)' {aka 'int (*)(lMEMORYSTATUSEX *)'}
[-Wcast-function-type]
  262 | if ((pfnex = (PFN_MS_EX) GetProcAddress (h,
"GlobalMemoryStatusEx")))
  |  ^


The offending code was added in 2003
(https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ed935c35314a6fe3b0c699bf642c704655873d49)
and has survived virtually without changes until this day. Perhaps 20 years
later it is time to clean the code – remove definitions of lMEMORYSTATUSEX and
PFN_MS_EX at the top, remove calls to GlobalMemoryStatus (which is pretty much
useless these days) and call GlobalMemoryStatusEx directly.

[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #7 from Jan Dubiec  ---
(In reply to Andrew Pinski from comment #6)
[...]
> as sizeof returns size_t.
> 
> Does that make sense now?
Yep, thanks.

[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #5 from Jan Dubiec  ---
Andrew, as per your wish, preprocessed lto-plugin\lto-plugin.c is in the
attachment. It was produced using the following command:

gcc -DHAVE_CONFIG_H -I. -I../../../gcc/lto-plugin
-I../../../gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall
-DBASE_VERSION=\"13.0.1\" -E -g3 -O2 ../../../gcc/lto-plugin/lto-plugin.c 
-DDLL_EXPORT -DPIC -o lto-plugin-preprocessed.c


Regarding gcc/ira-conflicts.cc, I think you are probably right, parentheses
should fix the issue. But I am not able to understand (without looking into
docs) how without the parentheses the expressions are promoted to unsigned long
long int instead of just long int. And why the warning does not appear on
Linux.

Regarding gcc/config/h8300/h8300.cc, I will file a separate report soon.

[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #4 from Jan Dubiec  ---
Created attachment 54406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54406=edit
Preprocessed lto-plugin\lto-plugin.c