--- Comment #14 from truedfx at gentoo dot org 2010-08-10 05:59 ---
In the original code, the patch fixes the problem too. Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-08-10 05:49
---
> Does anyone know which combination of recent commits is causing this problem?
The set of RTH's patches. Configure --with-tune=i686 to work around it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
--- Comment #1 from gekus at aha dot ru 2010-08-10 05:16 ---
Created an attachment (id=21445)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21445&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45245
g++ -c -Wno-multichar -fexceptions -g3 -D_MT -DNDEBUG -O3
-funsafe-loop-optimizations -Wunsafe-loop-optimizations -static -v -save-temps
-DTESTINETD -fnon-call-exceptions -I. -I../Common -o ./GNURelease/DelaydSQL.o
DelaydSQL.cpp
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-10 04:29 ---
*** This bug has been marked as a duplicate of 45182 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-10 04:29 ---
*** Bug 45242 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-10 02:54 ---
Does anyone know which combination of recent commits
is causing this problem? I've tried individually backing
out several of the likely offenders, but I still can't
bootstrap. So, I'm guessing that I need to back ou
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-10 02:37 ---
Created an attachment (id=21444)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21444&action=view)
Reduced testcase
Reduced testcase. gdb shows
Program received signal SIGSEGV, Segmentation fault.
0x080ed4c0 i
--- Comment #1 from Eric dot Zurcher at csiro dot au 2010-08-10 02:16
---
The FORTRAN code given below causes gfortran to fail with the message:
f951.exe: internal compiler error: Segmentation fault
I have tested this using the Mingw32 version of gfortran 4.5.0, and version
4.3.2 on SU
--
Summary: Incorrect passing of character string array argument
triggers an internal compiler error
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
--- Comment #4 from china dot wenli dot wang at gmail dot com 2010-08-10
01:07 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Thank you,yeah,the code is not a self-contained testcase.I copile it with
> > another codes which not show here.
>
> Yes, but we don't want to see
--- Comment #7 from dodji at gcc dot gnu dot org 2010-08-09 23:56 ---
Created an attachment (id=21443)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21443&action=view)
Candidate patch
I am testing this patch atm that seems to be working for now.
--
dodji at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-09 23:12 ---
Works with -O2 which means LIM is not working at -Os for some reason.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
void foo (int& sz, int n)
{
for (++n; --n;)
sz += 5;
}
Produces (-Os):
_Z3fooRii:
incl%esi
jmp .L2
.L3:
addl$5, (%rdi)
.L2:
decl%esi
jne .L3
ret
gcc thinks that every little change to sz needs to be stored in memory,
--- Comment #16 from tkoenig at gcc dot gnu dot org 2010-08-09 22:56
---
(In reply to comment #15)
> Here's another case where we generate a temporary:
>
> program main
> integer a(100)
> a(10:16) = a(11:17:1)
> end program main
Here's a tentative patch:
Index: dependency.c
--- Comment #29 from LpSolit at netscape dot net 2010-08-09 22:21 ---
(In reply to comment #28)
> I think you should probably set yourself up an account on sourceware.
> Fill out this form: http://sourceware.org/cgi-bin/pdw/ps_form.cgi and
> list me as your referrer.
Done! I selected "s
--- Comment #4 from eric_moyer at yahoo dot com 2010-08-09 22:10 ---
That is great to hear. I've wanted this feature for years (but never took the
time to create a bugzilla account.) Thank you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45203
--- Comment #15 from tkoenig at gcc dot gnu dot org 2010-08-09 21:54
---
Here's another case where we generate a temporary:
program main
integer a(100)
a(10:16) = a(11:17:1)
end program main
i...@linux-fd1f:~/Krempel/Dep-9> gfortran -Warray-temporaries d1.f90
d1.f90:3.13:
a(10:1
--- Comment #12 from rodolfo at rodsoft dot org 2010-08-09 21:35 ---
Thanks for the quick fix, I have already recompiled gcc and now it compiles the
snippets I've posted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45236
--- Comment #4 from steven at gcc dot gnu dot org 2010-08-09 21:32 ---
This blocks 17982. There are assemble_external calls are for
objc_get_class_decl, objc_assign_global_decl, and objc_assign_strong_cast_decl.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-09 21:28 ---
(In reply to comment #2)
> I want to disable warnings for particular lines of code rather than whole
> files.
See
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas
And
http://gcc.gnu.org
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-09 21:19 ---
Fixed by:
gcc/objc/
PR objc/44140
(init_objc_symtab): Use integer_zero_node, make the short
integer type specific on relevant nodes.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #11 from jason at gcc dot gnu dot org 2010-08-09 21:14 ---
Fixed for 4.6.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from jason at gcc dot gnu dot org 2010-08-09 21:13 ---
Subject: Bug 45236
Author: jason
Date: Mon Aug 9 21:13:12 2010
New Revision: 163042
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163042
Log:
PR c++/45236
* pt.c (lookup_template_class): Don
--- Comment #34 from steven at gcc dot gnu dot org 2010-08-09 21:13 ---
The FIXME here is this one in varasm.c:
---
/* We delay assemble_external processing until
the compilation unit is finalized. This is the best we can do for
right now (i.e. stage 3
--- Comment #12 from tkoenig at gcc dot gnu dot org 2010-08-09 19:35
---
Subject: Bug 44235
Author: tkoenig
Date: Mon Aug 9 19:34:49 2010
New Revision: 163041
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163041
Log:
2010-08-09 Thomas Koenig
PR fortran/44235
--- Comment #5 from ubizjak at gmail dot com 2010-08-09 18:24 ---
(In reply to comment #4)
> Fixed.
Confirmed fixed on alpha [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg00932.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45212
Recent regression with trunk revision 163037
> cat bug.f90
SUBROUTINE dbcsr_sort_indices(n,row_i, col_i)
INTEGER, DIMENSION(1:n), INTENT(INOUT) :: row_i, col_i
row_i(:) = ISHFT(row_i(:), 16) + col_i
END SUBROUTINE dbcsr_sort_indices
> gfortran -c -O3 bug.f90
bug.f90: In function
--- Comment #1 from changpeng dot fang at amd dot com 2010-08-09 17:52
---
This patch should be a valid fix, because the recognition of the dot_prod
pattern is known to be fail at this point if the stmt is outside the loop.
(I am not sure whether we should not see this case in the vecto
With gcc 4.6:
gfortran -c -o diis.fppized.o -O3 -fno-tree-pre -march=amdfam10 -m64
diis.fppized.f90
diis.fppized.f90: In function 'extrapolate':
diis.fppized.f90:882:0: internal compiler error: vector VEC(vec_void_p,base)
index domain error, in vinfo_for_stmt at tree-vectorizer.h:595
Please submi
--- Comment #13 from truedfx at gentoo dot org 2010-08-09 17:44 ---
Thanks, that seems to work for me too for the reduced code. I'll test the
original larger code that was failing too, but that'll take a little longer for
me to report back anything.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-09 17:44
---
Ah, DR 691!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45236
--- Comment #8 from jason at gcc dot gnu dot org 2010-08-09 17:42 ---
Wait, no, I was misreading your testcase; it doesn't have a pack expansion as a
template argument, so it ought to work.
--
jason at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-09 17:41 ---
(In reply to comment #0)
> The problem is in check_variable() in check.c. The first if-statement
> prevents the second one from being reached.
Right. However, exchanging them produces lots of regressions, since the i
In parallel.c, if HAVE_SYNC_BUILTINS is #undef'ed, then GOMP_parallel_end uses
a mutex to atomically modify the team->nthreads field. The mutex that is used
to atomically write to nthreads is locked but never unlocked.
parallel.c, GOMP_parallel_end:
#ifdef HAVE_SYNC_BUILTINS
__sync_fet
With gcc 4.6:
gfortran -c -o diis.fppized.o -O3 -fno-tree-pre -march=amdfam10 -m64
diis.fppized.f90
diis.fppized.f90: In function 'extrapolate':
diis.fppized.f90:882:0: internal compiler error: vector VEC(vec_void_p,base)
index domain error, in vinfo_for_stmt at tree-vectorizer.h:595
Please submi
--- Comment #7 from jason at gcc dot gnu dot org 2010-08-09 17:36 ---
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#691
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45236
--- Comment #6 from jason at gcc dot gnu dot org 2010-08-09 17:34 ---
14.1 paragraph 11 says,
If a template-parameter of a class template is a template parameter pack, it
shall be the last template-parameter.
This isn't quite right: what we really want to require is that if a
partial-s
--- Comment #12 from hjl dot tools at gmail dot com 2010-08-09 17:24
---
Created an attachment (id=21442)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21442&action=view)
A patch
This patch seems to work for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-08-09 17:18
---
Paul, can you send me a preview of the new descriptor structure so I can be
planning the internal unit I/O impacts if any.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128
--- Comment #6 from steven at gcc dot gnu dot org 2010-08-09 17:11 ---
Needs fixing in 4.4 still.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2010-08-09 17:11 ---
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg01067.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-09 17:01
---
(In reply to comment #9)
> Does this patch:
>
> --
> diff --git a/gcc/calls.c b/gcc/calls.c
> index cd0d9c5..cbb0944 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -2846,7 +2846,8 @@ expand_call (tree exp, rt
--- Comment #10 from truedfx at gentoo dot org 2010-08-09 16:58 ---
I had already tried simply commenting out the assert, and that caused wrong
code, so changing the assert without anything else won't help :)
FWIW, I now also checked the code difference between alloca(2) and alloca(6)
w
--- Comment #9 from hjl dot tools at gmail dot com 2010-08-09 16:38 ---
Does this patch:
--
diff --git a/gcc/calls.c b/gcc/calls.c
index cd0d9c5..cbb0944 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2846,7 +2846,8 @@ expand_call (tree exp, rtx target, int ignore)
/* Stack must
--- Comment #8 from hjl dot tools at gmail dot com 2010-08-09 16:28 ---
/* Adjust the stack pointer by minus ADJUST (an rtx for a number of bytes).
This pushes when ADJUST is positive. ADJUST need not be constant. */
void
anti_adjust_stack (rtx adjust)
{
rtx temp;
if (adjust =
--- Comment #4 from armin76 at gentoo dot org 2010-08-09 16:28 ---
Could this be backported to gcc-4.4 branch, please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41551
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-09 16:19 ---
__builtin_alloca (var) is handled properly. __builtin_alloca (const int)
is a special case. I am looking into it now.
--
hjl dot tools at gmail dot com changed:
What|Removed |A
--- Comment #6 from truedfx at gentoo dot org 2010-08-09 16:15 ---
With those two lines removed from 4.5.0, it looks like the stack will be
aligned properly by accident. When changing __builtin_alloca (2) to
__builtin_alloca (6), the only thing that changes in the generated code is
@@ -
libgo fails to build. Here's the error output:
gmake[4]: Entering directory
`/usr/home/chris/gnuobj/gccgo/i386-unknown-freebsd8.1/libgo'
rm -f syscall.gox syscalls/libsyscall.a
test -d syscalls || mkdir -p syscalls
files=`echo ../../../../gnusrc/gccgo/libgo/syscalls/errstr.go
../../../../gnusrc/
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in expand_call, at |[4.4 Regression] ICE in
|calls.c:2845 when passing
--- Comment #9 from froydnj at gcc dot gnu dot org 2010-08-09 15:58 ---
r114528 and r114655 have been committed as r163033.
r114348, r114396, and r116014 have been committed (no revisions, but I have
them crossed off on my local list).
FWIW, everything after r116179 is irrelevant for b
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-09 15:51 ---
(In reply to comment #4)
> H.J, this was introduced by your commit:
>
...
>
> By backing out lines marked as ***, compilation succeeds.
>
Can you take a look at the assembly output to see if
the stack is realigne
--- Comment #4 from ubizjak at gmail dot com 2010-08-09 15:24 ---
H.J, this was introduced by your commit:
138808hjl /* Ensure current function's preferred stack boundary is at
least
138808hjl what we need. Stack alignment may also increase
preferred stack
138808
--- Comment #4 from bernds at gcc dot gnu dot org 2010-08-09 15:04 ---
I'm reopening this as it's not fixed, and even if we fix it in the RTL
optimizers, it should stay open as a reminder that we produce poor initial RTL.
--
bernds at gcc dot gnu dot org changed:
What
--- Comment #2 from brtnfld at hdfgroup dot org 2010-08-09 15:02 ---
If the type declaration is moved to the module scope the code compiles.
MODULE liter_cb_mod
USE ISO_C_BINDING
TYPE, BIND(C) :: MYFTYPE
INTEGER(C_INT) :: I, J
REAL(C_FLOAT) :: S
END TYPE MYFTYPE
CONTAINS
FUNCT
--- Comment #5 from rodolfo at rodsoft dot org 2010-08-09 14:38 ---
And I think that the original intent of the attached code (as I wrote in the
summary) was lost when I tried to reduce it. Here's the original version:
//
template class foo;
templat
--- Comment #4 from rodolfo at rodsoft dot org 2010-08-09 14:24 ---
Well, this compiles:
template struct A {};
template struct B {};
template struct C {};
template struct foo;
template class A,
template class B,
template class C,
int...II, int J, int...K
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-09 14:20
---
This is certainly correct, and works as expected:
template struct foo;
template class C, int... II>
struct foo>
{
struct bar {};
};
template
struct A {};
foo<4, A<3>>::bar x;
--
http://gcc.gnu.org/
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-09 14:18
---
To me:
template class C, int... II, int S>
with the variadic II in the middle and S without a default, seems badly
illegal. Jason, should we immediately produce a meaningful error when we see
it?
--
pao
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-09 14:11
---
I would say the problem isn't about "access" (even in non-technical sense),
instead that the specialization itself isn't considered: indeed, if you comment
it out, the error is exactly the same.
--
http://
When I attempt to build gcc 4.5.1 or a recent 4.5 snapshot on an x86_64
workstation running SuSE Linux 11.3 I get the following messages:
gcc -c -DHAVE_CONFIG_H -g -fkeep-inline-functions -I.
-I/home/mrichmon/gcc-4.5.1/libiberty/../include -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototype
The following code doesn't compile on gcc-4.4.1, gcc-4.5.0 and gcc-trunk (as of
2010/08/09):
//---
template class foo;
template class C, int... II, int S>
struct foo,S>
{
struct bar {};
};
template
struct A {};
foo, 4>::bar x;
//
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-09 13:56 ---
Probably easier to not set TREE_READONLY or MEM_READONY_P here.
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 163030)
+++ gcc/emit-rtl.c
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-09 13:44
---
Note the specific constructor I mentioned:
// XXX http://gcc.gnu.org/ml/libstdc++/2008-02/msg00047.html
template
tuple(tuple<_UElements...>& __in)
we are *not* talking there about any of the construct
--- Comment #5 from jason at redhat dot com 2010-08-09 13:38 ---
Subject: Re: [C++0x] Can't copy-construct "tuple"
from "const tuple" rvalue
On 08/09/2010 09:31 AM, paolo dot carlini at oracle dot com wrote:
> I'm also thinking that the weird constructor tuple(tuple<_UElements...>&
--- Comment #4 from paolo dot carlini at oracle dot com 2010-08-09 13:31
---
Thanks for the clarification Jason. Indeed, I think the most robust fix is
using SFINAE, and actually we have already quite a bit of language in the FCD
about tuple constuctors vs constraining, I think it's tim
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-08-09 13:31
---
Backports are pre-approved if they pass bootstrap & testing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from jason at redhat dot com 2010-08-09 13:22 ---
Subject: Re: [C++0x] Can't copy-construct "tuple"
from "const tuple" rvalue
For tuple_m, you have a variadic template constructor that can take
*any* arguments whatsoever, and will therefore be a better match than
anyt
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-08-09 13:18
---
Subject: Bug 44632
Author: rguenth
Date: Mon Aug 9 13:18:08 2010
New Revision: 163031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163031
Log:
2010-08-09 Richard Guenther
PR middle-end/44632
--- Comment #1 from bigotp at acm dot org 2010-08-09 11:57 ---
Created an attachment (id=21441)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21441&action=view)
fixes for assumption that readonly means constant
The problem is caused by the same sort of test as was fixed in a diffe
This example is reduced from hardware-specific code that uses memory-mapped
registers to control and sample a logical signal. The read of the input signal
is moved to follow the clear of the output signal, in violation of the
requirements for volatile memory access.
Reproduce with: gcc -S -O2 ir
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-09 11:53 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from rguenther at suse dot de 2010-08-09 11:51 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong
code for complex division
On Mon, 9 Aug 2010, dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-09
>
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-09
11:44 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong
> The following might be a regression:
> Executing on host: /home/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/ho=
> me/dave/gnu/gcc/objdir/./gcc -nostdinc++
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-09 11:43 ---
Subject: Bug 45212
Author: rguenth
Date: Mon Aug 9 11:43:23 2010
New Revision: 163029
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163029
Log:
2010-08-09 Richard Guenther
PR middle-end/45212
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-09
11:37 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong
>
> On Sat, 07 Aug 2010, rguenth at gcc dot gnu dot org wrote:
>
> > So the following should fix this. Can you bootstrap/test this?
Oh, I forgot to say test
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-09
11:35 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong
code for complex division
On Sat, 07 Aug 2010, rguenth at gcc dot gnu dot org wrote:
> So the following should fix this. Can you bootstrap/test this?
--- Comment #2 from paul dot richard dot thomas at gmail dot com
2010-08-09 10:50 ---
Subject: Re: Segmentation fault with -fwhole-file for
subref_array_pointer
Dear Tobias,
> If one now recycles the definition for the array descriptor "desc" this
> information is not presen
--- Comment #5 from michael dot haubenwallner at salomon dot at 2010-08-09
08:49 ---
Well, I'm waiting for this to become fixed, even if it isn't a real blocker
here.
There is a workaround (=ugly hack) using alignment attributes within #ifdef's
for the rare cases where this really is a
--- Comment #8 from fredrik dot hederstierna at securitas-direct dot com
2010-08-09 07:55 ---
I think I found what was the problem, the flags
-mthumb -mcpu=arm966e-s -Os -falign-functions=4
Did not 32-bit-align my thumb->arm trampoline function.
I dont know if -Os win over -falign-fun
--- Comment #13 from paolo dot carlini at oracle dot com 2010-08-09 07:31
---
Any help with it would be appreciated, thanks. In general, if you mean to
contribute it's a good idea to sort out first the Copyright Assignment
paperwork, which is actually very simple but takes time:
http://
82 matches
Mail list logo
