if the copy constructor is decrated with the key word explicit, the following
code won't compile,
struct T
{
explicit T() {}
explicit T(const T) {}
};
void test(T const)
{
}
int main(int argc, char *argv[])
{
test(T());
return 0;
}
--
Summary: copy constructor
this has arrived in the last 2 days.
LANG=C /home/marcus/projects/gcc/BIN/bin/gcc -m32 -c -fPIC -O2 except.i
except.i: In function 'except_handler3':
except.i:28: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from marcus at jet dot franken dot de 2007-09-08 06:41
---
Created an attachment (id=14174)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14174action=view)
except.i
condensed testcase (from Wine)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351
--- Comment #31 from hjl at gcc dot gnu dot org 2007-09-08 06:47 ---
Subject: Bug 32183
Author: hjl
Date: Sat Sep 8 06:46:53 2007
New Revision: 128262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128262
Log:
2007-09-07 Zdenek Dvorak [EMAIL PROTECTED]
PR
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-09-08 07:16 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-09-08 07:19 ---
Confirmed.
Traceback:
#0 integer_onep (expr=0x0) at ../../../gcc/trunk/gcc/tree.c:1337
#1 0x080d0513 in gfc_conv_loop_setup (loop=0xbff16814)
at ../../../gcc/trunk/gcc/fortran/trans-array.c:3250
#2
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-08 08:09 ---
This probably needs the same technique as PR31229 / PR31154.
The following program is valid, but rejected by gfortran (also if one does not
rename the symbol):
func%i = 5
1
Error: Derived type 'z' at (1) is
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-08 09:15 ---
Yes the copy constructor is going to be called implicately here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33350
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-08 09:16 ---
Can you provide the output of /home/marcus/projects/gcc/BIN/bin/gcc -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351
--- Comment #1 from dorit at gcc dot gnu dot org 2007-09-08 09:19 ---
Subject: Bug 33301
Author: dorit
Date: Sat Sep 8 09:19:39 2007
New Revision: 128265
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128265
Log:
PR tree-optimization/33301
* tree-vect-analyze
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-08 09:23 ---
fix committed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dorit at gcc dot gnu dot org 2007-09-08 09:24 ---
fix committed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
I have a hunch this only happens on i386, not i586, which is why nobody
else has seen this so far:
/sw/test/GCC/trunk/libgomp/team.c: In function 'gomp_thread_start':
/sw/test/GCC/trunk/libgomp/team.c:131: error: invalid rtl sharing found in the
insn
(insn 22 21 23 2
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-08 09:42 ---
(In reply to comment #1)
(In reply to comment #0)
When the testcase gcc.dg/tree-ssa/predcom-3.c is compiled with
vectorization it
ICes when the dataref analysis called from vectorizer:
I can't get the
--- Comment #5 from pcarlini at suse dot de 2007-09-08 11:14 ---
Thanks. The patch passes regtesting.
Maybe Andrew can help us for a reduced testcase?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-09-08 11:32 ---
An equivalent C testcase eliminates the array stores:
int foo(int *a,int *b,int *c,int *d)
{
int val[3];
val[0] = *a;
val[1] = *b;
val[2] = *c;
return (val[0] != *d) (val[1] != *d) (val[2] !=
--- Comment #5 from uros at gcc dot gnu dot org 2007-09-08 11:33 ---
Subject: Bug 33329
Author: uros
Date: Sat Sep 8 11:33:08 2007
New Revision: 128269
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128269
Log:
PR target/33329
PR target/26449
*
--- Comment #14 from uros at gcc dot gnu dot org 2007-09-08 11:33 ---
Subject: Bug 26449
Author: uros
Date: Sat Sep 8 11:33:08 2007
New Revision: 128269
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128269
Log:
PR target/33329
PR target/26449
*
--- Comment #15 from ubizjak at gmail dot com 2007-09-08 11:35 ---
Reopened. Ther is really no magic here.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-09-08 11:40 ---
Confirmed.
Backtrace:
(gdb) b fancy_abort
Breakpoint 1 at 0x817cfe0: file ../../../gcc/trunk/gcc/diagnostic.c, line 654.
(gdb) r mm.f90
Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 mm.f90
--- Comment #16 from uros at gcc dot gnu dot org 2007-09-08 11:48 ---
Subject: Bug 26449
Author: uros
Date: Sat Sep 8 11:48:17 2007
New Revision: 128270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128270
Log:
PR rtl-optimization/26449
*
--- Comment #17 from ubizjak at gmail dot com 2007-09-08 11:51 ---
The testcase from comment #11 was added to the testsuite, but let's keep this
PR resolved as WORKSFORME for now. Please note that force_operand() will still
ICE for optabs with no handler.
--
ubizjak at gmail dot com
--- Comment #6 from ubizjak at gmail dot com 2007-09-08 11:52 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
Following testcase from PR target/33329 shows the problem where gcc doesn't
fold vector arithmetic operations with constant arguments to a load of vector
constant.
For clarity, sse4 will be used, but the same problem is present on sse2.
--cut here--
extern void g (int *);
void f (void)
{
int
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-08 12:45 ---
Confirmed.
Program received signal SIGSEGV, Segmentation fault.
0x0842837c in reload_as_needed (live_known=1)
at /home/richard/src/trunk/gcc/reload1.c:4161
4161 if (p != insn INSN_P (p)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-08 13:00 ---
It's currently not optimized because the simple phiprop does neither handle
component references nor inserts loads from pointers.
See the thread starting at
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01075.html
A simple program should print 1 but prints 2. Of some reason MINLOC fails
to find the minium location (first location) for the SUM expression.
PROGRAM TST
IMPLICIT NONE
REAL :: A(1,3)
A(:,1) = 10
A(:,2) = 20
A(:,3) = 30
WRITE(*,*) SUM(A(:,1:3),1)
WRITE(*,*) MINLOC(SUM(A(:,1:3),1),1)
--- Comment #11 from rakdver at gcc dot gnu dot org 2007-09-08 13:19
---
Subject: Bug 32283
Author: rakdver
Date: Sat Sep 8 13:18:49 2007
New Revision: 128272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128272
Log:
PR tree-optimization/32283
*
Dears
I would like to send a bug which was explicit by compiling the code:
BOOST_STATIC_ASSERT (
typeid (::connection::SPLight).name()
== typeid(::connection::LightsStructure::value_type).name()
);
This line is wrong, but it causes that gcc is going out
--- Comment #2 from patchapp at dberlin dot org 2007-09-08 14:00 ---
Subject: Bug number PR31547
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00684.html
--
Dear Sir
I would like to know how to correct this bug
Thank you for your attention
Haroldo C G Pereira
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-08 14:45 ---
Can you please attach preprocessed source for a testcase triggering this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355
--- Comment #3 from bangerth at dealii dot org 2007-09-08 15:20 ---
You omit the part of the section that talks about lvalues and rvalues. That
part clarifies which of the conversions is to be taken here.
If you really want to make your program ambiguous do this:
---
--- Comment #5 from bangerth at dealii dot org 2007-09-08 15:25 ---
I think there is very little that can be done here given the gcc extension
of taking the address of labels.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2007-09-08 15:27 ---
Yes, this is allowed.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from shw_mail at wp dot pl 2007-09-08 15:31 ---
(In reply to comment #1)
Can you please attach preprocessed source for a testcase triggering this?
Below is separated FULL example :-).
// test_case.cpp
#include boost/static_assert.hpp
#include typeinfo
struct
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-08 15:31 ---
The code compiles and runs correctly with trunk (aka 4.3).
I'm guessing that Thomas had fixed the problem and that
he did not back port the fix because the bug isn't a
regression. If Thomas does not comment on the PR
--- Comment #2 from bangerth at dealii dot org 2007-09-08 15:33 ---
This is a duplicate of PR 19092
W.
*** This bug has been marked as a duplicate of 19092 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #10 from bangerth at dealii dot org 2007-09-08 15:33 ---
*** Bug 33129 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-08 16:16 ---
I want to add that you can find gfortran 4.3.0 binaries at
http://gcc.gnu.org/wiki/GFortranBinaries
I'm actually unsure which patch fixed it. It might be Paul's PR32298 even
though it is about PARAMETER arrays.
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-08 17:23 ---
Can you attach the *.ii file that is generated if you compile this with
-save-temps added to the command line?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-08 17:49 ---
So the following brute force approach will make PRE to do insertion for _all_
loads. It produces then
g (b, c)
{
int prephitmp.15;
int prephitmp.10;
struct f g;
bb 2:
if (b == 0B)
goto bb 3;
else
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-08 17:51 ---
Note that basic cleanups after PRE are missing, for example FRE of inserted
loads.
And of course it makes code larger.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33344
--- Comment #1 from danglin at gcc dot gnu dot org 2007-09-08 18:23 ---
Also see the same ICE at -O2 on hppa.
Program received signal SIGSEGV, Segmentation fault.
0x0041e7a4 in reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.c:4161
4161 if (p != insn
--- Comment #4 from lauras at gcc dot gnu dot org 2007-09-08 18:36 ---
It sure looks like it is caused by my patch. I will be able to take care of
that on Monday.
I think this change should fix it (completely untested): rewrite
for (p = NEXT_INSN (prev); p != next; p
--- Comment #4 from shw_mail at wp dot pl 2007-09-08 19:04 ---
Created an attachment (id=14175)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14175action=view)
-save-temp from the code.
This is an .ii file contains preprocessed code.
--
--- Comment #5 from shw_mail at wp dot pl 2007-09-08 19:05 ---
Created an attachment (id=14176)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14176action=view)
The program which causes error.
Source code of the program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355
--- Comment #6 from pcarlini at suse dot de 2007-09-08 19:09 ---
Hi. So, what shall we do here? I can remove the warning completely or
conditionalize it to -Wextra, for example. Just let me know...
--
pcarlini at suse dot de changed:
What|Removed
The documentation of REG_RETVAL and REG_LIBCALL notes is incomplete. The
following additional information should be added to doc/rtl.texi:
1. LIBCALL and RETVAL notes always appear in pairs.
2. Operand 0 the libcall reg note always points to the other note of the pair.
3. Nested pairs of libcall
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-09-08 19:19 ---
I think PR 33346 is the same issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2007-09-08 19:17 ---
Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST
F90_RMA/BASEATTRWINF90.F90
ftn -o x -O2 bug2867.f90
aprun -n 1 ./x
Got incorrect value for WIN_SIZE (
I don't know how to fill in much of this form but I hope all will be clear from
the following transcript.
I'm hoping for advice on what to do (upgrade?) to fix the problem or failing
that what to do to help diagnose it.
===
[EMAIL PROTECTED]:~/mysql-5.0.45/client g++ -O3 -DDBUG_OFF
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-08 19:29 ---
This is ld crashing and ld is part of the binutils project.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from steven at gcc dot gnu dot org 2007-09-08 19:37 ---
Load PRE does still not optimize the test cases of comment #0 and comment #2.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from lauras at gcc dot gnu dot org 2007-09-08 19:40 ---
I will be able to handle this on Monday. If it's urgent, you can try (untested)
suggestion at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351#c4
Sorry for the trouble.
--
lauras at gcc dot gnu dot org changed:
--- Comment #7 from gdr at cs dot tamu dot edu 2007-09-08 20:00 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Hi. So, what shall we do here? I can remove the warning completely or
| conditionalize
Hi,
By simple MFPs I mean those that point to a class with single or no inheritance
and the class is fully defined at the time of the call. For example:
class SomeClass {};
typedef void (SomeClass::*MemberFunc)();
void callMemberFunc(SomeClass *object, MemberFunc func)
{
(object-*func)();
}
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-09-08 20:16
---
This one is already reported.
*** This bug has been marked as a duplicate of 29835 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-09-08 20:16
---
*** Bug 8 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-08 20:40 ---
VS seems to dispatch to some other function. Dependend on whether the method
is virtual or not the code path has to be more complicated. Of course this is
also dependent on the actual ABI. That is,
L7:
Trunk fails for sh-elf during compiling libgcc with a missing
local label:
/exp/ldroot/dodes/xsh-elf-gcc-orig/./gcc/xgcc
-B/exp/ldroot/dodes/xsh-elf-gcc-orig/./gcc/ -B/usr/local/sh-unknown-elf/bin/
-B/usr/local/sh-unknown-elf/lib/ -isystem /usr/local/sh-unknown-elf/include
-isystem
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #10 from anrp at mit dot edu 2007-09-08 21:44 ---
(In reply to comment #9)
Here's what I see:
The array __clz_tab is used in a macro, count_leading_zeros, which is called
in
the function __clzSI2 in libgcc2.c, which (AFAICT) gets compiled to the
function __clzsi2 and
--- Comment #11 from anrp at mit dot edu 2007-09-08 21:48 ---
(In reply to comment #10)
Here's an untested (I'm going to try to figure out how to get it to build into
the AVR build) function that replaces the definition of clz_tab with a 6
instruction bit of code:
; r2 in, r3 out
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:93: error: unrecognizable insn:
(call_insn 26 25 27 7 /home/segher/src/gcc/libgcc/../gcc/libgcc2.c:90 (parallel
[
(call (mem:QI (symbol_ref:SI (abort) [flags 0x41] function_decl
0x2b1aae353900 abort) [0 S1 A8])
(const_int 0
--- Comment #1 from segher at kernel dot crashing dot org 2007-09-08 23:06
---
SVN revision 128276
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33360
--- Comment #9 from bangerth at dealii dot org 2007-09-08 23:24 ---
This sounds good to me to. I guess we can now confirm the PR.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2007-09-08 23:27 ---
Confirmed. In particular, the value 1.1 is of type 'double' for which
it hardly ever makes sense to print it to 47 digits :-)
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #3 from bangerth at dealii dot org 2007-09-08 23:33 ---
I don't know whether gcc's result is correct or not (I suspect it is)
but here's two more data points:
- icc produces the same output
- Sun Studio produces the following compiler output:
--
g/x
--- Comment #4 from bangerth at dealii dot org 2007-09-08 23:43 ---
I have to admit that the result is strange. However, it appears entirely
within the compiler's right to do this, as [18.5.1/5] says:
-
bool before(const type_info rhs) const;
5 Effects:
Compares
--- Comment #1 from bangerth at dealii dot org 2007-09-08 23:45 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #2 from bangerth at dealii dot org 2007-09-08 23:47 ---
As a matter of fact, if the types had not been inside a struct, gcc would
have produced the warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32997
--- Comment #4 from bangerth at dealii dot org 2007-09-08 23:52 ---
The code is definitely invalid. The two typedefs declare two types with
external linkage. This is an ODR violation making the code invalid. The
standard doesn't require compilers to produce an error for a very good
-gnu
Configured with: ../gcc-4_2-branch/configure --enable-languages=c,c++
--prefix=/suse/NOBACKUP/gcc/gcc-4.2-branch
Thread model: posix
gcc version 4.2.2 20070908 (prerelease)
/suse/NOBACKUP/gcc/gcc-4.2-branch/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus
-E -quiet -v -I/home/andreas/work/uka/stxxl
--- Comment #2 from gerald at pfeifer dot com 2007-09-09 01:09 ---
Karl discussed this with me and despite some concerns on my side as well
I agreed to implement something like this. It's just a single line in a
config file that can be controlled via remote CVS, it turns out.
--
--
gerald at pfeifer dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gerald at pfeifer dot com
|dot org
--- Comment #2 from stevenyi at 163 dot com 2007-09-09 02:46 ---
(In reply to comment #1)
Yes the copy constructor is going to be called implicately here.
the copy constructor is not actually called at runtime. and both intel compiler
and vc++ can compile this code.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-09 02:58 ---
There is a C++ defect report about this really. GCC follows exactly what the
standard says but the defect report says something different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33350
--- Comment #2 from don-gcc at isis dot cs3-inc dot com 2007-09-09 03:43
---
Subject: collect2: ld terminated with signal 11 [Segmentation fault]
pinskia at gcc dot gnu dot org writes:
This is ld crashing and ld is part of the binutils project.
Mike Frysinger writes:
you should
--- Comment #6 from jason at gcc dot gnu dot org 2007-09-09 04:33 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from hp at gcc dot gnu dot org 2007-09-09 05:01 ---
Please try after r128284.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hp at gcc dot gnu dot org 2007-09-09 05:02 ---
Please try after r128284.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hp at gcc dot gnu dot org 2007-09-09 05:05 ---
Please try after r128284. See also story about this test-case for cris-elf at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00732.html.
--
hp at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from stevenyi at 163 dot com 2007-09-09 05:26 ---
I can not see any reason to call the copy constructor here. If you remove
keyword explicit so that let the code compile, you can find that the copy
constructor is not called at all.
--
84 matches
Mail list logo
