On 04/10/2011 23:47, Andrew Pinski wrote:
On Tue, Oct 4, 2011 at 2:40 PM, David Browndavid.br...@hesbynett.no wrote:
naked functions are often useful in embedded systems, and are therefore
useful (and implemented) on many gcc targets. It would make sense to have
the attribute available
On Wed, 05 Oct 2011 10:37:22 +0900
shiot...@rd.ten.fujitsu.com (塩谷晶彦) wrote:
Hi, Maintainer,
I found some incidents in
http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html#ARM-NEON-Intrinsics
Please check the following:
|6.54.3.8 Comparison (less-than-or-equal-to)
|
|
David Brown da...@westcontrol.com writes:
Some toolchains are configured to have a series of init sections at
startup (technically, that's a matter of the default linker scripts
and libraries rather than the compiler). You can get code to run at
specific times during startup by placing the
On 05/10/2011 12:00, Andi Kleen wrote:
David Brownda...@westcontrol.com writes:
Some toolchains are configured to have a series of init sections at
startup (technically, that's a matter of the default linker scripts
and libraries rather than the compiler). You can get code to run at
specific
On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
If, as the document proposes, 16 byte volatile will have to call the
external rotines, but 16 byte non-volatiles would be lock-free., and
the external routines use locked accesses for 16-byte volatile
atomics, then this makes the concurrent
On Wed, Oct 5, 2011 at 5:49 AM, Andrew MacLeod amacl...@redhat.com wrote:
On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
I see two ways out:
1) Say that accessing a non-volatile atomic through a volatile
reference or pointer causes undefined behavior. The standard doesn't
say that, and the
On 10/05/2011 10:44 AM, Jeffrey Yasskin wrote:
Yes, that's what I'm suggesting. The rule for 'volatile' from the
language is just that Accesses to volatile objects are evaluated
strictly according to the rules of the abstract machine. If the
instruction-level implementation for a 16-byte atomic
These patterns:
(define_insn avx2_lshlqv4di3
[(set (match_operand:V4DI 0 register_operand =x)
(ashift:V4DI (match_operand:V4DI 1 register_operand x)
(match_operand:SI 2 const_0_to_255_mul_8_operand
n)))]
TARGET_AVX2
{
operands[2] = GEN_INT (INTVAL
On Wed, Oct 5, 2011 at 8:57 PM, Richard Henderson r...@redhat.com wrote:
These patterns:
(define_insn avx2_lshlqv4di3
[(set (match_operand:V4DI 0 register_operand =x)
(ashift:V4DI (match_operand:V4DI 1 register_operand x)
(match_operand:SI 2
Hi,
I've been experimenting with different methods for emulating the
signed overflow of an 8-bit CPU. The method I've found that seems to
generate the most efficient code on both ARM and x86 is
bool overflow(unsigned int a, unsigned int b) {
const unsigned int sum = (int8_t)a + (int8_t)b;
On Wed, Oct 5, 2011 at 10:11 PM, Ulf Magnusson ulfali...@gmail.com wrote:
Hi,
I've been experimenting with different methods for emulating the
signed overflow of an 8-bit CPU. The method I've found that seems to
generate the most efficient code on both ARM and x86 is
bool overflow(unsigned
On 10/4/2011 12:08 AM, Iain Buclaw wrote:
I've have received news from Walter Bright that the license of the D
frontend has been assigned to the FSF. As the current maintainer of
GDC, I would like to get this moved forward, starting with getting the
ball rolling. What would need to be done?
Em 05-10-2011 17:11, Ulf Magnusson escreveu:
Hi,
I've been experimenting with different methods for emulating the
signed overflow of an 8-bit CPU.
You would like to check whether a 8-bit signed addition will overflow or
not, given the two operands. Is that correct?
As you used the word
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50613
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50613
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #38 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com 2011-10-05 06:40:45 UTC ---
Dear Mikael,
Very good - I'll give it urgent attention as soon as it appears.
Cheers
Paul
On Tue, Oct 4, 2011 at 11:56
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
07:10:56 UTC ---
Until http://gcc.gnu.org/viewcvs?root=gccview=revrev=176563
float a[1024], b[1024], c[1024], d[1024];
int j[1024];
void
foo (void)
{
int i;
for (i = 0; i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
08:09:24 UTC ---
BTW, the extra problematic casts aren't coming from the frontend, it is the
gimplifier that is inserting them:
/* Insert pointer conversions required by the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48035
Ozkan Sezer sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
09:04:59 UTC ---
Created attachment 25419
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25419
patch
An incomplete patch to avoid those casts from the IL.
We'd need to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50609
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-05
09:31:44 UTC ---
Author: rguenth
Date: Wed Oct 5 09:31:40 2011
New Revision: 179540
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179540
Log:
2011-10-05 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50609
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #9 from rguenther at suse dot de rguenther at suse dot de
2011-10-05 09:40:58 UTC ---
On Wed, 5 Oct 2011, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #8 from Jakub Jelinek jakub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50614
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50617
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50615
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
--- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2011-10-05 10:21:33
UTC ---
(In reply to comment #4)
Still there on trunk at revision 179525 (I see it with 4.4.6, 4.5.3, and
4.6.1). Note that for the test in comment #3, the line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38980
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582
--- Comment #3 from Paulo J. Matos Paulo.Matos at csr dot com 2011-10-05
10:53:06 UTC ---
Created attachment 25420
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25420
Allows reload to remove trivial insn
I noticed that reload was failing to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
--- Comment #3 from Paulo J. Matos Paulo.Matos at csr dot com 2011-10-05
11:08:36 UTC ---
(In reply to comment #2)
Is this bug still reproducible for you ?
I tried building an rx-elf toolchain from the current 4.6 branch sources and
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50614
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50614
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
12:10:15 UTC ---
-fdump-final-insns calls dump_enumerated_decls and that ICEs on the C++
specific trees (ARROW_EXPR etc.) left over in DECL_INITIAL of the FIELD_DECL by
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50620
Bug #: 50620
Summary: undefined reference errors / csmith lto testing
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38884
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #13 from jules at gcc dot gnu.org 2011-10-05 13:05:47 UTC ---
Coming to think of it, if _Sat were allowed on plain integers too, a _Flagged
_Sat int could also be queried for saturation using a similar mechanism, like:
int foo (_Sat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #39 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-05
14:10:30 UTC ---
Regarding the (In reply to comment #37)
Sorry, you should have asked for the latest patch.
I'll post a more up-to-date than the more up-to-date soon.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
Bug #: 50621
Summary: [4.7 Regression] Bootstrap failure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
--- Comment #6 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com 2011-10-05 14:35:14 UTC ---
Dear Tobias and Dominique,
We could fix this in 4.7 by adding a sm field to array descriptors.
If we added the sm field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38885
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-05
14:35:22 UTC ---
Author: rguenth
Date: Wed Oct 5 14:35:15 2011
New Revision: 179556
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179556
Log:
2011-10-05 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #1 from Yukhin Kirill kirill.yukhin at intel dot com 2011-10-05
14:36:19 UTC ---
Revision 179538 is ok.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-05
14:38:40 UTC ---
After talking about this for some time another idea came up. Basically, assign
the restrict tags for parameters at gimplification time by gimplifying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45095
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38885
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||bernds at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
--- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-05
15:04:02 UTC ---
(In reply to comment #6)
We could fix this in 4.7 by adding a sm field to array descriptors.
If we added the sm field after the dimension array, we would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-05
15:05:36 UTC ---
(In reply to comment #2)
Confirmed.
A stage1 cc1 ICEs the same way on gcc.c-torture/execute/2205-1.c with -O1
Passes with -fno-shrink-wrap. Is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-05
15:18:00 UTC ---
Passes with -fno-shrink-wrap. Is that on by default(?)
+{ OPT_LEVELS_1_PLUS, OPT_fshrink_wrap, NULL, 1 },
Am I correct to understand that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #14 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-05 15:19:01 UTC ---
On Wed, 5 Oct 2011, jules at gcc dot gnu.org wrote:
I don't much like the idea of using builtins for operations as fundamental as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #6 from Yukhin Kirill kirill.yukhin at intel dot com 2011-10-05
15:43:54 UTC ---
This was caused by
gcc.gnu.org/svn/gcc/trunk@179553
Previous one bootstraps ok:
gcc.gnu.org/svn/gcc/trunk@179549
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622
Bug #: 50622
Summary: ICE: verify_gimple failed for std::complexdouble
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50623
Bug #: 50623
Summary: Template metaprogramming involving 4
std::complexdouble fails without -std=gnu++0x
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
15:48:57 UTC ---
Created attachment 25423
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25423
CAST_RESTRICT removal
Attaching a test patch that just removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
15:52:49 UTC ---
(In reply to comment #10)
with tag coming from allocate_decl_uid (). We would use these copies
as restrict tag sources using the specified UID. Thus every
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50623
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50623
--- Comment #2 from Giulio Eulisse giulio.eulisse at cern dot ch 2011-10-05
15:57:31 UTC ---
Yes, just a misunderstanding with vincenzo on who posts the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #7 from Bernd Schmidt bernds at gcc dot gnu.org 2011-10-05
17:17:17 UTC ---
Author: bernds
Date: Wed Oct 5 17:17:12 2011
New Revision: 179560
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179560
Log:
PR bootstrap/50621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
Bernd Schmidt bernds at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50613
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
18:10:03 UTC ---
Author: jakub
Date: Wed Oct 5 18:09:56 2011
New Revision: 179567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179567
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #40 from Mikael Morin mikael at gcc dot gnu.org 2011-10-05
18:10:08 UTC ---
(In reply to comment #39)
Regarding the (In reply to comment #37)
Sorry, you should have asked for the latest patch.
I'll post a more up-to-date than the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50613
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624
Bug #: 50624
Summary: detecting array overflows regressed
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-05
18:56:24 UTC ---
Thanks.
It's not a pure regression. Even 4.5 misses some easy cases:
especially the local stack array case, which should be in theory really easy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50624
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-05
19:22:38 UTC ---
If I remember well this warning isn't very well designed and has many false
positives on the other side.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625
Bug #: 50625
Summary: [4.6/4.7 Regression][OOP] ALLOCATABLE attribute lost
for module CLASS variables
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
--- Comment #15 from janus at gcc dot gnu.org 2011-10-05 20:06:33 UTC ---
(In reply to comment #14)
Related ToDos:
1) check shape of dummy function results (in 'gfc_compare_interfaces')
2) check shape of function results when overriding TBPs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-05
21:39:31 UTC ---
We could fix this in 4.7 by adding a sm field to array descriptors.
I don't see why. I have looked at the dump.original of the following code:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50625
--- Comment #2 from janus at gcc dot gnu.org 2011-10-05 21:42:33 UTC ---
Here's an attempt to fix it:
Index: module.c
===
--- module.c(revision 179566)
+++ module.c(working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |pault at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48698
--- Comment #4 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-10-05
23:10:01 UTC ---
Author: bkoz
Date: Wed Oct 5 23:09:51 2011
New Revision: 179580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179580
Log:
2011-10-05 Benjamin Kosnik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48698
Benjamin Kosnik bkoz at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |bkoz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48698
Benjamin Kosnik bkoz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279
--- Comment #6 from Peter Foley jpfoley2 at verizon dot net 2011-10-06
00:09:03 UTC ---
Created attachment 25426
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25426
reduced testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279
--- Comment #7 from Peter Foley jpfoley2 at verizon dot net 2011-10-06
00:11:08 UTC ---
I've attached a reduced testcase that reproduces the ICE with the commandline
g++ -nostdlib -flto -g test.i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44022
john.harper at vuw dot ac.nz changed:
What|Removed |Added
CC||john.harper at vuw dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50626
Bug #: 50626
Summary: ICE with non-variadic function arguments after
variadic one
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50607
--- Comment #7 from Artem Shinkarov artyom.shinkaroff at gmail dot com
2011-10-06 02:07:38 UTC ---
bconstp-3.c failure is fixed with the commit 179588.
2011-10-06 Artjoms Sinkarovs artyom.shinkar...@gmail.com
* c-tree.h (c_expr_t): New
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50626
--- Comment #1 from Gyusik Choe kyusic at gmail dot com 2011-10-06 02:09:22
UTC ---
Created attachment 25427
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25427
preporcessed file
Hello!
2011-10-05 Uros Bizjak ubiz...@gmail.com
* gcc.dg/torture/builtin-complex-1.c: Use dg-add-options ieee.
Tested on alphaev68-pc-linux-gnu, committed to mainline.
Uros.
Index: gcc.dg/torture/builtin-complex-1.c
===
This patch was earlier submitted to google/main, but I propose itfor
the trunk as well.
This patch adds an intermediate coverage format (enabled via
'gcov-i'). This is a compact format as it does not require source
files.
The new option ('gcov -i') outputs .gcov files in an intermediate
textformat
This fixes many C++ tests on s390x and PPC64:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01220.html
Sorry about the garbled message. My mistake with the mailer. Here
is what I really intended to send.
This patch was earlier submitted to google/main, but I propose itfor
trunk as well.
This patch adds an intermediate coverage format (enabled via
'gcov-i'). This is a compact format as it does
Sorry about the badly formatted mail. Here is another version with a
different mailer. -Sharad
This patch was earlier submitted to google/main, but I propose it
for the trunk as well.
This patch adds an intermediate coverage format (enabled via 'gcov
-i'). This is a compact format as it
Hello!
No functional change.
2011-10-05 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.c (ix86_emit_binop): New static function.
(ix86_split_lea_for_addr): Use ix86_emit_binop to emit add and shl
instructions.
(x86_output_mi_thunk): Use ix86_emit_binop to
On Tue, Oct 4, 2011 at 9:02 PM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
On 5/10/2011, at 1:49 AM, Richard Guenther wrote:
On Tue, Oct 4, 2011 at 9:17 AM, Maxim Kuvyrkov ma...@codesourcery.com
wrote:
Richard,
The following patch fixes a CFG consistency problem.
When early IPA
Hi,
the optab_handler uses in expand_mult_highpart_optab haven't been
replaced with the widening_optab_handler yet.
Fixed with attached patch.
Tested on s390x and x86_64.
Bye,
-Andreas-
2011-10-05 Andreas Krebbel andreas.kreb...@de.ibm.com
* expmed.c (expand_mult_highpart_optab):
On Wed, Oct 5, 2011 at 12:18 AM, Artem Shinkarov
artyom.shinkar...@gmail.com wrote:
Hi
Here is a patch to inform a programmer about the expanded vector operation.
Bootstrapped on x86-unknown-linux-gnu.
ChangeLog:
* gcc/tree-vect-generic.c (expand_vector_piecewise): Adjust to
Jan Hubicka hubi...@ucw.cz writes:
Hi,
GNU LD has bug about reporting references to hidden symbol sthat has been
optimized out.
This however made me notice that we do output into LTO symbol tables things
that do
not belong there. In partiuclar we often output extern inline
On Wed 05 Oct 2011 09:33:09 BST, Andreas Krebbel wrote:
Hi,
the optab_handler uses in expand_mult_highpart_optab haven't been
replaced with the widening_optab_handler yet.
Apologies, I don't know how I missed that one? :(
Andrew
On Tue, Oct 4, 2011 at 10:58 PM, Richard Henderson r...@redhat.com wrote:
On 10/04/2011 01:17 PM, Tom de Vries wrote:
In general, to fold vlas (which are lowered to allocas) to normal
declarations,
if the alloca argument is constant.
Ah. Ok, I suppose. How often are you seeing this
On Tue, Oct 4, 2011 at 6:28 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 10/04/2011 03:03 PM, Richard Guenther wrote:
On Tue, Oct 4, 2011 at 9:43 AM, Tom de Vries tom_devr...@mentor.com wrote:
On 10/01/2011 05:46 PM, Tom de Vries wrote:
On 09/30/2011 03:29 PM, Richard Guenther wrote:
On
we have, like specifying the set of symbols _defined_ by a toplevel
asm, right? I might misremember but sth like
extern void foo (void);
asm( foo);
was supposed to do the trick. Or should we treat those as outputs
(given you use inputs for symbol uses)?
I don't recall any discussion
1 - 100 of 181 matches
Mail list logo
