[Bug fortran/61459] [4.8/4.9/4.10 Regression] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- The debugger shows that retarray is NULL on the call to matmul_r4. Clearly, this is not supposed to happen. Program received signal SIGSEGV, Segmentation fault. _gfortran_matmul_r4 (retarray=0x0, a=0x7fffd730, b=0x7fffd700, try_blas=0, blas_limit=0, gemm=0x0) at ../../../trunk/libgfortran/generated/matmul_r4.c:104 104 if (retarray->base_addr == NULL) I am a bit baffled by this, because this looks correct if you look at the use of the variable D.2357. struct array1_real(kind=4) D.2357; D.2357 = *(struct array1_real(kind=4) *) __result; D.2357.data = 0B; _gfortran_matmul_r4 (*(struct array1_real(kind=4) * *) &D.2357, D.2384, D.2391, 0, 0, 0B); ((struct array1_real(kind=4) *) __result)->data = D.2357.data; D.2360 = struct array1_real(kind=4) *) __result)->dim[0].lbound - D.2357.dim[0].lbound) - ((struct array1_real(kind=4) *) __result)->dim[0].ubound) + D.2357.dim[0].ubound != 0; ((struct array1_real(kind=4) *) __result)->dim[0].ubound = D.2357.dim[0].ubound + D.2362;
[Bug target/61387] [4.10 Regression] ~900 test failures on on x86_64-apple-darwin13 for g++ with -m64 after r211089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387
--- Comment #11 from Dominique d'Humieres ---
Is the following patch acceptable while waiting for a better understanding of
the problem?
--- ../_clean/gcc/config/i386/i386.c2014-07-02 23:54:09.0 +0200
+++ gcc/config/i386/i386.c2014-07-05 18:18:13.0 +0200
@@ -38899,7 +38899,7 @@ x86_output_mi_thunk (FILE *file,
because we're going to do no optimization. */
if (MEM_P (fnaddr))
{
- if (sibcall_insn_operand (fnaddr, word_mode))
+ if (sibcall_insn_operand (fnaddr, word_mode) && !TARGET_MACHO)
{
tmp = gen_rtx_CALL (VOIDmode, fnaddr, const0_rtx);
tmp = emit_call_insn (tmp);
[Bug fortran/61459] [4.8/4.9/4.10 Regression] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- Created attachment 33077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33077&action=edit Fix for the PR This regtests OK for dg.exp=gfortran.dg/alloc* so I presume that it is OK. Am regtesting the whole testsuite right now. 2014-07-06 Paul Thomas PR fortran/61459 * trans-expr.c (fcncall_realloc_result): Use the natural type for the address expression of 'res_desc'. 2014-07-06 Paul Thomas PR fortran/61459 * gfortran.dg/allocatable_function_8.f90 : New test
[Bug c++/61726] New: Ambiguous overload resolution with inherited op()s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61726
Bug ID: 61726
Summary: Ambiguous overload resolution with inherited op()s
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kaballo86 at hotmail dot com
The following snippet results in an ambiguous overload error:
struct foo1 { void operator()(int&) const {}; };
struct foo2 { void operator()(int const&) const {}; };
struct bar : foo1, foo2 {};
int main() {
int i = 0;
bar{}(i); // error
int const ci = 0;
bar{}(ci); // error
}
[Bug fortran/61459] [4.8/4.9/4.10 Regression] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 --- Comment #5 from Dominique d'Humieres --- AFAICT the patch also fixes pr58883.
[Bug fortran/58883] Wrong code with realloc on assignment with assigning RESHAPE() to the function result variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58883 --- Comment #2 from Dominique d'Humieres --- AFAICT this PR is fixed by the patch for pr61459.
[Bug c/61727] New: #pragma simd is undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61727 Bug ID: 61727 Summary: #pragma simd is undocumented Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org extend.texi does not document #pragma simd at all
[Bug c/6940] taking sizeof array parameter should trigger a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6940 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Sun Jul 6 19:00:10 2014 New Revision: 212312 URL: https://gcc.gnu.org/viewcvs?rev=212312&root=gcc&view=rev Log: PR c/6940 * doc/invoke.texi: Document -Wsizeof-array-argument. c-family/ * c.opt (Wsizeof-array-argument): New option. c/ * c-decl.c (grokdeclarator): Set C_ARRAY_PARAMETER. * c-tree.h (C_ARRAY_PARAMETER): Define. * c-typeck.c (c_expr_sizeof_expr): Warn when using sizeof on an array function parameter. cp/ * cp-tree.h (DECL_ARRAY_PARAMETER_P): Define. * decl.c (grokdeclarator): Set DECL_ARRAY_PARAMETER_P. * typeck.c (cxx_sizeof_expr): Warn when using sizeof on an array function parameter. testsuite/ * c-c++-common/Wsizeof-pointer-memaccess1.c: Use -Wno-sizeof-array-argument. * c-c++-common/Wsizeof-pointer-memaccess2.c: Likewise. * g++.dg/warn/Wsizeof-pointer-memaccess-1.C: Likewise. * gcc.dg/Wsizeof-pointer-memaccess1.c: Likewise. * g++.dg/torture/Wsizeof-pointer-memaccess1.C: Likewise. * g++.dg/torture/Wsizeof-pointer-memaccess2.C: Likewise. * gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Likewise. * c-c++-common/sizeof-array-argument.c: New test. * gcc.dg/vla-5.c: Add dg-warnings. ../libgomp/ * testsuite/libgomp.c/appendix-a/a.29.1.c (f): Add dg-warnings. Added: trunk/gcc/testsuite/c-c++-common/sizeof-array-argument.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess1.c trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess2.c trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C trunk/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C trunk/gcc/testsuite/g++.dg/warn/Wsizeof-pointer-memaccess-1.C trunk/gcc/testsuite/gcc.dg/Wsizeof-pointer-memaccess1.c trunk/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c trunk/gcc/testsuite/gcc.dg/vla-5.c trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c/appendix-a/a.29.1.c
[Bug c/6940] taking sizeof array parameter should trigger a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6940 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c/61727] #pragma simd is undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61727 --- Comment #1 from Andrew Pinski --- Most of the openmp ones are also undocumented, see bug 26154.
[Bug c++/61636] generic lambda "cannot call member function without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636
Adam Butcher changed:
What|Removed |Added
CC|adam at jessamine dot co.uk|abutcher at gcc dot
gnu.org
--- Comment #4 from Adam Butcher ---
(In reply to tower120 from comment #0)
>
> std::cout << if_else(do_first, data,
> [&](auto /*B&*/ data){
> std::cout << std::endl;
> std::cout << std::is_same::value;
> std::cout << std::endl;
>
> return fn1(/*static_cast*/(data));
> },
> [&](A& data){ return fn2(data); }
> );
> }
> };
>
This works if "this->" is used to explicitly specify the object upon which to
call 'fn1'. It works whether or not the static_cast is present or whether auto
or B is is used.
It looks like a binding issue with lambda templates; the name 'fn1' is being
seen as a reference to the member function rather than an attempt to bind it to
the captured 'this' for a member call.
The fact that clang compiles it fine makes me think that this is indeed a
genuine bug and that the extra "this->" qualification is not required by the
language. In dependent base member access, an explicit "this->" is required,
but I don't think it should be necessary here.
I'll have a look into it; but I've limited time to do so at the mo.
[Bug c++/61636] generic lambda "cannot call member function without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636
--- Comment #5 from Adam Butcher ---
In an attempt to get a reduced testcase, I've uncovered an ICE. With the extra
"this->" qualification on the reference to 'f' below, the code compiles fine.
Alternatively, if 'this' is explicitly captured, the unqualified member call
works too. There is clearly something a bit odd going on in this area.
struct X
{
template
void f(T t) {}
template
void g(T t)
{
[&] (auto x) {
f(x);
} (t);
}
};
int main()
{
X x;
x.g(2);
}
:10:10: internal compiler error: Segmentation fault
f(x);
^
0xb8926f crash_signal
../../gcc/toplev.c:337
0x95afe8 contains_struct_check
../../gcc/tree.h:2840
0x95afe8 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/fold-const.c:1471
0x9d0f49 gimplify_compound_lval
../../gcc/gimplify.c:1998
0x9c89ae gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7618
0x9d2808 gimplify_call_expr
../../gcc/gimplify.c:2432
0x9c8b37 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7637
0x9cd306 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5417
0x9c8bc2 gimplify_cleanup_point_expr
../../gcc/gimplify.c:5193
0x9c8bc2 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:8029
0x9cd306 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5417
0x9ce1af gimplify_bind_expr
../../gcc/gimplify.c:1100
0x9c907e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7863
0x9cd306 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5417
0x9cec36 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:8773
0x9cf236 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:8926
0x84d117 analyze_function
../../gcc/cgraphunit.c:650
0x84e3bb analyze_functions
../../gcc/cgraphunit.c:1028
0x84fc45 finalize_compilation_unit()
../../gcc/cgraphunit.c:2333
0x63bece cp_write_global_declarations()
../../gcc/cp/decl2.c:4647
[Bug libstdc++/61728] New: [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj@@CXXABI_1.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61728 Bug ID: 61728 Summary: [4.10 regression] lost symbol FUNC:_ZNK10__cxxabiv117__pbase_type_info15__pointer_ca tchEPKS0_PPvj@@CXXABI_1.3 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org r212174 removed _ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj from the libstdc++ ABI.
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #12 from Joshua Kinard ---
So I discovered the presence of the --disable-linux-futex configure flag,
rebuilt gcc-4.9.0 with it, and tested my conftest.c testcase, and can confirm
that the resulting binary no longer hangs on a futex syscall. It still calls
futex twice somewhere in the call chain, but that's probably expected behavior
or a different library (pthreads?):
set_tid_address(0x77256068) = 10805
set_robust_list(0x77256070, 12) = 0
futex(0x7fcb46b8, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fcb46b8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 0) =
-1 EINVAL (Invalid argument)
rt_sigaction(SIGRT_0, {0x8, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205b94}, NULL, 16) = 0
rt_sigaction(SIGRT_1, {0x1008, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205a34}, NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 16) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=2147483647}) = 0
futex(0x771fb9a0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x771fb9a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
exit_group(0) = ?
+++ exited with 0 +++
So, not the ideal solution, as I assume under a Linux kernel, there is some
advantage to using the futex syscall within gcc, but I don't know how that will
affect things. I'll try to compile glibc-2.19 with gcc-4.9.0 and see if the
'sln' static binary also hangs with this change.
[Bug c++/61636] generic lambda "cannot call member function without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636
Adam Butcher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-07-06
Assignee|unassigned at gcc dot gnu.org |abutcher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #6 from Adam Butcher ---
Reduced testcase:
struct X
{
template
void f(T t) {}
auto defer_f()
{
return [&] (auto x) {
f(x);
};
}
};
int main()
{
X x;
x.defer_f()(2);
}
Compiles if "this->f(x)" is used within 'defer_f'.
[Bug target/61729] New: FAIL: g++.dg/abi/scoped1.C -std=gnu++11 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61729
Bug ID: 61729
Summary: FAIL: g++.dg/abi/scoped1.C -std=gnu++11 execution
test
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target: powerpc-*-*
This fails only for -m32, not for -m64.
$ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/abi/scoped1.C -nostdinc++
-Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux
-Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++
-I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util
-std=gnu++11 -fabi-version=0 -Wabi=2
-Lpowerpc64-linux/32/libstdc++-v3/src/.libs
-Bpowerpc64-linux/32/libstdc++-v3/src/.libs
-Lpowerpc64-linux/32/libstdc++-v3/src/.libs -lm -m32 -o ./scoped1.exe -g
../gcc/testsuite/g++.dg/abi/scoped1.C: In function ‘int main()’:
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
f(9, A::a1, A::a2, A::a3, A::a1, A::a2, A::a3, A::a1, A::a2, A::a3); // {
dg-warning "passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C:22:69: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
../gcc/testsuite/g++.dg/abi/scoped1.C: In function ‘void f(int, ...)’:
../gcc/testsuite/g++.dg/abi/scoped1.C:9:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a1) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:10:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a2) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:11:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a3) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:12:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a1) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:13:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a2) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:14:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a3) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:15:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a1) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:16:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a2) __builtin_abort(); // { dg-warning
"passed" }
^
../gcc/testsuite/g++.dg/abi/scoped1.C:17:29: warning: scoped enum ‘A’ passed
through ... as ‘int’ before -fabi-version=6, ‘short int’ after [-Wabi]
if (__builtin_va_arg (ap, A) != A::a3) __builtin_abort(); // { dg-warning
"passed"
[Bug c++/61636] generic lambda "cannot call member function without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636 --- Comment #7 from tower120 --- I'm not sure what you mean, about adding "this->". But this case is not working : http://coliru.stacked-crooked.com/a/d69de477f9a746cb But to be true, it not work with clang either.
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #6 from Trevor Saunders --- > --- Comment #4 from Gary Funck --- > Created attachment 33076 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33076&action=edit > make log after trying patch thanks! I think the attached patch should fix all of those issues, would you mind testing it? Trev
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #7 from Gary Funck --- (In reply to Trevor Saunders from comment #6) > thanks! I think the attached patch should fix all of those issues, would > you mind testing it? Confirmed. With that patch, the stage1 compiler compiled successfully using g++ 4.5.1.
[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-*-* with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61225 --- Comment #10 from zhenqiang.chen at linaro dot org --- Yes. I see. The patch is in review. But no feedback although I had pinged it for three times. https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01325.html I will go on ping it.
[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61640 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Mon Jul 7 03:35:09 2014 New Revision: 212319 URL: https://gcc.gnu.org/viewcvs?rev=212319&root=gcc&view=rev Log: 2014-07-06 Jerry DeLisle Backport from trunk. PR libgfortran/61640 * io/list_read.c (next_char_internal): Adjust the read length to a single wide character. (eat_spaces): Add missing paren. * io/unix.c (mem_read4): Use the correct mem_alloc function for wide character internal reads. Modified: branches/gcc-4_9-branch/libgfortran/ChangeLog branches/gcc-4_9-branch/libgfortran/io/list_read.c branches/gcc-4_9-branch/libgfortran/io/unix.c
[Bug libfortran/61499] [4.9/4.10 Regression] Internal read of negative integer broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle --- Fixed and Closing
[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61640 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Mon Jul 7 03:58:16 2014 New Revision: 212321 URL: https://gcc.gnu.org/viewcvs?rev=212321&root=gcc&view=rev Log: 2014-07-06 Jerry DeLisle Backport from mainline. PR libgfortran/61640 * gfortran.dg/arrayio_16.f90: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/arrayio_16.f90 Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61640 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerry DeLisle --- Fixed and Closing
[Bug libfortran/61640] KIND=4 Character Array Internal Unit Read Fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61640 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Mon Jul 7 04:22:29 2014 New Revision: 212322 URL: https://gcc.gnu.org/viewcvs?rev=212322&root=gcc&view=rev Log: 2014-07-06 Jerry DeLisle PR libgfortran/61640 * gfortran.dg/arrayio_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/arrayio_16.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/61730] New: Cygwin AVX __m256i return value misaligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61730 Bug ID: 61730 Summary: Cygwin AVX __m256i return value misaligned Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland at rschulz dot eu Created attachment 33079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33079&action=edit Testcase which segfaults on Cygwin because of incorrect alignment The attached testcase segfault compiled with gcc 4.8.3 on Cygwin. It is fine when run&compiled on Linux and MingW. The debugger shows that it segfaults on vmovdqa generated for the return of type __m256i, because memory isn't aligned. Compiled with: g++ -mavx test2.cc.i -g Possible duplicates (reason why I think it probably isn't in parentheses): 16890 (this is suppose to be fixed, so I don't think it is a duplicate) 33774 (the subject says Cygwin/mingw but the text only mentions mingw - and this is only Cygwin)
