[Bug fortran/51788] Unstable gfc_verify_binding_labels check for a binding label which collides with a global entity

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
I confirm that if the lines

  use binding_label_tests_10 ! { dg-error "Variable one ..." }
  use binding_label_tests_10_main

are swapped, the code is compiled without error at r206072.

I am not sure to understand the remaining of this PR.

[Bug fortran/59024] ICE: after printing certain error messages, the compiler seg faults.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 4.8.2 and a clean 4.9.0, r206033. However the compilation exits
without ICE on my patched tree (r206072) but with the additional error

pr59024.f90:17.14:

END MODULE mtc
  1
Error: Procedure 'C_PTR_1' in generic interface 'tc' at (1) is neither function
nor subroutine

So this PR is likely a duplicate with a known fix. I'll try to figure out the
link.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-12-18
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

This has been improved already for the compiler generated misaligned loads in
r204219 aka PR47754, but when you explicitly use intrinsics we don't go through
the movmisalign path (and, I think we shouldn't, at least I doubt when you say
use _mm256_loadu_si256 you'd be expecting to use depending on tuning say two
misaligned 128-bit loads instead), it still forces the generation of UNSPECs.

This patch will if the compiler will emit a vmovdqu (or vmovup{s,d}) for normal
*mov_internal pattern emit that instead of the UNSPECs and allow
combining it into insns, while if you use the unaligned loads on something
known to be unaligned, it will still not combine it (it will honor the
unaligned load then, because you've requested it specially).

[Bug libstdc++/59530] Incorrect check on string_view operator[]

[3dw4rd at verizon dot net]

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

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
I mistakenly took cases for string which must be null terminated.
I think we'll just remove those lines from the testcases.

[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577

[mikpelinux at gmail dot com]

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

--- Comment #9 from Mikael Pettersson  ---
(In reply to fdarkangel from comment #8)
> Persists in gcc 4.8.2.

Try Bernd's patch, see link in comment #7.

[Bug gcov-profile/59527] [4.9 Regression] ICE: in fixup_reorder_chain, at cfgrtl.c:3739 during PGO Firefox build

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to Teresa Johnson from comment #8)
> I can't reproduce this one using your source/profles and command line
> (using a trunk updated to head last night plus my fix for the assert).
> I verified that splitting is kicking in, but no error occurs. Do you
> want to generate and tar up the dumps, and I can try to figure out
> what might be going on from that?

Sorry for not checking earlier, but this issue only happens with 
the gold linker. So please add -fuse-ld=gold to the command line.

Anyway lets close this bug. I'll open a new one for the 
"verify_flow_info failed" ICE.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[thiago at kde dot org]

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

--- Comment #2 from Thiago Macieira  ---
I have to use _mm_loadu_si128 because non-VEX SSE requires explicit unaligned
loads.

Here's more food for thought:

__m128i result = _mm_cmpeq_epi16((__m128i*)p1, (__m128i*)p2);

For non-VEX code, so far the compiler emitted one MOVDQA and one PCMPEQW if it
could, enforcing that both sources needed to be aligned. With VEX, VPCMPEQW can
do unaligned, so should the other load also be changed to VPMOVDQU instead of
VPMOVDQA?

Similarly, if I use _mm_load_si128 (not loadu), can the compiler combine one
load into the next instruction? Performance-wise, the execution will be the
same, with one fewer instruction to be retired (so, better); but it will not
cause an unaligned fault if the pointer isn't aligned.

[Bug gcov-profile/59542] New: [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[trippels at gcc dot gnu.org]

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

Bug ID: 59542
   Summary: [4.9 Regression] ICE: verify_flow_info failed during
Firefox build with 'gold'
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

Firefox LTO/PGO build fails when using the gold linker.

The testcase is too big to attach.

 % wget trippelsdorf.de/testcase.tar.bz2
 % tar xvjf testcase.tar.bz2
 % g++ -fuse-ld=gold -w -nostdlib -r -flto=4 -fprofile-use -fprofile-correction
-march=amdfam10 -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pipe
-O3 Unified_cpp_7.ii Unified_cpp_8.ii

/var/tmp/mozilla-central/js/src/vm/Interpreter.cpp: In function ‘Interpret’:
/var/tmp/mozilla-central/js/src/vm/Interpreter.cpp:3469:1: error: non-cold
basic block 39 dominated by a block in the cold partition (2517)
 }
 ^
/var/tmp/mozilla-central/js/src/vm/Interpreter.cpp:3469:1: internal compiler
error: verify_flow_info failed
0x5a1ecd verify_flow_info()
../../gcc/gcc/cfghooks.c:260
0x5b4ee2 cfg_layout_finalize()
../../gcc/gcc/cfgrtl.c:4286
0xd44662 duplicate_computed_gotos
../../gcc/gcc/bb-reorder.c:2492
0xd44662 execute
../../gcc/gcc/bb-reorder.c:2524
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/tmp/ccvLwfUA.ltrans0.ltrans.o] Error 1

With -fuse-ld=bfd everything works just fine.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[amker.cheng at gmail dot com]

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

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #17 from bin.cheng  ---
Hi Richard,
I am having difficulty in understanding cases if this PR.
For the reported case with two loops:

  for( y=0; y<4; y++, pDst += dstStep ) {
for( x=y+1; x<4; x++ ) {
s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
pDst[x] = (unsigned char)s;
}

pDst[y] = p3;
  }

The dump for statement 'pDst[y] = p3;' before IVOPT is like:

:
Invalid sum of incoming frequencies 1667, should be 278
  y.2_64 = (sizetype) y_89;
  D.6421_65 = pDst_88 + y.2_64;
  *D.6421_65 = p3_37;
  pDst_69 = pDst_88 + pretmp.21_118;
  ivtmp.35_116 = ivtmp.35_87 - 1;
  if (ivtmp.35_116 != 0)
goto ;
  else
goto ;


IVOPT chooses candidate 15:
candidate 15
  depends on 3
  var_before ivtmp.154
  var_after ivtmp.154
  incremented before exit test
  type unsigned int
  base (unsigned int) pDst_39(D) - (unsigned int) &p1
  step (unsigned int) (pretmp.21_118 + 1)
for use 1:
use 1
  address
  in statement *D.6421_65 = p3_37;

  at position *D.6421_65
  type unsigned char *
  base pDst_39(D)
  step pretmp.21_118 + 1
  base object (void *) pDst_39(D)
  related candidates 

After rewriting, the dump is like:

:
Invalid sum of incoming frequencies 1667, should be 278
  MEM[symbol: p1, index: ivtmp.154_200, offset: 0B] = p3_37;
  pDst_69 = pDst_88 + pretmp.21_118;
  ivtmp.149_218 = ivtmp.149_249 - 1;
  ivtmp.154_190 = ivtmp.154_200 + D.6617_250;
  if (x_40 != 4)
goto ;
  else
goto ;

Eventually, the storing to TMR[p1,ivtmp,0] is considered local and deleted.

BUT, for your reduced case:

  p3 = (unsigned char)(((signed int)p1[1] + (signed int)p2[1]
+ (signed int)p1[0] +(signed int)p1[0] + 2 ) >> 2 );

  for( x=y+1; x<4; x++ ) {
  s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
  pDst[x] = (unsigned char)s;
  }

  pDst[y] = p3;

It is about the the TMR in below dump (before IVOPT):

:
  # vect_pp1.30_166 = PHI 
  # vect_pp1.37_176 = PHI 
  # vect_pp1.46_194 = PHI 
  # vect_p.60_223 = PHI 
  # ivtmp.64_225 = PHI 
  ...
  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
  vect_pp1.30_167 = vect_pp1.30_166 + 8;
  vect_pp1.37_177 = vect_pp1.37_176 + 8;
  vect_pp1.46_195 = vect_pp1.46_194 + 8;
  vect_p.60_224 = vect_p.60_223 + 8;
  ivtmp.64_226 = ivtmp.64_225 + 1;
  if (ivtmp.64_226 < bnd.27_128)
goto ;
  else
goto ;

Your patch prevents IVOPT from choosing cand 4:
candidate 4 (important)
  var_before ivtmp.110
  var_after ivtmp.110
  incremented before exit test
  type unsigned int
  base (unsigned int) (&p1 + 8)
  step 8
  base object (void *) &p1
for use 3:
use 3
  generic
  in statement vect_p.60_223 = PHI 

  at position 
  type vector(8) unsigned char *
  base batmp.61_221 + 1
  step 8
  base object (void *) batmp.61_221
  is a biv
  related candidates 

To prevent IVOPT from rewriting into:

:
  # ivtmp.107_150 = PHI 
  # ivtmp.110_241 = PHI 
  D.6585_133 = (unsigned int) batmp.61_221;
  p1.131_277 = (unsigned int) &p1;
  D.6587_278 = D.6585_133 - p1.131_277;
  D.6588_279 = D.6587_278 + ivtmp.110_241;
  D.6589_280 = D.6588_279 + 4294967289;
  D.6590_281 = (vector(8) unsigned char *) D.6589_280;
  vect_p.60_223 = D.6590_281;
  ...
  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
  ivtmp.107_256 = ivtmp.107_150 + 1;
  ivtmp.110_146 = ivtmp.110_241 + 8;
  if (ivtmp.107_256 < bnd.27_128)
goto ;
  else
goto ;

Thus prevents IVOPT from generating candidate 15 in outer loop.  (Expressing
use 3 by cand 4 itself is good, right?)


---
But,
It seems because the check:

  if (address_p)
{
  /* Do not try to express address of an object with computation based
 on address of a different object.  This may cause problems in rtl
 level alias analysis (that does not expect this to be happening,
 as this is illegal in C), and would be unlikely to be useful
 anyway.  */
  if (use->iv->base_object
  && cand->iv->base_object
  && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
return infinite_cost;

failed because cand(15)->iv->base_object == NULL.  For the reported case, it's
not about an iv use appearing in memory reference while not marked as
address_p, and can be fixed by revise the existing check condition, is it true?

PS, sorry for replying to a fixed PR, I found it's kind of impossible to fix
PR52272 without fully understanding this one.

[Bug lto/59543] New: [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range

[trippels at gcc dot gnu.org]

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

Bug ID: 59543
   Summary: [4.9 Regression] lto1: fatal error: Cgraph edge
statement index out of range
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

During Firefox build I get:

markus@x4 shell % /var/tmp/gcc_test/usr/local/bin/g++ -flto=4 -o foofo -O2
Unified_cpp_shell0.o ../libjs_static.a
In member function ‘init’:
lto1: fatal error: Cgraph edge statement index out of range 9 < 10
compilation terminated.
make: *** [/tmp/cczchbUW.ltrans21.ltrans.o] Error 1
make: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

markus@x4 shell % /var/tmp/gcc_test/usr/local/bin/g++ -flto=4 -O2
Unified_cpp_shell0.o ../libjs_static.a -rdynamic
In member function ‘extractBetween’:
lto1: fatal error: Cgraph edge statement index out of range 25 < 50
compilation terminated.
make: *** [/tmp/cchXDtH7.ltrans22.ltrans.o] Error 1

Here's a testcase:

 tmp % wget trippelsdorf.de/cceI2Nud.ltrans22.o.bz2
 tmp % bzip2 -d cceI2Nud.ltrans22.o.bz2
 tmp % g++ -xlto -fltrans cceI2Nud.ltrans22.o
In member function ‘extractBetween’:
lto1: fatal error: Cgraph edge statement index out of range
compilation terminated.

[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006

[trippels at gcc dot gnu.org]

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

--- Comment #24 from Markus Trippelsdorf  ---
I've opened pr59543 for the cgraph edge statement index issue.

[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Comparing the test suite results between r206040 and r206072+my_fix, the test
gcc.dg/tree-prof/pr52027.c (see pr52794) passes now, but the tests

g++.dg/tree-prof/partition1.C
gcc.dg/tree-prof/20041218-1.c
gcc.dg/tree-prof/crossmodule-indircall-1.c
gcc.dg/tree-prof/pr49299-1.c
gcc.dg/tree-prof/pr49299-2.c

fails with -m64.

The typical failure is

spawn /opt/gcc/build_w/gcc/testsuite/g++/../../xg++
-B/opt/gcc/build_w/gcc/testsuite/g++/../../
/opt/gcc/work/gcc/testsuite/g++.dg/tree-prof/pr57451.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/opt/gcc/build_w/x86_64-apple-darwin13.0.0/libstdc++-v3/include/x86_64-apple-darwin13.0.0
-I/opt/gcc/build_w/x86_64-apple-darwin13.0.0/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++
-I/opt/gcc/work/libstdc++-v3/include/backward
-I/opt/gcc/work/libstdc++-v3/testsuite/util -fmessage-length=0 -O2
-freorder-blocks-and-partition -g -fprofile-use
-L/opt/gcc/build_w/x86_64-apple-darwin13.0.0/./libstdc++-v3/src/.libs
-B/opt/gcc/build_w/x86_64-apple-darwin13.0.0/./libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin13.0.0/./libstdc++-v3/src/.libs
-multiply_defined suppress -lm -m64 -o
/opt/gcc/build_w/gcc/testsuite/g++/pr57451.x02^M
/pr57451.C  
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function
parse, file
/SourceCache/ld64/ld64-224.1/src/ld/parsers/macho_relocatable_file.cpp, line
1639.^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
0  0x10f507724  __assert_rtn + 144^M
1  0x10f52a55c 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 1476^M
2  0x10f5113b6  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 328^M
3  0x10f50d776  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions
const&) + 310^M
4  0x10f54dd83  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 571^M
5  0x10f54fa33  ld::tool::InputFiles::parseWorkerThread() + 285^M
6  0x7fff8d911899  _pthread_body + 138^M
7  0x7fff8d91172a  _pthread_struct_init + 0^M
A linker snapshot was created at:^M
/tmp/pr57451.x02-2013-11-18-085025.ld-snapshot^M
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function
parse, file
/SourceCache/ld64/ld64-224.1/src/ld/parsers/macho_relocatable_file.cpp, line
1639.^M
collect2: error: ld returned 1 exit status^M

FAIL: g++.dg/tree-prof/pr57451.C compilation,  -fprofile-use
UNRESOLVED: g++.dg/tree-prof/pr57451.C execution,-fprofile-use

At this point I cannot say if these new failures are due to may fix or to some
recent commit.

[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661

[trippels at gcc dot gnu.org]

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

--- Comment #14 from Markus Trippelsdorf  ---
(In reply to David Kredba from comment #13)
> Qtwebkit-4.8.5 still ICEs after that patch applied:
> lto1: internal compiler error: in record_target_from_binfo, at
> ipa-devirt.c:673

Can you attach a testcase, please?

[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA

[yvan.roux at linaro dot org]

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

--- Comment #8 from Yvan Roux  ---
Forget my previous comment, I can reproduce it after a rebase.

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
https://sourceware.org/bugzilla/show_bug.cgi?id=12322
is still open.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 31463 [details]
> gcc49-pr59539.patch

>From a quick look at the patch, the proposed patch doesn't support masked
insns. 

I think it is better to introduce corresponding sse.md expanders for
UNSPEC_STOREU and UNSPEC_LOADU insns. These expanders will either generate
UNSPEC_* pattern or "normal" (masked) move in case of TARGET_AVX.

[Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> I think the problem is that ifcvt relies on consistent counting of insns,
> but the various functions count different things.

What kind of insns is responsible for the discrepancy that leads to the ICE?

> I guess best would be to count/skip/etc. the same things consistently, the
> problem is that some of the functions have other uses etc.

In any case, this would be a sensible approach.

> 1) let count_bb_insns not count insns with USE or CLOBBER PATTERNs

Agreed.

> 2) perhaps not count any JUMP_INSNs in flow_find_cross_jump if dir_p == NULL
> (i.e.
> when called from ifcvt)?
> 3) perhaps not count USE/CLOBBER insns in flow_find_head_matching_sequence if
> stop_after is non-zero?

I'd first make the functions behave the same wrt USE and CLOBBER insns.

> 4) perhaps add also skip_use argument to first_active_insn and if TRUE,
> ignore USE insns and for both {first,last}_active_insn if skip_use is TRUE,
> also ignore CLOBBER insns
>
> 5) in find_active_insn_{before,after} ignore USE/CLOBBER insns
> and document this properly?

I'm less sure about these ones: does their behavior need to be in keeping with
the insns counting?

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
"amker.cheng at gmail dot com"  wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
>
>bin.cheng  changed:
>
>   What|Removed |Added
>
>   CC||amker.cheng at gmail dot com
>
>--- Comment #17 from bin.cheng  ---
>Hi Richard,
>I am having difficulty in understanding cases if this PR.
>For the reported case with two loops:
>
>  for( y=0; y<4; y++, pDst += dstStep ) {
>for( x=y+1; x<4; x++ ) {
>s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
>pDst[x] = (unsigned char)s;
>}
>
>pDst[y] = p3;
>  }
>
>The dump for statement 'pDst[y] = p3;' before IVOPT is like:
>
>:
>Invalid sum of incoming frequencies 1667, should be 278
>  y.2_64 = (sizetype) y_89;
>  D.6421_65 = pDst_88 + y.2_64;
>  *D.6421_65 = p3_37;
>  pDst_69 = pDst_88 + pretmp.21_118;
>  ivtmp.35_116 = ivtmp.35_87 - 1;
>  if (ivtmp.35_116 != 0)
>goto ;
>  else
>goto ;
>
>
>IVOPT chooses candidate 15:
>candidate 15
>  depends on 3
>  var_before ivtmp.154
>  var_after ivtmp.154
>  incremented before exit test
>  type unsigned int
>  base (unsigned int) pDst_39(D) - (unsigned int) &p1
>  step (unsigned int) (pretmp.21_118 + 1)
>for use 1:
>use 1
>  address
>  in statement *D.6421_65 = p3_37;
>
>  at position *D.6421_65
>  type unsigned char *
>  base pDst_39(D)
>  step pretmp.21_118 + 1
>  base object (void *) pDst_39(D)
>  related candidates 
>
>After rewriting, the dump is like:
>
>:
>Invalid sum of incoming frequencies 1667, should be 278
>  MEM[symbol: p1, index: ivtmp.154_200, offset: 0B] = p3_37;
>  pDst_69 = pDst_88 + pretmp.21_118;
>  ivtmp.149_218 = ivtmp.149_249 - 1;
>  ivtmp.154_190 = ivtmp.154_200 + D.6617_250;
>  if (x_40 != 4)
>goto ;
>  else
>goto ;
>
>Eventually, the storing to TMR[p1,ivtmp,0] is considered local and
>deleted.
>
>BUT, for your reduced case:
>
>  p3 = (unsigned char)(((signed int)p1[1] + (signed int)p2[1]
>   + (signed int)p1[0] +(signed int)p1[0] + 2 ) >> 2 );
>
>  for( x=y+1; x<4; x++ ) {
>  s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
>  pDst[x] = (unsigned char)s;
>  }
>
>  pDst[y] = p3;
>
>It is about the the TMR in below dump (before IVOPT):
>
>:
>  # vect_pp1.30_166 = PHI 
>  # vect_pp1.37_176 = PHI 
>  # vect_pp1.46_194 = PHI 
>  # vect_p.60_223 = PHI 
>  # ivtmp.64_225 = PHI 
>  ...
>  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
>  vect_pp1.30_167 = vect_pp1.30_166 + 8;
>  vect_pp1.37_177 = vect_pp1.37_176 + 8;
>  vect_pp1.46_195 = vect_pp1.46_194 + 8;
>  vect_p.60_224 = vect_p.60_223 + 8;
>  ivtmp.64_226 = ivtmp.64_225 + 1;
>  if (ivtmp.64_226 < bnd.27_128)
>goto ;
>  else
>goto ;
>
>Your patch prevents IVOPT from choosing cand 4:
>candidate 4 (important)
>  var_before ivtmp.110
>  var_after ivtmp.110
>  incremented before exit test
>  type unsigned int
>  base (unsigned int) (&p1 + 8)
>  step 8
>  base object (void *) &p1
>for use 3:
>use 3
>  generic
> in statement vect_p.60_223 = PHI 
>
>  at position 
>  type vector(8) unsigned char *
>  base batmp.61_221 + 1
>  step 8
>  base object (void *) batmp.61_221
>  is a biv
>  related candidates 
>
>To prevent IVOPT from rewriting into:
>
>:
>  # ivtmp.107_150 = PHI 
>  # ivtmp.110_241 = PHI 
>  D.6585_133 = (unsigned int) batmp.61_221;
>  p1.131_277 = (unsigned int) &p1;
>  D.6587_278 = D.6585_133 - p1.131_277;
>  D.6588_279 = D.6587_278 + ivtmp.110_241;
>  D.6589_280 = D.6588_279 + 4294967289;
>  D.6590_281 = (vector(8) unsigned char *) D.6589_280;
>  vect_p.60_223 = D.6590_281;
>  ...
>  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
>  ivtmp.107_256 = ivtmp.107_150 + 1;
>  ivtmp.110_146 = ivtmp.110_241 + 8;
>  if (ivtmp.107_256 < bnd.27_128)
>goto ;
>  else
>goto ;
>
>Thus prevents IVOPT from generating candidate 15 in outer loop. 
>(Expressing
>use 3 by cand 4 itself is good, right?)
>
>
>---
>But,
>It seems because the check:
>
>  if (address_p)
>{
>   /* Do not try to express address of an object with computation based
>  on address of a different object.  This may cause problems in rtl
>   level alias analysis (that does not expect this to be happening,
> as this is illegal in C), and would be unlikely to be useful
> anyway.  */
>  if (use->iv->base_object
>  && cand->iv->base_object
>  && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
>return infinite_cost;
>
>failed because cand(15)->iv->base_object == NULL.  For the reported
>case, it's
>not about an iv use appearing in memory reference while not marked as
>address_p, and can be fixed by revise the existing check condition, is
>it true?

No, even expressing an address this way is broken as for example dependence
analysis vi

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Jakub Jelinek from comment #1)
> > Created attachment 31463 [details]
> > gcc49-pr59539.patch
> 
> From a quick look at the patch, the proposed patch doesn't support masked
> insns. 
> 
> I think it is better to introduce corresponding sse.md expanders for
> UNSPEC_STOREU and UNSPEC_LOADU insns. These expanders will either generate
> UNSPEC_* pattern or "normal" (masked) move in case of TARGET_AVX.

I can surely add the expanders, but don't understand the comment about masked
moves.  *maskload* is already a specialized UNSPEC, and can't really be merged
with arithmetic patterns (ok, perhaps with -mavx512f?) and handles both aligned
and unaligned operands the same.

[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka  ---
Thank you,
can you, please, check that the problem appears still after 
2013-12-17  Jan Hubicka  

* ipa-utils.h (possible_polymorphic_call_targets): Determine context of
the call.
* gimple-fold.c (gimple_fold_call): Use ipa-devirt to devirtualize.

this patch makes early passes to use same analysis for devirtualization as IPA
passes and thus it should prevent from devirtualization to be discovered just
after early passes but before IPA analysis.  I suspect those can bring LTO
streaming out of sync. If this is the case, we need to chase away the
unreachable code removal that should not be placed in between renumbering stmts
and streaming.

Honza

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #4)
> > From a quick look at the patch, the proposed patch doesn't support masked
> > insns. 
> > 
> > I think it is better to introduce corresponding sse.md expanders for
> > UNSPEC_STOREU and UNSPEC_LOADU insns. These expanders will either generate
> > UNSPEC_* pattern or "normal" (masked) move in case of TARGET_AVX.
> 
> I can surely add the expanders, but don't understand the comment about
> masked moves.  *maskload* is already a specialized UNSPEC, and can't really
> be merged with arithmetic patterns (ok, perhaps with -mavx512f?) and handles
> both aligned and unaligned operands the same.

Ah, sorry for being terse, I was looking at avx512f_storeu_..._mask. I assume
that this pattern can be combined as a memory operand into other SSE
instructions, in the same way as non-masked UNSPEC_* patterns. Admittedly, we
are in the middle of avx512f merge, so this assumption may be wrong.

[Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Eric Botcazou from comment #6)
> > I think the problem is that ifcvt relies on consistent counting of insns,
> > but the various functions count different things.
> 
> What kind of insns is responsible for the discrepancy that leads to the ICE?

On the given testcase the JUMP_INSN at the end of bb is returnjump_p (without
additional side effects), so it isn't counted and thus that problem isn't
present.  But the problem on the testcase is insn with USE pattern right before
the jump, count_bb_insns counts it as active insn, flow_find_cross_jump
doesn't, and we subtract from the former the latter to see how many insns we
should allow at most for flow_find_head_matching_sequence, and because of the
discrepancy it is one bigger than it should and we end up with
then_last_head being after then_end, which violates the assumptions the code
makes.

> > 3) perhaps not count USE/CLOBBER insns in flow_find_head_matching_sequence 
> > if
> > stop_after is non-zero?
> 
> I'd first make the functions behave the same wrt USE and CLOBBER insns.

Perhaps we can ignore those always in flow_find_head_matching_sequence?

> > 4) perhaps add also skip_use argument to first_active_insn and if TRUE,
> > ignore USE insns and for both {first,last}_active_insn if skip_use is TRUE,
> > also ignore CLOBBER insns
> >
> > 5) in find_active_insn_{before,after} ignore USE/CLOBBER insns
> > and document this properly?
> 
> I'm less sure about these ones: does their behavior need to be in keeping
> with the insns counting?

Perhaps, though I'd say it might be a ticking bomb.

[Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Perhaps we can ignore those always in flow_find_head_matching_sequence?

Yes, that seems to be the most sensible thing to do, so that count_bb_insns,
flow_find_cross_jump and flow_find_head_matching_sequence agree about them.

> Perhaps, though I'd say it might be a ticking bomb.

If the bomb would be an ICE, that's good enough for now in my opinion.

[Bug lto/59543] [4.9 Regression] lto1: fatal error: Cgraph edge statement index out of range

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #1)
> Thank you,
> can you, please, check that the problem appears still after 
> 2013-12-17  Jan Hubicka  
> 
> * ipa-utils.h (possible_polymorphic_call_targets): Determine context
> of
> the call.
> * gimple-fold.c (gimple_fold_call): Use ipa-devirt to devirtualize.
> 
> this patch makes early passes to use same analysis for devirtualization as
> IPA passes and thus it should prevent from devirtualization to be discovered
> just after early passes but before IPA analysis.  I suspect those can bring
> LTO streaming out of sync. If this is the case, we need to chase away the
> unreachable code removal that should not be placed in between renumbering
> stmts and streaming.

Yes, it still happens after r206042.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[jakub at gcc dot gnu.org]

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

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

So like this instead?  The half-merged AVX512f support makes any changes hard,
it isn't clear if the masked variant will be needed or not, but it can't be
handled that easily, so I've kept it in the expander name for now, just don't
optimize it.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[amker.cheng at gmail dot com]

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

--- Comment #19 from bin.cheng  ---
> 
> >not about an iv use appearing in memory reference while not marked as
> >address_p, and can be fixed by revise the existing check condition, is
> >it true?
> 
> No, even expressing an address this way is broken as for example dependence 
> analysis via scev can get confused about the actual base object.
Agree, only I think it's not scev's responsibility since scev only cares base
value initialized for the analyzing loop, rather than the BASE object.

> 
> IIRC previously we already avoided the mem-use case and I had to generalize 
> it 
> to also avoid addresses.
Not all.
For the reported case, use and cand like:
use 3
  generic
  in statement vect_p.70_247 = PHI 

  at position 
  type vector(8) unsigned char *
  base batmp.71_245 + 1
  step 8
  base object (void *) batmp.71_245
  is a biv
  related candidates 

candidate 15
  depends on 3
  var_before ivtmp.154
  var_after ivtmp.154
  incremented before exit test
  type unsigned int
  base (unsigned int) pDst_39(D) - (unsigned int) &p1
  step (unsigned int) (pretmp.21_118 + 1)

The check:

  if (address_p
  || (use->iv->base_object
  && cand->iv->base_object
  && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object))
  && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object
{
  /* Do not try to express address of an object with computation based
 on address of a different object.  This may cause problems in rtl
 level alias analysis (that does not expect this to be happening,
 as this is illegal in C), and would be unlikely to be useful
 anyway.  */
  if (use->iv->base_object
  && cand->iv->base_object
  && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
return infinite_cost;
}

still evaluates to false because:
   use->iv->base_object != NULL  &&  cand->iv->base_object == NULL
>

[Bug c++/35535] stl_vector.h Compilation error

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus  ---
(In reply to Jan Hubicka from comment #5)
>   PR middle-end/35535

For completeness: Those commits are for PR 35545

[Bug middle-end/35545] virtual call specialization not happening with FDO

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #11 from Tobias Burnus  ---
Author: hubicka
Date: Tue Dec 17 23:41:41 2013
New Revision: 206073

URL: http://gcc.gnu.org/viewcvs?rev=206073&root=gcc&view=rev
Log:
PR middle-end/35545
* tree-vrp.c (extract_range_from_unary_expr_1): Handle OBJ_TYPE_REF.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c



Author: hubicka
Date: Tue Dec 17 23:43:22 2013
New Revision: 206074

URL: http://gcc.gnu.org/viewcvs?rev=206074&root=gcc&view=rev
Log:
PR middle-end/35545
* gimple-fold.c (fold_gimple_assign): Attempt to devirtualize
OBJ_TYPE_REF.
(gimple_fold_stmt_to_constant_1): Bypass OBJ_TYPE_REF wrappers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

[Bug debug/59418] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2221

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Dec 18 10:34:00 2013
New Revision: 206084

URL: http://gcc.gnu.org/viewcvs?rev=206084&root=gcc&view=rev
Log:
PR debug/59418
* dwarf2cfi.c (dwarf2out_frame_debug_cfa_offset): Fix comment and tidy.
(dwarf2out_frame_debug_cfa_restore): Handle TARGET_DWARF_REGISTER_SPAN.
(dwarf2out_frame_debug_expr): Tidy.

Added:
trunk/gcc/testsuite/gcc.dg/pr59418.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2cfi.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/22007] Stack overflow in g++.dg/eh/cleanup1.C

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Kai Tietz  ---
> Issue seems to be solved for 32-bit and 64-bit windows on cygwin-host.  I 
> can't
> reproduce issue there anymore for 4.9 and 4.8.
>
> Is issue still an issue for 4.7, 4.8, 4.9 for you?

Not on the 4.7 branch, as I mentioned before.  The Tru64 UNIX port has
been removed in 4.8.

Rainer

[Bug debug/59418] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2221

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks for reporting the problem and distilling the testcase.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 31464 [details]
> gcc49-pr59539.patch
> 
> So like this instead?  The half-merged AVX512f support makes any changes
> hard, it isn't clear if the masked variant will be needed or not, but it
> can't be handled that easily, so I've kept it in the expander name for now,
> just don't optimize it.

Yes, but why you use misaligned_operand check? This check is used in move
patterns to generate movu insn *instead of* mova. I guess that we can skip this
check entirely.

[Bug rtl-optimization/57422] [4.9 Regression] ICE: SIGSEGV in dominated_by_p with custom flags

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #3 from Andrey Belevantsev  ---
Created attachment 31465
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31465&action=edit
proposed patch

This is an issue with somewhat surprising reason.  The problem in itself is
that when we're scheduling the fence insn (actually next insn), it gets
register renamed and so its previous form stored as the fence insn no longer
corresponds to the new form.  We do not expect it so there is no code to update
the fence insn in this case.

Starting to add this code that easily fixed the issue, I stopped and wondered
why this situation arises at all -- the fence insn should always be able to be
scheduled as is.  In this case, first, the target availability bit correctly
set to true on this insn is reset because this insn form was already scheduled
on this fence and the bit might be incorrect (see
vec_target_unavailable_vinsns).  Thus we resort to the full recomputation of
the possible registers for the insn, which suddenly do not include its target
register (ax).

Now this happens because ax is incorrectly marked as unavailable due to target
reasons.  And this in turn happens because of the typo in the patch of rev.
172231:

-#if !HARD_FRAME_POINTER_IS_FRAME_POINTER
-  for (i = hard_regno_nregs[HARD_FRAME_POINTER_REGNUM][Pmode]; i--;)
-   SET_HARD_REG_BIT (reg_rename_p->unavailable_hard_regs,
-  HARD_FRAME_POINTER_REGNUM + i);
-#endif
+  if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
+add_to_hard_reg_set (®_rename_p->unavailable_hard_regs,
+Pmode, HARD_FRAME_POINTER_IS_FRAME_POINTER);

Instead of HARD_FRAME_POINTER_REGNUM, the parameter passed to
add_to_hard_reg_set is HARD_FRAME_POINTER_IS_FRAME_POINTER, which is zero and
equals to ax number :-)  Thus we always mark ax as unavailable in this piece of
code, which was noticed just because for this particular insn this leads to its
renaming and for this insn it should never happen.

The obvious patch restoring HARD_FRAME_POINTER_REGNUM is attached and fixes the
testcase (for the reported revision; the trunk no longer fails).  I will also
add an assert to check that the fence insn never gets renamed.

[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to jos...@codesourcery.com from comment #1)
> The main concerns for diagnostics in such cases are (a) that they are 
> meaningful and (b) that invalid code gets at least one error with 
> -pedantic-errors, and at least one warning or error with -pedantic.  
> There may be less consistency in what's a warning / error if -pedantic 
> rather than -pedantic-errors is used.

So merely using -pedantic may produce errors that do not appear without
-pedantic? Is that really a desired behavior?

Also,

$ cc1 -std=c99 -pedantic test.c
test.c:1:5: warning: ISO C forbids zero-size array ‘a’ [-Wpedantic]
 int a[0] = {};
 ^
test.c:1:12: warning: ISO C forbids empty initializer braces [-Wpedantic]
 int a[0] = {};
^
test.c:2:11: warning: ISO C forbids empty initializer braces [-Wpedantic]
 int b[] = {};
   ^
test.c:2:5: error: zero or negative size array ‘b’
 int b[] = {};
 ^
test.c:3:5: warning: array ‘c’ assumed to have one element [enabled by default]
 int c[];
 ^

Note that a[0] = {} gives a warning but "b[] = {}" gives a hard error.

Clang seems much more consistent here:

test.c:1:7: warning: zero size arrays are an extension [-Wzero-length-array]
int a[0] = {};
  ^
test.c:1:12: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int a[0] = {};
   ^
test.c:2:11: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int b[] = {};
  ^
test.c:2:11: warning: zero size arrays are an extension [-Wzero-length-array]
test.c:3:5: warning: tentative array definition assumed to have one element
int c[];
^

Note that clang gives exactly the same warning for "a[0] = {}" and "b[] = {}".

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Because otherwise it can generate an aligned load, and I thought when user
explicitly writes he wants an unaligned load we should honor it, perhaps for
some reason the alignment info can't be trusted etc.
ix86_expand_vector_move_misalign also checks misaligned_operand and only emits
the non-UNSPEC insn for TARGET_AVX if it will result in misaligned load.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #8)
> Because otherwise it can generate an aligned load, and I thought when user
> explicitly writes he wants an unaligned load we should honor it, perhaps for
> some reason the alignment info can't be trusted etc.
> ix86_expand_vector_move_misalign also checks misaligned_operand and only
> emits
> the non-UNSPEC insn for TARGET_AVX if it will result in misaligned load.

Thanks, the patch looks OK then (perhaps with the comment on misaligned_operand
usage).

[Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339

[jakub at gcc dot gnu.org]

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

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

So like this?  Note, the USE/CLOBBER change for flow_find_cross_jump
has been added in 2011 for 4.7 as PR43920 fix:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02246.html

[Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> So like this?  Note, the USE/CLOBBER change for flow_find_cross_jump
> has been added in 2011 for 4.7 as PR43920 fix:
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02246.html

Yes, let's try that, but use the same idiom in flow_find_cross_jump as yours
(i.e. remove the useless p1) added by the above fix so that your patch will
have an explicit link to the above fix.

[Bug c/59520] a possible inconsistency in error diagnostics with "-pedantic -std=c99"

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Wed, 18 Dec 2013, manu at gcc dot gnu.org wrote:

> > The main concerns for diagnostics in such cases are (a) that they are 
> > meaningful and (b) that invalid code gets at least one error with 
> > -pedantic-errors, and at least one warning or error with -pedantic.  
> > There may be less consistency in what's a warning / error if -pedantic 
> > rather than -pedantic-errors is used.
> 
> So merely using -pedantic may produce errors that do not appear without
> -pedantic? Is that really a desired behavior?

Not desired, but considered less important than the main concerns for 
these options that I listed above.

[Bug fortran/55207] [F08] Variables declared in the main program should implicitly get the SAVE attribute

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org

function cast leads to gcc abort command

[buzush]

hi,

in the following code:

func.c   
i tried to cast an int(int,int) function into an int(int) function an got
the gcc warning and note:

func.c:13:32: warning: function called through a non-compatible type
[enabled by default]
func.c:13:32: note: if this code is reached, the program will abort

and when trying to run i get:

Illegal instruction (core dumped)

but if i compile this file with a .cpp ending with the gcc compiler it works
OK.
can anyone explain the problem of the compiler in the .c case?



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/function-cast-leads-to-gcc-abort-command-tp996589.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug tree-optimization/59544] New: Vectorizing store with negative stop

[bmei at broadcom dot com]

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

Bug ID: 59544
   Summary: Vectorizing store with negative stop
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmei at broadcom dot com

Created attachment 31467
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31467&action=edit
The patch against r206016

I was looking at some loops that can be vectorized by LLVM, but not GCC. One
type of loop is with store of negative step. 

void test1(short * __restrict__ x, short * __restrict__ y, short * __restrict__
z)
{
int i;
for (i=127; i>=0; i--) {
x[i] = y[127-i] + z[127-i];
}
}

I don't know why GCC only implements negative step for load, but not store. I
implemented a patch (attached), very similar to code in vectorizable_load. 

~/scratch/install-x86/bin/gcc ghs-dec.c -ftree-vectorize -S -O2 -mavx

Without patch:
test1:
.LFB0:
addq$254, %rdi
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
movzwl(%rsi,%rax), %ecx
subq$2, %rdi
addw(%rdx,%rax), %cx
addq$2, %rax
movw%cx, 2(%rdi)
cmpq$256, %rax
jne.L2
rep; ret

With patch:
test1:
.LFB0:
vmovdqa.LC0(%rip), %xmm1
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
vmovdqu(%rsi,%rax), %xmm0
movq%rax, %rcx
negq%rcx
vpaddw(%rdx,%rax), %xmm0, %xmm0
vpshufb%xmm1, %xmm0, %xmm0
addq$16, %rax
cmpq$256, %rax
vmovups%xmm0, 240(%rdi,%rcx)
jne.L2
rep; ret

Performance is definitely improved here. It is bootstrapped for
x86_64-unknown-linux-gnu, and has no additional regressions on my machine.

For reference, LLVM seems to use different instructions and slightly worse
code. I am not so familiar with x86 assemble code. The patch is originally for
our private port. 
test1:  # @test1
.cfi_startproc
# BB#0: # %entry
addq$240, %rdi
xorl%eax, %eax
.align  16, 0x90
.LBB0_1:# %vector.body
# =>This Inner Loop Header: Depth=1
movdqu  (%rsi,%rax,2), %xmm0
movdqu  (%rdx,%rax,2), %xmm1
paddw   %xmm0, %xmm1
shufpd  $1, %xmm1, %xmm1# xmm1 = xmm1[1,0]
pshuflw $27, %xmm1, %xmm0   # xmm0 = xmm1[3,2,1,0,4,5,6,7]
pshufhw $27, %xmm0, %xmm0   # xmm0 = xmm0[0,1,2,3,7,6,5,4]
movdqu  %xmm0, (%rdi)
addq$8, %rax
addq$-16, %rdi
cmpq$128, %rax
jne .LBB0_1
# BB#2: # %for.end
ret

[Bug c++/22007] Stack overflow in g++.dg/eh/cleanup1.C

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Kai Tietz  ---
So it is fixed for all open branches AFAICS.  Therefore close it as fixed

[Bug fortran/59411] [F03] Problem with TYPE(C_PTR) constant initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 Ever confirmed|0   |1

--- Comment #6 from Dominique d'Humieres  ---
Confirmed at r206083.

[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Dec 18 12:36:00 2013
New Revision: 206085

URL: http://gcc.gnu.org/viewcvs?rev=206085&root=gcc&view=rev
Log:
2013-12-18  Janus Weil  

Backport from mainline
2013-12-15  Janus Weil  

PR fortran/59493
* class.c (gfc_find_intrinsic_vtab): Handle BT_CLASS.

2013-12-18  Janus Weil  

Backport from mainline
2013-12-15  Janus Weil  

PR fortran/59493
* gfortran.dg/unlimited_polymorphic_15.f90: New.

Added:
   
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_15.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/class.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug other/59545] New: Signed integer overflow issues

[mpolacek at gcc dot gnu.org]

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

Bug ID: 59545
   Summary: Signed integer overflow issues
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

I ran bootstrap with -fsanitize=undefined, here's a list of issues I've found.

combine.c:8204:6: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
combine.c:8204:6: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
double-int.c:141:17: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
double-int.c:141:17: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
double-int.c:141:17: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
double-int.c:141:17: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
genattrtab.c:622:27: runtime error: signed integer overflow: 4568797 * 613
cannot be represented in type 'int'
genautomata.c:3497:23: runtime error: shift exponent 64 is too large for 64-bit
type 'long unsigned int'
ifcvt.c:1116:18: runtime error: signed integer overflow: -9223372036854775808 -
9223372036854775807 cannot be represented in type 'long int'
ifcvt.c:1116:18: runtime error: signed integer overflow: -9223372036854775808 -
9223372036854775807 cannot be represented in type 'long int'
ira-color.c:1508:29: runtime error: signed integer overflow: -12123975 * 185
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -128583990 * 811
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -128583990 * 811
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -128583990 * 811
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -128583990 * 811
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 590
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 590
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 590
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -131071000 * 590
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -13238070 * 808
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -134813175 * 122
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -14909212 * 910
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -15417108 * 941
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -16383750 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -16383750 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -16383750 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -16383750 * 1000
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -16383750 * 250
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -17664042 * 500
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -17664042 * 500
cannot be represented in type 'int'
ira-color.c:1508:29: runtime error: signed integer overflow: -19958478 * 219

[Bug libgomp/59546] New: wrong behavior with reduction

[valeryweber at hotmail dot com]

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

Bug ID: 59546
   Summary: wrong behavior with reduction
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
CC: jakub at gcc dot gnu.org

hi all

the following code is producing strange result (removing the writes works
fine). is it a bug?

v


gfortran-trunk --version
GNU Fortran (GCC) 4.9.0 20131119 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

[vwe@triest semd]$ cat gcc_reduction.f90 
program test
  use omp_lib
  implicit none
  integer :: i

  !$omp parallel reduction(+:i)
  i=1

  !$omp master
  write(*,*) 'first write'
  write(*,*) 'second write'
  !$omp end master

  !$omp end parallel

  if(i.ne.omp_get_max_threads()) then
 write(*,*) i
 stop 'err1'
  endif

end program test
[vwe@triest semd]$ export OMP_NUM_THREADS=1; gfortran-trunk -fopenmp
gcc_reduction.f90   ;  ./a.out 
 first write
 second write
  49
STOP err1

[Bug fortran/58991] ICE with associate and character string constant

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE occurs at line 10801 of gcc/fortran/resolve.c:

  e = sym->ts.u.cl->length;

gdb shows

(gdb) p sym->ts.u.cl
$2 = (gfc_charlen *) 0x0warning: (Internal error: pc 0x0 in read in psymtab,
but not in symtab.)

[Bug libgomp/59546] wrong behavior with reduction

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
i is uninitialized before the reduction, so if you add some number of threads
to an uninitialized value, you can get pretty much anything.

Also, there is no guarantee !$omp parallel will create exactly
omp_get_max_threads () threads, that is just maximum for the number of threads,
it can depend on env vars etc.

[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
Also seen on x86_64-apple-darwin13 at r206072 (only once).

Note that on x86_64-apple-darwin13 I see random PCH failures when I do the
check with -j8, e.g.:

WARNING: program timed out.
FAIL: gcc.dg/pch/save-temps-1.c  -O0 -g -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/save-temps-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/save-temps-1.c   -O0  -I. -Dwith_PCH (internal compiler error)
FAIL: gcc.dg/pch/save-temps-1.c   -O0  -I. -Dwith_PCH (test for excess errors)
FAIL: gcc.dg/pch/save-temps-1.c   -O0  assembly comparison
WARNING: program timed out.
FAIL: g++.dg/pch/pch.C  -O2 -g -I. -Dwith_PCH (test for excess errors)
FAIL: g++.dg/pch/pch.C -O2 -g assembly comparison
WARNING: program timed out.
FAIL: g++.dg/pch/pch.C  -O2 -I. -Dwith_PCH (test for excess errors)
FAIL: g++.dg/pch/pch.C -O2 assembly comparison
FAIL: g++.dg/pch/pch.C  -g -I. -Dwith_PCH (internal compiler error)
FAIL: g++.dg/pch/pch.C  -g -I. -Dwith_PCH (test for excess errors)
FAIL: g++.dg/pch/pch.C  -g assembly comparison

Could it be related to this PR?

[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #21 from Markus Trippelsdorf  ---
Jeff patch to split up the erroneous path optimization into two pieces
(r205689) fixes the issue.

[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
The fix has been committed to trunk and the 4.8 branch, so that it will be
included in the upcoming releases 4.9.0 and 4.8.3.

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

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

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

--- Comment #1 from Andreas Schwab  ---
Between r205951 and r205984.

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

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

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

--- Comment #2 from Andreas Schwab  ---
Created attachment 31468
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31468&action=edit
Preprocessed source

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[tejohnson at google dot com]

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

--- Comment #2 from Teresa Johnson  ---
Thanks, I am able to reproduce now with the gold linker option.
Investigating...
Teresa

On Wed, Dec 18, 2013 at 12:52 AM, trippels at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59542
>
> Markus Trippelsdorf  changed:
>
>What|Removed |Added
> 
>  CC||tejohnson at google dot com
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|m68k-linux  |m68k-*-*
 CC||amker at gcc dot gnu.org

--- Comment #3 from Andreas Schwab  ---
c03531c413c501b0033ea2ea3f030cd7e6f66320 is the first bad commit
commit c03531c413c501b0033ea2ea3f030cd7e6f66320
Author: amker 
Date:   Fri Dec 13 11:36:22 2013 +

PR tree-optimization/58296
PR tree-optimization/41488
* tree-scalar-evolution.c: Include necessary header files.
(simplify_peeled_chrec): New function.
(analyze_evolution_in_loop): New static variable.
Call simplify_peeled_chrec.
* tree-ssa-loop-ivopts.c (mark_bivs): Don't mark peeled IV as biv.
(add_old_iv_candidates): Don't add candidate for peeled IV.
* tree-affine.h (aff_combination_zero_p): New function.

PR tree-optimization/58296
PR tree-optimization/41488
* gcc.dg/tree-ssa/scev-7.c: New test.
* gcc.dg/pr41488.c: New test.
* g++.dg/pr59445.C: New test.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205959
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 Ever confirmed|0   |1

[Bug c++/59110] [4.9 Regression] [c++1y] ICE using auto in cast

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
We hit the exact same place as in PR59111.  lookup_conversions gets
template_type_parm as a parameter, subsequent TYPE_BINFO fails on it.

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

[Bug c++/59111] [4.9 Regression] [c++11] ICE on invalid usage of auto in return type

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
*** Bug 59110 has been marked as a duplicate of this bug. ***

[Bug c++/59111] [4.9 Regression] [c++11] ICE on invalid usage of auto in return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Hopefully just 
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -2506,7 +2506,7 @@ lookup_conversions (tree type)
   tree list = NULL_TREE;

   complete_type (type);
-  if (!TYPE_BINFO (type))
+  if (!RECORD_OR_UNION_TYPE_P (type) || !TYPE_BINFO (type))
 return NULL_TREE;

   lookup_conversions_r (TYPE_BINFO (type), 0, 0,
will do...

[Bug libfortran/59513] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[aruopp at gmx dot de]

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

--- Comment #5 from ARuopp  ---
Created attachment 31469
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31469&action=edit
test script for running xfoil with output in file

this is a test script for testing xfoil in running in batch mode.
what it does:
starting xfoil
loading a test profil naca 0018
setting values
calculating some lift and drag values for different aoa
writing solution in polarfile_1.dat
then it finishes


in shell execute the program like this:
xfoil < xfoil.naca.run1

[Bug libfortran/59513] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[aruopp at gmx dot de]

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

--- Comment #6 from ARuopp  ---
Hi,

thank you very much for your effort.
Compiling is not the problem. 
Try to execute the script, which I attached. 
Without the "backspace" modification, xfoil ends with the error message:

At line 655 of file ../src/iopol.f (unit = 9, file = 'polarfile_1.dat')
Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker,
possibly use REWIND or BACKSPACE

Is your xfoil running without the modification?

[Bug libfortran/59513] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[aruopp at gmx dot de]

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

--- Comment #7 from ARuopp  ---
Execute with:
xfoil < xfoil.naca.run1

[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Doesn't seem to be related to make -jN, I can reproduce it every few iterations
of:
rm i686-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch;
/usr/src/gcc/obj825/./gcc/xgcc -shared-libgcc -B/usr/src/gcc/obj825/./gcc
-nostdinc++ -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src
-L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include-x c++-header -nostdinc++ -g -O2
-D_GNU_SOURCE 
-I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include
-I/usr/src/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/usr/src/gcc/libstdc++-v3/include/precompiled/stdc++.h -o
i686-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch;
/usr/src/gcc/obj825/./gcc/xg++ -shared-libgcc -B/usr/src/gcc/obj825/./gcc
-nostdinc++ -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src
-L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include
-B/usr/src/gcc/obj825/i686-pc-linux-gnu/./libstdc++-v3/src/.libs
-fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE
-DLOCALEDIR="." -nostdinc++
-I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include
-I/usr/src/gcc/libstdc++-v3/libsupc++
-I/usr/src/gcc/libstdc++-v3/include/backward
-I/usr/src/gcc/libstdc++-v3/testsuite/util
/usr/src/gcc/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc
-std=gnu++0x -S -o stdc++.s

So perhaps it is related to address space randomization during PCH writing or
something similar.  The *.gch file is different every time.

[Bug libfortran/59513] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 Ever confirmed|0   |1

--- Comment #8 from Dominique d'Humieres  ---
Running your script on xfoil built by fink (gfortran 4.8.2) ends with the
reported error:

  10   rms: 0.6268E-05   max: -.8920E-04   D at   83  1
   a =  0.000  CL = -0.
  Cm =  0. CD =  0.00773   =>   CDf =  0.00549CDp =  0.00224

 Point added to stored polar  1
At line 652 of file ../src/iopol.f (unit = 9, file = 'polarfile_1.dat')
Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker,
possibly use REWIND or BACKSPACE

I'll try to find some time to build foil myself with earlier versions (don't
hold your breath!-).

[Bug fortran/59547] New: Problem with using tbp specification function in multiple class procedures

[b...@miller-mohr.de]

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

Bug ID: 59547
   Summary: Problem with using tbp specification function in
multiple class procedures
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b...@miller-mohr.de

Created attachment 31470
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31470&action=edit
Error messages from gfortran 4.9.0

Hi,

this is a follow-up on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450. The
ICE reported there got fixed (thanks). Verified this with 
GNU C version 4.9.0 20131217 (experimental).

However, there is still an issue with using a specification function in a class
procedure. When I use the function in multiple (tested with two) procedures, I
get errors on the function not being pure. However, when it is used in only one
procedure, this is not the case. The example I used is the following:

module classes

  implicit none

  type :: base_class
 integer :: member
   contains
 procedure, nopass :: get_num

 ! either of the lines below alone works, but not both together
 procedure :: get_array
 procedure :: get_array2
  end type

contains

  pure integer function get_num()
get_num = 2
  end function

  function get_array( this ) result(array)
class(base_class), intent(in) :: this
integer, dimension( this%get_num() ) :: array
  end function

  function get_array2( this ) result(array)
class(base_class), intent(in) :: this
integer, dimension( this%get_num(), this%get_num() ) :: array
  end function

end module

I get the attached errors.

Cheers
Marcus

[Bug fortran/59450] [OOP] ICE for type-bound-procedure expression in module procedure interface

[b...@miller-mohr.de]

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

--- Comment #9 from b...@miller-mohr.de ---
Hi,

verified that the ICE is gone in gcc version 4.9.0 20131217 (experimental).
Thanks a lot. However, there is still a problem. As it is no longer an ICE I
filed a new bug 59547 

Cheers
Marcus

[Bug libfortran/59513] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[aruopp at gmx dot de]

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

--- Comment #9 from ARuopp  ---
BTW: 
"At line 652 of file"is correct.

Line 655 was including some comments from my side... I didn't want to
confuse

[Bug c/57681] Possible missing break in cp-array-notation.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
The break has been added since then.  And in the following code, in case of
BUILT_IN_CILKPLUS_SEC_REDUCE, the code variable is not used, so that doesn't
seem like a bug.  Closing.

[Bug fortran/59547] Problem with using tbp specification function in multiple class procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed with trunk at r206033. However my patched tree gives

pr59547.f90:23.23:

integer, dimension( this%get_num() ) :: array
   1
Error: Function 'this' at (1) must be PURE
pr59547.f90:23.23:

integer, dimension( this%get_num() ) :: array
   1
Error: Function 'this' at (1) must be PURE
pr59547.f90:23.23:

integer, dimension( this%get_num() ) :: array
   1
Error: Function 'this' at (1) must be PURE

and this time I think I know where to look (I need a little bit of time to
search the patches I have applied and to recover bootstrap on darwin).

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Sounds just like uncovering a latent bug in cselib?

[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #9 from Vladimir Makarov  ---
(In reply to Richard Earnshaw from comment #5)
> Number of register-register move operations in the testcase
> lra:208
> no-lra: 105

That is huge degradation.  And I guess it is not only because of 2-ops insns. 
It works adequate on x86/x86-64.  Although I know some issues with 2-ops
commutative insns (I am trying to fix it too).

I think major problem is in wrong alternative choices as thumb lo/hi reg usage
is complicated.

I take this bug very seriously.  If I cannot fix it till end of Jan (sorry, it
is a vacation time), probably we should switch to reload pass for thumb.

[Bug c++/59548] New: Abort after copying std::unordered_map in debug mode

[max at duempel dot org]

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

Bug ID: 59548
   Summary: Abort after copying std::unordered_map in debug mode
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: max at duempel dot org

Created attachment 31471
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31471&action=edit
Demo code

Create an std::unordered_map and save its end() to a variable. Then copy the
std::unordered_map to a temporary variable, and destruct it. Now the iterator
will be "detached", and dereferencing it causes an abort:

/usr/include/c++/4.8/debug/safe_iterator.h:279:error: attempt to 
dereference a singular iterator.

Objects involved in the operation:
iterator "this" @ 0x0x7fff741c4f40 {
type =
N11__gnu_debug14_Safe_iteratorINSt8__detail14_Node_iteratorISt4pairIKiiELb0ELb0EEENSt7__debug13unordered_mapIiiSt4hashIiESt8equal_toIiESaIiE
(mutable iterator);
  state = singular;
}
Aborted

Minimal demo code and bug fix attached.

I suggest disabling _Safe_sequence_base's implicit copy constructor to avoid
future bugs like that. Patch attached.

[Bug c++/59548] Abort after copying std::unordered_map in debug mode

[max at duempel dot org]

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

--- Comment #1 from Max Kellermann  ---
Created attachment 31472
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31472&action=edit
Bug fix: call only _Base constructor, no implicit _Safe_sequence_base copy

[Bug c++/59548] Abort after copying std::unordered_map in debug mode

[max at duempel dot org]

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

--- Comment #2 from Max Kellermann  ---
Created attachment 31473
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31473&action=edit
Delete the implicit copy constructor in C++11 mode to detect bugs like this one

[Bug libfortran/59513] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
I also see the problem with gfortran 4.7.3.

[Bug target/59460] [4.9 Regression] ICE with -mips16 and __attribute__((nomips16))

[robert.suchanek at imgtec dot com]

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

--- Comment #1 from Robert Suchanek  ---
Ping

Where should I look at or what else could be done to resolve this without
reverting the patch for pr58115?

[Bug c++/59548] Abort after copying std::unordered_map in debug mode

[max at duempel dot org]

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

--- Comment #3 from Max Kellermann  ---
This is a regression by svn r195253.

>From the commit message:

"* include/debug/unordered_map.h: Undo previous commit. Default copy and move
constructors."

[Bug libfortran/59513] [4.7/4.8/4.9] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|Fortran runtime error:  |[4.7/4.8/4.9] Fortran
   |Sequential READ or WRITE|runtime error: Sequential
   |not allowed after EOF   |READ or WRITE not allowed
   |marker, possibly use REWIND |after EOF marker, possibly
   |or BACKSPACE|use REWIND or BACKSPACE

--- Comment #11 from Dominique d'Humieres  ---
No error with gfortran  4.4.7, 4.5.4, but gfortran 4.6.4 gives the error. So
marked as a 4.7/4.8/4.9 regression. 

When I'll have learnt how to build foil myself, I'll try to do some bisection
and some reduction.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 18 16:50:06 2013
New Revision: 206090

URL: http://gcc.gnu.org/viewcvs?rev=206090&root=gcc&view=rev
Log:
PR target/59539
* config/i386/sse.md
(_loadu,
_loaddqu): New expanders,
prefix existing define_insn names with *.

* gcc.target/i386/pr59539-1.c: New test.
* gcc.target/i386/pr59539-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr59539-1.c
trunk/gcc/testsuite/gcc.target/i386/pr59539-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661

[nheghathivhistha at gmail dot com]

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

--- Comment #15 from David Kredba  ---
I am sorry, I can't. When I did -nostdlib link on all object files, it linked.
Only full link command with all libraries causes ICE for me and I do not now
how to reduce it/identify.

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/59547] [OOP] Problem with using tbp specification function in multiple class procedures

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||janus at gcc dot gnu.org
Summary|Problem with using tbp  |[OOP] Problem with using
   |specification function in   |tbp specification function
   |multiple class procedures   |in multiple class
   ||procedures

--- Comment #2 from janus at gcc dot gnu.org ---
As the example in PR 59450 shows, the propagation of the PURE attribute (from
the procedure symbol of 'get_num' to the corresponding PPC in the vtab) works
in principle (it happens in resolve_fl_derived0).

I think the problem here is simply related to the resolution order: We resolve
get_array before get_num, therefore the pureness has not been propagated yet.

I will try to find a way around it ...

[Bug target/59539] Missed optimisation: VEX-prefixed operations don't need aligned data

[thiago at kde dot org]

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

--- Comment #12 from Thiago Macieira  ---
Thanks, rebuilding!

[Bug fortran/59547] [OOP] Problem with using tbp specification function in multiple class procedures

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
The following should be sufficient (regtesting now):


Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c(revision 206083)
+++ gcc/fortran/class.c(working copy)
@@ -721,9 +721,11 @@ add_proc_comp (gfc_symbol *vtype, const char *name

   if (tb->u.specific)
 {
-  c->ts.interface = tb->u.specific->n.sym;
+  gfc_symbol *ifc = tb->u.specific->n.sym;
+  c->ts.interface = ifc;
   if (!tb->deferred)
 c->initializer = gfc_get_variable_expr (tb->u.specific);
+  c->attr.pure = ifc->attr.pure;
 }
 }

[Bug fortran/59547] [OOP] Problem with using tbp specification function in multiple class procedures

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/59549] New: [SH] __builtin_return_address causes push/pop of PR

[olegendo at gcc dot gnu.org]

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

Bug ID: 59549
   Summary: [SH] __builtin_return_address causes push/pop of PR
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

The following:

void* test (void)
{
  return __builtin_return_address (0);
}

compiled with -m4 -O2 results in:

sts.l   pr,@-r15
sts pr,r0
lds.l   @r15+,pr
rts
nop

The push and pop of PR is not necessary, as it's only used, but not modified.
It seems that calc_live_regs in sh.c is missing something.

[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
I have reverted the changes in gcc/config/darwin.c done by r 206070 and
bootstrap went fine. The new failing tests are still there.

[Bug bootstrap/59541] [4.9 Regression] Revision 206070 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> The new failing tests are still there.

I was wrong: gcc.dg/tree-prof/crossmodule-indircall-1.c passes.

[Bug c++/59550] New: compiler crash when forming a pointer to a reference would be needed in std::initalizer_list

[ali.baharev at gmail dot com]

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

Bug ID: 59550
   Summary: compiler crash when forming a pointer to a reference
would be needed in std::initalizer_list
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ali.baharev at gmail dot com

Code:

#include 
#include 
using namespace std;

void writeSomething(initializer_list args) {
for (auto f : args )
f << "hello" << endl;
}

int main() {
ofstream outputFile("data_1.txt");
writeSomething({outputFile});
}

Online demonstration:

http://ideone.com/vTHDFy

This code came up at 

http://stackoverflow.com/q/20665699/341970

[Bug target/52794] gcc.dg/tree-prof/pr52027.c fails on x86_64/i386-apple-darwin*

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
This seems to be fixed by a change between r206040 and r206072. Due to pr59541
you need to revert r206070 for the file gcc/config/darwin.c.

[Bug debug/59418] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2221

[rmansfield at qnx dot com]

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

--- Comment #6 from Ryan Mansfield  ---
(In reply to Eric Botcazou from comment #5)
> Thanks for reporting the problem and distilling the testcase.

No problem, thanks for fixing.

[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Dec 18 22:00:53 2013
New Revision: 206101

URL: http://gcc.gnu.org/viewcvs?rev=206101&root=gcc&view=rev
Log:
2013-12-18  Janus Weil  

PR fortran/59493
* gfortran.h (gfc_find_intrinsic_vtab): Removed prototype.
(gfc_find_vtab): New prototype.
* class.c (gfc_find_intrinsic_vtab): Rename to 'find_intrinsic_vtab' and
make static. Minor modifications.
(gfc_find_vtab): New function.
(gfc_class_initializer): Use new function 'gfc_find_vtab'.
* check.c (gfc_check_move_alloc): Ditto.
* expr.c (gfc_check_pointer_assign): Ditto.
* interface.c (compare_actual_formal): Ditto.
* resolve.c (resolve_allocate_expr, resolve_select_type): Ditto.
* trans-expr.c (gfc_conv_intrinsic_to_class, gfc_trans_class_assign):
Ditto.
* trans-intrinsic.c (conv_intrinsic_move_alloc): Ditto.
* trans-stmt.c (gfc_trans_allocate): Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/class.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[tejohnson at google dot com]

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

--- Comment #3 from Teresa Johnson  ---
On Wed, Dec 18, 2013 at 6:15 AM, Teresa Johnson  wrote:
> Thanks, I am able to reproduce now with the gold linker option. 
> Investigating...
> Teresa
>
> On Wed, Dec 18, 2013 at 12:52 AM, trippels at gcc dot gnu.org
>  wrote:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59542
>>
>> Markus Trippelsdorf  changed:
>>
>>What|Removed |Added
>> 
>>  CC||tejohnson at google dot com
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.

Here is the patch that fixes it, and I am currently regression testing:

Teresa

2013-12-18  Teresa Johnson  

* bb-reorder.c (duplicate_computed_gotos): Invoke fixup_partitions
if we have made any changes.

Index: bb-reorder.c
===
--- bb-reorder.c(revision 206100)
+++ bb-reorder.c(working copy)
@@ -2390,6 +2390,7 @@ duplicate_computed_gotos (void)
   basic_block bb, new_bb;
   bitmap candidates;
   int max_size;
+  bool changed = false;

   if (n_basic_blocks_for_fn (cfun) <= NUM_FIXED_BLOCKS + 1)
 return 0;
@@ -2486,9 +2487,17 @@ duplicate_computed_gotos (void)
   new_bb->aux = bb->aux;
   bb->aux = new_bb;
   new_bb->flags |= BB_VISITED;
+  changed = true;
 }

 done:
+  /* Duplicating blocks above will redirect edges and may cause hot blocks
+ previously reached by both hot and cold blocks to become dominated only
+ by cold blocks. This will cause the verification when leaving cfg layout
+ mode to fail, and lead to now cold code in the hot section. Invoke
+ fixup_partitions to address these problems.  */
+  if (changed)
+fixup_partitions ();
   cfg_layout_finalize ();

   BITMAP_FREE (candidates);


>
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[Bug fortran/59440] [4.9 Regression] ICE in force_decl_die, at dwarf2out.c:20111 with -g

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
The problem is the following code in tree-nested.c:


/* A subroutine of convert_local_reference.  Create a local variable
   in the parent function with DECL_VALUE_EXPR set to reference the
   field in FRAME.  This is used both for debug info and in OpenMP
   lowering.  */

static tree
get_local_debug_decl (struct nesting_info *info, tree decl, tree field)
{
...
  new_decl = build_decl (DECL_SOURCE_LOCATION (decl),
 VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));
  DECL_IGNORED_P (new_decl) = DECL_IGNORED_P (decl);
...
  /* Do not emit debug info twice.  */
  DECL_IGNORED_P (decl) = 1;
}


Result: new_decl gets emitted due to DECL_IGNORED_P being copied - but the
NAMELIST_DECL still points to the 'old' decl, which now has DECL_IGNORED_P() =
1.

[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
./cc1 -Os -mthumb -mcpu=arm7tdmi -fno-short-enums test.i -m{no-}lra
-fno-schedule-insns2

original reload  reload with change  lra with change
reg moves   104 86  101
all moves   210 192 207
loads   561 569 541
stores  234 231 210

overall1005 992 958
mov/ldr/str

  First of all, I can not compile the test with LRA because of its
crash.  The problem is in choosing alternatives different from reload.
For some insn alternatives, LRA needs two hi regs for reloads.  But
there is only one 12, all others hi-regs are fixed.

 To be honest, I don't know why 12 is not fixed.  It results in using
12 by IRA and bigger code when even reload is used.  I believe it
should fixed too.

 Second, big number of moves is not a bad thing.  It should considered
with # ld/st.  LRA generates 15 more reg moves but 28 less loads and
21 less stores.  It means LRA with the patch generates smaller and
faster code than reload.

Here is the patch improving code size for reload and fixing LRA crash
and improving code for LRA.

  If arm part of the patch is ok, please let me know.  I'll commit the
patch then.  The rest of the patch does not affect the test code
generation but it might affect other code generated with -Os.

Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 206089)
+++ config/arm/arm.c(working copy)
@@ -29236,6 +29236,7 @@ arm_conditional_register_usage (void)
   for (regno = FIRST_HI_REGNUM;
   regno <= LAST_HI_REGNUM; ++regno)
fixed_regs[regno] = call_used_regs[regno] = 1;
+  fixed_regs[12] = call_used_regs[12] = 1;
 }

   /* The link register can be clobbered by any branch insn,
Index: lra-assigns.c
===
--- lra-assigns.c   (revision 206089)
+++ lra-assigns.c   (working copy)
@@ -612,7 +612,9 @@ find_hard_regno_for (int regno, int *cos
&& ! df_regs_ever_live_p (hard_regno + j))
  /* It needs save restore.  */
  hard_regno_costs[hard_regno]
-   += 2 * ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb->frequency + 1;
+   += (2
+   * REG_FREQ_FROM_BB (ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb)
+   + 1);
  priority = targetm.register_priority (hard_regno);
  if (best_hard_regno < 0 || hard_regno_costs[hard_regno] < best_cost
  || (hard_regno_costs[hard_regno] == best_cost
Index: lra-coalesce.c
===
--- lra-coalesce.c  (revision 206089)
+++ lra-coalesce.c  (working copy)
@@ -79,8 +79,8 @@ move_freq_compare_func (const void *v1p,
   rtx mv2 = *(const rtx *) v2p;
   int pri1, pri2;

-  pri1 = BLOCK_FOR_INSN (mv1)->frequency;
-  pri2 = BLOCK_FOR_INSN (mv2)->frequency;
+  pri1 = REG_FREQ_FROM_BB (BLOCK_FOR_INSN (mv1));
+  pri2 = REG_FREQ_FROM_BB (BLOCK_FOR_INSN (mv2));
   if (pri2 - pri1)
 return pri2 - pri1;

@@ -277,7 +277,7 @@ lra_coalesce (void)
fprintf
  (lra_dump_file, "  Coalescing move %i:r%d-r%d (freq=%d)\n",
   INSN_UID (mv), sregno, dregno,
-  BLOCK_FOR_INSN (mv)->frequency);
+  REG_FREQ_FROM_BB (BLOCK_FOR_INSN (mv)));
  /* We updated involved_insns_bitmap when doing the merge.  */
}
   else if (!(lra_intersected_live_ranges_p
@@ -291,7 +291,7 @@ lra_coalesce (void)
   "  Coalescing move %i:r%d(%d)-r%d(%d) (freq=%d)\n",
   INSN_UID (mv), sregno, ORIGINAL_REGNO (SET_SRC (set)),
   dregno, ORIGINAL_REGNO (SET_DEST (set)),
-  BLOCK_FOR_INSN (mv)->frequency);
+  REG_FREQ_FROM_BB (BLOCK_FOR_INSN (mv)));
  bitmap_ior_into (&involved_insns_bitmap,
   &lra_reg_info[sregno].insn_bitmap);
  bitmap_ior_into (&involved_insns_bitmap,
@@ -316,7 +316,8 @@ lra_coalesce (void)
/* Coalesced move.  */
if (lra_dump_file != NULL)
  fprintf (lra_dump_file, "  Removing move %i (freq=%d)\n",
-INSN_UID (insn), BLOCK_FOR_INSN (insn)->frequency);
+  INSN_UID (insn),
+  REG_FREQ_FROM_BB (BLOCK_FOR_INSN (insn)));
lra_set_insn_deleted (insn);
  }
  }
Index: lra-constraints.c
===
--- lra-constraints.c   (revision 206089)
+++ lra-constraints.c   (working copy)
@@ -4077,7 +4077,7 @@ lra_constraints (bool first_p)
  fprintf (lra_dump_file,
   "  Removing equiv init insn %i (freq=%d)\n",

[Bug other/59545] Signed integer overflow issues

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Dup of PR 57324? (yes, I know, gcc vs clang)

[Bug target/59551] New: ICE when compiling ImageMagick on hppa/linux

[aaro.koskinen at iki dot fi]

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

Bug ID: 59551
   Summary: ICE when compiling ImageMagick on hppa/linux
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaro.koskinen at iki dot fi

ICE when compiling ImageMagick-6.8.6-7 magick/draw.c on HPPA/Linux:

magick/draw.c: In function 'DrawImage':
magick/draw.c:3156:1: error: unrecognizable insn:
(insn 11930 11928 11931 68 (set (reg/f:SI 31 %r31)
(mem/f/c:SI (plus:SI (reg/f:SI 30 %r30)
(const_int -41640 [0x5d58])) [2 draw_info+0 S4 A32]))
magick/draw.c:1934 -1
 (nil))
magick/draw.c:3156:1: internal compiler error: in extract_insn, at recog.c:2154
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

.i output is attached.

Steps to reproduce:
gcc -O2 -c draw.i

GCC version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/hppa-linux-gnu/4.8.2/lto-wrapper
Target: hppa-linux-gnu
Configured with: /home/aaro/los/work/shared/gcc-4.8.2/configure --build=none
--host=hppa-linux-gnu --target=hppa-linux-gnu --prefix=/usr --disable-nls
--disable-bootstrap --enable-languages=c,c++ --with-system-zlib --enable-shared
--disable-static
Thread model: posix
gcc version 4.8.2 (GCC)

[Bug fortran/59440] [4.9 Regression] ICE in force_decl_die, at dwarf2out.c:20111 with -g

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus  ---
I see two not so pretty solutions:

a) The simple way: Duplicate debug info by also emitting code for the original
DECL.


b) The hard & slow way:

In tree-nested.c, add another walk_tree(), to be run after walk_function(),
which searches for TREE_CODE() == NAMELIST_DECL.

Then, the easy part follows: Go through the VEC of the NAMELIST_DECL and
replace the original decl by the one returned by
pointer_map_contains(info->var_map, decl).

[Bug target/59551] ICE when compiling ImageMagick on hppa/linux

[aaro.koskinen at iki dot fi]

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

--- Comment #1 from Aaro Koskinen  ---
Created attachment 31474
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31474&action=edit
Preprocessed source triggering the bug.