[Bug preprocessor/61613] ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name

[potswa at mac dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613

--- Comment #4 from David Krauss  ---
Created attachment 33288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33288&action=edit
Fix

Well, I decided to Do The Right Thing for users. Here is a working patch.

Let's see what the maintainers do with it :) .

[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Mon Aug 11 07:49:30 2014
New Revision: 213809

URL: https://gcc.gnu.org/viewcvs?rev=213809&root=gcc&view=rev
Log:
2014-08-11  Richard Biener  

PR fortran/61950
* trans-expr.c (gfc_conv_structure): Initialize _size with
a value of proper type.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c

[Bug fortran/62044] [4.8/4.9/4.10 Regression] ICE in USE statement with RENAME for extended derived type

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
  Known to work||4.4.7
Summary|ICE in USE statement with   |[4.8/4.9/4.10 Regression]
   |RENAME for extended derived |ICE in USE statement with
   |type|RENAME for extended derived
   ||type
 Ever confirmed|0   |1
  Known to fail||4.10.0, 4.5.4, 4.8.3, 4.9.1

--- Comment #1 from Dominique d'Humieres  ---
The code compiles with gfortran 4.4.7, but not with 4.5.4 up to trunk (4.10).

[Bug lto/62067] lto-lang.c:549: too many calls to va_end on some code paths ?

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62067

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/62081] [4.10 Regression] ICE: in fix_loop_structure, at loop-init.c:208 with -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts -fno-tree-reassoc -fno-tree-sink

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62081

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/62079] [4.9/4.10 Regression] ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62079

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.2
 Ever confirmed|0   |1

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

[Bug middle-end/62078] [4.10 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62078

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077

Richard Biener  changed:

   What|Removed |Added

   Keywords||build, lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
 CC|richard.guenther at gmail dot com  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Btw, I can confirm the issue for the 4.9 branch (with release checking).

[Bug ipa/62016] [4.8/4.9/4.10 Regression] very slow compilation at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The regression in 4.8 started with r193161.

[Bug tree-optimization/62075] [4.8/4.9/4.10 Regression] Vectorizer ICE on dolphin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62075

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2014-08-11
 Resolution|DUPLICATE   |---
   Target Milestone|--- |4.8.4
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I don't think this is a dup.  Confirmed.

[Bug tree-optimization/62075] [4.8/4.9/4.10 Regression] Vectorizer ICE on dolphin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62075

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
The issue here is that we have a load group with one stmt feeding a condition. 
For some reason we think that we can support vectorizing

_7 = _4 != 0

with _4 being defined by a pure-SLP def.  Which looks odd - the this is clearly
not a pure SLP node!

Fix:

Index: tree-vect-slp.c
===
--- tree-vect-slp.c (revision 213809)
+++ tree-vect-slp.c (working copy)
@@ -1793,7 +1793,8 @@ vect_detect_hybrid_slp_stmts (slp_tree n
&& (stmt_vinfo = vinfo_for_stmt (use_stmt))
&& !STMT_SLP_TYPE (stmt_vinfo)
 && (STMT_VINFO_RELEVANT (stmt_vinfo)
-|| VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_vinfo)))
+|| VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_vinfo))
+   || STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
&& !(gimple_code (use_stmt) == GIMPLE_PHI
  && STMT_VINFO_DEF_TYPE (stmt_vinfo)
   == vect_reduction_def))

[Bug middle-end/61927] [4.9/4.10 Regression] Wrong results with loop vectorization of: "var[i] = ABS_EXPR > 9.9e-7"

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61927

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
I see result differences and valgrind errors starting with r167220 , then
r183757 fixed that (all options).
Then r196872 regressed this again for the vectorizer.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #4 from Richard Biener  ---
Also fails with the 4.9.0 release on x86_64.

[Bug c++/62072] [4.9/4.10 regression] No SFINAE performed for function type

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62072

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |4.9.2

[Bug middle-end/61486] ICE with #pragma omp teams

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61486

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/62085] SFINAE where specialization parameter class member returns an abstract type fails

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62085

--- Comment #2 from Jonathan Wakely  ---
For a short piece of code with no external dependencies it's simpler to just
paste it into a comment than attach it:

template
struct A {
  T f();
};

template struct B {};
template struct B::type> {};

struct C {
  virtual ~C() = 0;
};

int main() {
  B();
}


EDG rejects it for the same reason as GCC.

[Bug fortran/60928] gfortran issue with allocatable components and OpenMP

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Should be fixed in trunk and 4.9.1+.

[Bug libstdc++/62082] cout fails to work with auto variable initialized with curvy brackets

[aleksej.penkov at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62082

Aleksej  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
   Severity|normal  |trivial

--- Comment #3 from Aleksej  ---
Not a bug according to the note from Daniel Krügler.

[Bug c++/60228] ICE using lambda in #pragma omp declare reduction

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228

--- Comment #1 from Jakub Jelinek  ---
I would not call this valid, because OpenMP 4.0 doesn't support C++11, thus
using C++11 constructs inside of OpenMP constructs is invalid.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,

[venkataramanan.kumar at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077

--- Comment #5 from Venkataramanan  ---
(In reply to Richard Biener from comment #4)
> Also fails with the 4.9.0 release on x86_64.

Also fails with the GCC 4.9 on Aarch64 target.

[Bug fortran/62087] New: A Piece of code compiling with ifort but giving error by gfortran 4.8

[kushwaha.sumit8 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62087

Bug ID: 62087
   Summary: A Piece of code compiling with ifort but giving error
by gfortran 4.8
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kushwaha.sumit8 at gmail dot com

A have following Piece of code which is a part of forecast model


subroutine ESMF_GridCompSetEntryPoint (comp, subroutineType, subroutineName,
phase, rc)

  type(ESMF_GridComp) :: comp
  character(*), intent(in) :: subroutineType
  interface
subroutine subroutineName (comp, importState, exportState, clock,
rc)

type(ESMF_GridComp), INTENT(inout) :: comp
type(ESMF_State) :: importState, exportState
type(ESMF_Clock) :: clock
integer, intent(out) :: rc
end subroutine
  end interface
  integer, intent(in) :: phase
  integer, intent(out) :: rc
end subroutine


TYPE(ESMF_GridComp), INTENT(inout)  :: gcGFS
INTEGER, INTENT(out):: rc1
CALL ESMF_GridCompSetEntryPoint (gcGFS, ESMF_SETINIT,  Initialize,  &
  ESMF_SINGLEPHASE, rc1)

SUBROUTINE Initialize(gcGFS, impGFS, expGFS, clock, rc)
 TYPE(ESMF_GridComp), INTENT(inout) :: gcGFS
 TYPE(ESMF_State),INTENT(inout) :: impGFS
 TYPE(ESMF_State),INTENT(inout) :: expGFS
 TYPE(ESMF_Clock),INTENT(inout) :: clock

 INTEGER, INTENT(out)   :: rc

...
...
...
END SUBROUTINE Initializ

when compiling with using mpif90 -f90=/garuda/GARUDA/gcc48/bin/gfortran
I am getting following error

 CALL ESMF_GridCompSetEntryPoint (gcGFS, ESMF_SETINIT,  Initialize,  &
1
Error: Interface mismatch in dummy procedure 'subroutinename' at (1): INTENT
mismatch in argument 'comp'

[Bug ipa/62016] [4.8/4.9/4.10 Regression] very slow compilation at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016

--- Comment #6 from Jakub Jelinek  ---
In 4.9/trunk I think the compile time improved with r208831 , though I was
testing tiny bit different testcase - if (p1 != 0) __builtin_abort ();
instead of assert (p1 == 0);, nevertheless, r208830 took at -O3 still over 13
minutes before I've killed it, r208831 only 3 minutes and something.

[Bug c/62070] ICE: verify_ssa failed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62070

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[4.10 Regression] ICE:  |ICE: verify_ssa failed
   |verify_ssa failed   |
  Known to fail||4.10.0, 4.6.4, 4.7.4,
   ||4.8.3, 4.9.1

--- Comment #3 from Richard Biener  ---
Fails since 4.6 at least.  Predictive commoning gets confused.  Not sure if
really a regression.  Note that you need checking enabled.

We end up here

static void
execute_pred_commoning_chain (struct loop *loop, chain_p chain,
 bitmap tmp_vars)
{
  unsigned i;
  dref a;
  tree var;

  if (chain->combined)
{
  /* For combined chains, just remove the statements that are used to
 compute the values of the expression (except for the root one).  */
  for (i = 1; chain->refs.iterate (i, &a); i++)
remove_stmt (a->stmt);

failing to realize that unrolling may end up creating new PHIs.

Note that predcom does just fine in the end - it just is "broken" by
the intermittent verification in gimple_duplicate_loop_to_header_edge.
That is already skipped in some cases so just remove it completely now.

[Bug tree-optimization/62070] ICE: verify_ssa failed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62070

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Aug 11 10:55:10 2014
New Revision: 213810

URL: https://gcc.gnu.org/viewcvs?rev=213810&root=gcc&view=rev
Log:
2014-08-11  Richard Biener  

PR tree-optimization/62070
* tree-ssa-loop-manip.c (gimple_duplicate_loop_to_header_edge):
Remove SSA checking.

* gcc.dg/pr62070.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr62070.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-manip.c

[Bug tree-optimization/62070] ICE: verify_ssa failed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62070

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|c   |tree-optimization
  Known to work||4.10.0
 Resolution|--- |FIXED
  Known to fail|4.10.0  |

--- Comment #4 from Richard Biener  ---
Fixed on trunk.

[Bug c/62069] [GCC-4.10.1] ICE: in int_cst_value, at tree.c:10625

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62069

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  cst_and_fits_in_hwi is odd.  And there are way too many users of
it...

[Bug c/62073] Segmentation fault with tree vectorize

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62073

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Mon Aug 11 11:24:35 2014
New Revision: 213812

URL: https://gcc.gnu.org/viewcvs?rev=213812&root=gcc&view=rev
Log:
2014-08-11  Felix Yang  

PR tree-optimization/62073
* tree-vect-loop.c (vect_is_simple_reduction_1): Check that DEF1 has
a basic block.

* gcc.dg/vect/pr62073.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr62073.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug c/62073] Segmentation fault with tree vectorize

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62073

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug c/62088] New: [GCC-4.10.1] Compilation failed to produce executable: torture with -fsanitize=address

[sabrinadfs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62088

Bug ID: 62088
   Summary: [GCC-4.10.1] Compilation failed to produce executable:
torture with -fsanitize=address
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sabrinadfs at gmail dot com

GCC-4.10.0 (trunk)
x86_64-apple-darwin11.4.2

Running the following test:
make -s -C gcc check-gcc RUNTESTFLAGS="dg-torture.exp=pr44050.c
--target_board=unix/-fsanitize=address"

GCC produced these error messages:

FAIL: gcc.dg/torture/pr44050.c   -O0  (test for excess errors)
Excess errors:
ld: library not found for -lasan

UNRESOLVED: gcc.dg/torture/pr44050.c   -O0  compilation failed to produce
executable
Executing on host: /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O1  -fno-tree-pta 
-lm   -fsanitize=address  -o ./pr44050.exe(timeout = 300)
spawn /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -fno-tree-pta -lm
-fsanitize=address -o ./pr44050.exe
ld: library not found for -lasan
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
ld: library not found for -lasan
collect2: error: ld returned 1 exit status

FAIL: gcc.dg/torture/pr44050.c   -O1  (test for excess errors)
Excess errors:
ld: library not found for -lasan

UNRESOLVED: gcc.dg/torture/pr44050.c   -O1  compilation failed to produce
executable
Executing on host: /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O2  -fno-tree-pta 
-lm   -fsanitize=address  -o ./pr44050.exe(timeout = 300)
spawn /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fno-tree-pta -lm
-fsanitize=address -o ./pr44050.exe
ld: library not found for -lasan
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
ld: library not found for -lasan
collect2: error: ld returned 1 exit status

FAIL: gcc.dg/torture/pr44050.c   -O2  (test for excess errors)
Excess errors:
ld: library not found for -lasan

UNRESOLVED: gcc.dg/torture/pr44050.c   -O2  compilation failed to produce
executable
Executing on host: /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O3
-fomit-frame-pointer  -fno-tree-pta  -lm   -fsanitize=address  -o ./pr44050.exe
   (timeout = 300)
spawn /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fomit-frame-pointer
-fno-tree-pta -lm -fsanitize=address -o ./pr44050.exe
ld: library not found for -lasan
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
ld: library not found for -lasan
collect2: error: ld returned 1 exit status

FAIL: gcc.dg/torture/pr44050.c   -O3 -fomit-frame-pointer  (test for excess
errors)
Excess errors:
ld: library not found for -lasan

UNRESOLVED: gcc.dg/torture/pr44050.c   -O3 -fomit-frame-pointer  compilation
failed to produce executable
Executing on host: /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never-O3 -g  -fno-tree-pta
 -lm   -fsanitize=address  -o ./pr44050.exe(timeout = 300)
spawn /Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/xgcc
-B/Users/sabrinasouto/Downloads/gcc_trunk/objdir/gcc/
/Users/sabrinasouto/Downloads/gcc_trunk/trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -g -fno-tree-pta -lm
-fsanitize=address -o ./pr44050.exe
ld: library not found for -lasan
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
ld: lib

[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025

--- Comment #3 from Jakub Jelinek  ---
Note, when I replace the if+abort with a printout of all the 8 c.h[] values and
take a poll of the results from:
./cc1.208700 -m31 -O0 sha.c -o sha0.s -quiet -nostdinc
./cc1.207604 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10 sha.c -o sha1.s
./cc1.207605 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10 sha.c -o sha2.s
./cc1.207604 -nostdinc -quiet -O2 -mno-lra -m31 -march=z196 -mtune=z10 sha.c -o
sha3.s
./cc1.207605 -nostdinc -quiet -O2 -m31 -march=z196 -mno-lra -mtune=z10 sha.c -o
sha4.s
/usr/src/gcc/objz/gcc/cc1 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10
sha.c -o sha5.s
/usr/src/gcc/objz/gcc/cc1 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10
sha.c -o sha6.s -mno-lra
where /usr/src/gcc/objz/gcc/cc1 is trunk from around Aug 5th, I get different
results from the testcase, and also if I remove the last line or two lines from
the loop in the function.  But which function have different result from the
-O0 results depends on how many lines are removed.
With no lines removed (G for results matching -O0, B for different result):
GGBGBBB
With the last line removed the results are GBGBBGB.
With the last two lines removed GBGBBGG, when 3 or more lines from the loop are
removed, all results are the same (i.e. all Gs).
As I believe the testcase doesn't have undefined behavior with any of the loop
lines removed, this shows that perhaps the shrink wrapping case just changed
things big enough that some RA or later issue either started appearing, or went
away.

[Bug c++/36961] fails to identify template

[vanyacpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961

Ivan Sorokin  changed:

   What|Removed |Added

 CC||vanyacpp at gmail dot com

--- Comment #7 from Ivan Sorokin  ---
(In reply to Andrew Pinski from comment #4)
> The error is correct as the type of v2 is foo so it cannot figure out the
> rest of the template agruments from that type.

I reduced the case and tested it on other compilers. clang, icc and msvc all
accept this code. The only compiler that reject this code is gcc. I don't know
if is code is conforming to C++ standard. In any case I think behavior of other
compilers is reasonable.

template
struct temp1
{};

template class node>
struct temp2 {};

struct foo : public temp2 {};

template class Temp1,
 template class> class Temp2>
void f(Temp2 v);

int main()
{
f(temp2());
f(foo());
}

[Bug c++/36961] fails to identify template

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
 Ever confirmed|0   |1

--- Comment #8 from Jonathan Wakely  ---
I don't see any reason this shouldn't compile.

[Bug c++/36961] fails to identify template

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961

--- Comment #9 from Jonathan Wakely  ---
For completeness, trunk says this for the reduced testcase in comment 7:

d.cc: In function ‘int main()’:
d.cc:17:12: error: no matching function for call to ‘f(foo)’
 f(foo());
^
d.cc:12:6: note: candidate: template class Temp1,
template class > class Temp2> void
f(Temp2)
 void f(Temp2 v);
  ^
d.cc:12:6: note:   template argument deduction/substitution failed:
d.cc:17:12: note:   can't deduce a template for ‘Temp2’ from
non-template type ‘foo’
 f(foo());
^

[Bug sanitizer/62089] Sanitizer may fail to instrument struct accesses

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62089

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov  ---
Created attachment 33289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33289&action=edit
Proposed patch

Attached a simple patch which seems to fix the problem. Bootstrap and regtests
passed but I want to test Asan-bootstrap as well. I'll then send patch for
review to gcc-patches.

[Bug sanitizer/62089] New: Sanitizer may fail to instrument struct accesses

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62089

Bug ID: 62089
   Summary: Sanitizer may fail to instrument struct accesses
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: y.gribov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Asan does not emit memory checks in copy_fs_struct function and thus fails to
detect invalid access (the code based upon fs_struct.c from Linux kernel):

#include 

struct vfsmount {};
struct dentry {};

struct path {
  struct vfsmount *mnt;
  struct dentry *dentry;
};

struct fs_struct {
  int users;
  int lock;
  int seq;
  int umask;
  int in_exec;
  struct path root, pwd;
};

void __attribute__((noinline, noclone))
copy_fs_struct(struct fs_struct *a, struct fs_struct *b) {
  a->root = b->root;
}

struct fs_struct a, b;

int
main () {
  __asan_poison_memory_region (&a.root, sizeof (a.root));
  copy_fs_struct (&a, &b);
  return 0;
}

[Bug target/62011] False Data Dependency in popcnt instruction

[ysrumyan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #6 from Yuri Rumyantsev  ---
I don't see any issues with 'false dependency' on HSW. I've got sep data on it:

for unsigned veriant (with LEA instructions):

0x400b30 52 161 lea0x1(%rdx),%ecx 
0x400b33 53 0 popcnt (%rbx,%rax,8),%rax 
0x400b39 54 353 lea0x2(%rdx),%r8d 
0x400b3d 55 0 popcnt (%rbx,%rcx,8),%rcx 
0x400b43 56 170 add%rax,%rcx 
0x400b46 57 25 lea0x3(%rdx),%esi 
0x400b49 58 332 popcnt (%rbx,%r8,8),%rax 
0x400b4f 59 196 add%rax,%rcx 
0x400b52 60 199 popcnt (%rbx,%rsi,8),%rax 
0x400b58 61 235 add%rax,%rcx 
0x400b5b 62 414 lea0x4(%rdx),%eax 
0x400b5e 63 0 add%rcx,%r14 
0x400b61 64 312 mov%rax,%rdx 
0x400b64 65 0 cmp%rax,%r12 
0x400b67 66 0 ja 400b30  

and we don't see any performance anomaly with popcnt.

But for 2nd loop we have

0x400c50 118 0 popcnt -0x8(%rdx),%rax 
0x400c56 119 0 popcnt (%rdx),%rcx 
0x400c5b 120 1086 add%rax,%rcx 
0x400c5e 121 492 popcnt 0x8(%rdx),%rax 
0x400c64 122 3 add%rcx,%rax 
0x400c67 123 507 add$0x20,%rdx 
0x400c6b 124 0 popcnt -0x10(%rdx),%rcx 
0x400c71 125 955 add%rax,%rcx 
0x400c74 126 479 add%rcx,%r13 
0x400c77 127 489 cmp%rsi,%rdx 
0x400c7a 128 0 jne400c50 

So far I can't imagine what the problem is.

[Bug tree-optimization/62075] [4.8/4.9/4.10 Regression] Vectorizer ICE on dolphin

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62075

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Aug 11 14:48:24 2014
New Revision: 213815

URL: https://gcc.gnu.org/viewcvs?rev=213815&root=gcc&view=rev
Log:
2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

* gcc.dg/vect/pr62075.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug target/61413] __ARM_SIZEOF_WCHAR_T is constant 32 -- should be 4 or 2

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61413

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-11
 CC||ramana at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ramana at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.0, 4.8.1, 4.8.2, 4.8.3,
   ||4.9.0, 4.9.1

--- Comment #1 from Ramana Radhakrishnan  ---
ARM ACLE mandates this, not ARM EABI.

Confirmed and broken everywhere. Simple fix in progress.

regards
Ramana

[Bug tree-optimization/61743] [4.10 Regression] Complete unroll is not happened for loops with short upper bound

[ysrumyan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743

--- Comment #8 from Yuri Rumyantsev  ---
Richard,

I tested both proposed fixes and i turned out that the first one is preferable
since performance of benchmark came back. Note that hoisting 2nd vrp pass gave
us another 14% slowdown but I did not investigate it.

Should I tested your fix or you do it yourself?

Thanks.

[Bug fortran/62087] A Piece of code compiling with ifort but giving error by gfortran 4.8

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62087

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
There insufficient and clear code to reproduce the issue.
Please attach a complete self-contained example.

[Bug c/62090] New: ice in compute_may_aliases

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62090

Bug ID: 62090
   Summary: ice in compute_may_aliases
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

For the attached code, compiled by gcc trunk dated 20140810,
the following crash message is produced

$ ../results/bin/gcc -std=gnu99 -O2 -c bug158.c
connection.c: In function ‘log_bad_request.isra.5’:
connection.c:679:1: internal compiler error: in compute_may_aliases, at
tree-ssa-structalias.c:7003
0xb02406 compute_may_aliases()
../../src/trunk/gcc/tree-ssa-structalias.c:7003
0x8bddb4 execute_function_todo
../../src/trunk/gcc/passes.c:1721
0x8be6cb do_per_function
../../src/trunk/gcc/passes.c:1476
0x8be6cb execute_todo
../../src/trunk/gcc/passes.c:1806
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$

Compiler flags -std=gnu99 -O2 required.

[Bug c/62090] ice in compute_may_aliases

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62090

--- Comment #1 from David Binderman  ---
Created attachment 33290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33290&action=edit
C source code

[Bug c++/62091] New: ice in before_dom_children

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091

Bug ID: 62091
   Summary: ice in before_dom_children
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 33291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33291&action=edit
C++ source code

For the attached code, compiled by gcc trunk dated 20140810,
the following crash message is produced

$ ../results/bin/gcc -c -O2 bug159.cc
snmpmsg.cpp: In member function ‘int
Snmp_pp::SnmpMessage::unload(Snmp_pp::Pdu&, Snmp_pp::OctetStr&,
Snmp_pp::snmp_version&, Snmp_pp::OctetStr*, Snmp_pp::OctetStr*, long int*,
Snmp_pp::UdpAddress*, Snmp_pp::Snmp*)’:
snmpmsg.cpp:540:5: internal compiler error: in before_dom_children, at
tree-ssa-pre.c:4411
0xbd423c eliminate_dom_walker::before_dom_children(basic_block_def*)
../../src/trunk/gcc/tree-ssa-pre.c:4411
0xf59987 dom_walker::walk(basic_block_def*)
../../src/trunk/gcc/domwalk.c:177
0xbd1332 eliminate
../../src/trunk/gcc/tree-ssa-pre.c:4526
0xbd253c execute
../../src/trunk/gcc/tree-ssa-pre.c:4941
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$  

Compiler flag -O2 required.

[Bug tree-optimization/62091] ice in before_dom_children

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
 CC||hubicka at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
  Component|c++ |tree-optimization
Version|4.9.2   |4.10.0
   Target Milestone|--- |4.10.0
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r213739.

markus@x4 tmp % cat bug159.cc
class SnmpSyntax
{
public:
  virtual SnmpSyntax *m_fn1 () const;
  ~SnmpSyntax () {}
  virtual SnmpSyntax &operator=(const SnmpSyntax &);
};

class A : public SnmpSyntax
{
public:
  A (int);
  SnmpSyntax *m_fn1 () const {}
  SnmpSyntax &operator=(const SnmpSyntax &);
};
int a;
void fn1 ()
{
  for (;; a++)
switch (0)
case 0:
  {
A b (0);
SnmpSyntax &c = b;
c.m_fn1 ();
  }
}

[Bug preprocessor/62086] A bug with option -fextended-identifiers

[pangbw at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086

--- Comment #2 from baoshan  ---
Are you sure \u00A8\u00AA\u00AD\u00AF\u00B2\u00B5 is invalid for C++ standard?
or it is just invalid for GCC now?
I extracted this code from a C++ test suite, and I think it should be valid for
C++11.

[Bug other/62092] New: libgomp.c++/target-2.C FAIL while compiling for OpenMP 4.0 offload target

[iverbin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62092

Bug ID: 62092
   Summary: libgomp.c++/target-2.C FAIL while compiling for OpenMP
4.0 offload target
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iverbin at gmail dot com

To reproduce using trunk gcc:
g++ -fopenmp libgomp/testsuite/libgomp.c++/target-2.C
testsuite/libgomp.c++/target-2-aux.cc

GIMPLE after ompexp phase:

double fn2(...)
{
  br.21_76 = &b; /* Ok.  */
  .omp_data_arr.33.br = &br;
  __builtin_GOMP_target (-1, _Z3fn2iRA1024_dRPd._omp_fn.0, &__OPENMP_TARGET__,
22, &.omp_data_arr.33, &.omp_data_sizes.34, &.omp_data_kinds.35);
}

_Z3fn2iRA1024_dRPd._omp_fn.0 (struct .omp_data_t.30 * .omp_data_i)
{
  __builtin_GOMP_parallel (_Z3fn2iRA1024_dRPd._omp_fn.1, &.omp_data_o.32, 0,
0);
}

_Z3fn2iRA1024_dRPd._omp_fn.1 (struct .omp_data_s.31 * .omp_data_i)
{
  br.22_22 = &b; /* Error: trying to use global var b.  */
}

Reduced testcase is here: https://gcc.gnu.org/ml/gcc/2014-07/msg00076.html

[Bug preprocessor/62086] A bug with option -fextended-identifiers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086

--- Comment #3 from Jonathan Wakely  ---
N.B. you're not compiling it as C++11, you're compiling it as C89

[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025

--- Comment #4 from Jakub Jelinek  ---
I've applied on top of r207604 just the
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/s390/s390.h?r1=207605&r2=207604&pathrev=207605
change and the testcase was miscompiled too, so the bug is just triggered by
different RA decisions from having reg 14 live on the epilogue.
The miscompilation goes away with -fno-schedule-insns2, but also with
-fno-schedule-insns -fschedule-insns2, but as I said earlier, appart from
different live in/out lr in/out (including r14 there) *.sched1 dump doesn't
contain any real insn changes.
Note only -mtune=z10 is miscompiled, other tuning options are ok.

[Bug preprocessor/62086] A bug with option -fextended-identifiers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
Those characters are all listed explicitly in E.1 [charname.allowed] as being
valid in identifiers for C++.

[Bug target/61641] [4.9/4.10 Regression] undefined label in jump_table_data

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61641

John David Anglin  changed:

   What|Removed |Added

  Attachment #33271|0   |1
is obsolete||

--- Comment #8 from John David Anglin  ---
Created attachment 33292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33292&action=edit
Patch

The attached patch fixes the testcase.  However, delay-slot-2.c
now fails when compiling 32-bit non PIC code.

[Bug c/62090] ice in compute_may_aliases

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62090

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-11
 CC||trippels at gcc dot gnu.org
Version|4.9.2   |4.10.0
   Target Milestone|--- |4.10.0
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
markus@x4 tmp % cat bug158.c
long a;
int *b;
extern __inline __attribute__ ((__always_inline__))
__attribute__ ((__gnu_inline__)) int sprintf (int *p1, char *p2, ...)
{
  a = __builtin_object_size (0, 0);
  return __builtin___sprintf_chk (0, 0, a, p2, __builtin_va_arg_pack ());
}

void
log_bad_request ()
{
  b += sprintf (0, "foo");
}

markus@x4 tmp % gcc -O2 -c bug158.c
bug158.c: In function ‘log_bad_request’:
bug158.c:11:1: internal compiler error: in execute_todo, at passes.c:1795
 log_bad_request ()
 ^
0x92b62c execute_todo
../../gcc/gcc/passes.c:1795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/58042] MinGW GCC produces problematic x64 executable with -O2 -static -flto -m64

[ssbssa at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58042

Domani Hannes  changed:

   What|Removed |Added

 CC||ssbssa at yahoo dot de

--- Comment #1 from Domani Hannes  ---
I can reproduce this with 4.8.3, but not with 4.9.0 or 4.9.1.

[Bug preprocessor/62086] A bug with option -fextended-identifiers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086

--- Comment #5 from joseph at codesourcery dot com  ---
See  regarding the #if 0 
question.  You could always raise a DR with WG14 or WG21 to try to get 
this question resolved properly.

(4.9 implements the C11/C++11 sets of UCNs allowed in identifiers, but of 
course you need to select the right -std option.  Previous versions didn't 
have that support, just the C99/C++98 sets.)

[Bug c/62093] New: multi-argument section attribute for bss, rodata, data

[josh at joshtriplett dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62093

Bug ID: 62093
   Summary: multi-argument section attribute for bss, rodata, data
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josh at joshtriplett dot org

The Linux kernel and similar use the section __attribute__ to place some data
and code into sections like "init", which can be discarded from memory at some
point, or "percpu", which gets mapped to different memory on each CPU. 
However, the section attribute only takes a single section argument, overriding
GCC's usual logic to place const data in rodata and uninitialized data in bss;
in particular, even uninitialized data always gets a value stored for it. 
Peter Anvin and others proposed a three-argument form of the section attribute,
providing three potentially different sections for data that would otherwise go
in data, bss, or rodata.  This would provide a significant space savings in the
compiled binary, as well as enforcing protection for read-only data.

[Bug preprocessor/62086] A bug with option -fextended-identifiers

[pangbw at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086

baoshan  changed:

   What|Removed |Added

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

--- Comment #6 from baoshan  ---
Yes, there would be no issue if compiling it with g++ and -std=c++03 or
-std=c++11.

I have set it to invalid.

[Bug libfortran/62094] New: Program crash when executing DEALLOCATE with addresses that have 0 in bits 26 and higher (little-endian)

[shamsundar at uh dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094

Bug ID: 62094
   Summary: Program crash when executing DEALLOCATE with addresses
that have 0 in bits 26 and higher (little-endian)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shamsundar at uh dot edu

Created attachment 33293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33293&action=edit
Fortran program that will exhibit the bug on a Linux x86-64 system, eg.
openSuse 12.3 desktop

The library routine free() in libc.so.6 on some X86-64 Linux systems will
deference address zero when the argument has bits 26 and up all zero. This will
cause the program to crash. A Fortran program that exposes this bug is
attached. Here are a few instructions from free(), from libc.so.6, stable
release 2.17, configured for x86_64_linux, gcc 4.7.2:

__libc_free: (argument in %rdi)
...
   7ea08:   48 8d 77 f0 lea-0x10(%rdi),%rsi
...
   7ea1b:   48 89 f0mov%rsi,%rax
   7ea1e:   48 25 00 00 00 fc   and$0xfc00,%rax
   7ea24:   48 8b 38mov(%rax),%rdi<<<
crash if %rax =  0

[Bug libfortran/62094] Program crash when executing DEALLOCATE with addresses that have 0 in bits 26 and higher (little-endian)

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Looks like a bug in glibc exposed by gfortran.  Not sure
why you think that this is a libgfortran bug.

[Bug target/62038] Out of range branch target in thunk

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038

--- Comment #1 from John David Anglin  ---
Author: danglin
Date: Mon Aug 11 19:07:16 2014
New Revision: 213829

URL: https://gcc.gnu.org/viewcvs?rev=213829&root=gcc&view=rev
Log:
PR target/62038
* config/pa/pa.c (pa_asm_output_mi_thunk): Use a branch with %r31 link
register.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c

[Bug target/62038] Out of range branch target in thunk

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038

--- Comment #2 from John David Anglin  ---
Author: danglin
Date: Mon Aug 11 19:10:59 2014
New Revision: 213830

URL: https://gcc.gnu.org/viewcvs?rev=213830&root=gcc&view=rev
Log:
PR target/62038
* config/pa/pa.c (pa_asm_output_mi_thunk): Use a branch with %r31 link
register.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/pa/pa.c

[Bug target/62038] Out of range branch target in thunk

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038

--- Comment #3 from John David Anglin  ---
Author: danglin
Date: Mon Aug 11 19:13:46 2014
New Revision: 213831

URL: https://gcc.gnu.org/viewcvs?rev=213831&root=gcc&view=rev
Log:
PR target/62038
* config/pa/pa.c (pa_asm_output_mi_thunk): Use a branch with %r31 link
register.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/pa/pa.c

[Bug c++/62080] Suboptimal code generation with eigen library

[beschindler at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080

--- Comment #4 from Benjamin Schindler  ---
(In reply to Marc Glisse from comment #2)
> (note that a minimal, self-contained testcase would be much better and
> shouldn't be hard to produce)


I don't mind doing so, but I don't quite know what is required to trigger this
isssue. 

After chatting with a friend, I realized yet another issue with the generated
assembly: it makes a lot of use of unaligned reads (movdqu) as opposed to
movdqa. Eigen types are by design aligned and thus, it should be possible to
use the (from what I've been told) faster aligned reads

Cheers

[Bug libfortran/62094] Program crash when executing DEALLOCATE with addresses that have 0 in bits 26 and higher (little-endian)

[sham at Central dot UH.EDU]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094

--- Comment #2 from sham at Central dot UH.EDU ---
Thanks, Steve. My pick of libgfortran as "product line" was because it was the
closest from the limited choices that the bug report form offered. 

As you observed, this is probably just a LIBC bug. On the other hand, I do not
know the interconnections between the code generated for ALLOCATE/DEALLOCATE by
GFortran and the conventions governing call to malloc()/free().

N. Shamsundar

From: kargl at gcc dot gnu.org [gcc-bugzi...@gcc.gnu.org]
Sent: Monday, August 11, 2014 1:47 PM
To: shamsun...@uh.edu
Subject: [Bug libfortran/62094] Program crash when executing DEALLOCATE with
addresses that have 0 in bits 26 and higher (little-endian)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Looks like a bug in glibc exposed by gfortran.  Not sure
why you think that this is a libgfortran bug.

--
You are receiving this mail because:
You reported the bug.

[Bug other/62095] New: gcc: error: unrecognized command line option

[dilyan.palauzov at aegee dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62095

Bug ID: 62095
   Summary: gcc: error: unrecognized command line option
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org

When I type
  gcc -WZ
I get
  gcc: error: unrecognized command line option ‘-WZ’
  gcc: fatal error: no input files
  compilation terminated.

But when I type
  gcc -Wno-Z
I get just
  gcc: fatal error: no input files
  compilation terminated.

I expect in the second case to see "unrecognized command line option "-Wno-Z"

Motivation:
  valgrind uncorrectly detects in configure.ac, if the compiler supports
-Wno-tautological-compare by running gcc -Wno-tautological-compare, which
prints no error => compiler supports -Wno-tautological-compare .  However,
during compiling valgrind, gcc manages to output somehow the message, that
"-Wno-tautological-compare " is not supported, but I cannot write a simple case
where gcc complains about -Wno-tautological-compare .

[Bug target/62038] Out of range branch target in thunk

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #4 from John David Anglin  ---
Fixed.

[Bug libfortran/62094] Program crash when executing DEALLOCATE with addresses that have 0 in bits 26 and higher (little-endian)

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094

--- Comment #3 from Steve Kargl  ---
On Mon, Aug 11, 2014 at 07:17:15PM +, sham at Central dot UH.EDU wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094
> 
> --- Comment #2 from sham at Central dot UH.EDU ---
> Thanks, Steve. My pick of libgfortran as "product line" was because
> it was the closest from the limited choices that the bug report form
> offered. 
> 
> As you observed, this is probably just a LIBC bug. On the other hand,
> I do not know the interconnections between the code generated for
> ALLOCATE/DEALLOCATE by GFortran and the conventions governing call
> to malloc()/free().
> 

glibc is developed independently of gcc.  You can go to
http://www.gnu.org/software/libc/bugs.html
for more information on reporting glibc bugs.

Unofortunately, I suspect the glibc developers will want
a C program that exposes the problem not a Fortran program.

[Bug c++/62096] New: unexpected warning overflow in implicit constant conversion

[travis.vitek at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62096

Bug ID: 62096
   Summary: unexpected warning overflow in implicit constant
conversion
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: travis.vitek at roguewave dot com

The following test case generates a an unexpected warning.

[vitek@sidewinder] 350 % gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/amd/packages/mdx/redhat/compilers/gcc-4.9.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.0/configure --prefix=/build/gcc-4.9.0
--enable-languages=c,c++
Thread model: posix
gcc version 4.9.0 (GCC)
[vitek@sidewinder] 351 % cat t.cpp
enum E {
E_val  = 1,
};

inline constexpr E operator~(E e)
{
return E(~static_cast(e));
}

int main()
{
int val = ~E_val;
(void) val;
}
[vitek@sidewinder] 352 % g++ --pedantic -std=c++11 -c ./t.cpp
./t.cpp: In function 'int main()':
./t.cpp:12:16: warning: overflow in implicit constant conversion [-Woverflow]
 int val = ~E_val;
^
[vitek@sidewinder] 353 %


The issue seems to be related to the function being constexpr and the type of
the destination being int. If I remove the constexpr or change the destination
type (to long long or E), the warning goes away.

[Bug target/62038] Out of range branch target in thunk

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038

John David Anglin  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2014-08-11
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #5 from John David Anglin  ---
There is a problem:

./target-2.exe: error while loading shared libraries: internal error: symidx
out of range of fptr table
FAIL: libgomp.c++/target-2.C execution test

[Bug other/62095] gcc: error: unrecognized command line option

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62095

--- Comment #1 from Andrew Pinski  ---
This is by design.  In fact this was a design change in the last few years.

[Bug other/62095] gcc: error: unrecognized command line option

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62095

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Andreas Schwab  ---
Please file this with valgrind, it should check for -Wtautological-compare, not
for the negated option.

[Bug libgcc/62097] New: mipsel-sde-elf build fails on OS X 10.7 host

[Anders.Montonen at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097

Bug ID: 62097
   Summary: mipsel-sde-elf build fails on OS X 10.7 host
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Anders.Montonen at iki dot fi

Created attachment 33294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33294&action=edit
Make all log

Trying to build a crosscompiler targeting mipsel-sde-elf on an OS X 10.7 host
fails with the following error:

# If this is the top-level multilib, build all the other
# multilibs.
DEFINES='' HEADERS='' \
../../../../gcc-4.9.1/libgcc/mkheader.sh > tmp-libgcc_tm.h
/bin/sh ../../../../gcc-4.9.1/libgcc/../move-if-change tmp-libgcc_tm.h
libgcc_tm.h
echo timestamp > libgcc_tm.stamp
Mode = sf\|df
Suffix = si\|2\|3
/Users/anders/work/toolchain/gcc/4.9.1/mipsel-sde-elf/./gcc/xgcc
-B/Users/anders/work/toolchain/gcc/4.9.1/mipsel-sde-elf/./gcc/ -nostdinc
-B/Users/anders/work/toolchain/gcc/4.9.1/mipsel-sde-elf/mipsel-sde-elf/newlib/
-isystem
/Users/anders/work/toolchain/gcc/4.9.1/mipsel-sde-elf/mipsel-sde-elf/newlib/targ-include
-isystem /Users/anders/work/toolchain/gcc/4.9.1/gcc-4.9.1/newlib/libc/include
-B/Users/anders/work/toolchain/gcc/4.9.1/mipsel-sde-elf/mipsel-sde-elf/libgloss/mips
-L/Users/anders/work/toolchain/gcc/4.9.1/mipsel-sde-elf/mipsel-sde-elf/libgloss/libnosys
-L/Users/anders/work/toolchain/gcc/4.9.1/gcc-4.9.1/libgloss/mips
-B/Users/anders/local/mipsel-sde-elf/bin/
-B/Users/anders/local/mipsel-sde-elf/lib/ -isystem
/Users/anders/local/mipsel-sde-elf/include -isystem
/Users/anders/local/mipsel-sde-elf/sys-include-g -O2 -Os -minterlink-mips16
-mcode-readable=pcrel -mno-gpopt -EB -O2  -g -O2 -Os -minterlink-mips16
-mcode-readable=pcrel -mno-gpopt -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -I. -I. -I../../.././gcc
-I../../../../gcc-4.9.1/libgcc -I../../../../gcc-4.9.1/libgcc/.
-I../../../../gcc-4.9.1/libgcc/../gcc -I../../../../gcc-4.9.1/libgcc/../include
 -DHAVE_CC_TLS  -o addsf3.o -MT addsf3.o -MD -MP -MF addsf3.dep addsf3 -c
../../../../gcc-4.9.1/libgcc/config/hardfp.c -fvisibility=hidden -DHIDE_EXPORTS
-Wno-missing-prototypes
xgcc: error: addsf3: No such file or directory
make[4]: *** [addsf3.o] Error 1
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

The configure command used:
--prefix=/Users/anders/local --target=mipsel-sde-elf --disable-nls
--enable-languages="c,c++" --enable-lto --with-newlib --with-arch-32=mips32r2
--with-arch-64=mips64r2

Building 4.8.3 with the same configuration succeeds without problems, and
building 4.9.1 for the m68k-unknown-elf and sh-elf targets also succeeds
without issues.
Building 4.9.1 for a the mipsel-sde-elf target on a Linux host also works fine.

[Bug libgcc/62097] mipsel-sde-elf build fails on OS X 10.7 host

[Anders.Montonen at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097

--- Comment #1 from Anders Montonen  ---
Created attachment 33295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33295&action=edit
Config log

[Bug c++/62080] Suboptimal code generation with eigen library

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62080

--- Comment #5 from Marc Glisse  ---
With the intrinsics patch, I notice that we don't simplify in gimple either:

  _40 = VIEW_CONVERT_EXPR<__m128i>(_39);
  MEM[(__m128i * {ref-all})vec_4(D)] = _40;
  _60 = MEM[(const double *)vec_4(D)];
  _61 = MEM[(const double *)vec_4(D) + 8B];
  _62 = {_60, _61};
  _63 = VIEW_CONVERT_EXPR<__v4si>(_62);

(_39 and _63 have the same type)

[Bug target/62098] New: incorrect code generated by arm gcc

[carrot at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098

Bug ID: 62098
   Summary: incorrect code generated by arm  gcc
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carrot at google dot com
Target: arm-unknown-linux-gnueabi

Compile following source code with options -march=armv7-a  -mfpu=vfpv3
-mfloat-abi=softfp -O2 -std=gnu++11

#include 
#include 

const int kFixedPointDenominator = 64;

float ceilToFloat(int m_value)  {
  float floatValue = static_cast(m_value) / kFixedPointDenominator;
  if (static_cast(floatValue * kFixedPointDenominator) == m_value)
 return floatValue;
  if (floatValue > 0)
 return nextafterf(floatValue, std::numeric_limits::max());
  return nextafterf(floatValue, std::numeric_limits::min());
}


trunk gcc generates:

fmsrs15, r0@ int
vcvt.f32.s32s15, s15, #6  // A
vcvt.s32.f32s15, s15, #6  // B
vmovr3, s15
cmpr3, r0
beq.L2
fcmpezss15
fmstat
ble.L6
movwr1, #65535
fmrsr0, s15
movtr1, 32639
bnextafterf
.L6:
movr1, #8388608
fmrsr0, s15
bnextafterf
.L2:
fmrsr0, s15   // C
bxlr


Instruction C returns the result of instruction B, but the expected return
value is the result of instruction A.

4.9 branch generates the same wrong codes, but 4.8 is correct.

[Bug other/62095] gcc: error: unrecognized command line option

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62095

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
Since I have seen this asked several times, I added a FAQ entry:

https://gcc.gnu.org/wiki/FAQ#wnowarning

Please use that link when answering similar PRs.

[Bug preprocessor/61613] ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to David Krauss from comment #4)
> Let's see what the maintainers do with it :) .

Probably nothing if you don't follow the submission process:
https://gcc.gnu.org/contribute.html

[Bug sanitizer/58543] Invalid unpoisoning of stack redzones on ARM

[yroux at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543

--- Comment #12 from yroux at gcc dot gnu.org ---
Author: yroux
Date: Mon Aug 11 21:57:46 2014
New Revision: 213841

URL: https://gcc.gnu.org/viewcvs?rev=213841&root=gcc&view=rev
Log:
2014-08-11  Michael Collison  

Backport from trunk r204251
2013-10-31  Richard Sandiford  
Yury Gribov  

PR sanitizer/58543
* asan.c (asan_clear_shadow): Allocate a new vreg for temporary
shadow pointer to avoid clobbering the main one.


Modified:
branches/linaro/gcc-4_8-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_8-branch/gcc/asan.c

[Bug target/59744] miscompilation of unsigned comparison on aarch64

[yroux at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744

--- Comment #8 from yroux at gcc dot gnu.org ---
Author: yroux
Date: Mon Aug 11 22:08:03 2014
New Revision: 213842

URL: https://gcc.gnu.org/viewcvs?rev=213842&root=gcc&view=rev
Log:
gcc/
2014-08-11  Michael Collison  

Backport from trunk r206529, r206530
2014-01-10  Richard Earnshaw  

PR target/59744
* aarch64-modes.def (CC_Zmode): New flags mode.
* aarch64.c (aarch64_select_cc_mode): Only allow NEG when the condition
represents an equality.
(aarch64_get_condition_code): Handle CC_Zmode.
* aarch64.md (compare_neg): Restrict to equality operations.

gcc/testsuite/
2014-08-11  Michael Collison  

Backport from trunk r206529
2014-01-10  Richard Earnshaw  

PR target/59744
* gcc.target/aarch64/cmn-neg.c: Use equality comparisons.
* gcc.target/aarch64/cmn-neg2.c: New test.


Added:
branches/linaro/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/cmn-neg2.c
Modified:
branches/linaro/gcc-4_8-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_8-branch/gcc/config/aarch64/aarch64-modes.def
branches/linaro/gcc-4_8-branch/gcc/config/aarch64/aarch64.c
branches/linaro/gcc-4_8-branch/gcc/config/aarch64/aarch64.md
branches/linaro/gcc-4_8-branch/gcc/testsuite/ChangeLog.linaro
branches/linaro/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/cmn-neg.c

[Bug bootstrap/62099] New: bootstrap build fails on ARM hard float system

[pab at pabigot dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099

Bug ID: 62099
   Summary: bootstrap build fails on ARM hard float system
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pab at pabigot dot com

gcc 4.9.1 bootstrap on an ARM hard-float system (TI AM3358 Cortex-A8 beaglebone
using Yocto: arm-poky-linux-gnueabi) fails with:

/home/pab/build/./gcc/xgcc -B/home/pab/build/./gcc/
-B/usr/local/gcc/armv7l-unknown-linux-gnueabihf/bin/
-B/usr/local/gcc/armv7l-unknown-linux-gnueabihf/lib/ -isystem
/usr/local/gcc/armv7l-unknown-linux-gnueabihf/include -isystem
/usr/local/gcc/armv7l-unknown-linux-gnueabihf/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fno-inline -I. -I. -I../.././gcc
-I../../../gcc-4.9.1/libgcc -I../../../gcc-4.9.1/libgcc/.
-I../../../gcc-4.9.1/libgcc/../gcc -I../../../gcc-4.9.1/libgcc/../include 
-DHAVE_CC_TLS  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../gcc-4.9.1/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/features.h:402:0,
 from /usr/include/stdio.h:27,
 from ../../../gcc-4.9.1/libgcc/../gcc/tsystem.h:87,
 from ../../../gcc-4.9.1/libgcc/libgcc2.c:27:
/usr/include/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or
directory
 # include 

Unlike the stage1 compiler, the host compiler always defines __ARM_PCS_VFP and
there is no gnu/stubs-soft.h available.

gcc-4.9.1 configured with only: --enable-languages=c,c++
--prefix=/usr/local/gcc

The gross workaround is to symlink stubs-soft.h -> stubs-hard.h and restart the
build.

https://gcc.gnu.org/ml/gcc-help/2013-02/msg00141.html suggests this has been
present since at least gcc 4.8.0.

[Bug bootstrap/62099] bootstrap build fails on ARM hard float system

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099

--- Comment #1 from Andrew Pinski  ---
How are you configuring GCC?  armv7l-unknown-linux-gnueabihf is the same as
armv7l-unknown-linux-gnueabi unless you add a few extra configure options.

[Bug bootstrap/62099] bootstrap build fails on ARM hard float system

[pab at pabigot dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099

--- Comment #2 from Peter A. Bigot  ---
Created attachment 33296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33296&action=edit
config.log from failed build

[Bug bootstrap/62099] bootstrap build fails on ARM hard float system

[pab at pabigot dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099

--- Comment #3 from Peter A. Bigot  ---
  $ ../gcc-4.9.1/configure --enable-languages=c,c++ --prefix=/usr/local/gcc

Hopefully the attached config.log will have more useful information.

[Bug bootstrap/62099] bootstrap build fails on ARM hard float system

[pab at pabigot dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099

--- Comment #4 from Peter A. Bigot  ---
If you mean how did OpenEmbedded configure the compiler that's being used for
the bootstrap, that's an uglier question that I can't really answer since it's
got various patches and special stuff involved.  The only reason I'm
bootstrapping the released 4.9.1 at all is to determine whether a C++11 issue
is due to OE patches; I didn't expect to run into this particular problem,
which appears to be a fragility in the bootstrap when using the newly built
compiler with the system headers from the originally build compiler.

[Bug bootstrap/62099] bootstrap build fails on ARM hard float system

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099

--- Comment #5 from Andrew Pinski  ---
You need to use -with-float=hard when configuring GCC.

[Bug libstdc++/62100] New: c++11 threads invoke pure virtual function on arm embedded system

[pab at pabigot dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100

Bug ID: 62100
   Summary: c++11 threads invoke pure virtual function on arm
embedded system
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pab at pabigot dot com

Created attachment 33297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33297&action=edit
reproducing code

The attached program built on the target with the MACHINE=beaglebone gcc-4.9.1
compiler from Yocto/OpenEmbedded poky master produces this error:

beaglebone[16]$ g++ -std=c++1y -pthread test.cc && ./a.out
starting
joining
pure virtual method called
terminate called without an active exception
Aborted (core dumped)

Based on google and discovery of these references:

* https://groups.google.com/d/msg/automatak-dnp3/Jisp_zGhd5I/ck_Cj6nO8joJ

*
http://stackoverflow.com/questions/23583317/c-11-threads-error-pure-virtual-function-called

I've tracked this down to ext/concurrence.h requiring the presence of
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to
use _S_atomic as the default lock policy instead of _S_mutex.  Defining those
macros allows the program to run correctly:

beaglebone[17]$ g++ -DWITH_HACKERY -std=c++11 -pthread test.cc && ./a.out
starting
joining
doit
done

I believe this is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
and that a better fix is to modify ext/concurrence.h to also use _S_atomic if
_GLIBCXX_ATOMIC_BUILTINS is defined even when the compare-and-swap are not. 
Preliminary testing suggests that this solves the problem.

The discussion at 52839 suggests there's an ABI compatibility issue here; I
don't really understand that (nor, honestly, care, since in this situation the
compiler's going onto an embedded system where I'm not worried about old
binaries).  However, if there's a reason why I shouldn't propose this as a
patch to OpenEmbedded please let me know.

[Bug target/26472] Default path for libgcc_s.sl is build directory

[wzis at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

wzis  changed:

   What|Removed |Added

 CC||wzis at hotmail dot com

--- Comment #18 from wzis  ---
Not sure whether the issue I got is related to this bug: When using GCC to
compile a C program, the binary got is linked with a libgcc_s.4 under the
HP-GCC 4.7.1 installed directory /opt/hp-gccxxx/xx/yy/../zz/aa/../, and to run
the program on another machine, that machine has to install the GCC also,
that's very bad. My question is why can't GCC generate a static lib for those
functions that must be used for the binary to run and linked with the program
statically? Isn't that will remove the dependency to GCC package for running
the program? I'm using hp-gcc-4.7.1.

[Bug bootstrap/62099] bootstrap build fails on ARM hard float system

[pab at pabigot dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099

Peter A. Bigot  changed:

   What|Removed |Added

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

--- Comment #6 from Peter A. Bigot  ---
Thanks; I'll try to remember that if I need to build from scratch again.

I see you've detected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 which
is why I was doing this in the first place, so am closing this report.

[Bug preprocessor/61613] ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name

[potswa at mac dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613

--- Comment #6 from David Krauss  ---
The patch should already pass the coding standards. I'm already legally
registered as a contributor.

Arthur, can you take care of the rest of the process? (Did you get my email?)

I'd like to take it 100% but the testsuite isn't working on my system. The
patch is small enough and unobscure enough that it's easier for someone else to
take responsibility than for me to dedicate another day to GCC build
configuration.

[Bug preprocessor/61613] ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name

[arthur.j.odwyer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613

--- Comment #7 from Arthur O'Dwyer  ---
@David, sadly, I'm not set up to build or test GCC patches, nor am I registered
as a contributor. Anyone else want to step up?

I could suggest test cases, perhaps, but I wouldn't be good at shepherding this
patch all the way through the process-I've-never-done-before.

[Bug c++/62101] New: deleted definitions of friend functions are rejected

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62101

Bug ID: 62101
   Summary: deleted definitions of friend functions are rejected
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com

Test:

struct X
{
friend void f(X, int) = delete;
friend void f(X, double) {}
};

struct Y;
void g(Y, int);
void g(Y, double);

struct Y
{
friend void g(Y, int) = delete;
friend void g(Y, double) {}
};

int main()
{
X x;
f(x, 5.0);
Y y;
g(y, 5.0);
}

deleted-friend.cpp:3:26: error: can’t initialize friend function ‘f’
  friend void f(X, int) = delete;
  ^
deleted-friend.cpp:13:26: error: can’t initialize friend function ‘g’
  friend void g(Y, int) = delete;
  ^

clang accepts the code. There doesn't seem to be any standard wording
forbidding in-class friend definitions that are deleted.

[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##

[potswa at mac dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844

David Krauss  changed:

   What|Removed |Added

 CC||potswa at mac dot com

--- Comment #9 from David Krauss  ---
The fix makes the case well-formed. It's not. A sequence of concatenation
operators is not processed as if they were separated by empty parameters. "A ##
## B" concatenates A with the (second) ## to produce an illegal token "A##".
Clang diagnoses it as such.

[Bug target/26472] Default path for libgcc_s.sl is build directory

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472

--- Comment #19 from dave.anglin at bell dot net ---
On 11-Aug-14, at 7:26 PM, wzis at hotmail dot com wrote:

> Not sure whether the issue I got is related to this bug: When using  
> GCC to
> compile a C program, the binary got is linked with a libgcc_s.4  
> under the
> HP-GCC 4.7.1 installed directory /opt/hp-gccxxx/xx/yy/../zz/aa/../,  
> and to run
> the program on another machine, that machine has to install the GCC  
> also,
> that's very bad. My question is why can't GCC generate a static lib  
> for those
> functions that must be used for the binary to run and linked with  
> the program
> statically? Isn't that will remove the dependency to GCC package for  
> running
> the program? I'm using hp-gcc-4.7.1.


The main problem is the HP linker hard codes shared library paths into  
applications
and shared libraries.

There are ways to manipulate the shared library search path with chatr  
and link options.
Check out the man pages for chatr and ld.

A static libgcc.a is installed and will be used with -static or - 
static-libgcc linker options.
This will avoid the hard-coded dependence on the installation path to  
libgcc_s.4.

Dave
--
John David Anglindave.ang...@bell.net

[Bug regression/62102] New: [4.10 Regression]: gcc.dg/torture/pr48953.c -O2 -flto

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62102

Bug ID: 62102
   Summary: [4.10 Regression]: gcc.dg/torture/pr48953.c -O2 -flto
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: hubicka at ucw dot cz
  Host: x86_64-unknown-linux-gnu
Target: cris-axis-elf

These tests previously passed, now they fail.
A patch in the revision range (last_known_working:first_known_failing)
212108:212117 exposed or caused these regressions.  Yes, I know this is more
than a month ago, sorry for the delay.  Since then they fail as follows:

Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/dg-torture.exp
...
FAIL: gcc.dg/torture/pr48953.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: gcc.dg/torture/pr48953.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.dg/torture/pr48953.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
FAIL: gcc.dg/torture/pr48953.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
WARNING: gcc.dg/torture/pr48953.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  compilation failed to produce executable

Messages in gcc.log (from r213837):

Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/pr48953.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never-O2 -flto
-fno-use-linker-plugin -flto-partition=none  -fno-tree-dce   -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris 
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3  -lm-o
./pr48953.exe(timeout = 300)
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/pr48953.c: In function
'main':
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/pr48953.c:14:5: error:
type mismatch in array reference
struct S

struct S

# .MEM_5 = VDEF <.MEM_4>
MEM[(struct S[2] *)&D.1358][0]{lb: 0 sz: 12}.value = 0;
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/pr48953.c:14:5: internal
compiler error: verify_gimple failed
0x8a872c verify_gimple_in_cfg(function*, bool)
/tmp/hpautotest-gcc1/gcc/gcc/tree-cfg.c:4994
0x7dc2c1 execute_function_todo
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:1749
0x7dd783 execute_todo
/tmp/hpautotest-gcc1/gcc/gcc/passes.c:1806
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
returned 1 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
compiler exited with status 1

Author of suspect patches in revision range CC:ed.
The test passes on the 4.9 branch.
Unfortunately, the failure is appearently LTO-specific and only exposed on this
target, from a quick browse of gcc-testresults archives.

[Bug middle-end/62103] New: Incorrect folding of bitfield in a union on big endian targets

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103

Bug ID: 62103
   Summary: Incorrect folding of bitfield in a union on big endian
targets
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org

Folding of bitfield in a union is incorrect on big endian targets. Consider the
testcase given in attachment, u.b would be folded to 0x45678 instead of
0x12345.

[Bug middle-end/62103] Incorrect folding of bitfield in a union on big endian targets

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103

thopre01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-12
   Assignee|unassigned at gcc dot gnu.org  |thopre01 at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from thopre01 at gcc dot gnu.org ---
Created attachment 33298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33298&action=edit
Testcase: bitfield in a union

[Bug middle-end/62103] Incorrect folding of bitfield in a union on big endian targets

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103

--- Comment #2 from thopre01 at gcc dot gnu.org ---
I forgot to mention the flag to use: -O1 and whatever flag is necessary to
select a big endian target (for instance -mbig-endian if the target is arm
little endian by default).

[Bug middle-end/62103] Incorrect folding of bitfield in a union on big endian targets

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62103

--- Comment #3 from thopre01 at gcc dot gnu.org ---
Author: thopre01
Date: Tue Aug 12 02:36:37 2014
New Revision: 213846

URL: https://gcc.gnu.org/viewcvs?rev=213846&root=gcc&view=rev
Log:
2014-08-12  Thomas Preud'homme  

gcc/
PR middle-end/62103
* gimple-fold.c (fold_ctor_reference): Don't fold in presence of
bitfields, that is when size doesn't match the size of type or the
size of the constructor.

gcc/testsuite/
PR middle-end/62103
* gcc.c-torture/execute/bitfld-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
While r207605 may be the trigger for the failure for this test.  I can twiddle
the test so that it fails with 207604 and 207605.  I'm starting to wonder if
207605 just tripped something latent.

I'm still looking, but we may have been totally barking up the wrong tree
focusing on 207605.

[Bug ipa/61659] [4.9/4.10 Regression] Extra undefined symbol because of devirtualization

[amker.cheng at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659

bin.cheng  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #21 from bin.cheng  ---
(In reply to Jason Merrill from comment #18)
> Author: jason
> Date: Wed Jul 30 17:27:14 2014
> New Revision: 213307
> 
> URL: https://gcc.gnu.org/viewcvs?rev=213307&root=gcc&view=rev
> Log:
>   PR lto/53808
>   PR c++/61659
>   * pt.c (push_template_decl_real): Set DECL_COMDAT on templates.
>   (check_explicit_specialization): Clear it on specializations.
>   * decl.c (duplicate_decls, start_decl): Likewise.
>   (grokmethod, grokfndecl): Set DECL_COMDAT on inlines.
>   * method.c (implicitly_declare_fn): Set DECL_COMDAT.  Determine
>   linkage after setting the appropriate flags.
>   * tree.c (decl_linkage): Don't check DECL_COMDAT.
>   * decl2.c (mark_needed): Mark clones.
>   (import_export_decl): Not here.
> 
> Modified:
> trunk/gcc/cp/ChangeLog
> trunk/gcc/cp/decl.c
> trunk/gcc/cp/decl2.c
> trunk/gcc/cp/method.c
> trunk/gcc/cp/pt.c
> trunk/gcc/cp/tree.c
> trunk/gcc/testsuite/g++.dg/opt/devirt4.C

Hi Jason,
After setting DECL_COMDAT, testcase g++.dg/ext/arm-fp16/fp16-mangle-1.C as
below no longer works.

/* { dg-do compile { target arm*-*-* } } */
/* { dg-options "-mfp16-format=ieee" } */

/* Test mangling */

/* { dg-final { scan-assembler "\t.global\t_Z1fPDh" } } */
void f (__fp16 *x) { }

/* { dg-final { scan-assembler "\t.global\t_Z1gPDhS_" } } */
void g (__fp16 *x, __fp16 *y) { }

/* { dg-final { scan-assembler "\t.global\t_ZN1SIDhDhE1iE" } } */
template  struct S { static int i; }; 
template <> int S<__fp16, __fp16>::i = 3;

Since g++ now outputs:

.weak_ZN1SIDhDhE1iE
.section.data._ZN1SIDhDhE1iE,"awG",%progbits,_ZN1SIDhDhE1iE,comdat
    .align2
.type_ZN1SIDhDhE1iE, %object
.size_ZN1SIDhDhE1iE, 4
_ZN1SIDhDhE1iE:
.word3
.ident"GCC: (GNU) 4.10.0 20140811 (experimental)"

rather than ".global\t_ZN1SIDhDhE1iE".

I assume we should refine the testcase? 

Thanks.

[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025

--- Comment #6 from Jeffrey A. Law  ---
It's late and I need to catch some zzzs. But as I hinted in my prior update, I
think we may chasing something latent.   I would recommend looking very closely
at r204497, which my bisecting implicated as the failing commit for a severely
hacked up test.

Reverting r204497 by hand on the trunk results in the original testcase working
properly.  I'm too tired to really analyze, but I think it's worth a looksie.