--- Comment #4 from dennis dot wassel at googlemail dot com 2008-07-02
08:54 ---
> (In reply to myself)
> The problem seems to remain the same, regardless of the type of array of XP,
> that is allocatable or fixed-size (compile-time).
> Stupid I didn't check this earlier...
Out of curi
--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-02 09:22 ---
This is caused by the implicit gotos at the end of basic blocks.
See http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01840.html
During cfgexpand this can be IMHO fixed by setting curr_location before
emitting the jump, no
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-02 09:36 ---
This is SCCP. And then both ivcanon and ivopts. Thus,
-fno-tree-scev-cprop -fno-ivopts -fno-tree-loop-ivcanon
fixes it.
Confirmed with -O.
--
rguenth at gcc dot gnu dot org changed:
What|Rem
the following two equivalent functions are compiled into different asm-code.
The bad thing is, that the more readable function (get_and_increment2) creates
worse code. It is bigger and slower. This is because it uses one register more
than the more optimized version get_and_increment1.
struct Int
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-07-02 10:31 ---
*** This bug has been marked as a duplicate of 32187 ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-07-02 10:31 ---
*** Bug 36692 has been marked as a duplicate of this bug. ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
the attached preprocessed source does not compile with g++-4.2. it does compile
with g++-4.0, 4.1 and 4.3, though, so i don't know whether there is any
interest to work on a reduced test case and work on a bug fix ...
from my reading of the compiler error, it has to do with the compiler-generated
--- Comment #1 from tim at klingt dot org 2008-07-02 10:58 ---
Created an attachment (id=15843)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15843&action=view)
compressed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36694
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-07-02 12:34 ---
I caused this.
Here's an obvious patch:
Index: iresolve.c
===
--- iresolve.c (revision 137255)
+++ iresolve.c (working copy)
@@ -106,7 +106,7 @@ res
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
int main() { typedef int& T; T a = T(); }
Compiling the snippet above produces no diagnostic with gcc 4.4.0 20080701 or
gcc 4.1.2. However, reading n2691, 8.5 paragraph 6:
A program that calls for default-initialization or value-initialization of an
entity of reference type is ill-formed.
I'm pr
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-07-02 14:20
---
OK to commit after testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36681
Compile following with -Wall:
#include
class Raii
{
public:
Raii () throw ()
{
std::cout << "Raii::Raii () called..." << std::endl;
}
public:
~Raii () throw ()
{
std::cout << "Raii::~Raii () called..." << std:: endl;
}
};
int main (int /*argc*/, char** /*
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-07-02 14:27
---
To debug this we will probably need to get remote ssh access to a machine like
this. I can think of three possible causes of the problem at the moment.
1) The executable is accessing the wrong version of libgfor
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-07-02 14:38 ---
Subject: Bug 36681
Author: tkoenig
Date: Wed Jul 2 14:36:58 2008
New Revision: 137355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137355
Log:
2008-07-02 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-07-02 14:38 ---
Subject: Bug 36590
Author: tkoenig
Date: Wed Jul 2 14:36:58 2008
New Revision: 137355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137355
Log:
2008-07-02 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #6 from dennis dot wassel at googlemail dot com 2008-07-02
14:39 ---
(In reply to comment #5)
> 1) The executable is accessing the wrong version of libgfortran. You might
> need to set LD_LIBRARY_PATH.
Nope, everything in order here, as far as I can tell:
isaac:/tmp$ ldd
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-07-02 14:40 ---
Fixed. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-07-02 14:41 ---
Fixed. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from mike dot allen at facsim dot org 2008-07-02 14:41
---
Is the line:
Raii raii();
being interpreted by the compiler as the declaration of a function that takes
no arguments and returns a Raii instance?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36696
--- Comment #3 from wirawan0 at gmail dot com 2008-07-02 14:43 ---
This problem also occurs with gfortran 4.3.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36632
--- Comment #7 from dennis dot wassel at googlemail dot com 2008-07-02
15:00 ---
(In reply to comment #5)
>
> 2) The system has a broken printf or memory allocation.
>
printf seems to be fine. If I compile and link this snippet of C
#include
void cprint_(float *x) {
printf("with pr
I get SIGSEGV when my C and C++ programs exits. I have tracked it down to the
__do_global_dtors_aux function. The newly added code under HIDDEN_DTOR_LIST_END
does not check if the function ptr from the list is 0 - which the old code
below does. On my platform (no-mmu ARM, uclibc, uclinux) at least
The gcc.c-torture/compile/20001226-1.c test case, when compiled with -O0
on the spu-elf target, results in a single function that exceeds local store
size (256 KB) on the SPU. This cannot run (cannot even be linked!); and
because it is a single function, overlay support does not help either.
Thi
--- Comment #1 from uweigand at gcc dot gnu dot org 2008-07-02 15:57
---
Subject: Bug 36698
Author: uweigand
Date: Wed Jul 2 15:56:31 2008
New Revision: 137367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137367
Log:
PR target/36698
* gcc.c-torture/compile/20
--- Comment #2 from uweigand at gcc dot gnu dot org 2008-07-02 15:59
---
Subject: Bug 36698
Author: uweigand
Date: Wed Jul 2 15:58:09 2008
New Revision: 137368
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137368
Log:
PR target/36698
* gcc.c-torture/compile/20
--- Comment #22 from hjl at gcc dot gnu dot org 2008-07-02 16:00 ---
Subject: Bug 36669
Author: hjl
Date: Wed Jul 2 15:59:19 2008
New Revision: 137369
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137369
Log:
gcc/
2008-07-02 H.J. Lu <[EMAIL PROTECTED]>
PR target/36
--- Comment #19 from rwild at gcc dot gnu dot org 2008-07-02 16:11 ---
(In reply to comment #7)
> > >So, you are suggesting that I should remove fPIC option, correct?
> > Yes. Is there a reason why you have CFLAGS set anyways?
> 2. -fPIC has always been set in all the other gcc versio
--- Comment #2 from rwild at gcc dot gnu dot org 2008-07-02 16:12 ---
Please post the compile command and the error.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from tim at klingt dot org 2008-07-02 16:15 ---
compiled via:
g++-4.2 server_dsp_thread_test.ii
error message:
libs/boost/boost/concept_check.hpp: In instantiation of
âboost::CopyConstructible::dummy_runnable>*>â:
libs/boost/boost/concept_check.hpp:154: instantiate
--- Comment #20 from imam dot toufique at intel dot com 2008-07-02 16:17
---
(In reply to comment #19)
> (In reply to comment #7)
> > > >So, you are suggesting that I should remove fPIC option, correct?
> > > Yes. Is there a reason why you have CFLAGS set anyways?
> > 2. -fPIC has alw
try compile:
#include
template
inline
size_t countof ( const T (&) [Count] )
{
return Count;
}
int main(int argc, char* argv[])
{
struct { int x1; int x2;} x [100];
std::cout << countof(x) << std::endl;
int y [101];
std::cout << countof(y) << std::endl;
struct Z { int x1; int x2;
--- Comment #21 from Ralf dot Wildenhues at gmx dot de 2008-07-02 16:46
---
Subject: Re: 4.3.1 failed to compile gcse.c file.
* imam dot toufique at intel dot com wrote on Wed, Jul 02, 2008 at 06:17:59PM
CEST:
> well... when libstdc and other shared libs are built, are they all built
I mistakenly called a function, and broke the compiler:
[EMAIL PROTECTED] ~/MD]$ cat diatoms.f90
module Diatoms
implicit none
contains
function InitialDiatomicX() result (v4)
real(kind=8),dimension(4)::v4
v4=1
end function InitialDiatomicX
subroutine FindDiatomicPeriod
call InitialDiatomicX()
e
Revision 137328 generates unaligned access in
gcc.c-torture/execute/complex-7.c
and revision 137304 is OK. Steve, will your patch
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00884.html
cause this? Thanks.
--
Summary: [4.4 Regression] unaligned access in gcc.c-
--- Comment #1 from sje at cup dot hp dot com 2008-07-02 17:17 ---
I don't see any reason why my patch would cause this problem. Looking through
my old test logs I see this test failing before my patch as well as after it.
The failures go back to version 126651 which is the oldest resu
Bootstrap fails at revision 137369 on i686-apple-darwin9 with:
...
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/i686
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-02 17:49 ---
Can you try
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00127.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-02 18:10 ---
With gfortran 4.1 and 4.2:
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in
'initialdiatomicx' at (1)
The same error is also shown for the following - also 4.3/4.4 do so:
print *, foo()
call foo(
--- Comment #2 from hjl at gcc dot gnu dot org 2008-07-02 19:32 ---
Subject: Bug 36702
Author: hjl
Date: Wed Jul 2 19:31:53 2008
New Revision: 137380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137380
Log:
2008-07-02 H.J. Lu <[EMAIL PROTECTED]>
PR boostrap/36702
--- Comment #12 from janus at gcc dot gnu dot org 2008-07-02 19:54 ---
Subject: Bug 32580
Author: janus
Date: Wed Jul 2 19:53:37 2008
New Revision: 137386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137386
Log:
2008-07-02 Janus Weil <[EMAIL PROTECTED]>
Tobias B
--- Comment #13 from janus at gcc dot gnu dot org 2008-07-02 20:19 ---
Fixed with rev 137386. Btw I have also tried compiling the whole CP2K, which
seems to work fine.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from janus at gcc dot gnu dot org 2008-07-02 20:19 ---
Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-07-02 20:20
---
> The fix would be to not propagate the comparisons if they can throw.
OK, thanks for the tip. The patch to convert Ada to a canonical boolean type
is written though (and eliminates the ICE as expected), I'm jus
http://groups.google.com/group/comp.lang.fortran/msg/b600c081a3654936
compiling attached program causes a segfault.
$ gfortran -c -fcray-pointer aaa.f90
aaa.f90: In function 'fptr':
aaa.f90:89: internal compiler error: Segmentation fault
==4019== Invalid read of size 4
==4019==at 0x40327E: r
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-02 20:26 ---
Created an attachment (id=15844)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15844&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36703
Remaining item since PR 32580 has been fixed.
Procedure pointers as function result are not yet implemented and currently
rejected.
Short example:
function foo() result(bar)
procedure() :: bar
and
function foo()
procedure() :: foo
Long example:
http://groups.google.com/group/comp.lang.for
save :: p
procedure() :: p
pointer :: p
end
Error: PROCEDURE attribute conflicts with SAVE attribute in 'p' at (1)
Problem: The SAVE + PROCEDURE checking comes too early before the POINTER is
seen. I think this program is valid.
Analogously:
subroutine bar(x)
procedure(), intent(in) :: x
poin
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-02 20:52 ---
I cannot find my patch any more so unassigning.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from dseketel at redhat dot com 2008-07-02 21:09 ---
Yes, foo bar (); is indeed the declaration of a function bar of type foo that
takes no arguments in parameter.
I believe gcc is right there.
--
dseketel at redhat dot com changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-02 21:16 ---
This is an ambiguous in the C++ standard that is resolved via making it a
function declaration.
That is:
Raii raii ();
Is declaring a function, raii, that returns a Raii type.
--
pinskia at gcc dot gnu dot o
--- Comment #2 from dseketel at redhat dot com 2008-07-02 22:19 ---
Hello,
I have sent a patch to the list at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00160.html.
Hopefully that patch should fix this issue.
--
dseketel at redhat dot com changed:
What|Removed
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-07-02 22:32
---
Subject: Bug 36285
Author: hutchinsonandy
Date: Wed Jul 2 22:31:11 2008
New Revision: 137396
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137396
Log:
PR testsuite/36285
* gcc.dg/compat/struct-by-v
I've built linux-2.6.24 for arm using gcc-4.3.1 and while it builds fine, the
resulting binary doesn't boot on qemu. If I build the same kernel with
gcc-4.2.4 it boots correctly.
The problem seems to be that the prefetch function
(linux-2.6.24/include/asm-arm/processor.h) causes a crash if it is c
--- Comment #1 from chris dot steel dot lnx at googlemail dot com
2008-07-02 22:36 ---
Created an attachment (id=15845)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15845&action=view)
kernel config to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36706
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-02 22:44 ---
The use of "o" is most likely wrong here and most likely not a GCC issue as you
are saying you access the memory when in reality you don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36706
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-02 22:46 ---
Yes o is wrong here. THis is not a GCC bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-02 22:47 ---
"o" means any offsetable memory operand so GCC thinks you are accessing memory
that will always be valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36706
I haven't found anything about this in Bugzilla or tried 4.3.1:
$ cat t.cpp && g++ -std=gnu++0x t.cpp
template void foo (T&& x) { x = T (); }
int main () {
int i;
foo (i);
}
t.cpp: In function void foo(T&&) [with T = int&]:
t.cpp:5: instantiated from here
t.cpp:1: internal compiler e
--- Comment #7 from widman at gimpel dot com 2008-07-03 01:40 ---
(In reply to comment #3)
Hi all,
I happen to be looking at something related to this issue and encountered this
GCC bug, so I thought I'd offer my observations.
> [EMAIL PROTECTED] wrote:
> | Something seems inde
I think this code is syntactically correct, but can cause problems in
debugging. If you don't scrutinize the code too carefully you can waste time
here - code was a cut and paste from strcpy to integer assignment with
resultant comma not changed to assignment.
// this code does nothing !
f -> fo
Since J is already defined, the namespace declaration should generate an error
("int J; namespace J{}" does generate an error). G++ gets confused with the g()
call and instead of generating an error it passes the problem to the assembler.
main.cpp:
struct J {
static void g() {}
};
namespace J
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-03 02:50 ---
-Wunused-value should warn about this ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36708
--- Comment #9 from ubizjak at gmail dot com 2008-07-03 06:09 ---
(In reply to comment #8)
> current trunk (actually a few days old) doesn't fail anymore. The script used
> for testing actually has ulimit -s 128000 which is pretty high. I tested with
> ulimit -s 32000 and ulimit -s 6400
64 matches
Mail list logo
