[Bug c/55584] __sync_fetch_and_* friends do not issue warnings when CPU does not support them natively

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is not needed any more as there is a libatomic which can be used to
implement all the non-implemented ones in the compiler.

If you don't link with libatomic you will get linker failures which should be
enough now.

[Bug target/55610] cc1 is calling munmap() on part of itself on darwin

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Does this work now?

[Bug libfortran/47149] failing build: execvp: /bin/sh: Argument list too long

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libfortran/47149] failing build: execvp: /bin/sh: Argument list too long

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-25
  Component|other   |libfortran
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
For target libraries, it does seem best to use a response file for linking.

[Bug tree-optimization/71987] New: ICE on valid code at -O1 and above on x86_64-linux-gnu: tree check: expected ssa_name, have addr_expr in get_ops, at tree-ssa-reassoc.c:3269

[su at cs dot ucdavis.edu]

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

Bug ID: 71987
   Summary: ICE on valid code at -O1 and above on
x86_64-linux-gnu: tree check: expected ssa_name, have
addr_expr in get_ops, at tree-ssa-reassoc.c:3269
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current GCC trunk at
-O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

This is a regression from 6.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160724 (experimental) [trunk revision 238696] (GCC) 
$ 
$ gcc-trunk -O0 small.c
$ gcc-6.1 -O1 small.c
$ 
$ gcc-trunk -O1 small.c
small.c: In function ‘fn2’:
small.c:8:6: internal compiler error: tree check: expected ssa_name, have
addr_expr in get_ops, at tree-ssa-reassoc.c:3269
 void fn2 ()
  ^~~
0xe7745c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9742
0xd81c18 tree_check
../../gcc-source-trunk/gcc/tree.h:3023
0xd81c18 get_ops
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:3269
0xd882ba maybe_optimize_range_tests
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:3523
0xd8e8f1 reassociate_bb
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5260
0xd8e187 reassociate_bb
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5469
0xd8e187 reassociate_bb
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5469
0xd90d3b do_reassoc
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5583
0xd90d3b execute_reassoc
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5670
0xd90d3b execute
../../gcc-source-trunk/gcc/tree-ssa-reassoc.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 





int a, b, *c, *d;

short fn1 (int p1)
{
  return a ? p1 : a;
}

void fn2 ()
{
  int e, *f = 
  b = fn1 (d != );
  c = f;
}

int main ()
{
  fn2 ();
  return 0;
}

[Bug c/71986] New: Bug bug when compiling gammu-1.37.3

[nequx at yandex dot ru]

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

Bug ID: 71986
   Summary: Bug bug when compiling gammu-1.37.3
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nequx at yandex dot ru
  Target Milestone: ---

[ 30%] Building C object
libgammu/CMakeFiles/libGammu.dir/phone/s60/s60phone.c.o
/root/gammu-1.37.3/libgammu/phone/s60/s60phone.c: In function
‘S60_SetAddCalendar’:
/root/gammu-1.37.3/libgammu/phone/s60/s60phone.c:1407:1: internal compiler
error: Ошибка сегментирования
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
libgammu/CMakeFiles/libGammu.dir/build.make:1526: ошибка выполнения рецепта для
цели «libgammu/CMakeFiles/libGammu.dir/phone/s60/s60phone.c.o»
make[2]: *** [libgammu/CMakeFiles/libGammu.dir/phone/s60/s60phone.c.o] Ошибка 1
CMakeFiles/Makefile2:1051: ошибка выполнения рецепта для цели
«libgammu/CMakeFiles/libGammu.dir/all»
make[1]: *** [libgammu/CMakeFiles/libGammu.dir/all] Ошибка 2
Makefile:147: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 2

I can not in any way call this package using cmake!

Line is error: 

GSM_Error S60_SetCalendar(GSM_StateMachine *s, GSM_CalendarEntry *Entry)
{
return S60_SetAddCalendar(s, Entry, NUM_CALENDAR_ENTRY_CHANGE,
ID_SetCalendarNote);
}

I go out segmentation error.What to do?
Linux linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64
GNU/Linux

[Bug driver/66203] aarch64-none-elf does not automatically find librdimon

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
By the way I will doing some bare metal aarch64 work soon but will be using a
different triplet for this env as it supports a few things the standard bare
metal does not.

[Bug middle-end/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||theJ893 at gmail dot com

--- Comment #201 from Andrew Pinski  ---
*** Bug 62623 has been marked as a duplicate of this bug. ***

[Bug c++/62623] [C++11] Behavior change in test case with -m32 and -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is a dup of bug 323.  -m32 causes the compiler to use the x87 register by
default so there are slight differences in the rounding vs non rounding in some
cases.

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

[Bug c++/71515] [4.9/5/6/7 Regression] ICE on valid C++ code on x86_64-linux-gnu: Segmentation fault (program cc1plus)

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Sun Jul 24 23:40:05 2016
New Revision: 238696

URL: https://gcc.gnu.org/viewcvs?rev=238696=gcc=rev
Log:
PR c++/71515 - typename in partial specialization

* pt.c (resolve_typename_type): Try to avoid calling
currently_open_class.

Added:
trunk/gcc/testsuite/g++.dg/template/typename22.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug rtl-optimization/71984] [7 Regression] wrong code with -O -mavx512cd

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Started with r237840.

[Bug ipa/71981] [6/7 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu (internal compiler error: in get_dynamic_type, at ipa-polymorphic-call.c:1667)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-24
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|ICE at -O2 and -O3 on   |[6/7 Regression] ICE at -O2
   |x86_64-linux-gnu (internal  |and -O3 on x86_64-linux-gnu
   |compiler error: in  |(internal compiler error:
   |get_dynamic_type, at|in get_dynamic_type, at
   |ipa-polymorphic-call.c:1667 |ipa-polymorphic-call.c:1667
   |)   |)
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'll take a look.

[Bug c++/71979] [5/6/7 Regression] ICE with on C++ code with incorrect type in overloaded base class '=' operator: in build_base_path, at cp/class.c:304

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-24
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE with on C++ code with   |[5/6/7 Regression] ICE with
   |incorrect type in   |on C++ code with incorrect
   |overloaded base class '='   |type in overloaded base
   |operator: in|class '=' operator: in
   |build_base_path, at |build_base_path, at
   |cp/class.c:304  |cp/class.c:304
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/70546] ifconvert if(cond) ++count; to count += cond; fails because of mergephi and failed loop header copying

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I think this is a dup of bug 30521.

[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #1 from Bill Schmidt  ---
I'll have a look soon.

[Bug libstdc++/71950] std::ios_base::failure.what() returns irrelevant error message

[skaianhero at gmail dot com]

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

--- Comment #4 from Austin Kramer  ---
(In reply to Jonathan Wakely from comment #3)
> 
> That would add overhead for exception handling and the vast majority of
> users do not use exceptions with fstream.
> 

That overhead would be almost nothing compared to the disk-accessing I/O that
happens deeper under the hood of these functions. It would simply involve
changing fstream::open to something like this (existing syntax tweaked to make
it easier to fit here):

void open(const char* __s, ios_base::openmode __mode) {
if (!_M_filebuf.open(__s, __mode))
this->setstate(ios_base::failbit);
else
try {
this->clear();
} catch (const std::ios::failure ) {
char buf[ESTR_BUF_SZ];
strerror_r(errno, buf, sizeof(buf));
throw std::ios::failure(buf);
}
}

I don't condone magic-mumber-sized buffers, and this is an errno example (that
DOES work on my playform), But my point is that the overhead happens only in
the failure case, after the comparatively expensive main-sequence operation,
with hardly any frame state that needs saving, and it only does any actual
throwing or buffer-writing if clear() is set up to throw. So it should be
pretty negligible.

> 
> Users can specialize basic_filebuf so we can't rely on non-standard
> functions.
> 
> I don't think it's worth changing anything here.

I wouldn't be so sure. Non-standard functionality aside, I still think the
exception message ought to be changed. I agree that checking the status bits of
the stream is the conventional way to go, but for some callers, that just ISN'T
ENOUGH INFORMATION. Most file operations can fail for more than one reason, and
having at least the ABILITY to generate a user or developer-readable error
message from standard library functions can be important in some cases.

Because between this vague message and PR 66145 preventing a valid system_error
containing exception from getting generated, there is NO way to determine why
an fstream function failed. And NOBODY likes seeing "Unknown Error".

[Bug rtl-optimization/71984] [7 Regression] wrong code with -O -mavx512cd

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-24
  Component|target  |rtl-optimization
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Confirmed, it looks like fwprop failure:

In insn 29, replacing
 (subreg:DI (reg:V8DI 92 [ D.2632 ]) 8)
 with (const_int 0 [0])
Changed insn 29
deferring rescan insn with uid = 29.

We can trace the value manually from _.222.cse1 dump
(element zero is at the leftmost position):

...

(insn 9 8 10 2 (set (reg:V2DI 96)
(const_vector:V2DI [
(const_int 0 [0])
(const_int 0 [0])
])) pr71984.c:8 1236 {movv2di_internal}
 (nil))

r96 = { 0, 0 }

(insn 10 9 11 2 (set (reg:V2DI 97)
(const_vector:V2DI [
(const_int 0 [0])
(const_int 0 [0])
])) pr71984.c:8 1236 {movv2di_internal}
 (nil))

r97 = { 0, 0 }

(insn 11 10 12 2 (set (reg:V2DI 98)
(const_vector:V2DI [
(const_int 0 [0])
(const_int 0 [0])
])) pr71984.c:8 1236 {movv2di_internal}
 (nil))

r98 = { 0, 0 }

(insn 12 11 13 2 (set (reg:V2DI 99)
(const_vector:V2DI [
(const_int 0 [0])
(const_int 0 [0])
])) pr71984.c:8 1236 {movv2di_internal}
 (nil))

r99 = { 0, 0 }

(insn 13 12 14 2 (set (reg:V2DI 99)
(vec_merge:V2DI (vec_duplicate:V2DI (reg:DI 93))
(reg:V2DI 99)
(const_int 2 [0x2]))) pr71984.c:8 3575 {sse4_1_pinsrq}
 (nil))

r99 = { 0, r93 }

(insn 14 13 15 2 (set (reg:V4DI 100)
(vec_concat:V4DI (reg:V2DI 99)
(reg:V2DI 98))) pr71984.c:8 4506 {avx_vec_concatv4di}
 (nil))

r100 = { r99, r98 }

(insn 15 14 16 2 (set (reg:V4DI 101)
(vec_concat:V4DI (reg:V2DI 97)
(reg:V2DI 96))) pr71984.c:8 4506 {avx_vec_concatv4di}
 (nil))

r101 = { r97, r96 }

(insn 16 15 28 2 (set (reg:V8DI 92 [ D.2632 ])
(vec_concat:V8DI (reg:V4DI 100)
(reg:V4DI 101))) pr71984.c:8 4512 {avx_vec_concatv8di}
 (nil))

r92 = { r100, r101 } = { r99, r98, r97, r96 } = { 0, r93, 0, 0, 0, 0, 0, 0 }

(insn 28 16 29 2 (set (reg:DI 105)
(subreg:DI (reg:V8DI 92 [ D.2632 ]) 0)) pr71984.c:8 81
{*movdi_internal}
 (nil))

r105 = 0

(insn 29 28 30 2 (set (reg:DI 106 [+8 ])
(subreg:DI (reg:V8DI 92 [ D.2632 ]) 8)) pr71984.c:8 81
{*movdi_internal}
 (nil))

r106 = r93

...

[Bug libstdc++/71950] std::ios_base::failure.what() returns irrelevant error message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Jonathan Wakely  ---
(In reply to Austin Kramer from comment #2)
> Well, if the actual throw happens obliviously in basic_ios::clear after
> fstream::open detects the error, it wouldn't be hard to have fstream::open
> catch the exception and re-throw a more helpful one.

That would add overhead for exception handling and the vast majority of users
do not use exceptions with fstream.

 The real hard part
> though is propagating the error details up to fstream::open in the first
> place. The call stack goes through several basic succeed/fail returns, some
> of which are public-facing functions.
> 
> There are 2 reasonable solutions I can think of that don't break the API,
> but neither are particularly clean.
> 
>  - Gratuitous overloading: Replace some intermediate basic_filebuf and
> __basic_file calls with ones that propagate an error code, and have their
> public-facing variants wrap the new versions and reduce the return value to
> the compliant types.

Users can specialize basic_filebuf so we can't rely on non-standard functions.

I don't think it's worth changing anything here.

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  ---
*** Bug 71985 has been marked as a duplicate of this bug. ***

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #9 from Manuel López-Ibáñez  ---
I also realize that the "inconsistency" issue is just because of my erroneous
interpretation of why we give a warning versus and error. There is no concept
of lossy conversions, thus I have updated the FAQ to remove any mention of such
a thing and just directly quote the manual:
https://gcc.gnu.org/wiki/FAQ#Wnarrowing

It is documented now that we give a warning for constants and an error for
non-constants and the rationale is simply that constant cases are easier to fix
than non-constant cases. I may disagree with this heuristic, but I don't care
enough about this topic to propose and argue for a patch implementing an
alternative, thus it is good enough for me.

Sorry for reopening this, I should have left it as it was.

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

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
What I suggested was that there is no backwards compatibility issue for C++03
code if the initialization creates a std::initializer_list. I was very
specifically talking about std::initializer_list not initializer lists in
general.

I also pointed out that there is no "clear requirement" for an error because
the standard only requires a diagnostic and a warning is a diagnostic.

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #7 from Manuel López-Ibáñez  ---
A simpler testcase:

#include 
double d;
std::vector v1 { d, 0.0, 0 };

prog.cc:3:33: warning: narrowing conversion of 'd' from 'double' to 'int'
inside { } [-Wnarrowing]
 std::vector v1 { d, 0.0, 0 };
 ^
prog.cc:3:33: warning: narrowing conversion of 'd' from 'double' to 'int'
inside { } [-Wnarrowing]
prog.cc:3:33: error: narrowing conversion of '0.0' from 'double' to 'int'
inside { } [-Wnarrowing]


It doesn't make sense that we give a warning for 'd' if no value of 'd' would
ever give a warning.


This case is different from:

int i;
char c[] = { i, 0 };

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
Note also that we give two warnings:

prog.cc:7:15: error: narrowing conversion of '0.0' from 'double' to 'int'
inside { } [-Wnarrowing]
 B b2 { 1, 0.0 };
   ^
prog.cc:9:25: warning: narrowing conversion of 'd' from 'double' to 'int'
inside { } [-Wnarrowing]
 std::vector v1 { d };
 ^
prog.cc:9:25: warning: narrowing conversion of 'd' from 'double' to 'int'
inside { } [-Wnarrowing]

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #4)
> g++ cannot know at the time of warning that d == 0.5, it just sees a
> variable 'd' that may have any value, such as 0.0.

Ah, but we do actually give an error for 0.0. So now I see the reporter's point
about inconsistency.

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #3)
> As a matter of consistency, I really think there shouldn't be
> different cases where we error out or warn. So treating the new C++11
> uniform initialization case the same as the older ones makes sense to me.
> 
> Of course, Jason as the C++ maintainer has the last word.
> CCing him.

The rationale is explained here:
https://gcc.gnu.org/wiki/FAQ#Wnarrowing

In a nutshell, error when it is sure that there is a change of value or loss of
precision, and warn otherwise.

In the example here, for any value of d in 1, 2, 1.0, 2.0, there is no loss of
precision or change of value. Even for:

double d = 0.5;
std::vector v1 { d };

g++ cannot know at the time of warning that d == 0.5, it just sees a variable
'd' that may have any value, such as 0.0.

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
As a matter of consistency, I really think there shouldn't be
different cases where we error out or warn. So treating the new C++11
uniform initialization case the same as the older ones makes sense to me.

Of course, Jason as the C++ maintainer has the last word.
CCing him.

[Bug fortran/70524] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[nico at josuttis dot de]

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

--- Comment #2 from Nicolai Josuttis  ---
Sorry, but IMO this is NOT the same.

> float f[3] = { d, d, d };
is an initialization of an array,
which is already supported by C.

> std::vector v1 { d };
is nothing that was possible before C++11.

Also both clang and VC++ handle this as a bug.

I am also surprised that ill-formed programs are not considered as bugs in
general. I didn't know that.
I always thought that a warning helps in places where a program is valid,
but probably not correct or useful.
So, why do other ill-formed programs result in bugs instead of warnings?

Sorry again
(Jonathan recommended me to open this bug, so ...).

[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR

[kugan at gcc dot gnu.org]

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

--- Comment #19 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sun Jul 24 12:47:29 2016
New Revision: 238695

URL: https://gcc.gnu.org/viewcvs?rev=238695=gcc=rev
Log:
gcc/ChangeLog:

2016-07-24  Kugan Vivekanandarajah  

PR middle-end/66726
* tree-ssa-reassoc.c (optimize_vec_cond_expr): Handle tcc_compare stmt
whose result is used in PHI.
(final_range_test_p): Likewise.
(maybe_optimize_range_tests): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||nico at josuttis dot de

--- Comment #13 from Markus Trippelsdorf  ---
*** Bug 71985 has been marked as a duplicate of this bug. ***

[Bug c++/71985] narrowing in initializer lists is not ill-formed where required

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Why do you think your case is any different than the ones discussed 
in PR55783?

If a program is ill-formed, »a conforming implementation shall issue at least
one diagnostic message«.
This is exactly what gcc does.

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

[Bug c++/71985] New: narrowing in initializer lists is not ill-formed where required

[nico at josuttis dot de]

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

Bug ID: 71985
   Summary: narrowing in initializer lists is not ill-formed where
required
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nico at josuttis dot de
  Target Milestone: ---

double d;
std::vector v1 { d };

only gives a warning instead of an error.

Unlike https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783,
here IMO there is a clear requoirement to result in an error because:

5.4.1 List-initialization [dcl.init.list] says:
> Otherwise, if T is a class type, constructors are considered. The applicable 
> constructors are enumerated
> and the best one is chosen through overload resolution (13.3, 13.3.1.7). If a 
> narrowing conversion (see
> below) is required to convert any of the arguments, the program is ill-formed.

and later:
> struct B {
> B(std::initializer_list);
> };
> B b1 { 1, 2 }; // creates initializer_list and calls constructor
> B b2 { 1, 2.0 }; // error: narrowing

This looks to me like my example, except that d is no constant.

But I see no difference between constants and avriables applied here
because according to 5.4.1 List-initialization [dcl.init.list]:
> A narrowing conversion is an implicit conversion
> — from a floating-point type to an integer type

Applies to all versions since C++11.
It tried 5.4.0 and other versions.

[Bug rtl-optimization/71779] [5/6/7 regression] isl miscompiled with -mabi=ilp32

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #9 from Bernd Edlinger  ---
(In reply to James Greenhalgh from comment #2)
> ---
> 
> So I have two questions.
> 
> First, where did the DImode paradoxical subreg come from in the first place,
> and why wasn't it a zero-extend?
> 

I think that comes from store_bit_field_using_insv.

This can be changed to a zero_extract, but I am not
sure if that is the reason for the wrong code.

Index: expmed.c
===
--- expmed.c(revision 238694)
+++ expmed.c(working copy)
@@ -664,14 +664,7 @@ store_bit_field_using_insv (const extraction_insn
 if we must narrow it, be sure we do it correctly.  */

  if (GET_MODE_SIZE (GET_MODE (value)) < GET_MODE_SIZE (op_mode))
-   {
- tmp = simplify_subreg (op_mode, value1, GET_MODE (value), 0);
- if (! tmp)
-   tmp = simplify_gen_subreg (op_mode,
-  force_reg (GET_MODE (value),
- value1),
-  GET_MODE (value), 0);
-   }
+   tmp = convert_to_mode (op_mode, value1, 1);
  else
{
  tmp = gen_lowpart_if_possible (op_mode, value1);


at least it changes insn 1047 to zero_extend:

(insn 1047 1046 1048 (set (reg:DI 479)
(zero_extend:DI (reg:SI 480))) isl_input.c:2496 -1
 (nil))

not sure if this changes anything...

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

--- Comment #7 from asmwarrior  ---
The -fno-delete-null-pointer-checks option exists in -O2 mode in both GCC 4.9
and GCC 5.x, but this crash issue only happens on GCC 5.x serials. So, why do
you think it is the reason?

See my related discussion here:
http://forums.codeblocks.org/index.php/topic,21207.msg145242.html#msg145242

[Bug c++/71975] In c++11/14 mode enumname::name is assumed name to be part of the enumname

[gw.fossdev at gmail dot com]

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

--- Comment #4 from Gert  ---
Regarding the "whitespace" I didn't know that with something like 

namespace foo { class bar {}; }

one can actually write 

  foo  ::bar x; 

i.e. add whitespaces between a namespace or class name and "::" before the
nested name, and I'm quite positive that I have never seen code where this is
actually done. This led me to the conclusion that the parser might be skipping
over whitespaces where it is not supposed to do so.

[Bug target/71984] New: [7 Regression] wrong code with -O -mavx512cd

[zsojka at seznam dot cz]

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

Bug ID: 71984
   Summary: [7 Regression] wrong code with -O -mavx512cd
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 38958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38958=edit
reduced testcase

Output:
$ gcc -O -mavx512cd testcase.c
$ ./a.out
Aborted

The function foo() is simplied to just return 0:

foo:
movl$0, %eax#,
ret



$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-238665-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-238665-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160722 (experimental) (GCC)

[Bug c++/71975] In c++11/14 mode enumname::name is assumed name to be part of the enumname

[gw.fossdev at gmail dot com]

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

--- Comment #3 from Gert  ---
Created attachment 38957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38957=edit
test case with "enu" being a struct

I would also assume that this is a parsing issue. 

With enu being a struct the compilation fails always (also with -std=c++98 and
c++03)

> g++ -std=c++98 whitespace_eating-class.cc

whitespace_eating-class.cc:11:24: error: ISO C++ forbids declaration of 'wow'
with no type [-fpermissive]
   friend enu ::wow();
^
whitespace_eating-class.cc:11:24: error: no 'int enu::wow()' member function
declared in class 'enu'

[Bug libstdc++/71950] std::ios_base::failure.what() returns irrelevant error message

[skaianhero at gmail dot com]

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

Austin Kramer  changed:

   What|Removed |Added

 CC||skaianhero at gmail dot com

--- Comment #2 from Austin Kramer  ---
Well, if the actual throw happens obliviously in basic_ios::clear after
fstream::open detects the error, it wouldn't be hard to have fstream::open
catch the exception and re-throw a more helpful one. The real hard part though
is propagating the error details up to fstream::open in the first place. The
call stack goes through several basic succeed/fail returns, some of which are
public-facing functions.

There are 2 reasonable solutions I can think of that don't break the API, but
neither are particularly clean.

 - Gratuitous overloading: Replace some intermediate basic_filebuf and
__basic_file calls with ones that propagate an error code, and have their
public-facing variants wrap the new versions and reduce the return value to the
compliant types.

 - Just use errno: AFAIK there's no spec saying that errno should be set in a
fstream::open call (from the perspective of the caller), but in practice it
seems to be set to the correct value for the underlying I/O error (though this
may be platform-dependent). If g++ could internally require errno to be set
deeper within the file operations and remain set until control returns to
fstream's functions, then those functions could re-throw a fresh exception
after basic_ios::clear with a more helpful message. But like you said, it's
hard (and perhaps wrong) to fully ensure that all sources of errors set errno
appropriately.

That said, I'm not sure how, in a world without PR 66145 causing issues, the
C++11 version would cleanly propagate the system_error details. Maybe it just
doesn't, and this fix would be used to address that as well.

[Bug middle-end/71741] The program works 3 times slower compiled with g++ 5.3.1 than the same program compiled with g++ 4.8.4 with the same command (i7-5820 Haswell)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-24
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Have you tried the binary you created with GCC 4.8.x and used it on the newer
distro?  If it is slower there, then this is a glibc issue.  It has been known
that glibc has slowed down sin/cos to make it more accurate in some corner
cases which might be what you are seeing.

[Bug middle-end/71741] The program works 3 times slower compiled with g++ 5.3.1 than the same program compiled with g++ 4.8.4 with the same command (i7-5820 Haswell)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

URL|http://stackoverflow.com/qu |
   |estions/38172066/the-progra |
   |m-works-3-times-slower-comp |
   |iled-with-g-5-3-1-than-the- |
   |same-program-c  |
  Component|c++ |middle-end

--- Comment #3 from Andrew Pinski  ---
http://stackoverflow.com/questions/38172066/the-program-works-3-times-slower-compiled-with-g-5-3-1-than-the-same-program-c

[Bug c++/71820] ICE on valid C++ code: in arg_assoc_type, at cp/name-lookup.c:5583

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
If you used decltype instead of __typeof__, it does not crash.

[Bug tree-optimization/54491] interval membership optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Only foo is not optimized.

But bar is optimized to the same as baz.

I don't know if range and foo are equivalent due to wrapping.