--- 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
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.
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
--- 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
--- 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 #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
--
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 #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
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 #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
--- 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 #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
> /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 #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::
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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
--- 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 #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 #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 #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 #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 #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
--
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
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
--
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
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=34273
--- 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 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
--- 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 ~
--- 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
--
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
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=34270
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=34269
The following invalid code snippets are wrongly accepted on mainline:
=
void foo() { __decltype; }
=
=
void foo() { __decltype(; }
=
--
Summary: [4.3 regression] Incomplet
--
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=34268
The following invalid code snippet triggers an ICE on mainline:
==
struct A
{
__decltype(~A);
};
==
bug.cc:3: internal compiler error: in lookup_member, at cp/search.c:1206
Please submit a full bug report,
--
Summary: [4.3 regression
--- Comment #11 from sabre at nondot dot org 2007-11-28 20:57 ---
Please don't disable these. There are a variety of compilers that optionally
or only generate C code, particularly for the functional languages. This is
useful functionality for these compilers.
--
http://gcc.gnu.or
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:55 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--
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=34267
The following invalid code snippet triggers an ICE on mainline:
==
template struct A
{
__decltype(A);
};
==
bug.cc:3: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:15697
Please submit a full bug report, [etc.]
--
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:52 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #15 from sam at gcc dot gnu dot org 2007-11-28 20:51 ---
Forget message, wrong # in ChangeLogs, will fix them
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17317
--- Comment #8 from aldot at gcc dot gnu dot org 2007-11-28 20:50 ---
A toplevel 'make' does what 'make bubblestrap' did before.
See also:
http://gcc.gnu.org/ml/gcc/2005-12/msg00435.html
http://gcc.gnu.org/ml/fortran/2005-12/msg00338.html
If install.texi from the 4_2-branch mentions thi
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-28 20:50 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-28 20:49 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #1 from sam at gcc dot gnu dot org 2007-11-28 20:48 ---
Subject: Bug 22559
Author: sam
Date: Wed Nov 28 20:48:10 2007
New Revision: 130498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130498
Log:
gcc/ada/
PR ada/22559
* sem_ch3.adb (Build_Derive
--- Comment #8 from jb at gcc dot gnu dot org 2007-11-28 20:48 ---
The vectorization of dot products is covered by PR31738, I suppose
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:46 ---
Subject: Bug 32792
Author: sam
Date: Wed Nov 28 20:46:18 2007
New Revision: 130497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130497
Log:
gcc/ada/
PR ada/32792
* sem_attr.adb (Analyze_Att
--- Comment #14 from sam at gcc dot gnu dot org 2007-11-28 20:45 ---
Subject: Bug 17317
Author: sam
Date: Wed Nov 28 20:44:58 2007
New Revision: 130496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130496
Log:
gcc/ada/
PR ada/17317
* par-ch4.adb (Is_Paramete
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:43 ---
Subject: Bug 15803
Author: sam
Date: Wed Nov 28 20:43:25 2007
New Revision: 130495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130495
Log:
gcc/ada/
PR ada/15803
* par-ch3.adb (P_Variant_Pa
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2007-11-28 20:08 ---
Subject: Re: Expressions of parameters evaluated with too high precision
On Wed, Nov 28, 2007 at 07:23:57PM -, fxcoudert at gcc dot gnu dot org
wrote:
>
> To sum up my point of view: -fno-ra
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-28 19:49 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-11-28 19:49
---
Patch applied. Thanks to David for the testing and
Mark for the review.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
f-conv.c (if_convertible_phi_p): Fail if BB other than
loop->header has virtual phi nodes.
* gcc.c-torture/compile/20071128-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20071128-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/
--- Comment #10 from rsandifo at gcc dot gnu dot org 2007-11-28 19:46
---
Subject: Bug 32406
Author: rsandifo
Date: Wed Nov 28 19:46:03 2007
New Revision: 130493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130493
Log:
gcc/
PR target/32406
* builtins.c (expand
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-28 19:45 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-28 19:43 ---
Subject: Bug 34247
Author: jakub
Date: Wed Nov 28 19:43:03 2007
New Revision: 130492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130492
Log:
* trans-expr.c (gfc_trans_string_copy): Convert both dest
--- Comment #5 from meklund at cisco dot com 2007-11-28 19:43 ---
Subject: Re: feature request: generate a warning for sizeof on a pointer
Hi Manu,
This is in regards to your Comments for the gcc feature enhancement
request, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702.
On Wed,
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-28 19:35 ---
> > If +Inf is a representable value, you need to go fix the IO subsystem
> > to read +Inf (and NaN).
I just checked:
- NAG f95, g95, ifort and sunf95 accept (case insensitive and with optional
"+"/"-" prefix) "NAN"
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-28 19:23
---
(In reply to comment #7)
> a) Do other compilers have an equivalent to -fno-range-check?
Most compilers have a behaviour similar to -fno-range-check by default, only
warning about range problems (Intel, Sun, g95
/*
% uname -a
Linux lepidus 2.4.21-sgi302r24 #1 SMP Fri Oct 22 22:43:12 PDT 2004 ia64 ia64
ia64 GNU/Linux
% gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.2.2/src/gcc-4.2.2/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/b
--- Comment #8 from tromey at gcc dot gnu dot org 2007-11-28 19:07 ---
*** Bug 33473 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from tromey at gcc dot gnu dot org 2007-11-28 19:07 ---
*** This bug has been marked as a duplicate of 14933 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-28 19:06 ---
Confirmed.
I didn't see any instances of @findex or @vindex in hostconfig.texi.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from kargl at gcc dot gnu dot org 2007-11-28 19:06 ---
(In reply to comment #6)
> I consider this a bug. I have to check, but I think that the IEEE rules are
> clear, even though they are not mandatory until we introduce the corresponding
> standard modules. The calculatio
--- Comment #13 from pbrook at gcc dot gnu dot org 2007-11-28 19:05 ---
The short answer is don't do that.
-mabi=iwmmxt selects a bare-metal (short-enum) AAPCS variant with iWMMXt
calling conventions. As such it is incompatible with the Linux EABI supplement
(http://www.codesourcery.com
--- Comment #7 from dominiq at lps dot ens dot fr 2007-11-28 18:48 ---
Subject: Re: Missed optimizations
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
Pretty impressive!
Note that with
--- Comment #12 from aldot at gcc dot gnu dot org 2007-11-28 18:28 ---
Not target specific, adjusting accordingly.
Observed everywhere with -fshort-enums
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-28 18:21 ---
Can you reproduce this with anything newer than 3.4?
The 3.x release series is closed. I couldn't reproduce with 4.1.
So, barring new information, I think this is fixed.
--
tromey at gcc dot gnu dot org changed:
--- Comment #6 from dominiq at lps dot ens dot fr 2007-11-28 18:18 ---
Subject: Re: Missed optimizations
> For example with a patch like this.
You also need
--- ../_gcc_clean/gcc/tree-flow.h 2007-11-16 16:17:46.0 +0100
+++ ../gcc-4.3-work/gcc/tree-flow.h 2007-11-28
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-28 18:03
---
I consider this a bug. I have to check, but I think that the IEEE rules are
clear, even though they are not mandatory until we introduce the corresponding
standard modules. The calculation of y does overflow, and
--- Comment #43 from dank at kegel dot com 2007-11-28 18:01 ---
Of the results posted above, the only interesting one that is still slower
than gcc-2.95 is a pentium 3 with -fPIC.
(Happily, gcc-4.3 is an improvement there, but it's still worse than 2.95.)
Oddly, this one does better wit
--- Comment #9 from rask at gcc dot gnu dot org 2007-11-28 18:01 ---
Created an attachment (id=14657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14657&action=view)
Patch v2 to enhance cse.c
This patch also handles unsigned comparisons and thus optimizes the original
testcase to
--- Comment #11 from aldot at gcc dot gnu dot org 2007-11-28 17:44 ---
The standard (6.7.2.2, 4) talks about the note in #7.
I read this as for this input:
8<---
enum e {ee};
struct s { __extension__ enum e baz:16; };
8<---
The smallest type that can represent en
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-28 17:34 ---
So what the BSD people said about this? Did they agree with your assessment?
How many of those 26 likely bugs were considered "real" bugs by them?
It really seems too noisy and with no clear way to avoid or workaround
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-28 17:32 ---
Dave, could you check this with a recent release?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #42 from dsh at gcc dot gnu dot org 2007-11-28 17:19 ---
Created an attachment (id=14656)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14656&action=view)
Benchmarks
I ran the benchmarks for the minimal testcase (using Dan Kegel's script) on a
Core 2 Duo, AMD Dual Core
--- Comment #7 from uweigand at gcc dot gnu dot org 2007-11-28 17:11
---
(In reply to comment #4)
> For reference, our hacky approach to enforce liveness of arguments is by
> using them as operands of an inline asm, which we insert as first instruction
> in every function. When those a
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 17:11 ---
Try:
pMethod p = &ClassA::templete method; // line 23, error
message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34264
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 17:08 ---
I doubt that this is a gcc bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from raj dot khem at gmail dot com 2007-11-28 16:40 ---
(In reply to comment #9)
> If the requested bitfield is larger than the type that was previously tried
> for
> enum, then you have to widen the type to fulfill that constaint.
>
is there a reference for this in th
1 - 100 of 148 matches
Mail list logo
