Thank you for the feedback. I did found the issue in mode_dependent_address_p
hook.
//Claudiu
-Original Message-
From: Eric Botcazou [mailto:ebotca...@adacore.com]
Sent: Monday, March 31, 2014 10:21 PM
To: Claudiu Zissulescu
Cc: gcc@gcc.gnu.org; Francois Bedard; claz...@gmail.com
Dear All ,
Was enabled the switch -fleading-underscore to emit the global
symbol name with prefix _ .
The respective C source file
int a=10;
int b=10,c;
int test()
{
c =a+b ;
tes();
return c ;
}
and respective asm file
.global _a
.section.data
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to zero out the upper bits.
So...
unsigned int foo (unsigned char *c)
{
return
On 2 April 2014 13:08, Anthony Green gr...@moxielogic.com wrote:
I though the answer was to simply add something like this...
(define_insn zero_extendqisi
[(set (match_operand:SI 0 register_operand =r)
(zero_extend:SI (match_operand:QI 1 register_operand r)))]
; ZERO EXTEND
On 03/27/2014 10:48 AM, Martin Liška wrote:
Previous patch is wrong, I did a mistake in name ;)
Martin
On 03/27/2014 09:52 AM, Martin Liška wrote:
On 03/25/2014 09:50 PM, Jan Hubicka wrote:
Hello,
I've been compiling Chromium with LTO and I noticed that WPA
stream_out forks and do
Hi
I am sure this is a simple mistake in our linker script but what
magic incantation, symbols, sections, end marker, etc. are
assumed to be properly constructed before this method works?
A pointer to the right magic in the standard sparc-elf linker script
would likely be sufficient for me to
Hi Richard,
As part of implementing the new O32 FPXX ABI I am making use of the
HARD_REGNO_CALL_PART_CLOBBERED macro to allow odd-numbered floating-point
registers to be considered as 'normally' callee-saved but call clobbered if
they
are being used to hold SImode or SFmode data. The macro is
On 04/02/14 06:08, Anthony Green wrote:
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to zero out the upper bits.
I'm a bit
Joern Rennecke joern.renne...@embecosm.com writes:
On 2 April 2014 13:08, Anthony Green gr...@moxielogic.com wrote:
I though the answer was to simply add something like this...
(define_insn zero_extendqisi
[(set (match_operand:SI 0 register_operand =r)
(zero_extend:SI
*PING*
Tobias Burnus wrote:
H.J. Lu wrote:
On Fri, Mar 28, 2014 at 12:41 PM, Mike Stump mikest...@comcast.net
wrote:
Since we are nearing release, I thought I'd mention I see:
../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall
Options' in menu `C Dialect Options' and in
Jeff Law l...@redhat.com writes:
On 04/02/14 06:08, Anthony Green wrote:
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to
On Wed, Apr 2, 2014 at 2:15 AM, Umesh Kalappa umesh.kalap...@gmail.com wrote:
Was enabled the switch -fleading-underscore to emit the global
symbol name with prefix _ .
ld HL, (a)
ld DE, (b)
add DE, HL
ld (c), DE
cal
Hello guys,
I don't know whether this is the best place to ask for this, but
anyway, here we go:
I have two different commandlines for collect2 (I got them after using
-v in gcc) and I found out that the original one does not work because
of the position in the parameter list.
Error:
Hello,
taking latest trunk gcc, I built Firefox and Chromium. Both
projects compiled without debugging symbols and -O2 on an 8-core
machine.
Firefox:
-flto=9, peak memory usage (in LTRANS): 11GB
Chromium:
-flto=6, peak memory usage (in parallel WPA phase ): 16.5GB
I see, the
On Wed, Apr 2, 2014 at 3:26 PM, David Guillen da...@davidgf.net wrote:
Hello guys,
I don't know whether this is the best place to ask for this, but
anyway, here we go:
I have two different commandlines for collect2 (I got them after using
-v in gcc) and I found out that the original one
Previous email presents a bit misleading graphs (influenced by
--enable-gather-detailed-mem-stats).
Firefox:
-flto=9, WPA peak: 8GB, LTRANS peak: 8GB
-flto=4, WPA peak: 5GB, LTRANS peak: 3.5GB
-flto=1, WPA peak: 3.5GB, LTRANS peak: ~1GB
These data shows that parallel WPA streaming
On 2 April 2014 23:26, David Guillen wrote:
Hello guys,
I don't know whether this is the best place to ask for this,
gcc-h...@gcc.gnu.org would have been better :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57887
Jaak Ristioja jaak at ristioja dot ee changed:
What|Removed |Added
CC||jaak at ristioja
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60264
--- Comment #3 from zqchen at gcc dot gnu.org ---
Author: zqchen
Date: Wed Apr 2 06:45:59 2014
New Revision: 209009
URL: http://gcc.gnu.org/viewcvs?rev=209009root=gccview=rev
Log:
gcc/
2014-04-02 Zhenqiang Chen zhenqiang.c...@linaro.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Dominique, what does the generated assembly look like in the (failing) Darwin
case?
Without -fabi-version=0 (or with -fabi-version=1 to 3), I get the pre r203469
manglings:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Dominique d'Humieres from comment #3)
The test gcc.target/i386/avx512f-gather-5.c fails on darwin
FAIL: gcc.target/i386/avx512f-gather-5.c scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60719
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Apr 2 07:52:36 2014
New Revision: 209010
URL: http://gcc.gnu.org/viewcvs?rev=209010root=gccview=rev
Log:
2014-04-02 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Apr 2 08:26:57 2014
New Revision: 209012
URL: http://gcc.gnu.org/viewcvs?rev=209012root=gccview=rev
Log:
2014-04-02 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60729
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Component|c++ |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60719
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #21 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Apr 2 08:34:45 2014
New Revision: 209016
URL: http://gcc.gnu.org/viewcvs?rev=209016root=gccview=rev
Log:
2014-04-02 Dominique d'Humieres domi...@lps.ens.fr
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60738
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||anton at samba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60737
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407
--- Comment #21 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Apr 2 08:44:40 2014
New Revision: 209017
URL: http://gcc.gnu.org/viewcvs?rev=209017root=gccview=rev
Log:
2014-04-02 Dominique d'Humieres domi...@lps.ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083
--- Comment #23 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Apr 2 08:58:03 2014
New Revision: 209018
URL: http://gcc.gnu.org/viewcvs?rev=209018root=gccview=rev
Log:
2014-03-26 Dominique d'Humieres domi...@lps.ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60739
Bug ID: 60739
Summary: Maybe uninitialized with deferred length character
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||wschmidt at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60739
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=57887
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Jaak Ristioja from comment #8)
also probably fixed by 204818.
It was definitely fixed by r204818.
I don't know what commit fixed the 4.7 ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Thanks Marek, in that case this is less high priority IMHO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
I think the main observation is that
use 1
address
in statement _15 = *_14;
at position *_14
type int *
base perm_9(D) + (sizetype) ((long unsigned int) (k_4(D) + -1) *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740
Bug ID: 60740
Summary: ICE in extract_affine w/ -O2 -ftree-loop-linear
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60740
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Sth like
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 209018)
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
Sth like
Index: gcc/c-family/c-common.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733
--- Comment #4 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Ok, will have a look today.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741
Bug ID: 60741
Summary: [-Wmaybe-uninitialized] false negative and confusing
warning message
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361
Andrew Sutton andrew.n.sutton at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
--- Comment #5 from Ian Lance Taylor ian at airs dot com ---
This is easy enough to recreate--do you really need valgrind output?
In any case, here it is.
cat foo.c
#include stdc-predef.h
valgrind gcc/cc1 foo.c
==25367== Memcheck, a memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640
--- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 32523
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32523action=edit
Proposed patch for the 4.8 branch
Independent of the trunk fix, I'm going to propose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640
--- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 32524
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32524action=edit
Proposed patch for the 4.7 branch
Independent of the trunk fix, I'm going to propose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Thanks. I get:
==15253==
==15253== Invalid read of size 1
==15253==at 0xD2BEB7: cpp_errno(cpp_reader*, int, char const*)
(errors.c:233)
==15253==by 0xD30DD2:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
diff --git a/libcpp/errors.c b/libcpp/errors.c
index d1ca7a12ff42..fa292214d677 100644
--- a/libcpp/errors.c
+++ b/libcpp/errors.c
@@ -230,7 +230,7 @@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #206 from Martin Liška mliska at suse dot cz ---
Firefox (and chromium) memory reports with -flto=9 and -O2; archive contains
also memory usage graph:
https://docs.google.com/file/d/0B0pisUJ80pO1bnV5V0RtWXJkaVU/edit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #207 from Martin Liška mliska at suse dot cz ---
Created attachment 32525
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32525action=edit
Memory usage graphs for -flto=9, -flto=4, -flto=1 with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449
--- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org ---
OTOH, why do we have to merge the decls/cgraph nodes at all? Can't we simply
make them aliases if tree merging decides the decls are not equal?
If we do so, we would never merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.7.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651
--- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org ---
Created attachment 32526
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32526action=edit
preprocessed libjava file
With the latest proposed patch, we get an assertion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60691
--- Comment #4 from Fabian Vogt fab...@ritter-vogt.de ---
(In reply to Andrew Pinski from comment #3)
(In reply to Fabian Vogt from comment #2)
It crashes and produces weird results if linked to bFLT.
Yes because EABI is an elf only abi, if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735
--- Comment #2 from Michael Meissner meissner at gcc dot gnu.org ---
Author: meissner
Date: Wed Apr 2 17:03:49 2014
New Revision: 209025
URL: http://gcc.gnu.org/viewcvs?rev=209025root=gccview=rev
Log:
2014-04-02 Michael Meissner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735
Michael Meissner meissner at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735
--- Comment #4 from Michael Meissner meissner at gcc dot gnu.org ---
Author: meissner
Date: Wed Apr 2 17:16:33 2014
New Revision: 209026
URL: http://gcc.gnu.org/viewcvs?rev=209026root=gccview=rev
Log:
2014-04-02 Michael Meissner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
--- Comment #8 from Ian Lance Taylor ian at airs dot com ---
I don't think that's the right patch, unless there is a good reason for msgid
to be NULL. Note that two lines down we are printing msgid, so that would need
to be fixed as well. But it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #4 from Brooks Moses brooks at gcc dot gnu.org ---
Interesting. As noted, with -fabi-version=[1 to 3] on Linux, I was getting
both sets.
Mike, what do you think is the best solution here? We could use Dominique's
patch with a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657
--- Comment #7 from Jeffrey A. Law law at redhat dot com ---
Actually, it occurs to me, why don't we fix the predicates. That seems like a
better solution than rejecting problematical constants in the insn's condition.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
--- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Ian Lance Taylor from comment #8)
I don't think that's the right patch, unless there is a good reason for
msgid to be NULL. Note that two lines down we are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733
--- Comment #5 from Bill Schmidt wschmidt at gcc dot gnu.org ---
The logic for placement of initializers for PHI candidates is a bit wrong.
They should be placed at the end of the feeding block for the PHI. Currently
they can end up being placed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60742
Bug ID: 60742
Summary: ill-formed declarator (array) in selection statement
not caught appropriately
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650
--- Comment #12 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Wed Apr 2 20:55:02 2014
New Revision: 209038
URL: http://gcc.gnu.org/viewcvs?rev=209038root=gccview=rev
Log:
2014-04-02 Vladimir Makarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733
--- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Author: wschmidt
Date: Wed Apr 2 22:07:30 2014
New Revision: 209040
URL: http://gcc.gnu.org/viewcvs?rev=209040root=gccview=rev
Log:
[gcc]
2014-04-02 Bill Schmidt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733
Bill Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60733
--- Comment #8 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Bill Schmidt from comment #7)
Fixed. Bug was introduced in 4.9 so no backports are needed.
That's very quick; thanks Bill!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60743
Bug ID: 60743
Summary: build/genautomata uses 700 MB memory for ARM
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702
arturomdn at gmail dot com changed:
What|Removed |Added
CC||arturomdn at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59967
--- Comment #2 from Jan Hubicka hubicka at ucw dot cz ---
193246hubicka /* If there is call on a hot path through the loop,
then
193246hubickathere is most probably not much to optimize. */
193246hubicka else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60706
--- Comment #3 from dave.anglin at bell dot net ---
On 31-Mar-14, at 4:53 AM, rguenth at gcc dot gnu.org wrote:
Like this. If that works for you it's pre-approved. Only
implements the
special-case (the gmp path would probably have a lot of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
Patch is spinning which introduced new predicates which only allow suitable
constants.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org ---
Author: hubicka
Date: Thu Apr 3 03:55:59 2014
New Revision: 209048
URL: http://gcc.gnu.org/viewcvs?rev=209048root=gccview=rev
Log:
PR ipa/60659
* ipa-devirt.c
On Wed, 2 Apr 2014, Thomas Preud'homme wrote:
Note that as it stands the patch does not work for arrays indexed with
variable (such a tab[a] || (tab[a+1] 8)) because fold_const does not
fold (a + 1) - a.
Uh? It does fold a+1-a for me. What it doesn't do is look through the
definition of b
On Wed, Apr 2, 2014 at 12:27 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
When I fixed various tests in
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01662.html for failures
with --with-arch=bdver3, I missed that a so-configured compiler still
defaults to -mtune=generic. If you override
From: Marc Glisse [mailto:marc.gli...@inria.fr]
Uh? It does fold a+1-a for me. What it doesn't do is look through the
definition of b in b-a. Richard+GSoC will supposedly soon provide a
function that does that.
Oh right, it's a bit more complex here since the array index is converted
to an
Hi DJ,
The patch below is to fix a snafu I made whilst fixing some problems
with the RL78 port a while ago. GCC was generating
(SUBREG (SYMBOL_REF) n) which made no sense to me, so I had the
movqi expander just fail when it encountered them. Now that I have
more idea about why they
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up offload target code based on the address of the
On Tue, 1 Apr 2014, Mike Stump wrote:
On Mar 31, 2014, at 4:50 AM, Richard Biener rguent...@suse.de wrote:
-$(INSTALL_PROGRAM) xgcc$(exeext)
$(DESTDIR)$(bindir)/$(GCC_INSTALL_NAME)$(exeext)
! -rm -f
$(DESTDIR)$(bindir)/$(target_noncanonical)-gcc-$(version)$(exeext)
! -( cd
On Wed, Apr 2, 2014 at 12:27 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
There are other failures this patch does not resolve in a
--with-arch=bdver3 --with-cpu=bdver3 configuration. Some of these are
AVX tests whose failures are not resolved by adding -mno-prefer-avx128
(and so this
On Wed, 19 Mar 2014, Bill Schmidt wrote:
Hi,
This patch (diff-abi-calls) backports fixes to common code to support
the new ELFv2 ABI. Copying Richard and Jakub for these bits.
Ok.
Thanks,
Richard.
Thanks,
Bill
2014-03-29 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport
On Wed, 19 Mar 2014, Bill Schmidt wrote:
Hi,
This patch (diff-pr54537) backports a fix for PR54537 which is unrelated
but necessary. Copying Richard and Jakub for the common code.
Ok.
Thanks,
Richard.
Thanks,
Bill
[libstdc++-v3]
2014-03-29 Bill Schmidt
On Wed, Apr 2, 2014 at 2:54 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
I took the lack of answer for this patch as an indication that the patch is
too
big. This is the first patch in a series of three. Its purpose is to create
some new
effective target for architecture having
On Wed, Apr 2, 2014 at 9:04 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
From: Marc Glisse [mailto:marc.gli...@inria.fr]
Uh? It does fold a+1-a for me. What it doesn't do is look through the
definition of b in b-a. Richard+GSoC will supposedly soon provide a
function that does
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sorry, I simply queued it in my review queue for stage1 ... it's definitely
something that was high on my wish-list (including of also using
general vector shuffles if available to support even more patterns).
Oh great. Anyway, having
Hi!
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up offload target code based on the address of the
Hi!
On Wed, 02 Apr 2014 09:34:29 +0200, I wrote:
On Thu, 20 Mar 2014 17:50:13 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
This is based on Michael Zolotukhin's patch 2/3 from a while ago. It
adds functionality to build function/variable tables that will allow
libgomp to look up
On Tue, 1 Apr 2014, Jan Hubicka wrote:
This reworks the option to use the Enum support we have now and
adds a =one case (to eventually get rid of one LTO operation mode,
=none ...). I was tempted to support -flto-partition=number
and get rid of --param lto-partitions (thereby also
1 - 100 of 152 matches
Mail list logo
