On 02/26/2015 08:13 PM, Chen Gang S wrote:
> On 02/26/2015 04:04 PM, Chen Gang S wrote:
>> If check fails, genrecog needs to stop and report error, so can let the
>> issue be found in time. The implementation is referenced from "gcc/doc/
>> md.log":
&
On 02/26/2015 04:04 PM, Chen Gang S wrote:
> If check fails, genrecog needs to stop and report error, so can let the
> issue be found in time. The implementation is referenced from "gcc/doc/
> md.log":
>
> [...]
>
> whitespace
>Whitespace characters
If check fails, genrecog needs to stop and report error, so can let the
issue be found in time. The implementation is referenced from "gcc/doc/
md.log":
[...]
whitespace
Whitespace characters are ignored and can be inserted at any
position except the first. This enables each al
On 2/25/15 07:36, augustine.sterl...@gmail.com wrote:
> On Tue, Feb 24, 2015 at 2:05 PM, Max Filippov wrote:
>> Hi,
>>
>> On Tue, Feb 24, 2015 at 6:54 PM, Jeff Law wrote:
>>>
>>> You can tackle them in any order you wish. However, I suspect fixing the
>>> xtensa backend may be easier. I don't h
On 2/25/15 03:22, Jeff Law wrote:
> On 02/24/15 10:29, Chen Gang S wrote:
>>
>> So for me, I shall let genrecog report error instead of warning when it
>> find this issue, next.
> Yes, I think an error would be appropriate here. That way nobody has to
> debug
On 2/25/15 01:03, augustine.sterl...@gmail.com wrote:
> On Tue, Feb 24, 2015 at 9:05 AM, Chen Gang S wrote:
>>
>> - After this patch, it can continue compiling, but can we be sure that
>>it always generates correct code for execution?
>
> After this patch, it sho
On 2/24/15 23:54, Jeff Law wrote:
> On 02/23/15 18:33, Chen Gang S wrote:
>> OK, thanks. I shall try to finish within this month (although I am
>> not quite sure whether I can finish on time).
> No problem. Any contribution you can make in this area is appreciated.
>
OK, t
On 2/24/15 07:14, Jeff Law wrote:
> On 02/23/15 16:09, Steven Bosscher wrote:
>>>
>>>
>>> Which violate the rule for matching constraints.
>>
>> ...and should never have worked at all...
> Yup. It's only been fairly recently that we started statically checking MD
> files in any significant way --
It is for Bug65117, after this fix, ".i" file can be passed compiling.
- 'this_alternative_win' is not initialized before use it: for the
first looping 0, it initializes 'this_alternative_win[0]', but
'did_match' may use 'this_alternative_win[2]'.
- 'this_alternative' may be not initi
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest
braces around empty body in an 'if' statement [-Wempty-body]
__
On 1/31/15 19:49, Marek Polacek wrote:
> On Sat, Jan 31, 2015 at 05:13:53PM +0530, Prathamesh Kulkarni wrote:
>> On 31 January 2015 at 15:30, Chen Gang S wrote:
>>> On 1/31/15 16:53, Andreas Schwab wrote:
>>>> Chen Gang S writes:
>>>>
>>>>
On 1/31/15 16:53, Andreas Schwab wrote:
> Chen Gang S writes:
>
>> * gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Use braces
>> instead of macro's empty body to avoid xgcc warnings.
>
> It's actually an empty loop now.
>
Excuse me, I am not qu
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest
braces around empty body in an 'if' statement [-Wempty-body]
__
On 1/31/15 06:57, Jakub Jelinek wrote:
> On Sat, Jan 31, 2015 at 06:37:30AM +0800, Chen Gang S wrote:
>> The related warning (cross compile tile with --disable-threads):
>>
>> ../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
>> '__gcov_fork
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest
braces around empty body in an 'if' statement [-Wempty-body]
__
On 1/28/15 20:02, Andrew Burgess wrote:
> * Chen Gang S [2015-01-28 19:34:38 +0800]:
>
>> libiberty/argv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libiberty/argv.c b/libiberty/argv.c
>> index f2727e8..9fdd55b 10064
On 1/28/15 20:02, Andrew Burgess wrote:
> * Chen Gang S [2015-01-28 19:34:38 +0800]:
>
>> libiberty/argv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libiberty/argv.c b/libiberty/argv.c
>> index f2727e8..9fdd55b 10064
Need free each array elements, or may cause memory leak.
2015-01-28 Chen Gang
* argv.c (expandargv): Use freeargv() instead of free() to avoid
memory leak.
---
libiberty/argv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libiberty/argv.c b/libiberty/argv
On 1/27/15 05:56, Jeff Law wrote:
> On 01/22/15 13:50, Chen Gang S wrote:
>> On 01/23/2015 03:53 AM, Jeff Law wrote:
>>> On 01/22/15 12:42, Chen Gang S wrote:
>>>>
>>>>
>>>> Thank you very much for your help applying the 3 patches. :-)
>
On 1/26/15 03:50, Gerald Pfeifer wrote:
> On Friday 2015-01-23 04:50, Chen Gang S wrote:
>> And I want to consult: for passing assignment working flow, must I
>> make a patch which contents much code lines? (At present, my patches
>> are all trivial patch).
>
> No,
On 01/23/2015 03:53 AM, Jeff Law wrote:
> On 01/22/15 12:42, Chen Gang S wrote:
>>
>>
>> Thank you very much for your help applying the 3 patches. :-)
> No problem.
>
>>
>> After finish the assignment working flow, I guess, I may have the write
>> a
On 01/23/2015 12:41 AM, Jeff Law wrote:
> On 01/22/15 04:55, Chen Gang S wrote:
>> On 01/22/2015 02:46 AM, Mike Stump wrote:
>>> On Jan 21, 2015, at 1:54 AM, Chen Gang S wrote:
>>>> On 1/6/15 04:07, Jeff Law wrote:
>>>>>
>>>>>>
On 10/08/2014 10:52 PM, Richard Henderson wrote:
> On 10/08/2014 03:47 AM, Chen Gang wrote:
>> It passes "make -k check" under Darwin x86_64.
>>
>> 2014-10-07 Chen Gang
>>
>> * unwind-dw2-fde.h (last_fde): Use "(const fde *)" instead of
>> "(char *)" to avoid qualifier warning by 'xgcc
On 11/24/2014 04:24 PM, Jakub Jelinek wrote:
> On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote:
>> On 11/24/14 15:41, Jakub Jelinek wrote:
>>> On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote:
>>
>> [...]
>>
+else
+ pp_wide_int(&pretty_name,
+
On 01/22/2015 02:46 AM, Mike Stump wrote:
> On Jan 21, 2015, at 1:54 AM, Chen Gang S wrote:
>> On 1/6/15 04:07, Jeff Law wrote:
>>>
>>>>* toplev.c (init_local_tick): Process the failure when read
>>>>fails for random_seed.
>>> This is
On 1/6/15 04:07, Jeff Law wrote:
> On 12/28/14 21:04, Chen Gang S wrote:
>> When failure occurs, random_seed may not be 0, so need reset it to 0
>> manually, or will let the next call init_random_seed() incorrect. The
>> related warning:
>>
>>g++ -c -DTARG
On 1/20/15 10:11, Joseph Myers wrote:
> On Mon, 19 Jan 2015, Chen Gang S wrote:
>
>> On 12/31/2014 06:26 AM, Joseph Myers wrote:
>>> On Mon, 29 Dec 2014, Chen Gang S wrote:
>>>
>>>> And in honest, this year what I have done is really not quite well, n
On 12/31/2014 06:26 AM, Joseph Myers wrote:
> On Mon, 29 Dec 2014, Chen Gang S wrote:
>
>> And in honest, this year what I have done is really not quite well, next
>> year I should be improved: should scanning Bugzilla and try to fix the
>> existing issues (just like anot
On 1/13/15 01:32, Jeff Law wrote:
> On 01/12/15 10:01, Jeff Law wrote:
>> This indicates a violation of the type safety invariants we're adding to
>> GCC. Simply changing the code to use rtx rather than rtx_insn is
>> probably a step in the wrong direction.
>>
>> Part of the problem here is that R
The related commit "1a1ed14 config/h8300: Use rtx_insn" gives an extra
check for rtx, which will cause building libgcc break, after regress it,
it can still generate the correct assemble code.
The related information is below:
[root@localhost libgcc]# cat libgcc2.i
typedef int DItype __attrib
The related commit is "275e275 IPA ICF: target and optimization flags
comparison.". For sem_function::equals_private(), fix the typo issue,
and for target_opts_for_fn(), fix access NULL issue.
For cross compiling h8300, it will cause the issue below:
[root@localhost h8300]# cat fp-bit.i
__inl
On 1/6/15 04:07, Jeff Law wrote:
> On 12/28/14 21:04, Chen Gang S wrote:
>> When failure occurs, random_seed may not be 0, so need reset it to 0
>> manually, or will let the next call init_random_seed() incorrect. The
>> related warning:
>>
>>g++ -c -DTARG
Hello Maintainers:
It is finished with qemu today, it spends 13 days, the result is below,
please help check.
With qemu:
=== gcc Summary ===
# of expected passes83439
# of unexpected failures175
# of unexpected successes 1
# of
On 12/31/14 06:26, Joseph Myers wrote:
> On Mon, 29 Dec 2014, Chen Gang S wrote:
>
>> And in honest, this year what I have done is really not quite well, next
>> year I should be improved: should scanning Bugzilla and try to fix the
>> existing issues (just like another me
, next
year I should be improved: should scanning Bugzilla and try to fix the
existing issues (just like another members' suggestions to me).
Thanks.
On 12/29/14 12:04, Chen Gang S wrote:
> When failure occurs, random_seed may not be 0, so need reset it to 0
> manually, or will let th
When failure occurs, random_seed may not be 0, so need reset it to 0
manually, or will let the next call init_random_seed() incorrect. The
related warning:
g++ -c -DTARGET_NAME=\"parisc-gchen-linux\" -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwin
36 matches
Mail list logo
