[Bug c/79482] New: _Static_assert(__builtin_constant_p(x)):

[mocramis at gmail dot com]

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

Bug ID: 79482
   Summary: _Static_assert(__builtin_constant_p(x)):
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mocramis at gmail dot com
  Target Milestone: ---

Compiling the wollowing code with gcc -O1 main.c:
= main.c =
int main(int argc, char *argv[]) { 
int x = 0;

_Static_assert(__builtin_constant_p(x) ? 1 : 2, "error");

return 0;
}
===

fails with the error :
  error: expression in static assertion is not constant
With optimizations disabled (O0), it compiles fine.

Also, if we replace the '?' operator by __builtin_choose_expr, the compiler
seems to behave as expected :
= main.c =
int main(int argc, char *argv[]) { 
int x = 0;

_Static_assert(__builtin_choose_expr(__builtin_constant_p(x), 1, 2),
   "error");

return 0;
}
===

This compiles fine with any level of optimisation (while __builtin_choose_expr
should expect the same 'constness' as _Static assert).

Clang 3.9 compiles both versions without errors (with O3).

Tested with gcc 6.3.1.

[BUILDROBOT] arm-netbsdelf: "cc1: internal compiler error: Segmentation fault" during -fself-test triggered from forcibly_ggc_collect()

[Jan-Benedict Glaw]

Hi!

When building a cross-gcc using config_list.mk using r245361 (as both,
a freshly built `build' compiler and as sources for the
cross-compiler), my build robot fails (see
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565).
Seems this is only triggered for arm-netbsdelf, it's running fine for
many/all? other targets in config_list.mk .

[...]
/home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/xgcc
 
-B/home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/
 -nostdinc -x c /dev/null -S -o /dev/null 
-fself-test=/home/jbglaw/repos-configlist_mk/gcc/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
0xaf7fdf crash_signal
/home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:333
0x6739b3 lookup_page_table_entry
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:635
0x6739b3 ggc_set_mark(void const*)
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:1532
0x571bff gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:49
0x57242a gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:401
0x572fae gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:382
0x571e61 gt_ggc_mx_lang_tree_node(void*)
./gt-c-c-decl.h:391
0x83ed15 ggc_mark_root_tab
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:77
0x83ef70 ggc_mark_roots()
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:94
0x674417 ggc_collect()
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:2202
0x842dff selftest::forcibly_ggc_collect()
/home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-tests.c:36
0x11d0491 selftest::run_tests()
/home/jbglaw/repos-configlist_mk/gcc/gcc/selftest-run-tests.c:103
0xaf9742 toplev::run_self_tests()
/home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:1932: recipe for target 's-selftest' failed
make[2]: *** [s-selftest] Error 1
rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gfortran.pod gcc.pod 
gcov-tool.pod gccgo.pod
make[2]: Leaving directory 
'/home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/gcc'
Makefile:4229: recipe for target 'all-gcc' failed
make[1]: *** [all-gcc] Error 2

Unfortunately, I don't know a good revision or when it started to
fail.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Alles sollte so einfach wie möglich gemacht sein.
the second  :  Aber nicht einfacher.  (Einstein)


signature.asc
Description: Digital signature

[Bug target/79481] New: AVX512PF: unmasked gather prefetch intrinsics missing

[wen...@mitsuba-renderer.org]

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

Bug ID: 79481
   Summary: AVX512PF: unmasked gather prefetch intrinsics missing
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wen...@mitsuba-renderer.org
  Target Milestone: ---

The latest trunk version (and all versions before as far as I can tell) are
missing the following (unmasked) intrinsics for gather prefetches:

_mm512_prefetch_i32gather_pd
_mm512_prefetch_i64gather_pd
_mm512_prefetch_i32gather_ps
_mm512_prefetch_i64gather_ps

It would be great if these could be added.

Thanks,
Wenzel

gcc-7-20170212 is now available

[gccadmin]

Snapshot gcc-7-20170212 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 245378

You'll find:

 gcc-7-20170212.tar.bz2   Complete GCC

  MD5=0074d94da90aa234fb0c7b689416d665
  SHA1=242003fb9b6c29658effb7bcd62cf65decbd7082

Diffs from 7-20170205 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug target/79480] -O3 and -mfpu=neon produces crashing code on ARM

[tulipawn at gmail dot com]

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

--- Comment #4 from PeteVine  ---
Whereas `-fsanitize=address` aborts all the same:

==28821==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs
operator delete) on 0xaf012100
#0 0xb6af76fb in operator delete(void*, unsigned int)
(/usr/gcc7/lib/libasan.so.4+0xd86fb)
#1 0xe5e53 in CLoad3DS::ProcessNextObjectChunk(CModel*, CObject*, Chunk*)
[clone .constprop.38] (/tmp/gl-117-1.3.2-src/src/gl-117+0xe5e53)
#2 0xe6773 in CLoad3DS::ProcessNextObjectChunk(CModel*, CObject*, Chunk*)
[clone .constprop.38] (/tmp/gl-117-1.3.2-src/src/gl-117+0xe6773)
#3 0xf8ae7 in CLoad3DS::ProcessNextChunk(CModel*, Chunk*) [clone
.constprop.30] (/tmp/gl-117-1.3.2-src/src/gl-117+0xf8ae7)
#4 0xf8ecf in CLoad3DS::ProcessNextChunk(CModel*, Chunk*) [clone
.constprop.30] (/tmp/gl-117-1.3.2-src/src/gl-117+0xf8ecf)
#5 0x80537 in CLoad3DS::Import3DS(CModel*, char*) [clone .constprop.29]
(/tmp/gl-117-1.3.2-src/src/gl-117+0x80537)
#6 0x3e403 in myFirstInit() (/tmp/gl-117-1.3.2-src/src/gl-117+0x3e403)
#7 0x1b2a7 in main (/tmp/gl-117-1.3.2-src/src/gl-117+0x1b2a7)
#8 0xb659d66f in __libc_start_main
(/lib/arm-linux-gnueabihf/libc.so.6+0x1766f)

0xaf012100 is located 0 bytes inside of 7680-byte region
[0xaf012100,0xaf013f00)
allocated by thread T0 here:
#0 0xb6af66cf in operator new[](unsigned int)
(/usr/gcc7/lib/libasan.so.4+0xd76cf)
#1 0xe5a5b in CLoad3DS::ProcessNextObjectChunk(CModel*, CObject*, Chunk*)
[clone .constprop.38] (/tmp/gl-117-1.3.2-src/src/gl-117+0xe5a5b)

SUMMARY: AddressSanitizer: alloc-dealloc-mismatch
(/usr/gcc7/lib/libasan.so.4+0xd86fb) in operator delete(void*, unsigned int)
==28821==HINT: if you don't care about these errors you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==28821==ABORTING

[Bug target/79480] -O3 and -mfpu=neon produces crashing code on ARM

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
That's the same command line that leads to an immediate crash (uninstrumented).

[Bug target/79480] -O3 and -mfpu=neon produces crashing code on ARM

[tulipawn at gmail dot com]

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

--- Comment #2 from PeteVine  ---
OK, having been built with: 

-mcpu=cortex-a5 -O3 -ffast-math -marm -fomit-frame-pointer -fipa-pta
-mfpu=neon-vfpv4 -ftree-vectorize -flto -fsanitize=undefined

doesn't crash but prints many errors, e.g.:

3ds.cpp:111:8: runtime error: load of misaligned address 0x007de59a for type
'Uint32', which requires 4 byte alignment
0x007de59a: note: pointer points here
 00 00  4d 4d 0d be 00 00 02 00  0a 00 00 00 03 00 00 00  3d 3d b9 ab 00 00 3e
3d  0a 00 00 00 03 00
  ^ 
3ds.cpp:111:8: runtime error: load of misaligned address 0x007de5aa for type
'Uint32', which requires 4 byte alignment
0x007de5aa: note: pointer points here
 00 00  3d 3d b9 ab 00 00 3e 3d  0a 00 00 00 03 00 00 00  ff af fa 00 00 00 00
a0  14 00 00 00 30 31
  ^ 
3ds.cpp:125:8: runtime error: load of misaligned address 0x007de5e1 for type
'Uint16', which requires 2 byte alignment
0x007de5e1: note: pointer points here
 00 96 96  96 20 a0 0f 00 00 00 11  00 09 00 00 00 96 96 96  30 a0 0f 00 00 00
11 00  09 00 00 00 e5
  ^ 
3ds.cpp:111:8: runtime error: load of misaligned address 0x007de5e3 for type
'Uint32', which requires 4 byte alignment
0x007de5e3: note: pointer points here
 96  96 20 a0 0f 00 00 00 11  00 09 00 00 00 96 96 96  30 a0 0f 00 00 00 11 00 
09 00 00 00 e5 e5 e5
  ^ 
3ds.cpp:125:8: runtime error: load of misaligned address 0x007de5e7 for type
'Uint16', which requires 2 byte alignment
0x007de5e7: note: pointer points here
 0f 00 00 00 11  00 09 00 00 00 96 96 96  30 a0 0f 00 00 00 11 00  09 00 00 00
e5 e5 e5 40  a0 0e 00

LIBGL: warning, gles_glBlendFuncSeparate is NULL
main.cpp:4762:29: runtime error: index 256 out of bounds for type 'int [256]'
main.cpp:4762:10: runtime error: load of address 0x00427180 with insufficient
space for an object of type 'int'
0x00427180: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  01 00 00 00 00
00 00 00  d8 2a 61 00
  ^ 
main.cpp:4783:35: runtime error: index 65536 out of bounds for type 'unsigned
char [65536]'
main.cpp:4783:37: runtime error: store to address 0x00407180 with insufficient
space for an object of type 'unsigned char'
0x00407180: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  00 00 00 00
  ^ 
main.cpp:4784:39: runtime error: index 65537 out of bounds for type 'unsigned
char [65536]'
main.cpp:4784:41: runtime error: store to address 0x00407181 with insufficient
space for an object of type 'unsigned char'
0x00407181: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  00 00 00 00 00
  ^ 
main.cpp:4785:39: runtime error: index 65538 out of bounds for type 'unsigned
char [65536]'
main.cpp:4785:41: runtime error: store to address 0x00407182 with insufficient
space for an object of type 'unsigned char'
0x00407182: note: pointer points here
 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
00  00 00 00 00 00 00
  ^ 
main.cpp:4786:39: runtime error: index 65539 out of bounds for type 'unsigned
char [65536]'
main.cpp:4786:41: runtime error: store to address 0x00407183 with insufficient
space for an object of type 'unsigned char'
0x00407183: note: pointer points here
 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00
  ^ 
main.cpp:3384:44: runtime error: downcast of address 0x00cb3488 which does not
point to an object of type 'AIObj'
0x00cb3488: note: object is of type 'DynamicObj'
 61 01 00 00  c4 2f 29 00 00 00 00 00  00 00 00 00 01 1b c8 00  00 00 80 3f 00
00 80 3f  00 00 00 3f
  ^~~
  vptr for 'DynamicObj'
main.cpp:3385:19: runtime error: member access within address 0x00cc67d8 which
does not point to an object of type 'DynamicObj'
0x00cc67d8: note: object is of type 'CExplosion'
 61 00 00 00  e4 43 29 00 00 00 00 00  00 00 00 00 00 00 00 00  cd cc cc 3d 00
00 80 3f  00 00 00 3f
  ^~~
  vptr for 'CExplosion'

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Will check if enabling bootstrap solves the problem.

Actually this does not seem to be the case. I still see the error with the
following GCC build (on Ubuntu 16.10):

Target: x86_64-linux-gnu
Configured with: /home/janus/gcc/trunk/configure --program-suffix=-7
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,fortran --disable-multilib --with-arch=haswell
Thread model: posix
gcc version 7.0.1 20170212 (experimental) [trunk revision 245376] (GCC)


Since no one can reproduce it, maybe it is Haswell-specific? I'll check if
removing "--with-arch=haswell" helps ...

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to janus from comment #6)
> The error goes away when using --enable-checking=release.

Well that is kinda of expected as the error is only enabled with checking
enabled.

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> I'm configuring with:
> 
> --program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu --with-arch=haswell --prefix=/usr
> --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,fortran
> --disable-bootstrap --disable-multilib

The error goes away when using --enable-checking=release.

[Bug target/79480] -O3 and -mfpu=neon produces crashing code on ARM

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Have you tried -fsanitize=undefined or -fsanitize=address to see if there is
undefined behavior in there?

[Bug target/79480] New: -O3 and -mfpu=neon produces crashing code on ARM

[tulipawn at gmail dot com]

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

Bug ID: 79480
   Summary: -O3 and -mfpu=neon produces crashing code on ARM
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

The gl-117 binary (source link attached) compiled with:

-mcpu=cortex-a5 -O3 -marm -fomit-frame-pointer -mfpu=neon -ftree-vectorize

crashes with a SIGBUS plus this kernel info:

 Alignment trap: not handling instruction f4620adf at [<00067c8c>]
 Unhandled fault: alignment exception (0x001) at 0x0048fcb1

Moreover, using LTO prints a warning about undefined behaviour:

main.cpp: In function ‘_ZL11myTimerFunci.isra.26’:
main.cpp:4762:29: warning: iteration 256 invokes undefined behavior
[-Waggressive-loop-optimizations]
  int h = heat [yind] [i2];
 ^
main.cpp:4757:5: note: containing loop
 for (i2 = 0; i2 < maxfx + 1; i2 ++)
 ^

The code is rather old C++ (g++ warns: ISO C++ forbids converting a string
constant to ‘char*’) but as long as -mfpu=neon is not used it doesn't crash,
even with the above warning. Reporting just in case.

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Sorry for the delay here. The unit number passed to the users dtio procedure is
0, so thats clearly wrong. I will see if I can fix that and see what happens.

[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)

[xilun0 at gmail dot com]

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

--- Comment #4 from Guillaume Knispel  ---
The dup seems to be 69846
This might also be vaguely related to 52154

[Bug c/79479] New: -Woverflow false alarm in unreachable expression

[eggert at gnu dot org]

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

Bug ID: 79479
   Summary: -Woverflow false alarm in unreachable expression
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

Created attachment 40722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40722=edit
gcc -m32 -Woverflow incorrectly complains about this

Compile the attached program with:

gcc -m32 -S too-large.c

and it responds:

too-large.c: In function ‘too_large’:
too-large.c:5:18: warning: integer overflow in expression [-Woverflow]
 return 32768 * 65536L < x;

Since the expression 32768 * 65536L cannot be executed on this platform (and
this is by design, the code tests whether the multiplication is advisable
before  trying it), the warning is a false alarm.

Bruno Haible originally reported this problem in bug-gnulib, here:

http://lists.gnu.org/archive/html/bug-gnulib/2017-02/msg00041.html

As this sort of thing is common in portable code that is checking for overflow
correctly, I suggest disabling -Woverflow tests inside unreachable expressions.

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #4)
> The preprocessed source doesn't ICE for me neither.

Huh, I guess then the problem is with me not doing a full bootstrap. I'm
configuring with:

--program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-arch=haswell --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --enable-languages=c,c++,fortran --disable-bootstrap
--disable-multilib

Will check if enabling bootstrap solves the problem.

[Bug c/79478] New: possible gimple error with gcc.dg/gimplefe-16.c

[dcb314 at hotmail dot com]

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

Bug ID: 79478
   Summary: possible gimple error with gcc.dg/gimplefe-16.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried out gcc/testsuite/gcc.dg/gimplefe-16.c with
a valgrind version of gcc trunk. It said:

$ ~/gcc/results.245356/bin/gcc -c -fgimple gcc.dg/gimplefe-16.c
==16161== Conditional jump or move depends on uninitialised value(s)
==16161==at 0x11233E8: can_be_stored_compactly_p (line-map.c:144)
==16161==by 0x11233E8: get_combined_adhoc_loc(line_maps*, unsigned int,
sour
ce_range, void*) (line-map.c:186)
==16161==by 0xC7323F: COMBINE_LOCATION_DATA (line-map.h:1020)
==16161==by 0xC7323F: set_source_range(tree_node*, source_range)
(tree.c:142
98)

[PATCH] Windows support for std::filesystem

[niXman]

Hi,

Tested on i686/x86_64-MinGW-W64

Please test possible regressions on posix platform.



--
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
https://sf.net/p/mingw-w64/
Index: libstdc++-v3/src/filesystem/dir.cc
===
--- libstdc++-v3/src/filesystem/dir.cc	(revision 245367)
+++ libstdc++-v3/src/filesystem/dir.cc	(working copy)
@@ -41,9 +41,10 @@
 #endif
 
 #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-# undef opendir
-# define opendir _wopendir
-#endif
+# include "fs-win32.h"
+#else
+# include "fs-posix.h"
+#endif // _GLIBCXX_FILESYSTEM_IS_WINDOWS
 
 namespace fs = std::experimental::filesystem;
 
@@ -51,7 +52,7 @@
 {
   _Dir() : dirp(nullptr) { }
 
-  _Dir(DIR* dirp, const fs::path& path) : dirp(dirp), path(path) { }
+  _Dir(os_DIR_t* dirp, const fs::path& path) : dirp(dirp), path(path) { }
 
   _Dir(_Dir&& d)
   : dirp(std::exchange(d.dirp, nullptr)), path(std::move(d.path)),
@@ -60,11 +61,11 @@
 
   _Dir& operator=(_Dir&&) = delete;
 
-  ~_Dir() { if (dirp) ::closedir(dirp); }
+  ~_Dir() { if (dirp) ::os_closedir(dirp); }
 
   bool advance(std::error_code*, directory_options = directory_options::none);
 
-  DIR*			dirp;
+  os_DIR_t*			dirp;
   fs::path		path;
   directory_entry	entry;
   file_type		type = file_type::none;
@@ -87,7 +88,7 @@
 if (ec)
   ec->clear();
 
-if (DIR* dirp = ::opendir(p.c_str()))
+if (os_DIR_t* dirp = ::os_opendir(p.c_str()))
   return {dirp, p};
 
 const int err = errno;
@@ -105,7 +106,7 @@
   }
 
   inline fs::file_type
-  get_file_type(const ::dirent& d __attribute__((__unused__)))
+  get_file_type(const ::os_dirent_t& d __attribute__((__unused__)))
   {
 #ifdef _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE
 switch (d.d_type)
@@ -145,13 +146,14 @@
 ec->clear();
 
   int err = std::exchange(errno, 0);
-  const auto entp = readdir(dirp);
+  const auto entp = ::os_readdir(dirp);
   std::swap(errno, err);
 
   if (entp)
 {
   // skip past dot and dot-dot
-  if (!strcmp(entp->d_name, ".") || !strcmp(entp->d_name, ".."))
+  if (!std::char_traits::compare(entp->d_name, _WS("."), 1) ||
+	!std::char_traits::compare(entp->d_name, _WS(".."), 2))
 	return advance(ec, options);
   entry = fs::directory_entry{path / entp->d_name};
   type = get_file_type(*entp);
@@ -239,7 +241,7 @@
  error_code* ec)
 : _M_options(options), _M_pending(true)
 {
-  if (DIR* dirp = ::opendir(p.c_str()))
+  if (os_DIR_t* dirp = ::os_opendir(p.c_str()))
 {
   auto sp = std::make_shared<_Dir_stack>();
   sp->push(_Dir{ dirp, p });
Index: libstdc++-v3/src/filesystem/fs-posix.h
===
--- libstdc++-v3/src/filesystem/fs-posix.h	(nonexistent)
+++ libstdc++-v3/src/filesystem/fs-posix.h	(working copy)
@@ -0,0 +1,49 @@
+
+// Copyright (C) 2014-2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+#ifndef _GLIBCXX_EXPERIMENTAL_FS_POSIX_H
+#define _GLIBCXX_EXPERIMENTAL_FS_POSIX_H 1
+
+#define os_DIR_t DIR
+#define os_dirent_t dirent
+#define os_open open
+#define os_opendir opendir
+#define os_closedir closedir
+#define os_readdir readdir_r
+#define os_stat stat
+#define os_stat_t stat
+#define os_chmod chmod
+#define os_mkdir mkdir
+#define os_getcwd getcwd
+#define os_chdir chdir
+#define os_utimbuf_t utimbuf
+#define os_utime utime
+#define os_remove remove
+#define os_rename rename
+#define os_truncate truncate
+
+#define os_utime utime
+
+#define _WS(x) x
+
+#endif // _GLIBCXX_EXPERIMENTAL_FS_POSIX_H
Index: libstdc++-v3/src/filesystem/fs-win32.h
===
--- libstdc++-v3/src/filesystem/fs-win32.h	(nonexistent)
+++ libstdc++-v3/src/filesystem/fs-win32.h	(working copy)
@@ -0,0 +1,64 @@
+
+// Copyright (C) 2014-2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. 

[Bug translation/79477] New: Please write code more translator-friendly

[roland.illig at gmx dot de]

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

Bug ID: 79477
   Summary: Please write code more translator-friendly
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

As a translator, I have to translate these strings:

-mdirect-move requires -mvsx
-mupper-regs-di requires -mvsx
-mpower9-vector requires -mpower8-vector
-mpower9-dform requires -mpower9-vector

And several more of this pattern. This is both boring and error-prone.

Instead of calling:

error ("-mpower9-dform requires -mpower9-vector");

Could you perhaps call:

error ("%s requires %s", "-mpower9-dform", "-mpower9-vector");

This would save the translators of each language a lot of work.

Re: [Fortran, Patch, CAF] Failed Images patch (TS 18508)

[Jerry DeLisle]

On 02/11/2017 03:02 PM, Alessandro Fanfarillo wrote:

Dear all,
please find in attachment a new patch following the discussion at
https://gcc.gnu.org/ml/fortran/2017-01/msg00054.html.

Suggestions on how to fix potential issues are more than welcome.

Regards,
Alessandro



On the failed images test:

program test_image_status
+  implicit none
+
+  write(*,*) image_status(1)
+

Write to a string and test the results.

I assume you have regression tested this again as stated in the earlier 
discussion.

I think this is OK to go in.

Jerry

[Bug c++/79476] New: C++ frontend ignores diagnostic pragma in macro

[j...@jak-linux.org]

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

Bug ID: 79476
   Summary: C++ frontend ignores diagnostic pragma in macro
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j...@jak-linux.org
  Target Milestone: ---

Created attachment 40721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40721=edit
Reproducer

We define three macros in APT:

#define APT_IGNORE_DEPRECATED_PUSH \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
#define APT_IGNORE_DEPRECATED_POP \
_Pragma("GCC diagnostic pop")
#define APT_IGNORE_DEPRECATED(XXX) \
APT_IGNORE_DEPRECATED_PUSH \
XXX \
APT_IGNORE_DEPRECATED_POP

So you can do stuff like APT_IGNORE_DEPRECATED(f();). This does not work
correctly however. Compiling the attached file with the C compiler results in
no warnings, with the C++ compiler a warning is emitted for
APT_IGNORE_DEPRECATED(f();) but not for using push/pop macros explicitly around
the f(); in the other functions:

$ gcc -c -Wdeprecated-declarations a.c
$ g++ -c -Wdeprecated-declarations a.c
a.c: In function ‘int a()’:
a.c:15:27: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
 APT_IGNORE_DEPRECATED(f();)
   ^
a.c:8:3: note: in definition of macro ‘APT_IGNORE_DEPRECATED’
   XXX \
   ^~~
a.c:11:5: note: declared here
 int f() __attribute__((deprecated));
 ^
a.c:15:29: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
 APT_IGNORE_DEPRECATED(f();)
 ^
a.c:8:3: note: in definition of macro ‘APT_IGNORE_DEPRECATED’
   XXX \
   ^~~
a.c:11:5: note: declared here
 int f() __attribute__((deprecated));
 ^

According to cpp, all functions expand to the same code.

This used to work at some point a long time ago, but I can't remember when.

Re: [PING] Re: [PATCH] Fix assembler arguments for -m16

[Uros Bizjak]

On Sun, Feb 12, 2017 at 4:27 PM, Gerald Pfeifer  wrote:
> I'd like to ping this patch for GCC 6 (and GCC 5).
>
> Gerald
>
> On Sun, 11 Dec 2016, Gerald Pfeifer wrote:
>> Uros, okay to also push to the GCC 6 branch for the coming release
>> and later the GCC 5 branch as well?  For reference, the committed
>> patch below.

OK.

Thanks,
Uros.

>> Gerald
>>
>>
>> 2016-12-11  Roger Pau Monné  
>>
>>   * config/i386/x86-64.h: Append --32 to the assembler options when
>>   -m16 is used on non-glibc systems as well.
>>
>> Index: config/i386/x86-64.h
>> ===
>> --- config/i386/x86-64.h  (revision 243527)
>> +++ config/i386/x86-64.h  (working copy)
>> @@ -49,7 +49,7 @@
>>  #define WCHAR_TYPE_SIZE 32
>>
>>  #undef ASM_SPEC
>> -#define ASM_SPEC "%{m32:--32} %{m64:--64} %{mx32:--x32}"
>> +#define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"
>>
>>  #undef ASM_OUTPUT_ALIGNED_BSS
>>  #define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \

[Bug fortran/79475] New: Missing space in error message: SINK addend not a constant integer

[roland.illig at gmx dot de]

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

Bug ID: 79475
   Summary: Missing space in error message: SINK addend not a
constant integer
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

fortran/openmp.c:

gfc_error ("SINK addend not a constant integer"
   "at %L", >where);

[Bug fortran/65542] [5/6/7 Regression] SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Feb 12 16:10:22 2017
New Revision: 245376

URL: https://gcc.gnu.org/viewcvs?rev=245376=gcc=rev
Log:
2017-02-12  Thomas Koenig  

PR fortran/65542
* intrinsic.c (gfc_intrinsic_func_interface):  Return an error
for -std=f95 for disallowed transformational functions in
initialization expressions.

2017-02-12  Thomas Koenig  

PR fortran/65542
* gfortran.dg/spread_init_expr_2.f90:  New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/spread_init_expr_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog

[PING] Re: [PATCH] Fix assembler arguments for -m16

[Gerald Pfeifer]

I'd like to ping this patch for GCC 6 (and GCC 5).

Gerald

On Sun, 11 Dec 2016, Gerald Pfeifer wrote:
> Uros, okay to also push to the GCC 6 branch for the coming release
> and later the GCC 5 branch as well?  For reference, the committed
> patch below.
> 
> Gerald
> 
> 
> 2016-12-11  Roger Pau Monné  
> 
>   * config/i386/x86-64.h: Append --32 to the assembler options when
>   -m16 is used on non-glibc systems as well.
> 
> Index: config/i386/x86-64.h
> ===
> --- config/i386/x86-64.h  (revision 243527)
> +++ config/i386/x86-64.h  (working copy)
> @@ -49,7 +49,7 @@
>  #define WCHAR_TYPE_SIZE 32
>  
>  #undef ASM_SPEC
> -#define ASM_SPEC "%{m32:--32} %{m64:--64} %{mx32:--x32}"
> +#define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"
>  
>  #undef ASM_OUTPUT_ALIGNED_BSS
>  #define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \

[libstdc++,doc] Standardize references to Boost documentation

[Gerald Pfeifer]

It appears we have been using various ways to refer to bits of Boost
documentation, and I suggest to standardize this a bit per the patch
below.

http://www.boost.org/libs/ seems to be the shortest and
simplest form doing to.

Thoughts?

Gerald

2017-02-10  Gerald Pfeifer  

* doc/xml/manual/policy_data_structures.xml: Simplify and
standardize references to boost.org.
* doc/xml/manual/policy_data_structures_biblio.xml: Ditto.
* doc/xml/manual/shared_ptr.xml: Ditto.

Index: doc/xml/manual/policy_data_structures.xml
===
--- doc/xml/manual/policy_data_structures.xml   (revision 245374)
+++ doc/xml/manual/policy_data_structures.xml   (working copy)
@@ -5090,7 +5090,8 @@
 
 
   Some test utilities borrow ideas from
-  http://www.w3.org/1999/xlink; 
xlink:href="http://www.boost.org/doc/libs/release/libs/timer/index.html;>boost::timer.
+  http://www.w3.org/1999/xlink;
+   xlink:href="http://www.boost.org/libs/timer/;>boost::timer.
 
 
 
Index: doc/xml/manual/policy_data_structures_biblio.xml
===
--- doc/xml/manual/policy_data_structures_biblio.xml(revision 245374)
+++ doc/xml/manual/policy_data_structures_biblio.xml(working copy)
@@ -1,4 +1,3 @@
-
 
 http://docbook.org/ns/docbook; version="5.0"
  xml:id="pbds.biblio" xreflabel="Bibliography">
@@ -181,7 +180,7 @@
 
   
http://www.w3.org/1999/xlink;
- xlink:href="http://www.boost.org/doc/libs/release/libs/timer/;>
+ xlink:href="http://www.boost.org/libs/timer/;>
  Boost Timer Library

   
@@ -208,7 +207,7 @@
 
   
http://www.w3.org/1999/xlink;
- xlink:href="http://www.boost.org/doc/libs/release/libs/pool/;>
+ xlink:href="http://www.boost.org/libs/pool/;>
  Boost Pool Library

   
@@ -236,7 +235,7 @@
 
   
http://www.w3.org/1999/xlink;
- 
xlink:href="http://www.boost.org/doc/libs/release/libs/type_traits/;>
+ xlink:href="http://www.boost.org/libs/type_traits/;>
  Boost Type Traits Library

   
Index: doc/xml/manual/shared_ptr.xml
===
--- doc/xml/manual/shared_ptr.xml   (revision 245374)
+++ doc/xml/manual/shared_ptr.xml   (working copy)
@@ -461,7 +461,7 @@
   
   
http://www.w3.org/1999/xlink;
- xlink:href="http://boost.org/libs/smart_ptr/shared_ptr.htm;>
+ xlink:href="http://www.boost.org/libs/smart_ptr/shared_ptr.htm;>
   Boost C++ Libraries documentation, shared_ptr

   

[Bug c++/49974] missing warning for indirectly returning reference to local/temporary

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
gcc is unable to look through dynamic static initializers, even with -flto or
-fwhole-program. If you use constexpr, you can make the program fail to
compile.
(adding your warning would be good, I just wanted to clarify what we already
have)

[Bug target/79473] New: -mload-store-pairs option is not documented in invoke.texi

[roland.illig at gmx dot de]

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

Bug ID: 79473
   Summary: -mload-store-pairs option is not documented in
invoke.texi
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

As a translator, I didn't know the concept before, so I had to look it up.

The explanation at
http://www.anandtech.com/show/8457/mips-strikes-back-64bit-warrior-i6400-architecture-arrives/3
looks short and easily understandable.

[doc] Update link to Objective-C 2.0 manual

[Gerald Pfeifer]

Applied (revision 245375).

Gerald

2017-02-12  Gerald Pfeifer  
 
* doc/standards.texi (Standards): Update reference to
Objective-C 2.0.

Index: doc/standards.texi
===
--- doc/standards.texi  (revision 245374)
+++ doc/standards.texi  (working copy)
@@ -290,7 +290,7 @@
 The authoritative manual on Objective-C 2.0 is available from Apple:
 @itemize
 @item
-@uref{https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html}
+@uref{https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html}
 @end itemize
 
 For more information concerning the history of Objective-C that is

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[glisse at gcc dot gnu.org]

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

--- Comment #19 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #16)
> Even if we moved our headers to separate directories, it wouldn't make
> __has_include sufficient..

Could you explain why? It would be a pain for other compilers using libstdc++
to add a suitable list of directories, but I don't immediately see why that
would fail.

[Bug tree-optimization/79460] gcc fails to optimise out a trivial additive loop for seemingly arbitrary numbers of iterations

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Raphael C from comment #1)
> After some experimentation (also carried out by Hagen von Eitzen), it seems
> that any limit of at least 72 which is also a multiple of 4 causes the same
> optimisation problem. That is the loop is *not* optimised out in these
> cases.  
> 
> Perhaps this is an example of one optimisation (SIMD vectorisation)
> conflicting with another?

IMHO, this is "scev propagation" on floating point values if ffast-math? is
enabled.  We shouldn't rely on vectorizer to propagate final value, it should
be done somewhere before vectorizer.  Thanks.

[Bug middle-end/79448] unhelpful -Wformat-truncation=2 INT_MAX warning

[mark at gcc dot gnu.org]

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

--- Comment #3 from Mark Wielaard  ---
A "workaround" for the example given in the description is to just pick some
arbitrary number you know wouldn't get exceeded. e.g:

  /* To help -Wformat-truncation=2 pretend the "count"
 translation will never be bigger than 128 chars.  */
  if (snprintf (buf, len, "%.*s: %d", 128 gettext ("count"), count) >= len)
return NULL;

But I have also some code that explicitly wants to know whether or not the size
of the formatted string will exceed what is currently available, to make sure
the output buffer gets resized. e.g.

  /* Would the output fit in the current buffer?  */
  int needed = snprintf (buf, avail, "%%mm%" PRIxFAST8, byte);
  if (needed > avail)
...

There is no good workaround for the second case.

Both cases seem to be solved by the proposed patch. While it still catches the
real issue also found by -Wformat-truncation=2.

But... The following produces different output depending on whether the code is
compiled with -Wformat-truncation=2 or not (-Wformat-truncation=1 also does
produce the expected output).

The idea of the code is that we snprintf into a buffer at a particular index
that is updated depending on the size of the string produced or, if the buffer
isn't big enough, returns extra space that would be needed.

This is using gcc trunk and the posted patch.

$ cat fct.c 
#include 
#include 
#include 

struct output_data
{
  char *bufp;   // buffer to write in.
  size_t *bufcntp;  // where in the buffer to write (to be updated).
  size_t bufsize;   // total buffer size.
  const uint8_t *data;  // auxiliary data (which register, flags, etc).
};

static int
FCT_freg (struct output_data *d)
{
  size_t *bufcntp = d->bufcntp;
  size_t avail = d->bufsize - *bufcntp;
  int needed = snprintf (>bufp[*bufcntp], avail, "%%st(%" PRIx32 ")",
 (uint32_t) (d->data[1] & 7));
  if ((size_t) needed > avail)
return (size_t) needed - avail;
  *bufcntp += needed;
  return 0;
}

typedef int (*opfct_t) (struct output_data *);
static const opfct_t op1_fct = FCT_freg;

int
main (int argc, char **argv)
{
  size_t size = 64;
  char buf[size];
  size_t idx = 0;
  uint8_t data[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
  int res;
  const char *prefix = "regs: ";

  struct output_data output_data =
{
  .bufp = buf,
  .bufsize = size,
  .bufcntp = ,
  .data = data,
};

  // Add some random data to the buf for debugging.
  memset (buf, 'A', size);
  buf[size - 1] = '\0';

  memcpy (buf, prefix, strlen (prefix) + 1);
  idx = strlen (prefix);
  for (uint8_t i = 0; i < 3; i++)
{
  data[1] = i; // Update register number to print.
  buf[idx] = 'X'; // Override expected zero char for debugging.

  printf ("Adding to buf at idx: %zd\n", idx);

  res = op1_fct (_data);
  if (res == 0)
{
  printf ("buf: \"%s\"\n", buf);
  buf[idx++] = ',';
}
  else
printf ("Need more space: %d\n", res);
}
  return 0;
}

$ gcc -g -O2 -o fct fct.c
$ ./fct 
Adding to buf at idx: 6
buf: "regs: %st(0)"
Adding to buf at idx: 13
buf: "regs: %st(0),%st(1)"
Adding to buf at idx: 20
buf: "regs: %st(0),%st(1),%st(2)"

$ gcc -Wformat-truncation=2 -g -O2 -o fct fct.c 
$ ./fct 
Adding to buf at idx: 6
buf: "regs: X"
Adding to buf at idx: 13
buf: "regs: XA,XA"
Adding to buf at idx: 20
buf: "regs: XA,XA,XAA"

Note how with -Wformat-truncation=2 the idx is correctly updated, but the
characters aren't actually written into the buffer...

Dropping -O2 does produce the expected output again.

[Bug rtl-optimization/79357] Doubling a single complex float gives inefficient code

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Note that we do not generate better code for
typedef float vec __attribute__((vector_size(8)));
vec g(vec x){return 2*x;}
(we don't consider larger vector modes when lowering/expanding vector
operations, there is already a PR about that)

Re: Weird optimization for tuples?

[Jonathan Wakely]

I've answered on gcc-help instead.

On 12 February 2017 at 00:55, David Guillen Fandos  wrote:
> Hello!
>
> I have the following function
> std::tuple getRawIdx(uint16_t tidx) {
>   return std::make_tuple(localidx.entries[tidx].indx_ptr,
> localidx.entries[tidx].indx_size);
> }
>
> Where s is a struct like
>
> typedef struct __attribute__((packed)) {
> uint32_t indx_ptr;
> uint8_t  indx_size;
> } _i_idx_entry ;
>
> The error I get is:
>
>  cannot bind packed field
> ‘((DBIndex*)this)->DBIndex::localidx.DBIndex::_i_idx::entries[((int)tidx)].DBIndex::_i_idx_entry::indx_ptr’
> to ‘unsigned int&’
>
> If extend the tuple to include a 3rd field and I return some other thing
> it just works:
>
> return std::make_tuple(localidx.entries[tidx].indx_ptr,
>localidx.entries[tidx].indx_size,
>tidx, prefb);
>
> I think gcc is trying to do some smart optimization or something and
> packed does not work because of tuple alignments not being packed.
>
> Any ideas?
> Thanks!
> David
>

Re: C++ Modules branch

[Gerald Pfeifer]

On Mon, 6 Feb 2017, Nathan Sidwell wrote:

Are you planning to add this to svn.html

Ah, thanks for the reminder.

First, here's a patch to collate the existing list, ok?


Oh, definitely.  This makes sense, and I trust your sorting
skills. :-)


(It seems quite a few may be dead now, time for some pruning?)


You mean, moving them to "Inactive Development Branches"?  Yes,
that makes sense.  

(In fact, it might make sense to differentiate between "Merged 
Branches" and "Inactive Development Branches", but that may be

too much effort.)

Gerald

New Swedish PO file for 'gcc' (version 7.1-b20170101)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-7.1-b20170101.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
What kind of comment would you like to have?  Normally we document what the
code is supposed to do, but here I can imagine just something like:
  /* We used to clear operands[4] here, which used to be a scratch register,
 but that is no longer the case.  */
which I'm afraid would just confuse rather than explain anything useful.
r235698 removed all other references to operands[4] (also without adding
comment on what it used to be).

(In reply to Kazumoto Kojima from comment #3)

> I've tested the patch with the top "make -k check" on sh4-unknown-linux-gnu
> and there are no regressions.

Thanks.

[Bug tree-optimization/79460] gcc fails to optimise out a trivial additive loop for seemingly arbitrary numbers of iterations

[drraph at gmail dot com]

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

--- Comment #1 from Raphael C  ---
After some experimentation (also carried out by Hagen von Eitzen), it seems
that any limit of at least 72 which is also a multiple of 4 causes the same
optimisation problem. That is the loop is *not* optimised out in these cases.  

Perhaps this is an example of one optimisation (SIMD vectorisation) conflicting
with another?

Re: [PATCH doc] update -dM to mention excluded macros (PR 41540)

[Gerald Pfeifer]

On Tue, 7 Feb 2017, Martin Sebor wrote:
> The attached documentation-only patch clarifies the description
> of the -dM option to mention that  __FILE__ (and other predefined
> macros) do no appear on the list generated by the option.

+The predefined macros @code{__FILE__}, @code{__LINE__}, @code{__DATE__},
+and @code{__TIME__} are excluded from this list because their replacements
+may change from one line of output to the next.

Is this ("their replacements may change") truefor __FILE__ as well?

In any case, this may be too nit-picking, and the patch looks fine
to me.

Thanks,
Gerald

[doc] sourceware.org now defaults to https

[Gerald Pfeifer]

Committed (revision 245374).

Gerald

2017-02-12  Gerald Pfeifer  

* doc/extend.texi (Named Address Spaces): sourceware.org now
defaults to https.
* doc/install.texi (Binaries): Ditto.
(Specific): Ditto.

Index: doc/extend.texi
===
--- doc/extend.texi (revision 245373)
+++ doc/extend.texi (working copy)
@@ -1446,7 +1446,7 @@
 
 @noindent
 Such code requires at least binutils 2.23, see
-@w{@uref{http://sourceware.org/PR13503,PR13503}}.
+@w{@uref{https://sourceware.org/PR13503,PR13503}}.
 
 @item
 On the reduced Tiny devices like ATtiny40, no address spaces are supported.
Index: doc/install.texi
===
--- doc/install.texi(revision 245373)
+++ doc/install.texi(working copy)
@@ -3075,7 +3075,7 @@
 Microsoft Windows:
 @itemize
 @item
-The @uref{http://sourceware.org/cygwin/,,Cygwin} project;
+The @uref{https://sourceware.org/cygwin/,,Cygwin} project;
 @item
 The @uref{http://www.mingw.org/,,MinGW} and
 @uref{http://mingw-w64.org/doku.php,,mingw-w64} projects.
@@ -4786,7 +4786,7 @@
 
 For some systems, old versions of GNU binutils may also be useful,
 and are available from @file{pub/binutils/old-releases} on
-@uref{http://sourceware.org/mirrors.html,,sourceware.org mirror sites}.
+@uref{https://sourceware.org/mirrors.html,,sourceware.org mirror sites}.
 
 Some of the information on specific systems above relates to
 such older systems, but much of the information

[wwwdocs] readings.html - remove ftp.uu.net reference

[Gerald Pfeifer]

The document itself is still available in the link following the
one removed.

Applied.

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.259
diff -u -r1.259 readings.html
--- readings.html   8 Feb 2017 18:44:56 -   1.259
+++ readings.html   12 Feb 2017 08:09:17 -
@@ -326,9 +326,6 @@
 http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm;>C99
 Defect Reports
 
-ftp://ftp.uu.net/doc/standards/ansi/X3.159-1989/;>C89
-Rationale (sources)
-
 http://www.lysator.liu.se/c/rat/title.html;>C89
 Rationale (HTML)
 

Re: [wwwdocs] Add a case to porting_to + a question wrt validity of another one

[Gerald Pfeifer]

On Wed, 8 Feb 2017, Marek Polacek wrote:
> Like this?

 As a consequence, the following examples are invalid and G++ will no longer
-compile them:
+compile them, because, in the following examples, G++ used to treat
+this->member where member has a non-dependent type, as
+type-dependent, and now it doesn't.

This has two instances of "the following examples".  Perhaps omit
the second instance and break the sentence, putting "G++ used to
treat..." in parenthesis after the first sentence, or adding this
explanation after the examples?

Also you'll need to write "-" instead of "->", and member
the second time as well (or member which we use in other places
in changes.html for this kind of usage).

This is fine with those changes, thanks.

Gerald