Re: [buildrobot] sparc64-linux broken
On Mon, Apr 21, 2014 at 05:51:04PM -0400, Michael Meissner wrote:
> On Mon, Apr 21, 2014 at 08:02:39PM +0200, Jakub Jelinek wrote:
> > Sure, we could change this to use mode_size_inline ((enum machine_mode)
> > (MODE))
> > in the macro instead, but I'd say for GCC codebase it is better if we fix
> > the few users of these macros that pass an int rather than enum machine_mode
> > to these macros.
>
> I fixed the powerpc (PR 60876), and while it would have been nice to have
> tested this against more backends, it was fairly simple to go through the
> GET_MODE_SIZE's and make them type correct. For the PowerPC, it tended to be
> in code of the form:
>
> for (m = 0; m < NUM_MACHINE_MODES; ++m)
> {
> // ...
> if (GET_MODE_SIZE (m)) ...
> }
>
> and the fix was to do something like:
>
> for (m = 0; m < NUM_MACHINE_MODES; ++m)
> {
> enum machine_mode m2 = (enum machine_mode)m;
> // ...
> if (GET_MODE_SIZE (m2)) ...
> }
>
> It reminds me when I was in the original ANSI C committee that made the 1989
> ANSI and 1990 ISO C standards, we debated making enum's more first class
> citizens, so you could do ++/-- on them, but the committee tended to be
> divided
> into 3 camps, one that wanted to delete enums altogether, one that wanted them
> as int constants, and one that wanted more type checking.
I've committed following fix as obvious after testing it with a
x86_64->sparc64-linux cross-compiler.
2014-04-22 Jakub Jelinek
PR target/60910
* config/sparc/sparc.c (sparc_init_modes): Pass enum machine_mode
value instead of int to GET_MODE_CLASS and GET_MODE_SIZE macros.
--- gcc/config/sparc/sparc.c.jj 2014-04-17 14:49:04.0 +0200
+++ gcc/config/sparc/sparc.c2014-04-22 09:21:52.192036251 +0200
@@ -4821,47 +4821,48 @@ sparc_init_modes (void)
for (i = 0; i < NUM_MACHINE_MODES; i++)
{
- switch (GET_MODE_CLASS (i))
+ enum machine_mode m = (enum machine_mode) i;
+ switch (GET_MODE_CLASS (m))
{
case MODE_INT:
case MODE_PARTIAL_INT:
case MODE_COMPLEX_INT:
- if (GET_MODE_SIZE (i) < 4)
+ if (GET_MODE_SIZE (m) < 4)
sparc_mode_class[i] = 1 << (int) H_MODE;
- else if (GET_MODE_SIZE (i) == 4)
+ else if (GET_MODE_SIZE (m) == 4)
sparc_mode_class[i] = 1 << (int) S_MODE;
- else if (GET_MODE_SIZE (i) == 8)
+ else if (GET_MODE_SIZE (m) == 8)
sparc_mode_class[i] = 1 << (int) D_MODE;
- else if (GET_MODE_SIZE (i) == 16)
+ else if (GET_MODE_SIZE (m) == 16)
sparc_mode_class[i] = 1 << (int) T_MODE;
- else if (GET_MODE_SIZE (i) == 32)
+ else if (GET_MODE_SIZE (m) == 32)
sparc_mode_class[i] = 1 << (int) O_MODE;
else
sparc_mode_class[i] = 0;
break;
case MODE_VECTOR_INT:
- if (GET_MODE_SIZE (i) == 4)
+ if (GET_MODE_SIZE (m) == 4)
sparc_mode_class[i] = 1 << (int) SF_MODE;
- else if (GET_MODE_SIZE (i) == 8)
+ else if (GET_MODE_SIZE (m) == 8)
sparc_mode_class[i] = 1 << (int) DF_MODE;
else
sparc_mode_class[i] = 0;
break;
case MODE_FLOAT:
case MODE_COMPLEX_FLOAT:
- if (GET_MODE_SIZE (i) == 4)
+ if (GET_MODE_SIZE (m) == 4)
sparc_mode_class[i] = 1 << (int) SF_MODE;
- else if (GET_MODE_SIZE (i) == 8)
+ else if (GET_MODE_SIZE (m) == 8)
sparc_mode_class[i] = 1 << (int) DF_MODE;
- else if (GET_MODE_SIZE (i) == 16)
+ else if (GET_MODE_SIZE (m) == 16)
sparc_mode_class[i] = 1 << (int) TF_MODE;
- else if (GET_MODE_SIZE (i) == 32)
+ else if (GET_MODE_SIZE (m) == 32)
sparc_mode_class[i] = 1 << (int) OF_MODE;
else
sparc_mode_class[i] = 0;
break;
case MODE_CC:
- if (i == (int) CCFPmode || i == (int) CCFPEmode)
+ if (m == CCFPmode || m == CCFPEmode)
sparc_mode_class[i] = 1 << (int) CCFP_MODE;
else
sparc_mode_class[i] = 1 << (int) CC_MODE;
Jakub
Re: [RFC] Detect most integer overflows.
On Tue, Apr 15, 2014 at 03:41:53PM +0200, Richard Biener wrote: > On Sat, Apr 12, 2014 at 12:53 AM, Hannes Frederic Sowa > wrote: > > Hi! > > > > On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote: > >> For a "quick" GCC implementation of the builtins you could expand > >> them to a open-coded sequence during gimplification. But due to > >> the issues pointed out above I'm not sure it is the best interface > >> to support (though now the names are taken). > > > > I played around with gcc internals for the first time today and came > > up with this. As this is my first patch to gcc I am very happy to hear > > feedback. Thanks! > > Looks reasonable for a first patch to GCC! New functions miss a > toplevel comment and the big conditionals would benefit from a comment > spelling out in a more readable way what is tested. I'll do that. > Note that you generally should use fold_buildN instead of buildN. Thanks for the hint. > And the patch lacks additions to gcc/doc/extend.texi documenting > these builtins. The patch was merely meant as a PoC to see whether the approach of rewriting the code during gimplification is still acceptable and thus only focused on that part. In the end I want to provide a complete patch which adds multiplication checks and also updates the documentation. > And then we come to the issue that a patch of this size requires a > copyright assignment with the FSF - do you have one covering GCC work? No, not yet, but I'll read up on it and will follow-up on that with the relevant persons. Thank you, Hannes
Re: [RFC] Detect most integer overflows.
On Thu, Apr 17, 2014 at 04:20:06PM +0200, Ondřej Bílka wrote: > On Sat, Apr 12, 2014 at 12:53:45AM +0200, Hannes Frederic Sowa wrote: > > Hi! > > > > On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote: > > > For a "quick" GCC implementation of the builtins you could expand > > > them to a open-coded sequence during gimplification. But due to > > > the issues pointed out above I'm not sure it is the best interface > > > to support (though now the names are taken). > > > > I played around with gcc internals for the first time today and came > > up with this. As this is my first patch to gcc I am very happy to hear > > feedback. Thanks! > > > Did you looked at resulting assembly for simple expressions? I had a look but didn't care at all at this point in time. I guess the best way to deal with this in the end is to make the check processor dependent to use overflow/carry flags to check if an overflow/wraparound happend. The addv4 primitives which came in with asan might be helpful for this. > Also Paul Eggert suggested at another list[1] to implement these with > 128bit arithmetic which gcc can optimize quite well, it uses overflow > flag as check. I thought about that but wasn't sure if 128 bit arithmetic works on all platforms and on freestanding binaries. > Could these builtins use a 128bit arithmetic as well? I guess it would be possible and if it is available on all platforms I could certainly switch to those. > P.S. > > A generated code is affected by generic gcc bug that gcc uses > conditional move instruction even when branch is very unlikely and > jump would be faster. > > [1] https://sourceware.org/ml/libc-alpha/2013-12/msg00084.html Thanks for the pointer! I'll play around and will post a new patch in the not too distant future. ;) Bye, Hannes
GCC 4.9.0 Released
One year and one month passed from the time when the last major version of the GNU Compiler Collection has been announced, so it is the time again to announce a new major GCC release, 4.9.0. GCC 4.9.0 is a major release containing substantial new functionality not available in GCC 4.8.x or previous GCC releases. The Local Register Allocator, introduced in GCC 4.8.0 for ia32 and x86-64 targets only, is now used also on the Aarch64, ARM, S/390 and ARC targets by default and on PowerPC and RX targets optionally. There have been substantial improvements to C++ devirtualization and various scalability bottlenecks in the interprocedural optimizations and LTO have been fixed. Support for various C++14 additions have been added to the C++ Front End, on the standard C++ library side the most important addition is support for the C++11 . GCC 4.9.0 supports the OpenMP 4.0 standard for C and C++, and a partial implementation of the Cilk Plus extension for data and task parallelism. Various kinds of undefined behaviors in programs can be now diagnosed at runtime through Undefined Behavior Sanitizer. Support for the new little-endian powerpc64le-linux platform has been added, which defaults to the new PowerPC ELFV2 ABI. On x86-64 and ia32, support for the AVX-512 instruction set has been implemented. See http://gcc.gnu.org/gcc-4.9/changes.html for more information about changes in GCC 4.9. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.9.0/ subdirectory. If you encounter difficulties using GCC 4.9, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. Driving a leading free software project such as GNU Compiler Collection would not be possible without support from its many contributors. Not to only mention its developers but especially its regular testers and users which contribute to its high quality. The list of individuals is too large to thank individually!
GCC 4.9.1 Status Report (2014-04-22)
Status == GCC 4.9.0 has been released, the branch is now open again under the usual release branch rules (regression fixes and documentation fixes only). The next release, 4.9.1, should be released in about two or three months from now, unless something very urgent forces us to release earlier. Quality Data Priority # Change from Last Report --- --- P10 0 P2 78 + 2 P3 17 + 11 --- --- Total95 + 13 Previous Report === http://gcc.gnu.org/ml/gcc/2014-04/msg00091.html The next report will be sent by Joseph.
Re: [RFC, LRA] Incorrect subreg resolution?
Richard Sandiford wrote:
Returning to this old thread...
Richard Sandiford writes:
Tejas Belagod writes:
When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
seem to handle subregs like
(subreg:DI (reg:TF hard_reg) 8)
on hard registers where the subreg byte offset is unaligned to a hard register
boundary(16 for AArch64). It seems to quietly ignore the 8 and resolves this to
incorrect an hard register during reload.
When I compile this test with -O3,
long double
cl (long double x, long double y)
{
return __builtin_copysignl (x, y);
}
cs.c.213r.ira:
(insn 26 10 33 2 (set (reg:DI 87 [ y+8 ])
(subreg:DI (reg:TF 33 v1 [ y ]) 8)) cs.c:4 34 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:TF 33 v1 [ y ])
(nil)))
(insn 33 26 35 2 (set (reg:TF 93)
(reg:TF 32 v0 [ x ])) cs.c:4 40 {*movtf_aarch64}
(expr_list:REG_DEAD (reg:TF 32 v0 [ x ])
(nil)))
(insn 35 33 34 2 (set (reg:DI 92 [ x+8 ])
(subreg:DI (reg:TF 93) 8)) cs.c:4 34 {*movdi_aarch64}
(nil))
(insn 34 35 23 2 (set (reg:DI 91 [ x ])
(subreg:DI (reg:TF 93) 0)) cs.c:4 34 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:TF 93)
(nil)))
cs.c.214r.reload
(insn 26 10 33 2 (set (reg:DI 2 x2 [orig:87 y+8 ] [87])
(reg:DI 33 v1 [ y+8 ])) cs.c:4 34 {*movdi_aarch64}
(nil))
(insn 33 26 35 2 (set (reg:TF 0 x0 [93])
(reg:TF 32 v0 [ x ])) cs.c:4 40 {*movtf_aarch64}
(nil))
(insn 35 33 34 2 (set (reg:DI 1 x1 [orig:92 x+8 ] [92])
(reg:DI 1 x1 [+8 ])) cs.c:4 34 {*movdi_aarch64}
(nil))
(insn 34 35 8 2 (set (reg:DI 0 x0 [orig:91 x ] [91])
(reg:DI 0 x0 [93])) cs.c:4 34 {*movdi_aarch64}
(nil))
.
You can see the changes to insn 26 before and after reload - the SUBREG_BYTE
offset of 8 seems to have been translated to v0 instead of v0.d[1] by
get_hard_regno ().
What's interesting here is that the SUBREG_BYTE that is generated for
(subreg:DI (reg:TF 33 v1 [ y ]) 8)
isn't aligned to a hard register boundary on SIMD regs where UNITS_PER_VREG for
AArch64 is 16. Therefore when this subreg is resolved, it resolves to v1 instead
of v1.d[1]. Is this something going wrong in LRA or is this a more fundamental
problem with generating subregs of hard regs with unaligned subreg byte offsets?
The same subreg on a pseudo works OK because in insn 33, the TF mode is
allocated integer registers and all is well.
I think this is the same problem that was being discussed for x86
after your no-op vec-select patch:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00801.html
and long following thread.
I'd still like to solve this in a target-independent way rather than add
an offset to CANNOT_CHANGE_MODE_CLASS, but I haven't had time to look at
it...
FWIW, here's one possible approach. The main part is to make the
invalid_mode_change code calculate a set of registers that are either
(a) invalid for the pseudo mode to begin with or (b) do not allow one
of the subregs to be taken (as calculated by simplify_subreg_regno,
which includes the original CANNOT_CHANGE_MODE_CLASS check).
One concern might be about compilation speed when collecting this info.
OTOH, the query is now genuinely constant time, whereas the old bitmap
test was O(num-pseudos) in the worst case. It might also be possible
to speed things up by walking the subregs using the DF information,
if it's up-to-date at this point (haven't checked). It would also be
possible to give an ID to each (inner mode, outer mode, byte) combination
and lazily cache the invalid register set for each one.
I went through the other uses of CANNOT_CHANGE_MODE_CLASS. Most of them
were checking for lowpart mode changes so look safe. The exception was
combine.c:subst.
This is really four patches squashed into one, but it's not ready to be
submitted yet. Was just wondering whether this solved your problem.
Hi Richard,
Sorry for the delay in replying to this.
Thanks for this patch - it bootstraps and regresses fine for aarch64. It also
regresses OK on ARM.
Your patch also fixes issues I was seeing when I undefined C_C_M_C for aarch64
which is what I was mostly troubled by (copysign1 regression et. al.)
Many Thanks,
Tejas.
Thanks,
Richard
*** /tmp/OCSP7f_combine.c 2014-03-11 07:34:37.928138693 +
--- gcc/combine.c 2014-03-10 21:39:09.428718086 +
*** subst (rtx x, rtx from, rtx to, int in_d
*** 5082,5096
)
return gen_rtx_CLOBBER (VOIDmode, const0_rtx);
- #ifdef CANNOT_CHANGE_MODE_CLASS
if (code == SUBREG
&& REG_P (to)
&& REGNO (to) < FIRST_PSEUDO_REGISTER
! && REG_CANNOT_CHANGE_MODE_P (REGNO (to),
! GET_MODE (to),
! GET_MODE (x)))
Re: [buildrobot] sparc64-linux broken
On 04/22/2014 12:26 AM, Jakub Jelinek wrote:
> I've committed following fix as obvious after testing it with a
> x86_64->sparc64-linux cross-compiler.
>
> 2014-04-22 Jakub Jelinek
>
> PR target/60910
> * config/sparc/sparc.c (sparc_init_modes): Pass enum machine_mode
> value instead of int to GET_MODE_CLASS and GET_MODE_SIZE macros.
Here's an additional change that I'd had in my tree.
Sorry about not getting it committed last night.
r~
* config/sparc/sparc.c (sparc_init_modes): Hoist GET_MODE_SIZE
computation to the top of the loop.
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index bf118e0..7f16609 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -4822,41 +4822,43 @@ sparc_init_modes (void)
for (i = 0; i < NUM_MACHINE_MODES; i++)
{
enum machine_mode m = (enum machine_mode) i;
+ unsigned int size = GET_MODE_SIZE (m);
+
switch (GET_MODE_CLASS (m))
{
case MODE_INT:
case MODE_PARTIAL_INT:
case MODE_COMPLEX_INT:
- if (GET_MODE_SIZE (m) < 4)
+ if (size < 4)
sparc_mode_class[i] = 1 << (int) H_MODE;
- else if (GET_MODE_SIZE (m) == 4)
+ else if (size == 4)
sparc_mode_class[i] = 1 << (int) S_MODE;
- else if (GET_MODE_SIZE (m) == 8)
+ else if (size == 8)
sparc_mode_class[i] = 1 << (int) D_MODE;
- else if (GET_MODE_SIZE (m) == 16)
+ else if (size == 16)
sparc_mode_class[i] = 1 << (int) T_MODE;
- else if (GET_MODE_SIZE (m) == 32)
+ else if (size == 32)
sparc_mode_class[i] = 1 << (int) O_MODE;
else
sparc_mode_class[i] = 0;
break;
case MODE_VECTOR_INT:
- if (GET_MODE_SIZE (m) == 4)
+ if (size == 4)
sparc_mode_class[i] = 1 << (int) SF_MODE;
- else if (GET_MODE_SIZE (m) == 8)
+ else if (size == 8)
sparc_mode_class[i] = 1 << (int) DF_MODE;
else
sparc_mode_class[i] = 0;
break;
case MODE_FLOAT:
case MODE_COMPLEX_FLOAT:
- if (GET_MODE_SIZE (m) == 4)
+ if (size == 4)
sparc_mode_class[i] = 1 << (int) SF_MODE;
- else if (GET_MODE_SIZE (m) == 8)
+ else if (size == 8)
sparc_mode_class[i] = 1 << (int) DF_MODE;
- else if (GET_MODE_SIZE (m) == 16)
+ else if (size == 16)
sparc_mode_class[i] = 1 << (int) TF_MODE;
- else if (GET_MODE_SIZE (m) == 32)
+ else if (size == 32)
sparc_mode_class[i] = 1 << (int) OF_MODE;
else
sparc_mode_class[i] = 0;
Re: [buildrobot] sparc64-linux broken
On Tue, Apr 22, 2014 at 07:55:00AM -0700, Richard Henderson wrote: > On 04/22/2014 12:26 AM, Jakub Jelinek wrote: > > I've committed following fix as obvious after testing it with a > > x86_64->sparc64-linux cross-compiler. > > > > 2014-04-22 Jakub Jelinek > > > > PR target/60910 > > * config/sparc/sparc.c (sparc_init_modes): Pass enum machine_mode > > value instead of int to GET_MODE_CLASS and GET_MODE_SIZE macros. > > Here's an additional change that I'd had in my tree. > Sorry about not getting it committed last night. Thanks and sorry for rushing up the fix. > * config/sparc/sparc.c (sparc_init_modes): Hoist GET_MODE_SIZE > computation to the top of the loop. Jakub
Re: GCC 4.9.0 Released
On 22 April 2014 14:10, Jakub Jelinek wrote: > One year and one month passed from the time when the last major version > of the GNU Compiler Collection has been announced, so it is the time again > to announce a new major GCC release, 4.9.0. > > GCC 4.9.0 is a major release containing substantial new > functionality not available in GCC 4.8.x or previous GCC releases. > > The Local Register Allocator, introduced in GCC 4.8.0 for ia32 and > x86-64 targets only, is now used also on the Aarch64, ARM, S/390 > and ARC targets by default and on PowerPC and RX targets optionally. Actually, I had switched the default for ARC -mlra back to off because of PR rtl-optimization/55464 - not being able to configure libgcc is a show-stopper. I just tried the testcase to see what it does now, and the -mlra option is not even accepted. cc1 complains that -mlra is valid for but not for C. It turns out that the comment I put into arc.opt about why I switched the default was interpreted as part of the option description. Moving the comment allowed -mlra to be accepted, and the PR55464 testcase no longer causes an ICE. In fact, when I flip the default back to lra, it can configure libgcc, however, it still fails to build it - throwing an ICE at lra-constraints.c:3492 while trying to compile libgcc2.c to __gcc_bcmp.o for arc600 .
C PreProcessor GCC-specific features ideas.
I've got ideas for improve the preprocessor with specific features. The basic idea is to make the preprocessing language a complete programming language. That can be useful for includes things like Autotools and advanced Makefiles directly in the source code, and have just a tiny Makefile for compile. 0. Multiple defines on one variable. The "constants" will be transformed in "variables". 1. Assertions #assert will be transformed in : #if ! # #endif (And will be of course re-preprocessed.) 2. Calculating #calculate will be transformed in : #define (And will be of course re-preprocessed.) Example : #calculate N 1+1 will be transformed in : #define N 2 (That can works with any type : bools, etc.) 3. Executing shell commands #exec-sh The shell command while be executed and the result (stdout) of the shell command will be putted in 4. Read and write files #read-file will put the content of the file in , and if is modified, is modified too.
[GSoC] Generating patterns from meta-description
Hi,
Thank-you for selecting me for GSoC 2014, I am looking forward to
working with GCC community. I am grateful to Richard Biener and Diego Novillo
for choosing to mentor me for this project. Unfortunately, I couldn't
reply last week because I am in the middle of university exams, I
apologize for that.
* Time Commitments:
I have university exams up-to 5th May, and couple of exams on 24th may
and 27th may. Thereafter I am completely free, and can commit up-to
50 hours per week on average.
* Few questions regarding genmatch:
a) Lexical analysis and Parsing:
I believe this is already in place. We would continue with
hand-written recursive descent parser.
b) Intermediate representations:
For representing "matching" operands
we will need to use a decision tree (I am not yet decided on how it would be
implemented). For "simplification" operands, we can use AST (struct operand).
For example:
(match_and_simplify
(negate (negate @0))
@0)
(match_and_simplify
(negate (bit_not @0))
(minus @0 { integer_one_node; }))
There would be 2 AST's to represent @0 and (minus @0 { integer_one_node; } ).
And one decision tree representing matching operands for both expressions.
Something like:
negate
negateminus
@0 @0 { integer_one_node' }
c) Code generation:
Currently code-generation is done for gimple by walking the AST by
calling .gen_gimple_match and .gen_gimple_transform on each node.
Would it be a good idea to separate code gen interfaces
(.gen_gimple_match and .gen_gimple_transform) from AST ?
We would be having two IR's (decision-tree and AST) and two targets
(generic and gimple). Code-generation for pattern-matching shall be
performed by tree-walk
of decision tree and for transforms by tree-walk of AST.
d) Handling Commutative operators:
Should it be hard-coded in genmatch which operators are commutative ?
Internally the pattern would be duplicated with operands reversed.
e) Finalizing syntax:
For example: plus vs PLUS vs PLUS_EXPR, currently all of them are accepted.
(I would prefer lowercase version). Similarly free-form if vs
lisp-style (if ...) etc.
* Upto 19th may:
I plan to do the following upto 19th May:
a) Separate code-gen interfaces from AST and add simple fixes to genmatch.
b) Study forwprop patterns.
c) Try to solve missed optimization bugs.
If there's something else I would need to do, I would be happy to hear
about that.
Let me thank-you once again for selecting me for GSoC, and
I hope I would be able to complete the project successfully within given time.
Thanks and Regards,
Prathamesh
reviewers for wide int.
Richi, David Edelsohn said that I should talk to you about appointing reviewers for wide-int.While I think that it may not be necessary to have any reviewers for wide-int in the long term, I think that it would be useful to make Richard Sandiford, Mike Stump and myself reviewers at least for this release cycle. While of course one hopes that there will be no issues with wide-int, a change of this size will have some pain no matter how well we have tested it. Having three reviewers will assure problems are resolved quickly. Thanks, Kenny
Re: reviewers for wide int.
On April 22, 2014 9:28:15 PM CEST, Kenneth Zadeck wrote: >Richi, > >David Edelsohn said that I should talk to you about appointing >reviewers >for wide-int.While I think that it may not be necessary to have any > >reviewers for wide-int in the long term, I think that it would be >useful >to make Richard Sandiford, Mike Stump and myself reviewers at least for > >this release cycle. > >While of course one hopes that there will be no issues with wide-int, a > >change of this size will have some pain no matter how well we have >tested it. Having three reviewers will assure problems are resolved >quickly. Works for me. I suppose this mainly covers wide-int.[CH], right? Richard. >Thanks, > >Kenny
Re: reviewers for wide int.
On 04/22/2014 03:37 PM, Richard Biener wrote: On April 22, 2014 9:28:15 PM CEST, Kenneth Zadeck wrote: Richi, David Edelsohn said that I should talk to you about appointing reviewers for wide-int.While I think that it may not be necessary to have any reviewers for wide-int in the long term, I think that it would be useful to make Richard Sandiford, Mike Stump and myself reviewers at least for this release cycle. While of course one hopes that there will be no issues with wide-int, a change of this size will have some pain no matter how well we have tested it. Having three reviewers will assure problems are resolved quickly. Works for me. I suppose this mainly covers wide-int.[CH], right? if you want to define it that narrowly you can. it really depends on how much help you want and how much you trust us not to go beyond what is reasonable. All three of us have been at this long enough to know when to ask for help. Kenny Richard. Thanks, Kenny
Re: reviewers for wide int.
On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck wrote: > >>> While of course one hopes that there will be no issues with wide-int, a >>> change of this size will have some pain no matter how well we have >>> tested it. Having three reviewers will assure problems are resolved >>> quickly. >> Works for me. I suppose this mainly covers wide-int.[CH], right? > if you want to define it that narrowly you can. it really depends on how > much help you want and how much you trust us not to go beyond what is > reasonable. All three of us have been at this long enough to know when to > ask for help. There is a large class of bugs that can creep in due to the subtle change of interface from double-int to wide-int. These happen outside of the wide-int.[ch] code and seem statistically more likely by a large margin than bugs in wide-int.[ch]. The good news, resolving them is easy enough with side-by-side comparisons (say of dump files and .s files). Most of those fixes I’d expect to be trivial (for some definition of trivial).
Re: C PreProcessor GCC-specific features ideas.
On Tue, Apr 22, 2014 at 9:38 AM, Solal wrote: > > I've got ideas for improve the preprocessor with specific features. > > The basic idea is to make the preprocessing language a complete > programming language. We are very unlikely to add such features to GCC unless they first become part of the C or C++ language standard. There are other preprocessors better suited for general purpose programming, such as m4. Ian
