[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #53 from Jan Hubicka  ---
This patch makes denominator to use resulting function size (not uninlined time
like 4.9 did but getting the resulting fraction closer to 4.9 style):
Index: ../../gcc/ipa-inline.c
===
--- ../../gcc/ipa-inline.c  (revision 221806)
+++ ../../gcc/ipa-inline.c  (working copy)
@@ -1167,6 +1168,7 @@ edge_badness (struct cgraph_edge *edge,
overall_growth += 256 * 256 - 256;
  denominator *= overall_growth;
 }
+  denominator *= inline_summaries->get (caller)->self_size + growth;

   badness = - numerator / denominator;

Large function growht is now hit only 8 times and compile time seems down to:
real0m33.670s
user0m33.065s
sys 0m0.522s
code size seems 8% bigger than 4.9, runtime is good.

The performance stays good with large-function-insns=10 and compile time
further drops to:
real0m32.127s
user0m31.634s
sys 0m0.520s

I will run firefox benchmarks tonight.

[Bug driver/65444] -z bndplt isn't passed to linker for -mmpx when building dynamic objects

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu Apr  2 08:15:49 2015
New Revision: 221831

URL: https://gcc.gnu.org/viewcvs?rev=221831&root=gcc&view=rev
Log:
gcc/
PR driver/65444
* config/i386/linux-common.h (MPX_SPEC): New.
(CHKP_SPEC): Add MPX_SPEC.
* doc/invoke.texi (-fcheck-pointer-boudns): Document
possible issues with '-z bndplt' support in linker.

libmpx/

PR driver/65444
* configure.ac: Add check for '-z bndplt' support
by linker. Add link_mpx output variable.
* libmpx.spec.in (link_mpx): New.
* configure: Regenerate.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/linux-common.h
trunk/gcc/doc/invoke.texi
trunk/libmpx/ChangeLog
trunk/libmpx/configure
trunk/libmpx/configure.ac
trunk/libmpx/libmpx.spec.in

[Bug driver/65444] -z bndplt isn't passed to linker for -mmpx when building dynamic objects

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #2 from Ilya Enkovich  ---
Fixed

[Bug ipa/65478] [5 regression] crafty performance regression

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Wed, 1 Apr 2015, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
> 
> --- Comment #23 from Jan Hubicka  ---
> > Seems to be a regression with -flto only?  I also see EON regressing without
> > -flto.
> Yes, the inlining is cross file.
> > 
> > http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64/index.html
> 
> Saw that one too. It is in between 
> Feb 10, 2015 18:20 UTC
> (Values: Base: 164.gzip: 1558, 175.vpr: 2392, 176.gcc: 2845, 181.mcf: 
> 3766,
> 186.crafty: 2926, 197.parser: 1975, 252.eon: 3726, 255.vortex: 3305, 
> 256.bzip2:
> 2218, 300.twolf: 3257 Peak: , 164.gzip: 1546, 175.vpr: 2397, 176.gcc: 1994,
> 181.mcf: 3819, 186.crafty: 2737, 197.parser: 1911, 252.eon: 4461, 255.vortex:
> 4364, 256.bzip2: 2348, 300.twolf: 3265)
> Feb 10, 2015 09:20 UTC
> (Values: Base: 164.gzip: 1549, 175.vpr: 2452, 176.gcc: 2734, 181.mcf: 
> 3458,
> 186.crafty: 2833, 197.parser: 1962, 252.eon: 4083, 255.vortex: 3378, 
> 256.bzip2:
> 2059, 300.twolf: 3231 Peak: , 164.gzip: 1555, 175.vpr: 2241, 176.gcc: 2800,
> 181.mcf: 3821, 186.crafty: 2681, 197.parser: 1905, 252.eon: 4415, 255.vortex:
> 4363, 256.bzip2: 2379, 300.twolf: 3220)
> 
> So it does not seem to point to inliner changes (fortunately).  At Megrez, you
> should be able to access the diff?

Yes, it's -r220566:220590, so it is very likely

+2015-02-10  Richard Biener  
+
+   PR tree-optimization/64909
+   * tree-vect-loop.c (vect_estimate_min_profitable_iters): Properly
+   pass a scalar-stmt count estimate to the cost model.
+   * tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost): Likewise.

which fixed a pretty serious vectorizer cost-model issue on all AMD archs.

Might be worth investigating (not that the cost modeling is very good...).

On megrez -march=native expands to

-march=bdver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 
-msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mfma 
-mfma4 -mxop -mbmi -mno-bmi2 -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 
-mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed 
-mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512er 
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec 
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma 
-mno-avx512vbmi -mno-clwb -mno-pcommit --param l1-cache-size=16 --param 
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2

[Bug tree-optimization/65658] Jump threading too pessimistic when optimizing for size

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-02
 Ever confirmed|0   |1

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

[Bug c++/65656] __builtin_constant_p should always be constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-02
 Ever confirmed|0   |1
  Known to fail||5.0

--- Comment #1 from Richard Biener  ---
If it's arg is a constexpr then it should return true and if not, false.

Confirmed.

[Bug ipa/65654] [5 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug ipa/65655] [5 Regression] ICE in speculative_call_info, at cgraph.c:1151

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

[rai...@emrich-ebersheim.de]

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

--- Comment #9 from Rainer Emrich  ---
Created attachment 35210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35210&action=edit
Test case including temporaries

[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

[rai...@emrich-ebersheim.de]

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

--- Comment #10 from Rainer Emrich  ---
(In reply to Jan Hubicka from comment #8)
> Hmm, is it still a problem and if so, why it is marked as resolved/invalid?
> 
> crtbegin/crtend should be compiled without LTO even with LTO bootstrap.
> Can you post the callgraph and resolution file created by compiling the
> testcase with --save-temps and -fdump-ipa-cgraph?

The attached test case is compiled with gcc version 5.0.0 20150326
(experimental) [trunk revision 221697] (GCC).

[Bug target/63890] [4.9/5 regression] Compiling trivial program with -O -p leads to misaligned stack

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres  ---
> also failing from the same bug, gcc.dg/aru-2.c

and likely gcc.dg/20021014-1.c.

The patch in comment 12 fixes

FAIL: gcc.dg/20021014-1.c execution test
FAIL: gcc.dg/aru-2.c execution test
FAIL: gcc.dg/pr43643.c execution test

but causes the following regressions

FAIL: g++.old-deja/g++.law/profile1.C  -std=gnu++11 execution test
FAIL: g++.old-deja/g++.law/profile1.C  -std=gnu++14 execution test
FAIL: g++.old-deja/g++.law/profile1.C  -std=gnu++98 execution test
FAIL: gcc.dg/nest.c execution test
FAIL: gcc.dg/nested-func-4.c execution test
FAIL: gcc.dg/pr32450.c execution test
FAIL: gcc.target/i386/mcount_pic.c execution test

(all with -m32).

[Bug libstdc++/65659] New: STL containers not specialized for pointer value_type

[marc at kdab dot com]

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

Bug ID: 65659
   Summary: STL containers not specialized for pointer value_type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc at kdab dot com

The STL containers are not specialised for pointer types, leading to tons of
duplicated virtually-identical binary code.

Example:

   vector could be implemented in terms of vector
   vector could be implemented in terms of vector
   vector> could be implemented in terms of
vector>
   vector> could be implemented in terms of
vector>

Is there anything that prevents this rather obvious optimisation? Allcators
having the wrong type?

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[hong.gyu.kim at lge dot com]

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

--- Comment #20 from Honggyu Kim  ---
Hi all,

Kyrill submitted a bug fix patch about 2 weeks ago.
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01014.html

I have tested his patch and found that the problem is clearly fixed.
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01497.html

Can anyone please review and approve the patch to fix this bug before releasing
gcc-5.0.0?
Thanks,

Honggyu

[Bug target/65660] New: [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

Bug ID: 65660
   Summary: [5 Regression] 252.eon regression on bdver2 with
-Ofast
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Target: x86_64-*-*

Created attachment 35211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35211&action=edit
-fopt-info-vec difference

r220580 regressed 252.eon on bdver2 with -Ofast
(http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64/252_eon_big.png). 
Actually I didn't verify yet it was r220580 but the regression appeared in the
range 220566:220590.

Attached is the difference in -fopt-info-vec where '-' is r220579 and '+' is
r220580.

As expected we vectorize a lot more but also some basic-block vectorizations
are gone it seems (btw, stupid spec separates stdout and stderr so for .h files
we don't easily see what sources they were included from)

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #21 from James Greenhalgh  ---
As this has been failing since GCC 4.6.3, it is not a regression and therefore
Kyrill's fix would not be appropriate for Stage 4.

It may be that the release managers make an exception for this fix, given that
it can cause wrong-code generation on a primary target. Otherwise, I'd expect
this to get fixed in 6.0 and backported as appropriate. Richard/Jakub?

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Happens apparently also on Intel cpus, see PR65076 comment 37 .

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
http://gcc.opensuse.org/SPEC/CINT/sb-czerny-head-64/252_eon_recent.png

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #22 from ktkachov at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #21)
> As this has been failing since GCC 4.6.3, it is not a regression and
> therefore Kyrill's fix would not be appropriate for Stage 4.
> 
> It may be that the release managers make an exception for this fix, given
> that it can cause wrong-code generation on a primary target. Otherwise, I'd
> expect this to get fixed in 6.0 and backported as appropriate. Richard/Jakub?

Yeah, I agree it's not a regression on the release branches, but we did have
wrong-code fixes in stage4 before (like for PR 65235).
My fix should only ever trigger in the case where we would definitely
miscompile otherwise, and should not impact codegen in any other case.

I don't mind waiting till stage 1 and backporting later. Up to the
maintainers/release managers.

[Bug libstdc++/65659] STL containers not specialized for pointer value_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  ---
It would be a massive ABI break.

The compiler's ICF pass should be improved to merge the identical code instead.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Looks like we now vectorize using loop vect instead of basic-block
vectorization.  The overhead might be noticable.  For example

 ./ggSpectrum.h:48:4: note: loop vectorized
-./ggSpectrum.h:49:18: note: basic block vectorized
-./ggSpectrum.h:49:18: note: basic block vectorized
-ggPathDielectricMaterial.cc:36:60: note: basic block vectorized
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment

is all from ggPathDielectricMaterial.cc.

Not sure why we peel for alignment at all as bdver2 has
vec_align_load_cost == vec_unalign_load_cost == vec_store_cost (there isn't
any unaligned store cost but IIRC an unalinged store consumes two store buffers
thus aligning the stores might be profitable).

Btw, the loop in question is:

void Set(float d) {
   for (int i = 0; i < nComponents(); i++)
  data[i] = d;
}

where I can very well imagine that nComponents() is _not_ large enough to
warrant loop vectorization (data is an array of 8 floats).  nComponents()
returns constant 8.

With bdver2 we now have

t.c:4:20: note: vectorization_factor = 4, niters = 8
t.c:4:20: note: === vect_update_slp_costs_according_to_vf ===
cost model: prologue peel iters set to vf/2.
cost model: epilogue peel iters set to vf/2 because peeling for alignment is
unknown.
t.c:4:20: note: Cost model analysis:
  Vector inside of loop cost: 4
  Vector prologue cost: 8
  Vector epilogue cost: 0
  Scalar iteration cost: 4
  Scalar outside cost: 0
  Vector outside cost: 8
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 2
t.c:4:20: note:   Runtime profitability threshold = 3
t.c:4:20: note:   Static estimate profitability threshold = 3
t.c:4:20: note: epilog loop required

while generic has

t.c:4:20: note: vectorization_factor = 4, niters = 8
t.c:4:20: note: === vect_update_slp_costs_according_to_vf ===
cost model: prologue peel iters set to vf/2.
cost model: epilogue peel iters set to vf/2 because peeling for alignment is
unknown.
t.c:4:20: note: Cost model analysis:
  Vector inside of loop cost: 1
  Vector prologue cost: 11
  Vector epilogue cost: 2
  Scalar iteration cost: 1
  Scalar outside cost: 0
  Vector outside cost: 13
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 17
t.c:4:20: note:   Runtime profitability threshold = 16
t.c:4:20: note:   Static estimate profitability threshold = 16
t.c:4:20: note: not vectorized: vectorization not profitable.

somehow the prologue cost looks off for bdver2.

Testcase:

struct ggSpectrum {
void Set (float d)
  {
for (int i = 0; i < 8; i++)
  data[i] = d;
  }
float data[8];
};

void foo (ggSpectrum *s, float d)
{
  s->Set(d);
}

now the best course of action is of course to not even consider peeling
this loop for alignment ... (if it can otherwise vectorize).

I think we run into round-off errors with my fix on bdver2, I have a crude
fix for that.

[Bug tree-optimization/65661] New: ICE in operator[], at vec.h:736, called from partition_view_init

[vries at gcc dot gnu.org]

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

Bug ID: 65661
   Summary: ICE in operator[], at vec.h:736, called from
partition_view_init
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

$ gcc src/gcc/testsuite/c-c++-common/ubsan/object-size-9.c
src/gcc/testsuite/c-c++-common/ubsan/object-size-9.c: In function ‘f1’:
src/gcc/testsuite/c-c++-common/ubsan/object-size-9.c:17:1: internal compiler
error: in operator[], at vec.h:736
 f1 (struct T x, int i)
 ^
0x6b2ac0 vec::operator[](unsigned int)
/home/vries/gcc_versions/devel/src/gcc/vec.h:736
0xff2c45 partition_view_init
/home/vries/gcc_versions/devel/src/gcc/tree-ssa-live.c:314
0xff2f25 partition_view_bitmap(_var_map*, bitmap_head*, bool)
/home/vries/gcc_versions/devel/src/gcc/tree-ssa-live.c:394
0xfc9ccd coalesce_ssa_name()
/home/vries/gcc_versions/devel/src/gcc/tree-ssa-coalesce.c:1335
0xf4d560 remove_ssa_form
/home/vries/gcc_versions/devel/src/gcc/tree-outof-ssa.c:1018
0xf4dee5 rewrite_out_of_ssa(ssaexpand*)
/home/vries/gcc_versions/devel/src/gcc/tree-outof-ssa.c:1252
0x823ef3 execute
/home/vries/gcc_versions/devel/src/gcc/cfgexpand.c:5932
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/65661] ICE in operator[], at vec.h:736, called from partition_view_init

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
At -O2, it's called from parition_to_var:
...
$ gcc src/gcc/testsuite/c-c++-common/ubsan/object-size-9.c -O2
src/gcc/testsuite/c-c++-common/ubsan/object-size-9.c: In function ‘f1’:
src/gcc/testsuite/c-c++-common/ubsan/object-size-9.c:97:1: internal compiler
error: in operator[], at vec.h:736
 }
 ^
0x6b2ac0 vec::operator[](unsigned int)
/home/vries/gcc_versions/devel/src/gcc/vec.h:736
0xfcd71c partition_to_var
/home/vries/gcc_versions/devel/src/gcc/tree-ssa-live.h:107
0xfce796 execute
/home/vries/gcc_versions/devel/src/gcc/tree-ssa-copyrename.c:469
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

[Bug tree-optimization/65661] ICE in operator[], at vec.h:736, called from partition_view_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Duh, I can't reproduce.  Hasn't this been by any chance already fixed?

[Bug tree-optimization/65661] ICE in operator[], at vec.h:736, called from partition_view_init

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
r221833

Configured with: src/configure --prefix=lean-c/install --with-cloog=infra
--with-ppl=infra --with-gmp=infra --with-mpfr=infra --with-mpc=infra
--disable-bootstrap --enable-checking=yes,rtl --enable-languages=c

[Bug target/53539] Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug sanitizer/64078] FAIL: c-c++-common/ubsan/object-size-9.c

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-02
 CC||vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from vries at gcc dot gnu.org ---
I have seen this a couple of times as well on x86_64.

Next time I encounter it, I'll try to post the full FAIL message, I think the
FAIL message is longer than one line. The line producing the failure looks
like:
...
fail "$name output pattern test, is ${output}, should
match $texttmp"
...

[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #9 from Florian Weimer  ---
On x86-64, Both jemalloc and tcmalloc return 8 byte aligned pointers for sizes
of 8 and less.  It's not true that malloc guarantuees 16-byte alignment there. 
You cannot look at glibc malloc implementation details and infer ABI properties
from that.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
With a true fix I get

t.c:3:20: note: Cost model analysis:
  Vector inside of loop cost: 4
  Vector prologue cost: 13
  Vector epilogue cost: 11
  Scalar iteration cost: 4
  Scalar outside cost: 0
  Vector outside cost: 24
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 7
t.c:3:20: note:   Runtime profitability threshold = 6
t.c:3:20: note:   Static estimate profitability threshold = 6

thus we still vectorize the loop for bdver2.  This is because of an oddity
in its cost model which has

  6,/* scalar_stmt_cost.  */
  4,/* scalar load_cost.  */
  4,/* scalar_store_cost.  */
  6,/* vec_stmt_cost.  */
  0,/* vec_to_scalar_cost.  */
  2,/* scalar_to_vec_cost.  */
  4,/* vec_align_load_cost.  */
  4,/* vec_unalign_load_cost.  */
  4,/* vec_store_cost.  */
  2,/* cond_taken_branch_cost.  */
  1,/* cond_not_taken_branch_cost.  */

and thus the prologue/epilogue is not pessimized enough for the extra
branches (which are very cheap compared to the scalar and vector stmt costs).

I am still testing the patch to avoid the round-off errors and really account
scalar stmts correctly.

I suppose the EON regression should be fixed by instead avoiding the
peeling for alignment with a better idea on cost.

[Bug tree-optimization/65661] ICE in operator[], at vec.h:736, called from partition_view_init

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
x86_64?

[Bug tree-optimization/65661] ICE in operator[], at vec.h:736, called from partition_view_init

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from vries at gcc dot gnu.org ---
I ran into this problem with what I thought was a clean rebuild, but after
doing another clean rebuild, it doesn't reproduce anymore. So it must have been
my error.

Marking resolved, invalid.

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
(In reply to ktkachov from comment #22)
> (In reply to James Greenhalgh from comment #21)
> > As this has been failing since GCC 4.6.3, it is not a regression and
> > therefore Kyrill's fix would not be appropriate for Stage 4.
> > 
> > It may be that the release managers make an exception for this fix, given
> > that it can cause wrong-code generation on a primary target. Otherwise, I'd
> > expect this to get fixed in 6.0 and backported as appropriate. 
> > Richard/Jakub?
> 
> Yeah, I agree it's not a regression on the release branches, but we did have
> wrong-code fixes in stage4 before (like for PR 65235).
> My fix should only ever trigger in the case where we would definitely
> miscompile otherwise, and should not impact codegen in any other case.
> 
> I don't mind waiting till stage 1 and backporting later. Up to the
> maintainers/release managers.

It's fine to fix wrong-code regressions in stage4 if they are obviously safe.

[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Then jemalloc and tcmalloc are just broken on x86_64.

[Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with "vector"

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr  2 11:54:58 2015
New Revision: 221838

URL: https://gcc.gnu.org/viewcvs?rev=221838&root=gcc&view=rev
Log:
PR preprocessor/61977
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Don't
predefine __vector/__bool/__pixel macros nor context sensitive
macros for CLK_ASM.
* config/spu/spu-c.c (spu_cpu_cpp_builtins): Similarly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/spu/spu-c.c

[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #35174|0   |1
is obsolete||

--- Comment #11 from Iain Sandoe  ---
Created attachment 35212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35212&action=edit
minimum change

OK - So Jakub's patch works with a minor change (quote the two components) viz:

-$1=-fno-common
+$1='-fno-common -mno-dynamic-no-pic'


1. the minimum change to fix this bug is to reconfigure libiberty with the
changed picflag.m4 (the attached patch includes the regenerated
libiberty/configure so that folks can test if they like).
 -- Perhaps we should extend that to all cases where */configure.ac calls
GCC_PICFLAG (although it's not needed for this pr, it might save confusion when
someone subsequently reconfigures).

2. I investigated --enable-host-shared and this seems to be a can of worms.
 - some places in the GCC tree just don't consider the possibility that the
host/target might need pic options
 - most places just jam -fPIC regardless of the host.
 - if I go through all of these cases and add in GCC_PICFLAG /
GCC_PICFLAG_TARGET as appropriate I can get --enable-host-shared builds to
complete on m32 darwin (but it doesn't seem like stage4 change and isn't a
regression in any case).
 - Even on x86_64 linux I don't see --enable-host-shared producing any .so for
these host-side libs (it seems to just generate convenience libs with PIC
code).
 - It's possible that some other places should be linking the PIC version of
libiberty (e.g. libsupc++) …

- I need to test this minimum change on a couple more boxes.

[Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with "vector"

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr  2 11:57:02 2015
New Revision: 221839

URL: https://gcc.gnu.org/viewcvs?rev=221839&root=gcc&view=rev
Log:
PR preprocessor/61977
* lex.c (cpp_peek_token): Temporarily clear pfile->cb.line_change.

* gcc.target/powerpc/pr61977-1.c: New test.
* gcc.target/powerpc/pr61977-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr61977-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr61977-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00053.html

C testcase:

void Set (float d, float *data)
{
  for (int i = 0; i < 8; i++)
data[i] = d;
}

note that I didn't really verify it is that specific vectorization causing the
slowdown.  It just appears a lot in the diff.  As said we should recognize
that peeling for alignment is stupid here.  Will produce a patch for that as
well.

[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Thanks for fixing that thinko.  Please regenerate not just libiberty/configure,
but also {gcc,libada,libgcc}/configure too.
The patch is ok for trunk with those changes with proper ChangeLog entry and
when posted to gcc-patches.
I agree --enable-host-shared for darwin can certainly wait for stage1 or for
whenever later anybody is actually interested in that on darwin.

[Bug preprocessor/61977] [4.8/4.9/5 Regression] powerpc preprocessor breaks on lines that end with "vector"

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Two out of the 3 patches applied to trunk, still waiting for review of the
first patch.

[Bug libstdc++/65641] unordered_map - __detail::_Mod_range_hashing is slow

[j.breitbart at tum dot de]

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

--- Comment #2 from Jens Breitbart  ---
Thanks for the link. I am not sure if there is really any benefit of using
libdivide instead of the masking.

I'll attach a first version of patch in which the functor stores the mask. Any
comments welcome, I am not familiar with the library.

Another possible solution would be to allow the number of buckets to be a power
of two, as one can easily compute the mask for such cases. This could be
triggered by the user explicitly calling rehash() with a power of two as the
parameter. Increasing the number of buckets would only increase to another
power of two. _Mod_range_hashing could check if the number of buckets is a
power of two and use masking in that case. This would not require an ABI
change.

Any chance of getting such a change upstream? As far as I can see, there seems
to be no easy way to have the unorered_map use our folding functor instead of
_Mod_range_hashing or am I missing something?

[Bug tree-optimization/48620] many libstdc++ tests FAIL with -m32 -fno-early-inlining -fipa-pta

[j.breitbart at tum dot de]

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

Jens Breitbart  changed:

   What|Removed |Added

 CC||j.breitbart at tum dot de

--- Comment #2 from Jens Breitbart  ---
Created attachment 35213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35213&action=edit
Add _mask_range_hashing to hashtable_policy.h v1

[Bug sanitizer/65662] New: AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

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

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

Bug ID: 65662
   Summary: AddressSanitizer CHECK failed:
../../../../gcc/libsanitizer/sanitizer_common/sanitize
r_allocator.h:835 "((res)) < ((kNumPossibleRegions))"
(0x3ffb49, 0x8)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, rguenther 
at suse dot de
Target: aarch64-*-*

Breakpoint 1, ComputeRegionId (this=0x3ffb737bd60 <__asan::allocator>, 
mem=4396780879872)
at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835
835 CHECK_LT(res, kNumPossibleRegions);
(gdb) p/x mem
$2 = 0x3ffb490

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

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

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug libstdc++/65641] unordered_map - __detail::_Mod_range_hashing is slow

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-02
 CC||fdumont at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jens Breitbart from comment #2)
> Another possible solution would be to allow the number of buckets to be a
> power of two, as one can easily compute the mask for such cases. This could
> be triggered by the user explicitly calling rehash() with a power of two as
> the parameter. Increasing the number of buckets would only increase to
> another power of two. _Mod_range_hashing could check if the number of
> buckets is a power of two and use masking in that case. This would not
> require an ABI change.

That sounds promising, and worth pursuing.

> Any chance of getting such a change upstream?

I don't see why not, although unless you have a GCC copyright assignment on
file, or plan to get one (immediately, since it can take a while) it's better
*not* to give us a patch, because we can't use it anyway and there can be no
danger of using your code if we don't see it!

> As far as I can see, there
> seems to be no easy way to have the unorered_map use our folding functor
> instead of _Mod_range_hashing or am I missing something?

I think you would need to use the _Hastable class template directly, rather
than via std::unordered_map. In theory that allows you to re-use the internals
with different policies, but in practice it's not very easy.

[Bug tree-optimization/48620] many libstdc++ tests FAIL with -m32 -fno-early-inlining -fipa-pta

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jens Breitbart from comment #2)
> Created attachment 35213 [details]
> Add _mask_range_hashing to hashtable_policy.h v1

Jens, I think you meant to attach this to PR65641, but as I said there, unless
you have a copyright assignment we can't use it anyway.

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
There are dups for this already.
The issue is that aarch64-linux has 3 very much different virtual address space
sizes and stock libsanitizer supports only the smallest one.  I have a patch
for supporting the middle-one, see e.g.
http://pkgs.fedoraproject.org/cgit/gcc.git/tree/gcc5-libsanitize-aarch64-va42.patch
but supporting all 3 virtual address space sizes requires more changes
upstream, because the smallest virtual address space size is really too small
for anything usable.

[Bug tree-optimization/48620] many libstdc++ tests FAIL with -m32 -fno-early-inlining -fipa-pta

[j.breitbart at tum dot de]

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

--- Comment #4 from Jens Breitbart  ---
Yes, sorry, not sure how this happened.

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org
   Target Milestone|5.0 |---

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #1)
> There are dups for this already.
> The issue is that aarch64-linux has 3 very much different virtual address
> space sizes and stock libsanitizer supports only the smallest one.  I have a
> patch for supporting the middle-one, see e.g.
> http://pkgs.fedoraproject.org/cgit/gcc.git/tree/gcc5-libsanitize-aarch64-
> va42.patch
> but supporting all 3 virtual address space sizes requires more changes
> upstream, because the smallest virtual address space size is really too
> small for anything usable.

The largest one is required to be supported for Cavium's ThunderX in a dual
socket case.  Can we declare address santizer broken for GCC 5 for AARCH64 due
to this?

I think MIPS has a similar issue too when different page sizes are used but
nobody upstream has reported it yet.

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I think it was a serious mistake to officially add support for it when it only
works on one of the 3 configurations.  Unfortunately there has not really been
any progress on this in the past 3 month since it has been reported, netierh
from aarch64 maintainers nor upstream.

[Bug c++/65642] [5 Regression] [C++11] GCC rejects valid constant expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Created attachment 35214
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35214&action=edit
pr65642.patch

Untested patch for example 1 and 3.

[Bug c++/65642] [5 Regression] [C++11] GCC rejects valid constant expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
(In reply to Marek Polacek from comment #3)
> Created attachment 35214 [details]
> pr65642.patch
> 
> Untested patch for example 1 and 3.

1 and 2.  3 is different.

[Bug sanitizer/64078] FAIL: c-c++-common/ubsan/object-size-9.c

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 35215
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35215&action=edit
relevant bit of gcc.log

> Next time I encounter it, I'll try to post the full FAIL message

I ran into this while testing an AFAIU unrelated patch.

I suppose the output scan fails because of the ''
messages. I have no idea whether those messages indicate a problem, or are
harmless.

[Bug c++/57712] GCC fails to to match out-of-line template member function definition with declaration

[stanshebs at earthlink dot net]

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

Stan Shebs  changed:

   What|Removed |Added

 CC||stanshebs at earthlink dot net

--- Comment #1 from Stan Shebs  ---
This bug seems to have manifested itself at Google in the following form:

struct S {
template int g(B b);
template auto h(B b) -> decltype(g(b));
  };
  template auto S::h(B b) -> decltype(g(b)) { return g(b); }

Clang likes it fine, but it still occurs for a couple-weeks-ago GCC:

tre.cc:5:27: error: prototype for ‘decltype (((S*)this)->S::g(b)) S::h(B)’ does
not match any in class ‘S’
 template auto S::h(B b) -> decltype(g(b)) { return g(b); }
   ^
tre.cc:3:31: error: candidate is: template decltype
(((S*)this)->S::g(b)) S::h(B)
 template auto h(B b) -> decltype(g(b));

[Bug target/65647] [5 Regression] GCC won't stop when compile for armv6-m

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
I've reproduced the problem too.  Such problems needs a lot of time to analyze
and fix but I hope to fix it at the beginning of next week.

[Bug libstdc++/65663] New: libstdc++: writing mixed-size blocks through an std::ofstream to a SMB 2.1 share produces file corruption

[kkananen at gmail dot com]

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

Bug ID: 65663
   Summary: libstdc++: writing mixed-size blocks through an
std::ofstream to a SMB 2.1 share produces file
corruption
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kkananen at gmail dot com

Created attachment 35216
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35216&action=edit
Preprocessed minimum-repro.ii

Basic description of the problem:
Application writing into a libstdc++ ofstream from a Mac OS X 10.9 or 10.10
host to a samba shared folder hosted on Windows 7/8/2008 Server (the
combination of OS X + Windows has to support SMB 2.1) can produce file
corruption.

Reproductions steps:
You need two PCs visible to each other in a network: 
  a. a Mac running OS X 10.9 or later
  b. a Windows 7, Windows Server 2008 R2 or later PC.

1. Share a test folder on the Windows PC so that it is visible for the Mac in 
  the network

2. Connect the Mac to the windows shared folder using the smb protocol:
  e.g. in OSX Finder, connect to server smb://name-of-windows-pc/name-of-share
  (the share should now be visible under /Volumes/name-of-share/)

3. Compile this application on the Mac against libstdc++
  e.g. apple clang 5.0:
clang++ ./minimum-repro.cpp -stdlib=libstdc++ -o minimum-repro
   g++ (4.0 or later):
g++ ./minimum-repro.cpp -o minimum-repro

4. Run the compiled app on the Mac, with a single argument, a path to a file on
the 
  network share:
  e.g. ./minimum-repro /Volumes/name-of-share/corruption-test.txt


The file will be written and it's contents read back and checked against the
reference - they will not match in contents, i.e. the file has been corrupted
on write.


The key to bug reproduction is to first write a small block of data (< 1022
bytes) and then a large block (> 0.5 MB) into an ofstream opened on the shared
folder. The file will be corrupt from the 0.5 MB mark onwards.

Flushing the ofstream between the writes, writing smaller blocks all make the
problem go away.


Built on OS X 10.8.5 and 10.9 with g++ 4.0.1, 4.2.1 and apple clang 5.0 and 5.1
using libstdc++ (6.0.9).

Tested on OS X 10.9, 10.10 (host) and Windows 7 and 8 (file server).

Version information:
$ g++-4.0 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc_40/gcc_40-5494~315/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5494)

$ g++-4.2 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

$ clang++ -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

$ clang++ -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix


Command-line to compile:
g++: g++ ./minimum-repro.cpp -o ./minimum-repro
clang: clang++ ./minimum-repro.cpp -stdlib=libstdc++ -o ./minimum-repro

[Bug libstdc++/65663] libstdc++: writing mixed-size blocks through an std::ofstream to a SMB 2.1 share produces file corruption

[kkananen at gmail dot com]

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

--- Comment #1 from Kaarlo Kananen  ---
Created attachment 35217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35217&action=edit
Original minimal reproduction .cpp

Full minimal reproduction source .cpp

[Bug ipa/65655] [5 Regression] ICE in speculative_call_info, at cgraph.c:1151

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Mine.

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

[kcc at gcc dot gnu.org]

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

--- Comment #4 from Kostya Serebryany  ---
AArch64 is being discussed at
https://groups.google.com/forum/#!topic/address-sanitizer/YzYRJEvVimw
Please join the discussion. 
We, the primary maintainers of asan, have no access to AArch64 boxes yet, 
so we rely on others here.

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

[kcc at gcc dot gnu.org]

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

--- Comment #5 from Kostya Serebryany  ---
AArch64 is being discussed at
https://groups.google.com/forum/#!topic/address-sanitizer/YzYRJEvVimw
Please join the discussion. 
We, the primary maintainers of asan, have no access to AArch64 boxes yet, 
so we rely on others here.

[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Thanks!
The resolution file is wrong:
1
test.o 1
172 795d441a PREEMPTED_REG main

the resolution of main() should be PREVAILING_DEF_IRONLY. PREEMTED_REG is
defined as follows:
PREEMPTED_REG (this definition was pre-empted by a definition in a regular
object file) 

This is linker bug. It basicaly instructs GCC to drop the definition of main
because it is defined elsewhere.

However GCC is not ready for non-weak symbol to be preemted and produces the
function into final binary anyway:

.file   ""
.def__main; .scl2;  .type   32; .endef
.text
.globl  main
.defmain;   .scl2;  .type   32; .endef
.seh_proc   main
main:
subq$40, %rsp
.seh_stackalloc 40
.seh_endprologue
call__main
movl$0, %eax
addq$40, %rsp
ret
.seh_endproc
.ident  "GCC: (GNU) 5.0.0 20150326 (experimental) [trunk revision
221697]"

Is something wrong with this assembly? How does the testecase comile w/o LTO?

[Bug ipa/65654] [5 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-04-02
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
I will take a look, too.

[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-04/msg3.html

[Bug c++/65625] [5 Regression] ICE in make_typename_type, at cp/decl.c:3499

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Thu Apr  2 16:43:02 2015
New Revision: 221842

URL: https://gcc.gnu.org/viewcvs?rev=221842&root=gcc&view=rev
Log:
PR c++/65625
* decl.c (make_typename_type): Handle seeing a variable template.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ23.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c++/65625] [5 Regression] ICE in make_typename_type, at cp/decl.c:3499

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/65642] [5 Regression] [C++11] GCC rejects valid constant expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu Apr  2 16:51:27 2015
New Revision: 221843

URL: https://gcc.gnu.org/viewcvs?rev=221843&root=gcc&view=rev
Log:
PR c++/65642
* constexpr.c (cxx_eval_pointer_plus_expression): Call
cxx_eval_constant_expression on the first operand.

* g++.dg/cpp0x/constexpr-fold1.C: New test.
* g++.dg/cpp0x/constexpr-fold2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-fold1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-fold2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

[rai...@emrich-ebersheim.de]

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

--- Comment #12 from Rainer Emrich  ---
Created attachment 35218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35218&action=edit
Test case compiled without -flto.

This without -flto.

By the way ld is:
GNU ld (GNU Binutils) 2.25.51.20150326

[Bug bootstrap/65664] New: ARM bootstrap fails with --with-fpu=neon-vfpv4

[lukacs at topgroups dot ca]

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

Bug ID: 65664
   Summary: ARM bootstrap fails with --with-fpu=neon-vfpv4
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukacs at topgroups dot ca
  Host: arm-slackware-linux-gnueabi
Target: arm-slackware-linux-gnueabi
 Build: arm-slackware-linux-gnueabi

Created attachment 35219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35219&action=edit
Compilation logs

configuration parameters include:

--with-cpu=cortex-a7 --with-tune=cortex-a7 --with-arch=armv7-a
--with-float=softfp  --with-fpu=neon-vfpv4 --disable-werror

and produces:

/bin/sh ./libtool  --tag=CC   --mode=compile
/home/woland/tmp/build-gcc/gcc.build.lnx/./gcc/xgcc
-B/home/woland/tmp/build-gcc/gcc.build.lnx/./gcc/
-B/usr/arm-slackware-linux-gnueabi/bin/ -B/usr/arm-slackware-linux-gnueabi/lib/
-isystem  /usr/arm-slackware-linux-gnueabi/include -isystem
/usr/arm-slackware-linux-gnueabi/sys-include-DHAVE_CONFIG_H -I.
-I../../../gcc-4.8.4/libgo  -I ../../../gcc-4.8.4/libgo/runtime
-I../../../gcc-4.8.4/libgo/../libffi/include -I../libffi/include -pthread 
-fexceptions -fplan9-extensions  -Wall -Wextra -Wwrite-strings -Wcast-qual  
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
../../../gcc-4.8.4/libgo/../libgcc -I ../../../gcc-4.8.4/libgo/../libbacktrace
-I ../../gcc/include -g -O2 -march=armv7-a -mtune=cortex-a7 -mfloat-abi=softfp
-MT go-type-complex.lo -MD -MP -MF .deps/go-type-complex.Tpo -c -o
go-type-complex.lo `test -f 'runtime/go-type-complex.c' || echo
'../../../gcc-4.8.4/libgo/'`runtime/go-type-complex.c
libtool: compile:  /home/woland/tmp/build-gcc/gcc.build.lnx/./gcc/xgcc
-B/home/woland/tmp/build-gcc/gcc.build.lnx/./gcc/
-B/usr/arm-slackware-linux-gnueabi/bin/ -B/usr/arm-slackware-linux-gnueabi/lib/
-isystem /usr/arm-slackware-linux-gnueabi/include -isystem
/usr/arm-slackware-linux-gnueabi/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.8.4/libgo -I ../../../gcc-4.8.4/libgo/runtime
-I../../../gcc-4.8.4/libgo/../libffi/include -I../libffi/include -pthread
-fexceptions -fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
../../../gcc-4.8.4/libgo/../libgcc -I ../../../gcc-4.8.4/libgo/../libbacktrace
-I ../../gcc/include -g -O2 -march=armv7-a -mtune=cortex-a7 -mfloat-abi=softfp
-MT go-type-complex.lo -MD -MP -MF .deps/go-type-complex.Tpo -c
../../../gcc-4.8.4/libgo/runtime/go-type-complex.c  -fPIC -DPIC -o
.libs/go-type-complex.o
../../../gcc-4.8.4/libgo/runtime/go-type-complex.c: In function
'__go_type_hash_complex':
../../../gcc-4.8.4/libgo/runtime/go-type-complex.c:87:1: error: unrecognizable
insn:
 }
 ^
(insn 99 98 100 17 (set (reg:DI 175 [ D.9567 ])
(unspec:DI [
(mem/c:DI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -24 [0xffe8])) [6  S8 A32])
] UNSPEC_MISALIGNED_ACCESS))
../../../gcc-4.8.4/libgo/runtime/go-type-complex.c:51 -1
 (nil))
../../../gcc-4.8.4/libgo/runtime/go-type-complex.c:87:1: internal compiler
error: in extract_insn, at recog.c:2154
0x38cb63 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.8.4/gcc/rtl-error.c:109
0x38cbb7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.8.4/gcc/rtl-error.c:117
0x35f1af extract_insn(rtx_def*)
../../gcc-4.8.4/gcc/recog.c:2154
0x2611e7 instantiate_virtual_regs_in_insn
../../gcc-4.8.4/gcc/function.c:1565
0x2611e7 instantiate_virtual_regs
../../gcc-4.8.4/gcc/function.c:1932
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [go-type-complex.lo] Error 1
make[4]: Leaving directory
`/home/woland/tmp/build-gcc/gcc.build.lnx/arm-slackware-linux-gnueabi/libgo'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/woland/tmp/build-gcc/gcc.build.lnx/arm-slackware-linux-gnueabi/libgo'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/woland/tmp/build-gcc/gcc.build.lnx/arm-slackware-linux-gnueabi/libgo'
make[1]: *** [all-target-libgo] Error 2
make[1]: Leaving directory `/home/woland/tmp/build-gcc/gcc.build.lnx'
make: *** [bootstrap] Error 2

If --with-fpu=neon-vfpv4 is removed, then it compiles fine.

[Bug bootstrap/65664] ARM bootstrap fails with --with-fpu=neon-vfpv4

[lukacs at topgroups dot ca]

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

--- Comment #1 from Gabor Lukacs  ---
Created attachment 35220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35220&action=edit
Preprocessed source

[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression

[skunk at iskunk dot org]

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

--- Comment #6 from Daniel Richard G.  ---
My admin installed 119961-13, which is the current version of 119961-11:

$ /usr/ccs/bin/as -V
as: SunOS 5.10 119961-13 Patch 08/06/2014
 Usage: as [-a32] [-m] [-m32] [-m64] [-n]
[...]

I'm still getting the same assembler error.

[Bug libstdc++/65663] libstdc++: writing mixed-size blocks through an std::ofstream to a SMB 2.1 share produces file corruption

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-04-02
Version|unknown |4.2.1
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Kaarlo Kananen from comment #0)
> Built on OS X 10.8.5 and 10.9 with g++ 4.0.1, 4.2.1 and apple clang 5.0 and
> 5.1 using libstdc++ (6.0.9).

Your version of libstdc++ is *ancient* (at least 7 years old) and not supported
or maintained.

Please either report it to Apple, who provided you with the ancient library, or
try with a newer version of libstdc++.

[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)

[chip at pobox dot com]

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

--- Comment #11 from Chip Salzenberg  ---
Indeed, 16 is required by the ABI; see
http://www.x86-64.org/documentation/abi.pdf page 12.  Only the SIMD __m256 is
bigger than 16, and there seems no end to Intel's extensions to SIMD registers,
so holding at 16 seems like the Right Thing.

[Bug libstdc++/53838] _GLIBCXX_DEBUG and empty ostringstream

[tom at kera dot name]

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

Tomalak Geret'kal  changed:

   What|Removed |Added

 CC||tom at kera dot name

--- Comment #6 from Tomalak Geret'kal  ---
Not a GCC bug? Really? I beg to differ.

 - Bug 54173
 - Bug 33021
 - Bug 64504

[Bug target/65581] [5 Regression] testsuite lto issue: multiple definition of `main', undefined reference to `WinMain'

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  ---
Rainer,
the compiled code (test.s) is identical to what LTO path produces, so I am
convinced this is a bug at binutils side.  Would you please mind filling up the
PR?

There are two issues at least - first is that the resolution of main should be
PREVAILING_DEF and second that it should not fail with undefined symbol.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #54 from Jan Hubicka  ---
I have full set of firefox talos benchmarks with inline-unit-growth bumped back
to 30 (I did not test default value by accident, but I am running itnow). We
now get back the GCC 4.9 performance on dromaeo_dom/dromaeo_css that was
troubling me most. We also get improvement on tsvgx and the startup time
benchmark (where mainline is already on par with GCC 4.9 after the wrapper
fix).

I am definitely surprised - I originally introduced the relative benefits as a
hack to get around value range limitation in the fixed point badness metric,
but the explanation about many average size functions being better for code
generation that case of some very small and some very big seems reasonable. 
The combined badness metric kind of consider function growth and unit growth to
be both limiting factors as they are.

Given the benchmark results, I think we should go ahead with the change. I will
work out the preferred limits for overall-unit-growth based on firefox
incrementally. Also we need to reconsider FDO metric. It seems that new one
works better for tramp3d and spec, I will re-check how it behaves on firefox.

[Bug bootstrap/65664] ARM bootstrap fails with --with-fpu=neon-vfpv4

[lukacs at topgroups dot ca]

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

--- Comment #2 from Gabor Lukacs  ---
If 

--with-fpu=neon-vfpv4

is replaced with 

--with-fpu=vfpv4 

then bootstrap works fine.

[Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #1 from Hans-Peter Nilsson  ---
Isn't this a dup of bug 64986?  Or bug 63205?

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  ---
JFTR: starting with a revision in the range (221618:221635] this fails somewhat
similarly for cris-elf; the simulator reports an invalid memory access (any
optimization level, different addresses) like so:

PASS: gfortran.dg/class_to_type_4.f90   -O0  (test for excess errors)
core: 4 byte read to unmapped address 0x63af0 at 0x2080c
program stopped with signal 11 (Segmentation fault).
FAIL: gfortran.dg/class_to_type_4.f90   -O0  execution test

[Bug ipa/65655] [5 Regression] ICE in speculative_call_info, at cgraph.c:1151

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Hmm it is interesting case, we try to resolve speculation while we are
duplicating it. I am testing the following

Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c   (revision 221845)
+++ ipa-inline-analysis.c   (working copy)
@@ -793,7 +793,11 @@ edge_set_predicate (struct cgraph_edge *
 {
   /* If the edge is determined to be never executed, redirect it
  to BUILTIN_UNREACHABLE to save inliner from inlining into it.  */
-  if (predicate && false_predicate_p (predicate))
+  if (predicate && false_predicate_p (predicate)
+  /* When handling speculative edges, we need to do the redirection
+ just once.  Do it always on the direct edge, so we do not
+attempt to resolve speculation while duplicating the edge.  */
+  && (!e->speculative || e->callee))
 e = redirect_to_unreachable (e);

   struct inline_edge_summary *es = inline_edge_summary (e);

[Bug libstdc++/53838] _GLIBCXX_DEBUG and empty ostringstream

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
One of those bugs is apparently not present in 4.2 or later, are you sure it's
the same?

Do you have a reproducible testcase to show the bug, not just "use macports, it
breaks"? or only links to other reports that show up for related search terms?

[Bug libstdc++/53838] _GLIBCXX_DEBUG and empty ostringstream

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
i.e. do you have the exact commands to build a gcc that shows the problem?

So it can be reproduced from a clean source tarball, without external
dependencies.

[Bug middle-end/65665] New: [5.0 Regression]: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none

[hp at gcc dot gnu.org]

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

Bug ID: 65665
   Summary: [5.0 Regression]: g++.dg/torture/pr64378.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, lto
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Host: x86_64-linux-gnu
Target: cris-elf

This test passed before, but since a revision in the range (221794:221800],
this test fails as follows:

Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/dg-torture.exp
...
FAIL: g++.dg/torture/pr64378.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
FAIL: g++.dg/torture/pr64378.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)

In g++.log (cutnpasted):
Executing on host:
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/g++/../../xg++
-B/tmp/hpautotest-gcc1/cris-elf/gcc
obj/gcc/testsuite/g++/../../
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/pr64378.C 
-fno-diagnostics-show-care
t -fdiagnostics-color=never  -nostdinc++
-I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -
I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include
-I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++ -I
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/include/backward
-I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/util -fmessage-
length=0   -O2 -flto -fno-use-linker-plugin -flto-partition=none  -fno-ipa-cp 
-S   -isystem /tmp/hpautotest-gcc1/cris-e
lf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include   -o pr64378.s(timeou
t = 300)
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/pr64378.C:24:1: internal
compiler error: Segmentation fault
0xbbbd85 crash_signal
/tmp/hpautotest-gcc1/gcc/gcc/toplev.c:383
0xf76aee vec::operator[](unsigned int)
/tmp/hpautotest-gcc1/gcc/gcc/vec.h:736
0xf76aee vec::operator[](unsigned int)
/tmp/hpautotest-gcc1/gcc/gcc/vec.h:1202
0xf76aee ipa_is_param_used
/tmp/hpautotest-gcc1/gcc/gcc/ipa-prop.h:405
0xf76aee ipa_icf::sem_item_optimizer::update_hash_by_addr_refs()
/tmp/hpautotest-gcc1/gcc/gcc/ipa-icf.c:2504
0xf76dd5 ipa_icf::sem_item_optimizer::execute()
/tmp/hpautotest-gcc1/gcc/gcc/ipa-icf.c:2394
0xf77f7e ipa_icf_driver
/tmp/hpautotest-gcc1/gcc/gcc/ipa-icf.c:3304
0xf77f7e ipa_icf::pass_ipa_icf::execute(function*)
/tmp/hpautotest-gcc1/gcc/gcc/ipa-icf.c:3351
Please submit a full bug report,

Judging from the actual changes in the revision range and from the backtrace, I
think it's the ipa-icf.c change rather than any of the other changes (e.g. lto
despite the -flto required to trig this), hence the single CC. I'll also bisect
further.

[Bug middle-end/65665] [5.0 Regression]: g++.dg/torture/pr64378.C -O2 -flto -fno-use-linker-plugin -flto-partition=none

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  ---
The cutnpasted backtrace was from revision 221841.

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

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

--- Comment #16 from Hans-Peter Nilsson  ---
(In reply to Jonathan Wakely from comment #14)
> Can we close this?

No.  IIUC, we're still/again using __atomic_is_lock_free with alignment deduced
from the current object rather than the type (even though it's now a
proxy-object; the faked pointer is constructed from the alignment of the
current object).

So, r221701 was wrong to change from null to the alignment-deduced
fake-pointer.

[Bug libstdc++/62259] atomic class doesn't enforce required alignment on powerpc64

[hp at gcc dot gnu.org]

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

--- Comment #8 from Hans-Peter Nilsson  ---
(In reply to Andrew Macleod from comment #4)
> Yeah... up until now, CRIS was the only port that this was an issue for.

And JFTR, the resolution to this PR doesn't solve the similar issue there. (To
wit, increasing alignment up to *that of an integer of* the natural size which
is not the same as "increasing alignment up to the natural size" which would
work.)

> The original C11 work had an extension  __attribute__(atomic)  which would
> do the same thing the _Atomic keyword does for non C11 compilation, and the
> type in the libstdc++ atomic classes would be given this attribute.

This would work.

[Bug middle-end/34010] [4.8/4.9 Regression] ppc64 bad stdargs codegen for zero sized objects

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #12 from amker at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #11)
> Hi Aldy,
> 
> If the only thing failing is -m32 -mpowerpc64, that is likely another
> problem.  Not likely a regression either (but I don't have testresults
> around going back more than a year or so; it failed then).

Hmm, I saw same case failed at least on aarch64 bigendian, fsf-4.9 branch.

Not sure if same with this one, Here is log message:

spawn /.../obj/gcc2/gcc/xgcc -B/.../obj/gcc2/gcc/ -fno-diagnostics-show-caret
-fdiagnostics-color=never -w
-I/projects/.../src/gcc/gcc/testsuite/gcc.dg/compat -Wno-abi
-DSKIP_DECIMAL_FLOAT -c -specs=aem-validation.specs -o c_compat_x_tst.o
/.../obj/gcc2/gcc/testsuite/gcc10/gcc.dg-struct-layout-1//t028_x.c
In file included from
/.../obj/gcc2/gcc/testsuite/gcc10/gcc.dg-struct-layout-1//t028_x.c:10:0:
/.../obj/gcc2/gcc/testsuite/gcc10/gcc.dg-struct-layout-1//t028_test.h: In
function 'checkx2823':
/projects/.../src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1_x2.h:11:22:
internal compiler error: Segmentation fault
/projects/.../src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.h:777:27:
note: in expansion of macro 'TX'
/.../obj/gcc2/gcc/testsuite/gcc10/gcc.dg-struct-layout-1//t028_test.h:24:1:
note: in expansion of macro 'T'
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
In file included from
/.../obj/gcc2/gcc/testsuite/gcc10/gcc.dg-struct-layout-1//t028_x.c:10:0:
/.../obj/gcc2/gcc/testsuite/gcc10/gcc.dg-struct-layout-1//t028_test.h: In
function 'checkx2823':
/projects/.../src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1_x2.h:11:22:
internal compiler error: Segmentation fault
/projects/.../src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.h:777:27:
note: in expansion of macro 'TX'
/.../obj/gcc2/gcc/testsuite/gcc10/gcc.dg-struct-layout-1//t028_test.h:24:1:
note: in expansion of macro 'T'
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o compile,  (internal
compiler error)