[Bug c++/95317] New: [7 regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317
Bug ID: 95317
Summary: [7 regression] ICE on valid C++14 code, in
tsubst_copy, at cp/pt.c:15649
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
ICE on valid C++14 code:
$ cat b.C
#include
template
struct num
{
enum { value = I };
};
#define VALUEOFNUM(x) std::remove_reference_t::value
template
void foo()
{
auto test = [&](auto i)
{
enum { VALUE = VALUEOFNUM(i) };
std::cout << VALUE;
};
test(num<0>());
test(num<1>());
}
int main()
{
foo();
}
$ g++-9 b.C
b.C: In instantiation of 'void foo() [with TYPE = void]':
b.C:27:15: required from here
b.C:18:22: internal compiler error: in tsubst_copy, at cp/pt.c:15649
18 | std::cout << VALUE;
| ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/Homebrew/homebrew-core/issues> for instructions.
Works fine with GCC up to version 6, but regresses at 7 and later.
[Bug c++/95321] New: Run-time crash on valid destructor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95321
Bug ID: 95321
Summary: Run-time crash on valid destructor code
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
// Run-time crash with g++ >= 9 and -Ox, x > 1
// Works perfectly with g++ <= 8.3
class IDestroyable
{
protected:
virtual void Destroy() = 0;
public:
void operator delete (void * ptr)
{
if (ptr != nullptr) static_cast(ptr)->Destroy();
}
};
class IToto
{
public:
virtual void Toto() = 0;
};
class ITotoDestroyable : public IToto, public IDestroyable
{
public:
void operator delete (void * ptr)
{
if (ptr != nullptr) delete static_cast(static_cast(ptr));
}
};
template
class DestroyableBase : public INTERFACE
{
protected:
virtual void Destroy()
{
::delete this;
}
public:
virtual ~DestroyableBase()
{
}
void operator delete (void * ptr)
{
::operator delete (ptr);
}
};
#include
class TotoDestroyable : public DestroyableBase
{
public:
~TotoDestroyable()
{
std::cout << "OK Destroyed !\n";
}
void Toto()
{
std::cout << "Toto !\n";
}
};
int main()
{
ITotoDestroyable * foo = new TotoDestroyable();
// Uncomment to workaround the crash
// foo->Toto();
delete foo;
}
Segfaults at runtime when compiled with G++ >= 9 and -O1 or higher.
Process 52619 launched: '/tmp/a.out' (x86_64)
Process 52619 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x00010d44 a.out`main [inlined] IDestroyable::operator
delete(ptr=0x000100604858) at a.cpp:11:70
8public:
9void operator delete (void * ptr)
10 {
-> 11 if (ptr != nullptr) static_cast(ptr)->Destroy();
12 }
13 };
14
[Bug c++/95321] Run-time crash on valid destructor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95321 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Francois-Xavier Coudert --- I don't have certainty it's not undefined behaviour, sorry. Closing.
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #16 from Francois-Xavier Coudert --- There is a case in our testsuite that is exercising this check: gcc.c-torture/execute/2603-1.c It was kept in the testsuite because "the exact DR resolution is as yet unclear but it seems very likely that the modified version will be considered OK" https://gcc.gnu.org/legacy-ml/gcc-patches/2004-02/msg00498.html Either this is OK, and the bug should be reconfirmed/unsuspended. Or the test case should be removed from the GCC testsuite.
[Bug fortran/96947] New: _gfortran_caf_fail_image called with wrong number of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947 Bug ID: 96947 Summary: _gfortran_caf_fail_image called with wrong number of arguments Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- Take the source code gfortran.dg/coarray_fail_st.f90 The tree dump shows that _gfortran_caf_fail_image() is called with one argument: _gfortran_caf_fail_image (0B); This call is generated in gfc_trans_fail_image(), which passes a NULL pointer: if (flag_coarray == GFC_FCOARRAY_LIB) return build_call_expr_loc (input_location, gfor_fndecl_caf_fail_image, 1, build_int_cst (pchar_type_node, 0)); But the prototype for the function in libgfortran is clear that it takes no argument: void _gfortran_caf_fail_image (void) __attribute__ ((noreturn)); I do not know which way this should be fixed. It creates runtime issues with coarrays on aarch64-apple-darwin20.
[Bug fortran/96947] _gfortran_caf_fail_image called with wrong number of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Francois-Xavier Coudert --- Fixed on trunk.
[Bug target/96968] aarch64 : ICE in vregs pass lowering __builtin_aarch64_get_fpcr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #1 from Francois-Xavier Coudert --- Exact same issue also occurs with __builtin_aarch64_get_fpsr(). With __builtin_aarch64_get_fpsr64() and __builtin_aarch64_get_fpcr64(), I get "error: unrecognizable insn" at -O0, and "internal compiler error: Segmentation fault" at -O1.
[Bug libbacktrace/96971] New: libbacktrace identifies object format as pecoff instead of macho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96971 Bug ID: 96971 Summary: libbacktrace identifies object format as pecoff instead of macho Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- This is happening on the current port of GCC to aarch64-apple-darwin20 (https://github.com/iains/gcc-darwin-arm64/issues/25) but I believe the issue is more general. The file format detection is done by running the libbacktrace/filetype.awk AWK script on an object file, generated by the compiler. During a bootstrap on aarch64-apple-darwin20, I see a weird behaviour: ../../ibin/libbacktrace/config.log:libbacktrace_cv_sys_filetype=pecoff ../../ibin/prev-libbacktrace/config.log:libbacktrace_cv_sys_filetype=macho ../../ibin/stage1-libbacktrace/config.log:libbacktrace_cv_sys_filetype=macho so the stage 3 libbacktrace is getting pecoff instead of macho. Yet, it is a correct macho object file, with the right signature: $ xxd /tmp/conftest.17440.o : cffa edfe 0c00 0001 0100 0010: 0400 3804 0020 8 .. 0020: 1900 b803 0030: 0040: 2c02 5804 ,...X... 0050: 2802 0700 0700 (... 0060: 0b00 5f5f 7465 7874 __text.. 0070: 5f5f 5445 5854 __TEXT.. 0080: 0090: 5804 X... 00a0: 0080 00b0: 5f5f 7465 7874 5f73 __text_s 00c0: 7461 7274 7570 5f5f 5445 5854 tartup..__TEXT.. 00d0: 00e0: 0800 5804 0400 X... 00f0: 0004 0080 0100: 5f5f 636f 6d6d 6f6e __common 0110: 5f5f 4441 5441 __DATA.. 0120: 2802 (... 0130: 0400 0200 0140: 0100 0150: 5f5f 6465 6275 675f __debug_ 0160: 696e 666f 5f5f 4457 4152 4600 info__DWARF. 0170: 0800 0180: ed00 6004 `... 0190: 8006 0300 0002 01a0: 5f5f 6465 6275 675f __debug_ 01b0: 6162 6272 6576 5f5f 4457 4152 4600 abbrev..__DWARF. 01c0: f500 01d0: 5700 4d05 W...M... 01e0: 0002 01f0: 5f5f 6465 6275 675f __debug_ 0200: 7075 626e 616d 6573 5f5f 4457 4152 4600 pubnames__DWARF. 0210: 4c01 L... 0220: 2700 a405 '... 0230: 0002 0240: 5f5f 6465 6275 675f __debug_ 0250: 7075 6274 7970 6573 5f5f 4457 4152 4600 pubtypes__DWARF. 0260: 7301 s... 0270: 1a00 cb05 0280: 0002 0290: 5f5f 6465 6275 675f __debug_ 02a0: 6172 616e 6765 7300 5f5f 4457 4152 4600 aranges.__DWARF. 02b0: 8d01 02c0: 3000 e505 0... 02d0: 9806 0100 0002 02e0: 5f5f 6465 6275 675f __debug_ 02f0: 6c69 6e65 5f5f 4457 4152 4600 line__DWARF. 0300: bd01 0310: 4a00 1506 J... 0320: a006 0100 0002 0330: 5f5f 6465 6275 675f __debug_ 0340: 7374 7200 5f5f 4457 4152 4600 str.__DWARF. 0350: 0702 0360:
[Bug libbacktrace/96973] New: No backtrace for cc1 on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973 Bug ID: 96973 Summary: No backtrace for cc1 on x86_64-apple-darwin Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- On x86_64-apple-darwin, internal errors in the compiler are not displaying backtraces. For example this code: $ cat ../../z1.f90 program p type ta integer :: a end type type t type(ta), pointer :: b end type type(t) :: z data z / t(ta(1)) / end is giving me: $ ./f951 ../../z1.f90 p main Analyzing compilation unit f951: internal compiler error: in record_reference, at cgraphbuild.c:64 libbacktrace could not find executable to open The message about not finding an executable is from fileline.c in fileline_initialize(). There, it's trying to find the executable in several steps. - state->filename is NULL - getexecname() is not available on darwin - the /proc filesystem is not either - the BSD-specific function sysctl_exec_name() is not present either I am wondering how this is supposed to work. Probably state->filename should be set in the first place.
[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #1 from Francois-Xavier Coudert ---
Continuing to debug, I've added a darwin-specific implementation of
getexecname() with this patch:
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index cc1011e8b5d..3e4161e47c6 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -47,8 +47,23 @@ POSSIBILITY OF SUCH DAMAGE. */
#include "internal.h"
#ifndef HAVE_GETEXECNAME
+#if __APPLE__
+#include
+
+char execname_buf[10240];
+
+static const char *
+getexecname (void)
+{
+ unsigned size = sizeof(execname_buf);
+
+ _NSGetExecutablePath(execname_buf, &size);
+ return execname_buf;
+}
+#else
#define getexecname() NULL
#endif
+#endif
#if !defined (HAVE_KERN_PROC_ARGS) && !defined (HAVE_KERN_PROC)
@@ -192,6 +207,7 @@ fileline_initialize (struct backtrace_state *state,
abort ();
}
+ printf("libbacktrace filename = %s\n", filename ? filename : "NULL");
if (filename == NULL)
continue;
Sadly, this is not enough. This is leading to another error:
rmeur /tmp/ibin/gcc $ ./f951 ../../z1.f90
p main
Analyzing compilation unit
f951: internal compiler error: in record_reference, at cgraphbuild.c:64
libbacktrace filename = NULL
libbacktrace filename = /private/tmp/ibin/gcc/./f951
f951: internal compiler error: Bus error: 10
libbacktrace filename = NULL
libbacktrace filename = /private/tmp/ibin/gcc/./f951
Internal compiler error: Error reporting routines re-entered.
libbacktrace filename = NULL
libbacktrace filename = /private/tmp/ibin/gcc/./f951
The backtrace (provided by lldb) for this new error is:
* frame #0: 0x0001013c1fff
f951`backtrace_free_locked(state=0x000142fd3000, addr=0x000144e94410,
size=5450529520) at mmap.c:104:15
frame #1: 0x0001013c21f4 f951`backtrace_alloc(state=0x000142fd3000,
size=25872, error_callback=(f951`::bt_err_callback(void *, const char *, int)
at diagnostic.c:552:3), data=0x7ffeefbff26c) at mmap.c:152:3
frame #2: 0x0001013c1572 f951`macho_add(state=0x000142fd3000,
filename="/usr/local/opt/isl/lib/libisl.22.dylib", descriptor=5, offset=0,
match_uuid=0x, base_address=5415538688, skip_symtab=0,
error_callback=(f951`::bt_err_callback(void *, const char *, int) at
diagnostic.c:552:3), data=, fileline_fn=0x7ffeefbfe858,
found_sym=0x7ffeefbfe854) at macho.c:575:6
frame #3: 0x0001013c1d11
f951`backtrace_initialize(state=0x000142fd3000,
filename="/tmp/ibin/gcc/f951", descriptor=5,
error_callback=(f951`::bt_err_callback(void *, const char *, int) at
diagnostic.c:552:3), data=0x7ffeefbff26c, fileline_fn=0x7ffeefbfe8b8)
at macho.c:1259:12
frame #4: 0x0001013c015f
f951`fileline_initialize(state=0x000142fd3000,
error_callback=(f951`::bt_err_callback(void *, const char *, int) at
diagnostic.c:552:3), data=0x7ffeefbff26c) at fileline.c:241:12
[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973 --- Comment #2 from Francois-Xavier Coudert --- I've gone a bit further with this, using the patch in comment #1 to fix the executable path issue. I am now trying to make the backtrace work within libgfortran, on a case with a known runtime error: $ cat a.f90 integer, allocatable :: i(:) allocate(i(10)) print *, i(20) end $ ./bin/gfortran a.f90 -fbounds-check -g && ./a.out At line 3 of file a.f90 Fortran runtime error: Index '20' of dimension 1 of array 'i' above upper bound of 10 Error termination. Backtrace: Could not print backtrace: executable file is not in Mach-O format Why is it complaining? Looking at the code in macho_add(), it's being called a number of times: filename = /private/tmp/irun/./a.out header.magic = 0xfeedfacf filename = /private/tmp/irun/./a.out.dSYM/Contents/Resources/DWARF/a.out header.magic = 0xfeedfacf filename = /tmp/irun/lib/libgfortran.5.dylib header.magic = 0xfeedfacf filename = /usr/lib/libSystem.B.dylib header.magic = 0xbebafeca filename = /usr/lib/libSystem.B.dylib header.magic = 0x It makes sense that it's called twice on libSystem.B.dylib, which is a fat i386 + x86_64 library on darwin19. The first time it correctly sees a fat magic, but the second time it finds it nul…
[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973 --- Comment #3 from Francois-Xavier Coudert --- In macho_add_fat(), the code correctly identifies 2 archs, with the right types (first i386, then x86_64). It's then calling macho_add() for the x86_64 arch, with an foffset of 0xb000, which looks very weird to me. That code has a FIXME, so maybe that's the issue? /* FIXME: What about cpusubtype? */ foffset = fat_arch.offset; if (swapped) foffset = __builtin_bswap64 (foffset); backtrace_release_view (state, &arch_view, error_callback, data); return macho_add (state, filename, descriptor, foffset, match_uuid, base_address, skip_symtab, error_callback, data, fileline_fn, found_sym);
[Bug target/63826] GCC produces haswell instructions that darwin14 assembler does not like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63826 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Francois-Xavier Coudert --- Old, not happening anymore.
[Bug sanitizer/59068] libsanitizer doesn't build on x86_64-unknown-linux-gnu with Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #4 from Francois-Xavier Coudert --- I am not having this issue anymore.
[Bug target/25119] 64-bit GCC on AIX is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25119 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #3 from Francois-Xavier Coudert --- Seems there is not intent to fix this.
[Bug bootstrap/82091] [5 only] Build failure on macOS 10.13 with Xcode 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Francois-Xavier Coudert --- Fixed in newer versions.
[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #4 from Francois-Xavier Coudert ---
I've identified the issue and found a fix. The problem is in the calculation of
the offset when !is_64. The current code is take the uint32_t offset value,
casting it into a uint64_t, then calling bswap64, which is wrong.
The correct way is to call bswap32 and then cast to uint64_t.
diff --git a/libbacktrace/macho.c b/libbacktrace/macho.c
index bd737226ca6..5974d8d8a5b 100644
--- a/libbacktrace/macho.c
+++ b/libbacktrace/macho.c
@@ -797,9 +797,13 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,
uint32_t fcputype;
if (is_64)
- memcpy (&fat_arch,
- (const char *) arch_view.data + i * arch_size,
- arch_size);
+ {
+ memcpy (&fat_arch,
+ (const char *) arch_view.data + i * arch_size,
+ arch_size);
+ if (swapped)
+ fat_arch.offset = __builtin_bswap64 (fat_arch.offset);
+ }
else
{
struct macho_fat_arch fat_arch_32;
@@ -809,7 +813,10 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,
arch_size);
fat_arch.cputype = fat_arch_32.cputype;
fat_arch.cpusubtype = fat_arch_32.cpusubtype;
- fat_arch.offset = (uint64_t) fat_arch_32.offset;
+ if (swapped)
+ fat_arch.offset = (uint64_t) __builtin_bswap32(fat_arch_32.offset);
+ else
+ fat_arch.offset = (uint64_t) fat_arch_32.offset;
fat_arch.size = (uint64_t) fat_arch_32.size;
fat_arch.align = fat_arch_32.align;
fat_arch.reserved = 0;
@@ -821,14 +828,9 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,
if (fcputype == cputype)
{
- uint64_t foffset;
-
/* FIXME: What about cpusubtype? */
- foffset = fat_arch.offset;
- if (swapped)
- foffset = __builtin_bswap64 (foffset);
backtrace_release_view (state, &arch_view, error_callback, data);
- return macho_add (state, filename, descriptor, foffset, match_uuid,
+ return macho_add (state, filename, descriptor, fat_arch.offset,
match_uuid,
base_address, skip_symtab, error_callback, data,
fileline_fn, found_sym);
}
[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #7 from Francois-Xavier Coudert ---
Actually we're not using the other members. So how about simply:
diff --git a/libbacktrace/macho.c b/libbacktrace/macho.c
index bd737226ca6..7f093f309fb 100644
--- a/libbacktrace/macho.c
+++ b/libbacktrace/macho.c
@@ -793,40 +793,33 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,
for (i = 0; i < nfat_arch; ++i)
{
- struct macho_fat_arch_64 fat_arch;
uint32_t fcputype;
+ uint64_t foffset;
if (is_64)
- memcpy (&fat_arch,
- (const char *) arch_view.data + i * arch_size,
- arch_size);
+ {
+ struct macho_fat_arch_64 fat_arch;
+ memcpy (&fat_arch,
+ (const char *) arch_view.data + i * arch_size,
+ arch_size);
+
+ foffset = swapped ? __builtin_bswap64 (fat_arch.offset) :
fat_arch.offset;
+ fcputype = swapped ? __builtin_bswap32 (fat_arch.cputype) :
fat_arch.cputype;
+ }
else
{
struct macho_fat_arch fat_arch_32;
-
memcpy (&fat_arch_32,
(const char *) arch_view.data + i * arch_size,
arch_size);
- fat_arch.cputype = fat_arch_32.cputype;
- fat_arch.cpusubtype = fat_arch_32.cpusubtype;
- fat_arch.offset = (uint64_t) fat_arch_32.offset;
- fat_arch.size = (uint64_t) fat_arch_32.size;
- fat_arch.align = fat_arch_32.align;
- fat_arch.reserved = 0;
- }
- fcputype = fat_arch.cputype;
- if (swapped)
- fcputype = __builtin_bswap32 (fcputype);
+ foffset = swapped ? __builtin_bswap32 (fat_arch_32.offset) :
fat_arch_32.offset;
+ fcputype = swapped ? __builtin_bswap32 (fat_arch_32.cputype) :
fat_arch_32.cputype;
+ }
if (fcputype == cputype)
{
- uint64_t foffset;
-
/* FIXME: What about cpusubtype? */
- foffset = fat_arch.offset;
- if (swapped)
- foffset = __builtin_bswap64 (foffset);
backtrace_release_view (state, &arch_view, error_callback, data);
return macho_add (state, filename, descriptor, foffset, match_uuid,
base_address, skip_symtab, error_callback, data,
[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973 --- Comment #10 from Francois-Xavier Coudert --- Hi Ian, There is still the issue in comment #1: none of the mechanisms for finding the executable path are currently working on darwin (at least in the circumstances I am testing in). - state->filename is NULL - getexecname() is not available on darwin - the /proc filesystem is not either - the BSD-specific function sysctl_exec_name() is not present either I would like to propose adding a mechanism using darwin's native function, which is _NSGetExecutablePath (defined in the header). Two questions, which are for you to decide, are: 1. should it be implemented as an addition case in the switch statement? or as a fallback for getexecname(), as I have done? 2. should it be guarded by an __APPLE__ preprocessor check, or detected in configure? My personal preference would be: 1. I don't really care 2. I don't see the value of a configure check, given it is directly and unambiguously linked to the target (and therefore to the __APPLE__ preprocessor macro being present) Please let me know what you prefer, and I will prepare and test a proper patch.
[Bug lto/47225] [4.6.0 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 Francois-Xavier Coudert changed: What|Removed |Added Target||i586-pc-mingw32 Status|RESOLVED|REOPENED CC||fxcoudert at gcc dot ||gnu.org Host||x86_64-apple-darwin10.6.0 Resolution|FIXED | Build||x86_64-apple-darwin10.6.0 --- Comment #9 from Francois-Xavier Coudert 2011-01-10 10:54:10 UTC --- (In reply to comment #8) > Fixed. I don't think it is. I am building a cross-compiler (with build = host = x86_64-apple-darwin10.6.0, target = i586-pc-mingw32) from unpatched GCC revision 168626, and it's failing with the same symptoms. When configuring libgcc, I get: checking for suffix of object files... configure: error: in `/Users/fx/devel/mingw/ibin/i586-pc-mingw32/libgcc': configure: error: cannot compute suffix of object files: cannot compile And the relevant part of config.log says: xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found compilation terminated.
[Bug bootstrap/47044] bootstrap comparison failure when -O2 defaults on -fgraphite-identity and --enable-build-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47044 Francois-Xavier Coudert changed: What|Removed |Added Target|x86_64-apple-darwin10 | Status|UNCONFIRMED |NEW Keywords||build Last reconfirmed||2011.01.28 10:36:30 CC||fxcoudert at gcc dot ||gnu.org Host|x86_64-apple-darwin10 | Ever Confirmed|0 |1 Build|x86_64-apple-darwin10 |
[Bug libfortran/46611] call to abstract class procedure segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46611 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.13 11:47:05 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert 2011-02-13 11:47:05 UTC --- Please give full source code demonstrating the issue, otherwise this cannot be investigated and the report will be closed.
[Bug fortran/47722] With -static "__mingw_vsprintf" on MinGW32 is not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47722 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2011.02.26 14:00:36 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #3 from Francois-Xavier Coudert 2011-02-26 14:00:36 UTC --- I can confirm having seen that in the past, which was due to the use of an older mingw runtime with newer mingw headers. Or, using a libgfortran that was compiled on a newer mingw, but is now running with an older version. Also, it does not happen for me on a clean install of a cross-compiler.
[Bug libfortran/45165] unix.c:fallback_access() leaks file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45165 --- Comment #2 from Francois-Xavier Coudert 2011-02-26 15:21:51 UTC --- Author: fxcoudert Date: Sat Feb 26 15:21:45 2011 New Revision: 170517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170517 Log: PR libfortran/45165 * unix.c (fallback_access): Fix file descriptor leaks. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c
[Bug libfortran/45165] unix.c:fallback_access() leaks file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45165 Francois-Xavier Coudert changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #3 from Francois-Xavier Coudert 2011-02-26 15:22:35 UTC --- Fixed on trunk.
[Bug tree-optimization/47445] Wrong code generated with -O -fno-omit-frame-pointer -fpeel-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47445 Francois-Xavier Coudert changed: What|Removed |Added Target|x86_64-pc-linux-gnu |x86_64 Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.26 16:03:59 Component|fortran |tree-optimization CC||fxcoudert at gcc dot ||gnu.org Host|x86_64-pc-linux-gnu |x86_64 Ever Confirmed|0 |1 Summary|testsuite/gfortran.dg/impur |Wrong code generated with |e_1.f08 FAILs with -O |-O -fno-omit-frame-pointer |-fno-omit-frame-pointer |-fpeel-loops |-fpeel-loops| --- Comment #1 from Francois-Xavier Coudert 2011-02-26 16:03:59 UTC --- Confirmed on x86_64-darwin, for both 32-bit and 64-bit generated code. The code emitted by the front-end looks good to me, so I'm tentatively assigning it to tree-optimization.
[Bug libfortran/47894] Documentation text for VERIFY intrinsic function is wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894 --- Comment #1 from Francois-Xavier Coudert 2011-02-26 16:34:52 UTC --- Author: fxcoudert Date: Sat Feb 26 16:34:47 2011 New Revision: 170519 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170519 Log: PR fortran/47894 * intrinsic.texi: Fix doc of the VERIFY intrinsic. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi
[Bug libfortran/47894] Documentation text for VERIFY intrinsic function is wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #2 from Francois-Xavier Coudert 2011-02-26 16:36:01 UTC --- Fixed on trunk.
[Bug libfortran/47894] Documentation text for VERIFY intrinsic function is wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894 --- Comment #4 from Francois-Xavier Coudert 2011-02-28 08:16:24 UTC --- Author: fxcoudert Date: Mon Feb 28 08:16:21 2011 New Revision: 170557 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170557 Log: PR fortran/47894 * intrinsic.texi: Fix doc of the VERIFY intrinsic. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi
[Bug libfortran/47894] Documentation text for VERIFY intrinsic function is wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Francois-Xavier Coudert 2011-02-28 08:17:59 UTC --- Fixed again, thanks again!
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #6 from Francois-Xavier Coudert ---
The current patch is also lacking handling of the sign if signed zero is used.
This should do the trick:
if (mpfr_sgn (x->value.real) == 0)
{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
return result;
}
Using mpfr_frexp() is a good idea, and probably a gain in the long term (easier
maintenance), so we may wrap it inside version checks. Tentative patch:
Index: simplify.c
===
--- simplify.c(revision 200350)
+++ simplify.c(working copy)
@@ -2342,16 +2342,25 @@ gfc_expr *
gfc_simplify_fraction (gfc_expr *x)
{
gfc_expr *result;
+
+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
mpfr_t absv, exp, pow2;
+#else
+ mpfr_exp_t e;
+#endif
if (x->expr_type != EXPR_CONSTANT)
return NULL;
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
+
+ /* MPFR versions before 3.1.0 do not include mpfr_frexp. */
+
if (mpfr_sgn (x->value.real) == 0)
{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
return result;
}
@@ -2369,9 +2378,17 @@ gfc_simplify_fraction (gfc_expr *x)
mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
mpfr_div (result->value.real, absv, pow2, GFC_RND_MODE);
+ mpfr_copysign (result->value.real, result->value.real,
+ x->value.real, GFC_RND_MODE);
mpfr_clears (exp, absv, pow2, NULL);
+#else
+
+ mpfr_frexp (&e, result->value.real, x->value.real, GFC_RND_MODE);
+
+#endif
+
return range_check (result, "FRACTION");
}
However, I don't have a machine set up for bootstrapping (and regtesting) this
change. I just happened to pass by here :)
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #7 from Francois-Xavier Coudert --- I forgot in the last comment to say: handling of sign for non-zero cases, in old MPFR versions, is done by this line which was missing in the existing code: + mpfr_copysign (result->value.real, result->value.real, + x->value.real, GFC_RND_MODE);
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #9 from Francois-Xavier Coudert --- > Before going to the machinery in comment #6, the following patch (i.e., > without any mpfr_copysign) Yep, you're right, no need for mpfr_copysign. Your patch looks good, if we don't want to introduce mpfr_frexp.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #12 from Francois-Xavier Coudert --- (In reply to Dominique d'Humieres from comment #10) > + y=fraction (-2.0) > + write (buf, *) y > + if (buf(1:10) /= " -0.50") call abort () Why involve I/O in your test, and not just test the value like that: if (fraction(-2.0) /= -0.5) call abort() and, slightly more complicated to handle negative zero, checking both value and sign: if (fraction(-0.0) /= 0.0) call abort if (sign(1.0, fraction(-0.0)) /= -1.0) call abort
[Bug libfortran/37634] Fix libgfortran compiling to support GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37634 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #5 from Francois-Xavier Coudert --- I think this bug was fixed by Steve Ellcey in revision 200374: r200374 | sje | 2013-06-24 17:24:19 +0200 (Mon, 24 Jun 2013) | 5 lines 2013-06-24 Steve Ellcey * configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement. * configure: Regenerate. (though, for some reason, this commit message cannot be found in libgfortran/ChangeLog). I'm closing, please reopen if it is not actually fixed (with current explanation of what goes wrong).
[Bug bootstrap/50812] New: libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 Bug #: 50812 Summary: libbid build fails with ICE on bid128_div.c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: fxcoud...@gcc.gnu.org Host: x86_64-apple-darwin11 Target: i586-pc-mingw32 Build: x86_64-apple-darwin11 Created attachment 25561 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25561 Preprocessed source triggering the ICE Building a cross-compiler to i586-pc-mingw32 fails with an ICE while compiling libgcc, or more precisely, libbid's bid128_div.c: ../../../../gcc/trunk/libgcc/config/libbid/bid128_div.c:1851:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1407 The cross-compiler is configured with: ../../gcc/trunk/configure --prefix=/Users/fx/devel/mingw/cross --target=i586-pc-mingw32 --disable-werror --with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 --enable-languages=c,fortran The backtrace of the ICE is: #0 fancy_abort (file=0x100aae258 "../../../gcc/trunk/gcc/ipa-inline.c", line=1407, function=0x100aae9a0 "inline_small_functions") at diagnostic.c:897 #1 0x00010056dd1a in ipa_inline () at ipa-inline.c:1407 #2 0x000100617f17 in execute_one_pass (pass=0x100aae258) at passes.c:2064 #3 0x000100618a7c in execute_ipa_pass_list (pass=0x100aae258) at passes.c:2431 #4 0x00010035f89c in ipa_passes [inlined] () at /Users/fx/devel/gcc/trunk/gcc/cgraphunit.c:2061 #5 0x00010035f89c in cgraph_optimize () at cgraphunit.c:2116 #6 0x00010036099f in cgraph_finalize_compilation_unit () at cgraphunit.c:1312 #7 0x0001000157d8 in c_write_global_declarations () at c-decl.c:9940 #8 0x0001006db701 in do_compile [inlined] () at /Users/fx/devel/gcc/trunk/gcc/toplev.c:581 I attach the preprocessed source. The bug is triggered consistently at -O1 and higher optimization. It can be reproduced simply with "cc1 -O bid128_div.i"
[Bug bootstrap/50812] libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 --- Comment #1 from Francois-Xavier Coudert 2011-10-20 15:25:20 UTC --- I should have added that I am using trunk revision 180247.
[Bug bootstrap/50812] libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 Francois-Xavier Coudert changed: What|Removed |Added CC||jh at suse dot cz --- Comment #3 from Francois-Xavier Coudert 2011-10-20 20:25:44 UTC --- So it's not mingw-specific, it's a full i686/x86_64 bootstrap failure. This seems due to either of these two patches: 2011-10-19 Jan Hubicka * ipa-inline.c (inline_small_functions): Always update all calles after inlining. 2011-10-19 Jan Hubicka PR bootstrap/50709 * ipa-inline.c (inline_small_functions): Fix checking code to not make effect on fibheap stability.
[Bug bootstrap/50812] libbid build fails with ICE on bid128_div.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50812 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Francois-Xavier Coudert 2011-10-21 12:36:25 UTC --- Fixed indeed.
[Bug target/51007] New: Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007
Bug #: 51007
Summary: Quadmath I/O doesn't work on MinGW
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fxcoud...@gcc.gnu.org
Target: i586-pc-mingw32
The following test program works fine with current trunk on i686 and
x86_64-linux:
#include
#include
int main (void)
{
char buf[100];
quadmath_snprintf (buf, sizeof buf, "%.60Qg", (__float128) 3.14);
puts (buf);
}
It outputs "3.140124344978758017532527446746826171875". When
compiled and run on MinGW, it gives an incorrect output (on my test system,
"1.9163987915738935076000483121420225908698150840344985584492e-4932"). I
confirmed with both a native MinGW build (i586-pc-mingw32) and a cross-compiler
for i586-pc-mingw32, running on x86_64-apple-darwin11, and running the result
under either Wine or a real Windows.
The cross-compiler is configured as such:
../../gcc/trunk/configure --target=i586-pc-mingw32 --disable-werror
--enable-languages=c,fortran
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-07 Ever Confirmed|0 |1
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007
--- Comment #1 from Francois-Xavier Coudert
2011-11-07 11:03:32 UTC ---
I don't know if it's related, or two different bugs, but hexadecimal printing
has the correct mantissa with a wrong exponent. See below the same testcase
compile on my mac (native compiler) and cross-compiled to mingw:
$ cat v.c
#include
#include
int main (void)
{
char buf[100];
quadmath_snprintf (buf, sizeof buf, "%.60Qa", (__float128) 3.14);
puts (buf);
}
$ gcc-4.6 v.c -lquadmath && ./a.out
0x1.91eb851eb851f000p+1
$ ./cross/bin/i586-pc-mingw32-gcc v.c -static -lquadmath
$ /opt/wine/bin/wine ./a.exe
0x1.91eb851eb851f000p-5318
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007
--- Comment #2 from Francois-Xavier Coudert
2011-11-07 11:29:39 UTC ---
The bug is not in the I/O routine, it can be reproduce by this simple
self-contained testcase (which doesn't need libquadmath).
#include
typedef union
{
__float128 value;
struct
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
unsigned negative:1;
unsigned exponent:15;
uint64_t mant_high:48;
uint64_t mant_low:64;
#else
uint64_t mant_low:64;
uint64_t mant_high:48;
unsigned exponent:15;
unsigned negative:1;
#endif
} ieee;
} ieee854_float128;
int main (void)
{
ieee854_float128 d;
d.value = (__float128) 3.14;
__builtin_printf ("%u\n", (unsigned) d.ieee.exponent);
}
On darwin, this program consistently outputs 16384. When cross-compiled to
mingw, and run on Windows XP, it consistently outputs 6448. When the same
executable is run under Wine on darwin, it outputs inconsistent, wrong values
(the last few invocations here show: 4755, 12947, 21139).
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007
--- Comment #3 from Francois-Xavier Coudert
2011-11-07 11:39:12 UTC ---
Going further: I tried to compare the trees generated by the simple function
below:
#include
typedef union
{
__float128 value;
struct
{
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
unsigned negative:1;
unsigned exponent:15;
uint64_t mant_high:48;
uint64_t mant_low:64;
#else
uint64_t mant_low:64;
uint64_t mant_high:48;
unsigned exponent:15;
unsigned negative:1;
#endif
} ieee;
} ieee854_float128;
unsigned foo (__float128 x)
{
ieee854_float128 d;
d.value = x;
return d.ieee.exponent;
}
AFAICT, both the original and the optimized tree for darwin and mingw are
identical. The assembly code generated for a common arch (-march=core2 -O0)
differs:
* on mingw *
_foo:
pushl %ebp
movl%esp, %ebp
subl$40, %esp
movdqa 8(%ebp), %xmm0
movdqa %xmm0, -40(%ebp)
movzwl -24(%ebp), %eax
andw$32767, %ax
movzwl %ax, %eax
leave
ret
* on darwin *
_foo:
pushq%rbp
movq%rsp, %rbp
movdqa%xmm0, -32(%rbp)
movdqa-32(%rbp), %xmm0
movdqa%xmm0, -16(%rbp)
movzwl-2(%rbp), %eax
andw$32767, %ax
movzwl%ax, %eax
popq%rbp
ret
Now, my assembly skills are pretty close to nil, so I can't figure out if the
differences are meaningful, and what they mean. I only hope that I got it close
enough that someone can, from here, understand where this code generation come
from and how to fix it.
[Bug target/51007] Quadmath I/O doesn't work on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007 Francois-Xavier Coudert changed: What|Removed |Added Keywords||patch CC||jakub at redhat dot com --- Comment #6 from Francois-Xavier Coudert 2011-11-07 12:42:26 UTC --- (In reply to comment #4) > So the mixture of different sized types in union is leading to this behavior. > You can see that result becomes ok, if you are specifying to union/struct the > attribute gcc_struct. Indeed, I confirm that your patch fixes the issue (and the original Fortran testcase reported on comp.lang.fortran now works fine). Both Tobias and Jakub (Cc'ed) are libquadmath maintainers and can approve it.
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-07 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1
[Bug libfortran/49188] Mismatch between -fsign-zero documentation and formatted output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188 --- Comment #3 from Francois-Xavier Coudert 2011-11-07 22:22:02 UTC --- Author: fxcoudert Date: Mon Nov 7 22:21:54 2011 New Revision: 181127 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181127 Log: PR libfortran/49188 PR libfortran/49336 * invoke.texi: Fix documentation of fsign-zero option. Remove contractions. * intrinsic.texi: Fix ATAN2 documentation for signed zeros. Remove contractions. * gfortran.texi: Remove contractions. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/invoke.texi
[Bug libfortran/49336] ATAN2 values differ from those specified in documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49336 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Francois-Xavier Coudert 2011-11-07 22:24:25 UTC --- Fixed on trunk.
[Bug libfortran/49336] ATAN2 values differ from those specified in documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49336 --- Comment #4 from Francois-Xavier Coudert 2011-11-07 22:22:02 UTC --- Author: fxcoudert Date: Mon Nov 7 22:21:54 2011 New Revision: 181127 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181127 Log: PR libfortran/49188 PR libfortran/49336 * invoke.texi: Fix documentation of fsign-zero option. Remove contractions. * intrinsic.texi: Fix ATAN2 documentation for signed zeros. Remove contractions. * gfortran.texi: Remove contractions. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/invoke.texi
[Bug libfortran/49188] Mismatch between -fsign-zero documentation and formatted output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Francois-Xavier Coudert 2011-11-07 22:24:38 UTC --- Fixed on trunk.
[Bug fortran/48729] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48729 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||WORKSFORME --- Comment #2 from Francois-Xavier Coudert 2011-11-07 22:33:19 UTC --- I cannot reproduce that either, even with a mingw or a mingw-w64 compiler. Thus, I'm closing this bug report. Please reopen if the problem is still present in more recent releases.
[Bug fortran/48972] OPEN with Unicode file name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48972 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-07 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement
[Bug fortran/49683] The system cannot execute the specified program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49683 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||WORKSFORME --- Comment #3 from Francois-Xavier Coudert 2011-11-07 22:37:11 UTC --- Closing as report gives insufficient information. Please reopen with detailed information if the issue persists.
[Bug fortran/50231] Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||DUPLICATE --- Comment #6 from Francois-Xavier Coudert 2011-11-07 22:41:08 UTC --- *** This bug has been marked as a duplicate of bug 47394 ***
[Bug fortran/47394] Internal compiler error when error count limit is reached
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47394 Francois-Xavier Coudert changed: What|Removed |Added CC||pavel.belomestnov at ||regeneron dot com --- Comment #5 from Francois-Xavier Coudert 2011-11-07 22:41:08 UTC --- *** Bug 50231 has been marked as a duplicate of this bug. ***
[Bug fortran/49943] libgfortran fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49943 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||WORKSFORME
[Bug fortran/49738] Compile errors on OSX darwin 11 (Lion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49738 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||WORKSFORME --- Comment #5 from Francois-Xavier Coudert 2011-11-07 22:44:45 UTC --- No news, and current trunk and 4.6 build fine under Mac OS 10.7 (Lion), so I'm closing this. Please reopen with specific details (i.e., which version of GCC you are compiling, how it is configured, etc.) if the issue persists.
[Bug fortran/49438] error during make
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49438 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot ||gnu.org --- Comment #8 from Francois-Xavier Coudert 2011-11-07 22:47:04 UTC --- Closing, please reopen with detailed information if you still encounter the issue. One problem may be that you were compiling with recent GMP headers, but picking up an older GMP library at runtime.
[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |NEW CC||fxcoudert at gcc dot ||gnu.org
[Bug fortran/49438] error during make
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49438 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #9 from Francois-Xavier Coudert 2011-11-07 22:48:26 UTC --- Closing, please reopen with detailed information if you still encounter the issue. One problem may be that you were compiling with recent GMP headers, but picking up an older GMP library at runtime.
[Bug fortran/50046] Hexadecimal Constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50046 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||WORKSFORME --- Comment #6 from Francois-Xavier Coudert 2011-11-07 22:50:06 UTC --- Same comment as Mikael here, hex constants following the GNU extension work fine with recent gfortran versions. Thus closing this report. If you still encounter this problem, please reopen with a self-contained example and information on what compiler you are using
[Bug libfortran/46611] call to abstract class procedure segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46611 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID
[Bug libfortran/47972] error.c:158:7: warning: return makes pointer from integer without a cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47972 Francois-Xavier Coudert changed: What|Removed |Added Keywords||patch Status|WAITING |NEW CC||fxcoudert at gcc dot ||gnu.org
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||FIXED --- Comment #16 from Francois-Xavier Coudert 2011-11-07 22:58:18 UTC --- The testcase appears to pass in recent testresults on this platform (http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01343.html), so I'm closing the PR.
[Bug libfortran/47970] c99_functions.c:611:5: warning: implicit declaration of function 'round'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47970 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |fxcoudert at gcc dot |gnu.org |gnu.org --- Comment #2 from Francois-Xavier Coudert 2011-11-08 06:47:16 UTC --- Created attachment 25749 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25749 Patch Moving the round() implementation before that of roundl() should fix it. Please confirm that it does.
[Bug fortran/48543] Collapse identical strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48543 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-08 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1
[Bug fortran/50334] interaction between -Wuninitialized and -finit-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50334 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-11/msg01136.htm ||l Keywords||documentation, patch Last reconfirmed||2011-11-08 CC||fxcoudert at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |fxcoudert at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 Summary|interaction between |interaction between |-Wuninitialized and |-Wuninitialized and |-finit-real=snan|-finit-* --- Comment #3 from Francois-Xavier Coudert 2011-11-08 07:56:41 UTC --- Document patch submitted at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01136.html
[Bug libstdc++/51026] New: Bootstrap failure due to libstdc++ on x86_64-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026 Bug #: 51026 Summary: Bootstrap failure due to libstdc++ on x86_64-darwin11 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: fxcoud...@gcc.gnu.org CC: amacl...@redhat.com Host: x86_64-apple-darwin11 Target: x86_64-apple-darwin11 Build: x86_64-apple-darwin11 Bootstrap currently fails on x86_64-apple-darwin11 due to a problem in building libstdc++.6.dylib: ld: duplicate symbol std::atomic_thread_fence(std::memory_order) in .libs/functexcept.o and .libs/compatibility-atomic-c++0x.o for architecture x86_64 collect2: error: ld returned 1 exit status make[5]: *** [libstdc++.la] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2
[Bug libstdc++/51026] Bootstrap failure due to libstdc++ on x86_64-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026 --- Comment #1 from Francois-Xavier Coudert 2011-11-08 08:06:07 UTC --- Should have added: this is with trunk revision , and probably due to 2011-11-07 Andrew MacLeod * include/bits/atomic_base.h (atomic_thread_fence): Revert. (atomic_signal_fence): Revert. 2011-11-07 Andrew MacLeod * include/bits/atomic_base.h (atomic_thread_fence): Call builtin. (atomic_signal_fence): Call builtin. (atomic_flag::test_and_set): Call __atomic_exchange when it is lockfree, otherwise fall back to call __sync_lock_test_and_set. (atomic_flag::clear): Call __atomic_store when it is lockfree, otherwise fall back to call __sync_lock_release.
[Bug fortran/50334] interaction between -Wuninitialized and -finit-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50334 --- Comment #4 from Francois-Xavier Coudert 2011-11-08 08:11:16 UTC --- Author: fxcoudert Date: Tue Nov 8 08:11:10 2011 New Revision: 181150 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181150 Log: PR fortran/50334 * invoke.texi (-finit-*): Document interaction with -Wuninitialized. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi
[Bug fortran/50334] interaction between -Wuninitialized and -finit-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50334 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Francois-Xavier Coudert 2011-11-08 08:11:57 UTC --- Fixed on trunk.
[Bug libfortran/47970] c99_functions.c:611:5: warning: implicit declaration of function 'round'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47970 --- Comment #3 from Francois-Xavier Coudert 2011-11-08 10:31:11 UTC --- Author: fxcoudert Date: Tue Nov 8 10:31:04 2011 New Revision: 181153 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181153 Log: PR libfortran/47970 * intrinsics/c99_functions.c (round): Move higher in the file. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/c99_functions.c
[Bug libfortran/47970] c99_functions.c:611:5: warning: implicit declaration of function 'round'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47970 Francois-Xavier Coudert changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Francois-Xavier Coudert 2011-11-08 10:32:31 UTC --- Fixed on trunk, thanks for reporting the issue!
[Bug libfortran/47972] error.c:158:7: warning: return makes pointer from integer without a cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47972 --- Comment #4 from Francois-Xavier Coudert 2011-11-08 21:58:51 UTC --- Author: fxcoudert Date: Tue Nov 8 21:58:47 2011 New Revision: 181180 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181180 Log: PR libfortran/47972 * runtime/error.c (gf_strerror): Silence warning. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/error.c
[Bug libfortran/47972] error.c:158:7: warning: return makes pointer from integer without a cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47972 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Francois-Xavier Coudert 2011-11-08 22:00:08 UTC --- Fixed on trunk, thanks Jakub for the patch!
[Bug fortran/50409] SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Francois-Xavier Coudert changed: What|Removed |Added Keywords||ice-on-valid-code, patch Status|NEW |ASSIGNED CC||fxcoudert at gcc dot ||gnu.org --- Comment #3 from Francois-Xavier Coudert 2011-11-08 22:31:36 UTC --- This is actually the same bug as PR48876, but the original fix was not enough. The following fixes it for good (fingers crosser, obviously!): Index: expr.c === --- expr.c(revision 181149) +++ expr.c(working copy) @@ -1853,8 +1853,8 @@ gfc_simplify_expr (gfc_expr *p, int type if (p->ref && p->ref->u.ss.end) gfc_extract_int (p->ref->u.ss.end, &end); - if (end < 0) -end = 0; + if (end < start) +end = start; s = gfc_get_wide_string (end - start + 2); memcpy (s, p->value.character.string + start,
[Bug fortran/50540] Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-08 CC||fxcoudert at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |fxcoudert at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #2 from Francois-Xavier Coudert 2011-11-08 22:33:54 UTC --- I agree with Steve's patch, so I intend to submit it for review.
[Bug fortran/50408] [4.6/4.7 regression] ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Francois-Xavier Coudert changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 Last reconfirmed|2011-09-15 00:00:00 |2011-11-08 0:00 CC||fxcoudert at gcc dot ||gnu.org Summary|ICE in transfer_expr|[4.6/4.7 regression] ICE in ||transfer_expr --- Comment #2 from Francois-Xavier Coudert 2011-11-08 23:01:00 UTC --- This one is actually a 4.6 and 4.7 regression. It runs fine on 4.3, 4.4 and 4.5. Reduced testcase: module m type int integer :: val end type int contains type(int) function foo() foo%val = 42 end function foo end module m program p use m print *, foo() end program p
[Bug fortran/50409] SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 --- Comment #4 from Francois-Xavier Coudert 2011-11-08 23:15:16 UTC --- Author: fxcoudert Date: Tue Nov 8 23:15:11 2011 New Revision: 181181 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181181 Log: PR fortran/50409 * expr.c (gfc_simplify_expr): Substrings can't have negative length. * gcc/testsuite/gfortran.dg/string_5.f90: Improve testcase. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/string_5.f90
[Bug fortran/50409] SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Francois-Xavier Coudert changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Francois-Xavier Coudert 2011-11-08 23:15:46 UTC --- Fixed on trunk.
[Bug fortran/50404] SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 --- Comment #2 from Francois-Xavier Coudert 2011-11-08 23:54:48 UTC --- Author: fxcoudert Date: Tue Nov 8 23:54:43 2011 New Revision: 181183 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181183 Log: PR fortran/50404 * io.c (gfc_resolve_close): CLOSE requires a UNIT. * gfortran.dg/io_constraints_3.f90: Improve testcase. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/io_constraints_3.f90
[Bug fortran/50404] SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Francois-Xavier Coudert changed: What|Removed |Added Keywords||ice-on-invalid-code Status|NEW |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Francois-Xavier Coudert 2011-11-08 23:57:21 UTC --- Fixed on trunk.
[Bug fortran/21881] ICE instead of error for large arrays in derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881 --- Comment #9 from Francois-Xavier Coudert 2011-11-09 06:57:15 UTC --- Author: fxcoudert Date: Wed Nov 9 06:57:10 2011 New Revision: 181192 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181192 Log: PR fortran/21881 * trans-types.c (gfc_get_dtype): Issue a fatal error instead of an internal error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c
[Bug fortran/21881] ICE instead of error for large arrays in derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881 Francois-Xavier Coudert changed: What|Removed |Added Keywords|ice-on-valid-code |diagnostic Status|NEW |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #10 from Francois-Xavier Coudert 2011-11-09 06:57:55 UTC --- Fixed on trunk.
[Bug fortran/38718] some simplifiers for elemental intrinsics missing; required for init expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38718 --- Comment #6 from Francois-Xavier Coudert 2011-11-09 09:41:21 UTC --- Author: fxcoudert Date: Wed Nov 9 09:41:17 2011 New Revision: 181198 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181198 Log: PR fortran/38718 * intrinsic.c (add_functions): Add gfc_simplify_dreal. * intrinsic.h (gfc_simplify_dreal): New proto. * simplify.c (gfc_simplify_dreal): New function. * gfortran.dg/initialization_29.f90: Expand test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_29.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/38718] some simplifiers for elemental intrinsics missing; required for init expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38718 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Francois-Xavier Coudert 2011-11-09 09:42:34 UTC --- LSHIFT and RSHIFT were implemented at some point, and I have now added DREAL simplification. Closing as fixed on trunk.
[Bug fortran/50540] Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540 --- Comment #3 from Francois-Xavier Coudert 2011-11-09 09:51:53 UTC --- Author: fxcoudert Date: Wed Nov 9 09:51:49 2011 New Revision: 181200 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181200 Log: PR fortran/50540 * resolve.c (resolve_forall_iterators): Transform internal errors to normal errors. * gfortran.dg/forall_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/forall_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50540] Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540 Francois-Xavier Coudert changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Francois-Xavier Coudert 2011-11-09 09:53:38 UTC --- Fixed on trunk, thanks Steve for the patch!
[Bug fortran/38282] Bit intrinsics: ILEN and IBCHNG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #16 from Francois-Xavier Coudert 2011-11-09 09:58:52 UTC --- Fixed on 4.6 branch a while back.
[Bug libstdc++/51026] [4.7 Regression] Bootstrap failure due to libstdc++ on x86_64-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Francois-Xavier Coudert 2011-11-09 10:09:53 UTC --- Appears to be fixed.
[Bug fortran/47065] Replace trim(a) by a(1:len_trim(a))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47065 --- Comment #7 from Francois-Xavier Coudert 2011-11-09 10:09:15 UTC --- Thomas, I think this is mostly fixed, isn't it? If so, we could close it.
[Bug bootstrap/51053] New: Bootstrap fails due to libitm on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51053 Bug #: 51053 Summary: Bootstrap fails due to libitm on x86_64-apple-darwin11 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: fxcoud...@gcc.gnu.org CC: r...@gcc.gnu.org Host: x86_64-apple-darwin11 Target: x86_64-apple-darwin11 Build: x86_64-apple-darwin11 With trunk rev. 181200, a bootstrap on x86_64-apple-darwin11 configured with: ../trunk/configure --enable-languages=c,fortran fails with: libtool: compile: /Users/fx/devel/gcc/ibin/./gcc/g++ -B/Users/fx/devel/gcc/ibin/./gcc/ -nostdinc++ -nostdinc++ -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin11.2.0/libstdc++-v3/include/x86_64-apple-darwin11.2.0 -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin11.2.0/libstdc++-v3/include -I/Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++ -I/Users/fx/devel/gcc/trunk/libstdc++-v3/include/backward -I/Users/fx/devel/gcc/trunk/libstdc++-v3/testsuite/util -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin11.2.0/libstdc++-v3/src -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin11.2.0/libstdc++-v3/src/.libs -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin11.2.0/bin/ -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin11.2.0/include -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin11.2.0/sys-include -DHAVE_CONFIG_H -I. -I../../../../trunk/libitm -I../../../../trunk/libitm/config/x86 -I../../../../trunk/libitm/config/posix -I../../../../trunk/libitm/config/generic -I../../../../trunk/libitm -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -march=i486 -mtune=i686 -fomit-frame-pointer -Wall -pthread -Werror -mavx -fabi-version=4 -g -O2 -m32 -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c ../../../../trunk/libitm/config/x86/x86_avx.cc -fno-common -DPIC -o .libs/x86_avx.o /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:3:Unknown pseudo-op: .pushsection /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:3:Rest of line ignored. 1st junk character valued 46 (.). /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:6:Unknown pseudo-op: .hidden /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:6:Rest of line ignored. 1st junk character valued 71 (G). /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:7:Unknown pseudo-op: .type /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:7:Rest of line ignored. 1st junk character valued 71 (G). /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:12:no such instruction: `vpalignr $1, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:15:no such instruction: `vpalignr $2, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:18:no such instruction: `vpalignr $3, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:21:no such instruction: `vpalignr $4, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:24:no such instruction: `vpalignr $5, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:27:no such instruction: `vpalignr $6, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:30:no such instruction: `vpalignr $7, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:33:no such instruction: `vpalignr $8, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:36:no such instruction: `vpalignr $9, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:39:no such instruction: `vpalignr $10, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:42:no such instruction: `vpalignr $11, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:45:no such instruction: `vpalignr $12, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:48:no such instruction: `vpalignr $13, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:51:no such instruction: `vpalignr $14, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:54:no such instruction: `vpalignr $15, %xmm0,%xmm1,%xmm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:57:Unknown pseudo-op: .size /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:57:Rest of line ignored. 1st junk character valued 71 (G). /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:58:Unknown pseudo-op: .popsection /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:107:no such instruction: `vmovaps 32(%esp), %ymm0' /var/folders/h8/9hx_fyj91053ksgdzb2w03vwgp/T//ccXFC6zc.s:165:no such in
[Bug bootstrap/51053] Bootstrap fails due to libitm on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51053 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Francois-Xavier Coudert 2011-11-09 11:22:14 UTC --- It's actually already reported, sorry for the noise. *** This bug has been marked as a duplicate of bug 51031 ***
[Bug bootstrap/51031] build error in libitm (how to disable trans-mem???)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot ||gnu.org --- Comment #3 from Francois-Xavier Coudert 2011-11-09 11:22:14 UTC --- *** Bug 51053 has been marked as a duplicate of this bug. ***
[Bug debug/30645] Failure to build 20001226-1.c with -O2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30645 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #3 from Francois-Xavier Coudert 2012-02-02 21:38:37 UTC --- Almost five years to the day!
[Bug fortran/52426] ICE for c_loc with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52426 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-29 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1
[Bug libfortran/36044] user-requested backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044 Francois-Xavier Coudert changed: What|Removed |Added Keywords||patch URL||http://gcc.gnu.org/ml/fortr ||an/2012-03/msg00015.html CC||fxcoudert at gcc dot ||gnu.org --- Comment #7 from Francois-Xavier Coudert 2012-03-03 07:45:51 UTC --- Patch was proposed at http://gcc.gnu.org/ml/fortran/2012-03/msg00015.html
[Bug fortran/52313] useless error message for old version of .mod file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Version|unknown |4.8.0 URL||http://gcc.gnu.org/ml/fortr ||an/2012-03/msg00016.html Keywords||diagnostic, patch Last reconfirmed||2012-03-03 CC||fxcoudert at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert 2012-03-03 09:54:40 UTC --- Thanks for the report. I submitted a patch for review: http://gcc.gnu.org/ml/fortran/2012-03/msg00016.html
[Bug fortran/30677] Intrinsics arguments evaluated multiple times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30677 Francois-Xavier Coudert changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Francois-Xavier Coudert 2012-03-03 13:03:23 UTC --- No activity, not a bug-report but really more of todo note. Closing :)
[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662 Francois-Xavier Coudert changed: What|Removed |Added CC||franke.daniel at gmail dot ||com --- Comment #9 from Francois-Xavier Coudert 2012-03-03 14:36:27 UTC --- *** Bug 29671 has been marked as a duplicate of this bug. ***
