The following valid code snippet triggers a segfault on mainline:
=
template void foo()
{
__decltype(0 ?: 0) x;
}
=
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [e
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34270
The following invalid code snippet triggers an ICE on mainline:
=
template struct A
{
static int i;
};
template int A::i(__decltype( A::i ));
=
bug.cc:6: internal compiler error: in finish_d
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34271
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 21:26 ---
Given that you provide no address for V1 and V2 and given that they are local
variables, there is no way they could be modified from outside (since you have
no way to know where the compiler would place them if it indeed
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-28 21:27 ---
> With your patch the runtime went from
> 93.670u 0.103s 1:33.85 99.9%0+0k 0+0io 32pf+0w
> to
> 38.741u 0.038s 0:38.85 99.7%0+0k 0+1io 32pf+0w
Thus: 59% faster. Here, it "only" went ~30% down from 49.89s to ~
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34273
A broken diagnostic is issued by mainline for the following code snippet:
=
struct A {};
struct B : A
{
B() : A()... {}
};
=
bug.cc: In constructor 'B::B()':
bug.cc:5: error: cannot expand initializer for member '#'tree_binfo' not
supported by dump_decl#
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 21:32 ---
The current SVN trunk gives the message you expect.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
-
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
===
template struct A {};
template struct A
{
template void foo();
};
void bar()
{
A a;
a.foo<0>();
}
===
bug.cc:3: error: template parameters not
A broken diagnostic is issued by mainline for the following code snippet:
===
template struct A
{
template class> struct B {};
};
A<0> a;
===
bug.cc:3: error: 'void' is not a
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 21:34 ---
Still present on SVN trunk
+===GNAT BUG DETECTED==+
| 4.3.0 20071127 (experimental) (i686-pc-linux-gnu) GCC error: |
| in gnat_to_gnu_entity, at ada/decl.c
A broken diagnostic is issued since GCC 4.0.0 for the following code snippet:
===
struct A
{
virtual A foo();
};
void bar(A& a)
{
a.foo()=0;
}
===
bug.cc: In function 'void
--- Comment #2 from Erik dot Bouts at Shell dot com 2007-11-28 21:50
---
Subject: RE: Pointer to template method of a class A, does not work in
template context for that class A
Hi pinskia,
this works!!
thanks!!
kind regards,
Erik
-Original Message-
From: pinskia at g
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-28 21:51 ---
Closing as invalid, the template keyword here is required as ClassA is
dependent so the compiler does not know if ClassA::method is a template or not.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-28 21:54 ---
Only the RM should change the priority. And I don't think this is blocking as
the difference is not different in working vs not working code.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #10 from steven at gcc dot gnu dot org 2007-11-28 22:02 ---
> + for (defs = DF_INSN_DEFS (insn);
> + *defs && DF_REF_REGNO (*defs) != REGNO (x);
> + defs++)
> +;
Are you aware of df_find_def() ?
> + if (minus_elt)
> + cmp = cse_find_compari
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-28 22:05
---
Indeed - unexpectedly impressive ;) The patch has (obviously) received no
tuning
as of the placement of the early unrolling in the pass pipeline and early
unrolling is only done if that doesn't increase code-size
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-28 22:08 ---
Also there isn't any regression now, but it works because the patch is (still)
in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34255
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34275
--- Comment #5 from andreasmeier80 at gmx dot de 2007-11-28 22:12 ---
It worked well in revision r128078
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
--- Comment #3 from shockenhull at niceberg dot com 2007-11-28 22:23
---
the problem is in the pre-compiled c++ library
work around:
using option -D_GLIBCXX_EXTERN_TEMPLATE=0
disable pre-compiled templates in the c++ headers and force correct
instanciation when -fleading-underscore i
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-28 22:27 ---
And the same with __typeof__ instead of __decltype. Since 3.4.
Why is this considered an regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-28 22:29 ---
Well, what do you expect by trying to declare an array of size 2**48 - 2**40 +
1, which is much greater than the 2**32 bytes of addressable memory on your
i686-pc-linux-gnu target? :/
(2**48) % (2**32) = 0 = (2**40) % (
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-28 22:34 ---
This is not a bug since you did not compile libstdc++ with
-fleading-underscore. There are some headers with extern template.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from dominiq at lps dot ens dot fr 2007-11-28 22:35 ---
Here are the timings before and after the patch for the polyhedron tests and
some variants:
Before patch After patch
Benchmark Ave Run Number Estim: Ave Run Numbe
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-28 22:07 ---
Created an attachment (id=14658)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14658&action=view)
example patch
This patch is an example of the suggestion in comment #6. When compiling with
-S -dp, it is clear wh
--- Comment #12 from steven at gcc dot gnu dot org 2007-11-28 22:49 ---
The only timings significantly changed are actually the compile times, which go
up significantly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
--- Comment #3 from raksit at google dot com 2007-11-28 23:06 ---
I am looking into this.
--
raksit at google dot com changed:
What|Removed |Added
CC|
--- Comment #13 from kargl at gcc dot gnu dot org 2007-11-28 23:06 ---
(In reply to comment #12)
> The only timings significantly changed are actually the compile times, which
> go
> up significantly.
>
Look at the kepler execution time. 22.73 s without the patch and
26.11 s with th
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-28 23:17 ---
Yes, that too. It was more a sarcastic addendum to your remark that there were
so few significantly changed numbers. It seemed to me you should not look at
just the execution times ;-)
--
http://gcc.gnu.org/bu
--- Comment #15 from dominiq at lps dot ens dot fr 2007-11-28 23:57 ---
If I am allowed to be sacarstic too, I'll say that the increase in compile time
(worst case 11%, arithmetic average 5%) is not against the current trend one
can see for instance in
http://www.suse.de/~gcctest/c++ben
--- Comment #5 from sergey dot gcc at comrades dot id dot au 2007-11-29
00:04 ---
(In reply to comment #3)
> // Workaround:
> class a
> {
> public:
> template
> operator T &() const
> throw(typename ::boost::disable_if<
> ::boost::
> /usr/local/gcc43-ira/bin/gcc -v
Using built-in specs.
Target: i386-apple-darwin9.0.0
Configured with: ../gcc/configure --prefix=/usr/local/gcc43-ira
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls --disable-bootstrap
--enable-languages=c,c++
--- Comment #1 from astrange at ithinksw dot com 2007-11-29 00:08 ---
Created an attachment (id=14659)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14659&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34279
--- Comment #11 from rask at gcc dot gnu dot org 2007-11-29 00:09 ---
In reply to comment #10 from Steven Bosscher 2007-11-28 22:02:
> > + for (defs = DF_INSN_DEFS (insn);
> > + *defs && DF_REF_REGNO (*defs) != REGNO (x);
> > + defs++)
> > +;
> Are you aware of df_find
--- Comment #6 from doko at gcc dot gnu dot org 2007-11-29 00:33 ---
Subject: Bug 34130
Author: doko
Date: Thu Nov 29 00:32:58 2007
New Revision: 130507
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130507
Log:
gcc/
2007-11-29 Matthias Klose <[EMAIL PROTECTED]>
Backpo
trying to do something simple like:
$ gcc -MM one.c two.c three.c -o .depend
results in .depend only containing the information from the last file processed
as each file processed causes the output to be opened/closed with O_TRUNC
$ cat .depend
three.o: three.c
$ strace -f -eopen gcc -MM one.c t
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-29 01:54 ---
This should be rejected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34280
With gcc version 4.3.0 20071024 (experimental) [trunk revision 129615]
configured:
../trunk/configure --enable-languages=c,c++,java --disable-static
--enable-__cxa_atexit --prefix=/home/daney/mvl_ti/gcj --with-gmp=/home/daney/mp
--with-mpfr=/home/daney/mp
--with-sysroot=/home/daney/mvl_ti/mv_pro_
--- Comment #9 from rakdver at gcc dot gnu dot org 2007-11-29 04:29 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01607.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2007-11-29
04:34 ---
It appears that the Darwin9 linker will be modified to handle this issue as the
linux linker does in the next Developer Tools update. However it is very
unlikely Darwin8's cctools will ever see such a fix.
--- Comment #10 from aoliva at gcc dot gnu dot org 2007-11-29 06:00 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned a
This testcase:
int test (int a)
{
volatile int z;
z = a + 1;
return z;
}
compiles into:
test:
subl$16, %esp #,
movl20(%esp), %eax # a, z.0
addl$1, %eax#, z.0
movl%eax, 12(%esp) # z.0, z
(1) movl12(%e
Following testcase:
--cut here--
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
typedef long long __v2di __attribute__ ((__vector_size__ (16)));
__m128i _mm_set_epi64x (long long __q1, long long __q0)
{
return __extension__ (__m128i)(__v2di){ __q0, __q1 };
}
-
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-11-29 07:13
---
> IMO, there is no need for (1), since we already have correct value in %eax.
> However, even when value lives in another register, we should load it into
> the return register from the reg, not from mem location.
--- Comment #6 from andreasmeier80 at gmx dot de 2007-11-29 07:41 ---
It worked also well in revision r128079. I'm going to do further tests to find
the causing commit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
101 - 148 of 148 matches
Mail list logo
