Compiling and running a C language program with array pointers using "MinGW-w64 GCC 11.4.0 64-bit Release" results in an error output

AN drew — Tue, 03 Mar 2026 09:06:30 -0000

I saw a post in the C Language Bar, a sub-forum of Baidu Tieba (a Chinese forum)

https://tieba.baidu.com/p/10519222306

The C language program inside has no syntax errors, but there is a problem with the output

#include <stdio.h>
int main(void)
{
    int array[4][4]={{1,6,5,3},{2,4,7,9},{8,11,15,13},{16,12,10,22}};
    int (*p)[4]=array;
    for(int i=0; i<4; i++)
    {
        for(int j=0; j<4; j++)
        {
            printf("%4d", *(*(p+i)+j));
        }
        printf("\n");
    }
    return 0;
}

When compiling and running the program using "MinGW-w64 GCC 11.4.0 64-bit Debug", the normal output is without any issues. However, when switching to use "MinGW-w64 GCC 11.4.0 64-bit Release" for compiling and running the program, some error numbers are output

After my testing, it was found to be an issue with the gcc optimization options. The Debug version defaults to -O0 optimization, while the Release version defaults to -O2 optimization. Enabling high-level optimizations (such as -O2, -O3, -Ofast) will result in errors, whereas low-level optimizations (such as -O0, -O1, -Os, -Og) normal output

In addition, if you change `((p+i)+j)` to `p[i][j]`, both the Debug and Release versions will output normally without any errors

Why UTF8 is not working with MSYS2 Mingw64 UCRT compiler?

Pali — Sat, 13 Dec 2025 19:09:32 -0000

No, there is no way.

Mingw-w64 does not provide ucrt libraries, they are provided by microsoft. DLL version which microsoft provides for Windows 7 does not support UTF-8. Static libraries provided by microsoft works only with msvc compiler. microsoft does not provide static libraries for mingw-w64.

If you want unicode on older windows versions then you need to stick with UTF-16.

Problems with creating/using dll's

B.V. — Mon, 13 Oct 2025 07:08:19 -0000

Hello,
I'm encountering a problem with creating/using a dll built with MinGW-w64
for 64 bit Windows, and I hope somebody can help me.

A method that works is to place (within the .h file) in front of every
item exported from the dll the text __declspec(dllexport) when creating
the dll and __declspec(dllimport) when using the dll. Apart from that
one should use the following gcc call to generate the dll,

gcc -o<lib nm=""> *.o <-L and -l params> -shared -s -Wl,--subsystem,windows,--out-implib,lib<lib nm="">.a</lib></lib>

As mentioned above this method works; however the source

https://www.codeproject.com/articles/MinGW-Static-and-Dynamic-Libraries

claims that one can use a simpler scheme. A simple example given therein
is
rem create .o files for inclusion into dll gcc -c add.c -o add.o rem create dll (actually, .so) gcc -shared -o libadd.so add.o rem compile to use .so gcc -o main.exe main.c libadd.so
This simple example works; however when I try it with a larger
"real world" example I can generate the .so without error, but
when I compile an example that uses the .so file I always get
the error "collect2.exe: error: ld returned 1 exit status" without
any further explanation. Can anyone provide some more information
on this?

Regards,
beamerbv

Different function abs called after include cassert.h

Sving 1024 — Sat, 11 Oct 2025 15:52:08 -0000

I also tried using x86_64-w64-mingw32-g++ -S ./test.cpp on my archlinux and here's the output:

    .file   "test.cpp"
    .text
    .section    .text$_ZSt3absx,"x"
    .linkonce discard
    .globl  _ZSt3absx
    .def    _ZSt3absx;  .scl    2;  .type   32; .endef
    .seh_proc   _ZSt3absx
_ZSt3absx:
.LFB29:
    pushq   %rbp
    .seh_pushreg    %rbp
    movq    %rsp, %rbp
    .seh_setframe   %rbp, 0
    .seh_endprologue
    movq    %rcx, 16(%rbp)
    movq    16(%rbp), %rax
    movq    %rax, %rdx
    negq    %rdx
    cmovns  %rdx, %rax
    popq    %rbp
    ret
    .seh_endproc
    .text
    .globl  _Z1gx
    .def    _Z1gx;  .scl    2;  .type   32; .endef
    .seh_proc   _Z1gx
_Z1gx:
.LFB37:
    pushq   %rbp
    .seh_pushreg    %rbp
    movq    %rsp, %rbp
    .seh_setframe   %rbp, 0
    subq    $32, %rsp
    .seh_stackalloc 32
    .seh_endprologue
    movq    %rcx, 16(%rbp)
    movq    16(%rbp), %rax
    movq    %rax, %rcx
    call    _ZSt3absx
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .globl  _Z1fx
    .def    _Z1fx;  .scl    2;  .type   32; .endef
    .seh_proc   _Z1fx
_Z1fx:
.LFB38:
    pushq   %rbp
    .seh_pushreg    %rbp
    movq    %rsp, %rbp
    .seh_setframe   %rbp, 0
    subq    $32, %rsp
    .seh_stackalloc 32
    .seh_endprologue
    movq    %rcx, 16(%rbp)
    movq    16(%rbp), %rax
    movq    %rax, %rcx
    call    _ZSt3absx
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (GNU) 15.2.0"

It seems that they do call the same function std::abs.

Different function abs called after include cassert.h

Ozkan Sezer — Sat, 11 Oct 2025 15:49:32 -0000

Hi everyone.

I tried to compile such code on https://godbolt.org/ using MinGW gcc 15.2.0:

#include <cstdlib>
#include <cassert>

long long g(long long x){
    return abs(x);
}

long long f(long long x){
    return std::abs(x);
}

and i get:

g(long long):
        push    rbp
        mov     rbp, rsp
        sub     rsp, 32
        mov     QWORD PTR 16[rbp], rcx
        mov     rax, QWORD PTR 16[rbp]
        mov     rcx, rax
        call    std::abs(long long)
        add     rsp, 32
        pop     rbp
        ret
f(long long):
        push    rbp
        mov     rbp, rsp
        sub     rsp, 32
        mov     QWORD PTR 16[rbp], rcx
        mov     rax, QWORD PTR 16[rbp]
        mov     rcx, rax
        call    std::abs(long long)
        add     rsp, 32
        pop     rbp
        ret

It seem that both of the functions calls std::abs. However, the first function g should call ::abs(int).

Without including cassert header it works perfectly. It seem that in cassert it includes stdlib.h and put all functions in namespace std in ::.

Am I doing something wrong?

How to build native MinGW-w64 GCC with case-sensitive file paths

Levon — Sat, 27 Sep 2025 15:42:36 -0000

Hello,

I am trying to build a native MinGW-w64 GCC (on Windows/MSYS2) in such a way that the compiler treats file paths case-sensitively, i.e., does not automatically convert paths to lowercase.

Currently, when I invoke g++.exe, I see that all paths passed to cc1plus are already converted to lowercase, regardless of the original case. I understand that the MinGW-w64 CRT mainly provides Windows API wrappers (open, stat, etc.) and does not modify the paths passed by GCC frontend.

My questions are:
1. Is there an official or recommended way to build MinGW-w64 GCC so that it preserves the case of file paths on Windows?
2. Is there a configure/build flag in MinGW-w64 CRT or GCC that enables case-sensitive behavior?

Any guidance, examples, or references to successful builds with case-sensitive paths would be greatly appreciated.

Need to provide instructions for importing a MinGW compiled library into Visual Studio/MSVC++

Jonathan Yong — Mon, 21 Jul 2025 03:21:27 -0000

There's no longer any need to ship libhamlib-4.lib if is generated from dlltool (as opposed to MSVC lib.exe) since libhamlib.dll.a fulfills the same role for gcc. You can still include it for gcc for users who are still expect it to named libhamlib-4.lib. For MSVC, the .def file alone is sufficient for use by lib.exe to generate MSVC compatible libraries.

Need to provide instructions for importing a MinGW compiled library into Visual Studio/MSVC++

Nate Bargmann — Mon, 21 Jul 2025 02:23:39 -0000

I shouldn't wait three months to follow up but other things got in the way.

Thanks for the info on dlltool.

Here is a partial listing from tree showing the bin and lib directories in the distributed .ZIP archive:

hamlib-w32-4.7~git/
├── bin
│   ├── ampctld.exe
│   ├── ampctl.exe
│   ├── libgcc_s_dw2-1.dll
│   ├── libhamlib-4.dll
│   ├── libusb-1.0.dll
│   ├── libwinpthread-1.dll
.
.
.
├── lib
│   ├── gcc
│   │   └── libhamlib.dll.a
│   └── msvc
│       ├── libhamlib-4.def
│       └── libhamlib-4.lib

These locations and files are based on a script a previous maintainer of our project created. Now I am questioning what I should include and what not.

The .DLLs in the bin directory are there so the executables (more than shown) can be run from that directory.

I'm mostly wondering if there is any reason to distribute the lib/gcc/libhamlib.dll.a file.

Also, since lib/msvc/libhamlib-4.lib is generated by MinGW's dlltool, I'm thinking that I should put it in a different directory probably named lib/mingw. That would probably help remove confusion.

Also, I've been provided a recipe for MSVC developers to generate the .lib file from the .dep file using Power Shell, so I think that is taken care of.

Thanks, Jonathan.

Where is langinfo.h and nl_langinfo() for MINGW64?

Vincent Belaïche — Sun, 13 Jul 2025 19:43:11 -0000

Have you tried

pacman -S mingw-w64-x86_64-gettext-tools

Need to provide instructions for importing a MinGW compiled library into Visual Studio/MSVC++

Jonathan Yong — Mon, 21 Apr 2025 02:37:30 -0000

https://learn.microsoft.com/en-us/cpp/build/reference/lib-input-files?view=msvc-170
It should be LIB.EXE /DEF:libhamlib-4.def

You can distribute the def file, MSVC users can run LIB.EXE themselves since it comes as part of MSVC.

Recent posts to Discussion

Compiling and running a C language program with array pointers using "MinGW-w64 GCC 11.4.0 64-bit Release" results in an error output

I saw a post in the C Language Bar, a sub-forum of Baidu Tieba (a Chinese forum)

https://tieba.baidu.com/p/10519222306

The C language program inside has no syntax errors, but there is a problem with the output

When compiling and running the program using "MinGW-w64 GCC 11.4.0 64-bit Debug", the normal output is without any issues. However, when switching to use "MinGW-w64 GCC 11.4.0 64-bit Release" for compiling and running the program, some error numbers are output

In addition, if you change *(*(p+i)+j) to p[i][j], both the Debug and Release versions will output normally without any errors

Why UTF8 is not working with MSYS2 Mingw64 UCRT compiler?

Problems with creating/using dll's

Different function abs called after include cassert.h

Different function abs called after include cassert.h

How to build native MinGW-w64 GCC with case-sensitive file paths

Need to provide instructions for importing a MinGW compiled library into Visual Studio/MSVC++

Need to provide instructions for importing a MinGW compiled library into Visual Studio/MSVC++

Where is langinfo.h and nl_langinfo() for MINGW64?

Need to provide instructions for importing a MinGW compiled library into Visual Studio/MSVC++

In addition, if you change `((p+i)+j)` to `p[i][j]`, both the Debug and Release versions will output normally without any errors