[GSoC 2019]: Interested in "Make C/C++ not automatically promote memory_order_consume to memory_order_acquire"

[Akshatg]

Hello all,

I'm a 2nd year Master's student at IIT Bombay. I have taken advance 
compiler related courses in the past semesters. I'm interested to work 
on the project "Make C/C++ not automatically promote 
memory_order_consume to memory_order_acquire" this summer. I have read 
the documents shared.


Kindly, let me know what I can do next to make my proposal stronger?

Thanks,
Akshat

Re:2018-12-26

[sale...@dake.com]

Dear Madam/Sir,
 
This is Monica from MF Battery company.
We manufacture batteries applied to cell phones, cameras. 
The customers are very satisfied with our quality & services, 
although we're not a world-famous company.
So, do you need new products to test the markets?
 
Btw, free samples will be sent out!
Any needs, please let me know!
 
 
Kind regards
 
 
Monica
 
--
Skype: Monica Lee
WhatsApp/Mob.: +86 15089538343
Wechat: +86 15089538343/Alex878566623
---
Ming Feng(Shenzhen) Battery CO.,LTD 
Web.: www.szmfbattery.co
Address: Room201,Floor 2, Building B, Yongchuang Industrial Area,Dalang Street 
Office,LonghuaNew District,Shenzhen,Guangdong Province ,China

Re: How to add %' into gfc_fatal_error

[Martin Liška]

On 3/11/19 6:23 PM, Steve Kargl wrote:
> On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
>> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
>>> Hi.
>>>
>>> I would like to add %' into __gcc_gfc__ in order to handle:
>>>
>>> ./xgcc -B. /tmp/module.ii -Wformat -c
>>> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
>>> dump_module(const char*, int)’:
>>> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
>>> unknown conversion type character ‘'’ in format [-Wformat=]
>>>  6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s",
>>> filename,
>>>   |   ^~~
>>>
>>> Can you please help me how to do that?
> 
> Are you inserting "%" in front of "'"?  Why?
> There are 18 occurences of "Can't" in gfc_error*
> messages in the fortran/*.c code.  If you're going
> to touch all 18 locations, then change "Can't" to
> "Cannot".
> 

Hi.

I'm addressing that with attached patch. The patch also touches Alexander's
note in a next email (i386.c change).

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
From 5903e4750fd5fd8e972cc5c69513ad724e8eb949 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 12 Mar 2019 09:39:07 +0100
Subject: [PATCH] Replace can't in error messages for Fortran.

gcc/c-family/ChangeLog:

2019-03-12  Martin Liska  

	* c-opts.c (c_common_handle_option): Wrap option with %< and %>.

gcc/fortran/ChangeLog:

2019-03-12  Martin Liska  

	* decl.c (add_init_expr_to_sym): Replace usage of 'can't'
	with 'cannot'.
	(variable_decl): Likewise.
	(cray_pointer_decl): Likewise.
	(match_binding_attributes): Likewise.
	* f95-lang.c (gfc_init): Likewise.
	* interface.c (gfc_check_typebound_override): Likewise.
	* intrinsic.c (make_generic): Likewise.
	* module.c (dump_module): Likewise.
	(gfc_use_module): Likewise.
	* primary.c (gfc_convert_to_structure_constructor): Likewise.
	* resolve.c (resolve_entries): Likewise.
	(check_generic_tbp_ambiguity): Likewise.
	(get_checked_tb_operator_target): Likewise.
	* scanner.c (load_file): Likewise.
	* trans-expr.c (gfc_conv_intrinsic_to_class): Likewise.

gcc/ChangeLog:

2019-03-12  Martin Liska  

	* config/i386/i386.c: Reword an error message.

gcc/testsuite/ChangeLog:

2019-03-12  Martin Liska  

	* gfortran.dg/abstract_type_3.f03: Amend test-case scan
	patterns.
	* gfortran.dg/binding_label_tests_4.f03: Likewise.
	* gfortran.dg/c_f_pointer_tests_6.f90: Likewise.
	* gfortran.dg/c_funloc_tests_6.f90: Likewise.
	* gfortran.dg/c_loc_tests_17.f90: Likewise.
	* gfortran.dg/constructor_9.f90: Likewise.
	* gfortran.dg/dec_structure_8.f90: Likewise.
	* gfortran.dg/entry_4.f90: Likewise.
	* gfortran.dg/init_char_with_nonchar_ctr.f90: Likewise.
	* gfortran.dg/initialization_23.f90: Likewise.
	* gfortran.dg/logical_assignment_1.f90: Likewise.
	* gfortran.dg/pr80752.f90: Likewise.
	* gfortran.dg/pr88116_1.f90: Likewise.
	* gfortran.dg/pr88467.f90: Likewise.
	* gfortran.dg/typebound_call_7.f03: Likewise.
	* gfortran.dg/typebound_generic_1.f03: Likewise.
	* gfortran.dg/typebound_operator_2.f03: Likewise.
	* gfortran.dg/typebound_operator_4.f03: Likewise.
	* gfortran.dg/typebound_proc_9.f03: Likewise.
	* gfortran.dg/unlimited_polymorphic_2.f03: Likewise.
---
 gcc/c-family/c-opts.c  |  2 +-
 gcc/config/i386/i386.c |  3 ++-
 gcc/fortran/decl.c | 10 +-
 gcc/fortran/f95-lang.c |  2 +-
 gcc/fortran/interface.c|  2 +-
 gcc/fortran/intrinsic.c|  8 
 gcc/fortran/module.c   | 14 +++---
 gcc/fortran/primary.c  |  2 +-
 gcc/fortran/resolve.c  | 18 +-
 gcc/fortran/scanner.c  |  2 +-
 gcc/fortran/trans-expr.c   |  4 ++--
 gcc/testsuite/gfortran.dg/abstract_type_3.f03  |  2 +-
 .../gfortran.dg/binding_label_tests_4.f03  |  2 +-
 .../gfortran.dg/c_f_pointer_tests_6.f90|  2 +-
 gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90 |  4 ++--
 gcc/testsuite/gfortran.dg/c_loc_tests_17.f90   |  2 +-
 gcc/testsuite/gfortran.dg/constructor_9.f90|  2 +-
 gcc/testsuite/gfortran.dg/dec_structure_8.f90  |  2 +-
 gcc/testsuite/gfortran.dg/entry_4.f90  |  8 
 .../gfortran.dg/init_char_with_nonchar_ctr.f90 |  8 
 .../gfortran.dg/initialization_23.f90  |  2 +-
 .../gfortran.dg/logical_assignment_1.f90   |  2 +-
 gcc/testsuite/gfortran.dg/pr80752.f90  |  2 +-
 gcc/testsuite/gfortran.dg/pr88116_1.f90|  2 +-
 gcc/testsuite/gfortran.dg/pr88467.f90  |  2 +-
 gcc/testsuite/gfortran.dg/typebound_call_7.f03 |  2 +-
 .../gfortran.dg/typebound_generic_1.f03|  4 ++--
 .../gfortran.dg/typebound_operator_2.f03   |  4 ++--
 .../gfortran.dg/typebound_operator_4.f03   |  4 ++--
 gcc

Re: How to add %' into gfc_fatal_error

[Steve Kargl]

On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote:
> On 3/11/19 6:23 PM, Steve Kargl wrote:
> > On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
> >> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
> >>> Hi.
> >>>
> >>> I would like to add %' into __gcc_gfc__ in order to handle:
> >>>
> >>> ./xgcc -B. /tmp/module.ii -Wformat -c
> >>> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
> >>> dump_module(const char*, int)’:
> >>> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
> >>> unknown conversion type character ‘'’ in format [-Wformat=]
> >>>  6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s",
> >>> filename,
> >>>   |   ^~~
> >>>
> >>> Can you please help me how to do that?
> > 
> > Are you inserting "%" in front of "'"?  Why?
> > There are 18 occurences of "Can't" in gfc_error*
> > messages in the fortran/*.c code.  If you're going
> > to touch all 18 locations, then change "Can't" to
> > "Cannot".
> 
> I'm addressing that with attached patch. The patch also touches Alexander's
> note in a next email (i386.c change).
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

The Fortran parts are OK.  The other parts look ok, but
I don't know if I can approve those changes.

-- 
steve

Re: How to add %' into gfc_fatal_error

[Martin Liška]

On 3/12/19 3:17 PM, Steve Kargl wrote:
> On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote:
>> On 3/11/19 6:23 PM, Steve Kargl wrote:
>>> On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote:
 On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote:
> Hi.
>
> I would like to add %' into __gcc_gfc__ in order to handle:
>
> ./xgcc -B. /tmp/module.ii -Wformat -c
> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
> dump_module(const char*, int)’:
> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
> unknown conversion type character ‘'’ in format [-Wformat=]
>  6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s",
> filename,
>   |   ^~~
>
> Can you please help me how to do that?
>>>
>>> Are you inserting "%" in front of "'"?  Why?
>>> There are 18 occurences of "Can't" in gfc_error*
>>> messages in the fortran/*.c code.  If you're going
>>> to touch all 18 locations, then change "Can't" to
>>> "Cannot".
>>
>> I'm addressing that with attached patch. The patch also touches Alexander's
>> note in a next email (i386.c change).
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
> 
> The Fortran parts are OK.  The other parts look ok, but

Good.

> I don't know if I can approve those changes.

I'm going to install the patch as it's just a follow up of already
approved patches.

Martin

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Vincent Lefevre]

On 2019-03-11 13:51:21 +0100, David Brown wrote:
> On 11/03/2019 12:24, Vincent Lefevre wrote:
> > It already does by default:
> > 
> >-Wshift-count-negative
> >Warn if shift count is negative. This warning is enabled
> >by default.
> > 
> >-Wshift-count-overflow
> >Warn if shift count >= width of type. This warning is
> >enabled by default.
> > 
> > Of course, if the compiler cannot guess that there will be such
> > an issue, it will not emit the warning. You certainly don't want
> > a warning for each non-trivial shift just because the compiler
> > cannot know whether the constraint on the shift count will be
> > satisfied.
> 
> While the compiler clearly can't give a warning on calculated shifts
> without massive amounts of false positives, it is able to give warnings
> when there is a shift by a compile-time known constant value that is
> invalid.  In the case of the OP's test function, inlining and constant
> propagation means that the shift value /is/ known to the compiler - it
> uses it for optimisation (in this case, it uses the undefined behaviour
> to "simplify" the calculations).
> 
> Am I right in thinking that this is because the pass that checks the
> shift sizes for warnings here comes before the relevant inlining or
> constant propagation passes?  And if so, would it be possible to change
> the ordering here?

To generate a warning, the compiler would also have to make sure
that the inlined code with an out-of-range shift is actually not
dead code. In practice, it may happen that constraints are not
satisfied on some platforms, but the reason is that on such
platforms the code will never be executed (this is code written
to take care of other platforms).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

debugging libgo failures

[Aldy Hernandez]

Hi Ian.  Hi folks.

I have some libgo failures which I'm pretty sure I caused (see below for 
details), but I can't seem to figure out how to reproduce.  Before I go 
down the rabbit hole, is there an easy way of reproducing say:


FAIL: database/sql
FAIL: net/http

I'm used to scouring 
x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining 
insight on how to manually run tests.  However, there's nothing in 
libgo/testsuite, and libgo/libgo.log just has a summary of tests.


Ideally I'd like a way of building a test (with say -fdump-tree-all), 
and/or sticking gdb on the resulting executable.


Thanks.
Aldy

--- FAIL: TestMaxIdleConns (0.00s)
sql_test.go:1789: freeConns after set to zero = -1; want 0
sql_test.go:1798: freeConns = -1; want 0
panic: runtime error: makeslice: cap out of range [recovered]
panic: runtime error: makeslice: cap out of range

goroutine 202 [running]:
panic
/home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:588
testing.tRunner..func1
/home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:765
panic
/home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:535
database..z2fsql.DB.Close

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql.go:768
sql.closeDB

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:140
database..z2fsql.TestMaxIdleConns

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:1800
testing.tRunner
/home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:827
created by testing.T.Run
/home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:878 +1163
FAIL: database/sql


[snip]
[snip]

net..z2fhttp.persistConn.writeLoop

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1888
created by net..z2fhttp.Transport.dialConn

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1339 
+2693


eax0x0
ebx0x2
ecx0xcbbdd84c
edx0x0
edi0x0
esi0x8
ebp0xcbbdd84c
esp0xcbbdd830
eip0xf7f93049
eflags 0x286
cs 0x23
fs 0x0
gs 0x63
FAIL: net/http

Re: debugging libgo failures

[Ian Lance Taylor]

On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez  wrote:
>
> I have some libgo failures which I'm pretty sure I caused (see below for
> details), but I can't seem to figure out how to reproduce.  Before I go
> down the rabbit hole, is there an easy way of reproducing say:
>
> FAIL: database/sql
> FAIL: net/http
>
> I'm used to scouring
> x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining
> insight on how to manually run tests.  However, there's nothing in
> libgo/testsuite, and libgo/libgo.log just has a summary of tests.
>
> Ideally I'd like a way of building a test (with say -fdump-tree-all),
> and/or sticking gdb on the resulting executable.

To run a test, cd to the libgo build directly (TARGET/libgo) and run
`make database/sql/check`.  To see the exact commands that it runs,
including how the compiler is invoked, run `make GOTESTFLAGS=--trace
database/sql/check`.  To leave the directory behind with the test
program, run `make GOTESTFLAGS=--keep database/sql/check`.  That will
leave a gotest/test directory.  In that directory you can run
`LD_LIBRARY_PATH=../../.libs ./a.out -test.short` to run the tests.
You can run specific failing tests using a -test.run option.  You can
of course run gdb on the program.

Hope that helps.

Ian


> --- FAIL: TestMaxIdleConns (0.00s)
>  sql_test.go:1789: freeConns after set to zero = -1; want 0
>  sql_test.go:1798: freeConns = -1; want 0
> panic: runtime error: makeslice: cap out of range [recovered]
>  panic: runtime error: makeslice: cap out of range
>
> goroutine 202 [running]:
> panic
>  /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:588
> testing.tRunner..func1
>  /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:765
> panic
>  /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:535
> database..z2fsql.DB.Close
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql.go:768
> sql.closeDB
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:140
> database..z2fsql.TestMaxIdleConns
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:1800
> testing.tRunner
>  /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:827
> created by testing.T.Run
>  /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:878 +1163
> FAIL: database/sql
>
>
> [snip]
> [snip]
>
> net..z2fhttp.persistConn.writeLoop
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1888
> created by net..z2fhttp.Transport.dialConn
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1339
> +2693
>
> eax0x0
> ebx0x2
> ecx0xcbbdd84c
> edx0x0
> edi0x0
> esi0x8
> ebp0xcbbdd84c
> esp0xcbbdd830
> eip0xf7f93049
> eflags 0x286
> cs 0x23
> fs 0x0
> gs 0x63
> FAIL: net/http

Re: [RFC] split of i386.c

[Eric Gallager]

On 3/12/19, Martin Liška  wrote:
> Hi.
>
> I've thinking about the file split about quite some time, mainly
> in context of PR84402. I would like to discuss if it's fine for
> maintainers of the target to make such split and into which logical
> components can the file be split?
>
> I'm suggesting something like:
> - option-related and attribute-related stuff (i386-options.c - as seen in
> patch)
> - built-in related functions
> - expansion/gen functions - still quite of lot of functions, would make
>   sense to split into:
>   - scalar
>   - vector
> - prologue/epilogue, GOT, PLT, symbol emission
> - misc extensions like STV, TLS, CET, retpolines, multiversioning, ..
> - helpers - commonly used functions, print_reg, ix86_print_operand, ..
>
> I am volunteering to make the split, hopefully early in the next stage1.
>
> Thoughts?
>
> Thanks,
> Martin
>

I'm not a maintainer, but just as an onlooker I highly support this
move; i386.c is way too long as it is. 7 pieces sounds like a good
number of new files to split it into, too.

Eric

Re: How to add %' into gfc_fatal_error

[Eric Gallager]

On 3/11/19, Martin Sebor  wrote:
> On 3/11/19 8:18 AM, Martin Liška wrote:
>> Hi.
>>
>> I would like to add %' into __gcc_gfc__ in order to handle:
>>
>> ./xgcc -B. /tmp/module.ii -Wformat -c
>> /home/marxin/Programming/gcc/gcc/fortran/module.c: In function ‘void
>> dump_module(const char*, int)’:
>> /home/marxin/Programming/gcc/gcc/fortran/module.c:6205:19: warning:
>> unknown conversion type character ‘'’ in format [-Wformat=]
>>   6205 |  gfc_fatal_error ("Can%'t delete module file %qs: %s", filename,
>>|   ^~~
>>
>> Can you please help me how to do that?
>
> gfc_fatal_error ("Cannot delete module file %qs: %s", filename,
>
> ;-)
>
> Seriously, I would avoid contractions in diagnostics, especially
> "can't."
>
> Martin
>

Not just in diagnostics but in general, I would argue.

Re: [RFC] split of i386.c

[Jeff Law]

On 3/12/19 2:50 PM, Eric Gallager wrote:
> On 3/12/19, Martin Liška  wrote:
>> Hi.
>>
>> I've thinking about the file split about quite some time, mainly
>> in context of PR84402. I would like to discuss if it's fine for
>> maintainers of the target to make such split and into which logical
>> components can the file be split?
>>
>> I'm suggesting something like:
>> - option-related and attribute-related stuff (i386-options.c - as seen in
>> patch)
>> - built-in related functions
>> - expansion/gen functions - still quite of lot of functions, would make
>>   sense to split into:
>>   - scalar
>>   - vector
>> - prologue/epilogue, GOT, PLT, symbol emission
>> - misc extensions like STV, TLS, CET, retpolines, multiversioning, ..
>> - helpers - commonly used functions, print_reg, ix86_print_operand, ..
>>
>> I am volunteering to make the split, hopefully early in the next stage1.
>>
>> Thoughts?
>>
>> Thanks,
>> Martin
>>
> 
> I'm not a maintainer, but just as an onlooker I highly support this
> move; i386.c is way too long as it is. 7 pieces sounds like a good
> number of new files to split it into, too.
I trust your judgment on where/how to split and fully support the goals
behind splitting.  Uros is the key person you need to get on board.

jeff

Re: GCC turns &~ into | due to undefined bit-shift without warning

[David Brown]

On 12/03/2019 16:40, Vincent Lefevre wrote:

On 2019-03-11 13:51:21 +0100, David Brown wrote:

On 11/03/2019 12:24, Vincent Lefevre wrote:

It already does by default:

-Wshift-count-negative
Warn if shift count is negative. This warning is enabled
by default.

-Wshift-count-overflow
Warn if shift count >= width of type. This warning is
enabled by default.

Of course, if the compiler cannot guess that there will be such
an issue, it will not emit the warning. You certainly don't want
a warning for each non-trivial shift just because the compiler
cannot know whether the constraint on the shift count will be
satisfied.


While the compiler clearly can't give a warning on calculated shifts
without massive amounts of false positives, it is able to give warnings
when there is a shift by a compile-time known constant value that is
invalid.  In the case of the OP's test function, inlining and constant
propagation means that the shift value /is/ known to the compiler - it
uses it for optimisation (in this case, it uses the undefined behaviour
to "simplify" the calculations).

Am I right in thinking that this is because the pass that checks the
shift sizes for warnings here comes before the relevant inlining or
constant propagation passes?  And if so, would it be possible to change
the ordering here?


To generate a warning, the compiler would also have to make sure
that the inlined code with an out-of-range shift is actually not
dead code. In practice, it may happen that constraints are not
satisfied on some platforms, but the reason is that on such
platforms the code will never be executed (this is code written
to take care of other platforms).



I disagree.  To generate an unconditional error (rejecting the program), 
the compiler would need such proof - such as by tracing execution from 
main().  But to generate a warning activated specifically by the user, 
there is no such requirement.  It's fine to give a warning based on the 
code written, rather than on code that the compiler knows without doubt 
will be executed.


(The warning here would be on the function "test" which calls the 
function with the shift, not on that function itself - since it is only 
when used in "test" that the compiler can see that there is undefined 
behaviour.)

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Vincent Lefevre]

On 2019-03-12 21:56:59 +0100, David Brown wrote:
> I disagree.  To generate an unconditional error (rejecting the program), the
> compiler would need such proof - such as by tracing execution from main().
> But to generate a warning activated specifically by the user, there is no
> such requirement.  It's fine to give a warning based on the code written,
> rather than on code that the compiler knows without doubt will be executed.

There's already a bug about spurious warnings on shift counts:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GIMPLE type and Architecture

[dalas]

Hi, I am new to GCC Infrastructure for this year.

I have an interest on GCC Intermediate Language System, and got into 
GIMPLE topic.


One question i got in mind is whether this GIMPLE is used for all 
front-end that GCC supports for now?


Seem the GIMPLE types are so generic that it even includes some 
3rd-party lib property.

GSOC -willing to work on a project idea for GCC

[Dinesh ch]

Hello,
I'm Dinesh aspiring to work on one of the project ideas -"Add new math.h and 
complex.h functions as built-ins" of GCC for GSOC.
I believe that I have the required skills stated in the project idea.
It would be great if I can get some help to start working on it so I could 
write the proposal with some work done and a little experience.

Thank you.
Regards,
Dinesh.