[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148
Gianluigi Tiesi changed:
What|Removed |Added
CC||sherpya at netfarm dot it
--- Comment #3 from Gianluigi Tiesi ---
I get illegal instruction on a AMD GEODE (something like i586):
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 10
model name : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz : 498.044
cache size : 128 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext
3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs: sysret_ss_attrs spectre_v1 spectre_v2
bogomips: 996.08
clflush size: 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
power management:
simple testcase:
__asm volatile("endbr32");
[Bug target/52991] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #22 from Gianluigi Tiesi --- (In reply to Ladislav Láska from comment #21) > Hi! > > I'm still seeing this problem on recent release 6.3.1, and it seems to be > enabled by default on at least some builds (msys2 for example). > > Can I help somehow to get this into trunk sooner? > > Thanks! everyone uses -mno-ms-bitfields nowadays
[Bug c/45317] struct union misalignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45317 --- Comment #2 from Gianluigi Tiesi sherpya at netfarm dot it 2012-11-15 00:13:28 UTC --- so mingw 4.7.0 has same packing behavior of linux gcc, why in _mingw_ = 4.7.0 should I add -malign-double to be compatible with mingw 4.7.0 and msvc abi?
[Bug c/45317] struct union misalignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45317 --- Comment #3 from Gianluigi Tiesi sherpya at netfarm dot it 2012-11-15 00:21:58 UTC --- I've also tested with -malign-double and nothing changes, I don't need mingw32 abi on linux, I need mingw abi on mingw, somehow changed with 4.7.0, I'm not sure if it's a bug or not
[Bug c/45317] struct union misalignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45317 --- Comment #4 from Gianluigi Tiesi sherpya at netfarm dot it 2012-11-15 00:36:10 UTC --- sorry my comment are for another bug, please ignore them
[Bug c/52991] New: attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Bug #: 52991
Summary: attribute packed broken on mingw32?
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sher...@netfarm.it
I've switched form mingw gcc 4.6.2 to 4.7.0 and I've noticed that attribute
packed does not work anymore as expected, simple testcase:
#include stdio.h
#include stdlib.h
#include inttypes.h
typedef struct st_tag
{
uint16_t head __attribute__ ((packed));
uint8_t type;
uint16_t flags __attribute__ ((packed));
} st;
int main(void)
{
st x;
printf(Structure packing got %u offset, expected 3\n,
(unsigned)((char*)x.flags - (char*)x));
return 0;
}
the generated asm is:
movl$4, 4(%esp)
movl$LC0, (%esp)
call_printf
the value is 3 in gcc 4.6.2
Using built-in specs.
COLLECT_GCC=c:\mingw\bin\gcc-4.7.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.7.0/configure --prefix=/mingw --disable-bootstrap
--enable-lto --with-pkgversion=Sherpya --with-bugurl=http://oss.netfarm.it/
--target=i686-pc-mingw32 --enable-targets=i686-pc-mingw32 --with-tune=generic
--with-cpu=i686 --disable-win32-registry --disable-shared --program-suffix=-4.7
--enable-version-specific-runtime-libs --enable-languages=c,c++
--disable-werror --enable-threads=win32 --with-dwarf2 --disable-nls
Thread model: win32
gcc version 4.7.0 (Sherpya)
I don't think save-temps output may be relevant
[Bug c/45317] New: struct union misalignment
Hi, bug or feature? I have this sample:
#include stdio.h
#include stdlib.h
#include stddef.h
#include stdint.h
int main(void)
{
union U
{
struct
{
uint32_t l;
uint32_t h;
} d;
uint64_t q;
};
struct S
{
uint32_t one;
union U two;
uint32_t three;
};
printf(sizeof(union) = %u\n, sizeof(union U));
printf(offsets %u, %u, %u\n, offsetof(struct S, one), offsetof(struct S,
two), offsetof(struct S, three));
return 0;
}
I have different results:
gcc version 4.4.5 20100816 (prerelease) (Debian 4.4.4-9) (32bit)
and gcc version 4.3.5 (Debian 4.3.5-2)
sizeof(union) = 8
offsets 0, 4, 12
gcc version 4.2.5 20090330 (prerelease) [Sherpya] (32bit latest changeset 4.2.5
on mingw)
and gcc version 4.4.3 on mingw32 (built from release tarball)
sizeof(union) = 8
offsets 0, 8, 16
---
I've discovered the problem by passing struct between a binary compiled with
msvc and my code, looks like the 'correct way' is to pad the first int32 in the
struct S with 4 byte to make union 'two' aligned to union size (8)
Something changed in gcc behavior that I don't known?
Regards
--
Summary: struct union misalignment
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sherpya at netfarm dot it
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45317
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #44 from sherpya at netfarm dot it 2010-04-24 02:46 --- nice, it's a bit difficult to handle autoreconf in mingw :D, I need a specific version on my linux box and then make a patch including configure and makefiles changes :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #13 from sherpya at netfarm dot it 2010-04-22 15:31 --- I can build 4.5.0 without problems, I think here no source is pulling in winsock header -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #7 from sherpya at netfarm dot it 2010-04-15 10:03 --- the correct way should be #if defined(FIONREAD) !defined(_WIN32) or if you prefer __MINGW32__ (note _WIN32 is not defined on cygwin) ioctlsocket is not suitable because it does not work on file descriptors also it will need ws2_32 library at link time -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #39 from sherpya at netfarm dot it 2010-04-12 16:55 --- (In reply to comment #35) So if I understand correctly, the state of things at the moment is this: Without LTO: Time: 419.938 sec (6 m 59 s) with LTO incl linker flags: Time: 443.047 sec (7 m 23 s) In other words, with LTO is ~6% slower than without. You say that results aren't exactly as expected but I think there is really not much you can expect. First of all, as it is, in GCC 4.5 LTO/WHOPR does not do a whole lot at all. It is really only inlining across translation unit boundaries. Second, LTO doesn't miraculously increase the number of optimization opportunities, and very often it makes things worse on register-starved architectures like i686 (see http://www.cs.rice.edu/~keith/512/Lectures/30IDFAO.pdf for folklore vs. fact in re. interprocedural optimization). Third, for C/C++ programs the source code is usually already organized in such a way to avoid requiring a whole-program view of the program for the compiler to optimize well. Think .h header files, static inline functions, by-value call conventions, etc. And although I don't know clamav very well, I suspect it's completely I/O bound so optimizing away memory latencies etc. (which is really what LTO is mostly about) wouldn't help for clamav anyway. That doesn't mean that optimizing LTO should slow down your program. It would be interesting to see if it's somehow possible to identify the part of the program that got slower. 6% slower for a new work in progress feature is ok for me, while 60% not :) clamav has a lot of io but also a lot of cpu so it can used for such tests but definitively this patch is usable and could provide more feedbacks to lto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug libstdc++/43738] New: basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
basic_file_stdio.cc in __basic_filechar::showmanyc() uses ioctl with FIONREAD, but the equivalent on win32 is ioctlsocket, perhaps not usable here, because I think there is not support for socket here in gcc (I'm wrong?) anyway it does not compiles I solve this by commenting out that part int __r = ioctl(this-fd(), FIONREAD, __num); if (!__r __num = 0) return __num; the problem still there since 4.3 iirc, I'm the only that noticed it? there is something wrong in my setup? my configure options: ../gcc/configure\ --prefix=/mingw \ --disable-bootstrap \ --with-gnu-ld \ --target=i686-pc-mingw32\ --with-tune=generic \ --with-cpu=i686 \ --disable-cpp \ --disable-win32-registry\ --disable-shared\ --enable-static \ --program-suffix=-4.6 \ --enable-version-specific-runtime-libs \ --enable-languages=c,c++\ --enable-cld\ --enable-__cxa_atexit \ --disable-werror\ --disable-checking \ --enable-multilib \ --enable-threads=posix \ --disable-libssp\ --with-dwarf2 \ --disable-nls \ --with-ppl \ --disable-cloog \ --enable-libgomp -- Summary: basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32 Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #1 from sherpya at netfarm dot it 2010-04-12 23:36 --- FIONREAD is defined by winsock header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #32 from sherpya at netfarm dot it 2010-04-11 17:38 --- I've repeated the test multiple times, I already done scan benchmarks before I think I need to check if I have same results on linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #34 from sherpya at netfarm dot it 2010-04-11 23:58 --- good point :) it should be written in caps, it's not common usage of linking flags :) anyway the reason is easy to understand results aren't exactly as expected by at least not crazy :) --- SCAN SUMMARY --- Known viruses: 754681 Engine version: de...@clamwin MinGW - Apr 12 2010 Scanned directories: 1 Scanned files: 4402 Infected files: 0 Data scanned: 980.84 MB Data read: 998.92 MB (ratio 0.98:1) Time: 443.047 sec (7 m 23 s) about the llvm dll I still get an ice lto1: internal compiler error: in input_gimple_stmt, at lto-streamer-in.c:1108 /* In case of type mismatches across units we can fail to unify some types and thus not find a proper field-decl here. So only assert here if checking is enabled. */ #ifdef ENABLE_CHECKING gcc_assert (tem != NULL_TREE); #endif any suggestion about submitting this bug? I suspect that intermediate file for this report would become very large (normally the resulting binary is 8-9mb large) I've not tested natively but only a cross, but in my opinion your patch looks ok, the produced code was always working -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #29 from sherpya at netfarm dot it 2010-04-09 18:30 --- using -flto links, but looks like it links in a different way while linking llvm part I get ice: In member function 'RefineAbstractType': lto1: internal compiler error: in input_gimple_stmt, at lto-streamer-in.c:1108 Please submit a full bug report, with preprocessed source if appropriate. See http://oss.netfarm.it/ for instructions. lto-wrapper: /opt/mingw/bin/i686-pc-mingw32-g++ returned 1 exit status clamav is not directly compilable with mingw I maintain an unofficial port used in clamwin I've made a simple set of makefiles (without deps by design) to build the mingw version even in cross git clone git://clamwin.git.sourceforge.net/gitroot/clamwin/clamav-win32.git cd contrib/mingw MINGW32_CROSS_PREFIX=i686-pc-mingw32- make or something like make llvm to make llvm dll (I've made a trick to have llvm jit optional) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #30 from sherpya at netfarm dot it 2010-04-09 19:48 --- there is something odd. with lto: --- SCAN SUMMARY --- Known viruses: 754681 Engine version: de...@clamwin MinGW - Apr 9 2010 Scanned directories: 1 Scanned files: 4402 Infected files: 0 Data scanned: 980.84 MB Data read: 998.92 MB (ratio 0.98:1) Time: 674.484 sec (11 m 14 s) without: --- SCAN SUMMARY --- Known viruses: 754681 Engine version: de...@clamwin MinGW - Apr 9 2010 Scanned directories: 1 Scanned files: 4402 Infected files: 0 Data scanned: 980.84 MB Data read: 998.92 MB (ratio 0.98:1) Time: 419.938 sec (6 m 59 s) a lot slower using lto? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #23 from sherpya at netfarm dot it 2010-04-09 03:55 --- Created an attachment (id=20342) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20342action=view) updated for current trunk obsoletes respin-3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #24 from sherpya at netfarm dot it 2010-04-09 03:56 --- Updated for current trunk, just compiled a cross gcc for mingw I'll test if works -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #26 from sherpya at netfarm dot it 2010-04-09 04:02 --- I'm getting a lot of: lto1: warning: visibility attribute not supported in this configuration; ignored in the linking phase using -fwhopr and the link fails with a lot of: ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.data+0xcb2c): undefined reference to `_sigcheck_dummy.31957.3318' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.data+0x134cc): undefined reference to `_sigcheck_dummy.31957.3318' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x15288): undefined reference to `_deflate_stored.34680.3322' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x15294): undefined reference to `_deflate_fast.34676.3326' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x152a0): undefined reference to `_deflate_fast.34676.3326' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x152ac): undefined reference to `_deflate_fast.34676.3326' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x152b8): undefined reference to `_deflate_slow.34672.3330' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x152c4): undefined reference to `_deflate_slow.34672.3330' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x152d0): undefined reference to `_deflate_slow.34672.3330' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x152dc): undefined reference to `_deflate_slow.34672.3330' ../../libclamav/7z.wpa.ltrans.o:7z.wpa.o:(.rdata+0x152e8): undefined reference to `_deflate_slow.34672.3330' using GNU ld (GNU Binutils) 2.20.51.20100408 the link is called by dllwrap: i686-pc-mingw32-dllwrap -Wl,--enable-stdcall-fixup -fwhopr --def ../../contrib/msvc/libclamav.def --implib libclamav.dll.a -o libclamav.dll ___allobjs__ -lws2_32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #27 from sherpya at netfarm dot it 2010-04-09 04:04 --- these functions are static -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug target/34625] msgl-check.c:199: error: unrecognizable insn:
--- Comment #11 from sherpya at netfarm dot it 2010-03-25 03:00 --- please apply to branch 4.2, tested on a file that was not working and fixed the problem (first hunk fails, but it's just the copyright date) -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34625
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #11 from sherpya at netfarm dot it 2009-06-24 11:42 --- I'm using 4.5 from svn, with -O2 and looks like not affected 4.3 and 4.4 are almost unusable on mingw (at least my builds) something changed in 4.5 branch, I've not tested further 4.3 or .4.4 since I was using 4.2 then switched to 4.5 when it started to work on mingw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #12 from sherpya at netfarm dot it 2009-06-24 23:22 --- however 4.5 is still far from being stable as 4.2, I get many crashes while using complied mplayer (it's a stress test for gcc :)) Unfortunately I had no much time to debug mplayer builds -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #47 from sherpya at netfarm dot it 2008-10-07 11:50 --- ffmpeg uses aligned vars inside an object from an external nasm/yasm compiled module, so it's very unlikely gcc can be aware of this, the patch should solve implicit sse code generation, but I think there are no solution for external references. Probably the best way is to pass -fno-common when there is sse code in the project I'll test your patch for the first post of the bugreport, and I'll test also ffmpeg but I'm almost sure that this TARGET_SSE is not true in this specific case with -fno-common I had no problems with make test (when using sse code) all of the stuff in this bugreport is not really definitive, we have a patch for local and for global using commons but there is no way to propagate this data in pe/coff object why not adding an extensions for intermediate coffs? there isn't space anywhere in coff files? yes one can use -fno-common or the fix to avoid crashes when gcc vectorize but it does not cover all cases -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #5 from sherpya at netfarm dot it 2008-10-07 12:48 --- *** This bug has been marked as a duplicate of 37750 *** -- sherpya at netfarm dot it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #5 from sherpya at netfarm dot it 2008-10-07 12:48 --- *** Bug 37584 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #6 from sherpya at netfarm dot it 2008-10-07 13:23 --- first bt, (pls tell me if you need output of leave temps, generated asm preprocessed or other stuff) Program received signal SIGSEGV, Segmentation fault. 0x0092c4c2 in _alloca () (gdb) bt #0 0x0092c4c2 in _alloca () #1 0x005c7462 in get_dc (s=0x6230030, mb_x=0, mb_y=0, plane_index=0) at libavcodec/snow.c:2426 #2 0x005cff6a in iterative_me (s=0x6230030) at libavcodec/snow.c:3126 #3 0x005d7467 in encode_blocks (s=0x6230030, search=1) at libavcodec/snow.c:2074 #4 0x005d7a2a in encode_frame (avctx=0x5aa3f90, buf=0x5fe06c0 BINARY DATA REMOVED..., buf_size=262144, data=0x22eda8) at libavcodec/snow.c:4268 #5 0x00499513 in avcodec_encode_video (avctx=0x5aa3f90, buf=0x5fe06c0 BINARY DATA REMOVED..., buf_size=262144, pict=0x22eda8) at libavcodec/utils.c:894 #6 0x00405626 in output_packet (ist=0x5ed6450, ist_index=0, ost_table=0x5aa4390, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:954 #7 0x00409269 in av_encode (output_files=0xb6b378, nb_output_files=1, input_files=0xb6a608, nb_input_files=1, stream_maps=0xb6b3c8, nb_stream_maps=0) at ffmpeg.c:2116 #8 0x00409761 in main (argc=Cannot access memory at address 0x0 ) at ffmpeg.c:3888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #8 from sherpya at netfarm dot it 2008-10-07 13:29 --- another crash in snow, this time argc/argv is not screwed Program received signal SIGSEGV, Segmentation fault. 0x0092c4c2 in _alloca () (gdb) bt #0 0x0092c4c2 in _alloca () #1 0x005d7de7 in encode_frame (avctx=0x5aa3f20, buf=0x5fda480 BINARY DATA REMOVED..., buf_size=405504, data=0x22eda8) at libavcodec/snow.c:2426 #2 0x00499513 in avcodec_encode_video (avctx=0x5aa3f20, buf=0x5fda480 BINARY DATA REMOVED..., buf_size=405504, pict=0x22eda8) at libavcodec/utils.c:894 #3 0x00405626 in output_packet (ist=0x5ed6450, ist_index=0, ost_table=0x5cd6470, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:954 #4 0x00409269 in av_encode (output_files=0xb6b378, nb_output_files=1, input_files=0xb6a608, nb_input_files=1, stream_maps=0xb6b3c8, nb_stream_maps=0) at ffmpeg.c:2116 #5 0x00409761 in main (argc=95043360, argv=0x3f4998) at ffmpeg.c:3888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #9 from sherpya at netfarm dot it 2008-10-07 13:35 --- sqv1 Program received signal SIGSEGV, Segmentation fault. 0x0092c4c2 in _alloca () (gdb) bt #0 0x0092c4c2 in _alloca () #1 0x005e3338 in svq1_encode_plane (s=0x5a9f2c0, plane=value optimized out, src_plane=0x5ac9fa0 BINARY DATA REMOVED..., ref_plane=0x6063010 '\200' repeats 200 times..., decoded_plane=0x6089300 '\200' repeats 200 times..., width=352, height=288, src_stride=352, stride=416) at libavcodec/svq1enc.c:363 #2 0x005e467a in svq1_encode_frame (avctx=0x5aa3eb0, buf=0x5fe05a0 , buf_size=405504, data=0x22eda8) at libavcodec/svq1enc.c:541 #3 0x00499513 in avcodec_encode_video (avctx=0x5aa3eb0, buf=0x5fe05a0 , buf_size=405504, pict=0x22eda8) at libavcodec/utils.c:894 #4 0x00405626 in output_packet (ist=0x5ed6450, ist_index=0, ost_table=0x5ac9e00, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:954 #5 0x00409269 in av_encode (output_files=0xb6b378, nb_output_files=1, input_files=0xb6a608, nb_input_files=1, stream_maps=0xb6b3c8, nb_stream_maps=0) at ffmpeg.c:2116 #6 0x00409761 in main (argc=Cannot access memory at address 0x100 ) at ffmpeg.c:3888 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #4 from sherpya at netfarm dot it 2008-10-07 09:38 --- unfortunately snow.c is a very big file, I'll try to find a shorter example, but if the problem is in alloca() the generated asm will not be so usefull -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #7 from sherpya at netfarm dot it 2008-10-07 13:27 --- compile flags OPTFLAGS=-O3 -fno-common -g3 -march=native -mtune=native -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -fasm -std=c99 -fomit-frame-pointer -DPTW32_STATIC_LIB -g3 -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -O2 -fno-math-errno -fno-signed-zeros -O3 -fno-common -march=native -mtune=native -pipe where added by me (-fno-common is needed to avoid crash in sse code) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #49 from sherpya at netfarm dot it 2008-10-07 12:15 --- not exactly, Simon Sasburg compiled with -march=core2 I'm not explicitly telling to gcc to compile sse code, arch is i686 and opt is -O2 so there is no sse code generated by gcc, ffmpeg declares aligned vars in fft.c and uses them in asm sse code, file fft_mmx.asm that is generated by yasm so gcc is unable to known that those vars will be used by sse code, this case will not covered by the last patch gcc should emit a warning when compiling align declared vars on win32 version 3.x had a similar warning but only if using align 16 with current state of compiler/toolchain even 16-bytes aligned is not possible without explicit -fno-common compile switch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #34 from sherpya at netfarm dot it 2008-10-06 14:13 --- $ nm ffmpeg_g.exe |grep ff_cos_16 00dd84e0 B _ff_cos_16 00de04c0 B _ff_cos_16384 except snow and svq1 tests, crashing because of bugs in tree opts on win32 sse code is working fine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #36 from sherpya at netfarm dot it 2008-10-06 17:14 --- so how with -fno-common can make aligned work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #38 from sherpya at netfarm dot it 2008-10-06 17:27 --- yes alignment works, and even my test align program with 4.2 without patches gives correct alignment to local and global symbols Local Aligned 16: 0 Local Aligned 32: 0 Global Aligned 16: 0 Global Aligned 32: 0 16 - 265986.00 - 32 - 132994.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug tree-optimization/37750] New: a lot of crashes with tree optimizations on mingw
while testing ffmpeg compiled with gcc 4.3.3 from 4.3 trunk I got a lot of crashes especially in snow encoding testcase by using: -fno-tree-dominator-opts -fno-tree-vrp -fno-dce -fno-tree-ch I get no crashes gcc 4.4 has same problems, I've already filled a bug about tree-ch, that corrupts the stack on win32 (looks like it's related to alloca()) -- Summary: a lot of crashes with tree optimizations on mingw Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #40 from sherpya at netfarm dot it 2008-10-06 18:54 --- I mean that with -fno-common alignment works, even with non patched 4.2, my question is due to the fact that it's not so clear for me what no-common does and adding -fno-common what are side effects? do using something like dummy or nops in bss section does something wrong? at this point a forced alignment to 16 wouldn't be such a problem for the space wasted, at least this can avoid problems with sse code (16 bytes) and 3dnow (8 bytes) gcc may need to disable sse code on mingw/cygwin or at least avoid implicit vectorizations -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37750] a lot of crashes with tree optimizations on mingw
--- Comment #2 from sherpya at netfarm dot it 2008-10-06 22:34 --- this problem started with 4.3, 4.3.2 on debian linux hasn't these problems -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37750
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #43 from sherpya at netfarm dot it 2008-10-07 01:32 --- binutils 2.18.91.20080917 on both there are changes for the local alignment in the gas code but gcc does not use them without my attached gcc_align_fix.diff patch (not sure 100%) newer binutils are not working well on mingw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #32 from sherpya at netfarm dot it 2008-10-04 21:40 --- this archive: http://people.netfarm.it/~sherpya/gcc/info.7z contains ffmpeg_g.exe - non stripped final executable fft.c/o/s - source, object file and asm generated related vars are: ff_cos_16, ff_cos_32 etc $ nm ffmpeg_g.exe |grep ff_cos_16 00e62d14 B _ff_cos_16 00e25654 B _ff_cos_16384 $ nm libavcodec/fft.o |grep ff_cos_16 0020 C _ff_cos_16 8000 C _ff_cos_16384 gcc version 4.3.3 20081004 (prerelease) (Sherpya) (plain svn with the patch) GNU ld (GNU Binutils) 2.18.91.20080917 I can also provide all my build env as 7z Regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #30 from sherpya at netfarm dot it 2008-10-03 17:06 --- the patch looks ok but unfortunately does not always solves the problem, something in the chain misalignes the symbol This does not happen always but in some circumstances :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #25 from sherpya at netfarm dot it 2008-09-30 14:10 --- (In reply to comment #24) Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 a printf in the code for ff_cos_16 causes the compiler to align the var, but at this point it crashes in another place using sse code So, does this mean that the align patch is working, but that there is some other bug that is preventing some sse code from working ? If so then I can formally submit the align patch for approval. Cheers Nick unfortunately not, with a printf the var is aligned without a printf is not aligned (someone changes the behavior of the patch), and thus it will crash the patch seems to make the right job but some other tool in the chain interferes with it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #15 from sherpya at netfarm dot it 2008-09-29 15:39 --- I also got the error on the first patch, gcc 4.4 from svn, binutils 2.18.91.20080917 I still have problems with 2.19 binutils snapshots (unable to correctly create and link dll) unfortunately the current gcc svn does not compile for mingw because of: build/i686-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2689: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), const int, const wchar_t [4], long double)' I may need to fill another bug There is no such code applicable to 4.2 branch :( Please take a look at the attached patch, I've picked it from a mailing list, it makes possible align with local variables (static) I don't known if your patches makes it unneeded -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #16 from sherpya at netfarm dot it 2008-09-29 15:40 --- Created an attachment (id=16426) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16426action=view) lcomm + alignment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #17 from sherpya at netfarm dot it 2008-09-29 16:30 ---
with both patches I can achieve align 16
align 16 on globals still fails
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 16
the program is:
#include stdio.h
#include stdlib.h
#include inttypes.h
static int local_16[8] __attribute__ ((aligned (16)));
static int local_32[8] __attribute__ ((aligned (32)));
int global_16[8] __attribute__ ((aligned (16)));
int global_32[8] __attribute__ ((aligned (32)));
int main(void)
{
printf(Local Aligned 16: %d\n, (intptr_t) local_16 % 16);
printf(Local Aligned 32: %d\n, (intptr_t) local_32 % 32);
printf(Global Aligned 16: %d\n, (intptr_t) global_16 % 16);
printf(Global Aligned 32: %d\n, (intptr_t) global_32 % 32);
return 0;
}
did I miss something?
(perhaps 16 byte alignment it's enough for sse)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #20 from sherpya at netfarm dot it 2008-09-29 19:33 ---
align testcase looks ok, but anyway I'm mainly interested to have code aligned
to 16. volatile around variables is not enough in my test program.
Nick's testcase is ok even on (local-only align) patched gcc 4.2
I've solved to_xstring problem by using vsnwprintf instead, but current trunk
produces buggy ffmpeg executable so many tests are crashing
aligned data looks ok, at least the variables that were unaligned when it was
crashing
I'm still not so sure about the optimization and the alignment, this code:
#include stdio.h
#include stdlib.h
#include inttypes.h
static volatile int local_16[8] __attribute__ ((aligned (16)));
static volatile int local_32[8] __attribute__ ((aligned (32)));
int volatile global_16[8] __attribute__ ((aligned (16)));
int volatile global_32[8] __attribute__ ((aligned (32)));
int main(void)
{
volatile double diff16, diff32;
printf(Local Aligned 16: %d\n, (intptr_t) local_16 % 16);
printf(Local Aligned 32: %d\n, (intptr_t) local_32 % 32);
printf(Global Aligned 16: %d\n, (intptr_t) global_16 % 16);
printf(Global Aligned 32: %d\n, (intptr_t) global_32 % 32);
diff16 = (intptr_t) global_16 / 16.0f;
diff32 = (intptr_t) global_32 / 32.0f;
printf(16 - %f - 32 - %f\n, diff16, diff32);
return 0;
}
still outputs:
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 16
16 - 263177.00 - 32 - 131587.50
regardless of the optimizations options
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #22 from sherpya at netfarm dot it 2008-09-29 23:17 ---
still no success while compiling ffmpeg :(
Program received signal SIGSEGV, Segmentation fault.
0x0074fe94 in ff_fft_calc_3dn ()
(gdb) bt
#0 0x0074fe94 in ff_fft_calc_3dn ()
#1 0x007506f5 in ff_fft_calc_3dn ()
#2 0x00750755 in ff_fft_calc_3dn ()
#3 0x00750a55 in ff_fft_dispatch_sse ()
#4 0x0400 in ?? ()
#5 0x0074f718 in ff_fft_calc_sse (s=0x5b14600, z=0x5b0c5f0) at
libavcodec/i386/fft_sse.c:35
#6 0x00748080 in ff_mdct_calc (s=0x5b145f0, out=0x5b0c5f0, input=0x5b105f0) at
libavcodec/dsputil.h:673
#7 0x0064731d in encode_superframe (avctx=0x5ac4010, buf=0x5ba0030 ,
buf_size=524288, data=0x5b5cca0) at libavcodec/wmaenc.c:92
#8 0x00495b16 in avcodec_encode_audio (avctx=0x5ac4010, buf=0x5ba0030 ,
buf_size=524288, samples=0x750a50) at libavcodec/utils.c:865
#9 0x00406236 in output_packet (ist=0x5ac4390, ist_index=0,
ost_table=0x3fbfb0, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:672
#10 0x004095d1 in av_encode (output_files=0xb6c000, nb_output_files=1,
input_files=0xb6b280, nb_input_files=1, stream_maps=0xb6c060, nb_stream_maps=0)
at ffmpeg.c:2129
#11 0x00409878 in main (argc=Cannot access memory at address 0xa
) at ffmpeg.c:3897
(gdb) p ff_cos_16
$1 = {1, 0.923879504, 0.707106769, 0.382683426, 6.12303177e-017, 0.382683426,
0.707106769, 0.923879504}
(gdb) p ff_cos_16
$2 = (FFTSample (*)[8]) 0xe55c94
asm code:
.lcomm _ff_cos_16,32,16
lcomm?
nm output:
$ nm ffmpeg_g.exe |grep ff_cos_16
00e55c94 B _ff_cos_16
00e185d4 B _ff_cos_16384
not aligned :(
gcc version 4.3.3 20080929 (prerelease) (Sherpya)
GNU assembler version 2.18.91 (i686-pc-mingw32) using BFD version (GNUBinutils)
2.18.91.20080917
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #23 from sherpya at netfarm dot it 2008-09-29 23:22 --- a printf in the code for ff_cos_16 causes the compiler to align the var, but at this point it crashes in another place using sse code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #4 from sherpya at netfarm dot it 2008-09-22 09:51 --- I've also seen crashes in alloca(), at least according to gdb backtrace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #2 from sherpya at netfarm dot it 2008-09-20 09:43 --- adding -fno-tree-ch avoid crashing in mencoder, so I filled the bug on this, but it can be a side effect of something else -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug tree-optimization/37584] New: -ftree-ch causes stack corruption on mingw32
Unfortunately there is no simple testcase for this, but compiling mplayer I get a lot of crashes related to stack corruption i.e. a function allocates in the stack 8 bytes and later gdb says that it cannot access to a byte that instead is bound I've tested with --stack-size on the linker but nothing changes gcc version 4.4.0 20080916 (experimental) does the same thing while gcc 4.2 is ok it can be reproduced compiling mplayer/mencoder with gcc = 4.3 and doing a simple encoding using snow codec: mencoder -oac faac -faacopts br=64 -ovc lavc -lavcopts vcodec=snow:vstrict=-2:vqscale=3:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel a.mpg -o a.avi Please tell me if I can provide more infos -- Summary: -ftree-ch causes stack corruption on mingw32 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug middle-end/30956] ice on final.c
--- Comment #4 from sherpya at netfarm dot it 2007-02-25 20:13 --- I've compiled other things and this messages is a warning in 4.1, but doesn't crashes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug c/30956] New: ice on final.c
When compiling fribidi-0.10.7 the compiler fails here: gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -Wall -pedantic -fno-strict-aliasing -MT fribidi_utils.lo -MD -MP -MF .deps/fribidi_utils.Tpo -c fribidi_utils.c -o fribidi_utils.o fribidi_utils.c: In function 'fribidi_map_range': fribidi_utils.c:108: internal compiler error: in rest_of_handle_final, at final.c:3942 fribidi-0.10.4 is ok Compiler version ming32 4.1.2 compile options: Configured with: ../gcc-4.1.2/configure --with-gcc --with-ld=/mingw/bin/ld --with-gnu-as --program-suffix=-4.1 --enable-version-specific-runtime-libs --disable-libstdcxx-debug --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads=win32 --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --enable-sjlj-exceptions --disable-interpreter --disable-werror --enable-hash-synchronization Thread model: win32 I'll attach dumps -- Summary: ice on final.c Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug c/30956] ice on final.c
--- Comment #1 from sherpya at netfarm dot it 2007-02-25 02:26 --- Detailed output: gcc -v -save-temps -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -Wall -pedantic -fno-strict-aliasing -MT fribidi_utils.lo -MD -MP -MF .deps/fribidi_utils.Tpo -c fribidi_utils.c -o fribidi_utils.o Using built-in specs. Target: mingw32 Configured with: ../gcc-4.1.2/configure --with-gcc --with-ld=/mingw/bin/ld --with-gnu-as --program-suffix=-4.1 --enable-version-specific-runtime-libs --disable-libstdcxx-debug --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads=win32 --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --enable-sjlj-exceptions --disable-interpreter --disable-werror --enable-hash-synchronization Thread model: win32 gcc version 4.1.2 [Sherpya] j:/mingw/bin/../libexec/gcc/mingw32/4.1.2/cc1.exe -E -quiet -v -I. -I. -I. -iprefix j:\mingw\bin\../lib/gcc/mingw32/4.1.2/ -MD fribidi_utils.d -MF .deps/fribidi_utils.Tpo -MP -MT fribidi_utils.lo -MQ fribidi_utils.o -DHAVE_CONFIG_H fribidi_utils.c -Wall -pedantic -fno-strict-aliasing -fworking-directory -O2 -fpch-preprocess -o fribidi_utils.i ignoring nonexistent directory j:/MinGW/mingw32/include #include ... search starts here: #include ... search starts here: . . . j:/mingw/bin/../lib/gcc/mingw32/4.1.2/include j:/MinGW/include /mingw/include j:/MinGW/lib/gcc/mingw32/4.1.2/include /mingw/include End of search list. j:/mingw/bin/../libexec/gcc/mingw32/4.1.2/cc1.exe -fpreprocessed fribidi_utils.i -quiet -dumpbase fribidi_utils.c -auxbase-strip fribidi_utils.o -g -O2 -Wall -pedantic -version -fno-strict-aliasing -o fribidi_utils.s GNU C version 4.1.2 [Sherpya] (mingw32) compiled by GNU C version 4.1.1 [Sherpya]. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=131005 Compiler executable checksum: 189b7f34c85af66fb411018b3b42b485 fribidi_utils.c: In function 'fribidi_map_range': fribidi_utils.c:108: internal compiler error: in rest_of_handle_final, at final.c:3942 -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug c/30956] ice on final.c
--- Comment #2 from sherpya at netfarm dot it 2007-02-25 02:33 --- Created an attachment (id=13104) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13104action=view) source .s and .i the full source of program can be found here: http://fribidi.org/download/fribidi-0.10.7.tar.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug c/30242] New: internal error in gcc break compilation
gcc 4.3 current svn branch revision 120001 it's not possible to have -save-temps since the compiler bombs while assembling cygwin.asm using gcc (uh?) /d/Download/Devel/MinGW/gcc-source/build/./gcc/xgcc -B/d/Download/Devel/MinGW/gcc-source/build/./gcc/ -L/d/Download/Devel/MinGW/gcc-source/build/mingw32/w insup/mingw -L/d/Download/Devel/MinGW/gcc-source/build/mingw32/winsup/w32api/lib -isystem /d/Download/Devel/MinGW/gcc-source/gcc/winsup/mingw/include -isyst em /d/Download/Devel/MinGW/gcc-source/gcc/winsup/w32api/include -B/mingw/mingw32/bin/ -B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem /mingw/ mingw32/sys-include -O2 -I../../gcc/gcc/../winsup/w32api/include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../ gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL_chkstk -xassembler-with-cpp -c ../../gcc/gcc/con fig/i386/cygwin.asm -o libgcc/./_chkstk.o -save-temps -- Summary: internal error in gcc break compilation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242
[Bug preprocessor/30242] internal error in gcc break compilation
--- Comment #1 from sherpya at netfarm dot it 2006-12-18 03:31 --- I forgot to attach the error: cc1.exe: internal compiler error: in add_standard_paths, at c-incpath.c:173 so it's not in gcc but the preprocessor I've bootstrapped from 4.1.1 -- sherpya at netfarm dot it changed: What|Removed |Added Component|c |preprocessor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242
[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #3 from sherpya at netfarm dot it 2005-12-11 08:09 --- looking at gcc/Makefile ORIGINAL_LD_FOR_TARGET = ./j:/mingw/bin/../lib/gcc/mingw32/4.0.2/../../../../mingw32/bin/ld.exe ORIGINAL_NM_FOR_TARGET = /mingw/bin/nm so LD path takes a : that interfers with make, on gcc 402 it works fine, so I think the problem is how configure finds the path of ld, somehow changed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #4 from sherpya at netfarm dot it 2005-12-11 20:41 --- My latest build unaffected from this bug is 4.1.0 cvs 20051013 (now I've switched to svn), anyway fixing the ld path compiles fine. -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin
--- Additional Comments From sherpya at netfarm dot it 2005-09-05 10:04 --- The patch still broken it fails to compiles some resources i.e. building reactos -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin
--- Additional Comments From sherpya at netfarm dot it 2005-06-14 00:30 --- can you provide a correct patch? I've just adapted the old one to apply and compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error
--- Additional Comments From sherpya at netfarm dot it 2005-06-05 06:48 --- yes it's true, but it's not a solution I'm trying to isolate to problem :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21878
[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin
--- Additional Comments From sherpya at netfarm dot it 2005-06-05 07:47 --- Your patches doesn't clean apply to current cvs, I've revised it but I've renamed DECL_NON_ADDR_CONST_P in TARGET_DECL_NON_ADDR_CONST_P in varasm.c since there is no reference for DECL_NON_ADDR_CONST_P in code, also I've noticed that in libgcov.c the mkdir substituion doesn't take place so mingw gives an error about mkdir taking 2 args instead of one. I'm attaching the new patch, please take a look -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error
--- Additional Comments From sherpya at netfarm dot it 2005-06-05 03:59 --- the problematic dirs are target-libiberty target-libstdc++-v3 since adding this to target: skipdirs=target-libiberty target-libstdc++-v3 compiles fine (cross compiling with linux), anyway I suppose this cannot work on native mingw32 build, but I'll test it anyway -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21878
[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin
--- Additional Comments From sherpya at netfarm dot it 2005-06-05 05:15 --- as I posted in the duplicated bug thread, the problematic directories are: target-libiberty target-libstdc++-v3 also I had a working build on cvs snapshot of 20050522, btw in that build ATTRIBUTE_SENTINEL was not defined when building libiberty on mingw, and also gcov has to be fixed since it has a mkdir with 2 params, on win32 it has only one param, but I've easy solved these problems. I'll spend some time to check when exactly the build was broken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
[Bug bootstrap/21878] New: Mingw32 target doesn't compile because of an internal compiler error
Different errors when cross compiling from linux, more detailed info follow -- Summary: Mingw32 target doesn't compile because of an internal compiler error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21878
[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error
--- Additional Comments From sherpya at netfarm dot it 2005-06-02 13:17 --- Created an attachment (id=9013) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9013action=view) Debug output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21878
[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error
--- Additional Comments From sherpya at netfarm dot it 2005-06-02 13:17
---
Linux cross:
Linux 2.6.x i686 GNU/Linux
Debian/Sid
System wide binutils 2.15
mingw32-binutils version 2.16
../gcc/configure -v \
--prefix=/usr \
--target=i586-mingw32msvc \
--enable-languages=c,c++\
--enable-threads\
--enable-sjlj-exceptions\
--disable-multilib \
--enable-version-specific-runtime-libs
make[1]: Entering directory `/root/mplayer/gcc/build/i586-mingw32msvc/libiberty'
if [ x != x ]; then \
/root/mplayer/gcc/build/./gcc/xgcc -B/root/mplayer/gcc/build/./gcc/
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include -c
-DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall
-pedantic -Wwrite-strings -Wstrict-prototypes
../../../gcc/libiberty/fopen_unlocked.c -o pic/fopen_unlocked.o; \
else true; fi
/root/mplayer/gcc/build/./gcc/xgcc -B/root/mplayer/gcc/build/./gcc/
-B/usr/i586-mingw32msvc/bin/ -B/usr/i586-mingw32msvc/lib/ -isystem
/usr/i586-mingw32msvc/include -isystem /usr/i586-mingw32msvc/sys-include -c
-DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall
-pedantic -Wwrite-strings -Wstrict-prototypes
../../../gcc/libiberty/fopen_unlocked.c -o fopen_unlocked.o
../../../gcc/libiberty/fopen_unlocked.c: In function 'unlock_std_streams':
../../../gcc/libiberty/fopen_unlocked.c:98: error: invariant not recomputed when
ADDR_EXPR changed
_iobD.1250[1];
../../../gcc/libiberty/fopen_unlocked.c:98: error: invariant not recomputed when
ADDR_EXPR changed
_iobD.1250[2];
../../../gcc/libiberty/fopen_unlocked.c:98: internal compiler error:
verify_stmts failed.
Attached dump files fopen_unlocked.{i,s}
Native compile:
../gcc/configure -v \
--prefix=/opt/gcc \
--enable-languages=c,c++\
--enable-threads\
--enable-sjlj-exceptions\
--disable-multilib \
--enable-version-specific-runtime-libs
works fine
: Stage1 (base) compiler is:
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.6/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.6 (Debian 1:3.3.6-5)
Win32 (mingw)
binutils 2.16
gcc (for stage1):
Reading specs from j:/MinGW/bin/../lib/gcc/mingw32/3.4.4/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.4 (mingw special)
../gcc/configure \
--with-gcc \
--with-gnu-ld \
--with-gnu-as \
--host=mingw32 \
--target=mingw32 \
--prefix=/mingw \
--enable-threads \
--disable-nls \
--enable-languages=c,c++ \
--disable-win32-registry \
--disable-shared \
--enable-sjlj-exceptions \
--enable-interpreter \
--enable-hash-synchronization \
--enable-libstdcxx-debug
make[1]: Entering directory `/home/Sherpya/gcc/build/gcc'
./xgcc -B./ -B/mingw/mingw32/bin/ -isystem /mingw/mingw32/include -isystem
/mingw/mingw32/sys-include -L/home/Sherpya/gcc/build/gcc/../ld -O2
-I../../gcc/gcc/../winsup/w32api/include -DIN_GCC-W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I.
-I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -DL_eprintf -c ../../gcc/gcc/libgcc2.c -o
libgcc/./_eprintf.o
../../gcc/gcc/libgcc2.c: In function '__eprintf':
../../gcc/gcc/libgcc2.c:1803: error: invariant not recomputed when ADDR_EXPR
changed
_iobD.1252[2];
../../gcc/gcc/libgcc2.c:1803: error: invariant not recomputed when ADDR_EXPR
changed
_iobD.1252[2];
../../gcc/gcc/libgcc2.c:1803: internal compiler error: verify_stmts failed.
Attached dump files libgcc2.{i,s}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21878
