[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Dominique d'Humieres from comment #11)
> With the patch in comment 9, gfortran.dg/class_48.f90 no longer fails and I
> don't see any regression. The warning for the test in pr58746 comment 2 is
> also fixed.

But you can always create testcases (in C/C++ etc.) that will hit this warning,
so while the FE change is possible, we need to do something either about the
optimization passes in between IPA and cunrolli (copyprop change Jeff talks
about, perhaps only done for that single pass instance and not others, or all?,
guess depending on how expensive it is) or scheduling there another instance of
some other cleanup pass, or deferring the warning reporting until some cleanup.

For the FE change, I guess most important are benchmark results, doesn't it
slow down important benchmarks?

[Bug other/59545] Signed integer overflow issues

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Markus Trippelsdorf from comment #5)
> Thanks Jakub, it looks much better now. What is left are mostly left shifts
> of negative values:
> 
> gcc/combine.c:11865:14: runtime error: left shift of negative value -4096

Left shifts of negative value we apparently only warn for C++11 and C++14, not
for C++98 (is that because the C++98 wording is fuzzy, don't remember), and for
C99 and C11 the even stronger check where for signed left shifts not only all
negative values shifted up by any amount are invalid, but also positive values
shifted up such that the result is negative or any bits are shifted away.

Perhaps we should fix that in preparation for C++11 anyway, just trying to
understand why GCC hasn't reported it.

> gcc/cp/error.c:448:7: runtime error: call to function
> pp_cxx_type_specifier_seq(cxx_pretty_printer*, tree_node*) through pointer
> to incorrect function type 'void (*)(c_pretty
> _printer *, tree_node *)'

Haven't seen this error, perhaps we don't instrument it (yet)?  Marek?

> gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 +
> 9223372036854775806 cannot be represented in type 'long'
> gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 +
> 9223372036854775807 cannot be represented in type 'long'
> gcc/expr.c:3986:17: runtime error: signed integer overflow: 0 -
> -9223372036854775808 cannot be represented in type 'long'

I wonder why I haven't seen these with GCC (for clang I used some random svn
snapshot and the compiler was so terribly slow and occassionally hanging that I
gave up on it).  What exact configuration you've used?

[Bug other/56811] [4.8/4.9 Regression] libbacktrace causes undefined symbol "_Unwind_GetIPInfo" on ia64-hpux

[d.v.a at ngs dot ru]

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

--- Comment #9 from __vic  ---
Is there any progress and/or solid plan? The last available version of G++ for
HP-UX is 4.7.1 (here
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=2a08725cc2f02110725cc2f02110275d6e10RCRD)
Without normal C++11 support and important bug fixes!

[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 #7 from Dominique d'Humieres  ---
Note that on x86_64-apple-darwin10 the test
gcc.dg/tree-prof/cold_partition_label.c has started to fail (compilation, 
-fprofile-use -D_PROFILE_USE) between r204856 (OK) and r205324 (fail). This is
fixed at 206120 with the faulty part of 206070 reverted.

[Bug other/59545] Signed integer overflow issues

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Markus Trippelsdorf from comment #5)
> 
> > gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 +
> > 9223372036854775806 cannot be represented in type 'long'
> > gcc/cselib.c:1121:43: runtime error: signed integer overflow: 4224 +
> > 9223372036854775807 cannot be represented in type 'long'
> > gcc/expr.c:3986:17: runtime error: signed integer overflow: 0 -
> > -9223372036854775808 cannot be represented in type 'long'
> 
> I wonder why I haven't seen these with GCC (for clang I used some random svn
> snapshot and the compiler was so terribly slow and occassionally hanging
> that I gave up on it).  What exact configuration you've used?

You're right that clang is terribly slow (e.g. compiling insn-extract takes
over 5 minutes on my machine).
I'm using the LLVM 3.4 branch (they are close to release).
Config:
 % CC="clang -fsanitize=undefined -fno-sanitize=bounds -w" CXX="clang++
-fsanitize=undefined -fno-sanitize=bounds -w" ../gcc/configure
--disable-bootstrap --disable-werror --disable-multilib
--enable-languages=c,c++,fortran

[Bug debug/59510] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212 with -O2 -g --param=large-stack-frame-growth=1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Very likely duplicate of PR debug/59350.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
> Let me raise another question that is unrelated, but perhaps you folks, in
> particular Joseph, could help add some clarify as I have been baffled by a
> couple of examples. 
> 
> In particular, are the following well-defined according the standard or they
> have undefined behavior? 

AFAIK neither is well-defined according to base standards, in C (and C++?) the
only valid accesses to union are to the last stored field, but it is accepted
as GNU extension.  

> Ex 2
> 
> 
> int printf (const char *, ...);
> 
> struct S0
> {
>   char f0;
>   int f1;
> };
> 
> union
> {
>   int f0;
>   struct S0 f1;
> } d;
> 
> int
> main ()
> {
>   struct S0 g = {0,0};
>   d.f1 = g;
>   printf ("%d\n", d.f0);

This is of course undefined behavior even with the GNU extensions, padding bits
in g are undefined and you are then accessing them.  It is the same thing
as if you did struct S0 g = {0,0}; memcpy (&d.f0, &g, sizeof (int)); printf
("%d\n", d.f0);

[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #12)
> But you can always create testcases (in C/C++ etc.) that will hit this
> warning, so while the FE change is possible, we need to do something either
> about the optimization passes in between IPA and cunrolli (copyprop change
> Jeff talks about, perhaps only done for that single pass instance and not
> others, or all?, guess depending on how expensive it is) or scheduling there
> another instance of some other cleanup pass, or deferring the warning
> reporting until some cleanup.
> 

Could someone please provide a C test case that generates this warning?

maybe something like:

 int dovar = from;
 if (dovar <= to)
   for (;;)
 {
  ...
  if (dovar == to)
break;
  dovar += step;
}

> For the FE change, I guess most important are benchmark results, doesn't it
> slow down important benchmarks?


I think the change in the simple DO-loops really makes sense,
independent of this warning.

It generates the IL code just a bit more like it is done in C:

for (dovar=from; dovar <= to; dovar+=step) { ... }

=>

 dovar = from;
 if (dovar <= to)
 {
   loop:
...
dovar+=step;
if (dovar <= to)
   goto loop;
 }

Therefore the IL is easier to analyze and 
chances are good that the optimizer performs better.

I can't do these benchmarks however. Who could do that for us?

[Bug preprocessor/59566] [4.8/4.9 regression] g++ preprocessor output includes comments meant for GNU C Library files

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-12-20
   Target Milestone|--- |4.8.3
Summary|[4.8 regression] g++|[4.8/4.9 regression] g++
   |preprocessor output |preprocessor output
   |includes comments meant for |includes comments meant for
   |GNU C Library files |GNU C Library files
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
You are using -C, so what do you expect?  Note that since 4.8.x GCC
automatically
includes stdc-predef.h (which you can see when you remove the -P option).  The
comment nicely explains in the last sentence:

/* This header is separate from features.h so that the compiler can
   include it implicitly at the start of every compilation.  It must
   not itself include  or any other header that includes
because the implicit include comes before any feature
   test macros that may be defined in a source file before it first
   explicitly includes a system header.  GCC knows the name of this
   header in order to preinclude it.  */

Thus, it works as designed. No?

[Bug c++/59565] ICE on valid code in DWARF generation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[amker.cheng at gmail dot com]

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

--- Comment #5 from bin.cheng  ---
For the offending loop:

  :

  :
  # b.4_30 = PHI 
  # prephitmp_28 = PHI 
  # b_lsm.11_13 = PHI 
  # ivtmp_46 = PHI 
  c.1_9 = prephitmp_28 | 1;
  b.4_12 = b.4_30 + 1;
  ivtmp_45 = ivtmp_46 - 1;
  if (ivtmp_45 != 0)
goto ;
  else
goto ;

Now SCEV recognizes b_lsm.11_13 as {1,1}_2, and vectorizer considers it can be
vectorized.
The problem comes in function slpeel_update_phi_nodes_for_guard1 for phi node
:# b_lsm.11_13 = PHI .  It's special because its loop_arg:
b.4_12 has already been handled in previous node and has non-null current
definition, resulting in assertion failure at line:
  gcc_assert (get_current_def (current_new_name) == NULL_TREE);

It seems loop manipulating utility for vectorization can't cope with this kind
PEELED phi node.

We can get more loops vectorized if we can handle this issue in vectorization.
For example, the more complicated example reported can be vectorized
successfully.

But, I think it's a little bit difficult to handle the case because it's
possible to have the PEELED phi node come before the phi node from which it's
peeled from (b.4_30, in this case), just like:

  :

  :
  # b_lsm.11_13 = PHI

[Bug tree-optimization/59564] False positive array -Warray-bounds check with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-20
  Component|c   |tree-optimization
Version|unknown |4.9.0
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.0

--- Comment #2 from Richard Biener  ---
DOM optimizes this to

  if (n <= 0)
{
  n = 0;
  arr[0] = 0;
}
  else
arr[n] = 0;

after which value-range propagation warns for the arr[n] on the else
branch because there n >= 1 and thus the access is out-of-bounds.

Fixing the obfuscation by doing

  if (n < 0) n = 0;

instead of

  if (n <= 0) n = 0;

fixes the warning.

The warning is basically that n is not constrained to be < 1 which is
of course kind-of-useless.  We don't warn for a plain arr[n] either.
But as you give VRP a half-useful range you make it emit the warning.

Common to these kind of "bogus" warnings is that we have duplicated the
memory access and warn about the "bad" half of it.  But we have no way
of tracking whether there are now two pieces instead of just one ...
(apart from maybe using source location info and making sure that VRP
computes the same "warning" for equal source location accesses).

[Bug other/59545] Signed integer overflow issues

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #6)
> > gcc/cp/error.c:448:7: runtime error: call to function
> > pp_cxx_type_specifier_seq(cxx_pretty_printer*, tree_node*) through pointer
> > to incorrect function type 'void (*)(c_pretty
> > _printer *, tree_node *)'
> 
> Haven't seen this error, perhaps we don't instrument it (yet)?  Marek?

Yeah, we don't instrument this at all.

[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 #8 from Dominique d'Humieres  ---
> > could someone please point me at the original post for this patch?
>
> I have the same question.

I have finally found the answer: final patch at

http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01368.html

OKed by Jan Hubicka at

http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01379.html

[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Weird, I still get exactly the same code (except for gcc version string)
between pre-r205884 and post-r205884.  So, what exact differences are you
seeing on the testcase, and with -fdump-tree-all -da starting with what pass? 
Tried both a non-bootstrap gcc in my bisecting tree and 12 freshly built gcc
x86_64 bootstraps from around Dec 5 till now.
Because when I'm not able to reproduce it, I'm hesistant to adding the
testcase...

[Bug preprocessor/59566] [4.8/4.9 regression] g++ preprocessor output includes comments meant for GNU C Library files

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Jakub Jelinek  ---
Yeah, that is not a bug.
With -ffreestanding, -nostdinc or -fpreprocessed  isn't
automatically included, but you then have to deal with the other effects of
those options.

[Bug c++/59567] New: Incorrect error 'was not declared in this scope'

[jascha at jawset dot com]

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

Bug ID: 59567
   Summary: Incorrect error 'was not declared in this scope'
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jascha at jawset dot com

Parent member variables not visible in derived type's c'tor if derived is in
template.
See the example for the exact scenario.

[Bug c++/59567] Incorrect error 'was not declared in this scope'

[jascha at jawset dot com]

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

Jascha Wetzel  changed:

   What|Removed |Added

  Attachment #31486|0   |1
is obsolete||

--- Comment #1 from Jascha Wetzel  ---
Created attachment 31488
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31488&action=edit
reproducing code

[Bug c++/59567] Incorrect error 'was not declared in this scope'

[jascha at jawset dot com]

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

Jascha Wetzel  changed:

   What|Removed |Added

  Attachment #31488|compile simply with "g++|reproducer
description|" |

--- Comment #2 from Jascha Wetzel  ---
Comment on attachment 31488
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31488
reproducer

compile simply with "g++ "

[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #7 from H.J. Lu  ---
[hjl@gnu-mic-2 gcc-regression]$ cat pr59413.c
typedef unsigned int uint32_t;

uint32_t a;
int b;

int
main ()
{
  uint32_t c;
  for (a = 7; a <= 1; a++)
{
  char d = a;
  c = d;
  b = a == c;
}
  if (a != 7)
__builtin_abort ();
  return 0;
}
[hjl@gnu-mic-2 gcc-regression]$
/export/project/git/gcc-regression/master/205883/usr/bin/gcc -S pr59413.c -Os
-o bad.s
[hjl@gnu-mic-2 gcc-regression]$
/export/project/git/gcc-regression/master/205887/usr/bin/gcc -S pr59413.c -Os
-o good.s
[hjl@gnu-mic-2 gcc-regression]$ diff -up bad.s good.s
--- bad.s2013-12-20 04:38:57.810620352 -0800
+++ good.s2013-12-20 04:39:12.476337299 -0800
@@ -8,20 +8,9 @@
 main:
 .LFB0:
 .cfi_startproc
-movlb(%rip), %edx
-movl$7, %eax
-.L2:
-incl%eax
-cmpl$3, %eax
-je.L6
-movl$1, %edx
-jmp.L2
-.L6:
-pushq%rax
-.cfi_def_cfa_offset 16
-movl%edx, b(%rip)
-movl$2, a(%rip)
-callabort
+movl$7, a(%rip)
+xorl%eax, %eax
+ret
 .cfi_endproc
 .LFE0:
 .sizemain, .-main
@@ -31,5 +20,5 @@ main:
 .LHOTE0:
 .commb,4,4
 .comma,4,4
-.ident"GCC: (GNU) 4.9.0 20131211 (experimental) [trunk revision
205883]"
+.ident"GCC: (GNU) 4.9.0 20131211 (experimental) [trunk revision
205887]"
 .section.note.GNU-stack,"",@progbits
[hjl@gnu-mic-2 gcc-regression]$

[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Ah, my fault then, terribly sorry, I've simplified the testcase a little bit
(removed the typedef and used unsigned int instead).  Apparently for the
reproduction it is important that the c variable uses some typedef to unsigned
int rather than that type directly.

[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 #6 from joseph at codesourcery dot com  ---
On Fri, 20 Dec 2013, su at cs dot ucdavis.edu wrote:

> In particular, are the following well-defined according the standard or they
> have undefined behavior? 

In both cases, you are accessing uninitialized padding bits.  ISO C allows 
for the possibility of type punning through unions (in a footnote added in 
C99 TC3, not in normative text), but this is still uninitialized data.  
Whether accesses to uninitialized data are completely undefined behavior, 
or only produce unspecified values in some cases, is less clear.  See 
N1747 and the discussion under DR 451 in the draft Chicago minutes N1764.  
(Your examples concern padding bits in objects with static storage 
duration, rather than uninitialized objects with automatic storage 
duration, but the issues are much the same.)  The general desire is to 
allow optimizations that may mean an uninitialized object does not act as 
if it has any consistent value, without making it undefined behavior to 
call memcpy (for example) on objects that may be only partly initialized.

[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to H.J. Lu from comment #5)
> It is fixed by r205884.  We can add the testcase and close it.

FWIW, it is also introduced by r204516.

[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec 20 13:07:10 2013
New Revision: 206147

URL: http://gcc.gnu.org/viewcvs?rev=206147&root=gcc&view=rev
Log:
PR tree-optimization/59413
* gcc.c-torture/execute/pr59413.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr59413.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/59413] [4.9 Regression] wrong code at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Thanks, testcase committed, so we are all set now.

[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
True, I guess adding -mtune=generic doesn't hurt though, it will be still
broken with --target_board=unix/-mtune=core2 or similar testing, but at least
it will FAIL less often.  For core* tuning the difference is e.g. in reassoc
(different reassoc widths, fairly recent change), and starting with probably
r160636 different IVopts decisions based on different costs.  I believe that is
the only reason for the different number of vector additions.

[Bug tree-optimization/59544] Vectorizing store with negative step

[meibf at gcc dot gnu.org]

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

--- Comment #1 from meibf at gcc dot gnu.org ---
Author: meibf
Date: Fri Dec 20 13:46:01 2013
New Revision: 206148

URL: http://gcc.gnu.org/viewcvs?rev=206148&root=gcc&view=rev
Log:
2013-12-20  Bingfeng Mei  

PR tree-optimization/59544
* tree-vect-stmts.c (perm_mask_for_reverse): Move before
vectorizable_store. 
(vectorizable_store): Handle negative step.

* gcc.target/i386/pr59544.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr59544.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug c++/59315] [4.9 regression] g++.dg/warn/Wunused-3.C FAILs with -fno-use-cxa-atexit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target|*-*-solaris2.*  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-20
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Host|*-*-solaris2.*  |
Summary|[4.9 regression]|[4.9 regression]
   |g++.dg/warn/Wunused-3.C |g++.dg/warn/Wunused-3.C
   |FAILs on Solaris|FAILs with
   ||-fno-use-cxa-atexit
 Ever confirmed|0   |1
  Build|*-*-solaris2.*  |

--- Comment #1 from Jakub Jelinek  ---
This regressed everywhere with -O -Wunused -fno-use-cxa-atexit starting with
r204265, on Solaris that is just the default, while on various other targets it
is not.  mark_used is no longer called on the TREE_STATIC global VAR_DECL,
eventhough it has a non-trivial destructor.  Jason, can you please have a look?

[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Testing

Index: gimplify.c   
=== 
--- gimplify.c  (revision 205891)   
+++ gimplify.c  (working copy)  
@@ -7358,12 +7358,22 @@ gimplify_expr (tree *expr_p, gimple_seq 
TREE_TYPE (*expr_p));   
  break;

+   case VIEW_CONVERT_EXPR: 
+ if (is_gimple_reg_type (TREE_TYPE (*expr_p))  
+ && is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p, 0
+   {   
+ ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,   
+  post_p, is_gimple_val, fb_rvalue);   
+ recalculate_side_effects (*expr_p);   
+ break;
+   }   
+ /* Fallthru.  */  
+   
case ARRAY_REF: 
case ARRAY_RANGE_REF:   
case REALPART_EXPR: 
case IMAGPART_EXPR: 
case COMPONENT_REF: 
-   case VIEW_CONVERT_EXPR: 
  ret = gimplify_compound_lval (expr_p, pre_p, post_p,  
fallback ? fallback : fb_rvalue);   
  break;
@@ -7709,10 +7719,17 @@ gimplify_expr (tree *expr_p, gimple_seq 
  break;

case BIT_FIELD_REF: 
- ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,   
-  post_p, is_gimple_lvalue, fb_either);
- recalculate_side_effects (*expr_p);   
- break;
+ { 
+   if (is_gimple_reg_type (TREE_TYPE (*expr_p))
+   && is_gimple_reg_type (TREE_TYPE (TREE_OPERAND (*expr_p, 0  
+ ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,   
+  post_p, is_gimple_val, fb_rvalue);   
+   else
+ ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,   
+  post_p, is_gimple_lvalue, fb_either);
+   recalculate_side_effects (*expr_p); 
+   break;  
+ } 

case TARGET_MEM_REF:
  {  


code-generation for the testcase is awkward though:

foo:
.LFB0:  
.cfi_startproc
movaps  %xmm0, -24(%rsp)
movq-24(%rsp), %rax
movq%rax, -24(%rsp)
movq-24(%rsp), %xmm0
ret

not sure why RTL cannot recover here, we expand from

foo (uint16x8_t x)
{
  vector(2) long unsigned int _2;
  long unsigned int _3;
  uint8x8_t _4;

  :
  _2 = VIEW_CONVERT_EXPR(x_5(D));
  _3 = BIT_FIELD_REF <_2, 64, 0>;
  _4 = VIEW_CONVERT_EXPR(_3);
  return _4;

with forwprop we could re-write this into

  _4 = BIT_FIELD_REF ;

as BIT_FIELD_REF is allowed to select uint8x8_t from uint16x8_t directly.

[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

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-20
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Zhendong Su from comment #4)
> It would be nice to see that this gets fixed eventually [...] 
> it would be great to see this aspect of compilers
> also gets better to become more "friendly" to beginners (and professionals
> too). 

I think everybody working on GCC would agree with you. But the number of people
working on GCC is very limited and they have a finite amount of time to
dedicate to it. So either you convince new people to start working on GCC or
yourself start contributing. Fixing this bug for example may be easy or may
require some effort, but given that it surely affects very few people using
non-standard code and there are also easy work-arounds, people already working
on GCC will likely spent their time on something else.

If you consider this issue important, just set-up a build environment, launch
gdb and start hacking. You can grep for the error message, set a breakpoint at
the error line and analyze why it is emitted and how you can modify the code to
follow the warning route. If you get it fixed before the end of January, it
will be in GCC 4.9.

Be the change you wish to see!

[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> I believe that is the only reason for the different number of vector 
> additions.

I don't think the number of packed double operations is changed, only the
number of occurrences of the scanned regular expression:

[Book15] f90/bug% gfc -S -mtune=generic -O3 -ffast-math -msse2
-fpredictive-commoning -ftree-vectorize -fdump-tree-optimized
/opt/gcc/work/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
[Book15] f90/bug% egrep "vect_[^\n]*\+ " fast-math-mgrid-resid.f.169t.optimized
| wc -l
  13
[Book15] f90/bug% grep addpd fast-math-mgrid-resid.s | wc -l  
23
[Book15] f90/bug% grep subpd fast-math-mgrid-resid.s | wc -l   
   4
[Book15] f90/bug% grep mulpd fast-math-mgrid-resid.s | wc -l
4
[Book15] f90/bug% gfc -S -O3 -ffast-math -msse2 -fpredictive-commoning
-ftree-vectorize -fdump-tree-optimized
/opt/gcc/work/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
[Book15] f90/bug% egrep "vect_[^\n]*\+ " fast-math-mgrid-resid.f.169t.optimized
| wc -l
  10
[Book15] f90/bug% grep addpd fast-math-mgrid-resid.s | wc -l
23
[Book15] f90/bug% grep subpd fast-math-mgrid-resid.s | wc -l
4
[Book15] f90/bug% grep mulpd fast-math-mgrid-resid.s | wc -l
4

> Well, I don't think configuring with arbitrary --with-cpu/tune is 
> a supported configuration for zero testsuite FAILs ...?

The tested configurations x86_64-apple-darwin* (IIRC defaulting to
--with-arch=core2 --with-cpu=core2) and x86_64-*-* configured with
--with-arch=corei7 --with-cpu=corei7. I also hope forbidden configurations are
rejected (as done for at least some compiling options).

[Bug preprocessor/59566] [4.8/4.9 regression] g++ preprocessor output includes comments meant for GNU C Library files

[gdlxn at us dot ibm.com]

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

--- Comment #3 from gdlxn at us dot ibm.com ---
Richard and Jakub - Thanks for the quick response and explanation.  I was able
to use the -nostdinc option to suppress the automatic inclusion of
, which eliminates the unwanted comments.

[Bug c++/59567] Incorrect error 'was not declared in this scope'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Gcc's behavior is correct as a is not dependent so it is not looked up via a
dependent base class.

[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec 20 16:32:21 2013
New Revision: 206152

URL: http://gcc.gnu.org/viewcvs?rev=206152&root=gcc&view=rev
Log:
PR c++/59255
* g++.dg/tree-prof/pr59255.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-prof/pr59255.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec 20 16:34:21 2013
New Revision: 206153

URL: http://gcc.gnu.org/viewcvs?rev=206153&root=gcc&view=rev
Log:
PR c++/59255
Backported from mainline
2013-08-19  Dehao Chen  

* value-prof.c (gimple_ic): Fix the bug of adding EH edge.

* g++.dg/tree-prof/pr59255.C: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/tree-prof/pr59255.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/value-prof.c

[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug debug/54114] VTA compile-time performance could be improved

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
Summary|[4.8/4.9 Regression]|VTA compile-time
   |variable-tracking   |performance could be
   |performance regression from |improved
   |4.8-20120610 to |
   |4.8-20120701|

--- Comment #10 from Jeffrey A. Law  ---
Removing regression marker based on c#7 and c#8.  Sounds like there's still
work that can be done here, but that the regression aspect is significantly
improved.

[Bug fortran/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
> Isn't that effectively a duplicate of the P1 regression PR57904?

Might well be, I'm not sure. However, the patch posted in PR 57904 comment 9
does not seem to fix the problem here ...

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[dave.anglin at bell dot net]

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

--- Comment #40 from dave.anglin at bell dot net ---
On 12/19/2013 5:53 PM, John David Anglin wrote:
> Rechecking status on the arm box.
Problem is still there:

../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:58:30:
 
fatal error: linux/perf_event.h: No such file or directory
  #include 

[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
So a quick prototype which reuses the infrastructure from the
phi-only-propagator cleans things up quite nicely.

Given this block after substitute_and_fold does its thing:

:
ubound.0_3 = 0;
size.1_4 = ubound.0_3 + 1;
size.1_5 = MAX_EXPR ;
_6 = size.1_5 * 4;
_7 = (character(kind=4)) _6;
_8 = MAX_EXPR <_7, 1>;
sizes_9 = __builtin_malloc (_8);
size.3_10 = MAX_EXPR ;
_11 = size.3_10 * 4;
_12 = (character(kind=4)) _11;
_13 = MAX_EXPR <_12, 1>;
strides_14 = __builtin_malloc (_13);
MEM[(integer(kind=4)[0:D.1917] *)sizes_9][0] = 1;
if (ubound.0_3 > 0)
  goto ;
else
  goto ;


I (manually) seed the phi-only propagator's 2nd step with _3 as being a newly
exposed destination of a copy/constant initialization and let that trivial
propagator do its thing...  Resulting in:

:
sizes_9 = __builtin_malloc (4);
strides_14 = __builtin_malloc (1);
MEM[(integer(kind=4)[0:D.1917] *)sizes_9][0] = 1;
goto ;

Which is exactly what we want.  Also note that we collapse the conditional at
the end of the block.  That in turn makes the problematic loop unreachable and
it goes away as one would expect.

The problem I see is I'd prefer not to expose this in substitute_and_fold
directly.  That routine is used by multiple propagators.  I'm thinking that
instead we can have a callback to the pass utilizing substitute_and_fold that
gets called when something has folded.

[Bug rtl-optimization/56069] [4.7/4.8/4.9 Regression] RA pessimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
Maybe I'm missing something here.  We have this immediately prior to IRA:

(insn 2 4 3 2 (set (reg/v:DI 86 [ mem ])
(reg:DI 5 di [ mem ])) j.c:2 89 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 5 di [ mem ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (parallel [
(set (reg:DI 88 [ D.1760 ])
(lshiftrt:DI (reg/v:DI 86 [ mem ])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) j.c:3 562 {*lshrdi3_1}
 (expr_list:REG_DEAD (reg/v:DI 86 [ mem ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 7 6 8 2 (set (reg:DI 89)
(const_int 17592186044416 [0x1000])) j.c:3 89 {*movdi_internal}
 (nil))
(insn 8 7 13 2 (parallel [
(set (reg:DI 87 [ D.1760 ])
(ior:DI (reg:DI 88 [ D.1760 ])
(reg:DI 89)))
(clobber (reg:CC 17 flags))
]) j.c:3 421 {*iordi_1}
 (expr_list:REG_DEAD (reg:DI 89)
(expr_list:REG_DEAD (reg:DI 88 [ D.1760 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ior:DI (reg:DI 88 [ D.1760 ])
(const_int 17592186044416 [0x1000]))
(nil))
(insn 13 8 16 2 (set (reg/i:DI 0 ax)
(reg:DI 87 [ D.1760 ])) j.c:4 89 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 87 [ D.1760 ])
(nil)))
(insn 16 13 0 2 (use (reg/i:DI 0 ax)) j.c:4 -1
 (nil))

ISTM that we want (reg 86) to prefer di and (reg 87) to prefer ax by way of the
hard register copies.  (reg 88) should then prefer di by way of insn 6.

(reg 89) really doesn't need a preference and can go anywhere that doesn't
conflict.

So if we look at the IRA dump we have:

Pass 1 for finding pseudo/allocno costs

r89: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r88: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r87: preferred AREG, alternative GENERAL_REGS, allocno GENERAL_REGS
r86: preferred DIREG, alternative GENERAL_REGS, allocno GENERAL_REGS

Which I guess is OK.  A bit surprised to not see r88 preferring DIreg at this
point, but I guess copies implied by the 2 operand nature are handled later.

ISTM that the copy implied by insn 6 should result in 88 somehow preferring
DIreg.  Then, ideally we'd see that while 89 can go anywhere it's best to match
it with 87.

Vlad, what am I missing here?

[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
*** Bug 58746 has been marked as a duplicate of this bug. ***

[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Dominique d'Humieres  ---
Fixed by the patch in pr57904 comment 9. Marked as duplicate.

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

[Bug c++/59568] New: complex type operator>> does not set eofbit for input streams.

[Physeterm at yahoo dot com]

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

Bug ID: 59568
   Summary: complex type operator>> does not set eofbit for input
streams.
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Physeterm at yahoo dot com

Created attachment 31489
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31489&action=edit
g++ -v

(Actually, it is set, it's just cleared before the return to caller)

The problem as I understand it is that the call to __is.putback(__ch)
resets the eofbit to 0, (in C++11) after a valid eof has been detected.
The next extraction operation fails on attempting to get a char type
but the eofbit is not set to 1.

This precludes the ability to do error checking on input files.

A simple solution I think would be to test for the eofbit before
attempting the putback. ie:

   else 
   {
  if (! __is.eof()) {
 __is.putback(__ch);
 __is >> __re_x;
 __x = __re_x;
  }
   }
   return __is;
}

in file /usr/include/c++/4.8.1/complex (This only fixes int types)

[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
> For the FE change, I guess most important are benchmark results, 
> doesn't it slow down important benchmarks?

AFAICT the answer is not at least for the gfortran test suite and the
polyhedron ones
(pb05, pb11, and my own variants).

May be Joost can do more testing for CP2K.

[Bug c++/59568] complex type operator>> does not set eofbit for input streams.

[Physeterm at yahoo dot com]

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

--- Comment #1 from Physeterm at yahoo dot com ---
Created attachment 31490
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31490&action=edit
test program

[Bug c++/59568] complex type operator>> does not set eofbit for input streams.

[Physeterm at yahoo dot com]

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

--- Comment #2 from Physeterm at yahoo dot com ---
Created attachment 31491
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31491&action=edit
input test file

[Bug c++/59568] complex type operator>> does not set eofbit for input streams.

[Physeterm at yahoo dot com]

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

--- Comment #3 from Physeterm at yahoo dot com ---
Created attachment 31492
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31492&action=edit
output

[Bug c++/59568] complex type operator>> does not set eofbit for input streams.

[Physeterm at yahoo dot com]

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

--- Comment #4 from Physeterm at yahoo dot com ---
Created attachment 31493
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31493&action=edit
make command

[Bug fortran/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> (In reply to Tobias Burnus from comment #1)
> > Isn't that effectively a duplicate of the P1 regression PR57904?
>
> Might well be, I'm not sure. However, the patch posted in PR 57904 comment 9 
> does not seem to fix the problem here ...

I don't think it is a duplicate and I think the warning is correct (on
x86_64-apple-darwin13 I get it with/without SAVE and with/without the patch in
PR 57904 comment 9).
Too bad that the warning is emitted twice and the iteration count starts at 0
and not at one as in first (IMHO #iterations=end-start+1, i.e., 5).

[Bug middle-end/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at redhat dot com
  Component|fortran |middle-end

--- Comment #4 from Dominique d'Humieres  ---
I think it is a middle-end issue.

[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
Dominique, thanks for verifying that 58746 is a duplicate.  I was wondering
about that.

Richi, we've known for a long time (since the early 90s) that running CSE soon
after loop unrolling is profitable.  S, why not run conditionally run DOM
after unrolling?   That wouldn't create a compile-time hit for a typical -O2
compilation.

[Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[law at redhat dot com]

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

--- Comment #18 from Jeffrey A. Law  ---
Whoops, message for Richi was meant for a different BZ.

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

[marxin.liska at gmail dot com]

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

--- Comment #9 from Martin Liška  ---
Hello,
   thank you for the hotfix that repaired switch/case missing return value.

Actually I was told by Jan to reproduce the functionality from varasm.c that I
was able to bootstrap and test.

The idea of reordering pass is to order all functions that are seen during
instrumentation run and are executed during start-up of an application.

So that, we do not build separate sections for .text, .text.hot and
.text.startup. On the other hand: any execute function should not live in
.text.unlikely and .text.startup. If so, it means that we miss profile info and
these functions can be identified during debugging process.

I am not familiar with darwin format, Jan do you know what could cause problem?

[Bug rtl-optimization/56069] [4.7/4.8/4.9 Regression] RA pessimization

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
(In reply to Jeffrey A. Law from comment #5)
> Maybe I'm missing something here.  We have this immediately prior to IRA:
> 

> ISTM that we want (reg 86) to prefer di and (reg 87) to prefer ax by way of
> the hard register copies.  (reg 88) should then prefer di by way of insn 6.
> 
> (reg 89) really doesn't need a preference and can go anywhere that doesn't
> conflict.
> 
> So if we look at the IRA dump we have:
> 
> Pass 1 for finding pseudo/allocno costs
> 
> r89: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
> r88: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
> r87: preferred AREG, alternative GENERAL_REGS, allocno GENERAL_REGS
> r86: preferred DIREG, alternative GENERAL_REGS, allocno GENERAL_REGS
> 
> Which I guess is OK.  A bit surprised to not see r88 preferring DIreg at
> this point, but I guess copies implied by the 2 operand nature are handled
> later.
> 
> ISTM that the copy implied by insn 6 should result in 88 somehow preferring
> DIreg.  Then, ideally we'd see that while 89 can go anywhere it's best to
> match it with 87.
> 
> Vlad, what am I missing here?

Preferred/alternative class is misleading here.  It is not used anywhere in
IRA/LRA for allocation decision (but may be it is used by reload -- i don't
remember).  It is only used as a temporary result for allocno class
calculation.

Hard reg preferences and copies are further in the dump.  They looks as
following

cp0:a2(r88)<->a3(r86)@1000:constraint
cp1:a0(r87)<->a1(r89)@1000:constraint
cp2:a0(r87)<->a2(r88)@1000:constraint
pref0:a0(r87)<-hr0@1500
pref1:a3(r86)<-hr5@1500

This problem is well known me.  Jakub filled analogous PR.  I am working on it.
 The reason of the problem are copies created for commutative ops insns.  Two
copies give different signals for hard reg preferences through the propagation
mechanism.  It is easy to make a test for this problem because the test should
be small and involve arguments and result on small number of insns.  Therefore
we have a few such PRs.  In bigger function, the probability of the problem
occurrence is quite small.

[Bug fortran/37336] [F03] Finish derived-type finalization

[janus at gcc dot gnu.org]

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

--- Comment #27 from janus at gcc dot gnu.org ---
>From http://gcc.gnu.org/ml/fortran/2013-12/msg00104.html ...

Currently missing are:

a) Finalization of the LHS during intrinsic assignment:
b) Finalization of functions results after their use
c) Finalization of structure/array constructors after their use.

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-20
Summary|[F2008] Add IS_CONTIGUOUS   |[F08] Add IS_CONTIGUOUS
   |intrinsic   |intrinsic
 Ever confirmed|0   |1

[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 #10 from Dominique d'Humieres  ---
> Hello,
>   thank you for the hotfix that repaired switch/case missing return value.

Nothing has been committed yet to fix darwin bootstrap!-(

[Bug middle-end/59569] New: [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294

[hjl.tools at gmail dot com]

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

Bug ID: 59569
   Summary: [4.9 Regression] r206148 causes internal compiler
error: in vect_create_destination_var, at
tree-vect-data-refs.c:4294
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: bmei at broadcom dot com

When compiling 253.perlbmk from SPEC CPU 2K on Linux/x86-64,
I got

[hjl@gnu-mic-2 0001]$
/export/project/git/gcc-regression/master/206150/usr/bin/gcc -c -o pp.o  
-DSPEC_CPU2000_LP64 -DSPEC_CPU2000_LINUX_I386 -DSPEC_CPU2000_NEED_BOOL
-DSPEC_CPU2000_GLIBC22-O3 -funroll-loops -ffast-math   pp.c
In file included from perl.h:1090:0,
 from pp.c:16:
handy.h:71:0: warning: "bool" redefined [enabled by default]
 #  define bool char
 ^
In file included from config.h:1:0,
 from perl.h:137,
 from pp.c:16:
spec_config.h:160:0: note: this is the location of the previous definition
 #define bool int
 ^
In file included from perl.h:2121:0,
 from pp.c:16:
pp.c: In function \u2018Perl_pp_splice\u2019:
embed.h:759:20: internal compiler error: in vect_create_destination_var, at
tree-vect-data-refs.c:4294
 #define pp_splice  Perl_pp_splice
^
pp.h:20:20: note: in definition of macro \u2018PP\u2019
 #define PP(s) OP * s(ARGSproto)
^
pp.c:2687:4: note: in expansion of macro \u2018pp_splice\u2019
 PP(pp_splice)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-mic-2 0001]$

[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Created attachment 31494
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31494&action=edit
A testcase

[hjl@gnu-mic-2 0001]$
/export/project/git/gcc-regression/master/206150/usr/bin/gcc -S -O3
-funroll-loops -ffast-math pr59569.c 
pr59569.c: In function ‘Perl_pp_splice’:
pr59569.c:7304:6: internal compiler error: in vect_create_destination_var, at
tree-vect-data-refs.c:4294
 OP * Perl_pp_splice(void)
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-mic-2 0001]$

[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-21
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug c++/59570] New: Warning for semicolon trailing closing curly brackets

[eugene.zelenko at gmail dot com]

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

Bug ID: 59570
   Summary: Warning for semicolon trailing closing curly brackets
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com

Hi!

I think will be great to have warning when useless semicolon trails closing
curly bracket (closing function definition or code block). Same should be done
for C.

Eugene.

[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
254.gap in SPEC CPU 2K is also failed.

[Bug c++/59571] New: [C++11] ICE when casting inside static member constexpr brace initializer

[bruck.michael at googlemail dot com]

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

Bug ID: 59571
   Summary: [C++11] ICE when casting inside static member
constexpr brace initializer
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruck.michael at googlemail dot com

$ cat ice.cpp
template 
struct foo
{
static constexpr int bar{(int)-1};
};

$ g++ -std=c++11 -c ice.cpp
ice.cpp:4:37: internal compiler error: unexpected expression ‘(int)((-1))’ of
kind cast_expr
 static constexpr int bar{(int)-1};
 ^

ice.cpp:4:37: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
...

$ g++ --version
g++ (GCC) 4.8.2
...