[Bug c/60090] New: For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"

[chengniansun at gmail dot com]

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

Bug ID: 60090
   Summary: For expression without ~, gcc -O1 emits "comparison of
promoted ~unsigned with unsigned"
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

For the expression "(l ^ a) != b", gcc -O0 emits no warning, but gcc -O1 emits
a warning "comparison of promoted ~unsigned with unsigned". After checking the
gimple code, I found the optimization transforms the expression to a bitwise
not expression. 

However, in a syntactic perspective, the warning message is confusing, given
the fact that there is no '~' in this expression. 

$: cat s.c
int fn1(unsigned char a, unsigned char b) {
  const unsigned l = 4294967295u;
  return (l ^ a) != b;
}
$: gcc-trunk -c -Wsign-compare s.c
$: gcc-trunk -c -Wsign-compare s.c -O1
s.c: In function ‘fn1’:
s.c:3:18: warning: comparison of promoted ~unsigned with unsigned
[-Wsign-compare]
   return (l ^ a) != b;
  ^

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #45 from Jan Hubicka  ---
The bug here is that lto-cgraph.c still checks DECL_COMDAT as a condition if
symbol is duplicated or partitioned.  We really need to get the logic into
lto-cgraph.c and use same test at both places... Will do that tomorrow.

[Bug fortran/60091] New: Misleading error messages in rank-2 pointer assignment to rank-1 target

[loximann at gmail dot com]

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

Bug ID: 60091
   Summary: Misleading error messages in rank-2 pointer assignment
to rank-1 target
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: loximann at gmail dot com

Compiler version: 4.9.0 20130917 (experimental) [trunk revision 202647]

Test program:

program test
real, target :: a(9)=1.
real, pointer :: p(:,:)

p(:,:)=>a  ! (a) Error: Lower bound has to be present at (1)
p(1:,1:)=>a! (b) Error: Different ranks in pointer assignment at
(1)
p(1:3,1:)=>a   ! (c) Error: Either all or none of the upper bounds must
be specified at (1)
p(1:3,1:3)=>a

end program

According to Note 7.48, "It is possible to obtain different-rank views of parts
of an object by specifying upper bounds in pointer assignment statements."

In my opinion, the error in all (a), (b) and (c) should be in the lines of
"Different ranks in pointer assignment at (1). All lower and upper bounds must
be specified".

[Bug c/60090] For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-06
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
This (and a bunch of other related PRs) is about early folding in the FE.  
c_fully_fold when optimize calls fold_build2 -> fold_binary_loc that transforms
the expression and then we issue those seemingly unrelated warnings.  I'd say
that while we want the exprs to be folded, we should issue diagnostics for the
unfolded exprs.  (I think it's been discussed numerous times in the past.)

Nothing for stage4, but we/I should address this in gcc 5.0.

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-06
 CC||abel at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
GCC right now only handles __restrict on function parameters, so in this case
the aliasing info isn't known.  While the loop is versioned for aliasing at
runtime, the info about that is only known during the vectorizer, therefore
e.g. scheduler can hardly know it.  The pointers to overaligned memory is
something you should generally avoid, __builtin_assume_aligned is what can be
used to tell the compiler about the alignment instead, overaligned types often
actually hurt generated code instead of improving it.  And the way you are
calling posix_memalign is IMHO a strict aliasing violation.

Perhaps GCC could handle posix_memalign specially as builtin if declared with
the right prototype (and optionally some new attribute) and derive both the
aliasing and alignment info from it, like the taking of the address of the
pointer in it isn't really an escape site of any kind, all the call does is
return two values instead of just one, so it could be folded into passing an
address of some temporary to the call instead and then loading from the
temporary and using some special pass-thru builtin that would tell GCC that the
pointer is really malloc-like (non-aliasing anything else) and also
use__builtin_assume_aligned.  The GNU memalign is far better than
posix_memalign from this POV.

Anyway, if I rewrite your testcase as:
#include 
#include 

__attribute__((noinline)) void
foo (double *__restrict__ a, double *__restrict__ b, double *__restrict__ c,
double *__restrict__ d, unsigned long NSIZE)
{
  unsigned long i, j;
  a = __builtin_assume_aligned (a, 32);
  b = __builtin_assume_aligned (b, 32);
  c = __builtin_assume_aligned (c, 32);
  d = __builtin_assume_aligned (d, 32);
  // initialize memory
  for(i=0; i

[Bug c/60090] For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
C++ folds while parsing and here for both -O0 -O we get

y.c: In function ‘int fn1(unsigned char, unsigned char)’:
y.c:3:18: warning: comparison of promoted ~unsigned with unsigned
[-Wsign-compare]
   return (l ^ a) != b;
  ^

[Bug c/60090] For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"

[chengniansun at gmail dot com]

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

--- Comment #3 from Chengnian Sun  ---
Thanks, Marek. 

May I ask another question on the Gcc optimizations and warnings? Is there a
policy that the warnings should be independent of the optimization levels? That
is, for all optimization levels, Gcc should always emit consistent warnings. 

I know that Clang has such a policy. But based on what I have observed on Gcc,
it seems that Gcc does not have this policy.

[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #18 from Jakub Jelinek  ---
Fixed.

[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types

[siddhesh at redhat dot com]

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

--- Comment #14 from Siddhesh Poyarekar  ---
I spoke to Jason last week and have now confirmed that the first fragment
indeed works correctly with 4.8.  Declaring a variable threadprivate *after* it
is defined is not yet supported, but it should not be very difficult to work
around that limitation.

I also have confirmation that the glibc support in place for
threadprivate/thread_local is sufficient and complete, so I'm closing out the
glibc TODO item.

[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r206947.

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
Eric,

could it be that the Finalize procedure is missing some sort of spin lock?



ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ cat
c761007_0.adb

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

with TCTouch;
package body C761007_0 is

  procedure Finalize( I : in out Internal ) is
Previous_Side_Effect : Boolean := False;
  begin
-- look to see if this character has been finalized yet
for SEI in 1..Side_Effect_Finger loop
  Previous_Side_Effect := Previous_Side_Effect
  or Side_Effect(Side_Effect_Finger) = I.Effect;
end loop;

delay 0.01; -- <= additional delay here

-- if not, then tack it on to the string, and touch the character
if not Previous_Side_Effect then
  Side_Effect_Finger := Side_Effect_Finger +1;
  Side_Effect(Side_Effect_Finger) := I.Effect;
  TCTouch.Touch(I.Effect);
end if;

  end Finalize;

end C761007_0;
ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ ./c761007 

,.,. C761007 ACATS 2.5 14-02-06 10:05:45
 C761007 Check that if a finalize procedure invoked by a transfer of
control or selection of a terminate alternative attempts
to propagate an exception, the exception is ignored, but
any other finalizations due to be performed are
performed.
   * C761007 Asynchronously aborted operation Expecting: GHIJ Got:
GHHIJ.
 C761007 FAILED .

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[marcin.krotkiewski at gmail dot com]

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

--- Comment #2 from Marcin Krotkiewski  ---
Jakub, thank you for your comments.

> GCC right now only handles __restrict on function parameters, so in this
> case the aliasing info isn't known.  While the loop is versioned for
> aliasing at runtime, the info about that is only known during the
> vectorizer, therefore e.g. scheduler can hardly know it. 

Does it mean that __restrict is not necessary in order to have a vectorized
code path? I see that if I compile your modified test.c, the loop is vectorized
regardless of whether I use __restrict, or not (runtime versioning). On the
other hand, using __restrict causes gcc to invoke memset for initialization,
while leaving it out results in two paths with a loop.

On the interesting side. Your test.c works indeed if compiled with additional
-fschedule-insns flag. However, if I now remove the __restrict keyword from
function arguments, I do see a vectorized path, but the flag has no effect and
instructions are again not reordered.

> The pointers to
> overaligned memory is something you should generally avoid,
> __builtin_assume_aligned is what can be used to tell the compiler about the
> alignment instead, overaligned types often actually hurt generated code
> instead of improving it.  

Thanks. Could you suggest what is the preferred way to use it in a portable
manner? e.g. make it suitable for icc, which has a __assume_aligned builtin?
Should I wrap it in a macro?

> And the way you are calling posix_memalign is IMHO
> a strict aliasing violation.

Could be,  gcc des not show a warning with -Wall. Thanks for pointing it out.

[Bug c/60090] For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I believe we strive for the warnings be independent of the optimization level,
but it's not always possible, we have tons of bugs where -Wuninitialized
depends on the optimization level, sometimes -Warray-bounds warns only on -O3,
some warnings depend on VRP or SRA, on -O some uses are constant-propagated
etc.  In the middle-end we often warn only about variables in SSA form which
are made, as a part of some optimization, non-addressable.

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
(In reply to Marcin Krotkiewski from comment #2)
> Thanks. Could you suggest what is the preferred way to use it in a portable
> manner? e.g. make it suitable for icc, which has a __assume_aligned builtin?
> Should I wrap it in a macro?

I think you could wrap it in a macro that is defined based on:
#ifdef __INTEL__
# define ...
#elif defined __GNUC__
# define ...
#endif

[Bug middle-end/60089] Complex arithmetic instructions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-06
  Component|rtl-optimization|middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
You'd need to disable complex lowering at the GIMPLE level and see what
support is missing from RTL expansion for example.

For the disabling I'd suggest adding a target hook (if it at any point is
supposed to go upstream).

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
As of posix_memalign the issue is not so much that of alias analysis (we could
handle it but we don't have a builtin right now) but that of alignment analysis
which doesn't implement alignment tracking of pointers stored in memory.  We
could "lower"

  posix_memalign (&ptr, align, size);

to

  posix_memalign (&ptr, align, size);
  ptr = __builtin_assume_algined (ptr, align);

and hope for FRE to fix things up enough to make that useful.

I have opened PR60092.

[Bug middle-end/60092] New: posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

Bug ID: 60092
   Summary: posix_memalign not recognized to derive alias and
alignment info
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: alias, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-02-06
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
As of posix_memalign the issue is not so much that of alias analysis (we could
handle it but we don't have a builtin right now) but that of alignment analysis
which doesn't implement alignment tracking of pointers stored in memory.  We
could "lower"

  posix_memalign (&ptr, align, size);

to

  posix_memalign (&ptr, align, size);
  ptr = __builtin_assume_algined (ptr, align);

and hope for FRE to fix things up enough to make that useful.

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Paulo J. Matos from comment #10)
> (In reply to Paulo J. Matos from comment #8)
> > 
> > Made a mistake. With the attached test, the final gimple before expand for
> > the loop basic block is:
> > ;;   basic block 5, loop depth 0
> > ;;pred:   5
> > ;;4
> >   # i_26 = PHI 
> >   # ivtmp.24_18 = PHI 
> >   _28 = (void *) ivtmp.24_18;
> >   _13 = MEM[base: _28, offset: 0B];
> >   x.4_14 = x;
> >   _15 = _13 ^ x.4_14;
> >   MEM[base: _28, offset: 0B] = _15;
> >   ivtmp.24_12 = ivtmp.24_18 + 4;
> >   temp_ptr.5_17 = (Sample *) ivtmp.24_12;
> >   _11 = (unsigned short) i_26;
> >   _2 = _11 + 1;
> >   i_1 = (short int) _2;
> >   _10 = (int) i_1;
> >   if (_10 < _25)
> > goto ;
> >   else
> > goto ;
> > ;;succ:   5
> > ;;6
> > 
> > However, the point is the same. IVOPTS should probably generate an int IV
> > instead of a short int IV to avoid the sign extend since removing the sign
> > extend during RTL seems to be quite hard.
> > 
> > What do you think?
> 
> For >= 4.8 the scalar evolution of _10 is deemed not simple, because it
> looks like the following:
>   type  size 
> unit size 
> align 32 symtab 0 alias set 3 canonical type 0x2ab16690
> precision 32 min  max  0x2ab12fa0 2147483647> context  D.2881>
> pointer_to_this >
>
> arg 0  type  HI
> size 
> unit size 
> align 16 symtab 0 alias set 4 canonical type 0x2ab16540
> precision 16 min  max  0x2ab12ee0 32767>
> pointer_to_this >
>
> arg 0 
> arg 1  arg 2  0x2acc9140 1>>>
> 
> This is something like: (int) (short int) {1, +, 1}_1. Since these are
> signed integers, we can assume they don't overflow, can't we simplify the
> scalar evolution to a polynomial_chrec over 32bit integers and forget the
> nop_expr that represents the sign extend?

Note that {1, +, 1}_1 is unsigned.  The issue is that while i is short
i++ is really i = (short)((int) i + 1) and thus only the operation in
type 'int' is known to not overflow and thus the IV in short _can_
overflow and the loop can loop infinitely for example for loopCount
== SHORT_MAX + 1.

The fix to SCEV analysis was to still be able to analyze the evolution at all.

The testcase is simply very badly written (unsigned short upper bound,
signed short IV and IV comparison against upper bound in signed int).

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Well, the problem with doing it this way is that ptr is still considered
address taken and the assume aligned then really can result in a noop move.
What I meant is expand:
  ret = posix_memalign (&ptr, align, size);
as
  {
void *temp;
ret = posix_memalign (&temp, align, size);
void *temp2 = __builtin_passthru_attribute_malloc_size (temp, size);
ptr = __typeof (ptr) __builtin_assume_aligned (temp2, align);
temp ={v}{CLOBBER};
  }
The advantages of doing it this way would be that (if ptr is not address taken
for other reasons) that it would not need to be address taken, escape and all
the like, I think posix_memalign is not reading the old content of the pointer
nor storing it anywhere, it just fills it in as another result, just by
reference.
And the optimizers would know it doesn't alias anything, like if it came from
malloc (size);, and is aligned to align bytes at least.
The disadvantage would be that if ptr is addressable for other reasons, we
wouldn't reuse it's address for posix_memalign, but pass address of another
temporary and then copied the mem.

[Bug middle-end/60093] New: ICE on testsuite/c-c++-common/ubsan/overflow-*.c

[bernd.edlinger at hotmail dot de]

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

Bug ID: 60093
   Summary: ICE on testsuite/c-c++-common/ubsan/overflow-*.c
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de

spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-2.c
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/./libsanitizer/
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/./libsanitizer/ubsan/
-L/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/./libsanitizer/ubsan/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -Os
-fsanitize=signed-integer-overflow -lm -o ./overflow-2.exe^M
In file included from
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-2.c:8:0:^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c: In
function 'main':^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:40:
internal compiler error: in simplify_subreg, at simplify-rtx.c:5903^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:12:29:
note: in definition of macro 'CHECK'^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:10:
note: in expansion of macro 'FN1'^M
0x57f3e3 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)^M
../../gcc-4.9-20140202/gcc/simplify-rtx.c:5902^M
0x57f793 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)^M
../../gcc-4.9-20140202/gcc/simplify-rtx.c:6123^M
0x2ded5b operand_subword_force(rtx_def*, unsigned int, machine_mode)^M
../../gcc-4.9-20140202/gcc/emit-rtl.c:1455^M
0x4da013 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)^M
../../gcc-4.9-20140202/gcc/optabs.c:1813^M
0x2efc2b expand_shift_1^M
../../gcc-4.9-20140202/gcc/expmed.c:2287^M
0x402b2f ubsan_expand_si_overflow_mul_check(gimple_statement_base*)^M
../../gcc-4.9-20140202/gcc/internal-fn.c:649^M
0x228667 expand_call_stmt^M
../../gcc-4.9-20140202/gcc/cfgexpand.c:2188^M
0x228667 expand_gimple_stmt_1^M
../../gcc-4.9-20140202/gcc/cfgexpand.c:3157^M
0x228667 expand_gimple_stmt^M
../../gcc-4.9-20140202/gcc/cfgexpand.c:3309^M
0x22998b expand_gimple_basic_block^M
../../gcc-4.9-20140202/gcc/cfgexpand.c:5149^M
0x22b88b gimple_expand_cfg^M
../../gcc-4.9-20140202/gcc/cfgexpand.c:5715^M
0x22b88b execute^M
../../gcc-4.9-20140202/gcc/cfgexpand.c:5935^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M


same for 

FAIL: c-c++-common/ubsan/overflow-mul-3.c  -Os  (internal compiler error)
FAIL: c-c++-common/ubsan/overflow-mul-4.c  -Os  (internal compiler error)

[Bug middle-end/60089] Complex arithmetic instructions

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)

> For the disabling I'd suggest adding a target hook (if it at any point is
> supposed to go upstream).

This target hook would be handy also for x86_64, which passes packed complex
SFmode values to and from function:

Following test:

_Complex float testf (_Complex float a, _Complex float b)
{
return a + b;
}

produces (-O2):

testf:
movq%xmm0, -8(%rsp)
movq%xmm1, -16(%rsp)
movss   -4(%rsp), %xmm0
movss   -8(%rsp), %xmm1
addss   -12(%rsp), %xmm0
addss   -16(%rsp), %xmm1
movss   %xmm0, -20(%rsp)
movss   %xmm1, -24(%rsp)
movq-24(%rsp), %xmm0
ret

Yes, indeed.

[Bug middle-end/60093] ICE on testsuite/c-c++-common/ubsan/overflow-*.c

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Target||armv7l-unknown-linux-gnueab
   ||ihf

--- Comment #1 from Bernd Edlinger  ---
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-4.9-20140202/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard

[Bug middle-end/59150] [4.9 Regression] ICE: in expand_one_var, at cfgexpand.c:1242 with -fopenmp

[sebastian.hu...@embedded-brains.de]

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

--- Comment #7 from Sebastian Huber  ---
Your patch fixed the problem on arm-rtems:

http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00303.html

[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 32063
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32063&action=edit
gcc49-pr60077.patch

Untested fix.

[Bug target/60094] New: gcc.target/arm/ftest-armv7em-thumb.c fails

[bernd.edlinger at hotmail dot de]

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

Bug ID: 60094
   Summary: gcc.target/arm/ftest-armv7em-thumb.c fails
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de

spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7em-thumb.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mthumb -march=armv7e-m
-mthumb -S -o ftest-armv7em-thumb.s^M
In file included from
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7em-thumb.c:37:0:^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:108:4:
error: #error __ARM_FEATURE_DSP is not defined but should be^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:122:4:
error: #error __ARM_FEATURE_SIMD32 is not defined but should be^M
compiler exited with status 1



almost the same:
FAIL: gcc.target/arm/ftest-armv7m-thumb.c (test for excess errors)

spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mthumb -march=armv7-m
-mthumb -S -o ftest-armv7m-thumb.s^M
In file included from
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c:31:0:^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:28:4:
error: #error __ARM_ARCH_ISA_ARM is defined but should not be^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:49:5:
error: #error __ARM_ARCH_PROFILE has unexpected value^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:77:5:
error: #error __ARM_FEATURE_LDREX has unexpected value^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:112:4:
error: #error __ARM_FEATURE_DSP is defined but should not be^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:126:4:
error: #error __ARM_FEATURE_SIMD32 is defined but should not be^M
compiler exited with status 1


root@socfpga_cyclone5:/home/ed/gnu/arm-linux-gnueabihf/bin# ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-4.9-20140202/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 4.9.0 20140202 (experimental) (GCC)

[Bug target/60094] gcc.target/arm/ftest-armv7em-thumb.c fails

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Target||armv7l-unknown-linux-gnueab
   ||ihf

--- Comment #1 from Bernd Edlinger  ---
this one's probably also related:

spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7r-arm.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -marm -march=armv7-r -S
-o ftest-armv7r-arm.s^M
In file included from
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7r-arm.c:40:0:^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:49:5:
error: #error __ARM_ARCH_PROFILE has unexpected value^M
compiler exited with status 1


spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7ve-arm.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -marm -march=armv7ve -S
-o ftest-armv7ve-arm.s^M
xgcc: error: unrecognized argument in option '-march=armv7ve'^M
xgcc: note: valid arguments to '-march=' are: armv2 armv2a armv3 armv3m armv4
armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2
armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv8-a armv8-a+crc
iwmmxt iwmmxt2 native^M
compiler exited with status 1


spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv8a-arm.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -marm -march=armv8-a -S
-o ftest-armv8a-arm.s^M
/home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv8a-arm.c:1:0:
error: target CPU does not support ARM mode^M
compiler exited with status 1

[Bug target/60062] [4.7/4.9 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  6 10:54:20 2014
New Revision: 207549

URL: http://gcc.gnu.org/viewcvs?rev=207549&root=gcc&view=rev
Log:
PR target/60062
* tree.h (opts_for_fn): New inline function.
(opt_for_fn): Define.
* config/i386/i386.c (ix86_function_regparm): Use
opt_for_fn (decl, optimize) instead of optimize.

* gcc.c-torture/execute/pr60062.c: New test.
* gcc.c-torture/execute/pr60072.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr60062.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr60072.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.h

[Bug middle-end/59150] [4.9 Regression] ICE: in expand_one_var, at cfgexpand.c:1242 with -fopenmp

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  6 10:59:30 2014
New Revision: 207551

URL: http://gcc.gnu.org/viewcvs?rev=207551&root=gcc&view=rev
Log:
PR middle-end/59150
* tree-vect-data-refs.c (vect_analyze_data_refs): For clobbers, call
free_data_ref on the dr first, and before goto again also set dr
to the next dr.  For simd_lane_access, free old datarefs[i] before
overwriting it.  For get_vectype_for_scalar_type failure, don't
free_data_ref if simd_lane_access.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug middle-end/60089] Complex arithmetic instructions

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Richard Biener from comment #1)
> You'd need to disable complex lowering at the GIMPLE level and see what
> support is missing from RTL expansion for example.
> 
> For the disabling I'd suggest adding a target hook (if it at any point is
> supposed to go upstream).

Couldn't the complex lowering pass check optab, like vector lowering does?

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-02-06
 Ever confirmed|0   |1

--- Comment #9 from Dominique d'Humieres  ---
The test works for me on x86_64-apple-darwin13 on trunk configured with

../work/configure --prefix=/opt/gcc/gcc4.9w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7

for the different tests I have done: separate files/one file, -m64 (default) or
-m32, -O3/-Ofast, -static. It works also with gfortran 4.7.4 and 4.8.2/3.

Note that I had to user the clang assembler since the as provided by apple is
too old, but it should not matter.

I have similar results on x86_64-apple-darwin10 (core2) with less accepted
options. valgrind reports no error with '-std=f95 -Wall -Wextra -Ofast
-march=native -ggdb', but is not happy if I add -m32, though the executable
still works outside valgrind.

One comment about you configure: you should NEVER use --disable-werror: if your
are unable to bootstrap without it, it means you are likely to have problems
later.

What happens if you configure without graphite, i.e., no cloog stuff?

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[pa...@matos-sorge.com]

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

--- Comment #13 from Paulo J. Matos  ---
(In reply to Richard Biener from comment #12)
> 
> Note that {1, +, 1}_1 is unsigned.  The issue is that while i is short
> i++ is really i = (short)((int) i + 1) and thus only the operation in
> type 'int' is known to not overflow and thus the IV in short _can_
> overflow and the loop can loop infinitely for example for loopCount
> == SHORT_MAX + 1.
> 
> The fix to SCEV analysis was to still be able to analyze the evolution at
> all.
> 
> The testcase is simply very badly written (unsigned short upper bound,
> signed short IV and IV comparison against upper bound in signed int).

I thought any signed operation cannot overflow, independently on its width,
therefore (short) (int + 1) shouldn't overflow.

I agree with you on the testcase, however, that's taken from customer code and
it's even if badly written, it's acceptable C. GCC 4.5.4 generates the scalar
evolution for the integer variable: {1, +, 1}_1 without the casts (therefore a
simple_iv). This allows GCC to use an int for an IV which helps discard the
sign extend in the loop body and later on allows the zero overhead loop being
generated. This case happens again and again and causes serious performance
regression on customer code.

[Bug target/60094] gcc.target/arm/ftest-armv7em-thumb.c fails

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Bernd, which revision is this?
I thought this would have been fixed with r207418

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[pa...@matos-sorge.com]

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

--- Comment #14 from Paulo J. Matos  ---
Something like this which looks much simpler hits the same problem:
extern int arr[];

void
foo32 (int limit)
{
  short i;
  for (i = 0; (int)i < limit; i++)
arr[i] += 1;
}

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Created attachment 32064
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32064&action=edit
part #1, aliasing

I've implemented the aliasing parts (and the builtin obviously).

It's true that doing

  posix_memalign (&ptr, );
  ptr = __builtin_assume_aligned (ptr, ...);

will keep ptr address-taken - but isn't it kept address-taken anyway because
it's passed to posix_memalign?

I think you are mixing the possible optimization we can do to posix_memalign
in general with the alignment issue, no?  Thus, we could transform

  posix_memalign (&ptr, );

to

  void *tem;
  posix_memalign (&tem, );
  ptr = tem;

independently.  Doing it as part of the alignment stuff of course makes sense.
But as you say, eventually we'd just use an extra stack slot for no good
reason.
I've long thought of teaching some more tricks to update_address_taken -
basically ignore some of the address-takens and apply simple transforms on
the stmts causing them if that would make the var non-address-taken
(memcpy comes to my mind as well here).

[Bug ada/60078] acats c761007 fails on ARM

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> could it be that the Finalize procedure is missing some sort of spin lock?

There are already explicit delays in the test, so very likely not.

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> 
> --- Comment #14 from Paulo J. Matos  ---
> Something like this which looks much simpler hits the same problem:
> extern int arr[];
> 
> void
> foo32 (int limit)
> {
>   short i;
>   for (i = 0; (int)i < limit; i++)
> arr[i] += 1;
> }

Exactly the same problem.  C integral type promotion rules make
that i = (short)((int)i + 1) again.  Note that (int)i + 1
does not overflow, (short) ((int)i + 1) invokes implementation-defined
behavior which in our case is modulo-2 reduction.

Nothing guarantees that (short)i + 1 does not overflow.

[Bug target/60094] gcc.target/arm/ftest-armv7em-thumb.c fails

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
trunk revision 207409

Well, in this case, I'll repeat this test next week.(In reply to ktkachov from
comment #2)
> Bernd, which revision is this?
> I thought this would have been fixed with r207418

trunk revision 207409

Well, in this case, I'll repeat this test next week.
Thanks.

[Bug middle-end/60080] gcc.dg/vect/vect-nop-move.c FAILs

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #1 from Bernd Edlinger  ---
Richard,

how about this?

--- gcc/cfgexpand.c.jj2014-01-09 21:12:36.0 +0100
+++ gcc/cfgexpand.c2014-02-06 13:01:09.280392442 +0100
@@ -2678,8 +2678,9 @@ expand_asm_operands (tree string, tree o
   ASM_OPERANDS_INPUT (body, i) = op;

   ASM_OPERANDS_INPUT_CONSTRAINT_EXP (body, i)
-= gen_rtx_ASM_INPUT (TYPE_MODE (type),
- ggc_strdup (constraints[i + noutputs]));
+= gen_rtx_ASM_INPUT_loc (TYPE_MODE (type),
+ ggc_strdup (constraints[i + noutputs]),
+ locus);

   if (tree_conflicts_with_clobbers_p (val, &clobbered_regs))
 clobber_conflict_found = 1;
@@ -2701,7 +2702,7 @@ expand_asm_operands (tree string, tree o

   sprintf (buffer, "%d", j);
   ASM_OPERANDS_INPUT_CONSTRAINT_EXP (body, ninputs - ninout + i)
-= gen_rtx_ASM_INPUT (inout_mode[i], ggc_strdup (buffer));
+= gen_rtx_ASM_INPUT_loc (inout_mode[i], ggc_strdup (buffer), locus);
 }

   /* Copy labels to the vector.  */

[Bug c++/60095] New: Dubious diagnostics for attempted surrogate call function

[lucdanton at free dot fr]

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

Bug ID: 60095
   Summary: Dubious diagnostics for attempted surrogate call
function
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

Using ‘gcc version 4.9.0 20140123 (experimental) (GCC)’ with the following
snippet:

//

struct foo {
typedef void(*ptr)(int&);
operator ptr() const;
};

int main()
{
foo f;
void* p = 0;
f(p);
}

//

$ g++-trunk -std=c++03 main.cpp 
main.cpp: In function 'int main()':
main.cpp:10:8: error: no match for call to '(foo) (void*&)'
 f(p);
^
main.cpp:1:8: note: candidate is:
 struct foo {
^
main.cpp:10:8: note: foo::ptr {aka void (*)(int&)} 
 f(p);
^
main.cpp:10:8: note:   candidate expects 2 arguments, 2 provided

Same output for all -std=c++{03,11,1y} modes. If e.g. foo has a call operator
instead, then the appropriate ‘no known conversion for argument 1 from 'void*'
to 'int&'’ is produced.

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #8 from Bernd Edlinger  ---
(In reply to Eric Botcazou from comment #7)
> > could it be that the Finalize procedure is missing some sort of spin lock?
> 
> There are already explicit delays in the test, so very likely not.

I added the line "delay 0.01; -- <= additional delay here"

and the result was the test fails on X86_64.

If I rewrite both Finalize methods to use protected data like this
the test starts to pass again with the delays.

$ cat c761007_0.ads

with Ada.Finalization;
package C761007_0 is

  type Internal is new Ada.Finalization.Controlled
with record
  Effect : Character;
end record;

  procedure Finalize( I: in out Internal );

  protected Data is
procedure Add( Effect : Character );
  private
Side_Effect : String(1..80);  -- way bigger than needed
Side_Effect_Finger : Natural := 0;
  end Data;

end C761007_0;


$ cat c761007_0.adb:

with TCTouch;
package body C761007_0 is

  procedure Finalize( I : in out Internal ) is
  begin
Data.Add(I.Effect);
  end Finalize;

  protected body Data is
procedure Add( Effect : Character ) is
  Previous_Side_Effect : Boolean := False;
begin
  -- look to see if this character has been finalized yet
  for SEI in 1..Side_Effect_Finger loop
Previous_Side_Effect := Previous_Side_Effect
or Side_Effect(Side_Effect_Finger) = Effect;
  end loop;

  delay 0.01; -- <= additional delay here

  -- if not, then tack it on to the string, and touch the character
  if not Previous_Side_Effect then
Side_Effect_Finger := Side_Effect_Finger +1;
Side_Effect(Side_Effect_Finger) := Effect;
TCTouch.Touch(Effect);
  end if;

end Add;
  end Data;

end C761007_0;

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[pa...@matos-sorge.com]

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

--- Comment #16 from Paulo J. Matos  ---
(In reply to rguent...@suse.de from comment #15)
> Exactly the same problem.  C integral type promotion rules make
> that i = (short)((int)i + 1) again.  Note that (int)i + 1
> does not overflow, (short) ((int)i + 1) invokes implementation-defined
> behavior which in our case is modulo-2 reduction.
> 
> Nothing guarantees that (short)i + 1 does not overflow.

OK, that makes sense. But in GCC 4.8 that doesn't seem to be what happens.
It seems to be i = (short) ((unsigned short) i + 1)
Later i is cast to int for comparison.

Before ivopts this is the end of the loop body:
  i.7_19 = (unsigned short) i_26;
  _20 = i.7_19 + 1;
  i_21 = (short intD.8) _20;
  _10 = (intD.1) i_21;
  if (_10 < _25)
goto ;
  else
goto ;

i is initially a short, then moved to unsigned short. The addition is performed
and returned to short. Then cast to int for the comparison.

For GCC 4.5.4 the end of loop body is:
  iD.2767_18 = iD.2767_26 + 1;
  D.5046_9 = (intD.0) iD.2767_18;
  if (D.5046_9 < D.5047_25)
goto ;
  else
goto ;

Here the addition is made in short int and then there's only one cast to int.

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Hack: when the return value of posix_memalign is ignored, if the platform
supports it, replace with a call to aligned_alloc (C11), which has an easier
interface.

[Bug c/60090] For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #1)
> This (and a bunch of other related PRs) is about early folding in the FE.  
> c_fully_fold when optimize calls fold_build2 -> fold_binary_loc that
> transforms the expression and then we issue those seemingly unrelated
> warnings.  I'd say that while we want the exprs to be folded, we should
> issue diagnostics for the unfolded exprs.  (I think it's been discussed
> numerous times in the past.)
> 
> Nothing for stage4, but we/I should address this in gcc 5.0.

I think this should be the plan:

http://gcc.gnu.org/ml/gcc/2013-11/msg00253.html

but someone has to implement it ;-)

In those cases where folding helps to avoid false positives, it would be nice
to be able to still fold on-demand or to delay the warnings until folding can
happen.

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
Created attachment 32065
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32065&action=edit
possible fix

well, I don't know if the Finalize method are supposed
to be called in a sequential manner, which GNAT does obviously not
guarantee.
But how about this, for a fix?

[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect

[izamyatin at gmail dot com]

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

--- Comment #3 from Igor Zamyatin  ---
Vectorizer dump snippet for main:

  foo.simdclone.0 (vect__12.7_3, vect_cst_.8_53, vect_cst_.8_53,
vect_cst_.9_51, vect_cst_.9_51);
  GIMPLE_NOP
  vect_v1.12_37 = MEM[(int *)vectp_v1.10_39];   (1)
  v1.0_14 = v1;
  vect_v2.16_60 = MEM[(int *)vectp_v2.14_58];   (2)
  v2.1_15 = v2;
  vect__16.18_63 = vect_cst_.13_7 * vect_cst_.17_62;  <--- constants instead of 
  _16 = v1.0_14 * v2.1_15; vect_v1.12_37 and
  MEM[(int *)vectp_a.19_65] = vect__16.18_63;  vect_v2.16_60 


Then DCE destroys (1) and (2) and later LIM hoists the multiplication away from
the loop.

[Bug c/60090] For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
(In reply to Manuel López-Ibáñez from comment #5)
> http://gcc.gnu.org/ml/gcc/2013-11/msg00253.html

Exactly.  I hope I can tackle at least a part of it in next stage 1.

> In those cases where folding helps to avoid false positives, it would be nice
> to be able to still fold on-demand or to delay the warnings until folding can 
> happen.

Sure.

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[pa...@matos-sorge.com]

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

--- Comment #17 from Paulo J. Matos  ---
(In reply to rguent...@suse.de from comment #15)
> On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> > 
> > --- Comment #14 from Paulo J. Matos  ---
> > Something like this which looks much simpler hits the same problem:
> > extern int arr[];
> > 
> > void
> > foo32 (int limit)
> > {
> >   short i;
> >   for (i = 0; (int)i < limit; i++)
> > arr[i] += 1;
> > }
> 
> Exactly the same problem.  C integral type promotion rules make
> that i = (short)((int)i + 1) again.  Note that (int)i + 1
> does not overflow, (short) ((int)i + 1) invokes implementation-defined
> behavior which in our case is modulo-2 reduction.
> 
> Nothing guarantees that (short)i + 1 does not overflow.

I am being thick... indeed I forgot to notice that i++ also invokes undefined
behaviour. I guess then GCC sorts that out by casting i into unsigned short for
the addition and all the remaining issues then unfold.

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 32066
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32066&action=edit
part #2, C11 aligned_alloc

It was noted that aligned_alloc is standard enough to be supported (and with
nicer interface albeit possibly clobbering errno ...).

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #4)
> Hack: when the return value of posix_memalign is ignored, if the platform
> supports it, replace with a call to aligned_alloc (C11), which has an easier
> interface.

The question is if posix_memalign is allowed to change errno.  If it is, then
making glibc contains say something like:

extern int __REDIRECT_NTH (__posix_memalign_alias,
   (void ** __ptr, size_t __alignment, size_t __size),
   posix_memalign) __nonnull ((1)) __wur;
extern void *__REDIRECT_NTH (__memalign_alias,
   (size_t __alignment, size_t __size),
   memalign)  __attribute__ ((__malloc__,
__alloc_size__ (2)));

__extern_inline int
posix_memalign (void **__ptr, size_t __alignment, size_t __size)
{
  if (__builtin_constant_p (__alignment))
{
  if (__alignment == 0
  || __alignment & (__alignment - 1)) != 0
  || __alignment % sizeof (void *))
return EINVAL;
  void *__res = __memalign_alias (__alignment, __size);
  if (__res == NULL)
return ENOMEM;
  *__ptr = __res;
  return 0;
}
  return __posix_memalign_alias (__ptr, __alignment, __size);
}

But looking at glibc sources, even posix_memalign actually changes errno.
Tbe problem with this inline version is that user aliasing bugs will trigger
people more often, and that some hack will need to be find out for the EINVAL
and ENOMEM values (because, stdlib.h is not supposed to include errno.h I
guess, so it would need to be some __EINVAL/__ENOMEM value determined by
configure or something).

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> 
> --- Comment #17 from Paulo J. Matos  ---
> (In reply to rguent...@suse.de from comment #15)
> > On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> > > 
> > > --- Comment #14 from Paulo J. Matos  ---
> > > Something like this which looks much simpler hits the same problem:
> > > extern int arr[];
> > > 
> > > void
> > > foo32 (int limit)
> > > {
> > >   short i;
> > >   for (i = 0; (int)i < limit; i++)
> > > arr[i] += 1;
> > > }
> > 
> > Exactly the same problem.  C integral type promotion rules make
> > that i = (short)((int)i + 1) again.  Note that (int)i + 1
> > does not overflow, (short) ((int)i + 1) invokes implementation-defined
> > behavior which in our case is modulo-2 reduction.
> > 
> > Nothing guarantees that (short)i + 1 does not overflow.
> 
> I am being thick... indeed I forgot to notice that i++ also invokes undefined
> behaviour. I guess then GCC sorts that out by casting i into unsigned short 
> for
> the addition and all the remaining issues then unfold.

No, i++ doesn't invoke undefined behavior - that's the whole point
and GCC got this wrong until it was fixed (4.5 is still broken).
The whole point is that limit == SHORT_MAX + 1 and the loop being
endless is _valid_ (well, apart from arr[i] then overflowing - looks
like an opportunity to derive that i can _not_ overflow ... ;))

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Marc Glisse from comment #4)
> > Hack: when the return value of posix_memalign is ignored, if the platform
> > supports it, replace with a call to aligned_alloc (C11), which has an easier
> > interface.
> 
> The question is if posix_memalign is allowed to change errno.  If it is,
> then making glibc contains say something like:
> 
> extern int __REDIRECT_NTH (__posix_memalign_alias,
>(void ** __ptr, size_t __alignment, size_t
> __size),
>posix_memalign) __nonnull ((1)) __wur;
> extern void *__REDIRECT_NTH (__memalign_alias,
>(size_t __alignment, size_t __size),
>memalign)  __attribute__ ((__malloc__,
> __alloc_size__ (2)));
> 
> __extern_inline int
> posix_memalign (void **__ptr, size_t __alignment, size_t __size)
> {
>   if (__builtin_constant_p (__alignment))
> {
>   if (__alignment == 0
>   || __alignment & (__alignment - 1)) != 0
>   || __alignment % sizeof (void *))
> return EINVAL;
>   void *__res = __memalign_alias (__alignment, __size);
>   if (__res == NULL)
> return ENOMEM;
>   *__ptr = __res;
>   return 0;
> }
>   return __posix_memalign_alias (__ptr, __alignment, __size);
> }
> 
> But looking at glibc sources, even posix_memalign actually changes errno.
> Tbe problem with this inline version is that user aliasing bugs will trigger
> people more often, and that some hack will need to be find out for the
> EINVAL and ENOMEM values (because, stdlib.h is not supposed to include
> errno.h I guess, so it would need to be some __EINVAL/__ENOMEM value
> determined by configure or something).

According to the specification this is wrong.  Note that changing errno
is hindering optimization.  For example

int foo (int *p)
{
  *p = 1;
  malloc (4);
  return *p;
}

cannot CSE *p because p may point to errno.  (works for float *p and
works when using posix_memalign with my patch)

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de  ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> 
> --- Comment #16 from Paulo J. Matos  ---
> (In reply to rguent...@suse.de from comment #15)
> > Exactly the same problem.  C integral type promotion rules make
> > that i = (short)((int)i + 1) again.  Note that (int)i + 1
> > does not overflow, (short) ((int)i + 1) invokes implementation-defined
> > behavior which in our case is modulo-2 reduction.
> > 
> > Nothing guarantees that (short)i + 1 does not overflow.
> 
> OK, that makes sense. But in GCC 4.8 that doesn't seem to be what happens.
> It seems to be i = (short) ((unsigned short) i + 1)
> Later i is cast to int for comparison.
> 
> Before ivopts this is the end of the loop body:
>   i.7_19 = (unsigned short) i_26;
>   _20 = i.7_19 + 1;
>   i_21 = (short intD.8) _20;
>   _10 = (intD.1) i_21;
>   if (_10 < _25)
> goto ;
>   else
> goto ;
> 
> i is initially a short, then moved to unsigned short. The addition is 
> performed
> and returned to short. Then cast to int for the comparison.
> 
> For GCC 4.5.4 the end of loop body is:
>   iD.2767_18 = iD.2767_26 + 1;
>   D.5046_9 = (intD.0) iD.2767_18;
>   if (D.5046_9 < D.5047_25)
> goto ;
>   else
> goto ;
> 
> Here the addition is made in short int and then there's only one cast to int.

Yes, and thus GCC 4.5 still contains the bug that i++ invokes undefined
behavior when overflowing (which it does not).

Re: [Bug ada/60078] acats c761007 fails on ARM

[Arnaud Charlet]

> well, I don't know if the Finalize method are supposed
> to be called in a sequential manner, which GNAT does obviously not
> guarantee.
> But how about this, for a fix?

That can't be a fix, only a workaround hiding a potential issue.

Your patch is completely changing the semantic and purpose of the test, which
is basically equivalent to removing the test altogether.

Furthermore, you can't put a delay statement inside
a protected procedure, it's a potentially blocking operation.

Arno

[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  ---
Author: amodra
Date: Thu Feb  6 13:25:38 2014
New Revision: 207553

URL: http://gcc.gnu.org/viewcvs?rev=207553&root=gcc&view=rev
Log:
PR target/60032
gcc/
* config/rs6000/rs6000.c (rs6000_secondary_memory_needed_mode): Only
change SDmode to DDmode when lra_in_progress.
gcc/testsuite/
* gcc.target/powerpc/pr60032.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr60032.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/60078] acats c761007 fails on ARM

[charlet at adacore dot com]

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

--- Comment #10 from charlet at adacore dot com  ---
> well, I don't know if the Finalize method are supposed
> to be called in a sequential manner, which GNAT does obviously not
> guarantee.
> But how about this, for a fix?

That can't be a fix, only a workaround hiding a potential issue.

Your patch is completely changing the semantic and purpose of the test, which
is basically equivalent to removing the test altogether.

Furthermore, you can't put a delay statement inside
a protected procedure, it's a potentially blocking operation.

Arno

[Bug c++/60096] New: c++11 lambda reference capture mistake

[feng.w...@uni-ulm.de]

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

Bug ID: 60096
   Summary: c++11 lambda reference capture mistake
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: feng.w...@uni-ulm.de

considering the following code:
[code]
#include 

int main()
{
std::cout <<
[]( int x )
{
return [&](int y)
{
return x+y;
}(2);
}(5)
  << "\n";
std::cout << []( int x )
 {
return [&x](int y)
{
return x+y;
};
 }(2)(5)
  << "\n";
std::cout << []( int x )
 {
return [x](int y)
{
return x+y;
};
 }(2)(5)
  << "\n";

return 0;
}
[/code]
the output produced by g++4.8 and g++4.9 is 
[output]
7
10
7
[/output]
while the expected output is 
[output]
7
7
7
[/output]

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
(In reply to char...@adacore.com from comment #10)
> > well, I don't know if the Finalize method are supposed
> > to be called in a sequential manner, which GNAT does obviously not
> > guarantee.
> > But how about this, for a fix?
> 
> That can't be a fix, only a workaround hiding a potential issue.
> 
> Your patch is completely changing the semantic and purpose of the test, which
> is basically equivalent to removing the test altogether.
> 
> Furthermore, you can't put a delay statement inside
> a protected procedure, it's a potentially blocking operation.
> 
> Arno

Hmm, thanks.

of course the delay was only meant to bring it to the point.

And it generates a warning when it is in a protected block, I know.

The point is, even with a short delay here the test should pass,
right?

What is the test supposed to do?

could you explain, why the test fails when the delay is added to the
unmodified test case?

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #7)
> According to the specification this is wrong.  Note that changing errno
> is hindering optimization.  For example
> 
> int foo (int *p)
> {
>   *p = 1;
>   malloc (4);
>   return *p;
> }
> 
> cannot CSE *p because p may point to errno.  (works for float *p and
> works when using posix_memalign with my patch)

Well, e.g.
http://pubs.opengroup.org/onlinepubs/007904975/functions/posix_memalign.html
says nothing about errno, I think only functions which explicitly document not
to clobber errno may not, all other functions may, but it's value is undefined
after the call.  For calls that are documented to change errno in some cases,
it is again defined only if those calls return a particular value (e.g. -1),
otherwise errno is still undefined.

Re: [Bug ada/60078] acats c761007 fails on ARM

[Arnaud Charlet]

> What is the test supposed to do?

Looks at the top of c761007.a, you'll find answers to this question.

> could you explain, why the test fails when the delay is added to the
> unmodified test case?

Sorry, I'm not following you here, I do not know which delay you would
add where (and why).

Arno

[Bug ada/60078] acats c761007 fails on ARM

[charlet at adacore dot com]

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

--- Comment #12 from charlet at adacore dot com  ---
> What is the test supposed to do?

Looks at the top of c761007.a, you'll find answers to this question.

> could you explain, why the test fails when the delay is added to the
> unmodified test case?

Sorry, I'm not following you here, I do not know which delay you would
add where (and why).

Arno

[Bug c++/60097] New: spurious warning about command line option "-Wno-mismatched-tags"

[dan at math dot uiuc.edu]

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

Bug ID: 60097
   Summary: spurious warning about command line option
"-Wno-mismatched-tags"
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dan at math dot uiuc.edu

int x;
char y;
void f () { y=x; }
/*
 compile with

 g++ -c -Wconversion -Wno-mismatched-tags

 get this:

foo.cc: In function 'void f()':
foo.cc:3:14: warning: conversion to 'char' from 'int' may alter its value
[-Wconversion]
 void f () { y=x; }
  ^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-mismatched-tags"
[enabled by default]

 the warning about -Wno-mismatched-tags is false, because it is not issued when
compiling with

g++ -c -Wno-mismatched-tags

 info:

happens under Mac OS X with the compiler below, and also under Ubuntu
with an older compiler

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
   
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc48/4.8.2/libexec/gcc/x86_64-apple-darwin13.0.2/4.8.2/lto-wrapper
Target: x86_64-apple-darwin13.0.2
Configured with: ../configure --build=x86_64-apple-darwin13.0.2
--prefix=/usr/local/Cellar/gcc48/4.8.2 --enable-languages=c,c++,objc,obj-c++
--program-suffix=-4.8 --with-gmp=/usr/local/opt/gmp4
--with-mpfr=/usr/local/opt/mpfr2 --with-mpc=/usr/local/opt/libmpc08
--with-cloog=/usr/local/opt/cloog018 --with-isl=/usr/local/opt/isl011
--with-system-zlib --enable-version-specific-runtime-libs
--enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release
--enable-lto --disable-werror --enable-plugin --disable-nls --disable-multilib
Thread model: posix
gcc version 4.8.2 (GCC) 

 */

[Bug middle-end/60080] gcc.dg/vect/vect-nop-move.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I just tried the patch on i386-pc-solaris2.10 and the SEGVs are gone.

Thanks for the quick fix.

Rainer

[Bug c/60087] Incorrect column number for -Wsign-compare

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Feb  6 13:57:37 2014
New Revision: 207554

URL: http://gcc.gnu.org/viewcvs?rev=207554&root=gcc&view=rev
Log:
PR c/60087
c-family/
* c-common.c (warn_for_sign_compare): Call warning_at with location
instead of warning.
testsuite/
* gcc.dg/pr60087.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr60087.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c/60087] Incorrect column number for -Wsign-compare

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/60096] c++11 lambda reference capture mistake

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This looks invalid to me, you return a closure that holds a dangling reference
to a function parameter that has gone out of scope.

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger  ---
(In reply to char...@adacore.com from comment #12)
> > could you explain, why the test fails when the delay is added to the
> > unmodified test case?
> 
> Sorry, I'm not following you here, I do not know which delay you would
> add where (and why).
> 
> Arno

I am here, because this test seems to fail on a Dual-Core ARM
running Linux version 3.7.0.

What it looks like for me, is this is executed on two cores in parallel:

   -- look to see if this character has been finalized yet
for SEI in 1..Side_Effect_Finger loop
  Previous_Side_Effect := Previous_Side_Effect
  or Side_Effect(Side_Effect_Finger) = I.Effect;
end loop;

-- if not, then tack it on to the string, and touch the character
if not Previous_Side_Effect then
  Side_Effect_Finger := Side_Effect_Finger +1;
  Side_Effect(Side_Effect_Finger) := I.Effect;
  TCTouch.Touch(I.Effect);
end if;

and both try to add "G" to Side_Effect. Both execute the for loop,
and both don't see each other, thus Previous_Side_Effect := False.
Then both enter the if statement, and end up with GGHIJ => test FAILED.

To make it reproducible, I added a delay 0.01 between for and if statement
and this made the test fail every time, even on X86_64.

If the test is OK as it is, then it is probably the responsibility
of the runtime to ony execute one Finalize method at the time?

So is it a bug in the Test Case or in the GNAT or on my hardware?


Bernd.

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Thu, 6 Feb 2014, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
> 
> --- Comment #8 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #7)
> > According to the specification this is wrong.  Note that changing errno
> > is hindering optimization.  For example
> > 
> > int foo (int *p)
> > {
> >   *p = 1;
> >   malloc (4);
> >   return *p;
> > }
> > 
> > cannot CSE *p because p may point to errno.  (works for float *p and
> > works when using posix_memalign with my patch)
> 
> Well, e.g.
> http://pubs.opengroup.org/onlinepubs/007904975/functions/posix_memalign.html
> says nothing about errno, I think only functions which explicitly document not
> to clobber errno may not, all other functions may, but it's value is undefined
> after the call.  For calls that are documented to change errno in some cases,
> it is again defined only if those calls return a particular value (e.g. -1),
> otherwise errno is still undefined.

Ok, my manpage says

RETURN VALUE
   aligned_alloc(), memalign(), valloc(), and pvalloc() return  a  
pointer
   to the allocated memory, or NULL if the request fails.

   posix_memalign()  returns  zero  on success, or one of the error 
values
   listed in the next section on failure.  Note that errno is not set.

so that must be incorrect.

If the value of errno is undefined after posix_memalign that doesn't
help us as we then still cannot CSE.

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #9)
> Ok, my manpage says
> 
> RETURN VALUE
>aligned_alloc(), memalign(), valloc(), and pvalloc() return  a  
> pointer
>to the allocated memory, or NULL if the request fails.
> 
>posix_memalign()  returns  zero  on success, or one of the error 
> values
>listed in the next section on failure.  Note that errno is not set.
> 
> so that must be incorrect.
> 
> If the value of errno is undefined after posix_memalign that doesn't
> help us as we then still cannot CSE.

Linux man pages are often incorrect, better look at the 3p ones ;).

[Bug c++/19377] Using declaration in "private" part causes "protected" diagnostic

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org

--- Comment #9 from Andrey Belevantsev  ---
Another test case of the same issue (both clang and icc compile this fine):

namespace ns {
  class Base {
  public:
int i;
  };
  class Derived : public Base {
using Base::i;
  };
}
class DerivedDerived : public ns::Derived {
  using ns::Base::i;
};

we get

/tmp/ns.C:4:9: error: ‘int ns::Base::i’ is inaccessible
/tmp/ns.C:10:7: error: within this context

It is indeed rejects-valid but I cannot claim this is a regression as I can't
find the version that did that correctly.  It's 9 years of the original
bugreport, maybe rise a priority?..

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[sch...@linux-m68k.org]

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

--- Comment #11 from Andreas Schwab  ---
If a function is not allowed to change errno this must be explicitly
documented.

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Andreas Schwab from comment #11)
> If a function is not allowed to change errno this must be explicitly
> documented.

That means

Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c.orig   2014-02-06 15:43:42.138266256 +0100
+++ gcc/tree-ssa-alias.c2014-02-06 15:43:33.046266882 +0100
@@ -1847,7 +1847,9 @@ call_may_clobber_ref_p_1 (gimple call, a
ao_ref dref;
ao_ref_init_from_ptr_and_size (&dref, ptrptr,
   TYPE_SIZE_UNIT (ptr_type_node));
-   return refs_may_alias_p_1 (&dref, ref, false);
+   return (refs_may_alias_p_1 (&dref, ref, false)
+   || (flag_errno_math
+   && targetm.ref_may_alias_errno (ref)));
  }
/* Freeing memory kills the pointed-to memory.  More importantly
   the call has to serve as a barrier for moving loads and stores

is necessary.

[Bug c++/60096] c++11 lambda reference capture mistake

[feng.w...@uni-ulm.de]

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

--- Comment #2 from Feng Wang  ---
(In reply to Jonathan Wakely from comment #1)
> This looks invalid to me, you return a closure that holds a dangling
> reference to a function parameter that has gone out of scope.

Sorry, my fault. I should have been using a const reference

[]( int const& x )
{
  return [&x](int const& y)
  {
return x+y;
  };
}  
(2)(5);

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #12)
> (In reply to Andreas Schwab from comment #11)
> > If a function is not allowed to change errno this must be explicitly
> > documented.
> 
> That means
> 
> Index: gcc/tree-ssa-alias.c
> ===
> --- gcc/tree-ssa-alias.c.orig   2014-02-06 15:43:42.138266256 +0100
> +++ gcc/tree-ssa-alias.c2014-02-06 15:43:33.046266882 +0100
> @@ -1847,7 +1847,9 @@ call_may_clobber_ref_p_1 (gimple call, a
> ao_ref dref;
> ao_ref_init_from_ptr_and_size (&dref, ptrptr,
>TYPE_SIZE_UNIT (ptr_type_node));
> -   return refs_may_alias_p_1 (&dref, ref, false);
> +   return (refs_may_alias_p_1 (&dref, ref, false)
> +   || (flag_errno_math
> +   && targetm.ref_may_alias_errno (ref)));
>   }
> /* Freeing memory kills the pointed-to memory.  More importantly
>the call has to serve as a barrier for moving loads and stores
> 
> is necessary.

For posix_memalign?  I think errno can contain any value, except that library
is not allowed to clear errno.
So, IMHO *p = 1; posix_memalign (...); return *p; can be still optimized into
return 1;, because if p = &errno; then *p after the call has undefined value
(just known not to be zero).

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Thu, 6 Feb 2014, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
> 
> --- Comment #13 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #12)
> > (In reply to Andreas Schwab from comment #11)
> > > If a function is not allowed to change errno this must be explicitly
> > > documented.
> > 
> > That means
> > 
> > Index: gcc/tree-ssa-alias.c
> > ===
> > --- gcc/tree-ssa-alias.c.orig   2014-02-06 15:43:42.138266256 +0100
> > +++ gcc/tree-ssa-alias.c2014-02-06 15:43:33.046266882 +0100
> > @@ -1847,7 +1847,9 @@ call_may_clobber_ref_p_1 (gimple call, a
> > ao_ref dref;
> > ao_ref_init_from_ptr_and_size (&dref, ptrptr,
> >TYPE_SIZE_UNIT (ptr_type_node));
> > -   return refs_may_alias_p_1 (&dref, ref, false);
> > +   return (refs_may_alias_p_1 (&dref, ref, false)
> > +   || (flag_errno_math
> > +   && targetm.ref_may_alias_errno (ref)));
> >   }
> > /* Freeing memory kills the pointed-to memory.  More importantly
> >the call has to serve as a barrier for moving loads and stores
> > 
> > is necessary.
> 
> For posix_memalign?  I think errno can contain any value, except that library
> is not allowed to clear errno.
> So, IMHO *p = 1; posix_memalign (...); return *p; can be still optimized into
> return 1;, because if p = &errno; then *p after the call has undefined value
> (just known not to be zero).

But on allocation failure posix_memalign may set it to 2, no?  So
for

  errno = 0;
  posix_memalign ()
  errno = 0;
  ptr = malloc ();
  if (!ptr)
perror ();

we may not DSE the 2nd errno = 0 store.

Richard.

[Bug c++/60096] c++11 lambda reference capture mistake

[feng.w...@uni-ulm.de]

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

Feng Wang  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Feng Wang  ---
mark as invalid.

[Bug tree-optimization/60098] DSE fails to DSE errno settings

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-02-06
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I have a patch.

[Bug tree-optimization/60098] New: DSE fails to DSE errno settings

[rguenth at gcc dot gnu.org]

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

Bug ID: 60098
   Summary: DSE fails to DSE errno settings
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: rguenth at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org

void *foo (int *p)
{
  void *q;
  *p = 0;
  q = __builtin_malloc (4);
  *p = 0;
  return q;
}

the first *p = 0 store is dead.

[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  6 15:47:12 2014
New Revision: 207562

URL: http://gcc.gnu.org/viewcvs?rev=207562&root=gcc&view=rev
Log:
PR debug/59992
* var-tracking.c (adjust_mems): Before adding a SET
to amd->side_effects, adjust it's SET_SRC using
simplify_replace_fn_rtx.

* gcc.dg/pr59992.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr59992.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c

[Bug debug/59575] [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=59575

--- Comment #32 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  6 15:52:17 2014
New Revision: 207563

URL: http://gcc.gnu.org/viewcvs?rev=207563&root=gcc&view=rev
Log:
PR target/59575
* config/arm/arm.c (emit_multi_reg_push): Add dwarf_regs_mask argument,
don't record in REG_FRAME_RELATED_EXPR registers not set in that
bitmask.
(arm_expand_prologue): Adjust all callers.
(arm_unwind_emit_sequence): Allow saved, but not important for unwind
info, registers also at the lowest numbered registers side.  Use
gcc_assert instead of abort, and SET_SRC/SET_DEST macros instead of
XEXP.

* gcc.target/arm/pr59575.c: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/59575] [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=59575

--- Comment #33 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb  6 15:52:36 2014
New Revision: 207564

URL: http://gcc.gnu.org/viewcvs?rev=207564&root=gcc&view=rev
Log:
PR target/59575
* config/arm/arm.c (emit_multi_reg_push): Add dwarf_regs_mask argument,
don't record in REG_FRAME_RELATED_EXPR registers not set in that
bitmask.
(arm_expand_prologue): Adjust all callers.
(arm_unwind_emit_sequence): Allow saved, but not important for unwind
info, registers also at the lowest numbered registers side.  Use
gcc_assert instead of abort, and SET_SRC/SET_DEST macros instead of
XEXP.

* gcc.target/arm/pr59575.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr59575.c

[Bug debug/59575] [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=59575

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #34 from Jakub Jelinek  ---
Fixed.

[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The testcase has been fixed, but unfortunately --enable-checking=yes,rtl
insn-recog.c still takes about an hour to var-track.

[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So fixed?

[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||openmp
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug c++/19377] Using declaration in "private" part causes "protected" diagnostic

[fabien at gcc dot gnu.org]

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

--- Comment #10 from fabien at gcc dot gnu.org ---
(In reply to Andrey Belevantsev from comment #9)
> Another test case of the same issue (both clang and icc compile this fine):

It is not the same issue as the protected keyword is not involved. (And Clang
and ICC should be fixed instead, see below).

> 
> namespace ns {
>   class Base {
>   public:
> int i;
>   };
>   class Derived : public Base {
> using Base::i;
>   };
> }
> class DerivedDerived : public ns::Derived {
>   using ns::Base::i;
> };
> 
> we get
> 
> /tmp/ns.C:4:9: error: ‘int ns::Base::i’ is inaccessible
> /tmp/ns.C:10:7: error: within this context
> 
> It is indeed rejects-valid but I cannot claim this is a regression as I
> can't find the version that did that correctly.  

The testcase is not valid, as a using declaration shall refer to a direct base
class, which is not the case in 'using ns::Base::i' (the namespace ns does not
seem to be relevant here). It is invalid for a second reason, 'using Base::i'
is declared (implicitly) in a private section, so inaccessible in
DerivedDerived.

> It's 9 years of the
> original bugreport, maybe rise a priority?..

Raising the priority would not make me fix this bug more quickly. This bug is
not a regression, and not a high priority in my opinion. Thought, it is in my
TODO list. I gave it a try two years ago, and it was not obvious to fix. Feel
free to take over if you have more free time than I have.

[Bug sanitizer/59585] Tests failing due to trailing newline

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #3 from Ramana Radhakrishnan  ---
Presumably fixed ?

[Bug target/58784] [ARM] LRA legitimate address issue with misalign neon_store

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from Ramana Radhakrishnan  ---
This is now fixed.

[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Vladimir Makarov  ---
(In reply to Tejas Belagod from comment #1)
> Created attachment 32053 [details]
> Reduced test case for LRA ICE.

Sorry, I can not reproduce it on the today trunk (I tried -O[0-3] including
-O2).

[Bug target/58699] ARM: emit PLDW instruction for prefetch with write intent

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-06
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Ramana Radhakrishnan  ---
confirmed.

[Bug middle-end/60089] Complex arithmetic instructions

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Is the complex multiplication instruction C99 Annex G-conforming, or could 
it only be used for -fcx-limited-range?

[Bug sanitizer/59585] Tests failing due to trailing newline

[tetra2005 at gmail dot com]

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

--- Comment #4 from Yuri Gribov  ---
Yup, thanks.

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P2  |P1
Version|4.8.2   |4.9.0
   Target Milestone|4.8.4   |4.9.0

[Bug other/60099] New: internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

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

Bug ID: 60099
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheghathivhistha at gmail dot com

I can't build Seamonkey with rev.

x86_64-pc-linux-gnu-g++ -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API
-DIMPL_LIBXUL  -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -fPIC  
-DMOZILLA_CLIENT -ggdb -pipe -march=native -mtune=native -mno-avx
-fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno
-std=gnu++0x -pthread -DNDEBUG -DTRIMMED -Os -freorder-blocks 
-fomit-frame-pointer -c testcase.ii


C-reduced testcase:

typedef enum
{ }
nsresult;
struct nsID
{
};
typedef nsID nsCID;
typedef nsID nsIID;
class nsISupports
{
};
class nsCOMPtr_helper
{
public:
virtual nsresult operator () (const nsIID &, void **) const;
};
template < class T > class nsRefPtr
{
public:
T element_type;
nsRefPtr & operator= (const nsCOMPtr_helper & helper)
{
helper (T::template COMTypeInfo < int >::kIID, 0);
}
};

class nsIURI:nsISupports
{
public:
template < class > struct COMTypeInfo
{
static nsIID kIID;
};
};
extern "C"
{
#pragma GCC visibility push(default)
}
class nsCreateInstanceByCID:public nsCOMPtr_helper
{
public:
nsCreateInstanceByCID (nsCID & aCID, nsISupports *, nsresult *):mCID
(aCID),
mErrorPtr ()
{
} nsresult operator () (const nsIID &, void **) const;
nsCID & mCID;
nsresult *mErrorPtr;
};

nsCID kSimpleURICID;
inline nsCreateInstanceByCID
do_CreateInstance (nsCID & aCID, nsresult *)
{
return nsCreateInstanceByCID (aCID, 0, 0);
}

void
nsDataHandlerNewURI ()
{
nsRefPtr < nsIURI > uri;
uri = do_CreateInstance (kSimpleURICID, 0);
}

[Bug other/60099] internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

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

--- Comment #1 from David Kredba  ---
I am sorry, revision 207472.

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #46 from Jan Hubicka  ---
Created attachment 32067
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32067&action=edit
Path I am testing

Hi,
this is patch I am testing. It synchronizes the logic in lto-cgraph.c and
ipa-partition.c
It seems I also forgot to commit very old patch for setting
used_from_other_partition flag correctly, with current code we probably can
trigger undefined symbol with COMDAT and cross-partition devirtualization. I
will try to look into that next.

[Bug other/60099] internal compiler error: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Weird, I can't reproduce it neither with r207472, nor with revision around
that.

[Bug target/58785] [ARM] LRA issue in Thumb mode with movhi

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-02-06
 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Looks to me like this is fixed. Trying for a variety of cores for Thumb-2 shows
no ICE.

Yvan ? 

Ramana

[Bug target/58847] ARM: emit NEON alignment hints for 32/16-bit accesses

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-06
 Ever confirmed|0   |1

[Bug other/60099] internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

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

--- Comment #3 from David Kredba  ---
Here it shows line number too.
./testcase.i:62:1: internal compiler error

Going to attach original ii file.

In check.sh I used in addition -I and -include that I deleted from the command
before sending here, can it be that?

x86_64-pc-linux-gnu-g++ -o nsDataHandler.o -c -I../../../dist/stl_wrappers
-I../../../dist/system_wrappers -include
/var/tmp/portage/www-client/seamonkey-2.24/work/comm-release/mozilla/config/gcc_hidden.h
-DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL 
-DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT
-I/var/tmp/portage/www-client/seamonkey-2.24/work/comm-release/mozilla/netwerk/protocol/data/../../base/src

-I/var/tmp/portage/www-client/seamonkey-2.24/work/comm-release/mozilla/netwerk/protocol/data
-I. -I../../../dist/include  -I/usr/include/nspr -I/usr/include/nss  -fPIC 
 -DMOZILLA_CLIENT -ggdb -pipe -march=native -mtune=native -mno-avx
-fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno
-std=gnu++0x -pthread -DNDEBUG -DTRIMMED -Os -freorder-blocks 
-fomit-frame-pointer -c ./testcase.i