with:
> --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.3.0
> Thread model: posix
>
Is this what gcc --version returns on your mac?
Paulo Matos
our division routine might be peculiar,
this division is also undefined.
The block skips the test for ((unsigned int) xx << 1 == 0 && yy == -1), should
we skip it if they're both zero as well? If not, what do you expect to get from
0/0 and 0%0?
Regards,
Paulo Matos
> -Original Message-
> From: Andrew Haley [mailto:a...@redhat.com]
> Sent: 28 July 2015 18:38
> To: Paulo Matos; gcc@gcc.gnu.org
> Subject: Re: Expectations for 0/0
>
> On 07/28/2015 04:40 PM, Paulo Matos wrote:
> > The block skips the test for ((unsig
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Paulo Matos
> Sent: 29 July 2015 10:12
> To: Andrew Haley; gcc@gcc.gnu.org
> Subject: RE: Expectations for 0/0
>
>
>
> > -Original Message-
pect these people to have?
I noticed I am not on the list (check commit r225509, user pmatos) either.
And thanks for your help on this transition.
--
Paulo Matos
the latest transition start?
--
Paulo Matos
On 27/08/15 16:56, Paulo Matos wrote:
I noticed I am not on the list (check commit r225509, user pmatos) either.
And thanks for your help on this transition.
r188804 | mkuvyrkov
for example.
--
Paulo Matos
On 18/03/16 15:02, Jonathan Wakely wrote:
>
> It's probably crashing because it's too large, so if you reduce it
> then it won't crash.
>
Would be curious to see what's the limit though, or if it depends on the
machine he's running GCC on.
--
Pau
irectly and I will give it a try.
Cheers,
--
Paulo Matos
> -Original Message-
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: 05 May 2014 10:11
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: jump_table_data and active_insn_p
>
> On Mon, Mar 17, 2014 at 12:51 PM, Paulo Matos wrote:
>
should be done outside of cc1. Other people have
thought about it and what you suggest is exactly the example found in OpenTuner
(http://opentuner.org/) announcement paper:
http://dspace.mit.edu/handle/1721.1/81958
The difference is that you don't compare .s files but instead choose the metric
based on the execution of the program on a test bench.
HTH,
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Basile Starynkevitch
> Sent: 20 May 2014 16:29
> To: Bruce Adams
> Cc: gcc@gcc.gnu.org
> Subject: Re: Roadmap for 4.9.1, 4.10.0 and onwards?
>
> On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams
use which sounded like a good idea.
Paulo Matos
Richard.
Jakub
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Andi Kleen
> Sent: 20 July 2014 22:29
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC version bikeshedding
>
> Paulo Matos writes:
> >
>
can't remember the option name
anymore. Can someone point me out to the option or a way to extract such
information?
Kind regards,
--
Paulo Matos
Apologies, wrong mailing list. Should have sent this to gcc-help.
On 06/11/2018 21:35, Paulo Matos wrote:
> Hi,
>
> I remember from awhile ago that there's some option (or there was...)
> that gets GCC to print some register allocation information together
> with the assembl
out information per basic block so it's not helpful for my
application. It would be great if -dA or -dP would show live out info as
well, but that doesn't seem to be the case at the moment.
--
Paulo Matos
think it's not impossible with all
that gcc provides, but there's certainly a fair amount of parsing of
these files, which is not ideal given their format might change under my
feet.
--
Paulo Matos
ebugging compute_block_dependencies in sched-rgn.c is
a massive pain. This calls sched_analyze which receives a struct
deps_desc that tracks the dependencies in the insn list. Is there a way
to pretty print this structure in gdb?
Kind regards,
--
Paulo Matos
On 14/02/2019 19:56, Jim Wilson wrote:
> On 2/14/19 3:13 AM, Paulo Matos wrote:
>> If I compile this with -O2, sched1 groups all loads and all stores
>> together. That's perfect. However, if I change TYPE to unsigned char and
>> recompile, the stores and loads are
On 15/02/2019 19:15, Jim Wilson wrote:
> On Thu, Feb 14, 2019 at 11:33 PM Paulo Matos wrote:
>> Are global variables not supposed to alias each other?
>> If I indeed do that, gcc still won't group loads and stores:
>> https://cx.rv8.io/g/rFjGLa
>
> I meant so
ed,
even if the sibcall was enabled? Or emit a sibcall even if it had been
disabled? Since the problem stems that at sibcall_ok_for_function_p I
don't have enough information to know what to do, is there a way to
decide this later on?
Thanks,
--
Paulo Matos
ented.
Kind regards,
--
Paulo Matos
As David pointed out in another email, I should have referenced the
buildbot homepage:
http://buildbot.net/
This is a framework with batteries included to build the kind of things
we want to have for testing. I certainly don't want to start a Jenkins
vs Buildbot discussion.
Kind regards,
--
Paulo Matos
On 20/09/17 19:14, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Paulo Matos wrote:
>
>> - buildbot can notify people if the build fails or if there's a test
>> regression. Notification can be sent to IRC and email for example. What
>> would people prefer to have as t
On 21/09/17 01:01, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 20, 2017 at 05:01:55PM +0200, Paulo Matos wrote:
>> This mail's intention is to gauge the interest of having a buildbot for
>> GCC.
>
> +1. Or no, +100.
>
>> - which machines we c
7;re a long way off that.
>
Yes, with GCC is slightly more complex but it should be possible to
calculate regressions even in the presence of non-zero FAILs.
Thanks for your comments,
--
Paulo Matos
ou
> can keep the false warnings as close to zero as possible.
>
Thanks. This is an interesting idea, however it might not be an easy
exercise to choose a subset of the tests for each compiled language that
PASS, are quick to run and representative. It would be interesting to
hear from some of the main developers which of the tests would be better
to run.
--
Paulo Matos
(or opening bugs, or
> whatever else might get our attention).
>
This is certainly one of the notifications that I think that need to be
implemented. If a patch breaks build or testing, the responsible parties
need to be informed, i.e. commiters, authors and possibly the list as well.
Thanks,
--
Paulo Matos
ix it myself. Except for the most trivial ones, it resulted several times
> in duplicated effort and waste of time. But of course, there are many
> more efficient gcc developers than me here :)
>
I think that's the point. I mean, as soon as a regression/build fail is
noticed, the buildbot should notify the right people of what happened
and those need to take notice and fix it or revert their patch. If
someone submits a patch, is notified it breaks GCC and does nothing,
then we have a bigger problem.
> Regarding the cpu power, maybe we could have free slots in
> some cloud? (travis? amazon?, )
>
Any suggestions on how to get these free slots? :)
Thanks for all the great suggestions and tips on your email.
--
Paulo Matos
On 22/09/17 01:23, Joseph Myers wrote:
> On Thu, 21 Sep 2017, Paulo Matos wrote:
>
>> Interesting suggestion. I haven't had the opportunity to look at the
>> compile farm. However, it could be interesting to have a mix of workers:
>> native compile farm one
at one point tried to read their
configuration. However, found the one by gdb simpler and used it as a
basis for what I have. I will look at their builders nonetheless to
understand what they build and how long they take.
> Anyway, it's good starting point what you did and I'm looking forward to more
> common use of the tool.
> Martin
>
Thanks,
--
Paulo Matos
On 25/09/17 13:14, Jonathan Wakely wrote:
> On 25 September 2017 at 11:13, Paulo Matos wrote:
>>> Apart from that, I fully agree with octoploid that
>>> http://toolchain.lug-owl.de/buildbot/ is duplicated effort which is running
>>> on GCC compile farm machin
#x27;ll inform you.
>
Thanks for the configuration file. I will take a look. Will eagerly wait
for news on the hardware request.
>
> Yes, duplication in way that it is (will be) same things. I'm adding author
> of the tool,
> hopefully we can unify the effort (and resources of course).
>
Great.
--
Paulo Matos
On 26/09/17 10:43, Martin Liška wrote:
> On 09/25/2017 02:49 PM, Paulo Matos wrote:
>> For benchmarks like Qt, blitz (as mentioned in the gcc testing page), we
>> can plot the build time of the benchmark and resulting size when
>> compiling for size.
>>
>
>
otify on the #gcc channel the results of the tests.
--
Paulo Matos
On 11/10/17 06:17, Markus Trippelsdorf wrote:
> On 2017.10.10 at 21:45 +0200, Paulo Matos wrote:
>> Hi all,
>>
>> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an update:
>>
>> * 3 x86_64 workers from CF are now installed;
>> * T
On 10/10/17 23:25, Joseph Myers wrote:
> On Tue, 10 Oct 2017, Paulo Matos wrote:
>
>> new test -> FAIL; New test starts as fail
>
> No, that's not a regression, but you might want to treat it as one (in the
> sense that it's a regression at
t; PASS: gcc.dg/Werror-13.c (test for errors, line )
>
> Actually, there are quite a few others like that
>
That actually surprised me.
I also see:
PASS: gcc.dg/Werror-13.c (test for errors, line )
PASS: gcc.dg/Werror-13.c (test for errors, line )
PASS: gcc.dg/Werror-13.c (test for errors, line )
PASS: gcc.dg/Werror-13.c (test for errors, line )
among others like it. Looks like a line number is missing?
In any case, it feels like the code I have to track this down needs to
be improved.
--
Paulo Matos
, that's useful. I will take a look.
--
Paulo Matos
eral ppc architectures and flavours as workers. We're
>> also
>> working with glibc community to improve it buildbot and to provide
>> workers
>> for builds on ppc.
>>
>> So, we'd like to know which platform you use for CI and how we can
>> cont
pdate in about a months time.
Kind regards,
--
Paulo Matos
much time implementing it, so I thought parsing the output
was just easier.
> If you file pull request(s) for the changes you've made in your copy of
> jamais-vu, I can take at look at merging them.
>
Happy to do so...
Will merge your changes into my fork first then.
Kind regards,
--
Paulo Matos
spect you are hitting a bug introduced recently, and fixed by:
> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00434.html
>
Wow, that's really useful. Thanks for letting me know.
--
Paulo Matos
o you know who this issue could be
raised with? FSF?
--
Paulo Matos
On 15/12/17 10:21, Christophe Lyon wrote:
> And the patch was committed last night (r255659), so maybe your builds now
> work?
>
Forgot to mention that. Yes, it built!
https://gcc-buildbot.linki.tools/#/builders/5
--
Paulo Matos
On 15/12/17 15:29, David Malcolm wrote:
> On Fri, 2017-12-15 at 10:16 +0100, Paulo Matos wrote:
>>
>> On 14/12/17 12:39, David Malcolm wrote:
>
> [...]
>
>>> It looks like you're capturing the textual output from "jv compare"
>>> and
>
y not use all of gcc113..gcc116.
>
> We do not have enough resources to dedicate machines to bots.
>
I have disabled gcc116.
Thanks,
--
Paulo Matos
On 15/12/17 10:21, Christophe Lyon wrote:
> On 15 December 2017 at 10:19, Paulo Matos wrote:
>>
>>
>> On 14/12/17 21:32, Christophe Lyon wrote:
>>> Great, I thought the CF machines were reserved for developpers.
>>> Good news you could add builders on
emental builds should always call configure,
just in case.
Thanks,
--
Paulo Matos
On 20/12/17 12:48, James Greenhalgh wrote:
> On Wed, Dec 20, 2017 at 10:02:45AM +0000, Paulo Matos wrote:
>>
>>
>> On 20/12/17 10:51, Christophe Lyon wrote:
>>>
>>> The recent fix changed the Makefile and configure script in libatomic.
>>> I gu
t
so I will definitely get it integrated on Monday and hopefully have
something to say afterwards.
Thanks for keeping me up-to-date with these changes.
--
Paulo Matos
ne using pysvn and the old and new
revision numbers.
I have started implementing this in my port. Would you consider merging it?
--
Paulo Matos
.. but... if we wait for that to happen to implement
something... :)
> Send a pull request (I've turned on travis CI on the github repository,
> so pull requests now automatically get tested on a bunch of different
> Python 3 versions).
>
Sure.
--
Paulo Matos
e to a different machine like gcc115
> or gcc116. As far as I know, they are identical.
>
Apologies for the clash on resources. Using gcc115 and gcc116 only now.
Kind regards,
--
Paulo Matos
On 02/23/10 19:12, Joern Rennecke wrote:
> Quoting "Paulo J. Matos" :
>> I have a situation in writing a specific condition on an md file.
>> I have an insn with 2 alternatives and then I use which_alternative to
>> generate the assembler code but if which_alternative == 1 I am
>> clobbering a regi
rent pseudos (since I have different pseudo regs) at different modes
(since the register might be set differently depending of the mode of the
comparison).
That seems to be the way to go.
Cheers,
Paulo Matos
Hi, sorry for the delay of this reply but just returned from paternity leave.
> -Original Message-
> From: Hans-Peter Nilsson [mailto:h...@bitrange.com]
> Sent: 05 March 2013 01:45
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Modeling predicate registers with
}
}
My question is, how does this work with recent gcc's and binutils'? If I use
-pg on gcc, will gcc stop outputting functions with isra, constprop, etc
suffixes and revert to clone suffixes or will it just use .?
Cheers,
Paulo Matos
> -Original Message-
> From: Hans-Peter Nilsson [mailto:h...@bitrange.com]
> Sent: 26 March 2013 17:43
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: RE: Modeling predicate registers with more than one bit
> >
> > What do you mean by source modes?
&g
> -Original Message-
> From: Joe Seymour [mailto:jseym...@codesourcery.com]
> Sent: 28 March 2013 15:17
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Clarification of cloned function names during profiling
>
>
> I had a patch committed to trunk gpr
> -Original Message-
> From: Joe Seymour [mailto:jseym...@codesourcery.com]
> Sent: 28 March 2013 15:37
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Clarification of cloned function names during profiling
>
> FWIW I fixed this for constprop because a cu
> -Original Message-
> From: Hans-Peter Nilsson [mailto:h...@bitrange.com]
> Sent: 26 March 2013 17:43
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: RE: Modeling predicate registers with more than one bit
>
> Unfortunately undocumented, but UTSL, for exampl
erver. :)
Cheers,
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Shakthi Kannan
> Sent: 11 April 2013 17:41
> To: gcc@gcc.gnu.org
> Subject: GCC Bugzilla database dump
>
> Hi,
>
> I would like
(passes.c:2379)
==30111==by 0x94BDFE: execute_pass_list(opt_pass*) (passes.c:2427)
==30111==by 0x94BE2F: execute_pass_list(opt_pass*) (passes.c:2428)
==30111==by 0x94BE2F: execute_pass_list(opt_pass*) (passes.c:2428)
==30111==by 0x68A254: expand_function(cgraph_node*) (cgraphunit.c:1640)
rmat [-Werror=format]
../../gcc/gcc/langhooks.c:462:31: error: too many arguments for format
[-Werror=format-extra-args]
I am unsure about how nls works and what's causing this since pp_printf seems
to be fine with %r, %R. I guess the important detail is that the string is
surrounded by _(...).
Any hints on this?
Paulo Matos
,
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 30 April 2013 14:33
> To: gcc@gcc.gnu.org
> Subject: disable-nls breaks build
>
> Hello,
>
> I just cloned gcc because of an
Turns out that this is a warning thrown by GCC that ends up as an error due to
--enable-werror-always.
Paulo Matos
> -Original Message-
> > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paulo
> > Matos
> > Sent: 30 April 2013 14:33
e. I am happy to patch
simplify_const_relational_operation if you agree with what I said.
Cheers,
Paulo Matos
> -Original Message-
> From: Mikael Pettersson [mailto:mi...@it.uu.se]
> Sent: 04 May 2013 11:51
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: BImode and STORE_VALUE_FLAG
>
>
> I can't comment on the code in question, but the backend for m68k may
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 07 May 2013 14:19
> To: Mikael Pettersson
> Cc: gcc@gcc.gnu.org
> Subject: RE: BImode and STORE_VALUE_FLAG
>
> In the meantime, where is FPmode
> -Original Message-
> From: Mikael Pettersson [mailto:mi...@it.uu.se]
> Sent: 04 May 2013 11:51
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: BImode and STORE_VALUE_FLAG
>
> I can't comment on the code in question, but the backend for m68k may be
s:
>
> > Further to this matter, can you explain the reasoning behind
> > vector-compare-1.c?
>
> Vector comparisons are different.
>
Right, my initial assumptions regarding vector comparisons were wrong and led
me to create a scalar comparison test for my problem that was broken.
Thanks,
Paulo Matos
the evaluation of ADJUST_BYTESIZE in -modes.def.
Is there a reason for it to be like this?
Cheers,
Paulo Matos
ster" "=p")
(eq:V2B4 (match_operand:V2SI 1 "register_operand")
(match_operand:V2SI 2 "general_operand")))]
...)
Is this something reasonable or will GCC simply choke since I am pushing the
limits of vector modes?
Paulo Matos
amylaar,
Do you recall how I can get those ARC branches, where they branches in official
GCC SVN?
Paulo Matos
> -Original Message-
> From: amyl...@spamcop.net [mailto:amyl...@spamcop.net]
> Sent: 17 May 2013 15:12
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subjec
Found, what it seems to be the most recent arc branch, arc-4_4-20090909-branch/.
http://gcc.gnu.org/viewvc/gcc/branches/arc-4_4-20090909-branch/
Paulo Matos
> -Original Message-
> From: amyl...@spamcop.net [mailto:amyl...@spamcop.net]
> Sent: 17 May 2013 15:12
> To: Paul
t_int 1))
(match_operand:BI 2 "const0" "")])
(label_ref (match_operand 3 "" ""))
(pc)))]
""...
but both of these alternatives don't seem to be supported as it causes an ICE
in patch_jump_insn.
What's the best way to deal with this situation? Is there any port out there
with similar issues?
Cheers,
Paulo Matos
but can't find a way to know this
unless I have something like an objdump for gimple.
If there's no tool out there to straightforwardly know this, what's the best
approach to find out if there's a problem written in the LTO stream?
Cheers,
Paulo Matos
at instruction is the only one on the ready list)
because it's possible that it can be paired with a later instruction in the
chain if issued simultaneously?
Cheers,
Paulo Matos
seems that the idea
is that 'issuing instructions as soon as possible is better' which might be
true for a single issue chip but a VLIW with multiple issue has to contend with
other problems.
Any thoughts on this?
Paulo Matos
> -Original Message-
> From: gcc-o
n unit does generate
incorrect output so I think there might be a bug lurking here.
Another thing I cannot grasp is that the test for inside_main completely
disappears. We do know n <= 2 after the loop but we have no information for
inside_main so I would assume we still need to test inside_main to know if we
should abort.
What do you think?
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 27 June 2013 14:52
> To: gcc@gcc.gnu.org
> Subject: Infinite recursion due to builtin pattern detection
>
> Another thing I cannot grasp is that
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 27 June 2013 15:02
> To: gcc@gcc.gnu.org
> Subject: RE: Infinite recursion due to builtin pattern detection
>
>
> Let me add that one of the
t seems to 'literally' break dependencies.
Is the behaviour of find_modifiable_mems a bug or somehow expected?
Cheers,
Paulo Matos
I could, of
course, create all of these by hand by defining 23 classes and define a single
constraint that matches these classes but I would like to know if there's
another way.
Cheers,
Paulo Matos
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: 05 July 2013 18:03
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Inter register constraints
>
> > have 64 registers that will give you 22 pairs. I could, of course,
> &g
ion I have.
Regards,
Paulo Matos
> -Original Message-
> From: Maxim Kuvyrkov [mailto:ma...@kugelworks.com]
> Sent: 16 July 2013 05:02
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Delay scheduling due to possible future multiple issue in VLIW
>
> Pa
index)
{
V8B b = __vec_put_v8b (a, value, index);
return b;
}
GCC complains with:
error: incompatible type for argument 1 of '__vec_put_v8b'
note: expected '__vector(8) signed char' but argument is of type 'V8B'
What's the correct way to create the intrinsics header?
--
Paulo Matos
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 29 August 2013 11:44
> To: gcc@gcc.gnu.org
> Subject: Prototypes for builtin functions
>
> Hi,
>
> I would like to hear how other archit
Hi,
Why do we have two macros in tree.h with seemingly the same semantics?
DECL_BUILT_IN and DECL_IS_BUILTIN?
--
Paulo Matos
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 03 September 2013 11:19
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Why DECL_BUILT_IN and DECL_IS_BUILTIN?
>
> On Tue, Sep 3, 2013 at 11:43 AM, Paulo Matos wrote:
&
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 03 September 2013 12:55
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Why DECL_BUILT_IN and DECL_IS_BUILTIN?
>
> DECL_IS_BUILTIN is true if the decl was created b
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of David
> Malcolm
> Sent: 09 October 2013 22:32
> To: gcc@gcc.gnu.org
> Subject: libgccjit.so: an embeddable JIT-compilation library based on GCC
>
> As some may have seen I posted a patch to gcc-
framework that allows this kind of testing
as opposed to the straightforward single test compilation?
Paulo Matos
> -Original Message-
> From: Jan Hubicka [mailto:hubi...@ucw.cz]
> Sent: 10 October 2013 17:24
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Testing ICEs resulting from profile directed optimization
>
> > Hi,
> >
> > I have found an ICE
varasm.c:415
This is obviously another thing I still have to understand why it's happening.
The testcase is still too big (1Mb) and I haven't reproduced it with any
upstream port so I am not reporting a bug yet.
For the patch attached:
2013-10-11 Paulo Matos
* tree.c (tree_ch
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 11 October 2013 13:47
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Invalid tree node causes segfault in diagnostic
>
>
> Hmm. We have several places acces
> -Original Message-
> From: Jan Hubicka [mailto:hubi...@ucw.cz]
> Sent: 11 October 2013 23:23
> To: Paulo Matos
> Cc: Jan Hubicka; gcc@gcc.gnu.org
> Subject: Re: Testing ICEs resulting from profile directed optimization
>
> You can use dg-additional-sources for
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 14 October 2013 09:53
> To: Jan Hubicka
> Cc: gcc@gcc.gnu.org
> Subject: RE: Testing ICEs resulting from profile directed optimization
>
&
1 - 100 of 182 matches
Mail list logo
