"H.J. Lu" a écrit:
>> 2012-11-24 H.J. Lu
>>
>> * configure.ac: Append gdbasan.in to .gdbinit if CFLAGS contains
>> -fsanitize=address.
>> * configure: Regenerated.
>>
>> * gdbasan.in: New file.
This is OK, if nobody objects in the next 48h.
Thanks.
--
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the half of the rtl code.
This looks OK to me.
--
Eric Botcazou
On 1 December 2013 19:55, Michael Hudson-Doyle
wrote:
> Ian Lance Taylor writes:
>
>> I've gotten a patch from Michael Hudson-Doyle to set GOARCH to arm64
>> on an Aarch64 system (https://codereview.appspot.com/34830045/).
>
> Haha, go us.
>
>> I've gotten a patch from Matthias Klose to set GOARC
On Mon, Dec 2, 2013 at 1:02 AM, Marcus Shawcroft
wrote:
> On 1 December 2013 19:55, Michael Hudson-Doyle
> wrote:
>> Ian Lance Taylor writes:
>>
>>> I've gotten a patch from Michael Hudson-Doyle to set GOARCH to arm64
>>> on an Aarch64 system (https://codereview.appspot.com/34830045/).
>>
>> Hah
Hi all!
Currently gcc has tests for AddressSanitizer and UBSanitizer. Do you
think it would make sense to add support for ThreadSanitizer testing as
well? If the answer is positive, we can work on dg infrastructure
(tsan-dg.exp, tsan.exp) and initial set of tests. As for the latter:
should we
> My apologies for taking so long to look at this.
No problem, all the more so that...
> > 2013-09-05 Eric Botcazou
> >
> > * config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with
> > arguments to push onto the stack and no varargs, save ip into a stack
> > slot if r
I'd be glad to have tsan tests in GCC.
At the very least we need to have a couple of sanity tests to make
sure tsan links and finds a trivial race.
The only mode in which my team can truly support tsan tests is when
they are verbatim copies of the upstream tests
and they are merged together with th
On 2 Dec 2013, at 00:06, "Rob Pike" wrote:
> arm64 it is
>
This is perverse and completely inconsistent with the rest of the gnu tool
chain. It makes no sense at all to me for go to be inconsistent in this way.
R.
On Mon, Dec 02, 2013 at 02:13:42PM +0400, Yury Gribov wrote:
> Currently gcc has tests for AddressSanitizer and UBSanitizer. Do you
> think it would make sense to add support for ThreadSanitizer testing
> as well? If the answer is positive, we can work on dg infrastructure
> (tsan-dg.exp, tsan.exp)
On 29 Nov 2013, at 19:38, "Andrew Pinski" wrote:
> On Fri, Nov 29, 2013 at 11:34 AM, Matthias Klose wrote:
>> Please let's pick aarch64. Everybody names it this way, except of course
>> Debian
>
> And the linux kernel.
>
The Linux kernel reports aarch64 in its uname. It's only the source
Konstantin Serebryany wrote:
> Other mode may work too, but we will not own the tests
> (similarly, we don't own the existing asan tests in GCC,
> although if the tests need fixing during integrate we do it).
I think everyone agrees on this. Once tests are in, Gcc team will
maintain them.
-Y
On Fri, Nov 29, 2013 at 3:59 PM, Richard Sandiford
wrote:
> Only a partial reply. I'll leave Kenny and Mike to answer the VARYING
> question.
>
> Richard Biener writes:
>> On Sat, Nov 23, 2013 at 8:23 PM, Mike Stump wrote:
>>> Richi has asked the we break the wide-int patch so that the individu
Jakub Jelinek wrote:
> The problem is that at least by default we
> don't want very expensive tests in the testsuite, whether it is runtime
> expensive or eats too much memory.
I see. We can only merge small tests then. From what I see in
compiler-rt/lib/tsan/lit_tests, most of the tests are rat
On Sat, Nov 30, 2013 at 1:55 AM, Kenneth Zadeck
wrote:
> Richi,
>
> this is the first of either 2 or 3 patches to fix this.There are two
> places that need be fixed for us to do 1X + 1 and this patch fixes the first
> one. There was an unnecessary call to mul_full and this was the only call
Hi Tobias,
On Fri, 25 Oct 2013, Tobias Burnus wrote:
>> http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
>> However, some script changes the link to:
>>http://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html
>> which won't work. Try yourself at http://gcc.gnu.org/gcc-4.9/c
On Sun, 1 Dec 2013, Ryan Mansfield wrote:
> I noticed there wasn't an entry in the option index for -fuse-ld. If
> OK, can someone apply? Thanks.
Thanks, Ryan! This is also covered by Tobias' patch...
On Sun, 1 Dec 2013, Tobias Burnus wrote:
> There are many more options which lack an optindex
The following fixes a bug in update_address_taken which fails
to reset debug stmts which take the address of a decl we will
rewrite into SSA form. Our verifiers don't catch this because
of an early out in the operand scanner which doesn't work in
the specific case of LTO profiledbootstrap (or bec
On Sat, Nov 30, 2013 at 10:43 AM, Richard Sandiford
wrote:
> So maybe two INTEGER_CST lengths weren't enough. Because bitsizetype
> can be offset_int-sized, wi::to_offset had a TYPE_PRECISION condition
> to pick the array length:
>
> template
> inline unsigned int
> wi::extended_tree ::get_len (
On Sat, Nov 30, 2013 at 6:24 PM, Eric Botcazou wrote:
> Hi,
>
> this test started to fail very recently on 32-bit platforms with 64-bit HWI.
> Not sure exactly why, but the issue is straightforward and was latent.
>
> For the following reference, a call to ao_ref_init_from_ptr_and_size yields:
>
>
On Sun, Dec 1, 2013 at 11:51 AM, Richard Sandiford
wrote:
> At the moment we only use host divisions for precisions <=
> HOST_BITS_PER_WIDE_INT. This patch extends it to any division in which
> the inputs fit in HWIs. The easiest way seemed to be to construct
> wide_int_refs for the numbers and
On Mon, Dec 02, 2013 at 12:05:57PM +0100, Richard Biener wrote:
>
> The following fixes a bug in update_address_taken which fails
> to reset debug stmts which take the address of a decl we will
> rewrite into SSA form. Our verifiers don't catch this because
> of an early out in the operand scanne
On Fri, Nov 29, 2013 at 5:10 PM, Yufeng Zhang wrote:
> On 11/29/13 10:44, Richard Biener wrote:
>>
>> On Fri, Nov 29, 2013 at 8:52 AM, Bin.Cheng wrote:
>>>
>>> On Thu, Nov 28, 2013 at 8:06 PM, Bin.Cheng wrote:
On Thu, Nov 28, 2013 at 6:48 PM, Richard Earnshaw
wrote:
>
> On
On Mon, 2 Dec 2013, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 12:05:57PM +0100, Richard Biener wrote:
> >
> > The following fixes a bug in update_address_taken which fails
> > to reset debug stmts which take the address of a decl we will
> > rewrite into SSA form. Our verifiers don't catch
On Wed, 2013-11-27 02:43:08 +0100, Jan-Benedict Glaw wrote:
> On Sun, 2013-11-24 20:02:43 +0100, Jan-Benedict Glaw
> wrote:
> > 2013-11-24 Jan-Benedict Glaw
> >
> > * config-list.mk (host_options): Allow to override it.
> > (LIST): Change "=" to "EQUAL".
> > (list): New target li
On Fri, Nov 29, 2013 at 4:03 PM, Jakub Jelinek wrote:
> On Fri, Nov 29, 2013 at 01:36:48PM +0100, Richard Biener wrote:
>> > Thoughts, comments? Does anyone have a good name for these accelerator
>> > targets or output targets, something that avoids the overloaded word
>> > "target" (I was thinkin
Hi All,
Attached is evident fix found in process of investigation of PR 58721.
Note that this fix does not resolve it.
Is it OK for trunk?
ChangeLog:
2013-11-02 Yuri Rumyantsev
* gcc/ipa-inline.c (check_callers) : Add missed pointer de-reference.
ipa-inline-fix
Description: Binary data
Hi,
"ld" is a special name for GCC driver. find_a_file has
#ifdef DEFAULT_LINKER
if (! strcmp (name, "ld") && access (DEFAULT_LINKER, mode) == 0)
return xstrdup (DEFAULT_LINKER);
#endif
#endif
It does 2 things:
1. Print DEFAULT_LINKER for -print-prog-name=ld.
2. Run DEFAULT_LINKE
On 11/30/13, 9:07 AM, Mike Stump wrote:
> On Nov 28, 2013, at 2:03 AM, Chung-Ju Wu wrote:
>> There is a pending testsuite patch for nds32 target:
>>http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01584.html
>>
>> Is it OK for trunk? :)
>
> Ok, but please remove:
>
> { target nds32*-*-* }
>
Hello,
On 19 Nov 12:05, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:03, Kirill Yukhin wrote:
> > Ping?
> Ping?
Ping?
--
Thanks, K
On Fri, 8 Nov 2013, H.J. Lu wrote:
> bugreport.texi has
>
> @menu
> * Criteria: Bug Criteria. Have you really found a bug?
> * Reporting: Bug Reporting. How to report a bug effectively.
> * Known: Trouble.Known problems.
> * Help: Service. Where to ask for help.
> @end
Hello,
On 19 Nov 12:08, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:06, Kirill Yukhin wrote:
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello,
On 19 Nov 12:12, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:08, Kirill Yukhin wrote:
> > > Is it ok for trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello,
On 19 Nov 12:11, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:07, Kirill Yukhin wrote:
> > > Is it ok for trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello,
On 19 Nov 12:14, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:09, Kirill Yukhin wrote:
> > > Is it ok for trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
On Mon, Dec 2, 2013 at 3:52 AM, Konstantin Serebryany
wrote:
> Another libsanitizer merge from upstream, r196090
> (needs attention on ubsan side)
>
> This hopefully fixes various build failures on non-x86-linux platforms,
> although I still tested it only on our x86_64 Linux Ubuntu 12.04 box:
> r
Hello,
On 19 Nov 12:14, Kirill Yukhin wrote:
> Hello,
> On 15 Nov 20:10, Kirill Yukhin wrote:
> > > Is it ok to commit to main trunk?
> > Ping.
> Ping.
Ping.
--
Thanks, K
Hello
> Ok for trunk?
Ping?
--
Thanks, K
Ping.
On Fri, 13 Sep 2013, Marc Glisse wrote:
Ping
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01381.html
On Fri, 23 Aug 2013, Marc Glisse wrote:
On Sun, 4 Aug 2013, Gerald Pfeifer wrote:
On Sat, 13 Jul 2013, Marc Glisse wrote:
2013-07-14 Marc Glisse
gcc/cp/
* call.c (build_c
Hello,
> Is it ok now?
Ping?
--
Thanks, K
On Mon, Dec 2, 2013 at 1:36 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> Attached is evident fix found in process of investigation of PR 58721.
> Note that this fix does not resolve it.
>
> Is it OK for trunk?
Ok.
Thanks,
Richard.
> ChangeLog:
>
> 2013-11-02 Yuri Rumyantsev
>
> * gcc/ipa-inline.
On Mon, Dec 02, 2013 at 05:13:45AM -0800, H.J. Lu wrote:
> > === libsanitizer/ChangeLog
> >
> > 2013-12-0X Kostya Serebryany
> >
> > * All source files: Merge from upstream r196090.
> > * tsan/Makefile.am (tsan_files): Added new files.
> > * tsan/Makefile.in: Rege
So ok to commit this fix?
---
From: Yury Gribov
Sent: Monday, December 02, 2013 10:12AM
To: Andreas Schwab
Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org,
eugeni.stepa...@gmail.com, VandeVondele Joost
, Evgeny Gavrin ,
Viacheslav Garbuzov
Subject:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> This change breaks one ubsan test:
> make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
> FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
> I am asking gcc-ubsan maintainers to help me decipher d
Richard Biener writes:
> On Sat, Nov 30, 2013 at 10:43 AM, Richard Sandiford
> wrote:
>> So maybe two INTEGER_CST lengths weren't enough. Because bitsizetype
>> can be offset_int-sized, wi::to_offset had a TYPE_PRECISION condition
>> to pick the array length:
>>
>> template
>> inline unsigned i
On Mon, 2 Dec 2013, Richard Biener wrote:
> On Mon, 2 Dec 2013, Jakub Jelinek wrote:
>
> > On Mon, Dec 02, 2013 at 12:05:57PM +0100, Richard Biener wrote:
> > >
> > > The following fixes a bug in update_address_taken which fails
> > > to reset debug stmts which take the address of a decl we will
On Mon, Dec 2, 2013 at 2:48 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Sat, Nov 30, 2013 at 10:43 AM, Richard Sandiford
>> wrote:
>>> So maybe two INTEGER_CST lengths weren't enough. Because bitsizetype
>>> can be offset_int-sized, wi::to_offset had a TYPE_PRECISION condition
>
Sorry, I was waiting for Jason to review (since he's the subject
matter expert), and I guess he was waiting for me?
Jason, can you please have a look and approve?
Only one comment from my side:
Index: doc/extend.texi
===
+In C++, th
On Mon, Dec 02, 2013 at 02:21:04PM +0100, Richard Biener wrote:
> On Mon, Dec 2, 2013 at 1:36 PM, Yuri Rumyantsev wrote:
> > Hi All,
> >
> > Attached is evident fix found in process of investigation of PR 58721.
> > Note that this fix does not resolve it.
> >
> > Is it OK for trunk?
>
> Ok.
>
>
On Mon, 2 Dec 2013, Gerald Pfeifer wrote:
Only one comment from my side:
Index: doc/extend.texi
===
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same type and @
On Mon, Dec 2, 2013 at 5:30 AM, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 02:21:04PM +0100, Richard Biener wrote:
>> On Mon, Dec 2, 2013 at 1:36 PM, Yuri Rumyantsev wrote:
>> > Hi All,
>> >
>> > Attached is evident fix found in process of investigation of PR 58721.
>> > Note that this fix do
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> > This change breaks one ubsan test:
> > make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
> > FAIL: c-c++-common/ubsan/vla-1.c -O0 e
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
wrote:
> Hello Richard,
>
> as a follow-up patch to the bit-fields patch(es), I wanted to remove the
> dependencies on
> the variable flag_strict_volatile_bitfields from expand_assignment and
> expand_expr_real_1.
> Additionally I want the access
On Mon, Dec 2, 2013 at 6:41 PM, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
>> On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
>> > This change breaks one ubsan test:
>> > make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m6
On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
> > On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> > > This change breaks one ubsan test:
> > > make check -C gcc RUNTESTFLAGS='--target_board=un
On Mon, Nov 25, 2013 at 1:07 PM, Bernd Edlinger
wrote:
> Hello,
>
> I had forgotten to run the Ada test suite when I submitted the previous
> version of this patch.
> And indeed there were some Ada test cases failing because in Ada packed
> structures are
> like bit fields, but without the DECL_
On Mon, Dec 02, 2013 at 03:47:18PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
> > On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
> > > On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> > > > This change breaks
On Mon, Nov 18, 2013 at 1:11 PM, Bernd Edlinger
wrote:
> Hi,
>
>
> This modified test case exposes a bug in the already approved part of the
> strict-volatile-bitfields patch:
>
> #include
>
> typedef struct {
> char pad;
> int arr[0];
> } __attribute__((packed)) str;
>
> str *
> foo (int* s
On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek wrote:
> Ping.
Ok. (yay, oldest patch in my review queue ...)
Thanks,
Richard.
> On Tue, Mar 05, 2013 at 05:06:21PM +0100, Marek Polacek wrote:
>> On Fri, Mar 01, 2013 at 09:41:27AM +0100, Richard Biener wrote:
>> > On Wed, Feb 27, 2013 at 6:38 PM
On Sun, Nov 3, 2013 at 11:25 AM, Bernd Edlinger
wrote:
> Hello,
>
> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
> because of
> an internal compiler error, see PR58155.
>
> The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
> should be enabled.
>
On Thu, Nov 28, 2013 at 6:06 AM, Jan Hubicka wrote:
>> Dear Teresa and Jan,
>>I tried to test Teresa's patch, but I've encountered two bugs
>> during usage of -fprofile-generate/use (one in SPEC CPU 2006 and
>> Inkscape).
>
> Thanks, this is non-LTO run. Is there a chance to get -flto version,
This fixes PR59139, ternary support was missing from get_val_for.
Instead of supporting it I simply chose to properly disable its
support.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-12-02 Richard Biener
PR tree-optimization/59139
* tree-ssa-
On Sat, Nov 23, 2013 at 8:23 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the tree-vec code.
>
> Ok?
Ok.
Thanks,
Richard
On Sat, Nov 23, 2013 at 8:22 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the random pieces that didn't seem to
> fit nic
Ping~
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03360.html
Thanks,
Yufeng
On 11/26/13 15:02, Yufeng Zhang wrote:
On 11/26/13 12:45, Richard Biener wrote:
On Thu, Nov 14, 2013 at 12:25 AM, Yufeng Zhang wrote:
On 11/13/13 20:54, Bill Schmidt wrote:
The second version of your original pat
Hello!
>> Does it support using libbacktrace in GCC?
>
> Not on it's own, but the support in the upstream maintained files
> is there, so hopefully it will be just a matter of follow-up patch
> with configury/Makefile etc. stuff, I'll work on it once the merge is
> committed.
>
> What is more impo
This patch puts every VLA test into its separate function to make it
less like fail due to stack overflow.
Ran ubsan testsuite, ok for trunk?
2013-12-02 Marek Polacek
testsuite/
* c-c++-common/ubsan/vla-1.c: Split the tests into individual
functions.
--- gcc/testsuite/c-c++-c
On Mon, Dec 02, 2013 at 04:57:49PM +0100, Marek Polacek wrote:
> This patch puts every VLA test into its separate function to make it
> less like fail due to stack overflow.
>
> Ran ubsan testsuite, ok for trunk?
Ok, thanks.
> 2013-12-02 Marek Polacek
>
> testsuite/
> * c-c++-common/ubs
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak wrote:
> Hello!
>
>>> Does it support using libbacktrace in GCC?
>>
>> Not on it's own, but the support in the upstream maintained files
>> is there, so hopefully it will be just a matter of follow-up patch
>> with configury/Makefile etc. stuff, I'll wor
On 12/02/13 08:16, Teresa Johnson wrote:
I'm wondering if the -fno-reorder-blocks-and-partition graph really
had that disabled. I am surprised that the size of the .text and
.text.hot did not shrink from splitting.
Could be due to needing longer jump opcodes to reach the unlikely sections.
jeff
On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
wrote:
Does it support using libbacktrace in GCC?
>>>
>>> Not on it's own, but the support in the upstream maintained files
>>> is there, so hopefully it will be just a matter of follow-up patch
>>> with configury/Makefile etc. stuff, I'l
On 12/1/2013, 7:57 AM, James Greenhalgh wrote:
On Thu, Nov 28, 2013 at 10:11:26PM +, Vladimir Makarov wrote:
Committed as rev. 205498.
2013-11-28 Vladimir Makarov
PR target/57293
* ira.h (ira_setup_eliminable_regset): Remove parameter.
* ira.c (ira_setup_elimina
On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
> On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek wrote:
> > Ping.
>
> Ok. (yay, oldest patch in my review queue ...)
;) thanks. Just to be sure, did you mean to ok this patch (that is,
the one with HOST_BITS_PER_INT)?
Bootstrap/r
On Mon, Dec 2, 2013 at 5:26 PM, Uros Bizjak wrote:
> On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
> wrote:
>
> Does it support using libbacktrace in GCC?
Not on it's own, but the support in the upstream maintained files
is there, so hopefully it will be just a matter o
Dear Teresa,
I will today double check if the graphs are correct :)
Martin
On 2 December 2013 17:16, Jeff Law wrote:
> On 12/02/13 08:16, Teresa Johnson wrote:
>>
>>
>> I'm wondering if the -fno-reorder-blocks-and-partition graph really
>> had that disabled. I am surprised that the size of th
On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
> We can fix this particular failure, but unless someone helps us test
> the code upstream
> (not just that it builds, but also that it works) asan has little
> chance to work on old systems anyway.
For these kernel headers tha
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
>> No, so your patch doesn't regress anything. I can configure with
>> --disable-libsanitizer to skip build of libsanitizer, although it
>> would be nice to support RHEL5 derived lon
On Mon, Dec 2, 2013 at 5:10 AM, Gerald Pfeifer wrote:
> On Fri, 8 Nov 2013, H.J. Lu wrote:
>> bugreport.texi has
>>
>> @menu
>> * Criteria: Bug Criteria. Have you really found a bug?
>> * Reporting: Bug Reporting. How to report a bug effectively.
>> * Known: Trouble.Known problems.
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
> On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek wrote:
> > On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
> >> No, so your patch doesn't regress anything. I can configure with
> >> --disable-libsanitizer to skip b
On Mon, 2 Dec 2013, Marc Glisse wrote:
>> Index: doc/extend.texi
>> ===
>> +In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
>> +@code{b} and @code{c} are vectors of the same type and @code{a} is an
>> +integer
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
> No, so your patch doesn't regress anything. I can configure with
> --disable-libsanitizer to skip build of libsanitizer, although it
> would be nice to support RHEL5 derived long-term distributions.
>
> > Is there a way to test gcc in
Points to solver has a bug that can cause complex constraints to be
skipped leading to wrong points-to results. In the case that exposed
the problem, there is sd constraint: x = *y which is never processed.
'y''s final points to set is { NULL READONLY ESCAPED NOLOCAL}, but 'x'
points-to set is {}.
On 11/29/2013 12:02 PM, Jakub Jelinek wrote:
> As we create SIMD clones for all of SSE2, AVX and AVX2 ISAs right now,
> the assembler needs to support SSE2, AVX and AVX2. Apparently some folks
> are still using binutils that don't handle that, this patch conditionalizes
> the test on that.
>
> Bo
On Mon, Dec 02, 2013 at 05:40:33PM +0100, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
> > On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek wrote:
> > > Ping.
> >
> > Ok. (yay, oldest patch in my review queue ...)
>
> ;) thanks. Just to be sure, did you
Ian Lance Taylor writes:
> On Sun, Dec 1, 2013 at 2:28 AM, Richard Sandiford
> wrote:
>> I followed Joseph's suggestion and reused longlong.h. I copied it from
>> libgcc rather than glibc since it seemed better for GCC to have a single
>> version across both gcc/ and libgcc/. I can put it in in
On Dec 2, 2013, at 5:02 AM, Chung-Ju Wu wrote:
> Perhaps I should have used the following description, which seems much better:
>
> +/* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have
> args in registers." { nds32*-*-* } "*" "" } */
Reads nicely, thanks. Also, if I do a
Gerald Pfeifer wrote:
Below you'll find a patch for maintainer-scripts/update_web_docs_svn
which I tested on gcc.gnu.org and the current documentation pages (not
those for older releases) are adjusted now.
Among others this fixes the link you reported above (though adjusting
gcc-4.9/changes.html
Il 02/12/2013 20:34, Richard Sandiford ha scritto:
>>> >> I followed Joseph's suggestion and reused longlong.h. I copied it from
>>> >> libgcc rather than glibc since it seemed better for GCC to have a single
>>> >> version across both gcc/ and libgcc/. I can put it in include/ if that
>>> >> see
On Dec 2, 2013, at 1:10 AM, Andrew Pinski wrote:
>> All the documentation relevant to this architecture uses the term
>> "aarch64". How is arm64 obvious?
>
> The same reason Linus used arm64:
> https://lkml.org/lkml/2012/7/15/133
Thanks for the link, ah, now I exactly understand what that port i
committed as revision 205599 to wide-int branch.
kenny
On 12/02/2013 05:50 AM, Richard Biener wrote:
On Sat, Nov 30, 2013 at 1:55 AM, Kenneth Zadeck
wrote:
Richi,
this is the first of either 2 or 3 patches to fix this.There are two
places that need be fixed for us to do 1X + 1 and this p
We triggered an assert on attached testcase, because when building the
compound literal with empty initial value complete_array_type returns
3, but we assert it returns 0. It returns 3 only in the pedantic mode,
where empty initializer braces are forbidden. Since we already gave
a warning, I thin
On Tue, 21 Aug 2012, Sriraman Tallam wrote:
> Committed after making the changes.
>
> One small problem, I am not sure how to fix this:
>
> The hyper link I referenced is :
> http://gcc.gnu.org/onlinedocs/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions
>
> whereas the committed ch
I noticed that there were still a couple of tests for zero precision.
This patch replaces them with asserts when handling separately-supplied
precisions and simply drops them when handling existing wide_ints.
(The idea is that most code would break for zero precision wide_ints
and only asserting in
see wide-int.h around line 290
the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
if the value coming in is an unsigned number of the type the represents
that mode, don't we loose a bit?
kenny
Marek Polacek wrote:
>On Mon, Dec 02, 2013 at 05:40:33PM +0100, Marek Polacek wrote:
>> On Mon, Dec 02, 2013 at 04:01:05PM +0100, Richard Biener wrote:
>> > On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek
>wrote:
>> > > Ping.
>> >
>> > Ok. (yay, oldest patch in my review queue ...)
>>
>> ;) tha
Kenneth Zadeck writes:
> see wide-int.h around line 290
>
> the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
> if the value coming in is an unsigned number of the type the represents
> that mode, don't we loose a bit?
That was the +1 mentioned here:
http://gcc.gnu.or
On 12/02/2013 03:34 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
see wide-int.h around line 290
the MAX_BITSIZE_MODE_ANY_INT is the largest mode on the machine. however
if the value coming in is an unsigned number of the type the represents
that mode, don't we loose a bit?
That was the
Hi,
On Mon, 2 Dec 2013 15:55:08Richard Biener wrote:
>
> On Mon, Nov 25, 2013 at 1:07 PM, Bernd Edlinger
> wrote:
>> Hello,
>>
>> I had forgotten to run the Ada test suite when I submitted the previous
>> version of this patch.
>> And indeed there were some Ada test cases failing because in Ada
...for optimization purpose. Should be done in one month.
Thanks!
--
Regards,
Tim Shen
commit cc7d58128e68455498d0257c4796cb70a9e24990
Author: tim
Date: Mon Dec 2 15:49:15 2013 -0500
2013-12-02 Tim Shen
* regex_compiler.h: Add todo comment.
* regex_executor.tcc: Likewi
On Mon, 2 Dec 2013, Tobias Burnus wrote:
> Looks good to me. (I fully concur that the _002d is ugly.)
Okay, so I applied this patch plus the one below to adjust
gcc-4.9/changes.html accordingly. (The first anchor there
is not stable, but for other reasons.)
Thanks for pushing for this fix!
Ger
The enclosed patch fixes a mismerge from google/gcc-4_7 to main. When
outputting a pubtype whose type has no skeleton section, it's DIE
offset should be from the comp_unit_die, instead of zero. Zero is
actually a place-holder for the end of the pubtypes.
Sterling
gcc/ChangeLog
2013-12-02 Sterlin
1 - 100 of 149 matches
Mail list logo
