Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes:
Richard Sandiford rdsandif...@googlemail.com writes:
Matthew Fortune matthew.fort...@imgtec.com writes:
I think instead we should have a configuration switch that allows a
particular -mfp option to be inserted alongside -mabi=32 if no
explicit -mfp is given. This is how most --with options work. Maybe
--with-fp- 32={32|64|xx}? Specific triples could set a default value
if they like.
E.g. the MTI, SDE and mipsisa* ones would probably want to default to
-- with-32-fp=xx. Triples aimed at MIPS IV and below would stay as
they are. (MIPS IV is sometimes used with -mabi=32.)
--with-fp-32 isn't the greatest name but is at least consistent with
--with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
breaking consistency is better though.
Tying the use of fpxx by default to a configure time setting is OK
with me. When enabled it would still have to follow the rules as
defined in the design in that it can only apply to architectures that
can support the variant.
Right. It's really equivalent to putting the -mfp on every command line
that doesn't have one.
Currently that means everything but mips1.
Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
I'm not sure this is the same as tying an ABI to an architecture as
both fp32 and fpxx are O32 and link compatible. Perhaps the configure
switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
related setting.
What I meant is that -march= and -mips shouldn't imply a different -mfp
setting. The -mfp setting should be self-contained and it should be an
error if the architecture isn't compatible.
We might be in violent agreement here :-) Like I say, I was just a bit
worried by the earlier -mips32r2 thing because there was a time when a -
mips option really could imply things like -mabi, -mgp and -mfp.
--with-o32-fp would be OK with me. I'm just worried about the ABI being
spelt differently from -mabi=, but there's probably no perfect
alternative.
I'd like to encourage the perspective that -mfp* options do not lead to
a different ABI in the same sense that other variations do. While it is
true that the calling conventions and code generation rules vary, 2 out
of 3 combinations of -mfp32 -mfpxx and -mfp64 with -mabi=o32 are link
compatible.
-mfp32 and -mfp64 aren't link-compatible though, so -mfp is part of the ABI.
What you're adding is a new variant that is individually link-compatible
with the other two (but obviously not both simultaneously). It's a third
ABI variant in itself.
The introduction of the modeless O32 ABI is intended to
remove the part of the O32 definition that says 'FR=0' and hence the
architecture then gets to dictate this and the generated code is still
O32. It is true today that we have several architectures that mandate
FR=0, some that cannot support fpxx and some that can support all fp*
variations. I see nothing preventing the future having an architecture
only supporting FR=1 though which we should also think about.
Agreed.
When considering such a scenario it would be highly desirable for the
following to just work as I believe architectural restrictions should
be accounted for when designing default options. If the architecture
gives no choice then it should just work IMO:
Some ideas (speculating that someone builds a core called mips_n with
only FR=1):
--with-o32-fp=32
mips-*-gcc -march=mips1 fp.c == generates fp32 code
mips-*-gcc -march=mips2 fp.c == generates fp32 code
mips-*-gcc -march=mips32r2 fp.c == generates fp32 code
mips-*-gcc -march=mips32r2 -mfp64 fp.c == generates fp64 code
mips-*-gcc -march=mips_n fp.c == generates fp64 code
--with-o32-fp=xx
mips-*-gcc -march=mips1 fp.c == generates fp32 code
mips-*-gcc -march=mips2 fp.c == generates fpxx code
mips-*-gcc -march=mips32r2 fp.c == generates fpxx code
mips-*-gcc -march=mips32r2 -mfp64 fp.c == generates fp64 code
mips-*-gcc -march=mips_n fp.c == generates fp64 code
--with-o32-fp=64
mips-*-gcc -march=mips1 fp.c == generates fp32 code
mips-*-gcc -march=mips2 fp.c == generates fpxx code
mips-*-gcc -march=mips32r2 fp.c == generates fp64 code
mips-*-gcc -march=mips32r2 -mfp64 fp.c == generates fp64 code
mips-*-gcc -march=mips32r2 -mfpxx fp.c == generates fpxx code
mips-*-gcc -march=mips_n fp.c == generates fp64 code
With these defaults, the closest supported ABI is used for each
architecture based on the --with-o32-fp build option. The only one I
really care about is the middle one as it makes full use of the O32 FPXX
ABI without a user needing to account for arch restrictions.
Note that --with-* options just insert a canned -mfoo=bar option under
certain conditions, with those conditions being the same regardless of bar.
So --with-o32-fp=32 should insert -mfp32 (and nothing else), --with-o32-fp=64
should insert -mfp64, etc.
The rules should therefore be
RE: dom requires PROP_loops
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 18:46
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: RE: dom requires PROP_loops
On March 13, 2014 5:00:53 PM CET, Paulo Matos pma...@broadcom.com wrote:
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 13:24
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: dom requires PROP_loops
Probably RTL cfgcleaup needs the same treatment as GIMPLE cfgcleanup
then - allow removal if loop properties allows it.
In both cfgcleanup.c and tree-cfgcleanup.c I can see code that protects
loop latches, but I see no code that allows removal of latch if
property allows it.
From what you say I would expect this would already be implemented in
tree-cfgcleanup.c, however what actually happens is that since
current_loops is non-null (PROP_loops is not destroyed in tree
loopdone), tree-cfgcleanup call chain ends up calling
cleanup_tree_cfg_bb on the bb loop latch and tree_forwarder_block_p
returns false for bb because of the following code thereby not removing
the latch:
if (current_loops)
{
basic_block dest;
/* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
dest = EDGE_SUCC (bb, 0)-dest;
if (dest-loop_father-header == dest)
return false;
}
Why do we need to protect the latch?
You are looking at old sources.
That's correct. I was looking at 4.8. Let me take a look at what trunk is
doing... :)
Richard.
Paulo Matos
Richard.
Re: SET_EXPR_LOCATION usage for unused tree?
On Thu, Mar 13, 2014 at 10:44 PM, Thomas Schwinge
tho...@codesourcery.com wrote:
Hi!
In gcc/c/c-parser.c:c_parser_omp_clause_num_threads (as well as other,
similar functions), what is the point of setting the boolean tree c's
location, given that this tree won't be used in the following?
/* Attempt to statically determine when the number isn't positive.
*/
c = fold_build2_loc (expr_loc, LE_EXPR, boolean_type_node, t,
build_int_cst (TREE_TYPE (t), 0));
if (CAN_HAVE_LOCATION_P (c))
SET_EXPR_LOCATION (c, expr_loc);
if (c == boolean_true_node)
{
warning_at (expr_loc, 0,
%num_threads% value must be positive);
t = integer_one_node;
}
[c not used anymore]
Both with and without the SET_EXPR_LOCATION, the error is the same:
../../loop.c: In function 'main':
../../loop.c:10:34: warning: 'num_threads' value must be positive
#pragma omp parallel num_threads(-1)
^
That can be even simplified to avoid building the tree if it doesn't simplify
with
c = fold_binary (LE_EXPR, boolean_type_node, t, build_int_cst
(TREE_TYPE (t), 0));
if (c c == boolean_true_node)
{
warning_at (
Richard.
Grüße,
Thomas
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes: The spec on: https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking has been updated and attempts to account for all the feedback. Not everything has been possible to simplify/rework as requested but I believe I have managed to address many points cleanly. (FWIW there seem to be some weird line breaks in the page which make it a bit hard to read.) The main thing that stood out for me was section 9. If we have the attributes and the program header (both good to have IMO) then we shouldn't have an ELF flag too. Static consumers should use the attribute and dynamic consumers should use the program header. The main point of encoding future info in a program header was to relieve the pressure on the ELF flags. As far as the program header encoding goes: I was thinking of a more general mechanism that specifies a block of data, a bit like the current PT_MIPS_OPTIONS does. Encoding the information directly in the enumeration wouldn't scale well, since we'd end up with the same problem as we have now for ELF flags. It would also be a bit wasteful to specify two bits of information this way since the other parts of the header structure don't carry any weight. Thanks, Richard
Legitimize address after reload
Hello, I'm writing a simple gcc backend and I'm experiencing a weird thing regarding address legitimation process. Two scenarios: If I only allow addresses to be either a register or symbols my gcc works. To do so I add the restrictions into the TARGET_LEGITIMATE_ADDRESS_P macro. This makes gcc to force registers for all the addresses. If I allow also a 'PLUS' expression to be a valid address (adding the restriction that the two addends are a register and a constant) it happens (sometimes) that gcc comes up with an expression like this one: (plus:SI (plus:SI (reg:SI somereg) (const_int 4)) (const_int 8)) After taking a look at the 386 backend (and others) I just discovered that there is a function called LEGITIMIZE_RELOAD_ADDRESS which is responsible for handling this case. My issue is that this function is not being called and, from what I saw while debugging, it seems that the offending RTX expression is created after the address_reload pass, and thus impossible for this pass to legitimize the address. Looking at other architectures it seems that they are doing more or less the same, so I don't know what the issue might be. Do you have any idea? Thanks, David
Re: Legitimize address after reload
On Fri, 14 Mar 2014 12:52:35 +0100 David Guillen da...@davidgf.net wrote: If I allow also a 'PLUS' expression to be a valid address (adding the restriction that the two addends are a register and a constant) it happens (sometimes) that gcc comes up with an expression like this one: (plus:SI (plus:SI (reg:SI somereg) (const_int 4)) (const_int 8)) After taking a look at the 386 backend (and others) I just discovered that there is a function called LEGITIMIZE_RELOAD_ADDRESS which is responsible for handling this case. My issue is that this function is not being called and, from what I saw while debugging, it seems that the offending RTX expression is created after the address_reload pass, and thus impossible for this pass to legitimize the address. Look at how e.g. the ARM backend and others handle the strict parameter to the legitimate_address hook -- you need to use that to forbid pseudo registers being allowed in RTXs in the strict case. LEGITIMIZE_RELOAD_ADDRESS is probably a red herring (at least for the simple cases you're probably dealing with to start with), and isn't used for LRA anyway. Getting these bits right can be very fiddly! The (plus (reg) (const)) operands can arise before/during during register elimination, IIRC. (You might need to get the register-elimination bits right, too...) Just a guess, anyway. (http://gcc.gnu.org/wiki/reload might be helpful if you've not read it.) Julian
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: The spec on: https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinki ng has been updated and attempts to account for all the feedback. Not everything has been possible to simplify/rework as requested but I believe I have managed to address many points cleanly. (FWIW there seem to be some weird line breaks in the page which make it a bit hard to read.) Apologies, I edited it offline and didn't check the result carefully enough. I'll clean it up. The main thing that stood out for me was section 9. If we have the attributes and the program header (both good to have IMO) then we shouldn't have an ELF flag too. Static consumers should use the attribute and dynamic consumers should use the program header. The main point of encoding future info in a program header was to relieve the pressure on the ELF flags. I know what you mean. I kept the ELF flag around because it firstly already exists (with the correct meaning as it happens) and secondly ELF flags are already consumed in the program loader whereas a small amount of new framework in the kernel is needed for the loader to respond to program headers. The 'executable stack' header is currently consumed but the mechanism is not extensible today. My thinking is that the ELF flag eases us into the program loader but could validly be dropped/not required long term. It is largely ignored by the tools anyway in favour of the program headers. I am happy to remove the ELF flag if I can confirm with our MIPS kernel developers that they can implement the program header inspection sooner rather than later. As far as the program header encoding goes: I was thinking of a more general mechanism that specifies a block of data, a bit like the current PT_MIPS_OPTIONS does. Encoding the information directly in the enumeration wouldn't scale well, since we'd end up with the same problem as we have now for ELF flags. It would also be a bit wasteful to specify two bits of information this way since the other parts of the header structure don't carry any weight. I was trying to avoid the need for a program header to refer to a block of data as that is another part of the object that has to be loaded to determine the flag information. There are 2^28 processor specific program headers available which seems quite generous (I half though of using 2 for the two modes), but I do also recognise that most of the header then becomes wasted space. I guess there may be some complaint if we choose to abuse every field of a header to encode information (i.e. address, size, alignment etc) but this would be a nice compact way to store flags. It would be more visible to put flags in the address fields as these are already printed by readelf et al. but the processor specific flags are not. Personally I'd open up all the fields to abuse over adding a block of data. The block of data increases the complexity of the program loader and dynamic loader as they have to ensure more of an object is read in order to make a decision. The extra data needed from an object would also be target specific, all do-able I'm just not sure on complexity. I wonder if Joseph or Maciej have any thoughts here as I believe they discussed this idea of using program headers in the past. Since I'm far from being an expert in this area I'm OK with anything as long as I can get all maintainers of dynamic loaders and program loaders to agree (ha!). Bionic, glibc, uclibc and linux kernel are the primary targets here. Regards, Matthew
Re: Legitimize address after reload
Thanks for you info Julian. I actually read all the docs and I think I 'more or less' understand the inner workings of gcc. What surprises me most is that during the non-strict RTL generation I do not see any 'strange' address pattern but during the post-reload process the non-legitimate address comes up. I guess it is due to the fact that one of the PLUS operands is a memory operand (a local var.?), thus resulting in double indirect memory address. In any case I'm not using the restrict variable and I'm assuming strict is zero, this is, not checking the hard regsiters themselves. This is because any reg is OK for base reg. I'm pretty sure I'm behaving similarly to arm, cris or x86 backends. Thanks, David 2014-03-14 13:11 GMT+01:00 Julian Brown jul...@codesourcery.com: On Fri, 14 Mar 2014 12:52:35 +0100 David Guillen da...@davidgf.net wrote: If I allow also a 'PLUS' expression to be a valid address (adding the restriction that the two addends are a register and a constant) it happens (sometimes) that gcc comes up with an expression like this one: (plus:SI (plus:SI (reg:SI somereg) (const_int 4)) (const_int 8)) After taking a look at the 386 backend (and others) I just discovered that there is a function called LEGITIMIZE_RELOAD_ADDRESS which is responsible for handling this case. My issue is that this function is not being called and, from what I saw while debugging, it seems that the offending RTX expression is created after the address_reload pass, and thus impossible for this pass to legitimize the address. Look at how e.g. the ARM backend and others handle the strict parameter to the legitimate_address hook -- you need to use that to forbid pseudo registers being allowed in RTXs in the strict case. LEGITIMIZE_RELOAD_ADDRESS is probably a red herring (at least for the simple cases you're probably dealing with to start with), and isn't used for LRA anyway. Getting these bits right can be very fiddly! The (plus (reg) (const)) operands can arise before/during during register elimination, IIRC. (You might need to get the register-elimination bits right, too...) Just a guess, anyway. (http://gcc.gnu.org/wiki/reload might be helpful if you've not read it.) Julian
Re: Reg Alloc Problem.
Hi All, To handle the below problem i.e making specific set of register as base registers ,which is the subset of general registers set. we see the *.c.208.ira logs as Pass 0 for finding pseudo/allocno costs r21: preferred BASE_REGS, alternative GENERAL_REGS, allocno GENERAL_REGS a2 (r21,l0) best BASE_REGS, allocno GENERAL_REGS r19: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS a0 (r19,l0) best GENERAL_REGS, allocno GENERAL_REGS r18: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS a1 (r18,l0) best GENERAL_REGS, allocno GENERAL_REGS a0(r19,l0) costs: LOW_8BIT_REGS:0 BASE_REGS:0 GENERAL_REGS:0 ALL_REGS:0 MEM:8 a1(r18,l0) costs: LOW_8BIT_REGS:0 BASE_REGS:0 GENERAL_REGS:0 ALL_REGS:0 MEM:8 a2(r21,l0) costs: LOW_8BIT_REGS:2 BASE_REGS:0 GENERAL_REGS:4 ALL_REGS:4 MEM:8 where IRA choose the GENERAL_REG over BASE (preferred) for the r21 pseudo,i'm looking for the cause in our backend,but mean while anyone in the group can share there experience w.r.t that will help me to solve issue asap. Thank you ~Umesh On Wed, Mar 12, 2014 at 7:30 PM, Umesh Kalappa umesh.kalap...@gmail.com wrote: Hi All, We are porting the gcc 4.8.1 to the new target and which has the pair 16 bit registers like AB or CD or EF and we modeled it in reg_class as AB,CD and DE 16 bit pair_regs and CD ,EF as 16 bit base_regs and A,B,C,D E and F as 8 bit as general_regs. We are stuck with below issues like 1)How do we modelled such that the register alloc to pick the respective base_regs i.e CD,DE instead of AB as show in the below case LD AB ,_a;//invalid instead of it should be emit LD CD ,_a LD (AB),#100; // invalid instead of it should be emit LD (CD),#100 Please note that we override the target hook like REGNO_REG_CLASS ,but still no luck here . 2)Current target enforce the restrictions on the pair register set usage for multiplication like MUL A,B or MUL C,D or MUL E,F But not MUL A,C or MUL B,C etc not across the pair_regs . Anyone can please shed some lights here ,will be appreciate and help us in the great way . Thank you for the patience ~Umesh
Re: [gsoc 2014] moving fold-const patterns to gimple
On Thu, Mar 13, 2014 at 4:44 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Mar 11, 2014 at 12:20 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Mar 10, 2014 at 7:29 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
Hi Richard,
Sorry for the late reply. I would like to have few clarifications
regarding the following points:
a) Pattern matching: Currently, gimple_match_and_simplify() matches
patterns one-by-one. Could we use a decision tree to do the matching
instead (similar to insn-recog.c) ?
For the moment, let's consider pattern matching on only unary
expressions without valueize and predicates:
pattern 1: (negate (negate @0))
pattern 2: (negate (bit_not @0))
from the two AST's corresponding to patterns (match::op), we can build
a decision tree:
Some-thing similar to:
NEGATE_EXPR
NEGATE_EXPRBIT_NOT_EXPR
and then generate code corresponding to this decision tree in gimple-match.c
so the generated code should look something similar to:
tree
gimple_match_and_simplify (enum tree_code code, tree type, tree op0,
gimple_seq *seq, tree (*valueize)(tree))
{
if (code == NEGATE_EXPR)
{
tree captures[4] = {};
if (TREE_CODE (op0) != SSA_NAME)
return NULL_TREE;
gimple def_stmt = SSA_NAM_DEF_STMT (op0);
if (!is_gimple_assign (def_stmt))
return NULL_TREE;
tree op = gimple_assign_rhs1 (def_stmt);
if (gimple_assign_rhs_code (op) == NEGATE_EXPR)
{
/* pattern (negate (negate @0)) matched */
}
else if (gimple_assign_rhs_code (op) == BIT_NOT_EXPR)
{
/* pattern (negate (bit_not_expr @0)) matched */
}
else
return NULL_TREE;
}
else
return NULL_TREE;
}
For commutative ops, the pattern can be duplicated by walking the
children of the node in reverse order.
(I am not exactly clear so far about representing binary operators in a
decision
tree) Is this the right way to go ? I shall try to shortly post a patch that
implements this.
Yes, that's the way to go (well, I'd even use a switch ()).
b) Targeting GENERIC, separating AST from gimple/generic:
For generating a GENERIC pattern should there be another pattern
something like match_and_simplify_generic ?
Yes, there is an existing API in GCC for this that operates on GENERIC.
It's fold_unary_loc, fold_binary_loc, fold_ternary_loc. The interface
the GENERIC match_and_simplify variant provides should match
that one.
Currently, the AST data structures (operand, expr, etc.)
are tied to gimple (gen_gimple_match, gen_gimple_transform).
We could also have similar functions: gen_generic_match,
gen_generic_transform for generating GENERIC ?
Yeah, but I'm not sure if keeping the (virtual) methods for generating
code makes much sense with a rewritten code generator.
Instead will it be better if we separate the AST
from target IR (generic/gimple) and make simplify a visitor on AST
(make simplify
abstract class, with simplify_generic and simplify_gimple visitor
classes that generate corresponding IR code) ?
Yes. Keep in mind the current state of genmatch.c is quick hack
to make playing with the API side and with patterns possible ;)
c) Shall it be a good idea in define_match name pattern, for
name to act as a substitute for pattern (similar to flex pattern
definitions), so the name can be used in bigger patterns ?
Maybe, I suppose we'll see when adding more patterns.
d) This is silly, but maybe use constants to denote corresponding tree
nodes ?
for example instead of { build_int_cst (integer_type_node, 0); }, one
could directly write 0, to denote a INTEGER_CST node with value 0.
Yes, that might be possible - though it will require more knowledge
in the pattern matcher (you also want to match '0'?) and the code
generator.
e) There was a mention on the thread, regarding testing of patterns
integrated into DSL. I wasn't able to understand that clearly. Could
you explain that briefly ?
DSL? Currently I'd say it would be nice to make sure each pattern
is triggered by at least one GCC testcase - this requires looking
at a particular pass dump (that of forwprop or ccp are probably most suitable
as they are run very early). I mentioned the possibility to do offline
(thus not with C testcases) testing but that would require some tool
to do that and it would be correctness testing (some automatic proof
generation tool - ISTR academics have this kind of stuff). But that was
just an idea.
Regarding gsoc proposal, I would like to align it on the following points:
a) Pattern matching using decision tree
good.
b) Generate GIMPLE folding patterns (tree-ssa-forwprop,
tree-ssa-sccvn, gimple-fold)
I'd narrow it down a bit, you can optionally do more if time permits.
I'd say
0) add basic arithmetic identities (x + 0, x * 1, x / 1, etc., correctly
for all
Re: [gsoc 2014] moving fold-const patterns to gimple
On Fri, Mar 14, 2014 at 9:01 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
On Thu, Mar 13, 2014 at 4:44 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Mar 11, 2014 at 12:20 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Mar 10, 2014 at 7:29 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
Hi Richard,
Sorry for the late reply. I would like to have few clarifications
regarding the following points:
a) Pattern matching: Currently, gimple_match_and_simplify() matches
patterns one-by-one. Could we use a decision tree to do the matching
instead (similar to insn-recog.c) ?
For the moment, let's consider pattern matching on only unary
expressions without valueize and predicates:
pattern 1: (negate (negate @0))
pattern 2: (negate (bit_not @0))
from the two AST's corresponding to patterns (match::op), we can build
a decision tree:
Some-thing similar to:
NEGATE_EXPR
NEGATE_EXPRBIT_NOT_EXPR
and then generate code corresponding to this decision tree in
gimple-match.c
so the generated code should look something similar to:
tree
gimple_match_and_simplify (enum tree_code code, tree type, tree op0,
gimple_seq *seq, tree (*valueize)(tree))
{
if (code == NEGATE_EXPR)
{
tree captures[4] = {};
if (TREE_CODE (op0) != SSA_NAME)
return NULL_TREE;
gimple def_stmt = SSA_NAM_DEF_STMT (op0);
if (!is_gimple_assign (def_stmt))
return NULL_TREE;
tree op = gimple_assign_rhs1 (def_stmt);
if (gimple_assign_rhs_code (op) == NEGATE_EXPR)
{
/* pattern (negate (negate @0)) matched */
}
else if (gimple_assign_rhs_code (op) == BIT_NOT_EXPR)
{
/* pattern (negate (bit_not_expr @0)) matched */
}
else
return NULL_TREE;
}
else
return NULL_TREE;
}
For commutative ops, the pattern can be duplicated by walking the
children of the node in reverse order.
(I am not exactly clear so far about representing binary operators in a
decision
tree) Is this the right way to go ? I shall try to shortly post a patch
that
implements this.
Yes, that's the way to go (well, I'd even use a switch ()).
b) Targeting GENERIC, separating AST from gimple/generic:
For generating a GENERIC pattern should there be another pattern
something like match_and_simplify_generic ?
Yes, there is an existing API in GCC for this that operates on GENERIC.
It's fold_unary_loc, fold_binary_loc, fold_ternary_loc. The interface
the GENERIC match_and_simplify variant provides should match
that one.
Currently, the AST data structures (operand, expr, etc.)
are tied to gimple (gen_gimple_match, gen_gimple_transform).
We could also have similar functions: gen_generic_match,
gen_generic_transform for generating GENERIC ?
Yeah, but I'm not sure if keeping the (virtual) methods for generating
code makes much sense with a rewritten code generator.
Instead will it be better if we separate the AST
from target IR (generic/gimple) and make simplify a visitor on AST
(make simplify
abstract class, with simplify_generic and simplify_gimple visitor
classes that generate corresponding IR code) ?
Yes. Keep in mind the current state of genmatch.c is quick hack
to make playing with the API side and with patterns possible ;)
c) Shall it be a good idea in define_match name pattern, for
name to act as a substitute for pattern (similar to flex pattern
definitions), so the name can be used in bigger patterns ?
Maybe, I suppose we'll see when adding more patterns.
d) This is silly, but maybe use constants to denote corresponding tree
nodes ?
for example instead of { build_int_cst (integer_type_node, 0); }, one
could directly write 0, to denote a INTEGER_CST node with value 0.
Yes, that might be possible - though it will require more knowledge
in the pattern matcher (you also want to match '0'?) and the code
generator.
e) There was a mention on the thread, regarding testing of patterns
integrated into DSL. I wasn't able to understand that clearly. Could
you explain that briefly ?
DSL? Currently I'd say it would be nice to make sure each pattern
is triggered by at least one GCC testcase - this requires looking
at a particular pass dump (that of forwprop or ccp are probably most
suitable
as they are run very early). I mentioned the possibility to do offline
(thus not with C testcases) testing but that would require some tool
to do that and it would be correctness testing (some automatic proof
generation tool - ISTR academics have this kind of stuff). But that was
just an idea.
Regarding gsoc proposal, I would like to align it on the following points:
a) Pattern matching using decision tree
good.
b) Generate GIMPLE folding patterns (tree-ssa-forwprop,
tree-ssa-sccvn, gimple-fold)
I'd narrow it down a bit, you can optionally do more if time permits.
Re: [gsoc 2014] moving fold-const patterns to gimple
On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote: I had a look at PR 14753 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753) from the first link. I have tried to implement those transforms (attached patch, stage-1 compiled). I have written the transforms to operate on GENERIC. Why not directly gimple or the .pd file? Is that correct ? The patterns mentioned in the links were: a) (X CST1) = CST2 - X = CST2 CST1 however, an expression Y = CST gets folded to Y CST - 1 so the transform I wrote: (X CST1) CST2 - X CST2 CST1 That's not the same, try X=1, CST1=1, CST2=0. b) (X ~CST) == 0 - X = CST Uh, that can't be true for all constants, only some with a very specific shape (7 is 2^3-1). -- Marc Glisse
Re: Legitimize address after reload
On 03/14/14 05:52, David Guillen wrote: Hello, I'm writing a simple gcc backend and I'm experiencing a weird thing regarding address legitimation process. Two scenarios: If I only allow addresses to be either a register or symbols my gcc works. To do so I add the restrictions into the TARGET_LEGITIMATE_ADDRESS_P macro. This makes gcc to force registers for all the addresses. If I allow also a 'PLUS' expression to be a valid address (adding the restriction that the two addends are a register and a constant) it happens (sometimes) that gcc comes up with an expression like this one: (plus:SI (plus:SI (reg:SI somereg) (const_int 4)) (const_int 8)) After taking a look at the 386 backend (and others) I just discovered that there is a function called LEGITIMIZE_RELOAD_ADDRESS which is responsible for handling this case. My issue is that this function is not being called and, from what I saw while debugging, it seems that the offending RTX expression is created after the address_reload pass, and thus impossible for this pass to legitimize the address. Looking at other architectures it seems that they are doing more or less the same, so I don't know what the issue might be. LEGITIMIZE_RELOAD_ADDRESS is a hook that allows the target to rewrite invalid addresses during the reload pass in such a way that reload can generate the address more efficiently than the generic code in reload can do. It should always be safe for LEGITIMIZE_RELOAD_ADDRESS to do nothing. For your problem I'm sure it's a total red herring. Jeff
Re: [gsoc 2014] moving fold-const patterns to gimple
On Fri, Mar 14, 2014 at 9:25 PM, Marc Glisse marc.gli...@inria.fr wrote: On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote: I had a look at PR 14753 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753) from the first link. I have tried to implement those transforms (attached patch, stage-1 compiled). I have written the transforms to operate on GENERIC. Why not directly gimple or the .pd file? Is that correct ? The patterns mentioned in the links were: a) (X CST1) = CST2 - X = CST2 CST1 however, an expression Y = CST gets folded to Y CST - 1 so the transform I wrote: (X CST1) CST2 - X CST2 CST1 That's not the same, try X=1, CST1=1, CST2=0. Ah yes. Shall following be correct ? (X CST1) CST2 - X ( (CST2 + 1) CST1 ) - 1 Works correctly for X=1, CST1 = 1, CST2 = 0 (X CST1) CST2 = (X CST1) = (CST2 + 1) // this pattern is mentioned in PR = X = (CST2 + 1) CST1 = X ((CST2 + 1) CST1) - 1 b) (X ~CST) == 0 - X = CST Uh, that can't be true for all constants, only some with a very specific shape (7 is 2^3-1). Agreed. Shall the pattern be folded if CST is 2^(n-1) ? -- Marc Glisse
Re: [gsoc 2014] moving fold-const patterns to gimple
On Fri, Mar 14, 2014 at 4:31 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
On Thu, Mar 13, 2014 at 4:44 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Mar 11, 2014 at 12:20 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Mar 10, 2014 at 7:29 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
Hi Richard,
Sorry for the late reply. I would like to have few clarifications
regarding the following points:
a) Pattern matching: Currently, gimple_match_and_simplify() matches
patterns one-by-one. Could we use a decision tree to do the matching
instead (similar to insn-recog.c) ?
For the moment, let's consider pattern matching on only unary
expressions without valueize and predicates:
pattern 1: (negate (negate @0))
pattern 2: (negate (bit_not @0))
from the two AST's corresponding to patterns (match::op), we can build
a decision tree:
Some-thing similar to:
NEGATE_EXPR
NEGATE_EXPRBIT_NOT_EXPR
and then generate code corresponding to this decision tree in
gimple-match.c
so the generated code should look something similar to:
tree
gimple_match_and_simplify (enum tree_code code, tree type, tree op0,
gimple_seq *seq, tree (*valueize)(tree))
{
if (code == NEGATE_EXPR)
{
tree captures[4] = {};
if (TREE_CODE (op0) != SSA_NAME)
return NULL_TREE;
gimple def_stmt = SSA_NAM_DEF_STMT (op0);
if (!is_gimple_assign (def_stmt))
return NULL_TREE;
tree op = gimple_assign_rhs1 (def_stmt);
if (gimple_assign_rhs_code (op) == NEGATE_EXPR)
{
/* pattern (negate (negate @0)) matched */
}
else if (gimple_assign_rhs_code (op) == BIT_NOT_EXPR)
{
/* pattern (negate (bit_not_expr @0)) matched */
}
else
return NULL_TREE;
}
else
return NULL_TREE;
}
For commutative ops, the pattern can be duplicated by walking the
children of the node in reverse order.
(I am not exactly clear so far about representing binary operators in a
decision
tree) Is this the right way to go ? I shall try to shortly post a patch
that
implements this.
Yes, that's the way to go (well, I'd even use a switch ()).
b) Targeting GENERIC, separating AST from gimple/generic:
For generating a GENERIC pattern should there be another pattern
something like match_and_simplify_generic ?
Yes, there is an existing API in GCC for this that operates on GENERIC.
It's fold_unary_loc, fold_binary_loc, fold_ternary_loc. The interface
the GENERIC match_and_simplify variant provides should match
that one.
Currently, the AST data structures (operand, expr, etc.)
are tied to gimple (gen_gimple_match, gen_gimple_transform).
We could also have similar functions: gen_generic_match,
gen_generic_transform for generating GENERIC ?
Yeah, but I'm not sure if keeping the (virtual) methods for generating
code makes much sense with a rewritten code generator.
Instead will it be better if we separate the AST
from target IR (generic/gimple) and make simplify a visitor on AST
(make simplify
abstract class, with simplify_generic and simplify_gimple visitor
classes that generate corresponding IR code) ?
Yes. Keep in mind the current state of genmatch.c is quick hack
to make playing with the API side and with patterns possible ;)
c) Shall it be a good idea in define_match name pattern, for
name to act as a substitute for pattern (similar to flex pattern
definitions), so the name can be used in bigger patterns ?
Maybe, I suppose we'll see when adding more patterns.
d) This is silly, but maybe use constants to denote corresponding tree
nodes ?
for example instead of { build_int_cst (integer_type_node, 0); }, one
could directly write 0, to denote a INTEGER_CST node with value 0.
Yes, that might be possible - though it will require more knowledge
in the pattern matcher (you also want to match '0'?) and the code
generator.
e) There was a mention on the thread, regarding testing of patterns
integrated into DSL. I wasn't able to understand that clearly. Could
you explain that briefly ?
DSL? Currently I'd say it would be nice to make sure each pattern
is triggered by at least one GCC testcase - this requires looking
at a particular pass dump (that of forwprop or ccp are probably most
suitable
as they are run very early). I mentioned the possibility to do offline
(thus not with C testcases) testing but that would require some tool
to do that and it would be correctness testing (some automatic proof
generation tool - ISTR academics have this kind of stuff). But that was
just an idea.
Regarding gsoc proposal, I would like to align it on the following points:
a) Pattern matching using decision tree
good.
b) Generate GIMPLE folding patterns (tree-ssa-forwprop,
tree-ssa-sccvn, gimple-fold)
I'd narrow it down a bit, you can optionally do more if time permits.
Re: [gsoc 2014] moving fold-const patterns to gimple
On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote: On Fri, Mar 14, 2014 at 9:25 PM, Marc Glisse marc.gli...@inria.fr wrote: On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote: The patterns mentioned in the links were: a) (X CST1) = CST2 - X = CST2 CST1 however, an expression Y = CST gets folded to Y CST - 1 so the transform I wrote: (X CST1) CST2 - X CST2 CST1 That's not the same, try X=1, CST1=1, CST2=0. Ah yes. Shall following be correct ? (X CST1) CST2 - X ( (CST2 + 1) CST1 ) - 1 Works correctly for X=1, CST1 = 1, CST2 = 0 Looks better. Though there is still the case where the new constant overflows, in which case we can fold the comparison to false. b) (X ~CST) == 0 - X = CST Uh, that can't be true for all constants, only some with a very specific shape (7 is 2^3-1). Agreed. Shall the pattern be folded if CST is 2^(n-1) ? Wrong parentheses. And I didn't really think about it, so that may not be the right test. I think it would be a good idea to write, in comments, next to each non-trivial transformation, a short proof (at least some form of explanation). It would help people re-reading it later see quickly why the conditions are what they are. -- Marc Glisse
Re: Legitimize address after reload
David Guillen da...@davidgf.net writes: In any case I'm not using the restrict variable and I'm assuming strict is zero, this is, not checking the hard regsiters themselves. This is because any reg is OK for base reg. I'm pretty sure I'm behaving similarly to arm, cris or x86 backends. strict doesn't mean which hard register it is, strict means whether or not it's a hard register at all. If strict is true, you must assume any REG which isn't a real hard register (i.e. REGNO = FIRST_PSEUDO_REGISTER) does NOT match.
Integration of ISL code generator into Graphite
Dear gcc contributors, I am going to try to participate in Google Summer of Code 2014. My project is Integration of ISL code generator into Graphite. My proposal can be found at on the following link https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing . I would be very grateful for your comments, feedback and ideas about its improvement. - Roman Gareev
Re: Integration of ISL code generator into Graphite
On 03/14/2014 09:21 PM, Roman Gareev wrote: Dear gcc contributors, I am going to try to participate in Google Summer of Code 2014. My project is Integration of ISL code generator into Graphite. My proposal can be found at on the following link https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing . I would be very grateful for your comments, feedback and ideas about its improvement. Thanks Roman, I will have a look later on. For now, please make sure you already register now your proposal in Google Melange. You can always upload better/improved versions. Thanks, Tobias
PLEASE RE-ADD MIRRORS (small correction)
I made a small mistake below on the ftp/rsync mirrors for the USA mirror. They should be: (USA) http://mirrors-usa.go-parts.com/gcc ftp://mirrors-usa.go-parts.com/gcc rsync://mirrors-usa.go-parts.com/gcc From: dan1...@msn.com To: gcc@gcc.gnu.org Subject: PLEASE RE-ADD MIRRORS Date: Fri, 14 Mar 2014 16:53:22 -0700 Hello, We previously had these same mirrors up under Go-Part.com but then changed our domain to Go-Parts.com. The mirror links then dropped off. We apologize deeply for this, and assure you that this is a one-time event. Going forward, the mirrors will stay up for a very long time to come, and are being served from very reliable and fast servers, and being monitored and maintained by a very competent server admin team. PLEASE ADD: (USA) http://mirrors-usa.go-parts.com/gcc ftp://mirrors.go-parts.com/gcc rsync://mirrors.go-parts.com/gcc (Australia) http://mirrors-au.go-parts.com/gcc ftp://mirrors-au.go-parts.com/gcc rsync://mirrors-au.go-parts.com/gcc (Russia) http://mirrors-ru.go-parts.com/gcc ftp://mirrors-ru.go-parts.com/gcc rsync://mirrors-ru.go-parts.com/gcc Thanks, Dan
[Bug preprocessor/60492] Using the L#param in a macro fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492 --- Comment #6 from J.R. Heisey jr at heisey dot org --- Really? What rule would make this behavior expected?
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #2)
(In reply to Marc Glisse from comment #1)
I see in the dump:
# .MEM_4 = VDEF .MEM_8
D.2272 ={v} {CLOBBER};
# VUSE .MEM_4
_5 = MEM[(doubleD.39 *)D.2272];
which looks like something we could warn about in the middle-end.
Could you elaborate? My middle-end foo is not as good as it used to be.
_5 = MEM[(doubleD.39 *)D.2272];
says we are reading something inside variable D.2272. And right in the previous
instruction:
D.2272 ={v} {CLOBBER};
we clobbered the content of that variable, so what we are reading is nonsense.
These clobbers are specifically added to indicate when variables die (like your
temporary).
And we don't need to rely on the clobber being exactly the previous
instruction. The state of the memory (VUSE) when we execute the last
instruction was defined (VDEF) by the clobber instruction, typically
walk_aliased_vdefs would help you find the last instructions that touched
something related to the variable (get_ref_base_and_extent to get the variable
maybe?), the visitor would always stop, recording if the instruction was a
clobber, and you would check if all branches (or one branch for a -Wmaybe- type
of warning?) stopped on a clobber. Some passes may record enough information to
make the walk unnecessary, but I am not sure. And you may want to record
objects you have already warned about, to avoid flooding if a dead variable is
used a lot.
Now that I am describing it, there may already be code that does the same thing
for use-after-free or other cases?
Anyway, a hard part would be deciding in which pass to warn. And turning this
vague description (assuming it makes at least a bit of sense) into something
that actually works. And finding a right compromise between false positives and
false negatives. The usual...
[Bug preprocessor/60492] Using the L#param in a macro fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- E.g. in ISO C99, 6.10.3.2, you can read that #s is replaced by a single preprocessing token, but the mere fect that L immediately precedes it doesn't make it a part of the same preprocessing token. For wide character literals, the L needs to be part of the same preprocessing token as the string after it.
[Bug libstdc++/60521] New: std::lock_guard ignores adopt_lock strategy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60521
Bug ID: 60521
Summary: std::lock_guard ignores adopt_lock strategy
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: turchanov at farpost dot com
lock_guard created with constructor lock_guard::lock_guard(mutex_type m,
adopt_lock_t tag) must adopt already locked mutex. But current implementation
ignores completely this fact and tries to lock passed mutex unconditionally:
templatetypename _Mutex
class lock_guard {
...
lock_guard(mutex_type __m, adopt_lock_t) : _M_device(__m)
{ } // calling thread owns mutex
...
};
and given the fact that mutex type is not a recursive mutex this code sequence
produces a dead-lock:
mutex mtx;
mtx.lock();
lock_guardmutex guard(mtx, adopt_lock); // -- deadlocks!
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #4)
This change:
diff --git a/gcc/function.c b/gcc/function.c
index a61e475..3b6718f 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6238,6 +6238,7 @@ thread_prologue_and_epilogue_insns (void)
}
/* Now duplicate the tails. */
if (!bitmap_empty_p (bb_tail))
+ {
FOR_EACH_BB_REVERSE_FN (bb, cfun)
{
basic_block copy_bb, tbb;
@@ -6304,6 +6305,17 @@ thread_prologue_and_epilogue_insns (void)
if (bitmap_empty_p (bb_tail))
break;
}
+
+ /* Basic blocks may have been changed. Merge each basic block
+with its successor if possible. */
+ FOR_EACH_BB_FN (bb, cfun)
+ if (single_succ_p (bb))
+ {
+ basic_block succ_bb = single_succ (bb);
+ if (can_merge_blocks_p (bb, succ_bb))
+ merge_blocks (bb, succ_bb);
+ }
+ }
}
fail_shrinkwrap:
seems to work.
We have cfg_cleanup for this, no?
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine.
[Bug fortran/60522] New: WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 Bug ID: 60522 Summary: WHERE construct causes an ICE in gfc_trans_where_2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roger.ferrer at bsc dot es Hi, the following code ! -- test.f90 subroutine foo(a, b) implicit none integer, dimension(:), intent(inout) :: a integer, dimension(:), intent(in) :: b where (b(:) 0) a(lbound(a, 1):ubound(a, 1)) = b(lbound(b, 1):ubound(b, 1)) * b(lbound(b, 1):ubound(b, 1)) end where end subroutine foo ! -- end of test.f90 causes an ICE if optimization is enabled: $ gfortran -c test.f90 -O test.f90: In function ‘foo’: test.f90:6:0: internal compiler error: in gfc_trans_where_2, at fortran/trans-stmt.c:4550 where (B(:) 0) ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions. The problem goes away if the assignment is of the (equivalent) form: a(:) = b(:) * b(:) or a = b * b or if optimization is disabled. Kind regards,
[Bug libstdc++/60521] std::lock_guard ignores adopt_lock strategy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60521
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-03-14
Ever confirmed|0 |1
Severity|blocker |normal
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Sergei Turchanov from comment #0)
lock_guard(mutex_type __m, adopt_lock_t) : _M_device(__m)
{ } // calling thread owns mutex
Where in that code do you think it locks the mutex?
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Furthermore, it is already fixed since r208551.
[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems to be fixed now. Please reopen if there is some reason you wanted to keep this open.
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #6) Furthermore, it is already fixed since r208551. Indeed, the fix for PR57320 also fixed this one.
[Bug c/60523] New: Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 Bug ID: 60523 Summary: Warning flag for octal literals Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david at westcontrol dot com It would be nice if there were a warning flag that triggered on octal literals. Octal literals are rarely used in modern C and C++ code, but can easily be introduced by mistake - int x = 050; appears at first reading to set x to 50, but in C and C++ the leading 0 means it is interpreted as octal and therefore sets x to 40 (decimal). As octal literals are seldom useful, and often confusing or accidental, they are banned by coding standards like MISRA. But as they are part of the language defined by the C and C++ standards, and are used in some existing code, they obviously cannot be removed. As a compromise, I would like to propose the introduction of a warning flags -Woctal which would produce a diagnostic message when a literal is interpreted as an octal number. Of preference, this would be included in -Wextra (it probably should not be in -Wall, since octal literals are valid C and C++).
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Octal literals are very useful for expressing unix/posix file modes like 0777 or even 0666. So having the warning part of eith -Wall or -Wextra does not make sense.
[Bug fortran/60522] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-14 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. The ICE goes away when compiling with -fno-frontend-optimize. The test compiles with r171100 (2011-03-17) and gives the ICE with r171653 (2011-03-29). The changes of frontend-passes.c in this range are r171653, r171575, and r171207.
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, so it's branch_prob()s call of split_block that splits the common latch of
loops 1 and 2
bb 3: (header loop 1)
bb 4: (header loop 2, latch loop 2 and 1)
_2 = fn1 ();
if (_2 != 0)
goto bb 4;
else
goto bb 3;
the cfghook adjusts the latch of loop 2 properly (bb4s loop father is 2)
but fails to notice that bb4 is also the latch of loop 1 ... so this
CFG hook loop handling only handles this correctly if we have simple
latches (because there the latch always belongs to its loop).
Fix:
Index: gcc/cfghooks.c
===
--- gcc/cfghooks.c (revision 208536)
+++ gcc/cfghooks.c (working copy)
@@ -510,9 +510,13 @@ split_block (basic_block bb, void *i)
if (current_loops != NULL)
{
+ edge_iterator ei;
+ edge e;
add_bb_to_loop (new_bb, bb-loop_father);
- if (bb-loop_father-latch == bb)
- bb-loop_father-latch = new_bb;
+ /* Identify all loops bb may have been the latch of and adjust them. */
+ FOR_EACH_EDGE (e, ei, new_bb-succs)
+ if (e-dest-loop_father-latch == bb)
+ e-dest-loop_father-latch = new_bb;
}
res = make_single_succ_edge (bb, new_bb, EDGE_FALLTHRU);
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Mar 14 09:27:19 2014 New Revision: 208562 URL: http://gcc.gnu.org/viewcvs?rev=208562root=gccview=rev Log: PR target/59396 * config/avr/avr.c (avr_set_current_function): Pass function name through default_strip_name_encoding before sanity checking instead of skipping the first char of the assembler name. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Mar 14 09:41:51 2014 New Revision: 208564 URL: http://gcc.gnu.org/viewcvs?rev=208564root=gccview=rev Log: Backport from 2014-03-14 trunk r208562. PR target/59396 * config/avr/avr.c (avr_set_current_function): Pass function name through default_strip_name_encoding before sanity checking instead of skipping the first char of the assembler name. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/avr/avr.c
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Nothing obvious stands out. I presume that exceptions cannot be caught? OK, it's presumably http://gcc.gnu.org/ml/gcc/2013-12/msg00157.html but no ARM maintainer has stepped in yet. :-( Try this: Index: config/arm/arm.h === --- config/arm/arm.h(revision 208561) +++ config/arm/arm.h(working copy) @@ -937,13 +937,13 @@ extern int arm_arch_crc; #ifndef ARM_TARGET2_DWARF_FORMAT #define ARM_TARGET2_DWARF_FORMAT DW_EH_PE_pcrel +#endif /* ttype entries (the only interesting data references used) use TARGET2 relocations. */ #define ASM_PREFERRED_EH_DATA_FORMAT(code, data) \ (((code) == 0 (data) == 1 ARM_UNWIND_INFO) ? ARM_TARGET2_DWARF_FORMAT \ : DW_EH_PE_absptr) -#endif /* The native (Norcroft) Pascal compiler for the ARM passes the static chain as an invisible last argument (possible since varargs don't exist in
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Mar 14 09:52:07 2014 New Revision: 208565 URL: http://gcc.gnu.org/viewcvs?rev=208565root=gccview=rev Log: Backport from 2014-03-14 trunk r208562. PR target/59396 * config/avr/avr.c (avr_set_current_function): Pass function name through default_strip_name_encoding before sanity checking instead of skipping the first char of the assembler name. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr.c
[Bug debug/60524] New: Typedef information bypassed in dwarf2 function parameter information when it is 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60524
Bug ID: 60524
Summary: Typedef information bypassed in dwarf2 function
parameter information when it is 'const'
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: wpk at culm dot net
For following code:
typedef unsigned char Bar[12];
void foo(Bar *bar) {}
void fooconst(const Bar *bar) {}
compiled with gcc -gdwarf-2 -c, readelf -wi shows the foolowing dwarf-2 info:
For typedef Bar:
12d: Abbrev Number: 2 (DW_TAG_typedef)
2e DW_AT_name: Bar
32 DW_AT_decl_file : 1
33 DW_AT_decl_line : 1
34 DW_AT_type: 0x38
138: Abbrev Number: 3 (DW_TAG_array_type)
39 DW_AT_type: 0x4f
3d DW_AT_sibling : 0x48
For 'foo' function:
156: Abbrev Number: 6 (DW_TAG_subprogram)
(...)
58 DW_AT_name: foo
(...)
278: Abbrev Number: 7 (DW_TAG_formal_parameter)
79 DW_AT_name: bar
(...)
7f DW_AT_type: 0x87
(...)
187: Abbrev Number: 8 (DW_TAG_pointer_type)
88 DW_AT_byte_size : 8
89 DW_AT_type: 0x2d
This points to DW_TAG_typedef for 'Bar'
But for 'fooconst':
18d: Abbrev Number: 9 (DW_TAG_subprogram)
(...)
8f DW_AT_name: (indirect string, offset: 0x5c): fooconst
(...)
2af: Abbrev Number: 7 (DW_TAG_formal_parameter)
b0 DW_AT_name: bar
(..)
b6 DW_AT_type: 0xbe
(..)
1be: Abbrev Number: 8 (DW_TAG_pointer_type)
bf DW_AT_byte_size : 8
c0 DW_AT_type: 0x38
This points directly to unsigned char[12], completely bypassing typedef Bar
info.
GCC version info:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P4 |P5 Status|NEW |RESOLVED Known to work||4.8.1, 4.8.3 Version|4.8.3 |4.8.2 Resolution|--- |FIXED Target Milestone|--- |4.8.3 Known to fail||4.8.2 --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed in 4.8.3.
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #3)
(In reply to Manuel López-Ibáñez from comment #2)
(In reply to Marc Glisse from comment #1)
I see in the dump:
# .MEM_4 = VDEF .MEM_8
D.2272 ={v} {CLOBBER};
# VUSE .MEM_4
_5 = MEM[(doubleD.39 *)D.2272];
which looks like something we could warn about in the middle-end.
Could you elaborate? My middle-end foo is not as good as it used to be.
_5 = MEM[(doubleD.39 *)D.2272];
says we are reading something inside variable D.2272. And right in the
previous instruction:
D.2272 ={v} {CLOBBER};
we clobbered the content of that variable, so what we are reading is
nonsense. These clobbers are specifically added to indicate when variables
die (like your temporary).
Where is the clobber added? The closer to the FE that we warn, the better
diagnostic we can generate. I'm not very concerned about maybe-branches, since
I expect most bugs to appear in temporaries created in the middle of
expressions (such as a.getB().getA().x), where no branching occurs.
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I agree with Andrew - if we are ever to implement -Woctal, making it a part of -Wextra doesn't sound sensible. Especially with -Werror it'd be a pain.
[Bug lto/60461] [4.9 Regression] LTO linking error at -Os (and above) on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Fri Mar 14 10:49:05 2014 New Revision: 208566 URL: http://gcc.gnu.org/viewcvs?rev=208566root=gccview=rev Log: 2014-03-13 Martin Jambor mjam...@suse.cz PR lto/60461 * ipa-prop.c (ipa_modify_call_arguments): Fix iteration condition and simplify it. testsuite/ * gcc.dg/lto/pr60461_0.c: New test. Added: trunk/gcc/testsuite/gcc.dg/lto/pr60461_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I would suggest that you implement this as a plugin. Plugins are particularly useful for enforcing this type of coding standards. If you make a generally useful plugin like one enforcing MISRA standards, it could be distributed with GCC in order to serve as a testcase for the plugins framework.
[Bug target/60525] New: [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525
Bug ID: 60525
Summary: [4.9 Regression] ICE: in final_scan_insn, at
final.c:2952
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
markus@x4 libgcc % cat test.i
typedef struct
{
long w[2];
} UINT128;
extern UINT128 a[];
int b, c, f, g, h, i, l, m, o, p, q;
double d;
UINT128 j, k, t;
long n, r;
unsigned long s;
fn1 (UINT128 *p1, UINT128 p2, UINT128 p3)
{
int e;
if (p2.w[1])
p1-w[0] = p3.w[0];
e = d + p2.w[0];
if (p3.w[1])
c = e;
p1-w[1] = b;
}
fn2 ()
{
UINT128 u;
fn1 (t, j, k);
u = a[l];
int v, w;
o = t.w[0] 1;
w = u.w[1] 32;
n = t.w[0] * u.w[0];
q = r;
r = r + s + (n 32);
v = q + r 1;
r = o * u.w[0];
q = o * w;
r = r + s + (n 32);
m = q + r;
p = u.w[1] 32;
r = u.w[1];
s = 0;
r = r + t.w[1] + n;
i = v;
o = t.w[0];
h = k.w[1] * k.w[0];
g = j.w[1];
f = j.w[0];
}
markus@x4 libgcc % gcc -march=amdfam10 -O2 -c test.i
test.i: In function ‘fn2’:
test.i:47:1: error: could not split insn
}
^
(insn:TI 31 30 32 5 (parallel [
(set (reg:DF 22 xmm1 [orig:142 D.1904 ] [142])
(float:DF (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [7 %sfp+-16
S8 A64])))
(clobber (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8])) [0 S8 A64]))
]) test.i:16 219 {*floatdidf2_sse_with_temp}
(nil))
test.i:47:1: internal compiler error: in final_scan_insn, at final.c:2952
0x82e4c8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0x6a9d5a final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:2952
0x6a9fb6 final(rtx_def*, _IO_FILE*, int)
../../gcc/gcc/final.c:2023
0x6aa1e5 rest_of_handle_final
../../gcc/gcc/final.c:4427
0x6aa1e5 execute
../../gcc/gcc/final.c:4502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r208556.
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #5 from David Brown david at westcontrol dot com --- I agree that warnings to match something like the MISRA coding standards would be best done as a plugin. But I believe that in this case, warning on octal literals would be quite a small addition to the main gcc code. I am not familiar enough with the gcc source code to implement it myself (like many people, I blame lack of time) - I therefore registered this enhancement request in the hope that someone was /is/ familiar with this part of gcc would be able to make the change quickly and easily.
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #4)
Where is the clobber added?
front-end, I expect (sorry, I'm trying to get something to work on windows and
don't have my usual sources at hand).
The closer to the FE that we warn, the better
diagnostic we can generate.
Then do it in the front-end and ignore my message ;-)
I'm not very concerned about maybe-branches, since
I expect most bugs to appear in temporaries created in the middle of
expressions (such as a.getB().getA().x), where no branching occurs.
An exemple I have in mind is (pseudo):
ref id(ref x){return x;}
ref fun(){return id(temporary);}
where the function call hides that we are returning a reference to a temporary
(id could return a reference to a global object, for all fun knows) and we know
more after inlining (I need id inlined into fun, and either fun inlined into
something that uses its returned ref (so my previous technique works) or I
would need a different (middle-end) warning that detects return local_var,
which seems even easier except that it would give a lot of duplicates with
front-end warnings).
[Bug c/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-14 CC||mpolacek at gcc dot gnu.org Summary|-fdump-rtl-expand and |[4.7/4.8/4.9 Regression] |attribute optimize gives|-fdump-rtl-expand and |incorrect dump file path|attribute optimize gives ||incorrect dump file path Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. GCC 4.4 works.
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug lto/60461] [4.9 Regression] LTO linking error at -Os (and above) on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Mar 14 12:54:25 2014 New Revision: 208567 URL: http://gcc.gnu.org/viewcvs?rev=208567root=gccview=rev Log: 2014-03-14 Richard Biener rguent...@suse.de PR middle-end/60518 * cfghooks.c (split_block): Properly adjust all loops the block was a latch of. * g++.dg/pr60518.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr60518.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code Priority|P3 |P1 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Component|c |middle-end Target Milestone|--- |4.7.4
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marek Polacek from comment #1) Confirmed. GCC 4.4 works. Well, seems 4.4 puts the dump file in $PWD.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Anyway, this is because finish_options is called for every optimize attribute (handle_optimize_attribute-parse_optimize_attribute-decode_options-finish_options) + one more time for command line options and every time it adds the directory prefix. I guess we should add the directory prefix just once.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32347 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32347action=edit gcc49-pr58721.patch Untested patch.
[Bug fortran/60526] New: [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60526 Bug ID: 60526 Summary: [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org The following program is supposed to be invalid: type X end type type(X) :: X end 4.6 rejects it with: type(X) :: X 1 Error: Symbol 'x' at (1) cannot have a type 4.7, 4.8 and trunk however accept it happily. I think that is yet another regression caused by the constructor implementation in 4.7.
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-14 Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/60526] [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60526 --- Comment #1 from janus at gcc dot gnu.org --- See also https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/ZZ0iPFE7TFk for a discussion of ifort's behavior (which is the other way round than gfortran's: it used to accept it but now rejects it).
[Bug c++/53711] Wunused-function should warn for functions in the unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53711 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Mar 14 15:20:28 2014 New Revision: 208569 URL: http://gcc.gnu.org/viewcvs?rev=208569root=gccview=rev Log: PR c++/53711 * d++.dg/warn/anonymous-namespace-6.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-6.C
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #5) I would need a different (middle-end) warning that detects return local_var, To confirm this, I looked at the last dangling reference I debugged, recompiled it with -O3 -fkeep-inline-functions, and a grep for return in the .optimized dump showed: return one; return one; return D.495451.c_; (where one is a global variable, but D.495451 is a local variable) so even this trivial version of the warning would be useful.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32348action=edit gcc49-pr60484.patch Untested fix. Alternatively, e.g. finish_options could guard it also with loc == UNKNOWN_LOCATION (for calls other than the first one loc should be some real locus).
[Bug c/60527] New: Incorrectly removed if statement while doing int arithmetics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60527
Bug ID: 60527
Summary: Incorrectly removed if statement while doing int
arithmetics
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nicklas.ekstrand at sonymobile dot com
Created attachment 32349
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32349action=edit
Test program modtest.c
In the following code:
static int getZ() {
int tmp;
Z = Z * A + B;
tmp = Z;
if (tmp == INT_MIN)
tmp++;
if (tmp 0)
tmp = -tmp;
return tmp % MEMSIZE;
}
The if-statement tmp==INT_MIN is optimized away when using -O2 or higher, e.g.,
$ gcc -Wall -Wextra -g -O2 modtest.c -o pc_modtest -lrt
$ ./pc_modtest
arr=0x7fc1608be010
i=0 A=945 B=411
z1=231029 z2=-7483648
Segmentation fault
When using -O0 the problem doesn't happen and the program will not cause a
segmentation fault.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- I've just regtested a similar patch, so it looks good.
[Bug c/60527] Incorrectly removed if statement while doing int arithmetics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60527 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- You have an integer overflow in your code which is why the comparisons are being removed. if (tmp == INT_MIN) Can never happen because B is always a positive constant (411), so tmp has a range of [INT_MIN+411. INT_MAX]. The only way to get INT_MIN is if you had an overflow and overflows in C are undefined.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||rth at gcc dot gnu.org Resolution|FIXED |--- --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Supposedly csa pass could remove sp additions followed by setting of sp to something not based on sp?
[Bug rtl-optimization/60508] [4.8/4.9 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:1082
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri Mar 14 16:34:57 2014 New Revision: 208570 URL: http://gcc.gnu.org/viewcvs?rev=208570root=gccview=rev Log: 2014-03-14 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60508 * lra-constraints.c (get_reload_reg): Add new parameter in_subreg_p. (process_addr_reg, simplify_operand_subreg, curr_insn_transform): Pass the new parameter values. 2014-03-14 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60508 * gcc.target/i386/pr60508.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr60508.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marc Glisse from comment #6) (In reply to Marc Glisse from comment #5) I would need a different (middle-end) warning that detects return local_var, To confirm this, I looked at the last dangling reference I debugged, recompiled it with -O3 -fkeep-inline-functions, and a grep for return in the .optimized dump showed: return one; return one; return D.495451.c_; (where one is a global variable, but D.495451 is a local variable) so even this trivial version of the warning would be useful. To avoid duplicates, the front-end could just return something else, like NULL, when it detects this case (I guess the behavior is undefined and we can do whatever we want, no?).
[Bug target/60528] New: MIPS GCC puts out complex constant incorrectly when in big-endian mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60528
Bug ID: 60528
Summary: MIPS GCC puts out complex constant incorrectly when in
big-endian mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sje at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target: mips-*-*
The included test program prints out:
x = 0.634964 1.298458
x = inf inf
on MIPS instead of:
x = 0.634964 1.298458
x = 0.182506 1.163916
To reproduce the problem you need to compile the program with no optimization
(-O0) and in big-endian mode. Little endian mode seems fine. When I compare
the assembly language output to an earlier 4.8.1 GCC, the latest GCC output
contains the following code to store the complex constant passed in to csinh:
$LC0:
.word1071927711
.word3624173458
.word1073006203
.word1962331215
Earlier GCC compilers that worked contained:
$LC0:
.word1071927711
.word-670793838
.word1073006203
.word1962331215
Test case:
#include stdio.h
#include complex.h
#include math.h
int main()
{
double complex x;
x = 0.63496391478473613 + 1.2984575814159773I;
printf(x = %f %f\n, creal(x), cimag(x));
x = csinh(x);
printf(x = %f %f\n, creal(x), cimag(x));
return 0;
}
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- It also breaks nearly every test in SPEC 2k and 2k6 ;)
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org ---
Unfortunately the patch regresses abi_check in libstdc++, libstdc++.so.6 now
because of the patch exports
_ZNSt12system_errorC1ESt10error_codeRKSs@@GLIBCXX_3.4.11
_ZNSt12system_errorC2ESt10error_codeRKSs@@GLIBCXX_3.4.11
symbols.
This is caused by wastly different inlining decisions (and the decisions don't
look like an improvement to me) on thread.cc.
Debugging this, I'm seeing this is caused by Honza's predict.c changes.
E.g. quite often we have tree_predict_by_opcode called on
__gthrw___pthread_key_create != 0. When we call expr_expected_value_1 on
this,
it returns a NE_EXPR (__gthrw___pthread_key_create is weakref), but with
TREE_CONSTANT set on it. That is reasonable, the comparison will be either
always true, or always false, but without explicit __builtin_expect from the
user I actually don't see a reason why we should predict it as always true.
So, I wonder if we shouldn't do on top of the #c19 patch:
--- gcc/predict.c.jj2014-03-14 13:16:15.0 +0100
+++ gcc/predict.c2014-03-14 17:49:11.686411889 +0100
@@ -2066,7 +2066,7 @@ tree_predict_by_opcode (basic_block bb)
visited = BITMAP_ALLOC (NULL);
val = expr_expected_value_1 (boolean_type_node, op0, cmp, op1, visited,
predictor);
BITMAP_FREE (visited);
- if (val TREE_CONSTANT (val))
+ if (val TREE_CODE (val) == INTEGER_CST)
{
if (predictor == PRED_BUILTIN_EXPECT)
{
That change seems to slightly improve the inlining decisions on thread.ii, e.g.
_ZN9__gnu_cxxL27__exchange_and_add_dispatchEPii.part.1.constprop.11 seems to be
inlined again, but _ZNSt12system_errorC1ESt10error_codeRKSs and
_ZNSt12system_errorC2ESt10error_codeRKSs are still no longer inlined.
Comparing to gcc with all the patches but all the predict.c #c19 and the above
bits reverted, I see that (looking at -m32 -O2 ...) the
_ZNSt12system_errorC1ESt10error_codeRKSs function (the other symbol is an alias
to it) is 601 bytes long and
_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE caller
406 bytes long with the predict.c changes and
_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE is 889 bytes
long with the predict.c changes reverted (the
_ZNSt12system_errorC1ESt10error_codeRKSs function is inlined then).
So, size wise it is a win to inline it, but not significant, and the function
is in any case larger than the caller.
Honza, your thoughts on this?
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #7) To avoid duplicates, the front-end could just return something else, like NULL, when it detects this case (I guess the behavior is undefined and we can do whatever we want, no?). I guess... Then we might as well introduce a call to __builtin_unreachable right before the return, at the same time as we replace the return value.
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- Octal literals are also used in macro definitions from system headers, so care would be needed that a warning doesn't apply to those. Such a warning should of course not apply to 0 (and maybe more generally should not apply to any octal constant consisting of some number of leading 0s followed by at most one nonzero digit, as those have the same value whether interpreted as octal or as decimal).
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org --- Created attachment 32350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32350action=edit proposed patch In the description for the patch in question, I mentioned how during stage1 we could clean up all these patterns to rely on LRA. The fact that this pr was filed immediately suggests that the current setup is quite difficult to follow. Cleaning this up now instead of waiting for stage1 would seem to be the way to make sure we get all the cases right.
[Bug fortran/60529] New: internal compiler error with allocatable sub-component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60529 Bug ID: 60529 Summary: internal compiler error with allocatable sub-component Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: carlos.a.cruz at nasa dot gov Using the following compiler release: GNU Fortran (GCC) 4.9.0 20140309 (experimental) on the following reproducer: --- module T_mod implicit none type :: TS integer, allocatable :: i(:) end type TS type :: T ! The following line causes an internal compiler error. type (TS) :: s(1) ! The following line does not: !type (TS), allocatable :: s(:) end type T contains subroutine insert(this) class(T) :: this end subroutine insert end module T_mod --- yields an internal compiler error: repro.F90: In function ‘__final_t_mod_T’: repro.F90:19:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:145 end module T_mod ^ 0x511048 ??? ../sysdeps/x86_64/elf/start.S:113 I am running on a Linux cluster: Linux discover28 2.6.32.54-0.3-default #1 SMP 2012-01-27 17:38:56 +0100 x86_64 x86_64 x86_64 GNU/Linux Note that the internal compiler error does not occur with two earlier releases of gfortran: GNU Fortran (GCC) 4.9.0 20140105 (experimental) GNU Fortran (GCC) 4.8.1
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri Mar 14 17:58:52 2014 New Revision: 208571 URL: http://gcc.gnu.org/viewcvs?rev=208571root=gccview=rev Log: PR middle-end/60484 * common.opt (dump_base_name_prefixed): New Variable. * opts.c (finish_options): Don't prepend directory to x_dump_base_name if x_dump_base_name_prefixed is already set, set it at the end. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/opts.c
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #9 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #7) To avoid duplicates, the front-end could just return something else, like NULL, when it detects this case (I guess the behavior is undefined and we can do whatever we want, no?). Actually, for a function that returns a reference, we may also want to warn if we detect that it is returning NULL. And a function returning a pointer could be marked returns_nonnull. In both cases we would be introducing a new warning, more confusing than a duplicate. But there are probably small variations on this idea that would work.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #20) Unfortunately the patch regresses abi_check in libstdc++, libstdc++.so.6 now because of the patch exports _ZNSt12system_errorC1ESt10error_codeRKSs@@GLIBCXX_3.4.11 _ZNSt12system_errorC2ESt10error_codeRKSs@@GLIBCXX_3.4.11 symbols. Those will not be exported now.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Mar 14 18:10:59 2014 New Revision: 208572 URL: http://gcc.gnu.org/viewcvs?rev=208572root=gccview=rev Log: PR ipa/58721 * config/abi/pre/gnu.ver (GLIBCXX_3.4.11): Remove unused pattern for _ZNSt12system_errorC* symbols which are not exported on any target. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Henderson from comment #3) Created attachment 32350 [details] proposed patch In the description for the patch in question, I mentioned how during stage1 we could clean up all these patterns to rely on LRA. The fact that this pr was filed immediately suggests that the current setup is quite difficult to follow. Cleaning this up now instead of waiting for stage1 would seem to be the way to make sure we get all the cases right. Your patch doesn't bootstrap: /var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -march=native -O3 -pipe -O2 -march=native -O3 -pipe -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _fixunssfdi.o -MT _fixunssfdi.o -MD -MP -MF _fixunssfdi.dep -DL_fixunssfdi -c ../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/libgcc2.c: In function ‘__fixunssfti’: ../../../gcc/libgcc/libgcc2.c:1492:1: error: unrecognizable insn: } ^ (insn 103 102 36 7 (set (reg:V2DF 22 xmm1 [104]) (vec_merge:V4SF (vec_duplicate:V4SF (float:SF (mem/c:DI (plus:DI (reg/f:DI 7 sp) (const_int -16 [0xfff0])) [3 %sfp+-8 S8 A64]))) (reg:V2DF 22 xmm1 [104]) (const_int 1 [0x1]))) ../../../gcc/libgcc/libgcc2.c:1449 -1 (nil)) ../../../gcc/libgcc/libgcc2.c:1492:1: internal compiler error: in extract_insn, at recog.c:2241 Please submit a full bug report, with preprocessed source if appropriate
[Bug lto/60530] New: openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 Bug ID: 60530 Summary: openssh-6.5p1 can't be built with lto - revision 208516 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Created attachment 32351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32351action=edit Un-reduced preprocessed source file gzipped The only one object file causing the erro from -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o is ssh.o. x86_64-pc-linux-gnu-gcc -o ssh ssh.i -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -pie -lssh -lopenbsd-compat -lssl -lcrypto -ldl -lutil -lz -lnsl -lcrypt -lresolv -lpthread umac.c:1193:3: warning: type of 'umac_ctx' does not match original declaration } umac_ctx; ^ ./umac.c:1193:3: note: previously declared here } umac_ctx; ^ /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccKc90pS.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /tmp/ccKc90pS.ltrans0.ltrans.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status
[Bug lto/60530] openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- When system libraries are removed, ssh.i file links to ssh file: x86_64-pc-linux-gnu-gcc -o ssh ssh.i -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -r -nostdlib ls -l ssh -rw-r--r-- 1 root root 129751 Mar 14 19:21 ssh
[Bug lto/60530] openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to David Kredba from comment #0) Created attachment 32351 [details] Un-reduced preprocessed source file gzipped The only one object file causing the erro from -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o is ssh.o. x86_64-pc-linux-gnu-gcc -o ssh ssh.i -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -pie -lssh -lopenbsd-compat -lssl -lcrypto -ldl -lutil -lz -lnsl -lcrypt -lresolv -lpthread umac.c:1193:3: warning: type of 'umac_ctx' does not match original declaration } umac_ctx; ^ ./umac.c:1193:3: note: previously declared here } umac_ctx; ^ /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/../../../../x86_64-pc- linux-gnu/bin/ld: /tmp/ccKc90pS.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /tmp/ccKc90pS.ltrans0.ltrans.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status When -pie is used, you need to add -fpie.
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.9.0 --- Comment #10 from John David Anglin danglin at gcc dot gnu.org --- On hppa2.0w-hp-hpux11.11 with 4.9.0, the error has changed: Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show- caret -fdiagnostics-color=never -O2 -S -o large-size-array-6.s(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show-caret -fdiagno stics-color=never -O2 -S -o large-size-array-6.s /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c:6:3: internal compil er error: in tree_to_uhwi, at tree.h:3653
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #33 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Mar 14 19:06:54 2014 New Revision: 208573 URL: http://gcc.gnu.org/viewcvs?rev=208573root=gccview=rev Log: PR c++/58678 * search.c (dfs_get_pure_virtuals): Treat the destructor of an abstract class as pure. Added: trunk/gcc/testsuite/g++.dg/ipa/devirt-30.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Jason Merrill jason at gcc dot gnu.org --- (In reply to David Kredba from comment #31) Calligra-2.8.0 is now affected too Does the patch I just checked in fix Calligra? If not, please reopen the bug with a testcase.
[Bug fortran/60522] [4.7/4.8/4.9 Regression] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|WHERE construct causes an |[4.7/4.8/4.9 Regression] |ICE in gfc_trans_where_2|WHERE construct causes an ||ICE in gfc_trans_where_2 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Forgot to mark the PR as a regression. The ICE is due to the gcc_unreachable at default: gcc_unreachable (); meaning that cnext-op has not one of the expected values in the switch.
[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 --- Comment #9 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Mar 14 19:36:18 2014 New Revision: 208574 URL: http://gcc.gnu.org/viewcvs?rev=208574root=gccview=rev Log: 2014-03-12 Michael Meissner meiss...@linux.vnet.ibm.com Back port from trunk 2013-04-25 Alan Modra amo...@gmail.com PR target/57052 * config/rs6000/rs6000.md (rotlsi3_internal7): Rename to rotlsi3_internal7le and condition on !BYTES_BIG_ENDIAN. (rotlsi3_internal8be): New BYTES_BIG_ENDIAN insn. Repeat for many other rotate/shift and mask patterns using subregs. Name lshiftrt insns. (ashrdisi3_noppc64): Rename to ashrdisi3_noppc64be and condition on WORDS_BIG_ENDIAN. 2013-06-07 Alan Modra amo...@gmail.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't override user -mfp-in-toc. (offsettable_ok_by_alignment): Consider just the current access rather than the whole object, unless BLKmode. Handle CONSTANT_POOL_ADDRESS_P constants that lack a decl too. (use_toc_relative_ref): Allow CONSTANT_POOL_ADDRESS_P constants for -mcmodel=medium. * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't override user -mfp-in-toc or -msum-in-toc. Default to -mno-fp-in-toc for -mcmodel=medium. 2013-06-18 Alan Modra amo...@gmail.com * config/rs6000/rs6000.h (enum data_align): New. (LOCAL_ALIGNMENT, DATA_ALIGNMENT): Use rs6000_data_alignment. (DATA_ABI_ALIGNMENT): Define. (CONSTANT_ALIGNMENT): Correct comment. * config/rs6000/rs6000-protos.h (rs6000_data_alignment): Declare. * config/rs6000/rs6000.c (rs6000_data_alignment): New function. 2013-07-11 Ulrich Weigand ulrich.weig...@de.ibm.com * config/rs6000/rs6000.md (*tls_gd_lowTLSmode:tls_abi_suffix): Require GOT register as additional operand in UNSPEC. (*tls_ld_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_dtprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_tprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_gdTLSmode:tls_abi_suffix): Update splitter. (*tls_ldTLSmode:tls_abi_suffix): Likewise. (tls_got_dtprel_TLSmode:tls_abi_suffix): Likewise. (tls_got_tprel_TLSmode:tls_abi_suffix): Likewise. 2014-01-23 Pat Haugen pthau...@us.ibm.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't force flag_ira_loop_pressure if set via command line. 2014-02-06 Alan Modra amo...@gmail.com PR target/60032 * config/rs6000/rs6000.c (rs6000_secondary_memory_needed_mode): Only change SDmode to DDmode when lra_in_progress. Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/linux64.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000-protos.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Mar 14 19:36:18 2014 New Revision: 208574 URL: http://gcc.gnu.org/viewcvs?rev=208574root=gccview=rev Log: 2014-03-12 Michael Meissner meiss...@linux.vnet.ibm.com Back port from trunk 2013-04-25 Alan Modra amo...@gmail.com PR target/57052 * config/rs6000/rs6000.md (rotlsi3_internal7): Rename to rotlsi3_internal7le and condition on !BYTES_BIG_ENDIAN. (rotlsi3_internal8be): New BYTES_BIG_ENDIAN insn. Repeat for many other rotate/shift and mask patterns using subregs. Name lshiftrt insns. (ashrdisi3_noppc64): Rename to ashrdisi3_noppc64be and condition on WORDS_BIG_ENDIAN. 2013-06-07 Alan Modra amo...@gmail.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't override user -mfp-in-toc. (offsettable_ok_by_alignment): Consider just the current access rather than the whole object, unless BLKmode. Handle CONSTANT_POOL_ADDRESS_P constants that lack a decl too. (use_toc_relative_ref): Allow CONSTANT_POOL_ADDRESS_P constants for -mcmodel=medium. * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't override user -mfp-in-toc or -msum-in-toc. Default to -mno-fp-in-toc for -mcmodel=medium. 2013-06-18 Alan Modra amo...@gmail.com * config/rs6000/rs6000.h (enum data_align): New. (LOCAL_ALIGNMENT, DATA_ALIGNMENT): Use rs6000_data_alignment. (DATA_ABI_ALIGNMENT): Define. (CONSTANT_ALIGNMENT): Correct comment. * config/rs6000/rs6000-protos.h (rs6000_data_alignment): Declare. * config/rs6000/rs6000.c (rs6000_data_alignment): New function. 2013-07-11 Ulrich Weigand ulrich.weig...@de.ibm.com * config/rs6000/rs6000.md (*tls_gd_lowTLSmode:tls_abi_suffix): Require GOT register as additional operand in UNSPEC. (*tls_ld_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_dtprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_tprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_gdTLSmode:tls_abi_suffix): Update splitter. (*tls_ldTLSmode:tls_abi_suffix): Likewise. (tls_got_dtprel_TLSmode:tls_abi_suffix): Likewise. (tls_got_tprel_TLSmode:tls_abi_suffix): Likewise. 2014-01-23 Pat Haugen pthau...@us.ibm.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't force flag_ira_loop_pressure if set via command line. 2014-02-06 Alan Modra amo...@gmail.com PR target/60032 * config/rs6000/rs6000.c (rs6000_secondary_memory_needed_mode): Only change SDmode to DDmode when lra_in_progress. Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/linux64.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000-protos.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #5 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) -march=native For what host?
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Attachment #32350|0 |1 is obsolete|| --- Comment #6 from Richard Henderson rth at gcc dot gnu.org --- Created attachment 32352 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32352action=edit second patch Testing showed some -m32 failures requiring minor tweaks.
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Henderson from comment #5) (In reply to Markus Trippelsdorf from comment #4) -march=native For what host? Like in comment0: -march=amdfam10
[Bug fortran/60522] [4.7/4.8/4.9 Regression] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3 from Mikael Morin mikael at gcc dot gnu.org ---
BLOCK constructs are not allowed inside WHERE constructs.
Thus, the common function optimization should not create a BLOCK to hold the
temporary variables, at least not inside WHERE.
Another possible fix, the following patch disables the optimization inside
WHERE.
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 52bd700..dc641de 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -630,9 +630,16 @@ static int
cfe_code (gfc_code **c, int *walk_subtrees ATTRIBUTE_UNUSED,
void *data ATTRIBUTE_UNUSED)
{
- current_code = c;
- inserted_block = NULL;
- changed_statement = NULL;
+ /* BLOCK constructs cannot appear inside WHERE blocks; as the optimization
+ may introduce the former we disable it inside the latter. */
+ if ((*c)-op == EXEC_WHERE)
+*walk_subtrees = 0;
+ else
+{
+ current_code = c;
+ inserted_block = NULL;
+ changed_statement = NULL;
+}
return 0;
}
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 32353 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32353action=edit A patch This patch checks LEAVE and remove stack deallocation. It removes 5 stack deallocations in cc1plus on Linux/i686.
[Bug c++/60531] New: template function not resolved when comparing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60531
Bug ID: 60531
Summary: template function not resolved when comparing
functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
template typename T void f();
int main() { fint == fint; }
is rejected with
test.cc: In function ‘int main()’:
test.cc:2:24: error: invalid operands of types ‘unresolved overloaded function
type’ and ‘unresolved overloaded function type’ to binary ‘operator==’
int main() { fint == fint; }
I see no reason why this would be invalid, and it is accepted by all other
compilers I was able to test (clang, Intel, Sun, MSVC), but it is rejected by
GCC at least as far back as 4.3.
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Fri Mar 14 21:28:59 2014 New Revision: 208581 URL: http://gcc.gnu.org/viewcvs?rev=208581root=gccview=rev Log: fortran/ PR fortran/60392 * trans-array.c (gfc_conv_array_parameter): Don't reuse the descriptor if it has transposed dimensions. testsuite/ PR fortran/60392 * gfortran.dg/transpose_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transpose_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
