On Fri, May 23, 2014 at 8:45 PM, Jakub Jelinek 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
>> >>undefined b
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 co
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
Hello!
> 2014-05-26 Michael Tautschnig
>
> 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
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
/opt
On Mon, May 26, 2014 at 1:59 AM, Dominique Dhumieres 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 if there is no
d
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$0x4,%e
> 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 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 -fdisable|enable-xx
On Mon, May 26, 2014 at 2:22 AM, FX 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 issue (http
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 26
On Mon, May 26, 2014 at 10:14 AM, FX 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 (), op2
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 send
On Mon, May 26, 2014 at 1:25 AM, Steve Kargl
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
>> MinGW this does not pro
On Fri, May 23, 2014 at 5:23 AM, Hans-Peter Nilsson 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 requiring jump
On Mon, May 26, 2014 at 1:14 AM, FX 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 (), op2.
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
D
On 23 May 2014 17:01, Evgeniy Stepanov 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,
Christophe.
> On Fri, May 23
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 wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
>> wrote:
>
>> >
>> > Updated ChangeLogs:
>> >
>> > *** gcc/ChangeLog ***
>> >
>> > 2014-05-20 Thomas Preud'homme
>> >
>> >
> 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 i
> 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 suc
> 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 2-
On Mon, May 26, 2014 at 2:53 PM, Arseny Solokha 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
> addition
> to al
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:
Ge
On Mon, May 26, 2014 at 01:00:56PM +0300, Janne Blomqvist wrote:
> On Mon, May 26, 2014 at 1:25 AM, Steve Kargl
> 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 a
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:
http://
On Mon, May 26, 2014 at 12:22 PM, Eric Botcazou 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 - X;
>re
Jan Hubicka 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 tree_decl_non_common (and
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.
Richar
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::vector v(4);
v.reserve(8);
int *p = v.data();
p[6] = 0; // BOOM
We call these bugs "container overflow" [2,6] and we've deve
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);
^
pr56724-2.c:9:
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 our
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 x86
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 Go
On Mon, May 26, 2014 at 6:12 PM, Jonathan Wakely wrote:
> 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
>
On May 26, 2014, at 4:26 AM, FX wrote:
> Here’s a patch that removes all the casts on output operands in x86/x86_64
> code in longlong.h.
I’d love for someone to explain why the casts were there in the first place… I
like the idea of removing them.
On May 26, 2014, at 6:39 AM, Richard Biener 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, thanks.
> 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]
> http://
On May 26, 2014, at 2:22 AM, FX 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 issue (https://
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 d'Humi
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 @@ cp_build_modify_expr
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 (http://llvm.org/bugs/show_bug.cgi?id=12653)
> 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 m
* 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.
* asan_calls_1.d
> 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
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 wit
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
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
* bid128_div.c (BID128_FUNCTION_ARG2): Remove unused variable 'Ql
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
On Mon, May 26, 2014 at 7:48 PM, Uros Bizjak 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)
>&& !(TARGET_64BIT
Hi,
adjusted patch to make it more bullet-proved and tested it.
2014-05-26 Kai Tietz
* 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
calls for
Hello!
2014-05-26 Uros Bizjak
* 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 (working copy)
@@ -1,3 +
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
Hello!
2014-05-26 Uros Bizjak
* 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
===
--- c-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, w
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 marks
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
+
+ * gfortran.texi (Project Status):
> 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/tre
Jeff Law 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
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 +02
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?
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 ex
- 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 R
On Mon, May 26, 2014 at 4:26 PM, Marc Glisse 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 are currently
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 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 functio
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*)
/tmp
On 26 May 2014 23:24, Vladimir Makarov 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
>>
>> /tmp/5244922_15.tmpdir/aci-gcc-fsf/sources/gcc-fsf
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"
"INST
On Mon, May 26, 2014 at 8:19 AM, Konstantin Serebryany
wrote:
>
> On Mon, May 26, 2014 at 6:12 PM, Jonathan Wakely wrote:
> > I see that the patch on the Google branch removes some of the
> > __google_stl_debug_vector checks -- are they considered no longer
> > necessary/useful with asan?
>
> Th
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 'PRId64
Sorry, I meant to refer to the 3/n patch.
Thanks, David
On Mon, May 26, 2014 at 9:58 PM, David Edelsohn 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
> print_statistic
> On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek 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 non-portable,
> 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
> Hi Jan,
>
>
> looks good. Thanks!
Thanks,
I have commited the change.
Honza
Georg-Johann Lay 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. Sorry, I d
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 wrote:
>> On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek 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
>> > relyi
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
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKe
> - 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 stan
On Tue, May 27, 2014 at 9:40 AM, Yury Gribov 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 of __asan_lo
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).
On May 27, 2014 3:58:06 AM CEST, David Edelsohn 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
>print_statistics(bitmap_descriptor_d**, output_info*)':
>/nasfarm/edelsohn/sr
On Tue, May 27, 2014 at 08:26:35AM +0200, Richard Biener wrote:
> >/nasfarm/edelsohn/src/src/gcc/cfg.c: In function 'void
> >dump_bb_info(FILE*, basic_block, int, int, bool, bool)':
> >/nasfarm/edelsohn/src/src/gcc/cfg.c:737:33: error: expected ')' before
> >'PRId64'
>
> This means aix has inttype
Hello!
These tests require vect_simd_clones effective target, as the target
should be able to compile AVX clones.
2014-05-27 Uros Bizjak
* testsuite/libgomp.fortran/declare-simd-1.f90: Require
vect_simd_clones effective target. Remove
dg-additional-options directives.
* tests
97 matches
Mail list logo
