--- Comment #3 from abel at gcc dot gnu dot org 2009-12-24 07:39 ---
The problem was that the failing assert is actually too strict, when an empty
block is removed, its predecessor could be outside the region. After fixing
this, I have also further robustified the function to expect emp
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-12-24 05:40 ---
Here is a reduced testcase without the include:
struct complex
{
complex(float b = 0.0, float c = 0.0) { __real__ a = b; __imag__ a = c; }
_Complex float a;
};
struct A {
virtual int value() const=0;
};
stru
--- Comment #3 from michael at jarvis dot net 2009-12-24 05:13 ---
Created an attachment (id=19385)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19385&action=view)
full g++ -v output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
--- Comment #2 from michael at jarvis dot net 2009-12-24 05:12 ---
Created an attachment (id=19384)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19384&action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
--- Comment #1 from michael at jarvis dot net 2009-12-24 05:12 ---
Created an attachment (id=19383)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19383&action=view)
source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
The following very simple program is giving me a warning with g++ 4.4.2 with
-Wall (or -Wstrict-aliasing=1, 2 or 3). I don't think it should be giving the
warning, so I think this is a bug.
Replacing std::complex with a simple user-defined complex-like class makes the
warning go away, so maybe t
..
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20091223/gcc-4.5-20091223/gcc/testsuite/gcc.dg/debug/dwarf2/aranges-fnsec-1.c
-gdwarf-2 -ffunction-sections -w -dA -S -o aranges-fn
The new testcase...
FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
fails on x86_64-apple-darwin10...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/
/sw/src/fink.build
0) at
../../gcc-4.5-20091223/gcc/tree-ssa-loop-manip.c:425
425 }
#0 check_loop_closed_ssa_use (bb=0x141e793a8, use=0x141e90160) at
../../gcc-4.5-20091223/gcc/tree-ssa-loop-manip.c:425
#1 0x0001007b9010 in verify_loop_closed_ssa () at
../../gcc-4.5-20091223/gcc/tree-ssa-loop-manip.c:4
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-24
02:37 ---
Still fails on x86_64-apple-darwin10 at r155434...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc45-4.4.999
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-12-24
02:34 ---
The pr42334-1.f test case fails as...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc45-4.4.999-20091223
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-24
02:29 ---
On x86_64-apple-darwin10, the two new test cases are cause ICEs...
FAIL: gfortran.dg/graphite/pr42334-1.f -O (internal compiler error)
FAIL: gfortran.dg/graphite/pr42334-1.f -O (test for excess errors)
--- Comment #1 from carrot at google dot com 2009-12-24 01:47 ---
Created an attachment (id=19381)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19381&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42486
Compile the attached source code with options -Os -mthumb, gcc generates:
sort_basket:
push{r4, r5, r6, r7, lr}
sub sp, sp, #20
str r1, [sp, #8] // A
b .L10
.L13:
mov r0, r4
.L10:
ldr r1, [sp, #8]
add r3,
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-12-24
01:35 ---
Note that gcc.dg/graphite/block-4.c also ICEs with essentially the same
backtrace...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999
lst_interchange_select_inner (scop=, outer_father=, outer=, inner_father=) at ../../gcc-4.5-20091223/gcc/graphite-interchange.c:706
706 for (inner = 0; VEC_iterate (lst_p, LST_SEQ (inner_father), inner,
l); inner++)
(gdb) bt
#0 0x0001004e17e8 in lst_interchange_select_inner (scop=, outer_father=, outer
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-12-24
01:26 ---
I still get an ICE on x86_64-apple-darwin10 at r155434 as...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir
Starting at GCC 4.4.0, the -V switch doesn't work:
$ gcc-4.1 -V4.3 -dumpversion
4.3.4
$ gcc-4.4 -V4.3 -dumpversion
$
--
Summary: [4.4 regression] -V switch broken
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:20 ---
Problem doesn't exist for -O1 -fgraphite-identity on x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:18 ---
Created an attachment (id=19380)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19380&action=view)
assembly from 'gfortran -O2 -fgraphite-identity air.f90 --save-temps -o air' on
x86_64-apple-darwin10
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:15 ---
Still broke on x86_64-apple-darwin10.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:14 ---
This still appears to be broken at r155434 on x86_64-apple-darwin10 with...
gfortran -O2 -fgraphite-identity air.f90 -o air
./air
AIRFLOW IN A BOX
Version 2.0
(c) Hanley Innovatio
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 23:47 ---
When GCC supports C++ attributes you could get the diagnostics you want like
this:
class A_noconst [[base_check]] : public A {
...
};
class A_const [[base_check]] : public A {
...
};
c.f. http://www.open-std.org/jtc1
--- Comment #41 from dominiq at lps dot ens dot fr 2009-12-23 23:34 ---
With the patch in comment #38, the tests fail:
[karma] f90/bug% gfcp -O3 where_2.f90
[karma] f90/bug% a.out
100 100 100 210 210 210
310 337
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-23 23:31 ---
*** This bug has been marked as a duplicate of 189 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from redi at gcc dot gnu dot org 2009-12-23 23:31 ---
*** Bug 37350 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-23 23:00
---
Dodji, is this just a duplicate of PR38600?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40044
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-23 22:59
---
*** Bug 36236 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-23 22:59
---
*** This bug has been marked as a duplicate of 38600 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from anlauf at gmx dot de 2009-12-23 22:39 ---
Note that I personally would declare sub as generic in mod1, e.g.
module mod1
interface sub
module procedure sub
end interface
contains
subroutine sub(x)
real x
end subroutine sub
end module mod1
and remove
--- Comment #1 from anlauf at gmx dot de 2009-12-23 22:31 ---
(In reply to comment #0)
Funny, ifort 11.1, xlf 12.1.0.5 and Sunstudio 12.1 accept the code,
but nagfor 5.2 rejects it with:
NAG Fortran Compiler Release 5.2(686)
Warning: prog.f90, line 23: Unused dummy variable X
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-23 22:25 ---
the original testcase now gives:
pr36236.cc: In function int main():
pr36236.cc:21:11: sorry, unimplemented: mangling template_id_expr
pr36236.cc:21:11: sorry, unimplemented: mangling template_id_expr
and the one in
Consider the following Fortran snippet:
subroutine sub
integer :: nRead
!$omp critical
if (nRead<3) return
!$omp end critical
end subroutine
Compiling this with "gfortran -fopenmp" results in a segfault (with 4.4.1 and
current trunk on x86_64-unknown-linux-gnu). The backtrace
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
CC||redi at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-23 21:17 ---
A recent 4.5.0 doesn't accept this:
pr33041.cc: In function int main():
pr33041.cc:20:26: error: no match for operator<< in std::cout <<
foo::foo
compilation terminated due to -Wfatal-errors.
Adding some parenth
--- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01 ---
Since LTO tree dump is quite different, can't we give it a different
command line option, something like -fdump-tree-lto-all, instead of
enabling it with -fdump-tree-all?
--
http://gcc.gnu.org/bugzilla/show_bug.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-23 20:12 ---
It is caused by revision 153958:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00176.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from davidxl at gcc dot gnu dot org 2009-12-23 19:37 ---
This bug is ARM specific (thumb) mode. In x86, the hoisting is unnecessary as
the move instruction support the imm form.
The issue here is more in the GIMPLE canonicalization (target specific). In
this case, the IR
Hi
Sorry if I'm asking on the wrong mailinglist,
but I've asked on various forums and I havn't found a solution.
I can't read files larger than 2 gig on my ubuntu64bit using 'read()',
the problem is not related to the allocation itself, which works.
Attached is a sample program that illustrates th
--- Comment #6 from spop at gcc dot gnu dot org 2009-12-23 18:27 ---
Seems like this is fixed by the patch from PR42221.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-23 18:15 ---
This used to work on 2009-10-15 on the graphite branch.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-23 18:11 ---
The testcase fails without graphite at -O0, probably a problem in the C++
front-end:
stopping the execution randomly, I get the following backtraces:
#0 0x00660ccc in structural_comptypes (t1=0x7f097e143690,
t
When LTO is enabled AVR fails all whopr/lto tests:
Testsuite fails all lto/whopr tests:
Example:
Executing on host: /media/verbatim/gcchead/obj-dir/gcc/xgcc
-B/media/verbatim/gcchead/obj-dir/gcc/
/media/verbatim/gcchead/trunk/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1.c
/media/verbatim/
--- Comment #9 from spop at gcc dot gnu dot org 2009-12-23 17:37 ---
The testcase still fails with -fgraphite-identity.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from wouter dot vermaelen at scarlet dot be 2009-12-23
17:21 ---
Seems this problem got introduced in revision 152492 (152491 still works,
152492 shows the problem).
2009-10-06 Martin Jambor
PR bootstrap/41395
* opts.c (decode_options): Run IPA-SRA a
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-23 17:09 ---
Fixed in 4.4/4.5.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-23 17:09 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-23 17:07 ---
Subject: Bug 42475
Author: jakub
Date: Wed Dec 23 17:07:04 2009
New Revision: 155431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155431
Log:
PR rtl-optimization/42475
* combine.c (make_compo
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-23 17:04 ---
Subject: Bug 42475
Author: jakub
Date: Wed Dec 23 17:04:07 2009
New Revision: 155430
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155430
Log:
PR rtl-optimization/42475
* combine.c (make_compo
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-23 16:54 ---
Subject: Bug 42454
Author: jakub
Date: Wed Dec 23 16:54:35 2009
New Revision: 155429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155429
Log:
PR debug/42454
* dwarf2out.c (add_ranges_by_label
--- Comment #5 from ramana at gcc dot gnu dot org 2009-12-23 16:37 ---
Fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from ramana at gcc dot gnu dot org 2009-12-23 16:36 ---
Subject: Bug 42093
Author: ramana
Date: Wed Dec 23 16:36:40 2009
New Revision: 155428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155428
Log:
Fix PR target/42093
2009-12-23 Ramana Radhakrishnan
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-23 16:29 ---
Subject: Bug 40670
Author: ramana
Date: Wed Dec 23 16:29:12 2009
New Revision: 155427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155427
Log:
Pass floating point constant moves to integer registers
as mov
--- Comment #6 from viriketo at gmail dot com 2009-12-23 15:34 ---
Done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
On Linux/Intel64, revision 155424 gave:
FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
FAIL: g++.dg/graphite/pr41305.C (test for excess errors)
FAIL: g++.dg/graphite/pr42130.C execution test
FAIL: gcc.dg/graphite/pr40281.c (test for excess errors)
FAIL: gfortran.dg/graphite/pr42393.f90
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-23 15:25 ---
Can't see anything in the backend that does CFI in prologue and epilogue for
the ARM port. Reclassifying as a target bug rather than a debug bug.
--
ramana at gcc dot gnu dot org changed:
What|Remo
! In this program, gfortran fails to identify the generic interface sub for
! sub_int. The compiler gives this error message:
!
! > gfortran prog.f90
! prog.f90:40.9:
!
! call sub(1)
! 1
! Error: Type mismatch in argument 'x' at (1); passed INTEGER(4) to REAL(4)
!
! However, if the use st
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-12-23 15:20
---
Fixed by Paul's patch:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00378.html
Prior to this patch, when debugging the testcase I see:
(gdb)
subfunc (a=492, b=2097148, c=0, d=...) at test.c:9
9 pr
--- Comment #5 from ramana at gcc dot gnu dot org 2009-12-23 15:12 ---
(In reply to comment #4)
> Created an attachment (id=19267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19267&action=view) [edit]
> Fix for libmudflap + libstdc++v3 for gcc 4.4.2
>
> In gcc 4.4.2, libstdc++v3
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2009-12-23
15:04 ---
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01081.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
--- Comment #40 from irar at il dot ibm dot com 2009-12-23 14:49 ---
(In reply to comment #39)
> I have regtested the patch in comment #31 and I have ~75 regressions on
> x86_64-apple-darwin10 in the gcc vect test suite (~100 on
> powerpc-apple-darwin9). Is this expected? and do you want
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-23 14:43 ---
(In reply to comment #1)
> Shouldn't the "openmp" keyword
> (http://gcc.gnu.org/bugzilla/describekeywords.cgi) be sufficient?
Yes it should ...
--
pinskia at gcc dot gnu dot org changed:
What|Rem
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-23 14:37 ---
Note -Wunreachable-code has since ben removed from the trunk ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-23
14:10 ---
Current behavior is correct.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
-
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-23
14:09 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00998.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42307
--- Comment #39 from dominiq at lps dot ens dot fr 2009-12-23 14:09 ---
With the patch in comment #37, the tests pass, but are not vectorized. I did a
mistake after applying the patch in comment #38 and I am doing a "quick"
bootstrap (~5h).
I have regtested the patch in comment #31 and
At revision 155425 the executable for air.f90 compiled with "-O2
-fgraphite-identity" gives:
...
ITERATION# TIME FINAL MASS RESIDUAL
14 100.43187820 0.0100 NaN
deltat, final t, iterations
100.00100.4318782042
At revision 155425 the executable for induct.f90 compiled with " -O3
-floop-block" gives:
...
Maximum wand/quad abs rel mutual inductance = 1.84138324899744549E-002
...
instead of
...
Maximum wand/quad abs rel mutual inductance = 5.95379428444659381E-002
...
when compiled with "-O2 -flo
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-23 13:49 ---
Shouldn't the "openmp" keyword
(http://gcc.gnu.org/bugzilla/describekeywords.cgi) be sufficient?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janus at gcc dot gnu dot org 2009-12-23 13:41 ---
*** Bug 42477 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-23 13:41 ---
(In reply to comment #2)
> Dupe of PR30471?
Ah, yes, indeed. The segfault is cured by the workaround from comment #7 of
that PR (i.e. compiling with -fopenmp -static -Wl,--whole-archive -lpthread
-Wl,--no-whole-archiv
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-23 13:32 ---
Dupe of PR30471?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-23 13:29 ---
Btw, one also gets the segfault without actually calling 'omp_get_num_procs':
subroutine s
!$ use omp_lib
!$ print *, 'Number of processors:', omp_get_num_procs()
end subroutine
end
This program can
--
Summary: [meta-bug] gfortran OpenMP bugs
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus
Consider this simple program:
use omp_lib
print *, 'Number of processors:', omp_get_num_procs()
end
After compiling this with "-fopenmp -static -fbacktrace", executing it gives
the output:
Number of processors: 2
Program received signal 11 (SIGSEGV): Segmentation fault.
Backtrace fo
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-12-23 12:08 ---
Part of this appears to be the same exgettext issue as bug 42467.
The rest appears to be option help strings using one or more spaces where
a single TAB should be used:
common.opt:-Wframe-larger-than= Warn if a funct
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-12-23 12:00 ---
This is the same exgettext bug as bug 42467.
*** This bug has been marked as a duplicate of 42467 ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-12-23 12:00 ---
*** Bug 42468 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42467
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-12-23 11:58 ---
The option help string is passed for translation as a whole before
the special interpretation for TAB as described in options.texi:
The help text is automatically line-wrapped before being displayed.
Normally the
Compiling the following code snippet:
int main(int argc, char **argv)
{
int i;
int asize = 3;
int array[3];
for (i = asize - 1; i < asize; i++)
array[i] = 42;
for (i = 0; i < asize; i++)
printf("%i\n", array[i]);
}
with "gc
--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-23 11:14 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 11:09 ---
C++ is not java, you cannot delegate to another constructor like this:
primes::primes(ulong p):maxp(p) { primes(); }
That creates a temporary object of type primes, it does not call the
constructor.
Therefore primes:
--- Comment #8 from redi at gcc dot gnu dot org 2009-12-23 11:02 ---
See http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/cwg_defects.html#329
I believe a "use" of the function must come after the definition for it to be
instantiated, indeed if I add this after the explicit instant
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 10:41 ---
4.1.0 is no longer supported, but in any case I get a warning for this, just
use -Wreturn-type or -Wall
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 10:30 ---
The code should not compile, Visual Studio is wrong.
Base b = 5;
is a copy initialization, equivalent to
Base b = Base(5);
which requires a copy constructor, but your copy constructor takes a non-const
Base& and
--- Comment #3 from ubizjak at gmail dot com 2009-12-23 09:57 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01067.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-23 09:39 ---
Combiner bug, testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #1 from yavor at gnu dot org 2009-12-23 09:06 ---
Created an attachment (id=19379)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19379&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475
This happens only on x86_64-unknown-linux-gnu and x86_64-pc-kfreebsd-gnu.
Complete command:
gcc CynthiuneHeaderCell.m -c \
-MMD -MP -I/home/y/yavor/include -DGNUSTEP
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1
-DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDE
--- Comment #8 from ramana at gcc dot gnu dot org 2009-12-23 09:00 ---
Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01060.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
While building gcc from tag gcc_4_4_1_release on Haiku, a segfault occurred
several times in various files, in the same location in linemap_lookup:
mn = set->cache;
The set variable is NULL. I changed linemap_lookup to return NULL when the set
is NULL and this problem went away. I also experi
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-23 08:41 ---
While that change triggered it because at *.ifcvt it causes a difference:
:
i_41 = j_4(D);
- # DEBUG i => NULL
+ # DEBUG i => i_9
if (i_41 <= 4095)
goto ;
it doesn't to appear to be the bug, i_9 definitio
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-debug
Priority|P3 |P2
94 matches
Mail list logo
