Jerry DeLisle wrote:
Regression tested on x86-64. Test case attached with patch.
OK for trunk?
Looks good to me. Thanks for the patch.
Tobias
2014-05-24 Tobias Burnus bur...@net-b.de
PR fortran/55117
* trans-io.c (nml_full_name, transfer_namelist_element): Insert
2013-11-19 Rong Xu x...@google.com
* gcc/gcov-io.h: Add atomic function macros for compiler use.
* gcc/common.opt (fprofile-generate-atomic): New option.
* gcc/tree-profile.c (gimple_init_edge_profiler): Support for
atomic counter update.
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, May 26, 2014 at 08:57:11AM +0400, Konstantin Serebryany wrote:
Last time I tried, asan did not work on ppc32 for a large number of
different reasons.
???
Comparing my 4.9.0 ppc/ppc64 testresults, for 32-bit I see:
On 23 May 2014 19:56, Richard Biener richard.guent...@gmail.com wrote:
On Fri, May 23, 2014 at 12:33 PM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
On 23 May 2014 17:05, Richard Biener richard.guent...@gmail.com wrote:
On Fri, May 23, 2014 at 9:23 AM, Zhenqiang Chen
On Fri, May 23, 2014 at 8:45 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, May 23, 2014 at 04:11:48PM +0400, Konstantin Serebryany wrote:
2) it doesn't still deal with unaligned power of two accesses properly,
but neither does llvm (at least not 3.4). Am not talking about
Hi,
A years ago there was a discussion (
https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about
debugging compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch
wasn't applied to trunk.
Is this still
Ping^2 ?
Thanks,
Kugan
On 12/05/14 09:47, Kugan wrote:
Ping ?
Thanks,
Kugan
On 02/05/14 19:04, Kugan wrote:
On 02/05/14 10:15, Joseph S. Myers wrote:
It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
names for the target's FE_* values; you'd run into problems
Hello!
2014-05-26 Michael Tautschnig m...@debian.org
PR target/61249
* doc/extend.texi: Fix parameter lists of __builtin_ia32_vfrczs[sd],
__builtin_ia32_mpsadbw256.
Thanks, I have committed the patch with slightly changed ChangeLog to
all branches.
Uros.
.././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
cast in a inline asm context requiring an l-value: remove the cast or
build with -fheinous-gnu-extensions
umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ());
On Mon, May 26, 2014 at 11:29:28AM +0400, Konstantin Serebryany wrote:
Note, I think some work is needed on the library side,
ERROR: AddressSanitizer: unknown-crash on address 0xffc439cf at pc
0x804898e bp 0xffc438d8 sp 0xffc438cc
With clang I get this nice report:
==20989==ERROR:
r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10.
../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this
scope
libgfortran/configure defines HAVE_STRNLEN on targets supporting it.
The same revision also breaks the test g++.dg/tls/diag-1.C
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres domi...@lps.ens.fr wrote:
r210901 breaks bootstrap on targets not supporting strnlen, e.g., darwin10.
../../_clean/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in
this scope
strnlen should be declared in include/libiberty.h
Agree.
I was going to change instrumentation of unaligned and unusual-sized
accesses to simple callbacks.
004b1f30 _Z3fooP1S:
4b1f30: 53 push %rbx
4b1f31: 48 89 fbmov%rdi,%rbx
4b1f34: be 04 00 00 00 mov
This causes GCC bootstrap to fail on Darwin systems (whose system compiler is
clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s
the right call, see below), I’ve filed a separate report for the bootstrap
issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315).
On Sat, May 24, 2014 at 6:44 AM, Xinliang David Li davi...@google.com wrote:
graph dump is broken in trunk (and gcc-49) -- the subgraph of the last
function gets dumped. The patch fixed the problem. Also fixed the
function header dump -- the cgraph uid is still used in many places
such as
On Mon, May 26, 2014 at 2:22 AM, FX fxcoud...@gmail.com wrote:
This causes GCC bootstrap to fail on Darwin systems (whose system compiler
is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
it’s the right call, see below), I’ve filed a separate report for the
bootstrap
On my side, I can see that r210901 breaks AArch64 compiler build:
gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_elf_asm_named_section(const char*, unsigned int, tree_node*)’:
gcc/config/aarch64/aarch64.c:8136: error: ‘decl_comdat_group’ was not
declared in this scope
Christophe.
On
On Mon, May 26, 2014 at 10:14 AM, FX fxcoud...@gmail.com wrote:
.././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
cast in a inline asm context requiring an l-value: remove the cast or
build with -fheinous-gnu-extensions
umul_ppmm (val[1], val[0], op1.ulow
On 05/26/2014 01:19 PM, Konstantin Serebryany wrote:
This is implemented in llvm, just need a flag flip. It also needs a
performance improvement in the run-time.
This is in my TODO, just didn't have time.
FYI I have a patch that adds -asan-instrumentation-with-call-threshold
for GCC (will
On Mon, May 26, 2014 at 1:25 AM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Mon, May 26, 2014 at 12:21:21AM +0300, Janne Blomqvist wrote:
Hi,
GFortran currently uses strftime(...,%c,...) to produce the result
for the CTIME and FDATE intrinsics. Unfortunately, it seems that on
On Fri, May 23, 2014 at 5:23 AM, Hans-Peter Nilsson h...@bitrange.com wrote:
I'm not defending the existing solution, I was observing your
patch breaking it. The obvious fix is adjustments by means of
this existing machinery; done. I suggest breakages be fixed
without shooting messengers or
On Mon, May 26, 2014 at 1:14 AM, FX fxcoud...@gmail.com wrote:
.././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a
cast in a inline asm context requiring an l-value: remove the cast or
build with -fheinous-gnu-extensions
umul_ppmm (val[1], val[0], op1.ulow
Hi,
the motivation of this work is to get rid of the range check on Z in:
function F (X : Integer; Y : Integer ) return Positive is
Z : Integer;
begin
if X = Y then
return 1;
end if;
Z := Y - X;
return Z;
end;
An equivalent C testcase is:
extern void abort (void);
int foo
Please post a patch.
How about that? I’m not doing a full clean-up of the longlong.h code outside
the area affected. This restores bootstrap on darwin, confirming that both the
system compiler and later-stage-gcc accepts it.
FX
longlong.diff
Description: Binary data
longlong.ChangeLog
On 23 May 2014 17:01, Evgeniy Stepanov eugeni.stepa...@gmail.com wrote:
Hi Christophe,
is there anything special about your setup? We've seen it build on
arm/linux and arm/android correctly.
Hi,
As Kugan said, I needed to add --enable-obsolete-rpc when configuring glibc.
Thanks,
On Mon, May 26, 2014 at 12:32:15PM +0200, FX wrote:
Please post a patch.
How about that? I’m not doing a full clean-up of the longlong.h code
outside the area affected. This restores bootstrap on darwin, confirming
that both the system compiler and later-stage-gcc accepts it.
grep
This is the last cleanup bit. Remaining is getting rid of
HOST_WIDE_INT in favor of [u]int64_t and adjusting interfaces
and interface names. That's too disruptive at the moment
(thus appropriate for a delay until 4.9.1 is out) and I'm not
sure if we want to split that work or if such splitting
BTW, similar testcase seems to segfault too:
int foo (int*p, int *i)
{
return __sec_reduce_max_ind(p[1:i]);
}
This one should be fixed by r210930
Thanks,
Igor
Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it
impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The
proposed patch disables building libsanitizer for powerpc*-*-linux* in addition
to already disabled powerpc*le-*-linux* until the smarter solution will
On 23 May 2014 05:36, Thomas Preud'homme thomas.preudho...@arm.com wrote:
From: Richard Biener [mailto:richard.guent...@gmail.com]
On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Updated ChangeLogs:
*** gcc/ChangeLog ***
2014-05-20 Thomas
From: Christophe Lyon [mailto:christophe.l...@linaro.org]
I have noticed that the new bswap-2.c test fails at execution on armeb
targets.
See:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/210843/report-
build-info.html
Could you have a look?
Sure.
I suspect it's the
So changing just 2 of them doesn't feel right to me…
Here’s a patch that removes all the casts on output operands in x86/x86_64 code
in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1
(system compiler) and stages 2-3 (gcc). OK to commit?
Other archs which have
So changing just 2 of them doesn't feel right to me…
[Again, with the patch actually attached… sorry]
Here’s a patch that removes all the casts on output operands in x86/x86_64 code
in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1
(system compiler) and stages
On Mon, May 26, 2014 at 2:53 PM, Arseny Solokha asolo...@gmx.com wrote:
Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it
impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The
proposed patch disables building libsanitizer for powerpc*-*-linux* in
This is Ping #1 for
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00747.html
an addendum that adds runtime library exception to two more files
in the ARM backend (arm-opts.h, arm-cores.def) that are included in libgcc.
Ok to apply?
Johann
Am 05/10/2014 02:51 AM, schrieb Ian Lance Taylor:
On Mon, May 26, 2014 at 01:00:56PM +0300, Janne Blomqvist wrote:
On Mon, May 26, 2014 at 1:25 AM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Mon, May 26, 2014 at 12:21:21AM +0300, Janne Blomqvist wrote:
Hi,
GFortran currently uses strftime(...,%c,...) to produce the result
Hello,
This is a follow up on a thread started long ago there:
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00967.html
With a first followup and a patch proposal there:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00731.html
Then a refinement suggested by Richard Sandiford here:
On Mon, May 26, 2014 at 12:22 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
the motivation of this work is to get rid of the range check on Z in:
function F (X : Integer; Y : Integer ) return Positive is
Z : Integer;
begin
if X = Y then
return 1;
end if;
Z := Y -
Jan Hubicka hubi...@ucw.cz writes:
I'm fine with enlarging tree_function_decl for now - ideally we'd push
stuff from it elsewhere (like target and optimization option tree nodes,
or most of the visibility and symbol related stuff). Not sure why
tree_type_decl inherits from
The following patch fixes completes the primitive int_traints
with long and long long variants and drops the HWI case. This
fixes darwin builds where HOST_WIDE_INT is 'long' but
int64_t is 'long long'.
Bootstrapped on x86_64-unknown-linux-gnu (and on darwin by Ian),
soon to be committed.
Hello,
Some of std::vector misuses are very hard to find with internal STL checks
or using external tools (such as Valgrind or AddressSanitizer [1]).
Example:
std::vectorint v(4);
v.reserve(8);
int *p = v.data();
p[6] = 0; // BOOM
We call these bugs container overflow [2,6] and we've
This patch introduces $subject, so if the warning says passing
argument N of X, the caret points to actual argument and not
to function decl. So e.g.:
pr56724-2.c:23:17: warning: passing argument 3 of ‘foo_sc’ from incompatible
pointer type
foo_sc (1, 2, f);
^
On 26/05/14 17:40 +0400, Konstantin Serebryany wrote:
Would you consider a patch similar to [4] for libstdc++ trunk?
If yes, any comments on the patch?
+ // When sanitizer annotataions are off, avoid bazillion of no-op
I'd rather see the member functions use
Hi,
according to the analysis, we should not reject these initializations.
Thus I added some code following closely 8.5/17. I also enlarged the
testcase a bit to make sure that, for example, we still reject too long
initializer-strings (a preliminary draft didn't call digest_init)
Tested
On 26/05/14 15:12 +0100, Jonathan Wakely wrote:
It does look useful but I'm concerned about a proliferation of
container checks, we already have the libstdc++ Debug Mode, and I'd
like to see some of the lightweight checks from the Google branch
added to trunk too.
I see that the patch on the
On May 26, 2014, at 6:39 AM, Richard Biener rguent...@suse.de wrote:
The following patch fixes completes the primitive int_traints
with long and long long variants and drops the HWI case.
Bootstrapped on x86_64-unknown-linux-gnu (and on darwin by Ian),
soon to be committed.
Looks good,
On 04/28/2014 10:08 AM, Christian Bruel wrote:
Hello,
I'd like to ping the following patches
[Hookize mode-switching]
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01003.html
[Add new hooks to support toggle and SH4A fpchg instruction]
On May 26, 2014, at 2:22 AM, FX fxcoud...@gmail.com wrote:
This causes GCC bootstrap to fail on Darwin systems (whose system compiler
is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
it’s the right call, see below), I’ve filed a separate report for the
bootstrap
The following patch adjust the regexp in gfortran.dg/bind_c_array_params_2.f90.
Tested on powerpc-apple-darwin9* and x86_64-apple-darwin*, and by
Andreas Schwab on unspecified targets (see
https://gcc.gnu.org/ml/fortran/2014-05/msg00137.html).
OK for trunk?
Dominique
2014-05-26 Dominique
On 05/25/2014 07:54 AM, Jan Hubicka wrote:
Hi,
this patch adds code to rerite references in vtable initializers to local
aliases
when doing so is a win.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-visibility.c (can_replace_by_local_alias_in_vtable): New function.
... the below should be better, handles correctly cv-qualifiers.
Thanks,
Paolo.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 210928)
+++ cp/typeck.c (working copy)
@@ -7502,6 +7502,18 @@
Hi all,
This patch adds support for outline Asan instrumentation (i.e. function
calls instead of inline checks). This has been recently added to LLVM to
* reduce long compiler runtimes on large functions with huge (over 10K)
number of memory accesses
Making implementations more similar
would require bigger rewrite of Asan
of GCC Asan
On Mon, May 26, 2014 at 07:58:17PM +0400, Yury Gribov wrote:
This patch adds support for outline Asan instrumentation (i.e.
function calls instead of inline checks). This has been recently
added to LLVM to
* reduce long compiler runtimes on large functions with huge (over
10K) number of
* asan_negative_params_1.diff - support for negative parameters
I don't like this. Why do you need it?
That's only for compatibility with LLVM. I know that's not usually
considered an argument in gcc-patches but things like this would surely
make developer's life harder.
*
On my side, I can see that r210901 breaks AArch64 compiler build:
gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_elf_asm_named_section(const char*, unsigned int, tree_node*)’:
gcc/config/aarch64/aarch64.c:8136: error: ‘decl_comdat_group’ was not
declared in this scope
This sould be
This adds a note to the user manual that code with label differences is not
supported. This is because adding an offset to a stub address as generated
with gs() will in general not yield the address of the label+offset.
This actually occurs only if gs() has something to do, e.g. on devices
On Mon, May 26, 2014 at 08:31:39PM +0400, Yury Gribov wrote:
* asan_negative_params_1.diff - support for negative parameters
I don't like this. Why do you need it?
That's only for compatibility with LLVM. I know that's not usually
considered an argument in gcc-patches but things like this
Hello!
Attached patch fixes several variable ‘Ql’ set but not used warnings
in bid128_div.c and bid64_div.c libbid sources. We can simply use
__mul_128x128_high functions when lowpart is not needed.
2014-05-26 Uros Bizjak ubiz...@gmail.com
* bid128_div.c (BID128_FUNCTION_ARG2): Remove
Hello!
There is a stray ! in ix86_rtx_costs which results in an invalid
bypass for LABEL_REFs. After some simplifications, the fixed condition
should read:
else if (flag_pic SYMBOLIC_CONST (x)
!(TARGET_64BIT
(GET_CODE (x) == LABEL_REF
|| (GET_CODE (x)
On Mon, May 26, 2014 at 7:48 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
There is a stray ! in ix86_rtx_costs which results in an invalid
bypass for LABEL_REFs. After some simplifications, the fixed condition
should read:
else if (flag_pic SYMBOLIC_CONST (x)
Hi,
adjusted patch to make it more bullet-proved and tested it.
2014-05-26 Kai Tietz kti...@redhat.com
* config/i386/i386.c (ix86_expand_call): Enforce for sibcalls
on memory the use of accumulator-register.
(ix86_function_ok_for_sibcall): Reject for x86_64 ABI sibling
Hello!
2014-05-26 Uros Bizjak ubiz...@gmail.com
* gcc.dg/lto/pr61278_1.c: Remove dg directives.
Tested on x86_64-pc-linux-gnu and committed.
Uros.
Index: ChangeLog
===
--- ChangeLog (revision 210936)
+++ ChangeLog
On Mon, May 26, 2014 at 02:20:36PM -0400, Kai Tietz wrote:
--- i386.c(revision 210936)
+++ i386.c(working copy)
@@ -5298,6 +5298,12 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
decl_or_type = type;
}
+ /* We need to reject stdarg-function for x86_64 ABI as
Hello!
2014-05-26 Uros Bizjak ubiz...@gmail.com
* c-c++-common/cilk-plus/AN/pr61191.c: Fix dg-error directives.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: c-c++-common/cilk-plus/AN/pr61191.c
The patches I posted to cache recog_op_alt and the set of enabled
alternatives both relied on having an array of LAST_INSN_CODE elements.
It turns out that LAST_INSN_CODE is only 1+ the last _named_ insn,
rather than 1+ the last used insn code.
The only users of LAST_INSN_CODE I can see are LRA,
Hi,
This patch teaches the C++ frontend to warn on NULL checks against
inline functions and it teaches the middle-end to fold NULL checks
against inline functions. These two things are currently done for
non-inline C++ functions, but inline functions are exceptional in that
the C++ frontend
Committed as Rev. 210946.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 210945)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2014-05-26 Tobias Burnus bur...@net-b.de
+
+ * gfortran.texi
Hi Jan,
r210901 | hubicka | 2014-05-25 00:00:14 +0200 (So, 25. Mai 2014)
this checkin broke the aarch64 build:
./../gcc-trunk/gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_elf_asm_named_section(const char*, unsigned int, tree)’:
../../gcc-trunk/gcc/tree.h:2326:26:
Jeff Law l...@redhat.com writes:
On 05/20/14 02:19, Richard Sandiford wrote:
On the subject of commutativity, we have:
static bool
commutative_constraint_p (const char *str)
{
int curr_alt, c;
bool ignore_p;
for (ignore_p = false, curr_alt = 0;;)
- Original Message -
On Mon, May 26, 2014 at 02:20:36PM -0400, Kai Tietz wrote:
--- i386.c (revision 210936)
+++ i386.c (working copy)
@@ -5298,6 +5298,12 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
decl_or_type = type;
}
+ /* We need to reject
Hi Jan,
looks good. Thanks!
Bernd
On Mon, 26 May 2014 21:07:28 +0200, Jan Hubicka wrote:
From: hubi...@ucw.cz
To: bernd.edlin...@hotmail.de
CC: hubi...@ucw.cz; gcc-patches@gcc.gnu.org
Subject: Re: aarch64 build broken
Hi Jan,
r210901 | hubicka | 2014-05-25 00:00:14 +0200 (So, 25.
On Mon, May 26, 2014 at 03:22:50PM -0400, Kai Tietz wrote:
In any case, I still can't understand how limiting the choices of the
register allocator can improve code rather than making it worse.
If the accumulator is available there, why doesn't the RA choose it
if it is beneficial? And
On Mon, 26 May 2014, Patrick Palka wrote:
This patch teaches the C++ frontend to warn on NULL checks against
inline functions and it teaches the middle-end to fold NULL checks
against inline functions. These two things are currently done for
non-inline C++ functions, but inline functions are
- Original Message -
On Mon, May 26, 2014 at 03:22:50PM -0400, Kai Tietz wrote:
In any case, I still can't understand how limiting the choices of the
register allocator can improve code rather than making it worse.
If the accumulator is available there, why doesn't the RA choose
On Mon, May 26, 2014 at 4:26 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 26 May 2014, Patrick Palka wrote:
This patch teaches the C++ frontend to warn on NULL checks against
inline functions and it teaches the middle-end to fold NULL checks
against inline functions. These two things
Hi,
libgfortran has malloc and calloc wrappers, but so far the equivalent
realloc wrapper has been missing. The attached patch corrects this,
and converts existing realloc users. Committed r210948 to trunk as
obvious after regtesting on x86_64-unknown-linux-gnu.
2014-05-26 Janne Blomqvist
- puts ( LAST_INSN_CODE\n\
+ printf ( LAST_INSN_CODE = %d\n\
};\n\
\n\
-#endif /* GCC_INSN_CODES_H */);
+#endif /* GCC_INSN_CODES_H */, last);
You probably didn't intend to delete the newline at the end of
the generated file?
Segher
On Mon, 26 May 2014, Patrick Palka wrote:
On Mon, May 26, 2014 at 4:26 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 26 May 2014, Patrick Palka wrote:
This patch teaches the C++ frontend to warn on NULL checks against
inline functions and it teaches the middle-end to fold NULL checks
On 2014-05-25, 12:58 PM, Christophe Lyon wrote:
Hi,
Since this patch was committed, I can see aarch64_be-none-elf build
fail in newlib with this error message:
0x8ba1fb check_rtl
/tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:2083
0x8bd5b2 lra(_IO_FILE*)
On 26 May 2014 23:24, Vladimir Makarov vmaka...@redhat.com wrote:
On 2014-05-25, 12:58 PM, Christophe Lyon wrote:
Hi,
Since this patch was committed, I can see aarch64_be-none-elf build
fail in newlib with this error message:
0x8ba1fb check_rtl
On Sun, 18 May 2014, Tom G. Christensen wrote:
Latest results for 4.9.x
-tgc
Testresults for 4.9.0:
arm-unknown-linux-gnueabi
hppa-unknown-linux-gnu
i386-pc-solaris2.9 (2)
i386-pc-solaris2.10
i386-pc-solaris2.11
i686-unknown-linux-gnu
mips-unknown-linux-gnu
Jan,
The IPA patch broke bootstrap on AIX with multiple failures.
The tail of the build log is attached.
- David
make AR_FLAGS= CC_FOR_BUILD= CC_FOR_TARGET= CFLAGS=-g -O2 CXXFLAGS=-g
-O2 CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET=
INSTALL=/nasfarm/edelsohn/src/src/install-sh -c
On Mon, May 26, 2014 at 8:19 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Mon, May 26, 2014 at 6:12 PM, Jonathan Wakely jwak...@redhat.com wrote:
I see that the patch on the Google branch removes some of the
__google_stl_debug_vector checks -- are they considered no
This patch (further) broke bootstrap on AIX. AIX defaults to 32 bit,
although it supports 64 bit HWI.
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'int
print_statistics(bitmap_descriptor_d**, output_info*)':
/nasfarm/edelsohn/src/src/gcc/bitmap.c:2168:24: error: expected ')'
before
Sorry, I meant to refer to the 3/n patch.
Thanks, David
On Mon, May 26, 2014 at 9:58 PM, David Edelsohn dje@gmail.com wrote:
This patch (further) broke bootstrap on AIX. AIX defaults to 32 bit,
although it supports 64 bit HWI.
/nasfarm/edelsohn/src/src/gcc/bitmap.c: In function 'int
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com wrote:
Doesn't look like the ppc32 port would be in any worse shape than the 64-bit
one.
Peter has brought a real problem, in particular the allocator now newly
relying on
2 x word size atomics which is definitely
Jan,
The IPA patch broke bootstrap on AIX with multiple failures.
The tail of the build log is attached.
Thanks,
I will give it a try at gcc111, good to have reproducible testcase.
Honza
- David
make AR_FLAGS= CC_FOR_BUILD= CC_FOR_TARGET= CFLAGS=-g -O2
CXXFLAGS=-g -O2
Hi Jan,
looks good. Thanks!
Thanks,
I have commited the change.
Honza
Georg-Johann Lay a...@gjlay.de writes:
This is Ping #1 for
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00747.html
an addendum that adds runtime library exception to two more files
in the ARM backend (arm-opts.h, arm-cores.def) that are included in libgcc.
Ok to apply?
This is OK.
On 05/22/2014 06:56 AM, Thomas Schwinge wrote:
Hi!
Now that GCC again is in development stage, and with fresh hope to have
someone review this patch submission, after having let the issue rest for
several months: I just re-tested the current versions. Still there are
no changes for a regular
On Tue, May 27, 2014 at 6:25 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com wrote:
Doesn't look like the ppc32 port would be in any worse shape than the
64-bit
one.
Peter has brought a real problem, in particular the
my 2c
- using instrumentation via calls adds extra 1.5x-2.x slowdown
- it indeed saves code size
- in LLVM this was done mostly to overcome the compile time problem on
huge functions
- in GCC we will indeed need this for kasan
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
- it would be nice to have the name prefix configurable from command
line (${PREFIX}_load1 instead of __asan_load1) because kasan uses
different names already.
Yeah, I noticed corresponding option in LLVM. AFAIK
On Tue, May 27, 2014 at 9:40 AM, Yury Gribov y.gri...@samsung.com wrote:
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
Interesting. can you share your ARM numbers?
- it would be nice to have the name prefix configurable from command
line (${PREFIX}_load1 instead
On 05/27/2014 09:43 AM, Konstantin Serebryany wrote:
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
Interesting. can you share your ARM numbers?
That wasn't an objection - I just made sure to specify the platform (x64
ABI is somewhat special).
96 matches
Mail list logo
