Re: PL/I for GCC version 0.0.15 released
PL/I for GCC is released under the terms of the GNU Public License; version 2. The GCC at trunk uses GPL version 3 or newer ... -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: PL/I for GCC version 0.0.15 released
On Sunday 30 September 2007 11.21:38 Rafael Espindola wrote: PL/I for GCC is released under the terms of the GNU Public License; version 2. The GCC at trunk uses GPL version 3 or newer ... I use the snapshot from 20070810 and there the COPYING file is still GPL version two. anyway I will plan an upgrade of the license together with major release upgrade, and leave the 0.0.xx series as GPLv2. Henrik
Automatic cast off union tree in gdb
Hi, When stepping through gcc with gdb: is there a way to be able to make gdb automatically cast a union tree to the correct struct depending on the union tree's type? A p tree will print out all unions. I'd not want to do a cast all the time. -- Konrad
Re: Automatic cast off union tree in gdb
Konrad == k e [EMAIL PROTECTED] writes: Konrad Hi, When stepping through gcc with gdb: is there a way Konrad to be able to make gdb automatically cast a union tree to the Konrad correct struct depending on the union tree's type? Not that I know of. Konrad A p tree Konrad will print out all unions. I'd not want to do a cast all the time. I think most developers use debug_tree for this. There are some gdb convenience commands defined in gcc/gdbinit.in (which is made into a real .gdbinit during the build) -- use these. And, I recommend reading the debugging tips page on the wiki. Tom
Re: [RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor
On 9/29/07, FX Coudert [EMAIL PROTECTED] wrote: Comments are highly welcome, both on the idea itself, and on the Perl script (my Perl is a bit rusty since I haven't used it for years). I think that if indeed metahtml is in such a bad shape as you describe, moving away from it asap is the right thing to do. But I'm not convinced that developing a gcc.gnu.org-specific template engine is the correct answer. There's plenty of such things available out there that are actively maintained and developed. E.g. Template Toolkit seems rather widely used, is written in perl (not my favourite language, but...) so it should work on the current webserver, is installable via CPAN, and contains a command-line utility that can be used to generate an entire site in one go, see http://www.template-toolkit.org/docs/tutorial/Web.html -- Janne Blomqvist
Re: GCC 4.2.2 RC2 Available
Manuel López-Ibáñez wrote: [ I posted this before but I think you missed it. Otherwise let me know. I don't want to be annoying. ] You're not being annoying. In general, if you send me a message explicitly (i.e., I'm in the To: or Cc: field), and you don't get a reply, the right assumption is that either I've not replied yet, or that I've somehow missed the message. In either case, if you feel it's urgent, please feel free to ping me again -- as you did here. Would you consider the patch in http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01735.html before the release? It doesn't look like that patch has been approved for mainline. If it is approved there, then it is OK for the 4.2 branch, after the 4.2.2 release. Also, the script that generates the release is supposed to generate the install documents but, that doesn't seem to be working because GCC 4.0.0 and GCC 4.1.0 contained a lot of HTML files in INSTALL/. However, the HTML files are missing in GCC 4.2.0 and in this GCC 4.2.2 RC2. Good catch. Looking back at the build logs, I see: /scratch/mitchell/gcc-releases/gcc-4.2.2-RC-20070927/gcc-4.2.2-RC-20070927/gcc/doc/include/gcc-common.texi:11: @include `gcc-vers.texi': No such file or directory. It looks like the problem here is that the release script builds the documentation before building the compiler. That used to work, but no longer does, because the documentation now depends on a file that is created by the build process. So, the right fix is probably to (a) apply your patch or an equivalent, and then (b) modify the release script so that instead of explicitly building the installation docs before the compiler is built, it does that afterwards -- or just relies on the compiler build to install the documentation. In either case, I don't think that this is a showstopper. (AFAIK, you're the first person to notice this, and you've indicated that it's now a relatively long-standing bug.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Inconsistent error/pedwarn: ISO C++
Manuel López-Ibáñez wrote: On 20/09/2007, Doug Gregor [EMAIL PROTECTED] wrote: We can't seem to decide whether ISO C++ really forbids comparisons between pointers and integers or not. The first two are for == and !=, the second two are for , , =, =. Why the inconsistency? typeck.c: error (ISO C++ forbids comparison between pointer and integer); typeck.c: error (ISO C++ forbids comparison between pointer and integer); typeck.c: pedwarn (ISO C++ forbids comparison between pointer and integer); typeck.c: pedwarn (ISO C++ forbids comparison between pointer and integer); These should all be pedwarns. The basic principle is to use pedwarn for things that have well-defined GNU semantics, but don't happen to be legal. That's especially true for things that are valid in GNU C. Here, the well-defined GNU semantics are that the integer is converted to the pointer type, as if by a cast. A patch to convert to pedwarns is pre-approved, if accompanied by a testcase. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
[Bug c/33598] New: gcc 4.2.1 ignores GNU LD in Solaris 9
We recently upgraded to 4.2.1 and noticed an immediate issue. After compiling gcc for sparcv9 and specifically setting --with-ld=/usr/local/gnu/bin/ld, whenever gcc actually runs it internally calls the Sun linker and therefore dies with unknown options. A simple hello world refuses to build because of bad LD options. Setting LD= seems to have little effect. I'm pasting a -v output of it below. Note I was using g++ here because that was handy, but it is the same for eitehr gcc or g++: /usr/local/bin/sparcv9/g++ -v hello.cpp Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../configure --enable-shared --enable-threads --with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as --disable-multilib --disable-libgcj --disable-libffi --disable-libjava --disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 Thread model: posix gcc version 4.2.1 /usr/local/libexec/gcc/sparc-sun-solaris2.9/4.2.1/cc1plus -quiet -v -D__sparcv8 hello.cpp -quiet -dumpbase hello.cpp -mcpu=v9 -auxbase hello -version -o /var/tmp//ccM6WkGY.s ignoring nonexistent directory NONE/include ignoring nonexistent directory /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../sparc-sun-solaris2.9/include #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1 /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1/sparc-sun-solaris2.9 /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1/backward /usr/local/include /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/include /usr/include End of search list. GNU C++ version 4.2.1 (sparc-sun-solaris2.9) compiled by GNU C version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 7f9cd0c7cc891b25f4cbce210dc67670 /usr/local/gnu/bin/as -V -Qy -s -xarch=v8plus -o /var/tmp//ccZD9lJS.o /var/tmp//ccM6WkGY.s GNU assembler version 2.17 (sparc-sun-solaris2.9) using BFD version 2.17 /usr/local/libexec/gcc/sparc-sun-solaris2.9/4.2.1/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crt1.o /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtbegin.o -L/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1 -L/usr/ccs/lib -L/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/../../.. /var/tmp//ccZD9lJS.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtend.o /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.390 ld: fatal: option -dn and -P are incompatible ld: fatal: Flags processing errors collect2: ld returned 1 exit status -- Summary: gcc 4.2.1 ignores GNU LD in Solaris 9 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dhaliK at jla dot rutgers dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c++/33599] New: segfault in program compiled by g++ 4.2, corrupted reference
Hello,
I am developing a C++ template library (a matrix library with expression
templates). Upgrading from g++-4.1 to g++-4.2, the programs using this library
run much (4x) faster, but some segfault!
I have fixed for this bug report an archive containing the bare minimum to
reproduce this bug.
To reproduce:
tar xfzv gcc-bug-report.tar.gz
cd gcc-bug-report
Then you can check that it works with g++-4.1:
g++-4.1 test.cpp -o test ./test
And you can check that it segfaults with g++-4.2:
g++-4.2 test.cpp -o test ./test
Now let us look into where exactly it segfaults. This happens in
EiMatrixConstRef::_read(), so let us look at the file:
src/internal/MatrixRef.h.
Here is the class EiMatrixConstRef:
templatetypename MatrixType class EiMatrixConstRef
: public EiObjecttypename MatrixType::Scalar, EiMatrixConstRefMatrixType
{
public:
typedef typename MatrixType::Scalar Scalar;
friend class EiObjectScalar, EiMatrixConstRef;
EiMatrixConstRef(const MatrixType matrix) : m_matrix(matrix)
{
std::cout contruct ref this on matrix m_matrix
std::endl;
}
EiMatrixConstRef(const EiMatrixConstRef other) : m_matrix(other.m_matrix)
{
std::cout contruct ref this from ref other on
matrix m_matrix
std::endl;
}
~EiMatrixConstRef() {std::cout destruct ref this std::endl;}
EI_INHERIT_ASSIGNMENT_OPERATORS(EiMatrixConstRef)
private:
int _rows() const { return m_matrix.rows(); }
int _cols() const { return m_matrix.cols(); }
const Scalar _read(int row, int col) const
{
std::cout ref this reading in matrix m_matrix
std::endl;
return m_matrix._read(row, col);
}
const MatrixType m_matrix;
};
So what happens is that the last call to EiMatrixConstRef::_read() segfaults
because the reference m_matrix is corrupted, i.e. as a pointer it has a bad
value.
This is strange because the cout's that I have added to the construcors and
destructor show that this EiMatrixConstRef object is properly constructed with
a good m_matrix reference, and not destructed since.
So at some point the m_matrix reference gets corrupted. The fact that this
didn't happen with g++-4.1 suggests to me that this might be a bug in g++-4.2.
Of course I might be wrong, I'm not an expert.
Cheers,
Benoit
--
Summary: segfault in program compiled by g++ 4.2, corrupted
reference
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jacob at math dot jussieu dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #1 from jacob at math dot jussieu dot fr 2007-09-30 08:57 --- Created an attachment (id=14271) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14271action=view) The archive allowing to reproduce the bug. Of course, I forgot the attachment :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-09-30 09:09 --- We recently upgraded to 4.2.1 and noticed an immediate issue. After compiling gcc for sparcv9 and specifically setting --with-ld=/usr/local/gnu/bin/ld, It is as though /usr/local/gnu/bin/ld was not invoked at all. Could you post the output of '/usr/local/gnu/bin/ld --version'? Did you bootstrap or build the compiler? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Summary|gcc 4.2.1 ignores GNU LD in |gcc 4.2.1 ignores GNU ld on |Solaris 9 |Solaris 9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #2 from jacob at math dot jussieu dot fr 2007-09-30 09:16 --- Here are some thoughts about why it is so fast with g++-4.2, perhaps related to why it segfaults. My library is an Expression Templates library. So when you do m1+m2 with matrices m1 and m2, instead of computing the sum of these two matrices, it constructs a new object of type (roughly) SumMatrix,Matrix and passes to its contructor references to m1 and m2. So when you do m3=m1+m2 it (roughly) calls Matrix::operator=(Sum) which calls Sum...::read() to evaluate the entries in the matrix sum. It is very important that the compiler be clever enough to understand that the objects of type Sum... are short-lived, so it doesn't need to emit any code for them in the final binary. g++ 4.1 didn't understand that, so it produced slow code. g++ 4.2 understands that, so it optimizes accordingly. That explains why 4.2 produces 4x faster code in my benchmarks. But I am afraid that I might be hitting a bug in this optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-30 09:22 --- Also try with --with-gnu-ld/--with-gnu-as. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug target/33505] Vectorizer (or spu target builtins) and PCH don't get along
--- Comment #1 from irar at il dot ibm dot com 2007-09-30 09:42 ---
I managed to reproduce it.
Here http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01559.html Richard suggested
to add a GTY(()) to
struct spu_builtin_description spu_builtins[] = {
#define DEF_BUILTIN(fcode, icode, name, type, params) \
{fcode, icode, name, type, params, NULL_TREE},
#include spu-builtins.def
#undef DEF_BUILTIN
};
Actually there is a GTY(()) in spu-builtins.h
extern GTY(()) struct spu_builtin_description spu_builtins[];
But anyway I tried to the following and it didn't help:
Index: spu.c
===
--- spu.c (revision 128708)
+++ spu.c (working copy)
@@ -4459,7 +4459,7 @@
^L
/* Create the built-in types and functions */
-struct spu_builtin_description spu_builtins[] = {
+struct spu_builtin_description GTY (()) spu_builtins[] = {
#define DEF_BUILTIN(fcode, icode, name, type, params) \
{fcode, icode, name, type, params, NULL_TREE},
#include spu-builtins.def
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
CC||irar at il dot ibm dot com,
||richard dot guenther at
||gmail dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-30 09:42:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33505
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-30 09:26 --- Also this does not make sense as bootstrap should have failed if gnu ld was not used. (In reply to comment #1) It is as though /usr/local/gnu/bin/ld was not invoked at all. Could you post the output of '/usr/local/gnu/bin/ld --version'? Did you bootstrap or build the compiler? Since it is 4.2.1, you can tell it was bootstrapped by the non use of --disable-bootstrap :). The main question I have is how bootstrapped worked but not the installed g++. Did you change something after install? Like delete the GNU ld? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug target/33505] Vectorizer (or spu target builtins) and PCH don't get along
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-30 09:53 --- This is kinda on my list of stuff to forward port from the internal PS3 toolchain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33505
[Bug middle-end/33597] Internal compiler error while compiling libswcale from ffmpeg
--- Comment #4 from ubizjak at gmail dot com 2007-09-30 10:03 ---
segfaults with -ftree-vectorize in SLP.
reduced testcase:
--cut here--
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
void
rgb15to24_C (const uint8_t * src, uint8_t * dst, long src_size)
{
const uint16_t *end;
const uint16_t *s = (uint16_t *)src;
uint8_t *d = (uint8_t *)dst;
end = s + src_size/2;
while (s end)
{
uint16_t bgr = *s++;
*d++ = (bgr0x1F)3;
*d++ = (bgr0x3E0)2;
*d++ = (bgr0x7C00)7;
}
}
--cut here--
gcc -O2 -ftree-vectorize -msse2:
t.c: In function �rgb15to24_C�:
t.c:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Program received signal SIGSEGV, Segmentation fault.
0x00a94d24 in vect_build_slp_tree (loop_vinfo=0x1039cc0,
node=0x7fffb8b97da0, group_size=3, slp_impossible=0x7fffb8b97e3f ,
inside_cost=0x7fffb8b97e38, outside_cost=0x7fffb8b97e34,
ncopies_for_cost=3) at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:2700
2700 if (!VECTOR_MODE_P (optab_op2_mode))
#0 0x00a94d24 in vect_build_slp_tree (loop_vinfo=0x1039cc0,
node=0x7fffb8b97da0, group_size=3, slp_impossible=0x7fffb8b97e3f ,
inside_cost=0x7fffb8b97e38, outside_cost=0x7fffb8b97e34,
ncopies_for_cost=3) at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:2700
#1 0x00a94f73 in vect_build_slp_tree (loop_vinfo=0x1039cc0,
node=0x7fffb8b97e28, group_size=3, slp_impossible=0x7fffb8b97e3f ,
inside_cost=0x7fffb8b97e38, outside_cost=0x7fffb8b97e34,
ncopies_for_cost=3) at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:2870
#2 0x00a955e3 in vect_analyze_slp_instance (loop_vinfo=0x1039cc0,
stmt=value optimized out)
at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:3000
#3 0x00a993e0 in vect_analyze_loop (loop=value optimized out)
at ../../gcc-svn/trunk/gcc/tree-vect-analyze.c:3045
#4 0x007f82ce in vectorize_loops ()
at ../../gcc-svn/trunk/gcc/tree-vectorizer.c:2501
Confirmed on x86_64 and i686/sse2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-30 10:03:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
[Bug middle-end/33597] Internal compiler error while compiling libswcale from ffmpeg
--- Comment #5 from ubizjak at gmail dot com 2007-09-30 10:28 ---
Patch in testing:
--cut here--
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 128890)
+++ tree-vect-analyze.c (working copy)
@@ -2696,6 +2696,13 @@
return false;
}
icode = (int) optab-handlers[(int) vec_mode].insn_code;
+ if (icode == CODE_FOR_nothing)
+ {
+ if (vect_print_dump_info (REPORT_SLP))
+ fprintf (vect_dump,
+Build SLP failed: op not supported by target.);
+ return false;
+ }
optab_op2_mode = insn_data[icode].operand[2].mode;
if (!VECTOR_MODE_P (optab_op2_mode))
{
--cut here--
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-09-30 10:03:40 |2007-09-30 10:28:58
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
[Bug inline-asm/33600] New: Breakage caused by the fix to PR33552
The fix to PR33552 unfortunately breaks the Linux kernel build.
Reduced testcase attached, but hey, I'll put it inline as well:
int f(int n)
{
int x;
asm( : =c(n), =r(x) : 1(n), 0(n));
return n;
}
And the error is:
usercopy.i:5: error: 'asm' operand has impossible constraints
--
Summary: Breakage caused by the fix to PR33552
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug middle-end/33597] Internal compiler error while compiling libswcale from ffmpeg
--- Comment #6 from irar at il dot ibm dot com 2007-09-30 10:37 --- (In reply to comment #5) Patch in testing: Thanks for fixing this! (I've just started to test the exact same patch :)) Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
[Bug inline-asm/33600] Breakage caused by the fix to PR33552
--- Comment #1 from segher at kernel dot crashing dot org 2007-09-30 10:39 --- Created an attachment (id=14272) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14272action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug middle-end/33597] Internal compiler error while compiling libswscale from ffmpeg
--- Comment #7 from ismail at pardus dot org dot tr 2007-09-30 11:30 --- Fix summary , swcale - swscale . Thanks for the fast fix! -- ismail at pardus dot org dot tr changed: What|Removed |Added Summary|Internal compiler error |Internal compiler error |while compiling libswcale |while compiling libswscale |from ffmpeg |from ffmpeg http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-30 11:37 ---
The usual error that happens with expression templates is that you return a
reference to a temporary object, using it after its lifetime ended. What
you then can observe is that if you inline enough the error goes away.
But this is just a wild guess. Instead you need to track this down further
to a smaller testcase (without the complete expression template machinery).
Oh, and the testcase crashes with -O2 for me; with gcc 4.0, 4.1, 4.2 and trunk.
It doesn't build with 3.4, so I didn't verify there. It already crashes with
void matrixOps()
{
EiMatrixint, 2, 3 a, b;
a = a + b;
}
my bet would be a bug in your code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug inline-asm/33600] [4.3 Regression] Breakage caused by the fix to PR33552
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-30 11:49 ---
asmcons does:
-(insn 6 3 11 2 t.i:5 (parallel [
-(set (reg/v:SI 60 [ n ])
+(insn 21 3 6 2 t.i:5 (set (reg/v:SI 58 [ x ])
+(reg/v:SI 60 [ n ])) -1 (nil))
+
+(insn 6 21 11 2 t.i:5 (parallel [
+(set (reg/v:SI 58 [ x ])
(asm_operands:SI () (=c) 0 [
-(reg/v:SI 60 [ n ])
-(reg/v:SI 60 [ n ])
+(reg/v:SI 58 [ x ])
+(reg/v:SI 58 [ x ])
]
[
(asm_input:SI (1) () 0)
@@ -43,8 +48,8 @@
] (t.i) 5))
(set (reg/v:SI 58 [ x ])
(asm_operands:SI () (=r) 1 [
-(reg/v:SI 60 [ n ])
-(reg/v:SI 60 [ n ])
+(reg/v:SI 58 [ x ])
+(reg/v:SI 58 [ x ])
]
[
(asm_input:SI (1) () 0)
but I wonder if the testcase is valid, as it overlaps an output in xmm
register ('x') with an immediate input ('n'). And if you look at
the output at -O0 we get
#APP
# 5 t.i 1
# %ecx %eax
# 0 2
#NO_APP
that is, no xmm register allocated. What does the unreduced asm look like?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Breakage caused by the fix |[4.3 Regression] Breakage
|to PR33552 |caused by the fix to PR33552
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug inline-asm/33600] [4.3 Regression] Breakage caused by the fix to PR33552
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-30 11:56 --- bah - ignore the comments about invalid asm ;) too early in the morning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-30 12:41 --- Diego, we seem to have a general problem with the incremental SSA updater. If we rename foo$ptr in bb 6: # foo$ptr_16 = PHI foo$ptr_18(ab)(5), D.1758_3(4) p_12 = foo$ptr_16; foo$ptr_19(ab) = 0B; p_15 = foo$ptr_16; p_4 = foo$ptr_16; p_5 = foo$ptr_16; D.1781_6 = foo$ptr_16-_vptr.Foo; D.1782_7 = *D.1781_6; OBJ_TYPE_REF(D.1782_7;foo$ptr_16-0) (foo$ptr_16); goto bb 8; it apperantly does not deal correctly with the lifetimes of foo$ptr_16 and foo$ptr_19(ab) overlapping. Note that the SSA_NAME_OCCURS_IN_ABNORMAL_PHI flags are correct, foo$ptr_16 does not live across an EH edge (but just local in BB 6). Still, for this flag to prevent creating overlapping life ranges it would have need to be set on foo$ptr_16 as well. [In the testcase the final inliner is the first one to cause renaming of foo$ptr, the early SRA pass introduces the life-range overlap (but hidden by a copy chain) and the first copyprop makes it obviously visible (that's the dump from above)] -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug middle-end/33597] Internal compiler error while compiling libswscale from ffmpeg
--- Comment #8 from uros at gcc dot gnu dot org 2007-09-30 12:45 --- Subject: Bug 33597 Author: uros Date: Sun Sep 30 12:45:32 2007 New Revision: 128891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128891 Log: PR tree-optimization/33597 * tree-vect-analyze.c (vect_build_slp_tree): Check if optab handler for LSHIFT_EXPR and RSHIFT_EXPR is available for vec_mode. testsuite/ChangeLog: PR tree-optimization/33597 * gcc.dg/vect/pr33597.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr33597.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
[Bug tree-optimization/33597] Internal compiler error while compiling libswscale from ffmpeg
--- Comment #9 from ubizjak at gmail dot com 2007-09-30 12:47 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||09/msg02085.html Status|ASSIGNED|RESOLVED Component|middle-end |tree-optimization Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-09-30 12:51 --- Zdenek may also have an idea? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-09-30 12:58 --- Also try with --with-gnu-ld/--with-gnu-as. These switches are useless with --with-ld/--with-as. Moreover, the compiler is apparently already configured for GNU ld. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #11 from dnovillo at google dot com 2007-09-30 13:41 --- Subject: Re: [4.3 Regression] wrong code with -O On 30 Sep 2007 12:41:03 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-30 12:41 --- Diego, we seem to have a general problem with the incremental SSA updater. If we rename foo$ptr in bb 6: # foo$ptr_16 = PHI foo$ptr_18(ab)(5), D.1758_3(4) p_12 = foo$ptr_16; foo$ptr_19(ab) = 0B; p_15 = foo$ptr_16; p_4 = foo$ptr_16; p_5 = foo$ptr_16; D.1781_6 = foo$ptr_16-_vptr.Foo; D.1782_7 = *D.1781_6; OBJ_TYPE_REF(D.1782_7;foo$ptr_16-0) (foo$ptr_16); goto bb 8; Is the symbol foo$ptr being marked for renaming? If so, that's wrong. A gimple register symbol cannot be marked for renaming if there are overlapping live ranges in its SSA names. We don't have a general mechanism to prevent that. Mostly because we do not keep track when OLRs are created. The generic SSA updating mechanism has no cheap way of checking that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug c++/33601] New: [4.3 regression] ICE with pointers to members using const C as the class identifier
g++43 -v output:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --program-suffix=43 --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070929 (experimental) (GCC)
Built from svn trunk, revision 128885
The following code fails to compile with this error:
canonical_type_error.cpp: In function 'int A::* getmemberptr()':
canonical_type_error.cpp:8: internal compiler error: canonical types differ for
identical types int A::* and int A::*
==
struct A
{
int membervar;
};
typedef const A type;
int type::* getmemberptr() { return type::membervar; }
=
I'm not sure if the code is valid however (using such a typedef as the class id
in a pointer to member declaration), but it did work with older builds of gcc.
It also fails if type is a template argument, which makes it possible to
stumble on this problem in a non obvious way because of automatic template
argument deduction.
--
Summary: [4.3 regression] ICE with pointers to members using
const C as the class identifier
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot chavasse at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33601
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #4 from jacob at math dot jussieu dot fr 2007-09-30 13:47 --- I had tried to make a shorter testcase but didn't find any that caused a crash. But yes, the shorter testcase that you found indeed causes a crash here. With both 4.1 and 4.2. So indeed, that's probably a bug in my own code, and at least it's not a regression from 4.1 to 4.2. Thanks for your help and sorry for the false alert! While I'm there, I'd like to draw your attention on the following fact. As I said, with my library's benchmark, 4.2 produces much faster code than 4.1. But trunk produces slower code than 4.2 does (almost as slow as 4.1). Is this normal, given that this is a development version? Or is that a regression worth reporting a bug against trunk/4.3 ? More precisely, here are the execution times of our benchmark with various versions of g++: g++-4.1: 21s g++-4.2: 4s g++-4.3: 15s (8s with -fforce-addr) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #12 from rguenther at suse dot de 2007-09-30 14:01 ---
Subject: Re: [4.3 Regression] wrong code with
-O
On Sun, 30 Sep 2007, dnovillo at google dot com wrote:
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-30 12:41
---
Diego, we seem to have a general problem with the incremental SSA updater.
If we rename foo$ptr in
bb 6:
# foo$ptr_16 = PHI foo$ptr_18(ab)(5), D.1758_3(4)
p_12 = foo$ptr_16;
foo$ptr_19(ab) = 0B;
p_15 = foo$ptr_16;
p_4 = foo$ptr_16;
p_5 = foo$ptr_16;
D.1781_6 = foo$ptr_16-_vptr.Foo;
D.1782_7 = *D.1781_6;
OBJ_TYPE_REF(D.1782_7;foo$ptr_16-0) (foo$ptr_16);
goto bb 8;
Is the symbol foo$ptr being marked for renaming? If so, that's wrong.
A gimple register symbol cannot be marked for renaming if there are
overlapping live ranges in its SSA names. We don't have a general
mechanism to prevent that. Mostly because we do not keep track when
OLRs are created. The generic SSA updating mechanism has no cheap way
of checking that.
Yes, it is marked for renaming by the inliner. Somehow the inliner
assumes there are no OLRs:
...
The function mark PHI_RESULT of such PHI nodes for renaming; it is
safe the EH edges are abnormal and SSA_NAME_OCCURS_IN_ABNORMAL_PHI
must be set. This means, that there will be no overlapping live ranges
for the underlying symbol.
This might change in future if we allow redirecting of EH edges and
we might want to change way build CFG pre-inlining to include
all the possible edges then. */
static void
update_ssa_across_eh_edges (basic_block bb)
{
edge e;
edge_iterator ei;
FOR_EACH_EDGE (e, ei, bb-succs)
if (!e-dest-aux
|| ((basic_block)e-dest-aux)-index == ENTRY_BLOCK)
{
tree phi;
gcc_assert (e-flags EDGE_EH);
for (phi = phi_nodes (e-dest); phi; phi = PHI_CHAIN (phi))
{
gcc_assert (SSA_NAME_OCCURS_IN_ABNORMAL_PHI
(PHI_RESULT (phi)));
mark_sym_for_renaming
(SSA_NAME_VAR (PHI_RESULT (phi)));
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug inline-asm/33600] [4.3 Regression] Breakage caused by the fix to PR33552
--- Comment #4 from segher at kernel dot crashing dot org 2007-09-30 14:07
---
The original code is: (arch/i386/lib/usercopy.c):
/* Generic arbitrary sized copy. */
#define __copy_user(to,from,size) \
do {\
int __d0, __d1, __d2; \
__asm__ __volatile__( \
cmp $7,%0\n \
jbe 1f\n \
movl %1,%0\n \
negl %0\n \
andl $7,%0\n \
subl %0,%3\n \
4: rep; movsb\n \
movl %3,%0\n \
shrl $2,%0\n \
andl $3,%3\n \
.align 2,0x90\n\
0: rep; movsl\n \
movl %3,%0\n \
1: rep; movsb\n \
2:\n \
.section .fixup,\ax\\n \
5: addl %3,%0\n \
jmp 2b\n \
3: lea 0(%3,%0,4),%0\n\
jmp 2b\n \
.previous\n \
.section __ex_table,\a\\n \
.align 4\n \
.long 4b,5b\n \
.long 0b,3b\n \
.long 1b,2b\n \
.previous \
: =c(size), =D (__d0), =S (__d1), =r(__d2) \
: 3(size), 0(size), 1(to), 2(from) \
: memory);\
} while (0)
--
segher at kernel dot crashing dot org changed:
What|Removed |Added
CC||segher at kernel dot
||crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #5 from dhaliK at jla dot rutgers dot edu 2007-09-30 14:12 --- $ /usr/local/gnu/bin/ld --version GNU ld version 2.17 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. I'm thinking -with-gnu-ld would fail anyways because since this is Solaris we have our GNU binaries in a non-standard path, hence why we use --with-ld= Two questions: Is --enable-bootstrap the default action and *should* I be explicitly enabling bootstrap with this type of setup? I'm also going to try building it with the Sun as and ld. In the same rpm build we do a second normal sparc build with the only difference being its use of the Sun tools, and that build compiles everything just fine. Even though my predecessor alreayd set it up that way, I'm not sure if the GNU ld is specifically needed for sparcv9 since Sun ld works fine on normal sparc builds. Either way... if it's ignoring the explicit declaration of GNU ld and using Sun ld, maybe setting it to Sun ld from the start will have a better result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-09-30 14:27 --- Two questions: Is --enable-bootstrap the default action and *should* I be explicitly enabling bootstrap with this type of setup? Yes, --enable-bootstrap is the default with 4.2.x so you only need to type 'make' or 'gmake' to bootstrap the compiler. As Andrew said, there is some mystery here: if the compiler cannot find /usr/local/gnu/bin/ld, it should never have been able to bootstrap itself. Could you verify that you have 3 compilers in the build directory, one for each stage of the 3-stage bootstrap? If they are there, could you try to reproduce the problem with them (instead of with the installed compiler)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-09-30 14:32 --- Configured with: ../configure --enable-shared --enable-threads --with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as --disable-multilib --disable-libgcj --disable-libffi --disable-libjava --disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 Thread model: posix gcc version 4.2.1 Btw, aren't you building in the source gcc directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug fortran/33400] Formatted read fails if line ends without line break
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-09-30 14:37 --- Subject: Bug 33400 Author: jvdelisle Date: Sun Sep 30 14:36:40 2007 New Revision: 128892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128892 Log: 2007-09-30 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/33400 * gfortran.dg/PR19872.f: Fix test condition. * gfortran.dg/list_read_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/list_read_7.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/PR19872.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33400
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #5 from jacob at math dot jussieu dot fr 2007-09-30 14:58 --- OK, found it, it was a very stupid error by me. Declared the matrix's array with the wrong size, so some write eventually wrote outside of the matrix's array, thus overwriting a reference. Closing the bug report (but still interested in your thoughts in the 4.3 speed regression, cf. previous comment). -- jacob at math dot jussieu dot fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/30299] [4.2/4.3 regression] ICE with broken template and inheritance
--- Comment #3 from pcarlini at suse dot de 2007-09-30 15:50 --- My patch for PR31446 fixes this one too ;) -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30299
[Bug c++/31446] [4.2/4.3 regression] ICE with invalid template parameter
--- Comment #7 from pcarlini at suse dot de 2007-09-30 15:52 --- NB: the patch also fixes PR30299 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug ada/33602] New: FAIL: c452001
splitting /test/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/c4/c452001.a into: c452001_0.ads c452001_0.adb c452001_1.ads c452001_1.adb c452001_2.ads c452001_2.adb c452001_3.ads c452001_3.adb c452001.adb BUILD c452001.adb gnatmake --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -gnat ws -O2 -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support c452001.adb -largs --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c452001.adb /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c452001_0.adb /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c452001_1.adb /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c452001_2.adb /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c452001_3.adb gnatbind -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support -x c452001.ali gnatlink c452001.ali --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/ gcc/ RUN c452001 ,.,. C452001 ACATS 2.5 07-09-30 06:40:49 C452001 Equality of private types and composite types with tagged components. * C452001 User-defined equality for untagged composite component was incorporated into predefined equality for array type. * C452001 User-defined equality for untagged composite component was incorporated into predefined inequality for array type. C452001 FAILED . FAIL: c452001 -- Summary: FAIL: c452001 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33602
[Bug c++/33461] [4.3 regression] ICE with invalid specialization involving parameter packs
--- Comment #2 from pcarlini at suse dot de 2007-09-30 15:53 --- NB: the patch also fixes PR31441 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33461
[Bug ada/25819] CXF3A01 core dump
--- Comment #5 from danglin at gcc dot gnu dot org 2007-09-30 15:55 --- Reappeared between 128058 and 128311. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25819
1culture
Good day bug-gcc Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 1588-347 1airdrop 1barbara 1607494
[Bug tree-optimization/33593] tree-outof-ssa moves sources of non-call exceptions past sequence points
--- Comment #5 from dnovillo at gcc dot gnu dot org 2007-09-30 16:00 --- Subject: Bug 33593 Author: dnovillo Date: Sun Sep 30 16:00:36 2007 New Revision: 128893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128893 Log: PR 33593 * tree-ssa-ter.c (is_replaceable_p): Return false if STMT may throw an exception. testsuite/ChangeLog PR 33593 * g++.dg/tree-ssa/pr33593.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr33593.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-30 16:05 --- Well, the speed regression is certainly not welcome. So, if you have a testcase that shows this you might want to open a new bugreport. A plus, if you can identify the single(?) hot loop that executes slower and compare assembler output for it - maybe there's something obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug ada/25819] CXF3A01 core dump
--- Comment #6 from danglin at gcc dot gnu dot org 2007-09-30 16:15 --- This is now also failing on hppa-unknown-linux-gnu. I first see it in 128257. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25819
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #22 from danglin at gcc dot gnu dot org 2007-09-30 16:26 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/27243] ACATS: c37215h on hppa-linux
--- Comment #4 from danglin at gcc dot gnu dot org 2007-09-30 16:32 --- This is still present in 4.2.2 20070929 (revision 128885). It's the only acats failure. It's not present in 4.3.0 20070929. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27243
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #7 from jacob at math dot jussieu dot fr 2007-09-30 16:41 --- OK, the person who reported the speed regression with g++-4.3 (Michael Olbrich) will open a bug report. I don't actually have g++-4.3 compiled so I'm not the right person to do so. Thanks, Benoit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug fortran/33542] gfortran does not detect ambigious specific names if they are the same as generic names
--- Comment #2 from pault at gcc dot gnu dot org 2007-09-30 16:53 ---
(In reply to comment #1)
Re-reading the Fortran standard, I believe now that already call foo(10) is
invalid (although it is not ambiguous).
In fact, I believe that the ambiguity in the interface is an error; this one
liner fixes the PR -
Index: /svn/trunk/gcc/fortran/interface.c
===
*** /svn/trunk/gcc/fortran/interface.c (revision 128873)
--- /svn/trunk/gcc/fortran/interface.c (working copy)
*** check_interface1 (gfc_interface *p, gfc_
*** 1044,1050
if (p-sym-name == q-sym-name p-sym-module == q-sym-module)
continue;
! if (compare_interfaces (p-sym, q-sym, generic_flag))
{
if (referenced)
{
--- 1044,1051
if (p-sym-name == q-sym-name p-sym-module == q-sym-module)
continue;
! if (compare_interfaces (p-sym, q-sym, generic_flag)
! || p-sym-name == q-sym-name)
{
if (referenced)
{
It's just now regtesting.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-30 16:53:34
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33542
[Bug fortran/33550] ICE (segfault) when USEing ambiguous symbols
--- Comment #1 from pault at gcc dot gnu dot org 2007-09-30 16:55 --- Since I posted a fix, I had better take it! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-09-27 13:26:54 |2007-09-30 16:55:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33550
Re: [Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
On 30 Sep 2007 14:32:32 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-09-30 14:32 --- Configured with: ../configure --enable-shared --enable-threads --with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as --disable-multilib --disable-libgcj --disable-libffi --disable-libjava --disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 Thread model: posix gcc version 4.2.1 Btw, aren't you building in the source gcc directory? nope two dots.
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #8 from pinskia at gmail dot com 2007-09-30 16:58 --- Subject: Re: gcc 4.2.1 ignores GNU ld on Solaris 9 On 30 Sep 2007 14:32:32 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-09-30 14:32 --- Configured with: ../configure --enable-shared --enable-threads --with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as --disable-multilib --disable-libgcj --disable-libffi --disable-libjava --disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 Thread model: posix gcc version 4.2.1 Btw, aren't you building in the source gcc directory? nope two dots. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-09-30 17:00 --- nope two dots. Yes, that's precisely why I said source gcc and not source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #10 from dhaliK at jla dot rutgers dot edu 2007-09-30 17:08 --- We build it twice. One for normal sparc (v8+ I believe) and one for sparcv9. The rpm spec file just cd's into gcc and makes a tmp sparc directory... hence the ../configure. It then makes a sparcv9 directory and does the same thing all over. This way one pass with rpmbuild spits out both. I'll get back to you on reproducing it in the build directory since it's still running right now from before... old machine and it doesn't seem to like gmake -j and exits randomly between files :( I'm interested to see if this build with sun as and ld gives the same problem since our normal sparc build doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-09-30 17:51 --- We build it twice. One for normal sparc (v8+ I believe) and one for sparcv9. The rpm spec file just cd's into gcc and makes a tmp sparc directory... hence the ../configure. It then makes a sparcv9 directory and does the same thing all over. This way one pass with rpmbuild spits out both. Note that we specifically warn against configuring the compiler that way: http://gcc.gnu.org/install/configure.html Moreover, what do you call to build for sparcv9 exactly? In other words, what's the difference between your 2 builds? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #12 from dhaliK at jla dot rutgers dot edu 2007-09-30 18:12 --- Thanks for the subdir heads up, I was not aware of that being an issue. On my next build I'll move it outside the src tree and see if it is happier. As far as sparcv9 goes, the bin and lib dirs obviously have to be different: --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 as opposed to defaults, but the main differences is the use of: LD_RUN_PATH=/usr/local/lib/sparcv9:/usr/local/lib rather than the standard /usr/local/lib. We don't want default sparc builds (v8+) looking in sparcv9 and of course sparcv9 should. Actually, while I was looking through the spec for this I found a typo that probably isn't related but could be a problem and should be fixed. In the meantime I'm rerunning the build outside of the src tree at your request. Have you guys had issues in the past with gmake -j or is it just my particular build platform? I wish I could use smp... it would finish a lot faster ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-09-30 18:30 --- As far as sparcv9 goes, the bin and lib dirs obviously have to be different: --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 as opposed to defaults, but the main differences is the use of: LD_RUN_PATH=/usr/local/lib/sparcv9:/usr/local/lib rather than the standard /usr/local/lib. None of these settings will give you a sparcv9 compiler and that could explain your problem. The sparcv9 subdirectory of /lib on Solaris contains 64-bit libraries so you need a 64-bit capable compiler to use them, either the multilib 32-bit sparc-sun-solaris2.9 compiler or the sparc64-sun-solaris2.9 compiler. The configure line you posted will build the non-multilib 32-bit compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug java/33570] Just tried to compile a java source code with gcc java
--- Comment #1 from tromey at gcc dot gnu dot org 2007-09-30 18:31 --- Compiling java source with gcc is not really supported. Instead use the gcj driver, which reads libgcj.spec and thus gets the proper options passed to jc1. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Just tried to compile a java|Just tried to compile a java |source code with gcc java |source code with gcc java http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33570
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #14 from dhaliK at jla dot rutgers dot edu 2007-09-30 18:40 --- None of these settings will give you a sparcv9 compiler and that could explain your problem. The sparcv9 subdirectory of /lib on Solaris contains 64-bit libraries so you need a 64-bit capable compiler to use them, either the multilib 32-bit sparc-sun-solaris2.9 compiler or the sparc64-sun-solaris2.9 compiler. The configure line you posted will build the non-multilib 32-bit compiler. Hmm that would be a problem! I think what we had in mind was ensuring that our custom 64bit packages (/usr/local/lib/sparcv9) were in the run path, while assuming that /lib/sparcv9 was already there. Sorry for the trouble, you've been a great help, but can you point me in the right direction of a proper 64bit configure, or better yet, a multlib build (than I only have to build it once! :) I know I had experimented trying to get multilib working once already but it never happened. Either way, if it's not possible on solaris at least getting a proper 64bit would be great. Our 32bit seems to work fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-09-30 18:45 --- Sorry for the trouble, you've been a great help, but can you point me in the right direction of a proper 64bit configure, or better yet, a multlib build (than I only have to build it once! :) I know I had experimented trying to get multilib working once already but it never happened. Either way, if it's not possible on solaris at least getting a proper 64bit would be great. Our 32bit seems to work fine. Multilib has worked for ages, just configure without --disable-multilib and without fiddling with --bindir and --libdir. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
llivrhol
Good day bug-gcc Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 lletysyp llacsenu livyenir llipimed
[Bug libstdc++/33603] New: configuration failure during native build
Native build on i686-pc-mingw32 fails in libstdc++ with: checking for sin in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 -- Summary: configuration failure during native build Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gdr at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
[Bug ada/25819] CXF3A01 core dump
--- Comment #7 from danglin at gcc dot gnu dot org 2007-09-30 19:52 --- This is probably a different problem. Oh well, (gdb) r Starting program: /test/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/cxf/cxf3a01/cxf3a01 warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. ,.,. CXF3A01 ACATS 2.5 07-09-30 15:19:49 CXF3A01 Check that the Valid function from package Ada.Text_IO.Editing returns False for strings that fail to comply with the composition constraints defined for picture strings. Check that the Valid function returns True for strings that conform to the composition constraints defined for picture strings. Program received signal SIGSEGV, Segmentation fault. 0x0002a9e0 in ada.text_io.editing.expand () at a-teioed.adb:110 110 return Result (1 .. Result_Index - 1); Current language: auto; currently ada (gdb) bt #0 0x0002a9e0 in ada.text_io.editing.expand () at a-teioed.adb:110 #1 0x0002ac64 in ada.text_io.editing.valid (blank_when_zero=true) at a-teioed.adb:2754 #2 0x0002f228 in _ada_cxf3a01 () (gdb) disass 0x0002a9d0 0x0002a9f0 Dump of assembler code from 0x2a9d0 to 0x2a9f0: 0x0002a9d0 ada__text_io__editing__expand+200: b,l 0xdf08 system__secondary_stack__ss_allocate,rp 0x0002a9d4 ada__text_io__editing__expand+204: depwi 0,31,2,r26 0x0002a9d8 ada__text_io__editing__expand+208: copy ret0,r3 0x0002a9dc ada__text_io__editing__expand+212: ldi 1,ret0 0x0002a9e0 ada__text_io__editing__expand+216: stw ret0,0(r3) 0x0002a9e4 ada__text_io__editing__expand+220: stw r4,4(r3) 0x0002a9e8 ada__text_io__editing__expand+224: copy r5,r24 0x0002a9ec ada__text_io__editing__expand+228: ldo 8(r3),r4 End of assembler dump. It appears system__secondary_stack__ss_allocate is broken: (gdb) p/x $ret0 $7 = 0x7900ff48 (gdb) p *$ret0 Cannot access memory at address 0x7900ff48 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25819
[Bug libstdc++/33603] configuration failure during native build
--- Comment #1 from rask at gcc dot gnu dot org 2007-09-30 20:35 --- Please look in your config.log for messages from collect2 and post the last linker failure one plus any that look wrong. -- rask at gcc dot gnu dot org changed: What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
[Bug fortran/33354] [4.2 only] MINLOC in combination with SUM gives wrong result
--- Comment #7 from enok at lysator dot liu dot se 2007-09-30 20:56 --- (In reply to comment #6) (In reply to comment #5) I added a testcase for this. Thanks! Can this bug be closed or does anyone feel strongly enough about it to fix it in 4.2? If we can identify which patch fixed this, I'd be in favor of backporting (even though we'll miss 4.2.2). Thomas I think it's a pretty serious bug. Everyone who uses MINLOC or MAXLOC will silently get wrong result in certain cases and those intrinsics are fairly commonly used. It would sure be nice if this could be fixed in 4.2.3, to bad its to late for 4.2.2. Let me know if theres anything I can do to help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354
[Bug fortran/33354] [4.2 only] MINLOC in combination with SUM gives wrong result
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-09-30 21:03 --- I am currently trying to find the patch responsible for fixing this. This could indeed be Paul's fix for PR 32298 and 31726. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354
[Bug c++/33604] New: significantly slower results with 4.3 compared to 4.2
In a C++ template library (a matrix library with expression templates) upgrading from g++-4.2 to g++-4.3 results in 3x slower programs. Compiler versions: g++-4.2 (GCC) 4.2.1 (Debian 4.2.1-5) g++-4.3 (Debian 4.3-20070902-1) 4.3.0 20070902 (experimental) [trunk revision 128028] $ g++-4.2 -O3 -DNDEBUG benchmark.cpp -o benchmark time ./benchmark 1.0001 0 0 0 1.0001 0 0 0 1.0001 real0m4.495s user0m4.416s sys 0m0.003s $ g++-4.3 -O3 -DNDEBUG benchmark.cpp -o benchmark time ./benchmark 1.0001 0 0 0 1.0001 0 0 0 1.0001 real0m15.891s user0m15.595s sys 0m0.018s I looked at the assembler code but I didn't see anything obvious (I don't know much about assembler so I may have missed something. I did notice that adding -fforce-addr changes the result for 4.3 but not for 4.2. $ g++-4.3 -O3 -DNDEBUG benchmark.cpp -fforce-addr -o benchmark time ./benchmark 1.0001 0 0 0 1.0001 0 0 0 1.0001 real0m8.779s user0m8.662s sys 0m0.007s -- Summary: significantly slower results with 4.3 compared to 4.2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot olbrich at gmx dot net GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug c++/33604] significantly slower results with 4.3 compared to 4.2
--- Comment #1 from michael dot olbrich at gmx dot net 2007-09-30 21:15 --- Created an attachment (id=14273) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14273action=view) The archive allowing to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug libstdc++/33603] configuration failure during native build
--- Comment #2 from gdr at cs dot tamu dot edu 2007-09-30 21:22 --- Subject: Re: configuration failure during native build rask at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Comment #1 from rask at gcc dot gnu dot org 2007-09-30 20:35 --- | Please look in your config.log for messages from collect2 and post the last | linker failure one plus any that look wrong. Many thanks for the quick and helpful reply. While looking for collect2, I realized the path to ld (and as) had been misdetected. Explicit specification of the path, --with-ld=/mingw/bin/ld.exe, let me have a successful configuration. The buikd is now past the confiuguration step. I hope there won't be anymore failure. Many thanks! Is this type of failure documented somewhere? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
[Bug libstdc++/32666] FAIL: abi_check
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-30 21:51 --- Subject: Re: FAIL: abi_check --- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-18 21:54 --- These all appear to be fails from missing C99 math functionality: tanl, etc. So, maybe something with libmath config, config for C99 functions? I think an update to the baseline symbols is needed. We now have libc 2.6. Dave --- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-30 21:51 --- Created an attachment (id=14274) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14274action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-30 22:28
---
The patch below should provide fallback functions (build in maintainer mode or
use autoreconf in libgfortran), does it work?
Index: intrinsics/c99_functions.c
===
--- intrinsics/c99_functions.c (revision 128673)
+++ intrinsics/c99_functions.c (working copy)
@@ -168,6 +168,31 @@ erfcf (float x)
#endif
+/* Wrappers for systems without the C99 gammaf() and lgammaf() functions. */
+
+#if defined(HAVE_GAMMA) !defined(HAVE_GAMMAF)
+#define HAVE_GAMMAF 1
+extern float gammaf (float);
+
+float
+gammaf (float x)
+{
+ return (float) gamma ((double) x);
+}
+#endif
+
+#if defined(HAVE_LGAMMA) !defined(HAVE_LGAMMAF)
+#define HAVE_LGAMMAF 1
+extern float lgammaf (float);
+
+float
+lgammaf (float x)
+{
+ return (float) lgamma ((double) x);
+}
+#endif
+
+
#ifndef HAVE_ACOSF
#define HAVE_ACOSF 1
float
Index: c99_protos.h
===
--- c99_protos.h(revision 128673)
+++ c99_protos.h(working copy)
@@ -284,6 +284,19 @@ extern float erfcf (float);
#endif
+/* Wrappers for systems without the C99 gammaf() and lgammaf() functions. */
+
+#if defined(HAVE_GAMMA) !defined(HAVE_GAMMAF)
+#define HAVE_GAMMAF 1
+extern float gammaf (float);
+#endif
+
+#if defined(HAVE_LGAMMA) !defined(HAVE_LGAMMAF)
+#define HAVE_LGAMMAF 1
+extern float lgammaf (float);
+#endif
+
+
/* log10l is needed on all platforms for decimal I/O */
#ifndef HAVE_LOG10L
Index: configure.ac
===
--- configure.ac(revision 128673)
+++ configure.ac(working copy)
@@ -379,6 +379,10 @@ AC_CHECK_LIB([m],[y1l],[AC_DEFINE([HAVE_
AC_CHECK_LIB([m],[ynf],[AC_DEFINE([HAVE_YNF],[1],[libm includes ynf])])
AC_CHECK_LIB([m],[yn],[AC_DEFINE([HAVE_YN],[1],[libm includes yn])])
AC_CHECK_LIB([m],[ynl],[AC_DEFINE([HAVE_YNL],[1],[libm includes ynl])])
+AC_CHECK_LIB([m],[gamma],[AC_DEFINE([HAVE_GAMMA],[1],[libm includes gamma])])
+AC_CHECK_LIB([m],[gammaf],[AC_DEFINE([HAVE_GAMMAF],[1],[libm includes
gammaf])]
)
+AC_CHECK_LIB([m],[lgamma],[AC_DEFINE([HAVE_LGAMMA],[1],[libm includes
lgamma])]
)
+AC_CHECK_LIB([m],[lgammaf],[AC_DEFINE([HAVE_LGAMMAF],[1],[libm includes
lgammaf
])])
# On AIX, clog is present in libm as __clog
AC_CHECK_LIB([m],[__clog],[AC_DEFINE([HAVE_CLOG],[1],[libm includes clog])])
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug libfortran/33583] FAIL: gfortran.dg/gamma_1.f90
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-30 22:31 --- Subject: Re: FAIL: gfortran.dg/gamma_1.f90 The patch below should provide fallback functions (build in maintainer mode or use autoreconf in libgfortran), does it work? I'll give this a whirl after the current build and check completes... Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
[Bug libstdc++/33605] New: Comparable concepts cause errors with abstract types
The following code fails because __gnu_cxx::_LessThanOpConcept has member
variables of type iterator::value_type, where iterator is an iterator over
an abstract type. 20.1.2 (LessThanComparable) doesn't mention that the type
has to be concrete.
#define _GLIBCXX_CONCEPT_CHECKS
#include algorithm
#include tr1/memory
#include vector
#include boost/iterator/indirect_iterator.hpp
struct AbstractThing
{
virtual void F() = 0; // comment this out and it works
};
struct ConcreteThing : AbstractThing
{
void F() {}
};
bool operator (const AbstractThing , const AbstractThing )
{
return false;
}
int main()
{
typedef std::vectorstd::tr1::shared_ptrAbstractThing Things;
Things things;
std::lower_bound(
boost::make_indirect_iterator(things.begin()),
boost::make_indirect_iterator(things.end()), ConcreteThing());
}
$ g++ -I../../../boost.1.34.0 -otest test.cpp
C:/devel/mingw/include/c++/4.2.1/bits/boost_concept_check.h: In instantiation
of
'__gnu_cxx::_LessThanOpConceptAbstractThing, ConcreteThing':
C:/devel/mingw/include/c++/4.2.1/bits/boost_concept_check.h:63: instantiated
f
rom 'void __gnu_cxx::__function_requires() [with _Concept =
__gnu_cxx::_LessThan
OpConceptAbstractThing, ConcreteThing]'
C:/devel/mingw/include/c++/4.2.1/bits/stl_algo.h:2894: instantiated from
'_For
wardIterator std::lower_bound(_ForwardIterator, _ForwardIterator, const _Tp)
[w
ith _ForwardIterator =
boost::indirect_iterator__gnu_cxx::__normal_iteratorstd
::tr1::shared_ptrAbstractThing*,
std::vectorstd::tr1::shared_ptrAbstractThin
g, std::allocatorstd::tr1::shared_ptrAbstractThing ,
boost::use_default
, boost::use_default, boost::use_default, boost::use_default, _Tp =
ConcreteThi
ng]'
test.cpp:26: instantiated from here
C:/devel/mingw/include/c++/4.2.1/bits/boost_concept_check.h:299: error: cannot
d
eclare field '__gnu_cxx::_LessThanOpConceptAbstractThing, ConcreteThing::__a'
to be of abstract type 'AbstractThing'
test.cpp:8: note: because the following virtual functions are pure within
'Abs
tractThing':
test.cpp:9: note: virtual void AbstractThing::F()
--
Summary: Comparable concepts cause errors with abstract types
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33605
[Bug libstdc++/33605] Comparable concepts cause errors with abstract types
--- Comment #1 from gcc at david dot osborn dot name 2007-09-30 22:48 --- Created an attachment (id=14275) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14275action=view) Patch for predicate and arithmetic constraints This patch fixes the immediate problem, but I think there may be other instances of this issue in bits/boost_concept_check.h. See this comment: // possibly should be Tp* a; and then dereference a in constraint // functions? present way would require a default ctor, i think... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33605
[Bug fortran/33502] gfortran with .F suffix and -g3 option chokes on preprocessor syntax
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-01 00:05 --- Created an attachment (id=14276) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14276action=view) Updated patch The attached updated patch seems to fix the issue (and also fixes a problem in the logic and yet another unrelated problem; I'll explain in my submission mail). This is currently regtesting with different debug formats. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33502
[Bug fortran/33539] Too much noise for zero-length character strings
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-10-01 00:07:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33539
[Bug c++/28639] [4.2/4.3 regression] ICE trying to print error on invalid template parameter
--- Comment #9 from pcarlini at suse dot de 2007-10-01 00:51 --- My patch for PR31446 fixes this one too ;) -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/31446] [4.2/4.3 regression] ICE with invalid template parameter
--- Comment #8 from pcarlini at suse dot de 2007-10-01 00:52 --- NB: the patch also fixes PR28639 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug c++/33590] c++ crash in KDE's qca module
--- Comment #4 from bangerth at dealii dot org 2007-10-01 01:10 --- On big files, this is what can happen with optimized builds... -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33590
[Bug target/33548] Core dump on HPUX
--- Comment #1 from ajd at gentrack dot com 2007-10-01 01:58 --- Compile with -Wl,-Z and it succeeds: gcc-4.1.2/bin/gcc -mlp64 pam_test.c -lpam -o pt -Wl,-Z It appears libpam on hpux requires -Z. It was removed here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00542.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33548
[Bug other/33606] New: cannot find library
I'm using 4.1.2, on an intel P4 2.6 and running the latest Debian. No matter how I describe it at the command line, the linker fails to find libcairo.a My library is located at /usr/lib My include is located at /usr/include/cairo The library is libcairo.a My command line looks like this.. gcc -I/usr/include/cairo graphics.c -L/usr/lib -llibcairo.a I can compile graphics.c to an object. ld answers with the same result. It will always say ld: cannot find -llibcairo.a The file is there. I can open it, and it shows up in the directory. I can exclude the .a extension. I can use the longhand switch. No matter what I do, it always ends with the same results. I suspect this is not really a bug, but I'm doing something wrong. The manual, while being substantial, includes no examples for even the common switches. I'm here to tell you, people (even the ones on #gcc IRC don't wanna touch it) are not helpful about it. And I LOVE GNU/Linux for teaching me more about computers in the last year than my life combined. I suspected that maybe the library is built wrong, but I used Synaptic to install it. It does link the standard libraries, however. Why can't it see it? -- Summary: cannot find library Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: virtualphoton at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33606
[Bug other/33606] cannot find library
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-01 02:27 --- -llibcairo.a should be -lcairo. A better place to ask this question is on [EMAIL PROTECTED] mailing list. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33606
[Bug other/33585] make html does not work for install files
--- Comment #3 from manu at gcc dot gnu dot org 2007-10-01 02:38 --- Subject: Bug 33585 Author: manu Date: Mon Oct 1 02:38:31 2007 New Revision: 128900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128900 Log: 2007-10-01 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR other/33585 * Makefile.in (build_html_dir/gccinstall): gccinstall.texi needs to be processed with the special script doc/install.texi2html. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33585
[Bug other/33585] make html does not work for install files
--- Comment #4 from manu at gcc dot gnu dot org 2007-10-01 02:39 --- *** Bug 33543 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||karthikkumar at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33585
[Bug other/33543] make html does not generate gccinstall documentation properly
--- Comment #2 from manu at gcc dot gnu dot org 2007-10-01 02:39 --- *** This bug has been marked as a duplicate of 33585 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33543
[Bug other/33585] make html does not work for install files
--- Comment #5 from manu at gcc dot gnu dot org 2007-10-01 02:39 --- Fixed for GCC 4.3 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33585
[Bug inline-asm/33600] [4.3 Regression] Breakage caused by the fix to PR33552
--- Comment #5 from matz at gcc dot gnu dot org 2007-10-01 02:51 --- Mine. Have a patch. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug inline-asm/33600] [4.3 Regression] Breakage caused by the fix to PR33552
-- matz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-01 02:52:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33600
[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values
--- Comment #10 from pault at gcc dot gnu dot org 2007-10-01 04:39 --- (In reply to comment #9) This probably caused by: http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00745.html r126885 | pault | 2007-07-24 21:15:27 +0200 (Di, 24 Jul 2007) | 36 lines 2007-07-24 Paul Thomas [EMAIL PROTECTED] PR 31205 PR 32842 * trans-expr.c (gfc_conv_function_call): Remove the default initialization of intent(out) derived types. Yes, the initialization is occurring in the wrong place in gfc_trans_deferred_vars. It looks to be easily fixable. I'll be onto it tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
