[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 --- Comment #8 from Kai Tietz --- Hmm, that behavior of gcc seems to be indeed pretty bad. The SEH commands for registers above index 15 (0..15) for xmm? are indeed undefined, and even worse, can't be coded proper into the seh table correctly. Anything above 16-byte size of ?mm registers, and anything above register index 15 has to be treated as call clobbered. But in anycase, the unwind information has not to contain that information
[Bug target/56186] [4.8 regression] function return ABI change for 128-bit types on Win64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56186 --- Comment #1 from Kai Tietz 2013-02-04 16:37:51 UTC --- Author: ktietz Date: Mon Feb 4 16:37:44 2013 New Revision: 195721 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195721 Log: PR target/56186 * config/i386/i386.c (function_value_ms_64): Add additional valtype argument and improve checking of return-argument types for 16-byte modes. (ix86_function_value_1): Add additional valtype argument on call of function_value_64. (return_in_memory_ms_64): Sync 16-byte sized mode handling with handling infunction_value_64 function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/56186] [4.8 regression] function return ABI change for 128-bit types on Win64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56186 Kai Tietz changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Kai Tietz 2013-02-04 16:39:48 UTC --- Fixed.
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 --- Comment #8 from Kai Tietz 2013-02-06 12:01:32 UTC --- Author: ktietz Date: Wed Feb 6 12:01:20 2013 New Revision: 195803 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195803 Log: 2013-02-06 Rainer Emrich PR target/52123 * adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via SECURITY_DESCRIPTOR * (__gnat_set_OWNER_ACL): Cast from DWORD to ACCESS_MODE (__gnat_portable_spawn): Fix cast to char* const* (add_handle): Cast from pointer via void ** (add_handle): Cast from pointer via int * (__gnat_locate_exec_on_path): Cast from pointer via TCHAR * (__gnat_locate_exec_on_path): Cast from pointer via char * * initialize.c (append_arg): Cast from pointer via LPWSTR (__gnat_initialize): Cast from pointer via LPWSTR * seh_init.c (__gnat_map_SEH): Cast from pointer via FARPROC Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/adaint.c trunk/gcc/ada/initialize.c trunk/gcc/ada/seh_init.c
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 --- Comment #11 from Kai Tietz 2013-02-07 10:15:42 UTC --- (In reply to comment #9) > Adding some CCs. The two changes about using HOST_LONG_LONG_FORMAT are fine. The use of HOST_WIDE_INT_PRINT_HEX_PURE in lto/lto.c is indeed wrong. The internal_error function uses %wx instead (AFAICS).
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 --- Comment #10 from Kai Tietz 2013-02-12 15:27:45 UTC --- Well, I re-tried to reproduce this issue with current 4.8 gcc version (native). As before, I can't reproduce that issue. Anyway I don't get what report was actual doing differently as I did, so I will keep this bug open. Nevertheless we had recently some changes to lto, which are affecting mingw targets, so it might be worth that report are retrying to reproduce. Please make sure that you aren't mixing objects with LTO-infomration of different versions.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #15 from Kai Tietz 2013-02-12 15:32:15 UTC --- Author: ktietz Date: Tue Feb 12 15:32:01 2013 New Revision: 195980 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195980 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: trunk/libada/ChangeLog trunk/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #16 from Kai Tietz 2013-02-12 15:37:09 UTC --- Author: ktietz Date: Tue Feb 12 15:36:56 2013 New Revision: 195981 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195981 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_7-branch/libada/ChangeLog branches/gcc-4_7-branch/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #17 from Kai Tietz 2013-02-12 15:39:07 UTC --- Author: ktietz Date: Tue Feb 12 15:38:57 2013 New Revision: 195982 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195982 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_6-branch/libada/ChangeLog branches/gcc-4_6-branch/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Kai Tietz changed: What|Removed |Added Priority|P2 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2013-02-12 Ever Confirmed|0 |1 --- Comment #18 from Kai Tietz 2013-02-12 15:44:07 UTC --- So required patch is applied to 4.6 branch , 4.7 branch, and trunk. Issue is fixed. As reminder I will keep this bug in status waiting, so we don't miss to remove this patch as soon as libtool got updated.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #20 from Kai Tietz 2013-02-12 18:02:56 UTC --- Hmm, why is NS_RECURSIVE for you an empty? It should become either cp -pR, or be equal to content of LN_S.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #21 from Kai Tietz 2013-02-12 18:04:53 UTC --- "LN_S_RECURSIVE" I mean.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Kai Tietz changed: What|Removed |Added Priority|P5 |P2 Status|WAITING |NEW --- Comment #29 from Kai Tietz 2013-02-13 10:03:41 UTC --- I reverted patch. But still have no idea what was actual going wrong here.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #32 from Kai Tietz 2013-02-13 10:19:35 UTC --- Author: ktietz Date: Wed Feb 13 10:19:26 2013 New Revision: 196002 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196002 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: trunk/libada/ChangeLog trunk/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #33 from Kai Tietz 2013-02-13 10:20:49 UTC --- Author: ktietz Date: Wed Feb 13 10:20:30 2013 New Revision: 196003 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196003 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_7-branch/libada/ChangeLog branches/gcc-4_7-branch/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #34 from Kai Tietz 2013-02-13 10:21:35 UTC --- Author: ktietz Date: Wed Feb 13 10:21:25 2013 New Revision: 196004 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196004 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_6-branch/libada/ChangeLog branches/gcc-4_6-branch/libada/Makefile.in
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 --- Comment #11 from Kai Tietz 2013-02-14 08:45:16 UTC --- Author: ktietz Date: Thu Feb 14 08:45:09 2013 New Revision: 196046 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196046 Log: 2013-02-14 Rainer Emrich PR target/52123 * adaint.c (__gnat_check_OWNER_ACL): Cast from pointer via SECURITY_DESCRIPTOR *. (__gnat_set_OWNER_ACL): Cast from DWORD to ACCESS_MODE. (__gnat_portable_spawn): Fix cast to char* const*. (add_handle): Cast from pointer via void **. (add_handle): Cast from pointer via int *. (__gnat_locate_exec_on_path): Cast from pointer via TCHAR *. (__gnat_locate_exec_on_path): Cast from pointer via char *. * initialize.c (append_arg): Cast from pointer via LPWSTR. (__gnat_initialize): Cast from pointer via LPWSTR. * seh_init.c (__gnat_SEH_error_handler): Cast from pointer via FARPROC. * tracebak.c: Cast from pointer via FARPROC. Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/adaint.c branches/gcc-4_7-branch/gcc/ada/initialize.c branches/gcc-4_7-branch/gcc/ada/seh_init.c branches/gcc-4_7-branch/gcc/ada/tracebak.c
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 --- Comment #12 from Kai Tietz 2013-02-14 13:04:15 UTC --- Author: ktietz Date: Thu Feb 14 13:04:10 2013 New Revision: 196051 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196051 Log: 2013-02-14 Rainer Emrich PR target/52123 * tracebak.c: Cast from pointer via FARPROC. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/tracebak.c
[Bug c/56465] New: Strange warning about variable modified range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56465 Bug #: 56465 Summary: Strange warning about variable modified range Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: kti...@gcc.gnu.org The following code produces warning, but it is actual a constant. typedef __SIZE_TYPE__ size_t; char _buf[(size_t) ((char *) 0 + sizeof (size_t))]; t_arr.c:3:1: Warnung: variabel modifiziertes »_buf« im Dateibereich [standardmäßig aktiviert] char _buf[(size_t) ((char *) 0 + sizeof (size_t))]; ^
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475
--- Comment #3 from Kai Tietz 2013-02-27 19:45:53
UTC ---
(In reply to comment #1)
> We had an AC_TRY_RUN test, but such kind of test give a lot of problems and we
> removed it. We had:
>
> AC_TRY_RUN([#include
> int main()
> {
> return !(fopen("/dev/random", "r")
> && fopen("/dev/urandom", "r"));
> }
> ],
> [ac_random_tr1=yes], [ac_random_tr1=no],
> [ac_random_tr1=no])
> ])
>
> Kai, can you suggest something working on MinGW and not using an AC_TRY_RUN?
> Or
> you can just special case MinGW. I have no way of testing such fixes, sorry.
Well, AC_TRY_RUN is for sure the wrong approach here. As such tests are
failing badly on cross-compilers.
I think sanest way to solve this is by special-casing mingw targets.
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475
--- Comment #6 from Kai Tietz 2013-02-28 08:43:30
UTC ---
(In reply to comment #4)
> I agree. Care to send a patch for that?
Well, something like this should fix the issue:
Index: acinclude.m4
===
--- acinclude.m4(Revision 196329)
+++ acinclude.m4(Arbeitskopie)
@@ -1739,7 +1739,10 @@ AC_DEFUN([GLIBCXX_CHECK_RANDOM_TR1], [
AC_MSG_CHECKING([for "/dev/random" and "/dev/urandom" for TR1
random_device])
AC_CACHE_VAL(glibcxx_cv_random_tr1, [
if test -r /dev/random && test -r /dev/urandom; then
- glibcxx_cv_random_tr1=yes;
+ case ${target_os} in
+ *mingw*) glibcxx_cv_random_tr1=no ;;
+ *) glibcxx_cv_random_tr1=yes ;;
+ esac
else
glibcxx_cv_random_tr1=no;
fi
[Bug c/56465] Strange warning about variable modified range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56465 --- Comment #2 from Kai Tietz 2013-02-28 15:56:09 UTC --- (In reply to comment #1) > >it is actual a constant. > > I don't think it is a integer constant expression though as it contains a cast > from a pointer type to an integer type. Well, it isn't a integer scalar, but still a constant.
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #8 from Kai Tietz 2013-03-01 10:23:28 UTC --- Author: ktietz Date: Fri Mar 1 10:23:21 2013 New Revision: 196371 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196371 Log: PR libstdc++/56475 * acinclude.m4 (GLIBCXX_CHECK_RANDOM_TR1): Disable check for mingw-targets. * configure: Regenerated. Modified: trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Kai Tietz 2013-03-01 10:27:05 UTC --- Fixed on trunk.
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #6 from Kai Tietz 2013-03-03 10:29:42 UTC --- Yes, patch looks reasonable. Please sent it to patch ML. This patch is small, so it is ok, but do you have already made paper-work with FSF for gcc?
[Bug bootstrap/56644] --disable-nls requires symbols from libintl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #3 from Kai Tietz 2013-03-20 06:59:33 UTC --- This looks like a duplicate of PR/54659. Which snapshort-date you are using of 4.8 gcc?
[Bug preprocessor/56686] gcc cannot find include header file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||WORKSFORME --- Comment #3 from Kai Tietz 2013-03-22 06:53:17 UTC --- Sorry can't reproduce your issue. I tested it with 4.6 up to 4.8 gcc version 'gcc -c -o t.o subsub/t.c -I.' without issues. I assume it might be caused that your working-directory isn't at TopDir, but in SubDir on compilation of your code. You can verify that by adding -I.. as option.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #3 from Kai Tietz 2013-03-25 08:20:59 UTC --- Issue is an old one ... I had even posted already a patch for this subject. See as reference http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00033.html link. The only way to solve this in a sane way is by moving it into C namespace for C++.
[Bug rtl-optimization/56719] missed optimization: i > 0xffff || i*4 > 0xffff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz 2013-03-25 11:41:15 UTC --- 0x3fff is wrong as 0x3fff * 4 is just 0xfffc. So proper optimization here is i > 0x3fffu. That is a missed opportunity in VRP.
[Bug c++/56742] New: Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
Bug #: 56742
Summary: Optimization bug lead to uncaught throw
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org
Target: x86_64-w64-mingw32, x86_64-pc-cygwin
Hi,
the following testcase:
#include
static int main_worker(int argc)
{
std::string s[32]; // [31] => no segfault
if (argc < 2)
throw 42;
return argc;
}
int main(int argc, char **argv)
{
try {
return main_worker(argc);
}
catch (int i) {
return i;
}
}
produces with optimization -O2 on execution the message:
"terminate called after throwing an instance of 'int'"
and abort gets called.
If compiled with optimization level -O1, execution works as expected.
[Bug c++/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 Kai Tietz changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-26 Ever Confirmed|0 |1 Known to fail||4.8.0
[Bug c++/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
--- Comment #2 from Kai Tietz 2013-03-26 21:14:23
UTC ---
Hmm, yes indeed it is the -freorder-blocks option. One solution is to disallow
after reload for SEH-target to modify jumps.
The following patch fixes the issue for me.
Index: i386.c
===
--- i386.c (Revision 197118)
+++ i386.c (Arbeitskopie)
@@ -3941,6 +3941,19 @@
register_pass (&insert_vzeroupper_info);
}
+/* Implement TARGET_CANNOT_MODIFY_JUMPS_P. */
+static bool
+ix86_cannot_modify_jumps_p (void)
+{
+ if (TARGET_SEH && reload_completed
+ && cfun)
+return true;
+ return false;
+}
+
+#undef TARGET_CANNOT_MODIFY_JUMPS_P
+#define TARGET_CANNOT_MODIFY_JUMPS_P ix86_cannot_modify_jumps_p
+
/* Update register usage after having seen the compiler flags. */
static void
[Bug c++/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
--- Comment #4 from Kai Tietz 2013-03-27 09:40:16
UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Hmm, yes indeed it is the -freorder-blocks option. One solution is to
> > disallow after reload for SEH-target to modify jumps.
>
> That's an awfully big hammer. Perhaps it's possible to first analyze
> what is actually happening in bbreorder that causes this bug?
Well, the issue is analyzed. The issue is that SEH is table-based EH, and so
after bb-reorder used labels for describing eh-regions are getting invalid.
If you take a look to the produces assembly for the example, you will notice
that easily.
I admit that the first patch is a bit too invasive, as it disables bb-reorder
in all cases. But in fact we need to disable it just if there is a
catch-region. A more improved variant is:
Index: i386.c
===
--- i386.c (Revision 197118)
+++ i386.c (Arbeitskopie)
@@ -3941,6 +3941,20 @@
register_pass (&insert_vzeroupper_info);
}
+/* Implement TARGET_CANNOT_MODIFY_JUMPS_P. */
+static bool
+ix86_cannot_modify_jumps_p (void)
+{
+ if (TARGET_SEH && reload_completed
+ && cfun && cfun->eh
+ && cfun->eh->region_tree)
+return true;
+ return false;
+}
+
+#undef TARGET_CANNOT_MODIFY_JUMPS_P
+#define TARGET_CANNOT_MODIFY_JUMPS_P ix86_cannot_modify_jumps_p
+
/* Update register usage after having seen the compiler flags. */
static void
[Bug rtl-optimization/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 --- Comment #6 from Kai Tietz 2013-03-27 14:43:24 UTC --- Well, this issue is related to SEH exceptions. So it is pretty clear, why you don't see it for linux. It is serious bug for 4.8 gcc. From user's perspective this is a regression. Technical it is a bug in bb-reorder for SEH. For 4.8 I think the above patch is the lowest invasive way to fix it. For trunk we might be able to use an approach as dw2 uses here. Not sure about later. I will discuss with Richard Henderson.
[Bug rtl-optimization/56742] [4.8 regression] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 Kai Tietz changed: What|Removed |Added Target Milestone|--- |4.8.1 Summary|Optimization bug lead to|[4.8 regression] |uncaught throw |Optimization bug lead to ||uncaught throw
[Bug c++/56761] Error: CreateProcess: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56761 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||WORKSFORME --- Comment #3 from Kai Tietz 2013-03-28 09:25:25 UTC --- (In reply to comment #2) > There is no header in standard C++, so any code written in the > last 15 years should not try to use it. Nor is there such a header in mingw. Not sure where you get things from, but all in all it sounds to me like you are invoking the wrong binaries. Do you call the executable in sysroot/bin, or that from sysroot/i686-pc-mingw32/bin, or those from sysroot/mingw/bin ? Anyway please report such issues on mingw.org's ML.
[Bug target/52790] Problems using x86_64-w64-mingw-w32-gfortran with mcmodel=large and medium
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52790 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Kai Tietz 2013-04-03 08:07:41 UTC --- This bug is fixed on trunk (upcoming 4.9). The patch won't be backported.
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 --- Comment #3 from Kai Tietz 2013-04-08 06:51:58 UTC --- Hmm, this bug looks like a duplicate of PR/56742 Could you test if provided patch in PR/56742 fixes your issue?
[Bug middle-end/56932] New: [regression 4.8]: vrp and/or niter-related wrong-code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932
Bug #: 56932
Summary: [regression 4.8]: vrp and/or niter-related wrong-code
bug
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org
The following testcase triggers this wrong code-bug.
int a[250];
__attribute__ ((noinline))
t(int i)
{
if (i==0)
exit(0);
if (i>255)
abort ();
}
main()
{
unsigned int i;
for (i=0;;i++)
{
a[i]=t((i+5)&0xff);
}
}
It fails with vrp-pass enabled. The issue is that overflow of (i+5)&0xff isn't
detected correct.
This test is related to existing testcase pr/55875 in gcc.c-torture/execute.
[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932 --- Comment #4 from Kai Tietz 2013-04-12 18:31:05 UTC --- Well, indeed increasing the array-size helps to avoid this issue. Nevertheless I don't get why it produces wrong code for argument of call of function t here. That there is a out-of-bounds access is one thing, but there is still wrong code produced. Also why - if gcc already detects an out-of-bounds access - there is no warning for that?
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz 2013-04-16 09:37:38 UTC --- Hmm, as this bug seems not to happen for mingw 32-bit, it might be related to definition of DEFAULT_ABI for 32-bit. Does it help to set in cygming.h header the line '#define DEFAULT_ABI (TARGET_64BIT ? MS_ABI : SYSV_ABI)' to '#define DEFAULT_ABI (TARGET_64BIT ? MS_ABI : MS_ABI)' ? If so, we need an new definition to indicate pe-coff ABI instead. At some places we are using here check DEFAULT_ABI == MS_ABI etc, which might cause for 32-bit here the issue. See for example the code in predicate.md, i386.c, etc.
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 --- Comment #5 from Kai Tietz 2013-04-18 18:19:28 UTC --- Created attachment 29898 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29898 Patch for supporting cygwin32's SYSV_ABI proper This patch should fix the reported issue.
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 --- Comment #7 from Kai Tietz 2013-04-19 08:18:13 UTC --- At what place it freezes? Can you provide a testcase? Are you sure it is really related to the patch? What makes you think that? All in all, what I mean about those questions is that it isn't helpful to tell such statements without even trying to narrow it down to its reason.
[Bug target/55445] Always defined __SEH__ when build from trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55445 --- Comment #5 from Kai Tietz 2013-04-23 07:25:49 UTC --- *** Bug 57040 has been marked as a duplicate of this bug. ***
[Bug target/57040] SEH Exception defined is conflicted with SJLJ Exception within several files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57040 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Kai Tietz 2013-04-23 07:25:49 UTC --- This issue is a dup. It seems that Ada is the only code-path still having this error, but anyway it isn't helpful to open n-times a bug report for the same issue. *** This bug has been marked as a duplicate of bug 55445 ***
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Kai Tietz 2013-04-30 10:33:59 UTC --- Hmm, I can't reproduce that. I just built things myself again for 4.8.1 gcc. I am a bit curious to read that due distributions like Fedora seem to be able to build stuff without isssues for 4.8.x gcc. First advice would be to look into libstdc++'s config.log to see why for you shared library isn't built. Second question is how you are actual configuring it, and what additional patches you might use on built?
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Kai Tietz 2013-04-30 10:42:28 UTC --- No this change wasn't hastily nor wrong. Actual the change makes things compliant to logic already used for cygwin for years. Additional it fixed a quirk there was about eh-code sometimes not using shared version, if it actual was necessary to. The point is, if you want to avoid dependency to DLL libgcc version, then please use support static option for it. Otherwise you might get dependencies to the shared version, and there is nothing wrong about that. I admit that some functions might be added to shared version, which would be for pe-coff better be placed into the pure static part of libgcc. But well that is an enhancment issue and not a bug.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-30 Ever Confirmed|0 |1 --- Comment #7 from Kai Tietz 2013-04-30 11:00:13 UTC --- Hmm, only issue I see is the use of '--disable-nls' option, which is known to cause issue. See here PR 54659. Another question I have is, what mingw-w64 header-set,crt you are using? You will need for >= 4.8.x gcc version actual trunk version. I looked through the config.log and don't see anything showing that shared-version doesn't work, so I assume the underlying issue you see is PR 54659.
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Kai Tietz 2013-04-30 11:03:30 UTC --- Would you please stop to change status? As I said, change is intended, it is no regression, it is actual a fix. In maximum it is a difference in behavior.
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 --- Comment #5 from Kai Tietz 2013-04-30 13:34:25 UTC --- (In reply to comment #4) > libgcc_s_sjlj-1.dll export the following symbos: > > [Ordinal/Name Pointer] Table > [ 0] _Unwind_Backtrace > [ 1] _Unwind_DeleteException > [ 2] _Unwind_FindEnclosingFunction > [ 3] _Unwind_Find_FDE > [ 4] _Unwind_GetCFA > [ 5] _Unwind_GetDataRelBase > [ 6] _Unwind_GetGR > [ 7] _Unwind_GetIP > [ 8] _Unwind_GetIPInfo > [ 9] _Unwind_GetLanguageSpecificData > [ 10] _Unwind_GetRegionStart > [ 11] _Unwind_GetTextRelBase > [ 12] _Unwind_SetGR > [ 13] _Unwind_SetIP > [ 14] _Unwind_SjLj_ForcedUnwind > [ 15] _Unwind_SjLj_RaiseException > [ 16] _Unwind_SjLj_Register > [ 17] _Unwind_SjLj_Resume > [ 18] _Unwind_SjLj_Resume_or_Rethrow > [ 19] _Unwind_SjLj_Unregister > [ 20] __absvdi2 > [ 21] __absvsi2 > [ 22] __addtf3 > [ 23] __addvdi3 > [ 24] __addvsi3 > [ 25] __ashldi3 > [ 26] __ashrdi3 > [ 27] __bswapdi2 > [ 28] __bswapsi2 > [ 29] __clear_cache > [ 30] __clrsbdi2 > [ 31] __clrsbsi2 > [ 32] __clzdi2 > [ 33] __clzsi2 > [ 34] __cmpdi2 > [ 35] __ctzdi2 > [ 36] __ctzsi2 > [ 37] __deregister_frame > [ 38] __deregister_frame_info > [ 39] __deregister_frame_info_bases > [ 40] __divdc3 > [ 41] __divdi3 > [ 42] __divsc3 > [ 43] __divtc3 > [ 44] __divtf3 > [ 45] __divxc3 > [ 46] __emutls_get_address > [ 47] __emutls_register_common > [ 48] __enable_execute_stack > [ 49] __eqtf2 > [ 50] __extenddftf2 > [ 51] __extendsftf2 > [ 52] __extendxftf2 > [ 53] __ffsdi2 > [ 54] __ffssi2 > [ 55] __fixdfdi > [ 56] __fixsfdi > [ 57] __fixtfdi > [ 58] __fixtfsi > [ 59] __fixunsdfdi > [ 60] __fixunsdfsi > [ 61] __fixunssfdi > [ 62] __fixunssfsi > [ 63] __fixunstfdi > [ 64] __fixunstfsi > [ 65] __fixunsxfdi > [ 66] __fixunsxfsi > [ 67] __fixxfdi > [ 68] __floatdidf > [ 69] __floatdisf > [ 70] __floatditf > [ 71] __floatdixf > [ 72] __floatsitf > [ 73] __floatundidf > [ 74] __floatundisf > [ 75] __floatunditf > [ 76] __floatundixf > [ 77] __floatunsitf > [ 78] __gcc_personality_sj0 > [ 79] __getf2 > [ 80] __gttf2 > [ 81] __letf2 > [ 82] __lshrdi3 > [ 83] __lttf2 > [ 84] __moddi3 > [ 85] __muldc3 > [ 86] __muldi3 > [ 87] __mulsc3 > [ 88] __multc3 > [ 89] __multf3 > [ 90] __mulvdi3 > [ 91] __mulvsi3 > [ 92] __mulxc3 > [ 93] __negdi2 > [ 94] __negtf2 > [ 95] __negvdi2 > [ 96] __negvsi2 > [ 97] __netf2 > [ 98] __paritydi2 > [ 99] __paritysi2 > [ 100] __popcountdi2 > [ 101] __popcountsi2 > [ 102] __powidf2 > [ 103] __powisf2 > [ 104] __powitf2 > [ 105] __powixf2 > [ 106] __register_frame > [ 107] __register_frame_info > [ 108] __register_frame_info_bases > [ 109] __register_frame_info_table > [ 110] __register_frame_info_table_bases > [ 111] __register_frame_table > [ 112] __subtf3 > [ 113] __subvdi3 > [ 114] __subvsi3 > [ 115] __trunctfdf2 > [ 116] __trunctfsf2 > [ 117] __trunctfxf2 > [ 118] __ucmpdi2 > [ 119] __udivdi3 > [ 120] __udivmoddi4 > [ 121] __umoddi3 > [ 122] __unordtf2 > > If I use unwind-sjlj.rc (unwind-seh.rc, or unwind-dw2.rc) to make sure > libgcc_s_sjlj-1.dll only export _Unwind_* symbols, is it acceptable ? No, actual all functions about Unwind, emutls, and register (deregister) have to be part of the DLL. The math-functions here might be candidates for the pure static-version only.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #12 from Kai Tietz 2013-04-30 13:49:25 UTC --- Hmm, I don't see in config.log any difference to the variant I have built on my box. Shared is actual enabled in you config.log for libstdc++-v3. So DLL should be built, if you don't have a build error. For me 32-bit and 64-bit w64 version builds OOTB without any issue. You are building multilib as I see, so do you have 32-bit and 64-bit setuped too? Could you check if there is for real no dll built by executing within your libstdc++-v3 build-directory the command 'find ./* -name "*.dll" -print'?
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-08 Ever Confirmed|0 |1 --- Comment #4 from Kai Tietz 2013-05-08 14:26:30 UTC --- (In reply to comment #3) > CC-ing Kai. Yes, patch looks reasonable. Indeed we had here a hick-up of changes and it gets fixed by this. I am ok by this change
[Bug libstdc++/57212] Don't use pe-coff weak support with mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57212 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Kai Tietz 2013-05-08 19:20:35 UTC --- Ok, done. Applied to trunk, and 4.8 branch. So I close this bug as fixed.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3 from Kai Tietz 2013-05-08 19:47:20
UTC ---
Well, I see that this symbol is part of our libmingwex.a library on trunk. For
gcc 4.8 and above it is recommented to use 3.0 runtime-version for w64.
I assume you are using 2.x crt version and having 3.x headers.
A simple test for checking what mingw-w64 runtime you are using in fact is by
compiling the following code and execute it:
#include
int main()
{
printf ("%s\n", __mingw_get_crt_info ());
return 0;
}
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 Kai Tietz changed: What|Removed |Added CC|ktietz70 at googlemail dot | |com | --- Comment #4 from Kai Tietz 2013-05-08 19:49:53 UTC --- I don't need it twice
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #6 from Kai Tietz 2013-05-08 20:04:56 UTC --- Fine, by which date this version was built? I am pretty curious to see that issue for 4.9 due I don't happen to see it on my box. Could you check, if libmingwex.a contains for you the symbol in question? For me $ x86_64-w64-mingw32-nm.exe /usr/local/x86_64-w64-mingw32/lib/libmingwex.a | grep -e "__mingw_strtod" displays: T __mingw_strtod and shows symbol is present.
[Bug libstdc++/57220] [mingw] Undefined reference to __mingw_strtod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57220 --- Comment #8 from Kai Tietz 2013-05-08 21:02:08 UTC --- Well, you should us the nm tool to check for existance of a symbol. Grepping for strings might lead you to wrong direction. I don't see anything obviously wrong on you temp-file. The only thing I am a bit confused about is that there seems to be a 4.7.2 directory used for crtend object ... so it looks to me that you might be still using two different runtimes and mixing stuff here happily. I just did a rebuild of all required stuff and I can't reproduce this issue. The options you've shown initially have for sure nothing to do with link-order, or about use of libraries.
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Kai Tietz --- Fixed.
[Bug target/48233] [4.6] can't bootstrap with ada, java and go on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48233 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Kai Tietz --- go language isn't supported for mingw targets (see PR/47726). The other languages should work with newer gcc versions. gcc 4.6 isn't no longer maintained, so I close this bug.
[Bug libstdc++/56332] libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #8 from Kai Tietz --- There is no such triplet x86_64-pc-mingw64 support.
[Bug ada/47163] Failure building target-libada for MingW64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47163 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Kai Tietz --- The remaining issue about LN -s is also mentioned in PR/52122 report. So I close this bug as fixed.
[Bug target/52122] [4.7/4.8/4.9 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #38 from Kai Tietz --- Due 4.6 is closed, and bug was fixed for 4.7 and upward, I close this bug. Please report issue for DJGPP as separate bug, if problem still exists.
[Bug other/41400] unwind table not properly populated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41400 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Kai Tietz --- This issue is fixed back atleast to gcc 4.7, so I close this bug as fixed.
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-15 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Kai Tietz --- Yes, this happens for function using eax as input-argument hand using stack-allocation. btw it isn't specific to chkstk_ms function. I will take a look
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-10 Ever Confirmed|0 |1 --- Comment #9 from Kai Tietz 2012-09-10 11:45:36 UTC --- (In reply to comment #8) > I think we should identify when this changed and why. Then, we can certainly > add the export (please send a regular patch to the library mailing list) but > at > a new minor version, thus CXXABI_1.3.7. The issue was exposed by trunc's new feature for PECOFF to place readonly-data with relocation into the .rdata section. Interesting that this wasn't noticed before, but to add _[_]ZTC* to gnu.ver fixes the issue.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #14 from Kai Tietz 2012-09-26 20:09:16
UTC ---
(In reply to comment #13)
> Hey P, I think you mean:
>
> diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
> b/libstdc++-v3/config/abi/pre/g
> index 5265b21..396feec 100644
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -1322,6 +1322,7 @@ GLIBCXX_3.4.17 {
> } GLIBCXX_3.4.16;
>
> GLIBCXX_3.4.18 {
> +
>global:
>
> # Names inside the 'extern' block are demangled names.
> @@ -1330,6 +1331,9 @@ GLIBCXX_3.4.18 {
>std::random_device::*;
> };
>
> +# construction vtable
> +_ZTCSt*;
> +
> } GLIBCXX_3.4.17;
>
> # Symbols in the support library (libsupc++) have their own tag.
>
>
> ie, not in CXXABI for std:: non-support things.
>
> This is an interesting thread thanks for the info Kai, very informative. The
> analysis looks good and patch looks correct, modulo above.
>
> Anyway, i have to add this export to gnu-versioned as well, so if it's ok with
> you I'll check in this modified patch along with the gnu-versioned-namespace
> one.
Sure, I am fine by your modified patch. Thanks to you Benjamin, and Paolo for
the patch.
[Bug middle-end/43672] Not compiled Qt library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43672 Kai Tietz changed: What|Removed |Added Status|WAITING |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Kai Tietz 2010-12-17 20:42:35 UTC --- Sorry, I assume as you didn't reported any updates for this bug, that your issue is already solved. Without gcc version and at least preprocessed source of the file producing the ICE you mentioned, there is no chance to investigate this bug. So I close this bug as invalid.
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834 --- Comment #13 from Kai Tietz 2010-12-18 10:16:16 UTC --- Author: ktietz Date: Sat Dec 18 10:16:13 2010 New Revision: 168019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168019 Log: 2010-12-18 Kai Tietz PR target/36834 * config/i386/i386.c (ix86_keep_aggregate_return_pointer): New local function. (ix86_return_pops_args): Use ix86_keep_aggregate_return_pointer function instead of KEEP_AGGREGATE_RETURN_POINTER. (ix86_handle_callee_pop_aggregate_return): New handler. (ix86_attribute_table): Add new attribute callee_pop_aggregate_return. * doc/extend.texi (callee_pop_aggregate_return): Add attribute documentation. 2010-12-18 Kai Tietz PR target/36834 * gcc.target/i386/aggregate-ret1.c: New. * gcc.target/i386/aggregate-ret2.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/aggregate-ret1.c trunk/gcc/testsuite/gcc.target/i386/aggregate-ret2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog
[Bug target/36834] structure return ABI for windows targets differs from native MSVC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834 Kai Tietz changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Known to fail|| --- Comment #14 from Kai Tietz 2010-12-18 10:38:11 UTC --- By this new attribute functions can be explicit marked to use VC compatible aggregate return pointer handling. I don't plan to backmerge this fix to 4.5.x tree, so I close this bug as fixed for 4.6 tree. For 4.7 there is planned to introduce for mingw 32-bit target the callabi MS_ABI/SYSV_ABI (as it is already present for 64-bit mingw target). This will then automatically switch on MS specific calling convention changes - eg ms-bitfield, caller-pops-aggregate-return, and co.
[Bug fortran/46917] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46917 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz 2010-12-21 15:15:23 UTC --- I can't confirm this ICE. My gcc is 4.6.0 20101215. Maybe this issue was already fixed.
[Bug bootstrap/47055] "make profiledbootstrap" fails on MSYS/mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47055 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz 2010-12-23 21:36:44 UTC --- Well, this bug seems to happen by the generation of the gcov_list, which seems to have the habit to always prefix full-pathnames by a slash ... Anayway, you can work-a-round this issue by setting environment variable GCOV_PREFIX_STRIP to 1 and setting GCOV_PREFIX to "m:/".
[Bug c++/15774] Conflicting function decls not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15774 --- Comment #7 from Kai Tietz 2010-12-25 10:41:09 UTC --- Author: ktietz Date: Sat Dec 25 10:41:05 2010 New Revision: 168241 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168241 Log: 2010-12-25 Kai Tietz PR c++/15774 * decl.c (decls_match): Check for FUNCTION_DECL also for identity of compatible attributes. ChangeLog gcc/testsuite 2010-12-25 Kai Tietz PR c++/15774 * g++.dg/warn/pr15774-1.C: New test. * g++.dg/warn/pr15774-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/pr15774-1.C trunk/gcc/testsuite/g++.dg/warn/pr15774-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/47055] "make profiledbootstrap" fails on MSYS/mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47055
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.27 10:27:32
AssignedTo|unassigned at gcc dot |ktietz at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Kai Tietz 2010-12-27 10:27:32
UTC ---
Patch sent to ML
Index: libgcov.c
===
--- libgcov.c (revision 168240)
+++ libgcov.c (working copy)
@@ -283,7 +283,7 @@
}
}
/* Update complete filename with stripped original. */
- if (!IS_DIR_SEPARATOR (*fname))
+ if (!IS_DIR_SEPARATOR (*fname) && !HAS_DRIVE_SPEC(fname))
{
strcpy (gi_filename_up, "/");
strcpy (gi_filename_up + 1, fname);
[Bug testsuite/47050] gcc.target/i386/aggregate-ret[12].c FAIL with -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47050 --- Comment #1 from Kai Tietz 2010-12-30 11:51:18 UTC --- Author: ktietz Date: Thu Dec 30 11:51:14 2010 New Revision: 168339 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168339 Log: 2010-12-30 Kai Tietz PR testsuite/47050 * gcc.target/i386/aggregate-ret1.c: Restrict to ilp32. * gcc.target/i386/aggregate-ret2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/aggregate-ret1.c trunk/gcc/testsuite/gcc.target/i386/aggregate-ret2.c
[Bug testsuite/47050] gcc.target/i386/aggregate-ret[12].c FAIL with -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47050 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Kai Tietz 2010-12-30 11:53:05 UTC --- Fixed on trunk at revision 168339.
[Bug target/38662] __fastcall confuses a function's throw() specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38662 Kai Tietz changed: What|Removed |Added Status|NEW |ASSIGNED CC||ktietz at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ktietz at gcc dot gnu.org |gnu.org | --- Comment #2 from Kai Tietz 2010-12-31 16:06:35 UTC --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02016.html
[Bug target/38662] __fastcall confuses a function's throw() specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38662 --- Comment #3 from Kai Tietz 2011-01-01 11:05:45 UTC --- Author: ktietz Date: Sat Jan 1 11:05:41 2011 New Revision: 168389 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168389 Log: ChangeLog gcc/ 2011-01-01 Kai Tietz PR target/38662 * tree.c (type_hash_eq): Call language hook for METHOD_TYPEs, too. ChangeLog gcc/cp 2011-01-01 Kai Tietz PR target/38662 * tree.c (cxx_type_hash_eq): Allow METHOD_TYPE, too. ChangeLog gcc/testsuite 2011-01-01 Kai Tietz PR target/38662 * g++.dg/eh/pr38662.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/eh/pr38662.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug target/38662] __fastcall confuses a function's throw() specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38662 Kai Tietz changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Kai Tietz 2011-01-01 11:20:15 UTC --- I don't intend to back-merge this patch to 4.5.x branch. So bug closed.
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #14 from Kai Tietz 2011-01-02 14:05:53 UTC --- Well, this bug is configure/environment related and not a bug of gcc AFAICS. So I close this as invalid.
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #7 from Kai Tietz 2011-01-02 14:29:18
UTC ---
(In reply to comment #3)
> I'm not sure if [basic.link] paragraph 5 means S::f should have external
> linkage or not. Paragraph 4 (third bullet) means that S has external linkage.
> Paragraph 5 refers to the name of the class and in this case the class has no
> name, but it has the typedef name for linkage purposes. I'm not sure if that
> means S::f should or should not have external linkage.
As far as I understand specificiation (C++ Standard - ANSI ISO IEC 14882 2003)
3.5 Program and linkage 3 Basic concepts
--- an object or reference that is explicitly declared const and neither
explicitly declared extern nor
previously declared to have external linkage; or
--- a data member of an anonymous union.
4 A name having namespace scope has external linkage if it is the name of
--- an object or reference, unless it has internal linkage; or
--- a function, unless it has internal linkage; or
--- a named class (clause 9), or an unnamed class defined in a typedef
declaration in which the class has the
typedef name for linkage purposes (7.1.3); or
--- a named enumeration (7.2), or an unnamed enumeration defined in a typedef
declaration in which the
enumeration has the typedef name for linkage purposes (7.1.3); or
--- an enumerator belonging to an enumeration with external linkage; or
--- a template, unless it is a function template that has internal linkage
(clause 14); or
--- a namespace (7.3), unless it is declared within an unnamed namespace.
5 In addition, a member function, static data member, class or enumeration of
class scope has external linkage
if the name of the class has external linkage.
7.1.3
...
If the typedef declaration defines an unnamed class (or enum), the first
typedef-name declared by the declaration
to be that class type (or enum type) is used to denote the class type (or enum
type) for linkage purposes
only (3.5).
[Example:]
typedef struct { } *ps, S; // S is the class name for linkage purposes
[end example]
...
So S becomes here class name and the class S has external linkage. So member
functions of it, too. Just explicit constructor/destructors aren't possible
here, as S() would be a normal method and needs a return type.
Kai
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with "cannot check for file existence when cross compiling"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz 2011-01-03 13:32:53 UTC --- This issue breaks cross-compile for me on cygwin
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with "cannot check for file existence when cross compiling"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #3 from Kai Tietz 2011-01-03 14:18:45 UTC --- The issue here is AC_CHECK_FILE, which is documented to not work for cross-compiling scenario. By replacing this to test -f, it should working for native and cross-compile. The following patch should solve this. I can't regenerate at the moment the configure for testing. I'll do it later this eveing at home. But maybe someone else could check it before. Index: configure.ac === --- configure.ac(revision 168422) +++ configure.ac(working copy) @@ -343,9 +343,12 @@ # Check for docbook AC_CHECK_PROG([XSLTPROC], xsltproc, yes, no) AC_CHECK_PROG([XMLLINT], xmllint, yes, no) -AC_CHECK_FILE([/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION], - [glibcxx_stylesheets=yes], [glibcxx_stylesheets=no]) +glibcxx_stylesheets=no; +if test -f /usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION; then + glibcxx_stylesheets=yes; +fi + # Check for xml/html dependencies. AM_CONDITIONAL(BUILD_XML, test $ac_cv_prog_DOXYGEN = "yes" &&
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with "cannot check for file existence when cross compiling"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #4 from Kai Tietz 2011-01-03 14:46:05 UTC --- (In reply to comment #3) > The issue here is AC_CHECK_FILE, which is documented to not work for > cross-compiling scenario. By replacing this to test -f, it should working for > native and cross-compile. > The following patch should solve this. I can't regenerate at the moment the > configure for testing. I'll do it later this eveing at home. But maybe someone > else could check it before. > Sorry had a typo with semicolon ... Index: configure.ac === --- configure.ac(revision 168422) +++ configure.ac(working copy) @@ -343,9 +343,12 @@ # Check for docbook AC_CHECK_PROG([XSLTPROC], xsltproc, yes, no) AC_CHECK_PROG([XMLLINT], xmllint, yes, no) -AC_CHECK_FILE([/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION], - [glibcxx_stylesheets=yes], [glibcxx_stylesheets=no]) +glibcxx_stylesheets=no; +if test -f /usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION; then + glibcxx_stylesheets=yes; +fi + # Check for xml/html dependencies. AM_CONDITIONAL(BUILD_XML, test $ac_cv_prog_DOXYGEN = "yes" &&
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with "cannot check for file existence when cross compiling"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #10 from Kai Tietz 2011-01-04 13:28:11 UTC --- (In reply to comment #9) > Kai, in order to help people actually using cross-compilation a lot, please > install your patchlet. Actual patch pre-approved. Then we can figure out > something better... Ok, I'll do. It will do so in a couple of hours as I don't have at office proper autoconf tools version (and for some stupid reasons I am not able to install it here).
[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with "cannot check for file existence when cross compiling"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #13 from Kai Tietz 2011-01-04 17:59:45 UTC --- Author: ktietz Date: Tue Jan 4 17:59:39 2011 New Revision: 168474 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168474 Log: 2011-01-04 Kai Tietz PR libstdc++/47145 * configure.ac (AC_CHECK_FILE): Replaced by test -f. * configure: Regenerated. Unbreaking cross-compiling ... Modified: trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac
[Bug bootstrap/47055] "make profiledbootstrap" fails on MSYS/mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47055 --- Comment #3 from Kai Tietz 2011-01-04 18:05:11 UTC --- Author: ktietz Date: Tue Jan 4 18:05:06 2011 New Revision: 168475 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168475 Log: 2011-01-04 Kai Tietz PR bootstrap/47055 * libgcov.c (gcov_exit): Check for HAS_DRIVE_SPEC. Modified: trunk/gcc/ChangeLog trunk/gcc/libgcov.c
[Bug bootstrap/47055] "make profiledbootstrap" fails on MSYS/mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47055 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Kai Tietz 2011-01-04 18:06:30 UTC --- Fixed
[Bug c++/47211] ICE: in cp_build_addr_expr_1, at cp/typeck.c:4866 with -fms-extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47211 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz 2011-01-07 15:25:52 UTC --- Just one question here about this scenario you've shown. Is this valid code in VC, or is your issue here the assert and missing diagnostic message?
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 --- Comment #3 from Kai Tietz 2011-01-07 19:48:18 UTC --- I am just about to test a patch for this. Java misses to build some type-nodes, which are necessary for building the va_list type. It seems so that unsigned_type_node is the culprit here.
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 --- Comment #5 from Kai Tietz 2011-01-07 21:11:52 UTC --- Author: ktietz Date: Fri Jan 7 21:11:48 2011 New Revision: 168585 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168585 Log: 2011-01-07 Kai Tietz PR bootstrap/47215 * decl.c (java_init_decl_processing): Initialize unsigned_type_node. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/decl.c
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Kai Tietz 2011-01-07 21:14:14 UTC --- Fixed.
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #4 from Kai Tietz 2011-01-08 20:55:20
UTC ---
Well, the issue here seems to be that in should_emit_struct_debug
TYPE_STUB_DECL (type) for provided type is a NULL_TREE. In next two
if-statements this result is used unconditionally. I am not sure if the
underlying issue is related to some other place in c++ FE (I assume so), but
following patch at least avoid segfault.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 168601)
+++ dwarf2out.c (working copy)
@@ -620,12 +620,14 @@
return DUMP_GSTRUCT (type, usage, criterion, generic, false, true);
type_decl = TYPE_STUB_DECL (type);
+ if (type_decl != NULL_TREE)
+{
+ if (criterion == DINFO_STRUCT_FILE_SYS && DECL_IN_SYSTEM_HEADER
(type_decl))
+ return DUMP_GSTRUCT (type, usage, criterion, generic, false, true);
- if (criterion == DINFO_STRUCT_FILE_SYS && DECL_IN_SYSTEM_HEADER (type_decl))
-return DUMP_GSTRUCT (type, usage, criterion, generic, false, true);
-
- if (matches_main_base (DECL_SOURCE_FILE (type_decl)))
-return DUMP_GSTRUCT (type, usage, criterion, generic, true, true);
+ if (matches_main_base (DECL_SOURCE_FILE (type_decl)))
+ return DUMP_GSTRUCT (type, usage, criterion, generic, true, true);
+}
return DUMP_GSTRUCT (type, usage, criterion, generic, false, false);
}
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 --- Comment #8 from Kai Tietz 2011-01-10 16:23:23 UTC --- Issue here is that s390 uses for its va_list_node_type a record containing long_integer_type_node type, which doesn't get initialized by java's decl.c
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 --- Comment #9 from Kai Tietz 2011-01-11 12:06:38 UTC --- Patch already posted at http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00575.html
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 --- Comment #10 from Kai Tietz 2011-01-11 14:51:17 UTC --- Author: ktietz Date: Tue Jan 11 14:51:07 2011 New Revision: 168662 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168662 Log: 2011-01-11 Kai Tietz PR bootstrap/47215 * decl.c (java_init_decl_processing): Initialize long_integer_type_node. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/decl.c
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 Kai Tietz changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Kai Tietz 2011-01-11 14:55:23 UTC --- Fixed. Hope there is no other missing type-node ...
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209 --- Comment #6 from Kai Tietz 2011-01-12 17:02:51 UTC --- Author: ktietz Date: Wed Jan 12 17:02:41 2011 New Revision: 168718 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168718 Log: 2011-01-12 Kai Tietz PR debug/47209 * dwarfout2.c (should_emit_struct_debug): Use TYPE_MAIN_VARIANT of type. 2011-01-12 Kai Tietz PR debug/47209 * g++.dg/debug/pr47209.C: New. Added: trunk/gcc/testsuite/g++.dg/debug/pr47209.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/47209] ICE: SIGSEGV in should_emit_struct_debug (dwarf2out.c:627) with -f{no-,}emit-struct-debug-{baseonly,reduced} -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47209 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Kai Tietz 2011-01-12 17:06:15 UTC --- Fixed.
[Bug c++/47213] ICE: SIGSEGV in determine_visibility (decl2.c:2076) with -fvisibility-ms-compat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47213 --- Comment #1 from Kai Tietz 2011-01-13 20:02:01 UTC --- Author: ktietz Date: Thu Jan 13 20:01:57 2011 New Revision: 168763 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168763 Log: 2011-01-13 Kai Tietz PR c++/47213 * g++.dg/ext/pr47213.C: New. 2011-01-13 Kai Tietz PR c++/47213 * cp-tree.h (CLASSTYPE_VISIBILITY): Use TYPE_MAIN_DECL instead of TYPE_NAME. (CLASSTYPE_VISIBILITY_SPECIFIED): Likewise. * decl2.c (determine_visibility): Add check of CLASS_TYPE_P for underlying_type. 2011-01-13 Kai Tietz PR c++/47213 * config/i386/cygming.h (TARGET_ASM_ASSEMBLE_VISIBILITY): PE specific hook. * config/i386/i386-protos.h (i386_pe_assemble_visibility): New function prototype. * config/i386/winnt.c (i386_pe_assemble_visibility): Warn only if attribute was specified by user. Added: trunk/gcc/testsuite/g++.dg/ext/pr47213.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/winnt.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47213] ICE: SIGSEGV in determine_visibility (decl2.c:2076) with -fvisibility-ms-compat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47213 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Kai Tietz 2011-01-13 20:05:18 UTC --- Fixed.
