[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #3 from H.J. Lu  ---
The assembler patch is posted at

https://sourceware.org/pipermail/binutils/2021-January/114978.html

GCC should emit ".dwarf_level 5" when generating DWARF5 info.

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[11 Regression] |[11 Regression]
   |cxx11-ios_failure-lt.s:3673 |cxx11-ios_failure-lt.s:3673
   |3: Error: file number less  |3: Error: file number less
   |than one|than one by r11-6755

--- Comment #2 from H.J. Lu  ---
/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/export/gnu/import/git/gcc-test-master-intel64-native/bld/./gcc/xgcc
-shared-libgcc
-B/export/gnu/import/git/gcc-test-master-intel64-native/bld/./gcc -nostdinc++
-L/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/11.0.0/x86_64-pc-linux-gnu/bin/ -B/usr/11.0.0/x86_64-pc-linux-gnu/lib/
-isystem /usr/11.0.0/x86_64-pc-linux-gnu/include -isystem
/usr/11.0.0/x86_64-pc-linux-gnu/sys-include   -fno-checking
-I/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/../libgcc
-I/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test-master-intel64-native/src-master/libstdc++-v3/libsupc++
  -std=gnu++11 -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi=2  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=cxx11-ios_failure.lo  -g -O2
-D_GNU_SOURCE -fcf-protection -mshstk -g0 -c cxx11-ios_failure-lt.s -o
cxx11-ios_failure.lo

cxx11-ios_failure-lt.s contains DWARF5 debug info.  Since -g0 is used,
--gdwarf-5 isn't passed to assembler:

[hjl@gnu-clx-1 gcc]$ ./xgcc -B./ -c /tmp/cxx11-ios_failure-lt.s
/tmp/cxx11-ios_failure-lt.s: Assembler messages:
/tmp/cxx11-ios_failure-lt.s:36733: Error: file number less than one
[hjl@gnu-clx-1 gcc]$ ./xgcc -B./ -c /tmp/cxx11-ios_failure-lt.s -g
[hjl@gnu-clx-1 gcc]$ 

This means that "gcc -c" no longer works on assembly codes generated with
-g when DWARF5 is enabled.

[Bug middle-end/98710] New: missing optimization (x | c) & ~(y | c) -> x & ~(y | c)

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 98710
   Summary: missing optimization (x | c) & ~(y | c) -> x & ~(y |
c)
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

On this function clang generates slightly shorter code

unsigned foo(unsigned x, unsigned y, unsigned c)
{
return (x | c) & ~(y | c);
}

because it notices that the expression can be simplified to x & ~(y | c). It
would be great if GCC can do the same.

https://godbolt.org/z/3ob6eb

[Bug middle-end/98709] New: gcc optimizes bitwise operations, but doesn't optimize logical ones

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 98709
   Summary: gcc optimizes bitwise operations, but doesn't optimize
logical ones
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

GCC 10.2 produces very good code for this function noticing that both sides of
conjuntion are the same:

unsigned foo_bitwise(unsigned a, unsigned b)
{
return (~a ^ b) & ~(a ^ b);
}

foo_bitwise(unsigned int, unsigned int):
xor edi, esi
mov eax, edi
not eax
ret

But when I write a similar function with logical operations it doesn't notice
that:

bool foo_logical(bool a, bool b)
{
return (!a ^ b) & !(a ^ b);
}

foo_logical(bool, bool):
mov eax, esi
xor eax, edi
xor eax, 1
cmp dil, sil
setedl
and eax, edx
ret

I believe that in a similar manner it can be optimized to something like this:

foo_logical(bool, bool):
xor edi, esi
mov eax, edi
xor eax, 1
ret

[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mark at gcc dot gnu.org
   Last reconfirmed||2021-01-17

--- Comment #1 from H.J. Lu  ---
This is with binutils master.  I think 2.36 branch may have the same issue.

[Bug debug/98708] New: [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 98708
   Summary: [11 Regression] cxx11-ios_failure-lt.s:36733: Error:
file number less than one
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, r11-6755 gave

cxx11-ios_failure-lt.s: Assembler messages:
cxx11-ios_failure-lt.s:36733: Error: file number less than one
make[9]: *** [Makefile:865: cxx11-ios_failure.lo] Error 1

  14 .file 1 "../../../../../src-master/libstdc++-v3/src/c++11/cxx11-io
 s_failure.cc"
..

36733 .file 0
"/export/gnu/import/git/gcc-test-master-intel64-native/bld 
/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11" "../../../../../src-master/li 
bstdc++-v3/src/c++11/cxx11-ios_failure.cc"
36734 .section.debug_str,"MS",@progb

r6752 is OK.

[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Martin Sebor  ---
-Wnonnull still is in the front end (in addition to the middle end).  This
instance is issued by check_nonnull_arg in c-family/c-common.c, but other
similar instances are issued from tree-ssa-ccp.c.

Rather than twiddling the NO_WARNING bit I wonder if changing the C++ front end
to emit an internal function for these casts and expanding it in the gimplifier
would be a better solution.  check_nonnull_arg would then have nothing to
complain about.

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

[Bahram.shahrooz at uc dot edu via Gcc-bugs]

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

--- Comment #13 from Bahram.shahrooz at uc dot edu ---
Thank you for your help.  I really appreciate your time.

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #12 from Steve Kargl  ---
On Sat, Jan 16, 2021 at 11:20:20PM +, Bahram.shahrooz at uc dot edu wrote:
> 
> Do you've any suggestions for how to trace the source
> of error so I can fix the code?
> 

Not really.  I suppose  old fashion debugging is needed
where you put 'print' statements into the code to check
intermediate results. As far as I can tell, you simply
are using undefined variables in the code.  This isn't
a gfortran bug, so the bug report will be closed.

[Bug c++/98707] New: ICE using std::string in a module partition

[practicaldesignbook at gmail dot com via Gcc-bugs]

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

Bug ID: 98707
   Summary: ICE using std::string in a module partition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: practicaldesignbook at gmail dot com
  Target Milestone: ---

Created attachment 49983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49983=edit
Input files A.cpp and Test.cpp to trigger bug along with associated
preprocessed files

gcc version: gcc version 11.0.0 20210116 (experimental)
target: x86_64-pc-linux-gnu
build options: -disable-multilib --enable-languages=c,c++,fortran,lto,objc
--no-create --no-recursion

g++ produces an internal compiler error when combining strings and module
partitions (code attached). The error is not produced if the constructor of A
is changed from a std::string to an int or if the code is written without a
module partition.

g++ -std=c++20 -fmodules-ts -c -save-temps A.cpp Test.cpp
Test.cpp:1:9: internal compiler error: in insert, at cp/module.cc:4888
1 | export module Test;
  | ^~
0x699623 trees_out::insert(tree_node*, walk_kind)
../.././gcc/cp/module.cc:4888
0xa119ee trees_out::add_indirects(tree_node*)
../.././gcc/cp/module.cc:7303
0xa14e50 trees_out::decl_node(tree_node*, walk_kind)
../.././gcc/cp/module.cc:8647
0xa15a42 trees_out::tree_node(tree_node*)
../.././gcc/cp/module.cc:9149
0xa15f0d trees_out::vec_chained_decls(tree_node*)
../.././gcc/cp/module.cc:4976
0xa19e1b trees_out::write_class_def(tree_node*)
../.././gcc/cp/module.cc:11712
0xa1baec depset::hash::find_dependencies()
../.././gcc/cp/module.cc:13202
0xa1bec4 module_state::write(elf_out*, cpp_reader*)
../.././gcc/cp/module.cc:17568
0xa1d19c finish_module_processing(cpp_reader*)
../.././gcc/cp/module.cc:19747
0x9b164b c_parse_final_cleanups()
../.././gcc/cp/decl2.c:5178
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

[Bahram.shahrooz at uc dot edu via Gcc-bugs]

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

--- Comment #11 from Bahram.shahrooz at uc dot edu ---
Thanks!

This is how I compiled: 

gfortran FiberAnalysis.f -finit-real=nan -fcheck=all -ffpe-trap=zero,invalid -o
FiberAnalysis_v2

This what I get after running (the answers are correct):

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x105c4ad3d
#1  0x105c4a16d
#2  0x7fff203c4d7c
#3  0x105c34e45
#4  0x105c3c653
#5  0x105c3cae6
zsh: floating point exception  /Users/bahram/FiberAnalysis_v2
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...none found.

Do you've any suggestions for how to trace the source of error so I can fix the
code?

[Bug c/98621] ICE: x from g referenced in f

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug c++/98660] -Wold-style-cast should not warn on casts that look like (decltype(x))(x)

[gasper.azman at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Gašper Ažman  ---
s/endif/pragma GCC diagnostic pop

[Bug c++/98660] -Wold-style-cast should not warn on casts that look like (decltype(x))(x)

[gasper.azman at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gašper Ažman  ---
@Eric Gallager: yes, the #pragma solution is what I currently use. It is
entirely unsatisfactory, for the reasons described in my original request.

The long-term usefulness of warnings is directly proportional to the number of
false positives they generate. If I wanted to enforce the warning in most of
the code, and only disable it where appropriate, this is what that looks like,
on a non-terrible example (borrowed from libunifex):

  #pragma GCC diagnostic push
  #pragma GCC diagnostic ignore "-Wold-style-cast"
  template 
  constexpr auto operator()(CPO cpo, Args&&... args) const
  noexcept(noexcept(tag_invoke((CPO &&) cpo, (Args &&) args...)))
  -> decltype(tag_invoke((CPO &&) cpo, (Args &&) args...)) {
return tag_invoke((CPO &&) cpo, (Args &&) args...);
  }
  #endif

Now please, kindly tell me how I can know I didn't screw up a C-style cast in
that mess? It turns out that in the example above, ALL the casts mean
std::forward, but imagine it was a function where only some of the arguments
are forwarded, and a co-worker mistakenly puts in a c-style cast that doesn't
just change the value-category.

I'm asking for this warning to get more useful by still diagnosing c-style
casts that change more than the value category, and not diagnosing c-style
casts that are the "safest" kind - value category only, since that's what the
idiom seems to be.

[Bug c++/98660] -Wold-style-cast should not warn on casts that look like (decltype(x))(x)

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Just don't use -Wold-style-cast then. Or disable it selectively with #pragma
GCC diagnostic

[Bug target/95095] Feature request: support -fno-unique-section-names

[i at maskray dot me via Gcc-bugs]

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

--- Comment #3 from Fangrui Song  ---
(In reply to Segher Boessenkool from comment #2)
> Can't we use ".text%name" for -ffunction-sections, like we did originally,
> in 1996?  See cf4403481dd6.  This does not conflict with other section
> names, and does not have all the problems you get from doing anything that
> is not a simple prefix.

A function named 'foo' compiles to '.text%foo'? It might have been better to
avoid conflicts with '.text.startup' '.text.hot' etc but now such a change
would just inconvenience users (think of various Linux kernel linker script
fragments).

.text%name does not address -fno-unique-section-names.

[Bug target/95095] Feature request: support -fno-unique-section-names

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Segher Boessenkool  ---
Can't we use ".text%name" for -ffunction-sections, like we did originally,
in 1996?  See cf4403481dd6.  This does not conflict with other section
names, and does not have all the problems you get from doing anything that
is not a simple prefix.

[Bug fortran/88124] Wrong results with procedure in seperate file

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||anlauf at gcc dot gnu.org

--- Comment #11 from anlauf at gcc dot gnu.org ---
I tried the appended code with main and sub split into 2 .F files,
and with the flags given in the mail to the ML, but can NOT reproduce the
issue with the following compiler versions:

(Debian 6.3.0-18+deb9u1) 6.3.0 20170516

(SUSE Linux) 7.5.0
(SUSE Linux) 10.2.1

7.2.0
8.4.1
9.3.1
10.2.1
11 (HEAD)

So can we assume that this has been fixed (accidentally) in the meantime?

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Segher Boessenkool  ---
(And that new test case is full of obvious invalid code as well, fwiw.)

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #6)
> The warning often warns on dead code.
> But even if the warning is right, that doesn't make it ice-on-invalid-code.
> The code may have UB at runtime, but that UB doesn't need to be ever
> triggered when running the program.

That does not make it valid code.

> ice-on-invalid-code stands for code that should be rejected (diagnosed with
> errors, not warnings), but instead of giving the error we ICE on it instead.
> That is not the case here.

The documentation says
  ice-on-invalid-code   ICE on code that is not valid
which is true here.

Anyway:
  unsigned long xor_buf_y[1];
  ...
  typecast_copy(xor_buf_y, in, 4);
which obviously is an out-of-bounds access.  But there are even worse things:
  char *__trans_tmp_2;
  memcpy(__trans_tmp_2, S2, 32);
(accessing an uninitialised variable).

So no, there is no way I can consider this a P1.

[Bug c++/98706] New: spurious unused-set-but-not-used when a parameter pack is empty

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 98706
   Summary: spurious unused-set-but-not-used when a parameter pack
is empty
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Short test case:

template 
constexpr auto f(T... ts) {
auto id = [](auto x){ return x; };
return (id(ts) + ... + 0);
}

static_assert(f() == 0);

Emits:

: In instantiation of 'constexpr auto f(T ...) [with T = {}]':
:7:17:   required from here
:3:10: warning: variable 'id' set but not used
[-Wunused-but-set-variable]
3 | auto id = [](auto x){ return x; };
  |  ^~
Compiler returned: 0

This is basically bug #56958, but the commentary there suggests that the
warning is okay and I want to be clear that the warning is a false positive
here. The warning persists even if a different instantiation of 'f' uses 'id'.

[Bug target/70454] --with-arch=native isn't applied to 32-bit x86 target library

[doko at debian dot org via Gcc-bugs]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #9 from Matthias Klose  ---
*** Bug 98705 has been marked as a duplicate of this bug. ***

[Bug target/98705] [11 Regression] bootstrap broken on x86_64-linux-gnu with --enable-cet and multilibs enabled

[doko at debian dot org via Gcc-bugs]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #2 from Matthias Klose  ---
marking as duplicate

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

[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert

[keith.marshall at mailinator dot com via Gcc-bugs]

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

--- Comment #6 from Keith Marshall  ---
(In reply to David Malcolm from comment #5)
> Should be fixed by the above commit.

I applied your patch, and disabled (by changing "#ifdef _WIN32" to "#if 0") the
effect of my own, so that the invalid assumption regarding Win32 DIR_SEPARATOR
is not corrected.  I now see:

 $ ./tut01-hello-world.exe
 internal compiler error: in make_tempdir_path_template, at
jit/jit-tempdir.c:73

 This application has requested the Runtime to terminate it in an unusual way.
 Please contact the application's support team for more information.

so all looks good, thanks.  Just one residual irritation: after displaying this
error message, in the console, MS-Windows pops up a dialogue box to tell me
that the program has stopped working, and invites me to (pointlessly) forward
an error report to Microsoft, before finally terminating the process.  Just
another annoying Windows feature, which I don't know how to circumvent, short
of hacking the registry, and the control panel settings, to disable Windows
error reporting altogether.

BTW, you may wish to consider the patches, which I have attached to:

 https://osdn.net/projects/mingw/ticket/41070

They do help those building libgccjit for MS-Windows.

[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #12 from Xi Ruoyao  ---
"readelf -s js.ltrans2.ltrans.o" gives a strange unnamed UND symbol:

  1411:  0 SECTION LOCAL  DEFAULT  UND 

I'm not sure what's happening...

[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #11 from Xi Ruoyao  ---
In my case the error message is:

/usr/bin/ld: js.ltrans2.ltrans.o: .symtab local symbol at index 1411 (>=
sh_info of 404) 
/usr/bin/ld: js.ltrans2.ltrans.o: error adding symbols: bad value

I've uploaded the "guilty" files, js.ltrans2.* to my server, at

https://bf.mengyan1223.wang/assets/gcc-97787/

so someone can analysis it.

[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #10 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #9)
> (In reply to rguent...@suse.de from comment #8)
> > Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at
> > compile time?
> 
> I'm trying, though my gut feeling is that it won't work.

There is no luck. "-mxgot -Wa,-xgot" gives the same error.

[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #9 from Xi Ruoyao  ---
(In reply to rguent...@suse.de from comment #8)

> I guess it is because -mxgot is supposed to be handled by the assembler?
> I see
> 
> %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
> 
> in ASM_SPEC.  I guess this doesn't make it to COLLECT_AS_OPTIONS
> and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.

I don't think so.

I can reproduce this issue compiling spidermonkey (js interpreter) from
firefox-78 ESR.  I'm using "-pipe" so I can easily find the parameters passed
to "as", using "ps -aux".  "-xgot" is passed correctly.

> Can you attach the full output of compiling & linking with -v added?
>
> Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at
> compile time?

I'm trying, though my gut feeling is that it won't work.

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-01-16
 Status|UNCONFIRMED |NEW

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #1)
> Also related to this issue:
> https://gcc.gnu.org/pipermail/fortran/2021-January/055581.html:

A patch for this issue was submitted at
  https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563399.html
and committed to mainline (GCC 11) as
  https://gcc.gnu.org/g:b90e4a97419ce91fd7c1628b5912e8f54bee3441
(plus a follow-up ChangeLog fix).

The issue of comment 0 remains.

[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #7 from Martin Uecker  ---
The documentation implies that the pointer escaping the scope and calling the
function is safe as long as it does not access a variable of the enclosing
function that went out of scope.

[Bug target/98705] [11 Regression] bootstrap broken on x86_64-linux-gnu with --enable-cet and multilibs enabled

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Should be already fixed, see PR70454.

[Bug target/98705] New: [11 Regression] bootstrap broken on x86_64-linux-gnu with --enable-cet and multilibs enabled

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 98705
   Summary: [11 Regression] bootstrap broken on x86_64-linux-gnu
with --enable-cet and multilibs enabled
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen after 77d372abec0fbf2cfe922e3140ee3410248f979e on x86_64-linux-gnu with
--enable-cet and multilibs enabled

libtool: compile:  /<>/build/./gcc/xgcc
-B/<>/build/./gcc/ -B/usr/lib/gcc-snap
shot/x86_64-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/lib/
-isystem /usr/lib/gcc-snapshot/
x86_64-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/x86_64-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
 -I../../../../src/libgomp -I../../../../src/libgomp/config/linux/x86
-I../../../../src/libgomp/config/l
inux -I../../../../src/libgomp/config/posix -I../../../../src/libgomp
-I../../../../src/libgomp/../inclu
de -Wall -Werror -ftls-model=initial-exec -DUSING_INITIAL_EXEC_TLS -march=i486
-pthread -mtune=generic -
fcf-protection -mshstk -g -O2 -m32 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c
../../../../src/libgomp/a
lloc.c  -fPIC -DPIC -o .libs/alloc.o
cc1: error: '-fcf-protection' is not compatible with this target
make[11]: *** [Makefile:798: alloc.lo] Error 1
make[10]: *** [Makefile:1021: all-recursive] Error 1
make[10]: Leaving directory
'/<>/build/x86_64-linux-gnu/32/libgomp'
make[9]: *** [Makefile:622: all] Error 2
make[9]: Leaving directory '/<>/build/x86_64-linux-gnu/32/libgomp'
make[8]: *** [Makefile:1440: multi-do] Error 1
make[8]: Leaving directory '/<>/build/x86_64-linux-gnu/libgomp'
make[7]: *** [Makefile:1410: all-multi] Error 2
[...]
make[4]: Leaving directory '/<>/build'
make[3]: *** [Makefile:28643: stagefeedback-bubble] Error 2
make[3]: Leaving directory '/<>/build'
make[2]: *** [Makefile:28674: profiledbootstrap-lean] Error 2
make[2]: Leaving directory '/<>/build'

configured with
 --enable-cet
 --with-arch-32=i686
 --with-abi=m64
 --with-multilib-list=m32,m64,mx32

[Bug tree-optimization/95527] Failure to optimize __builtin_ffs == 0

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
For popcount and clz we already have patterns for comparison of the result with
integers.
For ctz not sure what useful simplifications we can do, perhaps just
ctz(x) == bitsize-1 (and !=) to x == 1 << (bitsize-1) (or !=)?
Ah, maybe also inequalifies, ctz(x) >= 3 to (x & ((1 << 3) - 1)) == 0 ?

[Bug tree-optimization/96696] Failure to optimize div+mul to mod+sub

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 49982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49982=edit
gcc11-pr96696.patch

Untested fix.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96688, which changed state.

Bug 96688 Summary: Failure to optimize shift-right/add+bitwise not of constant 
to avoid bitwise not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688

   What|Removed |Added

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

[Bug tree-optimization/96688] Failure to optimize shift-right/add+bitwise not of constant to avoid bitwise not

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96685, which changed state.

Bug 96685 Summary: Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685

   What|Removed |Added

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

[Bug tree-optimization/96685] Failure to optimize not+sub to add+not

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/96271] Failure to optimize memcmp of doubles to avoid going through memory

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 95731, which changed state.

Bug 95731 Summary: Failure to optimize a >= 0 && b >= 0 to (a | b) >= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95731

   What|Removed |Added

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

[Bug tree-optimization/95731] Failure to optimize a >= 0 && b >= 0 to (a | b) >= 0

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/98704] New: coroutine_handle::done() == false after promise's unhandled_exception() has thrown

[m.krause--- via Gcc-bugs]

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

Bug ID: 98704
   Summary: coroutine_handle::done() == false after promise's
unhandled_exception() has thrown
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.kra...@tu-harburg.de
  Target Milestone: ---

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

[dcl.fct.def.coroutine]/14 says: "If the evaluation of the expression
promise.unhandled_exception() exits via an exception, the coroutine is
considered suspended at the final suspend point". So, after this exception has
propagated to the caller, I expect that the coroutine_handle's done() function
returns true (because of [coroutine.handle.observers]/3 "Returns: true if the
coroutine is suspended at its final suspend point, otherwise false").

However, the compiler for which I am reporting this makes done() return false
in this situation. See the attached example code (my expectation is 1 instead
of 0 in the final two lines of output).

By the way, gcc 10.2, gcc trunk, clang 10.0.0, clang trunk, msvc 14.28 all
behave in this way. See the short discussion on Slack Cpplang #coroutines
starting on 02-Jan-2021. A fix for msvc is already underway:
https://developercommunity.visualstudio.com/content/problem/1305540/coroutine-handledone-false-after-promises-unhandle.html

[Bug tree-optimization/96271] Failure to optimize memcmp of doubles to avoid going through memory

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.  Probably the last of these missed-optimization bugfixes from me for GCC
11, tomorrow starts stage4 and only regression bugfixes will be allowed.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96669, which changed state.

Bug 96669 Summary: Failure to optimize shift by variable+and by 1 to test for 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96669

   What|Removed |Added

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

[Bug tree-optimization/96669] Failure to optimize shift by variable+and by 1 to test for 0

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/96669] Failure to optimize shift by variable+and by 1 to test for 0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:e2559c3945a09521ffe4f59669bc4d902ae77adb

commit r11-6748-ge2559c3945a09521ffe4f59669bc4d902ae77adb
Author: Jakub Jelinek 
Date:   Sat Jan 16 09:21:52 2021 +0100

match.pd: Optimize ((cst << x) & 1) [PR96669]

While we had a ((1 << x) & 1) != 0 to x == 0 optimization already,
this patch adds ((cst << x) & 1) optimization too, this time the
second constant must be 1 though, not some power of two, but the first
one can be any constant.  If it is even, the result is false, if it is
odd, the result is x == 0.

2021-01-16  Jakub Jelinek  

PR tree-optimization/96669
* match.pd ((CST << x) & 1 -> x == 0): New simplification.

* gcc.dg/tree-ssa/pr96669-1.c: Adjust regexp.
* gcc.dg/tree-ssa/pr96669-2.c: New test.

[Bug tree-optimization/96271] Failure to optimize memcmp of doubles to avoid going through memory

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:b673e7547fb95d1f0d5cd17ae9e3874742cade66

commit r11-6747-gb673e7547fb95d1f0d5cd17ae9e3874742cade66
Author: Jakub Jelinek 
Date:   Sat Jan 16 09:17:38 2021 +0100

cd_dce: Return TODO_update_address_taken from last cd_dce [PR96271]

On the following testcase, handle_builtin_memcmp in the strlen pass folds
the memcmp into comparison of two MEM_REFs.  But nothing triggers updating
of addressable vars afterwards, so even when the parameters are no longer
address taken, we force the parameters to stack and back anyway.

This patch causes TODO_update_address_taken to happen right before last
forwprop
pass (at the end of last cd_dce), so after strlen1 too.

2021-01-16  Jakub Jelinek  

PR tree-optimization/96271
* passes.def: Pass false argument to first two pass_cd_dce
instances and true to last instance.  Add comment that
last instance rewrites no longer addressed locals.
* tree-ssa-dce.c (pass_cd_dce): Add update_address_taken_p member
and
initialize it.
(pass_cd_dce::set_pass_param): New method.
(pass_cd_dce::execute): Return TODO_update_address_taken from
last cd_dce instance.

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

[Bug middle-end/98702] linker failure with a very simple testing case for gcc10

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
gcc10 defaults to -fno-common.

Important - XYO Strategy Latest Update for 2021

[Darren Langdon via Gcc-bugs]

NEW Update for the XYO Strategy for January 2021.

Hiya,  I hope you don't mind but I saw that you were involved in with XYO
and the Coin App.  I wanted to let you know that since COIN BOSS is now
available to everyone I designed a strategy which helps people reach their
targets in their journey quickly and easily.

The strategy has just been updated today and wanted to share it straight
away.

If you click here

this will take you to the FREE strategy and if you have any questions feel
free in sending me an email.

Thank you for reading this and I am confident that this will help you too.

To your success

Darren

You may unsubscribe

to stop receiving our emails.