Pb on gcc : no warning on information lost.
Hello !
I am French, sorry for my bad english.
When I use gcc or g++ , I like when the compilator detects bug, with a
an error of compliation or a warning.
see this code :
long long fct()
{
return 0x123456789;
}
int main()
{
int a = fct();
cerr << a << endl;
}
when I compil with : g++ -Wall fic.cpp
I think that there should be a warning.
And there is nothing, the bug is not detected.
I think that it not normal.
Regards,
Yves Mocquard
Re: Pb on gcc : no warning on information lost.
(wrong list, you want gcc-h...@gcc.gnu.org)
On Mon, 14 Apr 2014, Yves Mocquard wrote:
When I use gcc or g++ , I like when the compilator detects bug, with a an
error of compliation or a warning.
see this code :
long long fct()
{
return 0x123456789;
}
int main()
{
int a = fct();
cerr << a << endl;
}
when I compil with : g++ -Wall fic.cpp
I think that there should be a warning.
-Wconversion
--
Marc Glisse
Re: Pb on gcc : no warning on information lost.
On Mon, Apr 14, 2014 at 2:41 PM, Yves Mocquard wrote:
> Hello !
> I am French, sorry for my bad english.
>
> When I use gcc or g++ , I like when the compilator detects bug, with a an
> error of compliation or a warning.
>
> see this code :
>
> long long fct()
> {
> return 0x123456789;
> }
> int main()
> {
> int a = fct();
> cerr << a << endl;
> }
>
> when I compil with : g++ -Wall fic.cpp
pass -Wconversion
I got this warning:
fooconv.c:8:14: warning: conversion to 'int' from 'long long int' may
alter its value [-Wconversion]
int a = fct();
^
> I think that there should be a warning.
> And there is nothing, the bug is not detected.
>
> I think that it not normal.
>
> Regards,
>
> Yves Mocquard
>
Re: Pb on gcc : no warning on information lost.
Thank you for your response.
Yves Mocquard.
Le 14/04/2014 11:15, Marc Glisse a écrit :
(wrong list, you want gcc-h...@gcc.gnu.org)
On Mon, 14 Apr 2014, Yves Mocquard wrote:
When I use gcc or g++ , I like when the compilator detects bug, with
a an error of compliation or a warning.
see this code :
long long fct()
{
return 0x123456789;
}
int main()
{
int a = fct();
cerr << a << endl;
}
when I compil with : g++ -Wall fic.cpp
I think that there should be a warning.
-Wconversion
Rename unwind.h to unwind-gcc.h
VxWorks7 has introduced an incompatible unwind.h header file that conflicts with gcc's unwind.h (which is a build time header file linked to the appropriate source header). I'd like to propose renaming gcc's unwind.h to unwind-gcc.h There are 54 occurrences in the gcc source tree, including the testsuite and one in the gdb testsuite. I have a patch ready to submit, but wished to get a preliminary reaction and have a discussion on issues I might have failed to consider. --Douglas Rupp
Re: Rename unwind.h to unwind-gcc.h
On Mon, Apr 14, 2014 at 10:10 AM, Douglas B Rupp wrote: > > VxWorks7 has introduced an incompatible unwind.h header file that conflicts > with gcc's unwind.h (which is a build time header file linked to the > appropriate source header). > > I'd like to propose renaming gcc's unwind.h to unwind-gcc.h > > There are 54 occurrences in the gcc source tree, including the testsuite and > one in the gdb testsuite. > > I have a patch ready to submit, but wished to get a preliminary reaction and > have a discussion on issues I might have failed to consider. You may have failed to consider that unwind.h is installed and can be #include'd by any program that is built with GCC. Renaming the installed file will break an unknown number of existing programs. Ian
Re: Code emitted was bloated with no optimisation.
Il 11/04/2014 07:05, Richard Sandiford ha scritto: Sure, but this is a bit extreme. I don't see off-hand how a[i] would generate a branch, for starters. That's an HI+HI->SI addition, with the higher half stored in (SP+2). The jump is emitted by cstore in order to compute the carry. add WA, IX ... ld HL, 1 ld (SP+2), HL cmp WA,IX j lt,_.L2 ld DE, 0 ld (SP+2), DE .L2: I'm not sure why such an addition would be necessary, but in any case the port is probably lacking a cstoresi4 pattern (you can use a predicate for operand 2 that only matches LTU). Paolo
Re: Unable to match instruction pattern
Thanks Richard,
That worked just as you suggested, and ... when I removed my
zero_extendhisi2 the IIRC the target-independent optabs code
generated exactly the same sequence.
Interestingly, I noticed that changing from my define_insn
"zero_extendhisi2" back to the define_expand "zero_extendhisi2"
caused some optimisation opportunities to be missed where an
expression calculated in 32 bits could equally well performed at
the natural 16 bit word width (because the result of the
calculation was truncated to 16 bits) :-)
Cheers, Paul.
On 12/04/14 04:21, Richard Sandiford wrote:
pshor...@dataworx.com.au writes:
Found it ...
I had
(define_expand "zero_extendhisi2"
[
(set (subreg:HI (match_operand:SI 0 "general_operand" "")0)
(match_operand:HI 1 "general_operand" ""))
(set (subreg:HI (match_dup 0)2)
(const_int 0))
]
""
""
)
FWIW, in general you shouldn't use subregs in expanders, but instead use
something like:
(define_expand "zero_extendhisi2"
[(set (match_operand:SI 0 "general_operand" "")
(zero_extend:SI (match_operand:HI 1 "general_operand" "")))]
""
{
emit_move_insn (gen_lowpart (HImode, operands[0]), operands[1]);
emit_move_insn (gen_highpart (HImode, operands[0]), const0_rtx);
DONE;
})
This allows MEMs to be simplified to smaller MEMs, which is preferable
to keeping them as SUBREGs. It also allows subregs of hard registers
to be simplified to simple REGs and handles constants correctly.
IMO SUBREGs of MEMs should go away. There's this strange convention
that (subreg (mem ...)) is treated as a register_operand before reload,
which is why:
if( !register_operand( operands[0], mode )
&& !register_operand( operands[1], mode ))
{
/* one of the operands must be in a register. */
operands[1] = copy_to_mode_reg (mode, operands[1]);
}
wouldn't trigger for a move between a constant and a subreg of a MEM.
OTOH, you should be better off not defining the zero_extendhisi2 at all,
since IIRC the target-independent optabs code would generate the same
sequence for you.
Thanks,
Richard
Redundant / wasted stack space and instructions
I'm porting to a 16 bit micro and noticed that when optimization is enabled (function.c:2101), most (non-volatile, non-addressed) stack variables are copied into virtual registers. I assume this is so the register allocator will attempt to allocate them to physical registers. Unfortunately, in those cases where there are a lot of stack parameters and those virtual registers are spilled to local variables a lot of code and stack space is wasted copying an image of the stack parameters into a spill slot instead of the overflow dropping back to use the original stack parameter space. For example ... addsp,-20 str0,[sp] str1,[sp+2] ldr0,[sp+24] str0,[sp+4] ldr2,[sp+26] str2,[sp+6] ldr3,[sp+28] str3,[sp+8] ldr0,[sp+30] str0,[sp+10] I'm aware that there are cases where the stack parameters are unsuitable as spill locations (due to partial values, alignment etc) but the majority of cases I see such as the example above the stack parameters are viable spill locations. In the case illustrated above the required stack space has blown out significantly and there are a host of redundant load/store operations that could be eliminated if the spill were to the stack parameters. For small micros such as MSP430 & friends and many of the Renasis MCUs, some of which only have 2K or ram on board, this could be a real issue. Although I reproduced the same behaviour on i386 using a stock compiler, I was wondering if there was something missing in my port that prevents spilling to stack locations, or a cleanup pass that addresses this issue ? Thanks, Paul
Re: Redundant / wasted stack space and instructions
On 04/14/14 18:58, pshor...@dataworx.com.au wrote: I'm porting to a 16 bit micro and noticed that when optimization is enabled (function.c:2101), most (non-volatile, non-addressed) stack variables are copied into virtual registers. I assume this is so the register allocator will attempt to allocate them to physical registers. Unfortunately, in those cases where there are a lot of stack parameters and those virtual registers are spilled to local variables a lot of code and stack space is wasted copying an image of the stack parameters into a spill slot instead of the overflow dropping back to use the original stack parameter space. For example ... addsp,-20 str0,[sp] str1,[sp+2] ldr0,[sp+24] str0,[sp+4] ldr2,[sp+26] str2,[sp+6] ldr3,[sp+28] str3,[sp+8] ldr0,[sp+30] str0,[sp+10] I'm aware that there are cases where the stack parameters are unsuitable as spill locations (due to partial values, alignment etc) but the majority of cases I see such as the example above the stack parameters are viable spill locations. In the case illustrated above the required stack space has blown out significantly and there are a host of redundant load/store operations that could be eliminated if the spill were to the stack parameters. For small micros such as MSP430 & friends and many of the Renasis MCUs, some of which only have 2K or ram on board, this could be a real issue. Although I reproduced the same behaviour on i386 using a stock compiler, I was wondering if there was something missing in my port that prevents spilling to stack locations, or a cleanup pass that addresses this issue ? The only way to know for sure is to dig through the debugging dumps to understand why any given pseudo register was not assigned to a hard register. If you're doing a new port, I would also recommend taking the time to investigate and possibly tune it to utilize LRA. It's been our experience that LRA, after tuning, produces superior code when compared to the old reload pass. Jeff
[GSoC] Status - 20140415
Hi Community, We have accepted 5 top-rated student proposals for this year's Google Summer of Code at GCC. Students, congratulations on your good work thus far, but don't relax, there is plenty of work ahead! The accepted proposals are below. The proposals will appear as "Accepted" on the GSoC website after April 21st when de-duplication process finishes (till that point proposals will be in shown as "Pending"). Generating folding patterns from meta description - Student: Prathamesh Kulkarni - Mentor: Richard Biener - Backup mentor: Diego Novillo Integration of ISL code generator into Graphite - Student: Roman Gareev - Mentor: Tobias Grosser - Backup mentor: TBD Concepts Separate Checking - Student: Braden Obrzut - Mentor: Andrew Sutton - Backup mentor: TBD GCC Go escape analysis - Student: Ray Li - Mentor: Ian Lance Taylor - Backup mentor: Diego Novillo Coarray support in GNU GFortran - Student: Alessandro Fanfarillo - Mentor: Tobias Burnus - Backup mentor: TBD Students, for some of you this will be your first dive into open-source development in a large community. Therefore, some ground rules for communications: 1. Your mentor is your primary contact. Most of your emails should be TO: . 2. Please CC: gcc@gcc.gnu.org, your backup mentor, and myself (GSoC GCC admin) on your emails. I know it may be scary and awkward to post publicly your first few messages, but -- trust me -- it will become second nature very soon. 3. Prefix your email subjects with "[GSoC]" so that it is easy for people scanning mailing lists and their inboxes to see your messages. 4. Use main #gcc channel on irc.oftc.net for discussions and don't be tempted into going 1-on-1 private chats with your mentor unless really necessary. 5. Mentors! Should your student forget to CC: the mailing list or accidentally start a private chat -- gently remind him/her of that and move the discussion into the public forum. The next month will be community bonding period where students should get comfortable working in GCC community and figure out how to get stuff done. To this end mentors and I will be assigning simple test tasks (fixing easy PRs, documentation fixes, etc) which will result in a committed patch. Any questions, comments or suggestions? I will send next status update in the middle of next week. Thank you, -- Maxim Kuvyrkov www.linaro.org
Re: Redundant / wasted stack space and instructions
On 15.04.2014 12:54, Jeff Law wrote: On 04/14/14 18:58, pshor...@dataworx.com.au wrote: I'm porting to a 16 bit micro and noticed that when optimization is enabled (function.c:2101), most (non-volatile, non-addressed) stack variables are copied into virtual registers. I assume this is so the register allocator will attempt to allocate them to physical registers. Unfortunately, in those cases where there are a lot of stack parameters and those virtual registers are spilled to local variables a lot of code and stack space is wasted copying an image of the stack parameters into a spill slot instead of the overflow dropping back to use the original stack parameter space. For example ... addsp,-20 str0,[sp] str1,[sp+2] ldr0,[sp+24] str0,[sp+4] ldr2,[sp+26] str2,[sp+6] ldr3,[sp+28] str3,[sp+8] ldr0,[sp+30] str0,[sp+10] I'm aware that there are cases where the stack parameters are unsuitable as spill locations (due to partial values, alignment etc) but the majority of cases I see such as the example above the stack parameters are viable spill locations. In the case illustrated above the required stack space has blown out significantly and there are a host of redundant load/store operations that could be eliminated if the spill were to the stack parameters. For small micros such as MSP430 & friends and many of the Renasis MCUs, some of which only have 2K or ram on board, this could be a real issue. Although I reproduced the same behaviour on i386 using a stock compiler, I was wondering if there was something missing in my port that prevents spilling to stack locations, or a cleanup pass that addresses this issue ? The only way to know for sure is to dig through the debugging dumps to understand why any given pseudo register was not assigned to a hard register. If you're doing a new port, I would also recommend taking the time to investigate and possibly tune it to utilize LRA. It's been our experience that LRA, after tuning, produces superior code when compared to the old reload pass. Jeff Thanks Jeff, The register spilling isn't the problem, this is a situation where there are more variables than registers so spilling is expected. The problem is that spilled vregs that correspond to stack parameters... that already have appropriate memory available, are spilling to a new local spill variable. I've just built the trunk msp430 and h8300 ports and they both spill correctly to the stack parameters when compiling the same test code... so I'll hunt through those ports so see if I can find something I've missed. I have ported to the LRA, however on this register poor CPU it seems to fail to allocate registers in cases where the old reload pass works just fine... maybe my LRA port also has problems :-) Cheers, Paul.
Re: WPA stream_out form & memory consumption
> On Mon, Apr 7, 2014 at 8:20 PM, Jan Hubicka wrote: > >> AFAIK we settled on a simpler one dropping columns at stream-out time > >> that also helped. > >> > >> As for the correct way to do the optimization we agreed(?) that streaming > >> the locations elsewhere and using references to them is more appropriate. > >> At stream-in (or before stream-out) we can then read the location pairs > >> and sort them before assigning linemap entries. > > > > Yep, however what makes difference is the sharing in between compilation > > units > > (so sameheaders gets assigned same locations) rather than sharing within > > the unit > > (by my experiments). The separate streaming+sorting will only help sharing > > within the unit. > > > > Perhaps something rather simplelike keeping previous stream and merging > > them will > > work, too, not sure if better than the simple cache hash though. > > Or perhaps we can somehow track per-source-file location spaces. Don't know. > > But then linemap itself should provide the ability to lookup existing > entries rather than you adding another table ontop of it ... I think the linemap representation does well for frontend use, that produces locations more or less in sequential manner. It is just LTO that is special. > > Note that you mess up the include stack when you re-use linemap entries > across files (we at least care to setup the source TU information so you > get 'included from foo.c' correctly - if you re-use linemaps you get that > screwed up and ultimately end up with bogus inline stacks for example). Hmm, never looked into how we track those to be honest. Indeed something that would need to be matched when chaching, too. If I get time, I will probably try to impelemnt the separate section for locators and we can see where we want to go from there. Honza > > Richard. > > > Honza
