RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat

[Thomas Preud'homme]

 From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
 
 Thomas Preud'homme thomas.preudho...@arm.com writes:
 
 -mno-float causes gcc to define the macro __mips_no_float, which the
 implementation can use when deciding whether to bother handling %f, etc.
 I'm afraid there's nothing more sophisticated to it than that.
 

So the libc needs to be compiled with -mno-float as well so that printf and
scanf drop the float handling? 

  In ARM case the calling convention also determine how to pass
  structures of 4 or less floats/double so there would also be an
  arch-dependent part. I am not sure about whether to add a new hook or
  provide helper function in the middle end for the backend to use.
 
 I assume for most cases the restriction is of the form calling this
 function must not use registers in class X.  I think we can detect
 that using the existing hooks.

I wish that information would be enough. Unfortunately, it's not.
Suppose your code is compiler with a soft float ABI. Then, your float do not
use any special register and yet, they make your code dependent on the
float ABI. Therefore, the real question you are asking the backend is:
is the register allocation for this parameter dependent on the float ABI?.
I do not think any current hook gives you this information.

Ideally that would be a new version of the function_arg and function_value
hook that takes a pointer to a boolean variable for the backend to give this
information. Alternatively, it could be a new variable hook that the middle
end [0] and back end would modify.

[0] The middle end needs to be able to reset the variable to detect all the
function that break the compatibility instead of just the first one, unless
the variable is an integer that gets incremented.

 
 A more general restriction would be must pass arguments in the same
 way for both option set A and option set B.  That too could be done
 using existing hooks and SWITCHABLE_TARGET, although it might not be
 hyper-efficient.

I don't know how exactly that would work. You would switch twice for
each function and ask the register used for each function call?

Best regards,

Thomas Preud'homme

Re: [gsoc 2014] moving fold-const patterns to gimple

[Richard Biener]

On Thu, Mar 20, 2014 at 9:52 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
 On Wed, Mar 19, 2014 at 3:13 PM, Richard Biener
 richard.guent...@gmail.com wrote:
 On Tue, Mar 18, 2014 at 9:04 AM, Prathamesh Kulkarni
 bilbotheelffri...@gmail.com wrote:
 On Mon, Mar 17, 2014 at 2:22 PM, Richard Biener
 richard.guent...@gmail.com wrote:
 On Sun, Mar 16, 2014 at 1:21 PM, Prathamesh Kulkarni
 bilbotheelffri...@gmail.com wrote:
 In c_expr::c_expr, shouldn't OP_C_EXPR be passed to operand
 constructor instead of OP_EXPR ?

 Indeed - I have committed the fix.

 Hi, I have attached an initial draft of my proposal.
 I would be grateful to receive your feedback.

 Ok, I had a look at the proposal and it is mostly fine.  I'd be more specific
 on the deliverables, specifically

 1) genmatch - program to read meta description and generate code to
 simplify GENERIC and GIMPLE according to the pattern descriptions
 using an algorithm not linear in the number of patterns

 2) add patterns matched by tree-ssa-forwprop.c (and thus patterns
 in fold-const.c it depends on) to the meta-description and perform
 the simplifications of tree-ssa-forwprop.c in terms of the simplification API

 You will figure out that there are possibly a lot of patterns in fold-const.c
 that forwprop depends on (I know mainly of all the comparison 
 simplifications).

 For the Timeline I'd move e) as a sub-task of f) to June 28 - July 16,
 eventually just dividing the weeks of July 17 - August 11 to that and
 the following task.

 That is, the overall deliverable should be a tree-ssa-forwprop.c that is
 (mostly) implemented in terms of patterns, ready for commit to trunk
 during stage1.

 As for targeting GENERIC, useful testing coverage of that path will
 come from for example re-writing fold-const.c:fold_comparison using
 the GENERIC API of the pattern simplifier.

 The devil will be in the details (as always) ;)

 As Maxim said - make sure to register your proposal in-time, you
 can always improve on it later.

 Thanks for the feedback. I have uploaded it:
 http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/prathamesh3492/5629499534213120
 Would you like to suggest any further changes ?
 There are a few formatting glitches, I am fixing those.

 Could you help me point out how to write test-cases for transforms ?
 For example:
 /* Fold ~A + 1 - -A */
 (match_and_simplify
   (PLUS_EXPR (BIT_NOT_EXPR @0) @1)
   if (@1 == integer_one_node)
   (NEGATE_EXPR @0))

 Is the following test-case correctly written ?
 /* { dg-do compile } */
 /* { dg-options -O -fdump-tree-forwprop }  */

 int foo (int x)
 {
   int temp1 = ~x;
   int temp2 = temp1 + 1;
   return temp2;
 }

 /* { dg-final { scan-tree-dump temp* = -x*(D) forwprop1 } } */
 Shall that be (somewhat) correct ?

Yes, though the pattern to scan for may be somewhat fragile (generally
avoid using '*' there but use \[^\n\r\]* to avoid getting false matches across
newlines).

 (Unfortunately, I cannot check if I have written the test-case correctly,
 because I am in the middle of a bootstrap build.
 Is there a way to run test-cases on only stage-1 compiler ?
 I tried make check-cc1 RUNTESTFLAGS=dg.exp=tree-ssa/match-2.c but that
 did not work).

I usually do development on a separate build directory that I configure
like

CFLAGS=-g CXXFLAGS=-g /src/configure --disable-bootstrap
make CFLAGS=-g CXXFLAGS=-g

then I can test incremental changes by in gcc/ doing

 make cc1
 make check-gcc RUNTESTFLAGS=tree-ssa.exp=match-2.c

Richard.

 forwprop output is:
 ;; Function foo (foo, funcdef_no=0, decl_uid=1743, symbol_order=0)

 gimple_match_and_simplified to temp2_3 = -x_1(D);
 foo (int x)
 {
   int temp2;
   int temp1;

   bb 2:
   temp1_2 = ~x_1(D);
   temp2_3 = -x_1(D);
   temp2_4 = temp2_3;
   return temp2_4;

 }

 Thanks and Regards,
 Prathamesh

 Thanks,
 Richard.

 Thanks and Regards,
 Prathamesh
 Thanks,
 Richard.

 This caused segfault for patterns when simplification operand was
 only c_expr (patch attached).

 * genmatch.c (c_expr::c_expr): use OP_C_EXPR instead of OP_EXPR in
 call to operand constructor.

Re: Request for discussion: Rewrite of inline assembler docs

[James Greenhalgh]

On Thu, Feb 27, 2014 at 11:07:21AM +, Andrew Haley wrote:
 Over the years there has been a great deal of traffic on these lists
 caused by misunderstandings of GCC's inline assembler.  That's partly
 because it's inherently tricky, but the existing documentation needs
 to be improved.
 
 dw limegreenso...@yahoo.com has done a fairly thorough reworking of
 the documentation.  I've helped a bit.
 
 Section 6.41 of the GCC manual has been rewritten.  It has become:
 
 6.41 How to Use Inline Assembly Language in C Code
 6.41.1 Basic Asm - Assembler Instructions with No Operands
 6.41.2 Extended Asm - Assembler Instructions with C Expression Operands
 
 We could simply post the patch to GCC-patches and have at it, but I
 think it's better to discuss the document here first.  You can read it
 at

This documentation looks like a huge improvement.

As the discussion here seems to have stalled, perhaps it is time to propose
the patch to gcc-patches?

I'm certainly keen to see this make it to trunk, the increase in clarity
is substantial.

Thanks,
James

Re: Integration of ISL code generator into Graphite

[Tobias Grosser]

On 03/21/2014 12:04 PM, Roman Gareev wrote:

Hi Tobias,

thank you for all your comments! I've tried to consider them in the
improved version of my proposal, which can be found at the following
link 
https://drive.google.com/file/d/0B2Wloo-931AoeUlYOHhETVBvY3M/edit?usp=sharing
.


- In unreleased isl 0.13.0, support for compute out feature


I haven't found information about this feature and isl 0.13.0. Could
you please give me a link to be referred to in the proposal?


Section 1.4.1 of the isl manual documents the following functions:

void isl_ctx_set_max_operations(isl_ctx *ctx,
unsigned long max_operations);
unsigned long isl_ctx_get_max_operations(isl_ctx *ctx);
void isl_ctx_reset_operations(isl_ctx *ctx);


- Improved code generation quality


I also haven't found code quality comparison between CLooG and ISL
code generator. Do you mean, that ISL code generator can improve code
quality with unrolling, full/partial tile separation, fine-grained
code size adjustments?


We have an unpublished paper on this. We should probably make this a 
tech report at some point.



- New internal representaion will be generated by ISL. Its structure is
planned to be similar to the CLAST tree, but can be changed ...

What does this  mean? The isl_ast representation is already defined. Are you
saying that isl may generate an ast that is different in structure to the
clast tree currently generated? Or are you saying we
still need to define the isl_ast and its nodes itself?


I wanted to say that ISL will generate ISL AST from the polyhedral
representation. This ISL AST (with pointers to original basic blocks
instead of statments) will be internal representation for Graphite,
that should be traversed and transformed into the GIMPLE CFG. I
eliminated the mention of this internal representation in the improved
version of the proposal.


Good.

I think this proposal is already very nice. I have some last comments in 
case you want to really polish it:


o 26-31 May: Get familiar with CLooG generation?

Why is this necessary?


Also, for the remaining time-line, I think you could start working on 
making this more detailed.


Instead of having separate testing and fixing bug weeks, I think it 
would be optimal to have for each weak one topic that you plan to finish 
(including testing and fixing), as well as a brief idea how to do it. 
You already have a good idea of what is needed, but you could detail 
this further by looking through the exiting source code (or by looking 
into Polly's IslCodeGeneration.cpp) to see what is needed.


In which week are you e.g. planning to write the code to generate 
isl_ast_expr?


Which pieces of the code are you planning to reuse?

Are you planning to split of pieces of the code that can be shared by 
CLooG and isl, before fully removing CLooG?


Cheers,
Tobias

GIMPLE tree dumping of, for example, GIMPLE_OMP_PARALLEL's CHILD_FN

[Thomas Schwinge]

Hi!

Certain GIMPLE codes, such as OpenMP ones, have a structured block
attached to them, for exmaple, gcc/gimple.def:GIMPLE_OMP_PARALLEL:

/* GIMPLE_OMP_PARALLEL BODY, CLAUSES, CHILD_FN, DATA_ARG represents

   #pragma omp parallel [CLAUSES]
   BODY

   BODY is a the sequence of statements to be executed by all threads.
[...]
   CHILD_FN is set when outlining the body of the parallel region.
   All the statements in BODY are moved into this newly created
   function when converting OMP constructs into low-GIMPLE.
[...]
DEFGSCODE(GIMPLE_OMP_PARALLEL, gimple_omp_parallel, 
GSS_OMP_PARALLEL_LAYOUT)

Using -ftree-dump-all, I can see this structured block (BODY) getting
dumped, but it then disappears in the ompexp pass', and reappears (as
function main._omp_fn.0) in the next ssa pass' dump.

If I'm correctly understanding the GCC sources as well as operating GDB,
in the gimple pass we get main._omp_fn.0 dumped because
gcc/cgraphunit.c:analyze_functions iterates over all functions
(analyze_function - dump_function).  In the following passes,
presumably, this is not done anymore: omplower, lower, eh, cfg.  In
ompexp, the GIMPLE_OMP_PARALLEL is expanded into a
»__builtin_GOMP_parallel (main._omp_fn.0)« call, but the main._omp_fn.0
is not dumped (and there is no BODY anymore to dump).  In the next ssa
pass, main._omp_fn.0 again is being dumped, by means of
gcc/passes.c:do_per_function_toporder (execute_pass_list -
execute_one_pass - execute_function_dump - dump_function_to_file), as I
understand it.  What do I need to modify to get main._omp_fn.0 included
in the dumps before the ssa pass, too?

Example:

int
main(void)
{
#pragma omp parallel
  {
extern void foo(void);
foo ();
  }
  return 0;
}

p2.c.003t.original:

;; Function main (null)
{
  #pragma omp parallel
{
  {
{
  extern void foo (void);
  foo ();
}
  }
}
  return 0;
}

p2.c.004t.gimple:

main ()
{
  int D.1749;
  #pragma omp parallel
{
  {
extern void foo (void);
foo ();
  }
}
  D.1749 = 0;
  return D.1749;
}

main._omp_fn.0 (void * .omp_data_i)
{
  bb 5:
  bb 3:
  foo ();
  return;

}

p2.c.006t.omplower:

;; Function main (main, funcdef_no=0, decl_uid=1743, symbol_order=0)
main ()
{
  int D.1749;
  {
#pragma omp parallel [child fn: main._omp_fn.0 (???)]
  {
extern void foo (void);

foo ();
  }
  #pragma omp return
  }
  D.1749 = 0;
  return D.1749;
}

p2.c.007t.lower, p2.c.010t.eh:

;; Function main (main, funcdef_no=0, decl_uid=1743, symbol_order=0)
main ()
{
  int D.1749;
  #pragma omp parallel [child fn: main._omp_fn.0 (???)]
  foo ();
  #pragma omp return
  D.1749 = 0;
  goto D.1754;
  D.1754:
  return D.1749;
}

p2.c.011t.cfg:

;; Function main (main, funcdef_no=0, decl_uid=1743, symbol_order=0)
[...]
main ()
{
  int D.1749;
  bb 2:
  #pragma omp parallel [child fn: main._omp_fn.0 (???)]
  bb 3:
  foo ();
  #pragma omp return
  bb 4:
  D.1749 = 0;
  return D.1749;

}

p2.c.012t.ompexp:

;; Function main (main, funcdef_no=0, decl_uid=1743, symbol_order=0)
OMP region tree
bb 2: gimple_omp_parallel
bb 3: GIMPLE_OMP_RETURN
Introduced new external node (foo/2).
Merging blocks 2 and 6
Merging blocks 2 and 4
main ()
{
  int D.1749;
  bb 2:
  __builtin_GOMP_parallel (main._omp_fn.0, 0B, 0, 0);
  D.1749 = 0;
  return D.1749;
}

p2.c.015t.ssa:

;; Function main._omp_fn.0 (main._omp_fn.0, funcdef_no=1, decl_uid=1751, 
symbol_order=1)
main._omp_fn.0 (void * .omp_data_i)
{
  bb 5:
  bb 3:
  foo ();
  return;
}

;; Function main (main, funcdef_no=0, decl_uid=1743, symbol_order=0)
main ()
{
  int _3;
  bb 2:
  __builtin_GOMP_parallel (main._omp_fn.0, 0B, 0, 0);
  _3 = 0;
  return _3;
}


Grüße,
 Thomas


pgpv_AdE6Cp9f.pgp
Description: PGP signature

Re: [RL78] Questions about code-generation

[Richard Hulme]

On 11/03/14 01:40, DJ Delorie wrote:

I'm curious.  Have you tried out other approaches before you decided
to go with the virtual registers?


Yes.  Getting GCC to understand the unusual addressing modes the
RL78 uses was too much for the register allocator to handle.  Even
when the addressing modes are limited to usual ones, GCC doesn't
have a good way to do regalloc and reload when there are limits on
what registers you can use in an address expression, and it's worse
when there are dependencies between operands, or limited numbers of
address registers.


Is it possible that the virtual pass causes inefficiencies in some cases 
by sticking with r8-r31 when one of the 'normal' registers would be better?


For example, I'm having a devil of a time convincing the compiler that 
an immediate value can be stored directly in any of the normal 16-bit 
registers (e.g. 'movw hl, #123').  I'm beginning to wonder whether it's 
the unoptimized code being fed in that's causing problems.


Taking a slight variation on my original test code (removing the 
'volatile' keyword and accessing an 8-bit memory location):




#define SOE0L (*(unsigned char *)0xF012A)

void orTest()
{
   SOE0L |= 3;
}



produces (with -O0)

  28_test:
  29  C9 F0 2A 01   movwr8, #298
  30 0004 C9 F2 2A 01   movwr10, #298
  31 0008 AD F2 movwax, r10
  32 000a BD F4 movwr12, ax
  33 000c FA F4 movwhl, r12
  34 000e 8Bmov a, [hl]
  35 000f 9D F2 mov r10, a
  36 0011 6A F2 03  or  r10, #3
  37 0014 AD F0 movwax, r8
  38 0016 BD F4 movwr12, ax
  39 0018 DA F4 movwbc, r12
  40 001a 8D F2 mov a, r10
  41 001c 48 00 00  mov [bc], a
  42 001f D7ret

In some cases, the normal optimization steps remove a lot, if not all, 
of the unnecessary register passing, but not always.


The conditions on the movhi_real insn allow an immediate value to be 
stored in (for example) HL directly, and yet I cannot find a single 
instance in my project where it isn't in the form of


movwr8, #298
movwax, r10
movwhl, ax

and no manner of re-arranging the conditions (that I've found) will 
cause the correct code to be generated.  It's determined to put the 
immediate value into rX, and then copy that into ax (which is also 
unnecessary).


I see the same problem with 'cmp' when the value to be compared is in 
the A register:


mov r8, a
cmp r8, #3

The A register is the one register that can be almost guaranteed to be 
usable with any instruction, and copying it to R8 (or wherever) to 
perform the comparison not only wastes two bytes for the move but also 
makes the cmp instruction a byte longer, so five bytes are used instead 
of two.


I looked at the code produced for IA64 and ARM targets, and although I'm 
not as familiar with those instruction sets, they didn't appear to do as 
much needless copying, which strengthens my suspicion that it's 
something in the RL78 backend that needs 'tweaking'.


The suggestions made regarding 'volatile' were very helpful and I've 
made some good savings elsewhere by adding support for different 
addressing modes and more efficient instructions but there are still a 
number of (theoretically) easy pickings that should (I feel) be possible 
before more complicated optimizations need to be looked at.


As ever, any suggestions are very gratefully received.  I hope to be 
able to post some patches once I'm comfortable that I haven't missed 
anything obvious or done something stupid.


Regards,

Richard.

RE: [RFC, MIPS] Relax NaN rules

[Rich Fuhler]

 From: Matthew Fortune
 Sent: Tuesday, March 18, 2014 08:06
 To: Joseph Myers
 Cc: Richard Sandiford; ma...@codesourcery.com; dal...@aerifal.cx; Andrew 
 Pinski (pins...@gmail.com); gcc@gcc.gnu.org; Rich Fuhler; Moore, Catherine 
 (catherine_mo...@mentor.com)
 Subject: RE: [RFC, MIPS] Relax NaN rules

 Joseph Myers jos...@codesourcery.com writes:
   1) There is no way to mark a module as don't care/not relevant. At a
   minimum this could be done via inspection of the GNU FP ABI attribute
   and when its value is 'Any' then NaNs don't matter. Better still would
   be that modules with floating point only require a certain NaN state
   if they use functions like __builtin_[s}nan. This would partially
   reduce the impact of the strict NaN checks.
 
  In general you can't tell whether a module cares.  It could have an 
  initializer
  0.0 / 0.0, without having any function calls involving floating point (so in
  principle being independent of hard/soft float, but not of NaN format).  Or 
  it
  could be written with knowledge of the ABI to do things directly with bit
  patterns (possibly based on a configure test rather than __mips_nan2008).
  The concept of a don't-care module is meaningful, but while heuristics can
  reliably tell that a module does care (e.g. GCC generated an encoding of a
  NaN bit-pattern, whether from __builtin_nan or 0.0 / 0.0) they can't so
  reliably tell that it doesn't care (although if it doesn't contain NaN bit-
  patterns, or manipulate representations of floating-point values through
  taking their addresses or using unions, you can probably be sure enough to
  mark it as don't-care - note that many cases where there are calls with
  floating-point arguments and results, but no manipulation of bit-patterns 
  and
  no NaN constants, would be don't-care by this logic).

 Thanks Joseph. I guess I'm not really pushing to have don't-care supported as 
 it would take a lot of effort to determine when code does and does not care, 
 you rightly point  out more cases to deal with too. I'm not sure if the 
 benefit would then be worth it or not as there would still be modules which 
 do and do not care about old and new NaNs  so it doesn't really relieve any 
 pressure on toolchains or linux distributions. The second part of the 
 proposal is more interesting/useful as it is saying I don't care about the 
 impact of getting NaN encoding wrong and a tools vendor/linux distribution 
 then gets to make that choice. Any comments on that aspect?

 Regards,
 Matthew

Hi Joseph, as I remember from conversations last year, there is also an issue 
if the
programmer specifically enables the FPU exceptions. If the FPU, kernel emulator,
or bare-metal emulator (CS3's for example) did raise a signaling NaN, then the
intermixing couldn't be done. As I remembering this correctly?

I ask this for another reason as well: since we're adding IFUNC capability to 
MIPS,
we may need to harden the dynamic loader to protect $f12 and $f14. If signaling
NaN was raised on the load, then we have more problems to deal with...

-rich 

RE: [RFC, MIPS] Relax NaN rules

[Joseph S. Myers]

On Fri, 21 Mar 2014, Rich Fuhler wrote:

 Hi Joseph, as I remember from conversations last year, there is also an 
 issue if the programmer specifically enables the FPU exceptions. If the 
 FPU, kernel emulator, or bare-metal emulator (CS3's for example) did 
 raise a signaling NaN, then the intermixing couldn't be done. As I 
 remembering this correctly?

I'm not clear on what the question is.  But if, say, a program uses only 
quiet NaNs, and cares about the invalid exception, but gets used on 
wrongly configured hardware or with libraries with an inconsistent notion 
of what a quiet NaN is, then it may get spurious invalid exceptions from 
some of the other pieces thinking they've received a signaling NaN.

 I ask this for another reason as well: since we're adding IFUNC 
 capability to MIPS, we may need to harden the dynamic loader to protect 
 $f12 and $f14. If signaling NaN was raised on the load, then we have 
 more problems to deal with...

I haven't looked at the details of what MIPS hardware does with signaling 
NaN loads - but in general uses of signaling NaNs work better if loads 
don't trigger the NaN, only arithmetic, conversions and other operations 
that IEEE 754 specifies should trigger it, so loads and stores always 
preserve the original bit-patterns.  (Cf. the bugs on x86 where a union 
gets copied via its double member, even though some other member is 
active, and so gets corrupted because the signaling NaN gets converted to 
quiet along the way.)

-- 
Joseph S. Myers
jos...@codesourcery.com

RE: [RFC, MIPS] Relax NaN rules

[Maciej W. Rozycki]

On Fri, 21 Mar 2014, Joseph S. Myers wrote:

  I ask this for another reason as well: since we're adding IFUNC 
  capability to MIPS, we may need to harden the dynamic loader to protect 
  $f12 and $f14. If signaling NaN was raised on the load, then we have 
  more problems to deal with...
 
 I haven't looked at the details of what MIPS hardware does with signaling 
 NaN loads - but in general uses of signaling NaNs work better if loads 
 don't trigger the NaN, only arithmetic, conversions and other operations 
 that IEEE 754 specifies should trigger it, so loads and stores always 
 preserve the original bit-patterns.  (Cf. the bugs on x86 where a union 
 gets copied via its double member, even though some other member is 
 active, and so gets corrupted because the signaling NaN gets converted to 
 quiet along the way.)

 Coprocessor loads (LWC1/LDC1/MTC1/MTHC1/DMTC1) and stores 
(SWC1/SDC1/MFC1/MFHC1/DMFC1) are not arithmetic and never trap on any bit 
patterns.  I reckon GCC already takes advantage of this and stores 
integers temporarily in FPRs in some cases.

  Maciej

RE: [RFC, MIPS] Relax NaN rules

[Rich Fuhler]

 From: Maciej W. Rozycki [ma...@codesourcery.com]
 Sent: Friday, March 21, 2014 16:21
 To: Joseph S. Myers
 Cc: Rich Fuhler; Matthew Fortune; Richard Sandiford; dal...@aerifal.cx; 
 Andrew Pinski (pins...@gmail.com); gcc@gcc.gnu.org; Moore, Catherine 
 (catherine_mo...@mentor.com)
 Subject: RE: [RFC, MIPS] Relax NaN rules


 Coprocessor loads (LWC1/LDC1/MTC1/MTHC1/DMTC1) and stores
 (SWC1/SDC1/MFC1/MFHC1/DMFC1) are not arithmetic and never trap on any bit
 patterns.  I reckon GCC already takes advantage of this and stores
 integers temporarily in FPRs in some cases.

  Maciej

Thanks Maciej, I blame it on the 387 - corrupted me for life...

Re: [RL78] Questions about code-generation

[DJ Delorie]

 Is it possible that the virtual pass causes inefficiencies in some
 cases by sticking with r8-r31 when one of the 'normal' registers
 would be better?

That's not a fair question to ask, since the virtual pass can *only*
use r8-r31.  The first bank has to be left alone else the
devirtualizer becomes a few orders of magnitude harder, if not
impossible, to make work correctly.

 In some cases, the normal optimization steps remove a lot, if not all, 
 of the unnecessary register passing, but not always.

I've found that removing uneeded moves through registers is
something gcc does poorly in the post-reload optimizers.  I've written
my own on some occasions (for rl78 too).  Perhaps this is a good
starting point to look at?

 much needless copying, which strengthens my suspicion that it's 
 something in the RL78 backend that needs 'tweaking'.

Of course it is, I've said that before I think.  The RL78 uses a
virtual model until reload, then converts each virtual instructions
into multiple real instructions, then optimizes the result.  This is
going to be worse than if the real model had been used throughout
(like arm or x86), but in this case, the real model *can't* be used
throughout, because gcc can't understand it well enough to get through
regalloc and reload.  The RL78 is just to weird to be modelled
as-is.

I keep hoping that gcc's own post-reload optimizers would do a better
job, though.  Combine should be able to combine, for example, the mov
r8,ax; cmp r8,#4 types of insns together.

Re: [RL78] Questions about code-generation

[Jeff Law]

On 03/21/14 18:35, DJ Delorie wrote:


I've found that removing uneeded moves through registers is
something gcc does poorly in the post-reload optimizers.  I've written
my own on some occasions (for rl78 too).  Perhaps this is a good
starting point to look at?


much needless copying, which strengthens my suspicion that it's
something in the RL78 backend that needs 'tweaking'.


Of course it is, I've said that before I think.  The RL78 uses a
virtual model until reload, then converts each virtual instructions
into multiple real instructions, then optimizes the result.  This is
going to be worse than if the real model had been used throughout
(like arm or x86), but in this case, the real model *can't* be used
throughout, because gcc can't understand it well enough to get through
regalloc and reload.  The RL78 is just to weird to be modelled
as-is.

I keep hoping that gcc's own post-reload optimizers would do a better
job, though.  Combine should be able to combine, for example, the mov
r8,ax; cmp r8,#4 types of insns together.
The virtual register file was the only way I could see to make RL78 
work.  I can't recall the details, but when you described the situation 
to me the virtual register file was the only way I could see to make the 
RL78 work in the IRA+reload world.


What would be quite interesting to try would be to continue to use the 
virtualized register set, but instead use the IRA+LRA path.  Presumably 
that wouldn't be terribly hard to try and there's a reasonable chance 
that'll improve the code in a noticeable way.


The next obvious thing to try, and it's probably a lot more work, would 
be to see if IRA+LRA is smart enough (or can be made so with a 
reasonable amount of work) to eliminate the virtual register file 
completely.


Just to be clear, I'm not planning to work on this; my participation and 
interest in the RL78 was limited to providing a few tips to DJ.


Jeff

[Bug target/60598] [4.9 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60598

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32413
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32413action=edit
gcc49-pr60598.patch

I've bootstrapped/regtested this version of the patch (feel free to rewrite the
ChangeLog entry), attaching just to show the testcase added on
{s390,s390x,powerpc,powerpc64}-linux (--enable-checking=yes), no regressions.

[Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints

[d.salikhov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606

Bug ID: 60606
   Summary: ICE [ARM] error: insn does not satisfy its constraints
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.salikhov at samsung dot com

Created attachment 32414
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32414action=edit
Code sample reproducing the bug

Reproduced on 4.8.0+ and on trunk.

*How to reproduce:*
Compile sample code in attachment by arm-v7a9-linux-gnueabi-gcc -S ice.c

*Compiler output:*
ice.c: In function 'alpha':
ice.c:5:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 5 2 6 (set (reg:SI 3 r3 [orig:110 pc.0 ] [110])
(reg/v:SI 15 pc [ pc ])) ice.c:4 641 {*arm_movsi_vfp}
 (nil))
ice.c:5:1: internal compiler error: in note_invalid_constants, at
config/arm/arm.c:13693
0x83e1907 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:109
0x83e1945 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:120
0x85e4b49 note_invalid_constants
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:13693
0x85e4b49 arm_reorg
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:14031
0x83e17b8 rest_of_handle_machine_reorg
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/reorg.c:3939
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.



*Commit introducing the bug:*
git hash: bffbb863ff0f267b5111bfa95b42c99cd0474424
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@189350
138bc75d-0d04-0410-961f-82ee72b054a4



arm-v7a9-linux-gnueabi-gcc -v output:

Using built-in specs.
COLLECT_GCC=../../toolchain_repos/ta_sdk/cortex-cross-tools_exp/bin/arm-v7a9-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/libexec/gcc/arm-v7a9-linux-gnueabi/4.8.3/lto-wrapper
Target: arm-v7a9-linux-gnueabi
Configured with:
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-v7a9-linux-gnueabi --disable-libmudflap --disable-libssp
--with-gnu-as --with-gnu-ld --disable-lto --disable-nls
--prefix=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-shared --disable-threads --disable-libssp --disable-libquadmath
--without-headers --with-newlib --disable-decimal-float --disable-libffi
--enable-languages=c
--with-sysroot=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/arm-v7a9-linux-gnueabi/sys-root/
--with-gmp=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpfr=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpc=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-libgomp --disable-libatomic --with-interwork --with-cpu=cortex-a9
--with-arch=armv7-a --with-mode=arm --with-tune=cortex-a9 --with-fpu=vfpv3
--with-float=softfp
Thread model: single
gcc version 4.8.3 20140321 (prerelease) (GCC)

[Bug lto/60607] New: Missing lto command line option handling causes build failures

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60607

Bug ID: 60607
   Summary: Missing lto command line option handling causes build
failures
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

Consider (-march=native is amdfam10):

markus@x4 tmp % cat foo.ii
markus@x4 tmp % cat bar.ii
typedef int __m128i __attribute__ ((__vector_size__ (16)));
__m128i a, b, c;
void dequant_scaling () { c = __builtin_ia32_pmulld128 (a, b); }
markus@x4 tmp % g++ -flto -fPIC -march=native -O2 -c foo.ii
markus@x4 tmp % g++ -flto -fPIC -march=native -O2 -msse4.1 -c bar.ii
markus@x4 tmp % g++ -flto -march=native -O2 -shared foo.o bar.o
bar.ii: In function ‘dequant_scaling’:
bar.ii:3:61: error: ‘__builtin_ia32_pmulld128’ needs isa option -m32 -msse4.1
 void dequant_scaling () { c = __builtin_ia32_pmulld128 (a, b); }
 ^
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/g++ returned 1 exit status

Adding -msse4.1 to the final link step would fix the issue.
This causes e.g. media-libs/x265 build failures see: PR60568 comment13.

[Bug tree-optimization/45932] execute/pr37573.c fails after Neon misaligned patch.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45932

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
updating based on c#3 and a recent set of testresults.

[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0

[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
4.3 branch is closed and looks like my backport never made it. Closing this out
as it got fixed in a 4.4.0 release I suspect

[Bug target/54051] [4.7 Regression] Invalid alignment specifier generated for vld3_lane_* and vld3_dup_* intrinsics.

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54051

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #8 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Not working on this.

[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51744

--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
typedef __SIZE_TYPE__ size_t;
extern void *memset (void *__s, int __c, size_t __n) __attribute__
((__nothrow__)) __attribute__ ((__nonnull__ (1)));
extern void __warn_memset_zero_len (void) __attribute__((__warning__ (memset
used with constant zero length parameter; this could be due to transposed
parameters)));
extern __inline __attribute__((__always_inline__))
__attribute__((__artificial__))
void * __attribute__ ((__nothrow__))
memset (void *__dest, int __ch, size_t __len)
{
  if (__builtin_constant_p (__len)  __len == 0
   (!__builtin_constant_p (__ch) || __ch != 0))
{
  __warn_memset_zero_len ();
  return __dest;
}
  return __builtin___memset_chk (__dest, __ch, __len, 
 __builtin_object_size (__dest, 0));
}

void
main (int argc, char **argv)
{
  char buf[5000];

  memset (buf, 0xFF, argc);
}


This breaks a lot of applications if you build them with LTO and
-D_FORTIFY_SOURCE=2.  The reason this happens is that when LTO bytecode
is output we still have

  bb 2:
  _2 = (long unsigned int) argc_1(D);
  _6 = __builtin_constant_p (_2);
  if (_6 != 0)
goto bb 3;
  else
goto bb 5;

  bb 3:
  if (_2 == 0)
goto bb 4;
  else
goto bb 5;

  bb 4:
  __warn_memset_zero_len ();
  goto bb 6;

  bb 5:
  __memset_chk (buf, 255, _2, 5000);

  bb 6:
  buf ={v} {CLOBBER};

thus __builtin_constant_p is not yet forced to be evaluated.  This means that
we put __warn_memset_zero_len into the LTO symbol table which is queried
by the linker and this causes it to warn at the beginning of link-time.
Also (as can be seen with the cases where we introduce a call late) the
linker wants to see a final set of symbols at this time, thus it won't drop
the reference to __warn_memset_zero_len even if during LTRANS phase we
optimize it away.

[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51744

--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
It also (sadly) means this works with -fno-use-linker-plugin.  It also means
that not outputting the UNDEF into the LTO symbol table for this case doesn't
work as the executable will not link (we optimize the symbol away) if we don't
fold away the reference to it later.

I see no better way than either forcing the linker to re-scan needed symbols
and warn at a second stage only or to fold __builtin_constant_p earlier.

[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51744

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||4.7.3, 4.8.3, 4.9.0
   Severity|normal  |major

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[y.gribov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606

Yury Gribov y.gribov at samsung dot com changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov y.gribov at samsung dot com ---
(In reply to D.Salikhov from comment #0)
 Compile sample code in attachment by arm-v7a9-linux-gnueabi-gcc -S ice.c

For my 4.9 with --enable-checking this fails earlier during LRA:

tmp.c: In function 'alpha':
tmp.c:5:1: internal compiler error: in check_rtl, at lra.c:2070
 }
 ^
0x9a3545 check_rtl
/home/ygribov/src/gcc-master/gcc/lra.c:2070
0x9a3fc7 lra(_IO_FILE*)
/home/ygribov/src/gcc-master/gcc/lra.c:2449
0x952374 do_reload
/home/ygribov/src/gcc-master/gcc/ira.c:5457
0x9526c2 rest_of_handle_reload
/home/ygribov/src/gcc-master/gcc/ira.c:5598
0x95270c execute
/home/ygribov/src/gcc-master/gcc/ira.c:5627

The problematic RTL seems to be

 (insn 5 2 6 2 (set (reg:SI 3 r3 [orig:110 D.4140 ] [110])
(reg/v:SI 15 pc [ pc ])) tmp.c:4 663 {*arm_movsi_vfp}
 (nil))

Indeed movsi patterns in arm.md does not allow pc in RHS:

 (define_insn *arm_movsi_insn
  [(set (match_operand:SI 0 nonimmediate_operand =rk,r,r,r,rk,m)
(match_operand:SI 1 general_operand  rk, I,K,j,mi,rk))]

I'm not sure whether this is a bug or a feature. As a workaround you could
simply do

 register unsigned long pc;
 asm(mov %0, pc : =r(pc));

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[d.salikhov at samsung dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606

--- Comment #2 from D.Salikhov d.salikhov at samsung dot com ---
I suppose it is a bug as according to ARM Architecture Reference Manual,
A8.8.13 AND (immediate), pc is valid register for using in 'AND' instruction as
an input.

[Bug lto/59626] [4.8/4.9 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626

--- Comment #17 from Richard Biener rguenth at gcc dot gnu.org ---
Seems to happen quite often when building packages with LTO (see PR51744 for
another major annoyance there).

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.3
   Keywords||lto
   Last reconfirmed|2014-03-19 00:00:00 |2014-03-21
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|lto1 ICE in |[4.9 Regression] lto1 ICE
   |add_symbol_to_partition, at |in add_symbol_to_partition,
   |lto/lto-partition.c:233 -   |at lto/lto-partition.c:233
   |when no -fresolution= is|with -fno-use-linker-plugin
   |available   |
   Target Milestone|--- |4.9.0

--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
.res data is produced by the linker-plugin thus this bug boils down to an ICE
that can be reproduced with -fno-use-linker-plugin.

The non-linker-plugin path doesn't get much attention these days.  4.8 works
for me.

Confirmed.

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||miles at gnu dot org

--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
*** Bug 56775 has been marked as a duplicate of this bug. ***

[Bug lto/56775] -flto and -fprofile-generate together result in a link-time internal compiler error (in add_symbol_to_partition)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56775

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Same spot of the ICE as 60567.

*** This bug has been marked as a duplicate of bug 60567 ***

[Bug target/60607] -march=native command line option handling breaks LTO option machinery

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60607

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Keywords||lto
   Last reconfirmed||2014-03-21
  Component|lto |target
 Ever confirmed|0   |1
Summary|Missing lto command line|-march=native command line
   |option handling causes  |option handling breaks LTO
   |build failures  |option machinery
   Severity|enhancement |normal

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
The issue is that -march=native explodes to explicit set options, including
negative ones such as -mno-sse4.1.  That's bad, as we now have conflicting
options for bar.o and foo.o which we merge like

  /* Do what the old LTO code did - collect exactly one option
 setting per OPT code, we pick the first we encounter.
 ???  This doesn't make too much sense, but when it doesn't
 then we should complain.  */

I think this option exploding done by -march=native is simply broken.

At least exploding to full positive _and_ negative lists is.  Either we
have a separate option for each target feature - then we don't need the
-mno-xxx stuff, or we don't - then we need to fix that.

Note that the plan for the future is to no longer merge any target options
for link-time but use target attributes more aggressively.  The current code
merely tries to make the link-step succeed somehow, not follow what the
user intended with setting specific target options on specific TUs.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128

--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
 --- Comment #34 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 I ran the test on Solaris 9 and 11 and looked at the resulting .sum
 files.  Seeing the Unsupported rounding entries on Solaris 11 (any
 platform without the rounding issue actually) seemed strange/backwards
 at first (double negation) until I understood how it's done.

 I agree that direct logic is better than double negation. With the following
 patch
[...]
 the gfortran.sum contains

 ...
 PASS: gfortran.dg/fmt_en.f90  -O0   scan-file All kinds rounded to nearest
 ...

Even better.  Tested again on i386-pc-solaris2.9 and i386-pc-solaris2.11.

Thanks.
Rainer

[Bug debug/60603] [4.7/4.8/4.9 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60603

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32415
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32415action=edit
gcc49-pr60603.patch

Untested fix.

[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #54 from Jakub Jelinek jakub at gcc dot gnu.org ---
Agreed.

[Bug c++/60608] New: Template argument problem

[volumedriverteam at cloudfounders dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608

Bug ID: 60608
   Summary: Template argument problem
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: volumedriverteam at cloudfounders dot com

#include functional
templatetypename... Args
void
wrapper(void (*f)(Args...),
Args... args)
{
f(std::forwardArgs...(args...));
}

void
myfun(int)
{}

void
myfun2(const int)
{}

void
test()
{
int a = 0;
wrapperint(myfun, a);

wrapper(myfun, a);

wrapperint(myfun2, a);

const int b = 0;
wrapper(myfun2, b);

wrapperconst int(myfun2, b);
}
It's not clear why the last line doesn't compile. It doesn't give any problem
on clang. The compiler seems to get the type of myfun2 wrong.

[Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression]
   |inefficient FDO |inefficient FDO
   |instrumentation code|instrumentation code

--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Fixed on trunk.

[Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577

--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Mar 21 11:52:50 2014
New Revision: 208746

URL: http://gcc.gnu.org/viewcvs?rev=208746root=gccview=rev
Log:
2014-03-21  Richard Biener  rguent...@suse.de

PR tree-optimization/60577
* tree-core.h (struct tree_base): Document nothrow_flag use
in VAR_DECL_NONALIASED.
* tree.h (VAR_DECL_NONALIASED): New.
(may_be_aliased): Adjust.
* coverage.c (build_var): Set VAR_DECL_NONALIASED.

* gcc.dg/tree-ssa/ssa-lim-11.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-11.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree.h

[Bug c++/60608] Template argument problem

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60608

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to volumedriverteam from comment #0)
 void
 myfun2(const int)

Top-level const is removed from function parameters, so this function is
equivalent to:

  void myfun2(int);

And the instantiation wrapperconst int is equivalent to:

  template void wrapperconst int(void (*)(int), int);

G++ gets confused trying to match const int to int somewhere.


f.cc: In function ‘void test()’:
f.cc:31:33: error: no matching function for call to ‘wrapper(void ()(int),
const int)’
 wrapperconst int(myfun2, b);
 ^
f.cc:31:33: note: candidate is:
f.cc:4:1: note: templateclass ... Args void wrapper(void (*)(Args ...), Args
...)
 wrapper(void (*f)(Args...),
 ^
f.cc:4:1: note:   template argument deduction/substitution failed:
f.cc:31:33: note:   mismatched types ‘const int’ and ‘int’
 wrapperconst int(myfun2, b);
 ^

[Bug target/60609] New: [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

Bug ID: 60609
   Summary: [4.8/4.9 Regression] Error: value of 256 too large for
field of 1 bytes at 68242
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

Created attachment 32416
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32416action=edit
preprocessed source

originall reported as a gas issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=16735

seen when building the ppl 1.1 bindings for SWI Prolog, using binutils from the
2.24 branch on arm-linux-gnueabihf with a compiler defaulting to thumb mode.

seen with current 4.8 branch and at least trunk 20140306.

$ g++ -c -g -O2 ppl_prolog_common.ii
/tmp/ccuRxr3p.s: Assembler messages:
/tmp/ccuRxr3p.s:126688: Error: value of 256 too large for field of 1 bytes at
68242

$ g++ -marm -c -g -O2 ppl_prolog_common.ii
succeeds

$ as -v -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -meabi=5 -o
ppl_prolog_common.o ppl_prolog_common.s
GNU assembler version 2.24 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Debian) 2.24
ppl_prolog_common.s: Assembler messages:
ppl_prolog_common.s:130339: Error: value of 256 too large for field of 1 bytes
at 70430

[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

--- Comment #1 from Matthias Klose doko at gcc dot gnu.org ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-16'
--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 --disable-libmudflap
--disable-libitm --disable-libquadmath --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-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-16)

[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Hi Rainer,

  Given that the 2.9 target is deprecated, do we really care about this problem
?

  Also - when I tried to assemble the file you uploaded I had no problems. 
This was using gas built from today's FSF mainline binutils sources, but I also
tried a version built from the 2.24 sources and the 2.23 sources - they all
worked.

Cheers
  Nick

[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Confirmed - reducing.

[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419

--- Comment #18 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Fri Mar 21 12:48:02 2014
New Revision: 208747

URL: http://gcc.gnu.org/viewcvs?rev=208747root=gccview=rev
Log:
2014-03-21  Martin Jambor  mjam...@suse.cz

PR ipa/60419
* ipa.c (symtab_remove_unreachable_nodes): Clear thunk flag of nodes
in the border.

testsuite/
* g++.dg/ipa/pr60419.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr60419.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE ---
 --- Comment #2 from Nick Clifton nickc at redhat dot com ---
 Hi Rainer,

   Given that the 2.9 target is deprecated, do we really care about this 
 problem
 ?

Not too much.  Given that is was a new failure, I still reported it to
check if we can do something about it short of XFAILing the test.

   Also - when I tried to assemble the file you uploaded I had no problems. 
 This was using gas built from today's FSF mainline binutils sources, but I 
 also
 tried a version built from the 2.24 sources and the 2.23 sources - they all
 worked.

Sorry, I forgot: the failure only happens with the native as, not with gas.

Rainer

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|c++ |ipa

[Bug rtl-optimization/60601] [4.9 Regression] profiledbootstrap fails with Ada

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60601

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-checking
 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed by Jakub.  Works for release checking.

[Bug debug/60603] [4.7/4.8/4.9 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60603

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |4.9.0

[Bug ipa/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59176

--- Comment #13 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Fri Mar 21 12:59:35 2014
New Revision: 208748

URL: http://gcc.gnu.org/viewcvs?rev=208748root=gccview=rev
Log:
2014-03-21  Martin Jambor  mjam...@suse.cz

PR ipa/59176
* cgraph.h (symtab_node): New flag body_removed.
* ipa.c (symtab_remove_unreachable_nodes): Set body_removed flag
when removing bodies.
* symtab.c (dump_symtab_base): Dump body_removed flag.
* cgraph.c (verify_edge_corresponds_to_fndecl): Skip nodes which
had their bodies removed.

testsuite/
* g++.dg/torture/pr59176.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr59176.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/ipa.c
trunk/gcc/symtab.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59176

Martin Jambor jamborm at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Martin Jambor jamborm at gcc dot gnu.org ---
Fixed.

[Bug lto/59626] [4.8/4.9 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626

--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
 But the function doesn't inline itself, that is why it uses the asm alias
 and GCC shouldn't be looking through that and merging the two decls because
 of that.
 
 Breaking this breaks pretty much all of glibc -D_FORTIFY_SOURCE, and there
 really isn't any other way how to write it.
 
 To show the reason for the inline:
 __fortify_function __nonnull ((1, 2)) __wur ssize_t
 __NTH (readlink (const char *__restrict __path, char *__restrict __buf,
  size_t __len))
 {
   if (__bos (__buf) != (size_t) -1)
 {
   if (!__builtin_constant_p (__len))
 return __readlink_chk (__path, __buf, __len, __bos (__buf));
 
   if ( __len  __bos (__buf))
 return __readlink_chk_warn (__path, __buf, __len, __bos (__buf));
 }
   return __readlink_alias (__path, __buf, __len);
 }
 
 The inline must be always_inline, because it is a security matter if it is
 inlined or not, and we want it to expand as a call to __readlink_chk if
 it needs runtime verification, otherwise as a call to the original function,
 not inlined.  So, this is really a LTO/IPA bug.

Note that __readlink_alias was _not_ declared always-inline and thus at least
the call edge (even if eventually re-directing to readlink itself) should
not be considered always-inline.  But we always check the always-inline flag
on the callee decl, even if it was substituted from an alias.  As we throw
away the callgraph edges it's also hard to maintain this edge property there.

[Bug target/60610] New: [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

Bug ID: 60610
   Summary: [4.9 Regression] ICE in convert_regs_1, at
reg-stack.c:3064
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Host: i586-linux-gnu
Target: x86_64-*-*

Created attachment 32417
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32417action=edit
testcase

/usr/lib/gcc/i586-suse-linux/4.9/cc1 -fpreprocessed efiemu.i -quiet -dumpbase
efiemu.c -m64 -mcmodel=large -mno-red-zone -mtune=generic -march=x86-64
-auxbase-strip efiemu64_c.o -O2 -Wall -Werror -version -o efiemu.s
../../grub-core/efiemu/runtime/efiemu.c: In function 'efiemu_get_time':
../../grub-core/efiemu/runtime/efiemu.c:247:1: internal compiler error: in
convert_regs_1, at reg-stack.c:3064
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Note that the weird thing is that with 4.8 I get

[  127s] GRUB2 will be compiled with following components:
...
[  127s] efiemu runtime: No (cannot compile with -m64 -mcmodel=large
-mno-red-zone -nostdlib)

but appearantly with 4.9 that succeeds (the compiler wasn't built with
multilibs)

[  153s] efiemu runtime: Yes

so maybe this isn't a true regression.  It's at least odd.

[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609

--- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
Created attachment 32418
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32418action=edit
Reduced testcase

Reduced testcase. Looks prima-facie like lengths are messed up somewhere which
needs careful digging.


-march=armv7-a -mthumb -c -O2 -mfpu=vfpv3-d16 on trunk.

Ramana

[Bug c++/60611] New: friend function declaration rejected when the namespace in which it is declared is not explicitely specified in the declaration

[nicolas.bertolotti at mathworks dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60611

Bug ID: 60611
   Summary: friend function declaration rejected when the
namespace in which it is declared is not explicitely
specified in the declaration
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.bertolotti at mathworks dot fr

Created attachment 32419
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32419action=edit
Source file to reproduce the issue

If you compile the following piece of code using g++ (4.7.2):

class class1; 

namespace ns1 { 

class class2; 
class class3; 
}

ns1::class3 *func(ns1::class2 * cfg, const class1 * def); 

namespace ns1 { 

class class4 { 
#ifdef WORKAROUND
friend ns1::class3 *(::func)(ns1::class2 * cfg, const class1 * def);
#else
friend class3 *(::func)(class2 * cfg, const class1 * def); 
#endif
}; 
}
 (also attached)
you get the following:
$ g++ -c test.cpp
test.cpp:17:25: error: ‘func’ is neither function nor member function; cannot
be declared friend
test.cpp:17:23: error: expected ‘;’ at end of member declaration
test.cpp:17:32: error: expected ‘)’ before ‘*’ token

Now, if you explicitely add the namespaces as they appear in the initial
declaration (add -DWORKAROUND), the compilation succeeds.

[Bug c++/60612] New: Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[tasptz at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612

Bug ID: 60612
   Summary: Throwing exception, catching and rethrowing
(std::exception_ptr) in destructor leads to segfault
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tasptz at gmail dot com

Created attachment 32420
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32420action=edit
Test source file

See attached sample.
Compiled with gcc 4.7 (g++-4.7 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3) the
program runs and exits normally. Compiled with gcc 4.8 a segfault occurs.

#0  0x in ?? ()
#1  0x77b34c76 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x77b33d39 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x77b348ea in __gxx_personality_v0 () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x775d3803 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#5  0x775d3b9b in _Unwind_RaiseException () from
/lib/x86_64-linux-gnu/libgcc_s.so.1
#6  0x77b34c5a in
std::rethrow_exception(std::__exception_ptr::exception_ptr) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00400cb1 in A::~A() ()
#8  0x00400bc4 in main ()

version:
g++ (GCC) 4.8.2

system:
Linux gpustation 3.5.0-21-generic #32~precise1-Ubuntu SMP Thu Dec 13 20:26:47
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

gcc configure:
--enable-languages=c,c++

example compilation:
g++ -std=c++11 -o main main.cpp

[Bug middle-end/60419] [4.8 Regression] ICE Segmentation fault

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[4.8/4.9 Regression] ICE|[4.8 Regression] ICE
   |Segmentation fault  |Segmentation fault

--- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org ---
Fixed on the trunk so far.

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600

--- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org ---
Well, this is ICE on code with undefined behavior.  Function test
calls itself with a parameter which is a reference to an object of
type child2 and then static_casts it to a reference to child1.  These
are non-PODs, neither of these types is an ancestor of the other and
thus the use of static_cast is not allowed by the C++ standard.

ipa-prop based devirtualization does not see the cast, it thinks the
object is of type child2, and therefore the virtual method it looks up
is intermediate::topf.  Then it does a consistency check to see
whether type hierarchy based devirtualization has that function among
its possible targets.  However, this devirtualization starts with
child1 as its outer type and thus it concludes the only possible
target is top::topf.  The consistency check fails and we get an ICE on
assert.

The assert has to go but I wonder whether we want to give up when
possible_polymorphic_call_target_p returns false so that we don't try
to optimize such undefined cases.  We might even give a warning,
although making the warning useful to the user might require some
effort.

[Bug sanitizer/60613] New: Invalid signed subtraction ubsan diagnostics

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60613

Bug ID: 60613
   Summary: Invalid signed subtraction ubsan diagnostics
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: jakub at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

On x86_64-linux with -O2 -m32 -fsanitize=undefined on:
__attribute__((noinline, noclone)) long long
foo (long long y)
{
  asm ();
  return 8LL - y;
}

int
main ()
{
  foo (1);
  return 0;
}

we get invalid diagnostics:
runtime error: signed integer overflow: 8 - 1 cannot be represented in type
'long long int'

[Bug sanitizer/60613] Invalid signed subtraction ubsan diagnostics

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60613

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug lto/57715] lto1.exe: internal compiler error: in add_symbol_to_partition

[vhaisman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57715

Václav Zeman vhaisman at gmail dot com changed:

   What|Removed |Added

 CC||vhaisman at gmail dot com

--- Comment #3 from Václav Zeman vhaisman at gmail dot com ---
Created attachment 32421
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32421action=edit
preprocessed source

[Bug lto/57715] lto1.exe: internal compiler error: in add_symbol_to_partition

[vhaisman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57715

--- Comment #4 from Václav Zeman vhaisman at gmail dot com ---
(In reply to Tobias Burnus from comment #2)
 This PR might have the same reason as PR60567.
 
 Namely, your GCC has not been compiled on a system with working linker
 plugin - and thus, lto1 is not invoked with -fresolution=.
 
 Try compiling with -fuse-linker-plugin - if that gives an error, try a GCC
 which has been configured with --with-plugin-ld= pointing to a newer
 Binutils - 2.21 or newer. If that helps, it is a duplicate of PR60567.

I was able to (manually) reduce the test to 

g++  -r -nostdlib  src/.libs/liblog4cplus_la-rootlogger.ii -flto -o
.libs/cyglog4cplus-1-2-2.dll

The preprocessed file is attached compressed.

 
 If it doesn't help: Create a reduced test case as described at
 http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs

[Bug lto/57715] lto1.exe: internal compiler error: in add_symbol_to_partition

[vhaisman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57715

--- Comment #5 from Václav Zeman vhaisman at gmail dot com ---
(In reply to Václav Zeman from comment #4)
 (In reply to Tobias Burnus from comment #2)
  This PR might have the same reason as PR60567.
  
  Namely, your GCC has not been compiled on a system with working linker
  plugin - and thus, lto1 is not invoked with -fresolution=.
  
  Try compiling with -fuse-linker-plugin - if that gives an error, try a GCC
  which has been configured with --with-plugin-ld= pointing to a newer
  Binutils - 2.21 or newer. If that helps, it is a duplicate of PR60567.
 
 I was able to (manually) reduce the test to 
 
 g++  -r -nostdlib  src/.libs/liblog4cplus_la-rootlogger.ii -flto -o
 .libs/cyglog4cplus-1-2-2.dll
 
 The preprocessed file is attached compressed.
 
  
  If it doesn't help: Create a reduced test case as described at
  http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs

Oops! All of this should have gone to PR 56963 instead.

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600

--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
Or we might produce a call to __builtin_unreachable (we already do
that in ipa_get_indirect_edge_target_1 in similar cases) or
__builtin_abort.  Tough decision, although I'll probably go for
__builtin_unreachable, for the sake of consistency.

[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284

[vhaisman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963

--- Comment #7 from Václav Zeman vhaisman at gmail dot com ---
Created attachment 32422
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32422action=edit
preprocessed source

[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284

[vhaisman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963

--- Comment #6 from Václav Zeman vhaisman at gmail dot com ---
(In reply to Tobias Burnus from comment #5)
 This PR might have the same reason as PR60567.
 
 Namely, your GCC has not been compiled on a system with working linker
 plugin - and thus, lto1 is not invoked with -fresolution=.
 
 Try compiling with -fuse-linker-plugin - if that gives an error, try a GCC
 which has been configured with --with-plugin-ld= pointing to a newer
 Binutils - 2.21 or newer. If that helps, it is a duplicate of PR60567.

I was able to (manually) reduce the test to 

g++  -r -nostdlib  src/.libs/liblog4cplus_la-rootlogger.ii -flto -o
.libs/cyglog4cplus-1-2-2.dll

The preprocessed file is attached compressed.

 
 If it doesn't help: Create a reduced test case as described at
 http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs

[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284

[vhaisman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963

--- Comment #8 from Václav Zeman vhaisman at gmail dot com ---
BTW, the current version with which I have reduced the test case is this:

`-- g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.8.2/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/gcc4/gcc-4.8.2-2/src/gcc-4.8.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc4/gcc-4.8.2-2/src/gcc-4.8.2 --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-arch=i686
--with-tune=generic --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.2 (GCC)

[Bug c/60614] New: -Wtype-limits fails to warn on unsigned bitfields

[hjp at liab dot dk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60614

Bug ID: 60614
   Summary: -Wtype-limits fails to warn on unsigned bitfields
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjp at liab dot dk

This is possibly related to #54787, but with a different case.

After finding a bug in code compiled with avr-gcc, I created this test case, as
no warning was issued when I expected it. The following test case is tested on:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20140206/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-cloog-version-check --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 20140206 (prerelease) (GCC)

Test case:
#include stdio.h

struct {
unsigned char field1 :3;
unsigned char field2 :5;
} teststruct;

int main ( void ) {

unsigned char test;

if (teststruct.field1  0) //issues no warning
printf(Field1 was negative\n);

if (test  0) //issues warning
printf(Test was negative\n);

return 0;
}


// Compilation:
$ gcc -Wall -Wextra test.c -o test
test.c: In function ‘main’:
test.c:17:2: warning: comparison is always false due to limited range of data
type [-Wtype-limits]
  if (test  0)
  ^


==
The warning is not issued on test for negative unsigned bitfield as I expected
it.

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600

Martin Jambor jamborm at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org ---
This is what I'm about to bootstrap and test and then try with Mozilla
Firefox.

It might be worthwhile to report the error in the library from which
the testcase is derived.  You can even try and build and test the
library with this patch but with BUILT_IN_UNREACHABLE replaced with
BUILT_IN_ABORT to track the issue.

--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1639,11 +1639,18 @@ ipa_get_indirect_edge_target_1 (struct cgraph_edge *ie,
return NULL_TREE;
   target = gimple_get_virt_method_for_binfo (token, binfo);
 }
-#ifdef ENABLE_CHECKING
-  if (target)
-gcc_assert (possible_polymorphic_call_target_p
-(ie, cgraph_get_node (target)));
-#endif
+
+  if (target  !possible_polymorphic_call_target_p (ie,
+cgraph_get_node (target)))
+{
+  if (dump_file)
+   fprintf (dump_file,
+Type inconsident devirtualization: %s/%i-%s\n,
+ie-caller-name (), ie-caller-order,
+IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (target)));
+  target = builtin_decl_implicit (BUILT_IN_UNREACHABLE);
+  cgraph_get_create_node (target);
+}

   return target;
 }

[Bug sanitizer/60613] Invalid signed subtraction ubsan diagnostics

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60613

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32423
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32423action=edit
gcc49-pr60613.patch

Untested fix.

[Bug target/60598] [4.9 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60598

--- Comment #7 from Richard Henderson rth at gcc dot gnu.org ---
Author: rth
Date: Fri Mar 21 15:31:25 2014
New Revision: 208749

URL: http://gcc.gnu.org/viewcvs?rev=208749root=gccview=rev
Log:
PR target/60598

* ifcvt.c (dead_or_predicable): Return FALSE if there are any frame
related insns after epilogue_completed.
* gcc.dg/pr60598.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr60598.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60598] [4.9 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60598

Richard Henderson rth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Henderson rth at gcc dot gnu.org ---
Fixed.

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
In C++11 destructors have an implicit noexcept, so the 4.7 behaviour is wrong:
the program should call std::terminate() when the exception leaves ~A()

If you change the program to:

~A() noexcept(false)

then it runs and exits normally.

If you explicitly add:

~A() noexcept(true)

then you get the same behaviour from 4.7 and 4.8, it segfaults in the terminate
handler.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Richard Biener from comment #0)
 Created attachment 32417 [details]
 testcase
 
 /usr/lib/gcc/i586-suse-linux/4.9/cc1 -fpreprocessed efiemu.i -quiet
 -dumpbase efiemu.c -m64 -mcmodel=large -mno-red-zone -mtune=generic
 -march=x86-64 -auxbase-strip efiemu64_c.o -O2 -Wall -Werror -version -o
 efiemu.s
 ../../grub-core/efiemu/runtime/efiemu.c: In function 'efiemu_get_time':
 ../../grub-core/efiemu/runtime/efiemu.c:247:1: internal compiler error: in
 convert_regs_1, at reg-stack.c:3064
  }
  ^
 libbacktrace could not find executable to open
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See http://bugs.opensuse.org/ for instructions.

I got

[hjl@gnu-6 pr60610]$ /export/build/gnu/gcc-32bit/build-i586-linux/gcc/cc1
-fpreprocessed efiemu.i -quiet -dumpbase efiemu.c -m64 -mcmodel=large
-mno-red-zone -mtune=generic -march=x86-64 -auxbase-strip efiemu64_c.o -O2
-Wall -version -o efiemu.s
GNU C (GCC) version 4.9.0 20140321 (experimental) (i586-linux)
compiled by GNU C version 4.8.2 20140115 (Red Hat 4.8.2-11), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20140321 (experimental) (i586-linux)
compiled by GNU C version 4.8.2 20140115 (Red Hat 4.8.2-11), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 1545236744b328e15d09c2404fa0d2e2
../../grub-core/efiemu/runtime/efiemu.c: In function
‘efiemu_set_virtual_address_map’:
../../grub-core/efiemu/runtime/efiemu.c:378:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
../../grub-core/efiemu/runtime/efiemu.c:381:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
../../grub-core/efiemu/runtime/efiemu.c:384:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
../../grub-core/efiemu/runtime/efiemu.c:387:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
[hjl@gnu-6 pr60610]$

[Bug c++/42328] rejects valid friend

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42328

--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
Clang accepts the code in comment 0, but GCC 4.9 and icc 13.0.1 still give the
same errors as stated here in 2009

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[tasptz at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612

tasptz at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from tasptz at gmail dot com ---
Thanks, Jonathan.

[Bug c++/60611] friend function declaration rejected when the namespace in which it is declared is not explicitely specified in the declaration

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60611

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
This is not invalid, it's a bug: the terminate handler should terminate, not
segfault

[Bug c++/60615] New: bad location in error from initializer

[tromey at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60615

Bug ID: 60615
   Summary: bad location in error from initializer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org

Consider this source:

struct v
{
  int (*f1) (int);
  int (*f2) ();
  int (*f3) (int);
  int (*f4) (int);
};

int func(int x) { return x; }
int fv() { return 23; }

struct v inst = {
  func,
  func,
  func,
  func
}; // Line 17

Compile it with g++:

barimba. g++ --syntax-only pr.cc
pr.cc:17:1: error: invalid conversion from ‘int (*)(int)’ to ‘int (*)()’
[-fpermissive]
 }; // Line 17
 ^

Note that the error refers to line 17 and does not mention the field name
at all.  This is very inconvenient when one has a large struct of
function pointers -- it can be quite hard to find the actual location
of the problem.

[Bug c++/60616] New: bad location from -Wunused-parameter

[tromey at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60616

Bug ID: 60616
   Summary: bad location from -Wunused-parameter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org

Consider this source code:

int whatever (int x,
  int y)
{
  return x;
}


Compile it with g++:

barimba. g++ -c -Wunused-parameter pr.cc
pr.cc:1:5: warning: unused parameter ‘y’ [-Wunused-parameter]
 int whatever (int x,
 ^


Note that the error message refers to the wrong location.
I think it should point to the 'y' on line 2.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
You need 32-bit non-multilib cc1.  I can reproduce this, looking into it now.
4.8 configured the same way would complain:
error: code model ‘large’ not supported in the 32 bit mode
sorry, unimplemented: 64-bit mode not compiled in
but 4.9 doesn't for some reason.

[Bug target/60617] New: [4.8 Regression]

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60617

Bug ID: 60617
   Summary: [4.8 Regression]
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

Created attachment 32424
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32424action=edit
preprocessed source

seen with the 4.8 branch on arm-linux-gnueabihf, configured with
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 

omitting the -fno-tree-dce works around the issue.  not seen with the 4.7
branch and trunk 20140306.

$ g++ -std=c++11 -fPIC -fno-tree-dce -fno-exceptions -fno-omit-frame-pointer -c
-g -O2 JITArithmetic32_64.ii
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp: In member function 'void
JSC::JIT::emit_op_add(JSC::Instruction*)':
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:526:1: error: unable to
find a register to spill in class 'LO_REGS'
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:526:1: error: this is the
insn:
(insn 335 334 336 20 (parallel [
(set (reg:SI 3 r3)
(ior:SI (eq:SI (reg/v:SI 112 [ op ])
(reg/v:SI 110 [ dst ]))
(eq:SI (reg/v:SI 111 [ op ])
(reg/v:SI 110 [ dst ]
(clobber (reg:CC 100 cc))
]) ../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:514 295
{*ior_scc_scc}
 (expr_list:REG_UNUSED (reg:CC 100 cc)
(nil)))
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:526: confused by earlier
errors, bailing out
Preprocessed source stored into /tmp/ccb0Osgc.out file, please attach this to
your bugreport.

[Bug c++/60384] [4.9 Regression] [c++1y] ICE with invalid typedef

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60384

--- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Mar 21 16:35:26 2014
New Revision: 208752

URL: http://gcc.gnu.org/viewcvs?rev=208752root=gccview=rev
Log:
/cp
2014-03-21  Paolo Carlini  paolo.carl...@oracle.com

PR c++/60384
* name-lookup.c (push_class_level_binding_1): Check identifier_p
on the name argument.

/testsuite
2014-03-21  Paolo Carlini  paolo.carl...@oracle.com

PR c++/60384
* g++.dg/cpp1y/pr60384.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr60384.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/60384] [4.9 Regression] [c++1y] ICE with invalid typedef

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60384

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
This got broken with r203634.
203634   tmsriram   if ((TARGET_64BIT_P (opts-x_ix86_isa_flags) != 0)
203634   tmsriram   != ((opts-x_ix86_isa_flags  OPTION_MASK_ISA_64BIT) !=
0))
is always false, no matter how the compiler has been configured:
i386.h:#define TARGET_64BIT_P(x) TARGET_ISA_64BIT_P(x)
#define TARGET_ISA_64BIT_P(ix86_isa_flags) ((ix86_isa_flags 
OPTION_MASK_ISA_64BIT) != 0)

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32425
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32425action=edit
gcc49-pr60610.patch

Completely untested patch.

[Bug target/60618] New: ICE when building openssh on hppa w/-ftrapv in gcse.c

[vapier at gentoo dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60618

Bug ID: 60618
   Summary: ICE when building openssh on hppa w/-ftrapv in gcse.c
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vapier at gentoo dot org
CC: toolchain at gentoo dot org
  Host: hppa2.0-linux-gnu
Target: hppa2.0-linux-gnu
 Build: hppa2.0-linux-gnu

Created attachment 32426
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32426action=edit
preprocessed output

building the latest version of openssh on hppa ICEs when using -ftrapv (which
upstream adds themselves)

$ hppa2.0-unknown-linux-gnu-gcc-4.6.4 -c ssh-keygen.i -O2 -ftrapv
ssh-keygen.i: In function ‘do_fingerprint’:
ssh-keygen.i:9188:1: internal compiler error: in hoist_code, at gcse.c:4631

$ hppa2.0-unknown-linux-gnu-gcc-4.7.3 -c ssh-keygen.i -O2 -ftrapv
ssh-keygen.i: In function ‘do_known_hosts’:
ssh-keygen.i:9499:1: internal compiler error: in hoist_code, at gcse.c:3123

$ hppa2.0-unknown-linux-gnu-gcc-4.8.2 -c ssh-keygen.i -O2 -ftrapv
ssh-keygen.i: In function ‘do_fingerprint’:
ssh-keygen.i:9188:1: internal compiler error: in get_pressure_class_and_nregs,
at gcse.c:3438

[Bug target/60520] stack adjustment are not merged anymore

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

  Attachment #32399|0   |1
is obsolete||

--- Comment #13 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 32427
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32427action=edit
A patch with a target hook

[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
When I step through std::rethrow_exception() in gdb it goes from line 215 to
line 223, so skips over the call to get_terminate(), so dep-terminateHandler
is null and so is dep-unwindHeader.exception_cleanup

(gdb) bt
#0  std::rethrow_exception (ep=...) at
/home/jwakely/src/gcc/gcc/libstdc++-v3/libsupc++/eh_ptr.cc:223
#1  0x00400d39 in A::~A (this=0x7fffd9df, __in_chrg=optimized
out) at ep.cc:19
#2  0x00400c4c in main () at ep.cc:28
(gdb) p *dep
$17 = {primaryException = 0x603090, unexpectedHandler = 0x77d3a7c0
std::terminate(), terminateHandler = 0x0, nextException = 0x0, handlerCount =
0, handlerSwitchValue = 0, actionRecord = 0x0, languageSpecificData = 0x0, 
  catchTemp = 0, adjustedPtr = 0x0, unwindHeader = {exception_class = 0,
exception_cleanup = 0x0, private_1 = 0, private_2 = 0}}

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
*Sigh* -- ignore that. After line 223 it jumps back to 216 then continues back
to 223 again with the right values in *dep. I thought I was debugging an
unoptimised libstdc++.so but apparently not.

[Bug libstdc++/60587] [4.9 Regression] debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60587

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Fri Mar 21 18:54:06 2014
New Revision: 208755

URL: http://gcc.gnu.org/viewcvs?rev=208755root=gccview=rev
Log:
PR libstdc++/60587
* include/debug/functions.h (_Is_contiguous_sequence): Define.
(__foreign_iterator): Accept additional iterator. Do not dispatch on
iterator category.
(__foreign_iterator_aux2): Likewise. Add overload for iterators
from different types of debug container. Use _Is_contiguous_sequence
instead of is_lvalue_reference.
(__foreign_iterator_aux3): Accept additional iterator. Avoid
dereferencing past-the-end iterator.
(__foreign_iterator_aux4): Use const value_type* instead of
potentially user-defined const_pointer type.
* include/debug/macros.h (__glibcxx_check_insert_range): Fix comment
and pass end iterator to __gnu_debug::__foreign_iterator.
(__glibcxx_check_insert_range_after): Likewise.
(__glibcxx_check_max_load_factor): Fix comment.
* include/debug/vector (_Is_contiguous_sequence): Define partial
specializations.
* testsuite/23_containers/vector/debug/57779_neg.cc: Remove
-std=gnu++11 option and unused header.
* testsuite/23_containers/vector/debug/60587.cc: New.
* testsuite/23_containers/vector/debug/60587_neg.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/60587.cc
  - copied, changed from r208753,
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/60587_neg.cc
  - copied, changed from r208753,
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/functions.h
trunk/libstdc++-v3/include/debug/macros.h
trunk/libstdc++-v3/include/debug/vector
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc

[Bug libstdc++/60587] [4.9 Regression] debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60587

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Fixed (with a rather more complicated patch!)

[Bug fortran/60576] [4.8/4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Running the test compiled with -fsanitize=address gives

=
==70806==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff58110428 at pc 0x107b115d8 bp 0x7fff58110240 sp 0x7fff58110218
READ of size 168 at 0x7fff58110428 thread T0
#0 0x107b115d7 (/opt/gcc/gcc4.9w/lib/libasan.1.dylib+0x1a5d7)
#1 0x107af0340
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11340)
#2 0x107af18ad
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x128ad)
#3 0x7fff9184e5fc (/usr/lib/system/libdyld.dylib+0x35fc)
#4 0x0

Address 0x7fff58110428 is located in stack of thread T0 at offset 104 in frame
#0 0x107af000d
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1100d)

  This frame has 1 object(s):
[32, 104) 'at' == Memory access at offset 104 overflows this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x1fffeb022030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022070: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
=0x1fffeb022080: 00 00 00 00 00[f4]f4 f4 f3 f3 f3 f3 00 00 00 00
  0x1fffeb022090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Contiguous container OOB:fc
  ASan internal:   fe
==70806==ABORTING

[Bug fortran/60560] Problem allocating character array with assumed length

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60560

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I get the error from version 4.3.1 up to 4.9.0 (trunk).

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
Fixed.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60610

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Fri Mar 21 21:24:31 2014
New Revision: 208756

URL: http://gcc.gnu.org/viewcvs?rev=208756root=gccview=rev
Log:
PR target/60610
* config/i386/i386.h (TARGET_64BIT_P): If not TARGET_BI_ARCH,
redefine to 1 or 0.
* config/i386/darwin.h (TARGET_64BIT_P): Redefine to
TARGET_ISA_64BIT_P(x).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h
trunk/gcc/config/i386/i386.h

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148

--- Comment #14 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
Author: jvdelisle
Date: Fri Mar 21 22:14:36 2014
New Revision: 208757

URL: http://gcc.gnu.org/viewcvs?rev=208757root=gccview=rev
Log:
2014-03-21  Jerry DeLisle  jvdeli...@gcc.gnu.org

PR fortran/60148
* gfortran.texi: Add description of namelist DELIM= behavior.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148

--- Comment #15 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
Author: jvdelisle
Date: Fri Mar 21 22:19:44 2014
New Revision: 208759

URL: http://gcc.gnu.org/viewcvs?rev=208759root=gccview=rev
Log:
2014-03-21  Jerry DeLisle  jvdeli...@gcc.gnu

PR libfortran/60148
* io/transfer.c (data_transfer_init): If std= was specified, set
delim status to DELIM_NONE of no other was specified.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148

Jerry DeLisle jvdelisle at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
Fixed on trunk.

[Bug target/60604] GCC incorrectly compiles s_csinh function on MIPS

[sje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604

--- Comment #1 from Steve Ellcey sje at gcc dot gnu.org ---
Created attachment 32428
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32428action=edit
New reduced test case

Here is a new reduced test case that calls no libm functions.  I am pretty sure
that the bug is in the handling of __builtin_fabs and specifically in
expand_absneg_bit where we use the MIPS exp instruction to genreate a floating
point absolute value.  I am not sure exactly what the problem is, but if I have
this routine always return NULL_RTX and use a differentr method of computing a
floating point absolute value then my program works.

I thought it might be a simulator issue since I do most of my testing with qemu
but I ran the executable on hardware and got failures there.

The new reduced test case prints with -O0 or -O1 prints:

x = 0.634964 1.298458
In __csinh(1), 0.634964 1.29846
In __csinh(2), 0.634964 1.29846
x = 0.00 0.00

With -O2 or -O3 it prints:

x = 0.634964 1.298458
In __csinh(1), 0.634964 1.29846
In __csinh(2), 1.00959e+116 1.29846
In if statement
x = 0.00 0.00

[Bug target/60604] GCC incorrectly compiles s_csinh function on MIPS

[sje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60604

Steve Ellcey sje at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Steve Ellcey sje at gcc dot gnu.org ---
Richard and Andrew, I hope you don't mind me adding you to the CC list for this
bug but I am curious if you can reproduce this bug and if you have any ideas on
what could be going wrong.

[Bug libstdc++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60612

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |4.8.3

--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
This is a bug in libsupc++, I have a patch to fix it.