[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #12 from ktietz at gcc dot gnu dot org 2010-09-21 17:58 --- Subject: Bug 45694 Author: ktietz Date: Tue Sep 21 17:58:32 2010 New Revision: 164489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164489 Log: 2010-09-21 Kai Tietz kai.ti...@onevision.com PR target/45694 * config/i386/i386.c (ix86_expand_prologue): Save r10 in case that static chain-register is used for 64-bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #13 from ktietz at gcc dot gnu dot org 2010-09-21 19:05 --- Subject: Bug 45694 Author: ktietz Date: Tue Sep 21 19:05:18 2010 New Revision: 164495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164495 Log: 2010-09-21 Kai Tietz kai.ti...@onevision.com PR target/45694 * config/i386/i386.c (ix86_expand_prologue): Save r10 in case that static chain-register is used for 64-bit. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-09-21 19:09 --- Issue fixed on mainline and backported to 4.5 branch -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug target/45694] [MinGW64] fortran host associated variables+optimization==failure?
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-09-20 12:07 --- (In reply to comment #8) This issue is caused by the fact that __chkstk clobbers r10 (see its constrains), which is used here as argument-register for this nested function. So something is broken here about register-clobbering. I would welcome if my modified stack-allocation for windows would get reviewed and applied. This new implementation avoid this useless register-clobbering ... But well, this seems to me like a bug in interpretation of register clobbering here ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-09-17 14:01 --- Created an attachment (id=21820) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820action=view) testcase for problem As this test need more then on header, please extract it and compile then main.c to reproduce it. At least I was able to do this on linux64 by this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #15 from ktietz at gcc dot gnu dot org 2010-09-17 18:37 --- (In reply to comment #14) Created an attachment (id=21820) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21820action=view) [edit] testcase for problem As this test need more then on header, please extract it and compile then main.c to reproduce it. At least I was able to do this on linux64 by this testcase. Patch for it posted to ML. See http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01394.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-09-16 17:04:34 |2010-09-17 18:37:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-09-16 16:56 --- (In reply to comment #4) (In reply to comment #2) http://gcc.gnu.org/bugs/#need Since this is a bug in the preprocessor it is hard to get a preprocessed source that causes a bug. That's true. Interesting is that by doing preprocessed source out of it, result is correct. Just within compiler it makes troubles, as here garbage collector gets raised, which cleans up with store reference, as a root element for preprocessor tokens is missing to keep it alive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug bootstrap/45666] ICE: /mingw/include/winnt.h:3350:5: Segmentation fault
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-09-14 05:46 --- *** This bug has been marked as a duplicate of 45362 *** -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45666
[Bug preprocessor/45362] Dangling reference about saved cpp_macro for push/pop macro
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-09-14 05:46 --- *** Bug 45666 has been marked as a duplicate of this bug. *** -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||t7 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug target/45452] Change default link order for x86_64-mingw32
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-09-01 16:58 --- Fix applied at revision 163738. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45452
[Bug target/45452] Change default link order for x86_64-mingw32
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-08-31 12:17 --- Ok, patch sent to gcc's ML. This issue can lead to troubles on Windows OSes Vista or newer. But this bug isn't just x86_64-*-mingw32 one. It affects (if more recent import-libraries are used) even 32-bit mingw and cygwin, too. I addressed this in the patch I've sent. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC target triplet|x86_64-w64-mingw32 |*-*-mingw* i686-*-cygwin Last reconfirmed|-00-00 00:00:00 |2010-08-31 12:17:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45452
[Bug preprocessor/41943] include search path composition is bogus
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-08-31 14:31 --- Fixed on trunk and won't be backported to 4.5.x, therefore I close this bug -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug bootstrap/43900] ICE in dbxout.c
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-08-21 08:19 --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #2) As it turns out, the ICE only manifests in a parallel build. I tried make -j 8, my default and make -j 3. For an ordinary make there is no issue. So, I'm curious how to handle this. Any thoughts? Rainer Rainer, you are not accidentially are using rxvt terminal? Kai I did, but I haven't had any issues in the past. So , I try without rxvt. Rainer Have you made your tests here without rxvt? I tested it in cygwin standard cmd shell for -j3, and I can bootstrap here without flaw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43900
[Bug bootstrap/43900] ICE in dbxout.c
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-08-21 09:26 --- Ok, let us close it. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43900
[Bug preprocessor/45362] New: Dangling reference about saved cpp_macro for push/pop macro
The issue is that for the push/pop macro the old state of the macro (a cpp_macro reference) is stored. As this structure is handled by GC without a root, all get free'ed when garbage collection happens. This gc can lead to issues when such a saved node gets undefined and the node, which previously hold the cpp_macro reference, gets reused for a different macro. As the linked in the saved macro list isn't under control of gc and it doesn't have a gc root element, the stored reference gets invalid in such cases and can lead to segmentation faults due access to already free'ed memory. -- Summary: Dangling reference about saved cpp_macro for push/pop macro Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
[Bug libstdc++/45300] New: in cstdio/cstdlib keyword restrict is used instead of __restrict
We noticed that in the headers cstdio and cstdlib the c99 keyword restrict is used unconditionally. AFAICS it should be used here __restrict instead. By user-report - I've got - it leads to the issue that the restrict keyword gets interpreted as argument name for non c99. -- Summary: in cstdio/cstdlib keyword restrict is used instead of __restrict Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: x86_64-*-* i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300
[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-08-16 17:40 --- (In reply to comment #3) Let's add in CC Jakub, just in case he can see something wrong vs the C library with using __restrict__ here. The normal c-library headers are using here __restrict as keyword. But __restrict__ should be fine too, beside there are some nits I can't see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300
[Bug fortran/42954] gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-08-03 10:09 --- Created an attachment (id=21373) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21373action=view) Patch for fixing at least target part for preprocessor This patch re-enables at least target defines for fortran's preprocessor. The architecture part isn't enabled, as for example i386's architecture preprocessor settings are at the moment just working for C/C++ frontends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
[Bug target/45111] New: main function isn't profiled
I recently noticed that for the main function the _monstartup call gets emitted after _mcount call. This leads to the issue, that for the main function itself no information are getting gathered. A possible solution here would be to call mcount for main-function, if not -mfentry is used, a second time. This shouldn't harm. Any comments? -- Summary: main function isn't profiled Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: i?86-*-cygwin *-*-mingw* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45111
[Bug middle-end/45075] New: Optimization failure about user-defined sections
Hello,
as we noticed there is an new optimization failure about user-defined sections
and loops.
The following code works for me with -O0, but fails with -O2.
extern void abort (void);
static long long start __attribute__ ((section (.my_sec$A))) = 0;
static long long end __attribute__ ((section (.my_sec$Z))) = 2;
int main()
{
long long *p;
for (p = (start + 1); p != end; p++)
if (*p == 2)
abort();
return 0;
}
--
Summary: Optimization failure about user-defined sections
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45075
[Bug middle-end/45075] Optimization failure about user-defined sections
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-07-26 08:43 --- Version used $ /usr/local/bin/x86_64-pc-mingw32-gcc.exe -v Using built-in specs. COLLECT_GCC=/usr/local/bin/x86_64-pc-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-mingw32/4.6.0/lto-wrapper.exe Target: x86_64-pc-mingw32 Configured with: ../gcc/configure --target=x86_64-pc-mingw32 --enable-lto target _alias=x86_64-pc-mingw32 --enable-languages=c,c++,fortran,java,lto,objc --no-create --no-recursion : (reconfigured) ../gcc/configure --target=x86_64-pc-mingw32 --enable-lto target_alias=x86_64-pc-mingw32 --enable-languages=c,c++,fortran,java,lto,objc --no-create --no-recursion Thread model: win32 gcc version 4.6.0 20100726 (experimental) (GCC) This issue could be also LTO related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45075
[Bug middle-end/45075] Optimization failure about user-defined sections
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-07-26 08:52 --- The test fails for me for any type != char for section variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45075
[Bug preprocessor/41943] include search path composition is bogus
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-07-23 18:32 --- Subject: Bug 41943 Author: ktietz Date: Fri Jul 23 18:32:25 2010 New Revision: 162479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162479 Log: 2010-07-23 Kai Tietz kai.ti...@onevision.com PR target/41943 * Makefile.in (USER_H_INC_NEXT_PRE, USER_H_INC_NEXT_POST): New. (stmp-int-hdrs): Prefix/postfix headers by include_next. * config.gcc (user_headers_inc_next_pre): New. (user_headers_inc_next_post): Likewise. (*-w64-mingw*): Use for float.h post-fixing, and for stddef.h/stdarg.h pre-fixing by include_next. * configure.ac (user_headers_inc_next_post): New. (user_headers_inc_next_pre): New. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/config.gcc trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug ada/43731] Missing ada multilib on i686-w64-mingw32 target
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-07-11 09:15 --- Subject: Bug 43731 Author: ktietz Date: Sun Jul 11 09:15:12 2010 New Revision: 162057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162057 Log: 2010-07-11 Kai Tietz kai.ti...@onevision.com Merged back from trunk * config/i386/winnt.c (i386_pe_file_end): Quote symbol name in directive -export. 2010-07-11 Kai Tietz kai.ti...@onevision.com Merged back from trunk PR ada/43731 * gcc-interface/Makefile.in: Add rules for multilib x86/x64 mingw targets. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/ada/ChangeLog branches/gcc-4_5-branch/gcc/ada/gcc-interface/Makefile.in branches/gcc-4_5-branch/gcc/config/i386/winnt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43731
[Bug ada/43731] Missing ada multilib on i686-w64-mingw32 target
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-07-11 09:20 --- Fixed for head and 4.5.1 -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43731
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-06-29 20:24 --- (In reply to comment #5) One possible cause of this problem is that in configuration there could be something going wrong with stat functions returning 32-bit vs 64-bit values. This seems not to be the issue here. sys/stat.h includes sys/types.h, so there is no need to put it in front explicit. The issue is that Windows C-runtimes uses OS buffer File I/O, which means that data will be written just when page-size (4k) is full. By calling _commit, which is like fsync, it is forced that buffer gets physical written to disk. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-06-28 17:27 --- Created an attachment (id=21030) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21030action=view) Patch for mingw x86/x64 targets This patch fixes for me the problem by calling in raw_flush and in buf_flush the '_commit' crt function. It takes care that internal file-data gets written, so that afterwards fstat will get the proper size. PS: Sorry for the whitespace changes, but my editor removes trailing whitespaces automatically (if wished I can remove them for final patch) Regards, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug fortran/44697] I/O testsuite failures: \r\n vs \n - gfortran.dg/ftell_3.f90
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-06-28 17:59 --- Yes, suggested patch works fine for me -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44697
[Bug ada/43731] Missing ada multilib on i686-w64-mingw32 target
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-06-12 13:20 --- Subject: Bug 43731 Author: ktietz Date: Sat Jun 12 13:19:17 2010 New Revision: 160662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160662 Log: 2010-06-12 Kai Tietz PR ada/43731 * gcc-interface/Makefile.in: Add rules for multilib x86/x64 mingw targets. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43731
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-06-09 11:53 --- Fixed by patch at revision 159965. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug testsuite/44159] CPU options cause testsuite failures
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-06-07 10:57 --- Subject: Bug 44159 Author: ktietz Date: Mon Jun 7 10:56:44 2010 New Revision: 160363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160363 Log: 2010-06-07 Kai Tietz kai.ti...@onevision.com PR target/44159 * gcc.target/i386/abi-2.c: Check sysv abi here. * gcc.target/i386/aes-avx-check.h: Call test in noinline function to avoid failures by different ABIs. * gcc.target/i386/aes-check.h: Likewise. * gcc.target/i386/avx-check.h: Likewise. * gcc.target/i386/fma4-check.h: Likewise. * gcc.target/i386/mmx-3dnow-check.h: Likewise. * gcc.target/i386/mmx-check.h: Likewise. * gcc.target/i386/pclmul-avx-check.h: Likewise. * gcc.target/i386/pclmul-check.h: Likewise. * gcc.target/i386/sse-check.h: Likewise. * gcc.target/i386/sse2-check.h: Likewise. * gcc.target/i386/sse3-check.h: Likewise. * gcc.target/i386/sse4_1-check.h: Likewise. * gcc.target/i386/sse4_2-check.h: Likewise. * gcc.target/i386/sse4a-check.h: Likewise. * gcc.target/i386/ssse3-check.h: Likewise. * gcc.target/i386/xop-check.h: Likewise. * gcc.target/i386/pr27971.c: Fix for LLP64. * gcc.target/i386/pr39139.c: Likewise. * gcc.target/i386/pr39315-check.c: Likewise. * gcc.target/i386/vararg-1.c: Likewise. * gcc.target/i386/vararg-2.c: Likewise. Additional add dg-compile to avoid failure due missing foo symbol. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/abi-2.c trunk/gcc/testsuite/gcc.target/i386/aes-avx-check.h trunk/gcc/testsuite/gcc.target/i386/aes-check.h trunk/gcc/testsuite/gcc.target/i386/avx-check.h trunk/gcc/testsuite/gcc.target/i386/fma4-check.h trunk/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h trunk/gcc/testsuite/gcc.target/i386/mmx-check.h trunk/gcc/testsuite/gcc.target/i386/pclmul-avx-check.h trunk/gcc/testsuite/gcc.target/i386/pclmul-check.h trunk/gcc/testsuite/gcc.target/i386/pr27971.c trunk/gcc/testsuite/gcc.target/i386/pr39139.c trunk/gcc/testsuite/gcc.target/i386/pr39315-check.c trunk/gcc/testsuite/gcc.target/i386/sse-check.h trunk/gcc/testsuite/gcc.target/i386/sse2-check.h trunk/gcc/testsuite/gcc.target/i386/sse3-check.h trunk/gcc/testsuite/gcc.target/i386/sse4_1-check.h trunk/gcc/testsuite/gcc.target/i386/sse4_2-check.h trunk/gcc/testsuite/gcc.target/i386/sse4a-check.h trunk/gcc/testsuite/gcc.target/i386/ssse3-check.h trunk/gcc/testsuite/gcc.target/i386/vararg-1.c trunk/gcc/testsuite/gcc.target/i386/vararg-2.c trunk/gcc/testsuite/gcc.target/i386/xop-check.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
[Bug testsuite/44159] CPU options cause testsuite failures
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-06-07 11:09 --- Subject: Bug 44159 Author: ktietz Date: Mon Jun 7 11:08:46 2010 New Revision: 160365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160365 Log: 2010-06-07 Kai Tietz kai.ti...@onevision.com Backport from mainline: PR target/44159 * gcc.target/i386/abi-2.c: Check sysv abi here. * gcc.target/i386/aes-avx-check.h: Call test in noinline function to avoid failures by different ABIs. * gcc.target/i386/aes-check.h: Likewise. * gcc.target/i386/avx-check.h: Likewise. * gcc.target/i386/fma4-check.h: Likewise. * gcc.target/i386/mmx-3dnow-check.h: Likewise. * gcc.target/i386/mmx-check.h: Likewise. * gcc.target/i386/pclmul-avx-check.h: Likewise. * gcc.target/i386/pclmul-check.h: Likewise. * gcc.target/i386/sse-check.h: Likewise. * gcc.target/i386/sse2-check.h: Likewise. * gcc.target/i386/sse3-check.h: Likewise. * gcc.target/i386/sse4_1-check.h: Likewise. * gcc.target/i386/sse4_2-check.h: Likewise. * gcc.target/i386/sse4a-check.h: Likewise. * gcc.target/i386/ssse3-check.h: Likewise. * gcc.target/i386/xop-check.h: Likewise. * gcc.target/i386/pr27971.c: Fix for LLP64. * gcc.target/i386/pr39139.c: Likewise. * gcc.target/i386/pr39315-check.c: Likewise. * gcc.target/i386/vararg-1.c: Likewise. * gcc.target/i386/vararg-2.c: Likewise. Additional add dg-compile to avoid failure due missing foo symbol. * gcc.dg/compound-literal-1.c: Fix for llp64. * gcc.dg/pr32370.c: Likewise. * gcc.dg/pr37561.c: Likewise. * gcc.dg/pr41340.c: Likewise. * gcc.dg/pr41551.c: Likewise. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/compound-literal-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr32370.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr37561.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr41340.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr41551.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/abi-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/aes-avx-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/aes-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/avx-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/fma4-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/mmx-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pclmul-avx-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pclmul-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr27971.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr39139.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr39315-check.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse2-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse3-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse4_1-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse4_2-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse4a-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/ssse3-check.h branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/vararg-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/vararg-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/xop-check.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
[Bug testsuite/44159] CPU options cause testsuite failures
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-06-07 11:09 --- Fixed an 4.5 branch and on mainline. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-05-31 14:07 --- Subject: Bug 44161 Author: ktietz Date: Mon May 31 14:06:41 2010 New Revision: 160070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160070 Log: 2010-05-31 Kai Tietz kai.ti...@onevision.com PR target/44161 * config/i386/cygming.h (SUBTARGET_OVERRIDE_OPTIONS): Handle flag_pic. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 14:11:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-05-31 14:16 --- Subject: Bug 44161 Author: ktietz Date: Mon May 31 14:16:21 2010 New Revision: 160072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160072 Log: 2010-05-31 Kai Tietz kai.ti...@onevision.com Merged from trunk PR target/44161 * config/i386/cygming.h (SUBTARGET_OVERRIDE_OPTIONS): Handle flag_pic. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/cygming.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-05-31 14:17 --- Merged back to 4.5 branch at revision 160072. Fixed. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-05-28 11:19 --- Subject: Bug 44299 Author: ktietz Date: Fri May 28 11:19:41 2010 New Revision: 159965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159965 Log: 2010-05-28 Kai Tietz kai.ti...@onevision.com PR bootstrap/44299 * config/i386/t-cygming: Adjust header dependencies for winnt-cxx.c. * config/i386/winnt-cxx.c (IN_GCC_FRONTEND): Remove undefine. * config/i386/winnt.c (IN_GCC_FRONTEND): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/t-cygming trunk/gcc/config/i386/winnt-cxx.c trunk/gcc/config/i386/winnt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-27 08:14 --- Subject: Bug 44287 Author: ktietz Date: Thu May 27 08:13:58 2010 New Revision: 159912 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159912 Log: gcc/cp/ 2010-05-27 Kai Tietz kai.ti...@onevision.com PR bootstrap/44287 * rtti.c (emit_support_tinfos): Check for NULL_TREE. * class.c (layout_class_type): Likewise. * decl.c (finish_enum): Likewise. * mangle.c (write_builitin_type): Likewise. gcc/ 2010-05-27 Kai Tietz kai.ti...@onevision.com PR bootstrp/44287 * c-lex.c (narrowest_unsigned_type): Check for NULL_TREE. (narrow_signed_type): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/c-lex.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/cp/rtti.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #12 from ktietz at gcc dot gnu dot org 2010-05-27 08:44 --- Fixed on trunk. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug target/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-05-27 09:48 --- Seems to be fixed by side-effect or by weird toolchain. I can't reproduce it anymore, too. So, I close this bug as works-for-me. Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
[Bug c++/44294] [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-27 15:53 --- I saw this regression now for a long time for x86_64-w64-mingw32. Interesting is that it appeared now but not for x86, but I assume code is broken already for a long time. Maybe the code-change I did yesterday exposed this bug. See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02088.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-27 15:53:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
[Bug bootstrap/44299] New: Bootstrap broken for cygwin and mingw targets
gcc -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DNATIVE_C ROSS -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototy pes -Wmissing-format-attribute -Wold-style-definition -fno-common -DHAVE_CONFIG _H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../ gcc/gcc/../libcpp/include -I/home/ktietz/source/gcc-head/buildw64/./gmp -I/home/ ktietz/source/gcc-head/gcc/gmp -I/home/ktietz/source/gcc-head/buildw64/./mpfr -I /home/ktietz/source/gcc-head/gcc/mpfr -I/home/ktietz/source/gcc-head/gcc/mpc/src -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libde cnumber -DCLOOG_PPL_BACKEND-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../. ./gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/ktietz/source/gcc -head/buildw64/./gmp -I/home/ktietz/source/gcc-head/gcc/gmp -I/home/ktietz/sourc e/gcc-head/buildw64/./mpfr -I/home/ktietz/source/gcc-head/gcc/mpfr -I/home/ktiet z/source/gcc-head/gcc/mpc/src -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/. ./libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND \ ../../gcc/gcc/config/i386/winnt-cxx.c In file included from ../../gcc/gcc/config/i386/winnt-cxx.c:25: ../../gcc/gcc/rtl.h:22:9: attempt to use poisoned GCC_RTL_H -- Summary: Bootstrap broken for cygwin and mingw targets Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: i?86-*-cygwin *-*-mingw* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-27 20:41 --- Subject: Bug 44299 Author: ktietz Date: Thu May 27 20:40:48 2010 New Revision: 159949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159949 Log: 2010-05-27 Kai Tietz kai.ti...@onevision.com PR bootstrap/44299 * config/i386/winnt.c (IN_GCC_FRONTEND): Undefine. * config/i386/winnt-cxx.c (IN_GCC_FRONTEND): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt-cxx.c trunk/gcc/config/i386/winnt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-26 19:49 --- Hmm, is here rtti in use? Could you please test following patch, if it solves your bootstrap issue? Kai Index: gcc/gcc/cp/rtti.c === --- gcc.orig/gcc/cp/rtti.c 2010-05-26 17:54:18.0 +0200 +++ gcc/gcc/cp/rtti.c 2010-05-26 21:46:53.066961700 +0200 @@ -1502,6 +1502,8 @@ emit_support_tinfos (void) tree types[3]; int i; + if (bltn == NULL_TREE) + continue; types[0] = bltn; types[1] = build_pointer_type (bltn); types[2] = build_pointer_type (cp_build_qualified_type (bltn, -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-05-26 20:00 ---
(In reply to comment #3)
(In reply to comment #1)
Hmm, is here rtti in use? Could you please test following patch, if it
solves
your bootstrap issue?
Kai
Index: gcc/gcc/cp/rtti.c
===
--- gcc.orig/gcc/cp/rtti.c 2010-05-26 17:54:18.0 +0200
+++ gcc/gcc/cp/rtti.c 2010-05-26 21:46:53.066961700 +0200
@@ -1502,6 +1502,8 @@ emit_support_tinfos (void)
tree types[3];
int i;
+ if (bltn == NULL_TREE)
+ continue;
types[0] = bltn;
types[1] = build_pointer_type (bltn);
types[2] = build_pointer_type (cp_build_qualified_type (bltn,
I don't think so since it also failed in ibgfortran.
hmm, this should be the real reason here.
Index: gcc/gcc/c-lex.c
===
--- gcc.orig/gcc/c-lex.c2010-05-21 20:16:07.0 +0200
+++ gcc/gcc/c-lex.c 2010-05-26 21:58:52.839130300 +0200
@@ -480,7 +480,11 @@ narrowest_unsigned_type (unsigned HOST_W
for (; itk itk_none; itk += 2 /* skip unsigned types */)
{
- tree upper = TYPE_MAX_VALUE (integer_types[itk]);
+ tree upper;
+
+ if (integer_types[itk] == NULL_TREE)
+ continue;
+ upper = TYPE_MAX_VALUE (integer_types[itk]);
if ((unsigned HOST_WIDE_INT) TREE_INT_CST_HIGH (upper) high
|| ((unsigned HOST_WIDE_INT) TREE_INT_CST_HIGH (upper) == high
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #7 from ktietz at gcc dot gnu dot org 2010-05-26 20:45 --- Created an attachment (id=20756) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20756action=view) integer_array can hold now NULL_TREEs for unsupported integer-scalar types integer_array can hold now NULL_TREEs for unsupported integer-scalar types (like __int128). As these new types aren't present for 32-bit hosts (without hardware bit wide interger = 64, this issue occures. This patch addresses those issues. PR/44287 * cp/rtti.c (emit_support_tinfos): Check for NULL_TREE. * cp/class.c (layout_class_type): Likewise. * cp/decl.c (finish_enum): Likewise. * cp/mangle.c (write_builitin_type): Likewise. * c-lex.c (narrowest_unsigned_type): Likewise. Patch already sent to ML. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-05-26 20:49 --- (In reply to comment #7) Instead of integer_array of course integer_types I meant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-05-26 21:09 --- Created an attachment (id=20757) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20757action=view) Updated patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug target/43869] ms_abi - sysv_abi passing float arguments incorrectly
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-05-23 06:52 ---
Subject: Bug 43869
Author: ktietz
Date: Sun May 23 06:51:50 2010
New Revision: 159754
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159754
Log:
2010-05-23 Naarten Lankhorst mlankho...@codeweavers.com
PR target/43869
* gcc.c-target/pr43869.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr43869.c (with props)
Modified:
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/gcc.target/i386/pr43869.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.target/i386/pr43869.c
('svn:mime-type' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug target/43869] ms_abi - sysv_abi passing float arguments incorrectly
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-05-23 06:52 --- Subject: Bug 43869 Author: ktietz Date: Sun May 23 06:52:32 2010 New Revision: 159755 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159755 Log: 2010-05-23 Naarten Lankhorst mlankho...@codeweavers.com PR target/43869 * config/i386/i386.c: Make sure that the correct regparm is passed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug target/43869] ms_abi - sysv_abi passing float arguments incorrectly
--- Comment #7 from ktietz at gcc dot gnu dot org 2010-05-23 06:57 ---
Subject: Bug 43869
Author: ktietz
Date: Sun May 23 06:57:20 2010
New Revision: 159756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159756
Log:
2010-05-23 Naarten Lankhorst mlankho...@codeweavers.com
Merged from trunk
PR target/43869
* config/i386/i386.c: Make sure that the correct regparm is passed.
2010-05-23 Naarten Lankhorst mlankho...@codeweavers.com
Merged from trunk
PR target/43869
* gcc.c-target/pr43869.c: New test.
Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr43869.c (with
props)
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
Propchange: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr43869.c
('svn:eol-style' added)
Propchange: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr43869.c
('svn:mime-type' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug target/43869] ms_abi - sysv_abi passing float arguments incorrectly
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-05-23 07:12 --- Fixed on trunk and back-merged to gcc-4_5 branch. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug libgcj/28263] [win32] Memory Leak In Cleaning Exception Handling Contexts
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-05-23 07:21 --- (In reply to comment #1) This issue is solved for mingw-w64 runtime. It uses no more the mingwm10.dll mechanism. Instead it uses TLS callbacks to implement it. By this reason the Cleaning of Exception Contexts is always present for this runtime. Maybe mingw.org's runtime will support TLS callbacks sometimes, too. This bug remains for Windows OSes without TLS callback support, and for those the -mthreads build-option can solve the issue. The mechanism of TLS callback is now present for mingw.org's runtime too. Even the use of mingwm10.dll for OSes (like 9x/Me) is solved. Additional it isn't anymore of importance to link by -mthread option. The cleaning up is effective now anyway. So I close this bug as invalid, as the solution isn't part of gcc itself. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28263
[Bug target/40905] GCC creates invalid executable with auto-imported DLL and __attribute__((cold))
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-05-23 07:41 --- As there is no feed-back for some time now. I've tested this issue with recent mingw runtimes and the issue is solved. As this isse is related to old pseudo-relocation and linker, and not related to gcc itself, I close this bug as works-for-me. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40905
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #22 from ktietz at gcc dot gnu dot org 2010-05-21 11:28 --- Patch fron comment #14 applied to trunk. Back-port won't be done as there is a risc of emutls-fallout (as Richard mentioned in his approval). Committed at revision 159658. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #18 from ktietz at gcc dot gnu dot org 2010-05-19 09:15 --- Hi David, Could you test the suggested patch for AIX? Richard told me that the patch is sensible, but the attribute merging is something to be tested for AIX. Thanks in advance, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #20 from ktietz at gcc dot gnu dot org 2010-05-19 16:18 --- (In reply to comment #19) What is the relationship between this bug and PR 44132? Richi and Honza seem to prefer the DECL_PRESERVE_P hack. We will see if Iain's lowering works. I don't think both the decl attribute merging patch and DECL_PRESERVE_P patch are needed. I don't see here any relations AFAICS (beside both patches are touching emutls). This declaration preserve flag is fine, but AFAICS don't address this issue. The point here is that w32 targets dependent on original decl-attributes for name-decoration. So Richi asked me, that I ask you, if you could test this patch for AIX to avoid side-effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-18 14:22 --- (In reply to comment #10) Re-opening. It turns out that GCC fails to actually apply the dllexport attribute to TLS control vars. So solving the binutils problem allows auto-export of a TLS variable to work, but as auto-export gets disabled in the presence of any explicit dllexport directives, this isn't an effective solution. I believe the problem needs to be addressed in config/i386/winnt.c#i386_pe_encode_section_info() I have doubts about the approach in winnt.c, but well maybe I am wrong here. I investigated for this issue and see the real issue in declaration cloning in varasm.c's emutls_decl- function, which simply doesn't copy attributes of the delaration, which then leads to issues about name-decoration. Also the DECL_DLLIMPORT_P has to be copied here, too (for import). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-05-18 15:18 ---
Hi Dave,
following patch solves the issue for me pretty well.
ChangeLog
* varasm.c (emutls_decl): Clone attributes for new decl.
Index: gcc/gcc/varasm.c
===
--- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
+++ gcc/gcc/varasm.c2010-05-18 17:10:11.385445300 +0200
@@ -403,6 +403,8 @@ emutls_decl (tree decl)
int foo() { return i; }
__thread int i = 1;
in which I goes from external to locally defined and initialized. */
+ DECL_DLLIMPORT_P (to) = DECL_DLLIMPORT_P (decl);
+ DECL_ATTRIBUTES (to) = targetm.merge_decl_attributes (decl, to);
TREE_STATIC (to) = TREE_STATIC (decl);
TREE_USED (to) = TREE_USED (decl);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug testsuite/44159] CPU options cause testsuite failures
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-17 14:54:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44159
[Bug bootstrap/43900] ICE in dbxout.c
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-04-27 07:52 --- (In reply to comment #2) As it turns out, the ICE only manifests in a parallel build. I tried make -j 8, my default and make -j 3. For an ordinary make there is no issue. So, I'm curious how to handle this. Any thoughts? Rainer Rainer, you are not accidentially are using rxvt terminal? Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43900
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #10 from ktietz at gcc dot gnu dot org 2010-04-24 12:02 ---
So I investigated this issue about mktemp in more detail and found finally the
first-scope and second-scope bug here.
Old logic was opening files and as long as mktemp failed on a second call,
things were working (the re-initialization of the template was missing, so one
of the following calls will failed). As side-effect there were many file
handles generated, which weren't closed.
Tested patch is
Index: unix.c
===
--- unix.c (revision 158676)
+++ unix.c (working copy)
@@ -889,25 +889,26 @@
template = get_mem (strlen (tempdir) + 20);
+#ifdef HAVE_MKSTEMP
sprintf (template, %s/gfortrantmpXX, tempdir);
-#ifdef HAVE_MKSTEMP
-
fd = mkstemp (template);
#else /* HAVE_MKSTEMP */
-
- if (mktemp (template))
-do
+ fd = -1;
+ do
+{
+ sprintf (template, %s/gfortrantmpXX, tempdir);
+ if (!mktemp (template))
+ break;
#if defined(HAVE_CRLF) defined(O_BINARY)
fd = open (template, O_RDWR | O_CREAT | O_EXCL | O_BINARY,
S_IREAD | S_IWRITE);
#else
fd = open (template, O_RDWR | O_CREAT | O_EXCL, S_IREAD | S_IWRITE);
#endif
-while (!(fd == -1 errno == EEXIST) mktemp (template));
- else
-fd = -1;
+}
+ while (fd == -1 errno == EEXIST);
#endif /* HAVE_MKSTEMP */
Ok for applying it to trunk, 4.5, and 4.4?
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #12 from ktietz at gcc dot gnu dot org 2010-04-24 12:25 --- (In reply to comment #11) Yes, OK to commit to trunk. Thanks! Ok, applied to trunk at revision 158686. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-04-22 07:42 --- (In reply to comment #3) My feeling is that, e.g., on Windows this won't work; I do not know whether before the environment variables GFORTRAN_TMPDIR, TMP and TEMP are used or not, but /tmp does exist on many Windows systems. Kai, what's the best way to find out the temporary directory under Windows (MinGW/MinGW64/Cygwin)? And, do you see something obviously wrong with the code in comment 1 (alias http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/io/unix.c;hb=HEAD#l868 ) I would use here the platform API GetTempPath. This seems to be the best solution here. In general TEMP and/or TMP are defined in environment, but they need to be there defined. So This functions should do the proper thing for win32 targets (beside cygwin, as here /tmp/ is of course valid). Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug middle-end/43702] [4.6 regression] FAIL: g++.dg/other/pr35504.C execution test
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-04-12 18:06 --- Committed at revision 158232. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43702
[Bug middle-end/43702] [4.6 regression] FAIL: g++.dg/other/pr35504.C execution test
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-04-09 14:26 --- Suggested fix for this issue posted to ML at http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00426.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-09 14:26:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43702
[Bug target/40905] GCC creates invalid executable with auto-imported DLL and __attribute__((cold))
--- Comment #7 from ktietz at gcc dot gnu dot org 2010-04-05 09:17 --- (In reply to comment #6) I added you to this thread, as you merged new pseudo-relocation code to mingw.org's runtime. As cygwin and mingw.org are supporting now new linker generated runtime-pseudo-relocation, could you please confirm that your issue is solved. I tested your issue and for me it works with recent version of cygwin/mingw.org runtimes. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40905
[Bug target/43524] ICE: in ix86_expand_prologue, at config/i386/i386.c:8636 with -mstack-arg-probe on x86_64-linux
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-03-26 12:14 --- The assert here is just in respect to comment Only valid for Win32.. Just win32 targets are providing for gcc a __chkstk implementation. So I think it was the reason for this assert. But AFAICS there is no other reason for this assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43524
[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-03-23 12:32 --- (In reply to comment #7) An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00937.html Patch is fine. It is absolutely necessary to support gcc's intrinsic headers for mingw. The fixinclude approach is one way to solve it and I am fine by it. For mingw-w64 we used the #pragma push/pop_macro feature to make sure we declare function without getting problems by this define in ia32intrin.h. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
[Bug regression/43356] Wrong code and misleading warning statement with no effect
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-03-14 08:20 --- Correct, the fmod-family was marked as pure, which is obviously wrong. Thanks, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43356
[Bug regression/43356] New: Wrong code and misleading warning statement with no effect
The following code compiled on 4.4.x works without problems, but by using gcc
4.5 it produces for -O0 wrong code, and for -O = 1 correct code but the
strange warning (with -Wall option enabled) 'modf.c:9:1: warning: statement
with no effect.'.
#include stdio.h
#include math.h
int main( void )
{
double d = 10.5;
double i = 100.0;
modf( d, i );
printf( %f %f\n, d, i );
return 0;
}
--
Summary: Wrong code and misleading warning statement with no
effect
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43356
[Bug regression/43356] Wrong code and misleading warning statement with no effect
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-03-13 14:26 --- Created an attachment (id=20100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20100action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43356
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-03-12 08:57 --- The follow-up patch about those collision in enumerator names is posted at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00427.html to gcc's patch-ML. The only issue remaining open for mingw/cygwin targets after this patch is the preprocessor issue, but it has already its own bug-report. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #10 from ktietz at gcc dot gnu dot org 2010-03-08 08:03 --- (In reply to comment #9) Kai, Patch in Comment #8 is OK to commit. Thanks! (I also regression tested on x86-64-linux-gnu.) Ok, applied at revision 157271. Patch for enumerators ERROR, WARNING, SILENT will follow soon. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-03-05 10:04 --- (In reply to comment #5) This patch has a problem about the printf formatter definitions in libgfortran.h header. So I suggest to use the following patch instead. I am current on to bootstrap it completely and test the given testcases by it again. Index: gcc/libgfortran/libgfortran.h === --- gcc.orig/libgfortran/libgfortran.h 2009-12-04 18:22:19.0 +0100 +++ gcc/libgfortran/libgfortran.h 2010-03-05 07:44:41.230103300 +0100 @@ -28,6 +28,15 @@ see the files COPYING3 and COPYING.RUNTI #ifndef LIBGFOR_H #define LIBGFOR_H +/* Ensure that ANSI conform stdio is used. This needs to be set before + any system header file is included. */ +#if defined __MINGW32__ +# define _POSIX 1 +# define gfc_printf gnu_printf +#else +# define gfc_printf __printf__ +#endif + /* config.h MUST be first because it can affect system headers. */ #include config.h @@ -703,15 +712,15 @@ extern void show_locus (st_parameter_com internal_proto(show_locus); extern void runtime_error (const char *, ...) - __attribute__ ((noreturn, format (printf, 1, 2))); + __attribute__ ((noreturn, format (gfc_printf, 1, 2))); iexport_proto(runtime_error); extern void runtime_error_at (const char *, const char *, ...) - __attribute__ ((noreturn, format (printf, 2, 3))); + __attribute__ ((noreturn, format (gfc_printf, 2, 3))); iexport_proto(runtime_error_at); extern void runtime_warning_at (const char *, const char *, ...) - __attribute__ ((format (printf, 2, 3))); + __attribute__ ((format (gfc_printf, 2, 3))); iexport_proto(runtime_warning_at); extern void internal_error (st_parameter_common *, const char *) @@ -795,7 +804,7 @@ extern int unit_to_fd (int); internal_proto(unit_to_fd); extern int st_printf (const char *, ...) - __attribute__ ((format (printf, 1, 2))); + __attribute__ ((format (gfc_printf, 1, 2))); internal_proto(st_printf); extern int st_vprintf (const char *, va_list); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #7 from ktietz at gcc dot gnu dot org 2010-03-05 10:34 ---
(In reply to comment #6)
As by this patch libgfortran.h defines _POSIX, some additional features (at
least for mingw-w64) getting active about localtime_r and gmtime_r (which
getting implemented by defines, if _POSIX is defined). So the following patch
is getting necessary too.
Index: gcc/libgfortran/intrinsics/date_and_time.c
===
--- gcc.orig/libgfortran/intrinsics/date_and_time.c 2009-06-22
09:43:32.0 +0200
+++ gcc/libgfortran/intrinsics/date_and_time.c 2010-03-05 11:14:39.200103300
+0100
@@ -55,6 +55,11 @@ see the files COPYING3 and COPYING.RUNTI
thread-local storage so they are threadsafe. */
#ifndef HAVE_LOCALTIME_R
+/* If _POSIX is defined localtime_r gets defined by mingw-w64 headers. */
+#ifdef localtime_r
+#undef localtime_r
+#endif
+
static struct tm *
localtime_r (const time_t * timep, struct tm * result)
{
@@ -64,6 +69,11 @@ localtime_r (const time_t * timep, struc
#endif
#ifndef HAVE_GMTIME_R
+/* If _POSIX is defined gmtime_r gets defined by mingw-w64 headers. */
+#ifdef gmtime_r
+#undef gmtime_r
+#endif
+
static struct tm *
gmtime_r (const time_t * timep, struct tm * result)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-03-06 07:21 --- Created an attachment (id=20034) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=view) Patch about printf and POSIX float conversion 2010-03-06 Kai TIetz kai.ti...@onevision.com PR/42950 * libgfortran.h (_POSIX): Define if __MINGW32__ is defined. (gfc_printf): Define to gnu_printf for __MINGW32__ case, otherwise to __printf__. (gfc_strtof,gfc_strtod,gfc_strtold): Define for mingw case to POSIX compatible converter functions. (runtime_error): Use instead gfc_printf as formatter attribute name. (runtime_error_at): Likewise. (runtime_warning_at): Likewise. (st_printf): Likewise. * intrinsics/date_and_time.c (localtime_r): Undefine possible defined macro. (gmtime_r): Likewise. * io/read.c (convert_real): Use gfc_strtof, gfc_strtod, and gfc_strtold. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #16 from ktietz at gcc dot gnu dot org 2010-02-04 08:47 --- (In reply to comment #15) Any further word on this? As I said in comment #14, we fixed a strict-aliasing bug in our C runtime related to POSIX printf. As I tested it with current runtime, result looks ok to me. It isn't an alignment issue, and neiter it was a gcc-bug. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug libgomp/42829] TLS detection in ./configure is wrong.
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-01-23 10:35 --- Yes, I can confirm this issue, but want to investigate where the underlying issue really comes from. The interesting issue I found is, that if a TLS-variable isn't assigned, the values of the addresses in different threads are equal. As soon as one thread initialize the variable in program flow (not by initializing the global __thread variable), everthing works as expected. Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42829
[Bug objc/42293] Can't build ObjC runtime library with GC for W32 target
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-12-18 15:53 --- In mingw-w64 headers we do the following #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) #define BOOL WINBOOL #endif For local build for obj-c we use a patched objc.h defining __OBJC_BOOL. This worked for use building it. Maybe this is a general solution for this? Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42293
[Bug objc/42293] Can't build ObjC runtime library with GC for W32 target
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-12-08 11:41 --- (In reply to comment #3) Created an attachment (id=19235) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19235action=view) [edit] Diff file This allows me to compile it, but quoting from windef.h: /* FIXME: Is there a good solution to this? */ Well, this issue is known to me. Changing the order here can work-a-round it, but possibly leads to other issues, as windef.h will redefine it. In mingw-w64 platform headers we worked-a-round this by checking for __OBJC__ to check, if we shouldn't define BOOL. But of course this also just a hack. The real issue for w32/w64 targets is, that type BOOL is part of the platform header API definition, which conflicts here. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42293
[Bug preprocessor/41943] include search path composition is bogus
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-12-06 11:47 ---
By rethinking this issue I came to the point that this would lead to pretty
havy incompatibilities between -pc-mingw32 and -w64-mingw32. Also it would
disallow to use the default /usr/local prefix for installtion without setting
up a sysroot.
So I think to change gcc.c here is the better variant and fixes both venture
targets here. As win32 paths are pretty unique for native windows targets, I
think this patch here is minimal intrusive for *nix targets.
Index: gcc/gcc/gcc.c
===
--- gcc.orig/gcc/gcc.c 2009-11-26 17:37:26.0 +0100
+++ gcc/gcc/gcc.c 2009-12-06 12:37:38.21319 +0100
@@ -2900,8 +2900,11 @@
{
if (!IS_ABSOLUTE_PATH (prefix))
fatal (system path '%s' is not absolute, prefix);
-
- if (target_system_root)
+ if (target_system_root
+#if HAVE_DOS_BASED_FILE_SYSTEM == 1
+ (!prefix[0] || prefix[1] != ':')
+#endif
+ )
{
if (target_sysroot_suffix)
prefix = concat (target_sysroot_suffix, prefix, NULL);
I tested this patch and it seems to do what you expects it should do.
Cheers,
Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-11-29 20:47:06 |2009-12-06 11:47:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug preprocessor/41943] include search path composition is bogus
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-12-06 20:01 --- Well, this patch doesn't hurt in gcc.c, but doesn't solve the issue. Sorry for posting this. incpath.c is the location to investigate in. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-12-05 18:16 --- hmm, I still don't see in gcc's root in libtool.m4 the patch for detecting x64_64 archives. Did I miss here something? Cheers, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-12-05 18:31 --- I meant in libtool.m4, too: We have here: mingw* | pw32*) # Base MSYS/MinGW do not provide the 'file' command needed by # func_win32_libid shell function, so use a weaker test based on 'objdump', # unless we find 'file', for example because we are cross-compiling. # func_win32_libid assumes BSD nm, so disallow it if using MS dumpbin. if ( test $lt_cv_nm_interface = BSD nm file / ) /dev/null 21; then lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' lt_cv_file_magic_cmd='func_win32_libid' else lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?' lt_cv_file_magic_cmd='$OBJDUMP -f' fi ;; But well, this is not about library, so my fault. It is about shared libraries. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-12-05 19:21 --- (In reply to comment #4) Subject: Re: libtool fails to detect pe-x86-64 import library * ktietz at gcc dot gnu dot org wrote on Sat, Dec 05, 2009 at 07:16:12PM CET: hmm, I still don't see in gcc's root in libtool.m4 the patch for detecting x64_64 archives. Did I miss here something? The patch in #1 is in ltmain.sh. Did you mean another patch? What I missed to say. Many thanks for your hard work. I think we can close this bug, can't we? Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
[Bug preprocessor/41943] include search path composition is bogus
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-12-03 21:56 --- Would it be a solution (at least for -w64- targets) to remove the sys-root/mingw part and default to sysroot/include sysroot/lib instead. At least for the -w64- targets there is no real need of this /mingw subfolder. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug preprocessor/41943] include search path composition is bogus
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-29 20:47:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
[Bug target/40786] Windows %I32 format confusion
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-10-30 17:52 --- Well, I meant of course 4.4 branch. I won't backport this. So I closed this bug. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40786
[Bug bootstrap/41709] Failing bootstrap in stage 2 while building Ada + C
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-10-30 17:57 --- (In reply to comment #1) gcc-4.5-20091008 snapshot was used. By the way, gcc-4.4.2-RC-20091008 works fine. Could you please give us your configuration line? We do bootstraps (until Stage 3) with current 4.5 gcc without issues. Therefore I assume that your issue is related to your configure, or that you missed to pre-install runtime and/or headers, or binutils isn't present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41709
[Bug target/41799] __enable_execute_stack introduced for mingw32 in r134089 doesn't work for kernel-mode components
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-10-27 17:16 --- Applied to trunk at revision 153606. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41799
[Bug target/41799] __enable_execute_stack introduced for mingw32 in r134089 doesn't work for kernel-mode components
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-10-26 19:24 --- Patch post at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01577.html to ML -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41799
[Bug target/41799] __enable_execute_stack introduced for mingw32 in r134089 doesn't work for kernel-mode components
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-10-23 17:59 --- Created an attachment (id=18882) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18882action=view) Patch for enable for mingw32 targets -fset-stack-executable Changelog * config/i386/mingw32.h (CHECK_EXECUTE_STACK_ENABLED): New macro. * config/i386/mingw.opt: Add fset-stack-executable. * config/i386/i386.c (ix86_trampoline_init): Make call to emit_library_call conditional, if CHECK_EXECUTE_STACK_ENABLED is defined and its value is not zero. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41799
[Bug target/41799] __enable_execute_stack introduced for mingw32 in r134089 doesn't work for kernel-mode components
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-22 20:04:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41799
[Bug target/32187] Complex __float128 is rejected
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-09-27 09:25 --- The new attribute basetype_mode (see http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could provide a way to solve this, as it makes sure that it is associated to the base type, instead of the current type declaration as mode attribute does. by defining __float128 as '#define __float128 float __attribute__ ((basetype_mode(DF)))' Constructs like '__complex__ DFtype z;' getting handled proper, too. Maybe this is a way to solve this issue. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug target/32187] Complex __float128 is rejected
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-27 09:28 --- (In reply to comment #7) The new attribute basetype_mode (see http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could provide a way to solve this, as it makes sure that it is associated to the base type, instead of the current type declaration as mode attribute does. by defining __float128 as '#define __float128 float __attribute__ ((basetype_mode(DF)))' Constructs like '__complex__ DFtype z;' getting handled proper, too. Err, I meant here of course '__complex__ __float128 z;' Maybe this is a way to solve this issue. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug target/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-27 09:59 --- Closed this bug. As it is solved. At least provide testcase doesn't ice with native gcc for w64 anymore. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug other/41234] Configure fails to find non-existent g++ preprocessor flag with syntax errors
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-27 10:03 --- I tested given scenario and g++ could find the headers in Stage 2 (using msys make). So this seems to be a configure/environment setup issue, if it still exists for you. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41234
[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-21 17:33:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
