On Sun, Aug 5, 2018 at 12:48 AM, H.J. Lu wrote:
> On Sat, Aug 04, 2018 at 11:48:15PM +0200, Uros Bizjak wrote:
>> On Sat, Aug 4, 2018 at 9:49 PM, H.J. Lu wrote:
>> > On Sat, Aug 4, 2018 at 12:09 PM, Uros Bizjak wrote:
>> >> On Sat, Aug 4, 2018 at 3:59 PM, H.J. Lu wrote:
>> >>> On Sat, Aug 4, 20
Hi,
I would like to do a minor tweak to the patch.
While staring at the other patch I realized that I should
better pass size and not thissize to the check
function, instead of making use of how thissize is
computed using MIN above. This means that this condition
+ if ((unsigned)len != size &&
On Sun, Aug 5, 2018 at 12:15 AM, Uros Bizjak wrote:
>>> OK, but please add a comment, so in the future we will still know the
>>> purpose of the magic number.
>>>
>>
>> Like this?
>>
>> H.J.
>> ---
>> cfun->machine->max_used_stack_alignment is used to decide how stack frame
>> should be aligned.
Hi all,
the attached patch fixes PR 86116 by splitting up the function
'compare_type' into two variants: One that is used for checking
generic interfaces and operators (keeping the old name), and one that
is used for checking dummy functions and procedure pointer assignments
('compare_type_charact
On Tue, Jul 24, 2018 at 6:49 AM, Marek Polacek wrote:
> On Tue, Jul 03, 2018 at 04:27:33PM -0400, Jason Merrill wrote:
>> On Tue, Jul 3, 2018 at 3:41 PM, Jason Merrill wrote:
>> > On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
>> >> On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill w
OK
On Sat, Aug 4, 2018 at 2:18 AM, Jakub Jelinek wrote:
> Hi!
>
> Some time ago, I've moved the poor man's offsetof recognizing hack to
> cp_fold. On the following testcase that means we don't fold it early during
> parsing. Now, if we try to evaluate those inside of constexpr contexts
> with !
OK.
On Sat, Aug 4, 2018 at 1:54 AM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, for valid structured bindings this patch should be
> unnecessary, because the identifiers from the structured binding shouldn't
> be used in the initializer of the structured binding, but for invalid source
On 08/05/2018 12:51 AM, Bernd Edlinger wrote:
> On 08/04/18 22:52, Martin Sebor wrote:
>> On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
> If I call this with foo (2, 1), do you still claim it is not valid C?
String funct
On 08/05/2018 12:08 AM, Bernd Edlinger wrote:
> On 08/04/18 23:56, Martin Sebor wrote:
>> On 08/03/2018 01:00 AM, Jeff Law wrote:
>>> On 07/24/2018 05:18 PM, Bernd Edlinger wrote:
On 07/24/18 23:46, Jeff Law wrote:
> On 07/24/2018 01:59 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> Th
On 8/4/18, Martin Sebor wrote:
> The sprintf handling of wide characters neglects to consider
> that calling the function may fail due to a conversion error
> (when the wide character is invalid or not representable in
> the current locale). The handling also misinterprets
> the POSIX %S wide str
Hi!
My other patch with adds assertions to varasm.c regarding correct
nul termination of sting literals did make these incorrect string
constants in JIT frontend fail.
The string constants are not nul terminated if their length exceeds
200 characters. The test cases do not use strings of that s
Hi everyone,
this patch reduces calls to logarithm functions by
merging log a + log b => log a*b and
log a - log b => log a/b
This is my first contribution, so have I forgot something?
I think a contributor agreement is not needed since it's
a 20-line patch, and I may not have time to contribute i
On 08/04/2018 02:52 PM, Martin Sebor wrote:
> On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid C?
>>>
>>> String functions like strlen operate on character strings st
On August 4, 2018 10:52:02 PM GMT+02:00, Martin Sebor wrote:
>On 08/03/2018 01:43 AM, Jakub Jelinek wrote:
>> On Thu, Aug 02, 2018 at 09:59:13PM -0600, Martin Sebor wrote:
If I call this with foo (2, 1), do you still claim it is not valid
>C?
>>>
>>> String functions like strlen operate on ch
On Sun, 5 Aug 2018, MCC CS wrote:
this patch reduces calls to logarithm functions by
merging log a + log b => log a*b and
this makes sense.
+ /* x * logN(a) + y * logN(b) -> x * y * logN(a * b). */
this on the other hand... Can you explain the math?
--
Marc Glisse
> merging log a + log b => log a*b and
Maybe a*b could overflow, while adding the logarithms would not?
Bernd.
On Aug 05 2018, Marc Glisse wrote:
> On Sun, 5 Aug 2018, MCC CS wrote:
>
>> this patch reduces calls to logarithm functions by
>> merging log a + log b => log a*b and
>
> this makes sense.
Even when a*b may overflow?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578
On Sun, 5 Aug 2018, Bernd Edlinger wrote:
merging log a + log b => log a*b and
Maybe a*b could overflow, while adding the logarithms would not?
Well, that's a discussion that happens every time a new transformation is
added to -funsafe-math-optimizations (I assume this one is under that
um
On 08/05/18 20:35, Marc Glisse wrote:
> On Sun, 5 Aug 2018, Bernd Edlinger wrote:
>
>>> merging log a + log b => log a*b and
>>
>> Maybe a*b could overflow, while adding the logarithms would not?
>
> Well, that's a discussion that happens every time a new transformation is
> added to -funsafe-ma
> Sent: Sunday, August 05, 2018 at 8:17 PM
> From: "Marc Glisse"
> To: "MCC CS"
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Optimize logarithm addition and subtraction
>
> On Sun, 5 Aug 2018, MCC CS wrote:
>
> > this patch reduces calls to logarithm functions by
> > merging log a + log
On Sun, 5 Aug 2018, MCC CS wrote:
Besides, if you think optimizing
/* logN(a) + logN(b) -> logN(a * b) */
would be enough, without the coefficients,
here's a simpler patch:
Index: gcc/match.pd
===
--- gcc/match.pd(revision 2633
On 08/03/2018 12:16 PM, Jeff Law wrote:
On 07/27/2018 03:44 PM, Eric Botcazou wrote:
Apropos of the discussion about improving the docs for
TARGET_CUSTOM_FUNCTION_DESCRIPTORS in the context of the C-SKY port
submission,
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01454.html
here is the patch
This is the third iteration of the C-SKY port patch set. The previous
versions were posted here:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01289.html
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01861.html
Changes since V2 are:
- The cse_cc pass is gone, replaced by a no-op move of the c
2018-08-05 Jojo
Huibin Wang
Sandra Loosemore
Chung-Lin Tang
Andrew Jenner
C-SKY port: Configury
gcc/
* config.gcc (csky-*-*): New.
* configure.ac: Add csky to targets for dwarf2 debug_line support.
* configure: Regenerated.
contrib/
* config-list.mk (LIST):
2018-08-05 Jojo
Huibin Wang
Sandra Loosemore
Chung-Lin Tang
C-SKY port: Backend implementation
gcc/
* config/csky/*: New.
* common/config/csky/*: New.
csky-gcc-2.patch.gz
Description: application/gzip
2018-08-05 Sandra Loosemore
C-SKY port: Documentation
gcc/
* doc/extend.texi (C-SKY Function Attributes): New section.
* doc/invoke.texi (Option Summary): Add C-SKY options.
(C-SKY Options): New section.
* doc/md.texi (Machine Constraints): Document C-SKY constraints.
diff --git a/gcc/
2018-08-05 Sandra Loosemore
Chung-Lin Tang
Xianmiao Qu
C-SKY port: Testsuite
gcc/testsuite/
* g++.dg/Wno-frame-address.C: Adjust for C-SKY.
* g++.dg/torture/type-generic-1.C: Likewise.
* gcc.c-torture/compile/2804-1.c: Likewise.
* gcc.c-torture/execute/20101011-1.c: Li
2018-08-05 Jojo
Huibin Wang
Sandra Loosemore
Chung-Lin Tang
C-SKY port: libgcc
libgcc/
* config.host: Add C-SKY support.
* config/csky/*: New.
diff --git a/libgcc/config.host b/libgcc/config.host
index 18cabaf..bd4ef1e 100644
--- a/libgcc/config.host
+++ b/libgcc/conf
28 matches
Mail list logo
