Re: dict slice in python (translating perl to python)
-> Re: dict slice in python (translating perl to python) gcc-bugs <-- Thread --> <-- Date --> Re: dict slice in python (translating perl to python) B Wed, 10 Sep 2008 09:43:55 -0700 <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: dict slice in python (translating perl to python) B Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: dict slice in python (translating perl to python) B Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: dict slice in python (translating perl to python) B Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: dict slice in python (translating perl to python) B Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: dict slice in python (translating perl to python) B Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: dict slice in python (translating perl to python) B Reply via email to
You'rе my viсtim
Hi, viсtim. I write yоu beсausе I рut а malwаre оn thе web раgе with pоrn whiсh you have visited. My virus grabbеd аll yоur реrsоnаl info аnd turnеd оn your саmеra which captured thе process оf your оnаnism. Just аfter thаt thе soft saved your соntаct list. I will delete thе соmpromising vidеo and info if yоu раy mе 350 EURO in bitcoin. This is аddress for рaymеnt : 15YhhpyLFM4rf9WQPKTuzREidxLwpGYJ56 I give you 30 hours after you оpen my mеssagе fоr mаking thе transасtiоn. Аs soon as yоu reаd the message I'll sеe it right away. It is nоt neсessаry tо tell me that yоu hаve sеnt money to me. This аddress is сonnеctеd to yоu, my system will dеlete evеrything autоmatiсally аftеr trаnsfеr соnfirmаtion. If yоu nееd 48 h just reply оn this letter with +. Yоu сan visit the pоliсе stаtion but nоbody саn hеlр yоu. If yоu try to decеive mе , I'll sеe it right awаy ! I dоnt live in your сountry. Sо they сan not trасk my lоcаtion еven for 9 mоnths. Goоdbye. Dоnt forget abоut the shаme and to ignоre, Your lifе саn be ruined.
Possible bug with switch when optimization is turned on.
Hi
The following code seems to be correctly executed when compiled with
GCC 4.4.7 and LLVM 6.1. It does not correctly compile with gcc version
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4).
The following is what I have reduced the problem to:
#include
#include
#define GENERAL 1
#define BRACKETS 2
#define QUOTES 3
//This method contains the issue.
void foo(char *qb, char* into) {
//The starting state is important for the bug.
int state = QUOTES;
int save_state = BRACKETS;
while (qb) { //Always true, it seems this can't just be '1'
printf("State is %d\n", state);
switch (state) {
case BRACKETS:
printf("Yay this was correctly executed\n");
exit(0);
break;
case GENERAL:
printf("Oh no how did you get here?\n");
printf("State is %d\n", state);
exit(1);
break;
case QUOTES:
state = save_state;
printf("State went to %d btw BRACKETS is %d\n", state, BRACKETS);
save_state = GENERAL; //Remove this line and it will work even
when optimised.
printf("After save state, state went to %d btw BRACKETS is
%d\n", state, BRACKETS);
break;
default: ;
}
printf("State %d btw GENERAL %d\n", state, GENERAL);
}
printf("If you see this then something is really wrong.\n");
exit(4);
}
int main() {
//These don't seem to matter don't concern yourself with them.
char *b = "123";
char out[4];
foo(b, out);
return 1;
}
If I compile this with:
gcc -O0 -g -Wall -Werror sillyswitch.c -o sillyswitch
It will correctly print "Yay this was correctly executed"
However if I compile this with:
gcc -O -g -Wall -Werror sillyswitch.c -o sillyswitch
It will print "Oh no how did you get here?"
I suspect this is a bug. I am unable to create an account to report
this as a bug though.
-Luke
[Bug c++/94671] New: Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
Bug ID: 94671
Summary: Wrong behavior with operator new overloading when
using O2 for optimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@odd-e.com
Target Milestone: ---
This bug is a similar bug as an earlier reported in clang:
https://bugs.llvm.org/show_bug.cgi?id=15541
When having the overloaded new operator defined in other cpp or in a lib, g++
with O2 optimizes a new operation without assignment (or assignment to local or
static), and it will not call the overloaded new at all.
The following code will reproduce the problem.
---
test.cpp:
---
#include
#define CHECK(expect, actual) std::cout << "EXPECT:" << expect <<
"\tACTUAL:"<
#include
#include
extern bool newCalled;
bool newCalled = false;
void* operator new (size_t size) throw (std::bad_alloc)
{
newCalled = true;
return malloc(size);
}
---
I know this is an optimization (it doesn't happen with -O0)... but it does
break the C++ standard.
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #2 from Bas Vodde --- Oh wow, does this mean that it is the choice of the compiler to actually call an overloaded operator new ? That is interesting. Thanks. I'd still consider it highly surprising behavior, at least it was for me...
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #4 from Bas Vodde --- The newCalled to true in the example was the simplest way to show the behavior. This bug came up in a open source project called CppuTest. This has the functionality to detect memory leaks and does so by overloading the operator new. For each operator new, it keeps accounting information. When an operator new gets optimized by the compiler, the framework can't keep track of the accounting information and the delete call will report that non-allocated memory was deleted. I assume this is an useful and perfectly legit way of overloading operator new/delete. This behavior was caught when running the automated test of the framework, which failed in the debian build when updating to gcc10: https://people.debian.org/~doko/logs/gcc10-20200225/cpputest_3.8-7_unstable_gcc10.log
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #5 from Bas Vodde ---
In the case we found this, it mostly uses the overload for accounting and thus
it doesn't cause a serious problem ('just' a test failure).
If you use the overloaded new/delete for providing your own memory management,
then this would potentially cause a serious problems.
[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671 --- Comment #9 from Bas Vodde --- Hi Jonathan, You are right, I was drawing much too many conclusions there. I should have waited with that comment until I slept :) Sorry for that. And it has been a while since I read the proposal, it has been years since we hit this problem in clang. Let me experiment a bit and see why gcc now behaves differently than clang, and whether that can cause a non-optimized placement delete to called on a replace operator new. Otherwise, I still find it odd behavior but less harmful as I wrongly stated in the previous comment.
[Bug c++/57632] New: Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632 Bug ID: 57632 Summary: Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX) Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: b...@odd-e.com G++ on MacOsX acts different when enabling the new c++11 related to operator new overloads. If I compile the following code: #include "stdlib.h" #include void* operator new(size_t mem) throw(std::bad_alloc); void* operator new(size_t mem) throw(std::bad_alloc); Then when compiling g++ new.cpp, it compiles fine. But when I compile g++ -std=c++11 new.cpp, then it results in this error: new.cpp:6:52: error: declaration of ‘void* operator new(size_t) throw (std::bad_alloc)’ has a different exception specifier void* operator new(size_t mem) throw(std::bad_alloc); ^ new.cpp:5:7: error: from previous declaration ‘void* operator new(std::size_t)’ void* operator new(size_t mem) throw(std::bad_alloc); ^ I've not been able to replicate this under linux and digging into it a bit, it seems to relate to the c++config.h definitions of _GLIBCXX_THROW.
[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632 --- Comment #3 from Bas Vodde --- Thanks for the comments. I understand the problems in implementing a compiler, when this is also unclear in the language itself. Whatever is decided related to this, it would probably be a good idea to give a better error message. Right now, the error message is telling the user that the operator new *with* an exception specifier doesn't have one and that they are different, even though the two lines are exactly the same. It is a bit confusing. It would be good though to solve this in a way that both works with C++11 and C++03 as it came up when compiling a piece of code that is used by multiple compilers and by both language versions.
[Bug fortran/59450] New: ICE for Array Valued Function combined with Deferred Specification Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 Bug ID: 59450 Summary: ICE for Array Valued Function combined with Deferred Specification Function Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: b...@miller-mohr.de Hi, when I try to compile the code below I receive an internal compiler error. The idea of the test case is to have a base class with a type-bound procedure returning an array. The size of the array is determined by using a specification function with deferred binding, i.e. it will be implemented in a child class / extended derived type. When I use a component of the base class instead of the specification function the code compiles without problems. module classes implicit none type, abstract :: base_class integer :: varnum contains procedure(pvf_get_num), nopass, deferred :: get_num procedure :: get_array end type base_class abstract interface pure function pvf_get_num() result(num) integer :: num end function pvf_get_num end interface contains function get_array( this ) result(array) class(base_class), intent(in) :: this ! compiles ! integer, dimension( this%varnum ) :: array ! crashes integer, dimension( this%get_num() ) :: array array = 0 array(1) = 1 end function get_array end module classes In detail I obtain the following Driving: gfortran -v --save-temps gcc-test2.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/lrz/mnt/sys.x86_64/compilers/gcc/4.8.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.2/configure --prefix=/lrz/sys/compilers/gcc/4.8.2 --enable-languages=ada,c,c++,fortran,java,go,objc,obj-c++ --with-mpfr=/lrz/sys/libraries/mpfr/3.0.0 --with-gmp=/lrz/sys/libraries/gmp/5.0.1 --with-mpc=/lrz/sys/libraries/mpc/0.9 Thread model: posix gcc version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /lrz/mnt/sys.x86_64/compilers/gcc/4.8.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/f951 gcc-test2.f90 -quiet -dumpbase gcc-test2.f90 -mtune=generic -march=x86-64 -auxbase gcc-test2 -version -fintrinsic-modules-path /lrz/mnt/sys.x86_64/compilers/gcc/4.8.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2/finclude -o gcc-test2.s GNU Fortran (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 f951: internal compiler error: Segmentation fault 0x87f55f crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x55971e mio_expr ../../gcc-4.8.2/gcc/fortran/module.c:3300 0x559d68 mio_array_spec ../../gcc-4.8.2/gcc/fortran/module.c:2406 0x559e8f mio_component ../../gcc-4.8.2/gcc/fortran/module.c:2596 0x55a11a mio_component_list ../../gcc-4.8.2/gcc/fortran/module.c:2624 0x55a11a mio_symbol ../../gcc-4.8.2/gcc/fortran/module.c:3816 0x55a442 write_symbol ../../gcc-4.8.2/gcc/fortran/module.c:5090 0x55a58d write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5130 0x55a535 write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5109 0x55a535 write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5109 0x55a535 write_symbol0 ../../gcc-4.8.2/gcc/fortran/module.c:5109 0x55caa7 write_module ../../gcc-4.8.2/gcc/fortran/module.c:5396 0x55caa7 gfc_dump_module(char const*, int) ../../gcc-4.8.2/gcc/fortran/module.c:5534 0x56844a gfc_parse_file() ../../gcc-4.8.2/gcc/fortran/parse.c:4623 0x5a3c05 gfc_be_parse_file ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189 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. Compiling the same source with 4.7.1 (on another system) I do not receive an ICE, but instead get error reports that the specification functions wouldn't be pure Using built-in specs. COLLECT_GCC=gfortran-4.7.1 Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix /home/SOFTWARE/GCC/gcc-4.7.1 --program-suffix=-4.7.1 --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran Thread model: posix gcc version 4.7.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-save-temps' '-mtune=generic&#x
[Bug fortran/59450] [OOP] ICE for type-bound-procedure expression in module procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 --- Comment #5 from b...@miller-mohr.de --- (In reply to janus from comment #4) > (In reply to janus from comment #2) > > Draft patch which fixes the error (not regtested): > > Does regtest cleanly. Hi, just wanted to say thanks. Your speed is terrific :) Cheers Marcus
[Bug fortran/59547] New: Problem with using tbp specification function in multiple class procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59547 Bug ID: 59547 Summary: Problem with using tbp specification function in multiple class procedures Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: b...@miller-mohr.de Created attachment 31470 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31470&action=edit Error messages from gfortran 4.9.0 Hi, this is a follow-up on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450. The ICE reported there got fixed (thanks). Verified this with GNU C version 4.9.0 20131217 (experimental). However, there is still an issue with using a specification function in a class procedure. When I use the function in multiple (tested with two) procedures, I get errors on the function not being pure. However, when it is used in only one procedure, this is not the case. The example I used is the following: module classes implicit none type :: base_class integer :: member contains procedure, nopass :: get_num ! either of the lines below alone works, but not both together procedure :: get_array procedure :: get_array2 end type contains pure integer function get_num() get_num = 2 end function function get_array( this ) result(array) class(base_class), intent(in) :: this integer, dimension( this%get_num() ) :: array end function function get_array2( this ) result(array) class(base_class), intent(in) :: this integer, dimension( this%get_num(), this%get_num() ) :: array end function end module I get the attached errors. Cheers Marcus
[Bug fortran/59450] [OOP] ICE for type-bound-procedure expression in module procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 --- Comment #9 from b...@miller-mohr.de --- Hi, verified that the ICE is gone in gcc version 4.9.0 20131217 (experimental). Thanks a lot. However, there is still a problem. As it is no longer an ICE I filed a new bug 59547 Cheers Marcus
[Bug libstdc++/91719] New: gcc compiles seq_cst store on x86-64 differently from clang/icc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91719
Bug ID: 91719
Summary: gcc compiles seq_cst store on x86-64 differently from
clang/icc
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.gier...@b-tu.de
Target Milestone: ---
On x86-64 all versions of gcc compile a sequentially consistent atomic store as
'mov + mfence'. Both clang and icc on the other hand instead compile such a
store using only a 'xchg' instruction, which appears to be more efficient
according to my tests.
Example code:
--
#include
std::atomic G{0};
void store() {
G.store(1);
}
--
[Bug c++/85043] New: -Wuseless-cast false positive for temporary objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85043
Bug ID: 85043
Summary: -Wuseless-cast false positive for temporary objects
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@michael-lossin.de
Target Milestone: ---
> cat x.cc
#include
struct A
{
int value = 42;
A & inc() { ++value; return *this; }
};
int main()
{
{
A a;
std::cout << A(a).inc().value << ", ";
std::cout << a.value << "\n";
}
{
A a;
std::cout << a.inc().value << ", ";
std::cout << a.value << "\n";
}
}
> g++ -Wuseless-cast -o x x.cc
x.cc: In function 'int main()':
x.cc:13:21: warning: useless cast to type 'A' [-Wuseless-cast]
std::cout << A(a).inc().value << ", ";
^
> ./x
43, 42
43, 43
Here, A(a) is not a cast but creates a temporary object which in turn is
modified. Removing the "useless cast" would alter the original object, so the
warning should not be shown in this case.
error in gcc / g++ standard header file
Please resolve the following gcc / g++ compiler error in /usr/include/c++/3.2.3/bits/fstream.tcc In file included from /usr/include/c++/3.2.3/fstream:576, /usr/include/c++/3.2.3/bits/fstream.tcc: In member function `virtual _Traits::pos_type std::basic_filebuf<_CharT, _Traits>::seekoff(_Traits::off_type, std::_Ios_Seekdir, std::_Ios_Openmode)': /usr/include/c++/3.2.3/bits/fstream.tcc:455: *syntax error before `this'* I am using the version : Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) I am calling in my file, internally which might be calling , the error is in on line 455
[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544 Frédéric Leroy changed: What|Removed |Added CC||frederic.le...@b-com.com --- Comment #9 from Frédéric Leroy --- Hello, I wanted to use -finstrument-functions with a software but it fails to link as in the example above. I use gcc from ubuntu 16.04: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 I recompiled the small snippet from mobi in comment 7 and it gave the same error. What need to be done to avoid this error or to fix gcc ?
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #8 from burnus at net-b dot de 2006-04-27 08:09 ---
Subject: Re: gfortran: Warn/abort when format in write
does not fit passed arguments
(In reply to comment #7)
> Tobias, I hope this is what you were looking for. I don't really
think we need
> a compile time check. That would be pretty involved to do and the
error is
> caught at runtime.
I think it is ok (though Brooks wording is probably better).
Still it would be nice if it would be detected during compile time. In
my case it was burried in an
if(something that rarely happens) write(*,'(''n'')') n
which I wouldn't have found easily without the compile-time warning of
the NAG compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug debug/38479] Incorrect dwarf generated for function with parameters greater 4 words in length
--- Comment #5 from francois at b-powers dot be 2009-02-19 13:10 --- Any update on this bug ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38479
[Bug target/91841] vector_size(8) passes MMX register without emms cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841 Bernard B changed: What|Removed |Added CC||b-gccbugzilla@largestprime. ||net --- Comment #7 from Bernard B --- The resolution of this bug should be at least WONTFIX, not INVALID, because as the OP reports, this is perfectly valid portable code that works on 64-bit x86 and other non-x86 architectures supported by GCC. I have just encountered this issue myself when supporting an in-house library which heavily uses vector types. It makes compilation of 32-bit x86 code with vector types pretty much unusable. A library author cannot control what users of the library will do after calling the library's functions. It's unreasonable to expect all users to put _mm_empty() in all the right places and only on x86-32. And the current failure mode of silent corruption is the worst. Even if the ABI of __m64 types is unusable as currently specified, could gcc implement a workaround? Either (1) emit the emms instruction (between a callee return with vector type and a subsequent FPU operation or the end of the function); or (2) simply not use the __m64 type for passing 64-bit vector types at all? The latter is an ABI break, but the ABI was broken anyway!
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #5 from burnus at net-b dot de 2010-03-03 16:59 --- Subject: Re: [4.5 Regression] Missing array temp for DT with pointer component On 03/03/2010 04:53 PM, Paul Richard Thomas wrote: > Yet another in the series :-) I hope that it is the last... > So do I - especially with regards to regressions. Regarding temporaries: I was compiling some programs with the patched gfortran and the number of created temporaries is quite low - and I think no low-lying fruits are left. There are some cases of assignments for which middle-end array support were helpful (hint, hint) and some other cases with MATMUL and assignments which could be solved in the front end. (And two of the programs here could gain some performance, if they would move to TR 15581; without the compiler has unnecessarily to assume aliasing. But as both do not dare to drop support for F95-only compilers, yet, ...) By the way, for RESHAPE gfortran generates temporaries what could be avoided if RESHAPE wouldn't deallocate - that's another candidate to fix after the new array descriptor gained a "bool allocated" component ... cf. PR 32512. > This bootstraps and regtests on RHEL5.2/x86_64 - OK for trunk? > OK. Thanks a lot for the patch! Tobias > 2010-03-03 Paul Thomas > > PR fortran/43243 > * trans-array.c (gfc_conv_array_parameter): Contiguous refs to > allocatable ultimate components do not need temporaries, whilst > ultimate pointer components do. > > 2010-03-03 Paul Thomas > > PR fortran/43243 > * gfortran.dg/internal_pack_12.f90: New test. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug fortran/24790] arguments are displayed as reference or pointer to normal type in GDB
--- Comment #6 from burnus at net-b dot de 2006-10-22 21:03 --- See http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01086.html for a preliminary patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
[Bug c/28196] New: miscompiled initialization of a constant pointer reference with offset (ppc64 target)
The following code is miscompiled when using -m64 (=ppc64) target: const static double a = 1.0; const static double *b = (double*)&a - 1; &b[1] should be &a, but it's not - there is an additional offset of 0x1 -- Summary: miscompiled initialization of a constant pointer reference with offset (ppc64 target) Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: inbox at b-q-c dot com GCC build triplet: powerpc-apple-darwin8.6 GCC host triplet: powerpc-apple-darwin8.6 GCC target triplet: powerpc-apple-darwin8.6 (ppc64) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug c/28196] miscompiled initialization of a constant pointer reference with offset (ppc64 target)
--- Comment #1 from inbox at b-q-c dot com 2006-06-28 20:44 --- Created an attachment (id=11774) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11774&action=view) test case - returns 0 on success or 1 when miscompiled gcc -m64 -o gcc64bug gcc64bug.c Inspection of the a and b will show: a = 1fe8 b = 11fe0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug c/28196] miscompiled initialization of a constant pointer reference with offset (ppc64 target)
--- Comment #2 from inbox at b-q-c dot com 2006-06-28 20:47 --- The original description should state that there is an additional offset of 0x1 (it said 0x1 instead). Also this bug is reproducible with earlier version of gcc such as 4.0.1 as supplied by Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug c/28196] miscompiled initialization of a constant pointer reference with offset (ppc64 target)
--- Comment #3 from inbox at b-q-c dot com 2006-06-28 20:50 --- Created an attachment (id=11775) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11775&action=view) output of gcc -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
[Bug target/24626] internal compiler error: verify_flow_info failed
--- Comment #2 from b dot gunreben at web dot de 2005-11-09 07:07 ---
Another testcase, fails with gcc -O2 -c, same compiler as above:
typedef long
(*bla)(int *node);
static long F2(void *tree, long blk, bla after_node_func)
{
long call_result = 0;
int *node;
if (call_result = after_node_func(node))
goto error_free_node;
T(node);
return 0;
error_free_node:
T(node);
error:
return call_result;
}
long F1(void *tree)
{
return F2(tree, F3(tree), (void *)0);
}
--
b dot gunreben at web dot de changed:
What|Removed |Added
CC||b dot gunreben at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug c/32889] New: ICE in delete_output_reload, at reload1.c:7926
in gcc (GCC) 4.2.1 20070705 (prerelease) (SUSE Linux)
# gcc -c -O2 -fPIC x.i
x.i: In function 'mi_open':
x.i:104: warning: incompatible implicit declaration of built-in function
'strlen'
x.i:111: internal compiler error: in delete_output_reload, at reload1.c:7926
attaching testcase to this bug
--
Summary: ICE in delete_output_reload, at reload1.c:7926
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b dot gunreben at web dot de
GCC host triplet: hppa2.0-suse-linux
GCC target triplet: hppa2.0-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32889
[Bug c/32889] ICE in delete_output_reload, at reload1.c:7926
--- Comment #1 from b dot gunreben at web dot de 2007-07-25 08:20 --- Created an attachment (id=13971) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13971&action=view) testcase x.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32889
[Bug c/32889] ICE in delete_output_reload, at reload1.c:7926
--- Comment #2 from b dot gunreben at web dot de 2007-07-25 08:26 --- just to add some more information: # gcc -v Using built-in specs. Target: hppa2.0-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.2 --enable-version-specific-runtime-libs --without-system-libunwind --host=hppa2.0-suse-linux Thread model: posix gcc version 4.2.1 20070705 (prerelease) (SUSE Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32889
[Bug c++/33467] New: Compilation error while compiling DynCommon.cpp
Following is the machine and compiler details:
bash-3.00$ gcc -v
Using built-in specs.
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure
Thread model: single
gcc version 4.0.2
Following error is generated while compiling "DynCommon.cpp" which is a file in
opensource middleware (ACE/TAO):
g++ -fvisibility=hidden -fvisibility-inlines-hidden -w -O2 -g -DHPUX_VERS=
-DACE_HAS_THREADS -D_POSIX_C_SOURCE=199506L
-I/instaroam/pinakee/TAO/ACE_wrappers -I/instaroam/pinakee/TAO/ACE_wrappers/TAO
-DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -I../.. -I.. -DTAO_DYNAMICANY_BUILD_DLL
-c -fPIC -o .shobj/DynamicAny/DynCommon.o DynamicAny/DynCommon.cpp
DynamicAny/DynCommon.cpp: In member function 'void
TAO_DynCommon::_ZTv0_n100_N13TAO_DynCommon17insert_longdoubleEe(CORBA::LongDouble)':
DynamicAny/DynCommon.cpp:1290: internal compiler error: in make_decl_rtl, at
varasm.c:871
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gmake[1]: *** [.shobj/DynamicAny/DynCommon.o] Error 1
gmake[1]: Leaving directory `/instaroam/pinakee/TAO/ACE_wrappers/TAO/tao'
gmake: *** [DynamicAny] Error 2
--
Summary: Compilation error while compiling DynCommon.cpp
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinakee dot b at xius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
[Bug c++/33467] Compilation error while compiling DynCommon.cpp
--- Comment #1 from pinakee dot b at xius dot com 2007-09-18 05:08 --- Created an attachment (id=14217) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14217&action=view) The file is where the compilation error is coming. The attachment is the file where the compilation error is being reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
[Bug c++/33467] Compilation error while compiling DynCommon.cpp
--- Comment #2 from pinakee dot b at xius dot com 2007-09-18 07:05 --- Created an attachment (id=14218) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14218&action=view) The attachment is the zip of preprocessed file of the source file. Since the file size was more than that allowed, it has been zipped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
[Bug c/35193] New: can't find a register in class 'R1_REGS' while reloading 'asm'
when I try to compile a current glibc for hppa, I get the following error:
gcc -O2 -c dcigettext.i
dcigettext.c: In function ‘_nl_find_msg’:
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:220: error: can't
find a register in class 'R1_REGS' while reloading 'asm'
dcigettext.c:1102: error: can't find a register in class 'R1_REGS' while
reloading 'asm'
dcigettext.c:1164: error: can't find a register in class 'R1_REGS' while
reloading 'asm'
dcigettext.c:1194: error: can't find a register in class 'R1_REGS' while
reloading 'asm'
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:220: error: 'asm'
operand has impossible constraints
dcigettext.c:1102: error: 'asm' operand has impossible constraints
dcigettext.c:1164: error: 'asm' operand has impossible constraints
dcigettext.c:1194: error: 'asm' operand has impossible constraints
however, if I remove the lines with starting # signs in the preprocessed code
like:
grep -v "^#" dcigettext.i > x.i
it just compiles. The original error also vanishes if I use -O instead of -O2.
Adding preprocessed dcigettext.i, to reproduce, run
gcc -O2 -c dcigettext.i
--
Summary: can't find a register in class 'R1_REGS' while reloading
'asm'
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b dot gunreben at web dot de
GCC host triplet: hppa-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
[Bug c/35193] can't find a register in class 'R1_REGS' while reloading 'asm'
--- Comment #1 from b dot gunreben at web dot de 2008-02-14 13:28 --- Created an attachment (id=15148) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15148&action=view) preprocessed dcigettext.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
[Bug c++/56715] New: Explicit Reg Vars are being ignored for consts when using g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
Bug #: 56715
Summary: Explicit Reg Vars are being ignored for consts when
using g++
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: goswin-...@web.de
Created attachment 29714
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29714
example source that experiences the bug
I'm trying to pass a value to an `asm' operand using a specific register for
arm with a freestanding compiler. Following the example from the info pages I
have the following code:
void foo() {
register const int r4 asm("r4") = 0x1000;
asm volatile("swi #1" : : "r"(r4));
}
void bar() {
register int r4 asm("r4") = 0x1000;
asm volatile("swi #1" : : "r"(r4));
}
Both foo() and bar() compile correct when using gcc. But when using g++ the
foo() function suddenly uses the "r3" register instead of "r4". The bar()
function remains correct.
% arm-none-eabi-g++ -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/usr/local/cross/libexec/gcc/arm-none-eabi/4.7.2/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.7.2/configure --target=arm-none-eabi
--prefix=/usr/local/cross --disable-nls --enable-languages=c,c++
--without-headers
Thread model: single
gcc version 4.7.2 (GCC)
% arm-none-eabi-gcc -O2 -save-temps -S bug.c good code
% arm-none-eabi-g++ -O2 -save-temps -S bug.c bad code
--
_Z3foov:
.fnstart
.LFB0:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #4096
@ 3 "bug.c" 1
swi #1
@ 0 "" 2
bx lr
--
The source explicitly asked for "r4" but g++ uses r3 instead.
[Bug c++/56715] Explicit Reg Vars are being ignored for consts when using g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
--- Comment #2 from Goswin von Brederlow 2013-03-25
00:07:19 UTC ---
(In reply to comment #1)
> const is a bit special in C++, it can be used as part of a const integer
> expression which is what is happening here.
How does that make it right to ignore the register specification? Or how do you
specify which register to use to pass the constant to asm in a specific
register?
To me it seems wrong to ignore the asm("r4") without even a warning. This does
break asm() statements that expect specific registers to be used.
[Bug c++/56715] Explicit Reg Vars are being ignored for consts when using g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
Goswin von Brederlow changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #5 from Goswin von Brederlow 2013-03-25
11:11:52 UTC ---
If it is invalid, as in not allowed, then I would expect an error. If it is
undefined behaviour then I would expect a warning.
For example:
register const int r4 asm("r4") = 0x1000;
Warning: const expression wont be bound to a specific register.
[Bug target/66960] Add interrupt attribute to x86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960 --- Comment #20 from Goswin von Brederlow --- So it's been a year since my last comment. Is this dead or is someone still working on it? It would be a nice addition to gcc.
[Bug c/65668] New: gcc does not know how to use __eabi_uldivmod properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65668 Bug ID: 65668 Summary: gcc does not know how to use __eabi_uldivmod properly Product: gcc Version: 4.9.2 URL: https://gist.github.com/mrvn/0c79b146f74c28da401f Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: goswin-v-b at web dot de Build: arm-none-eabi I have a uint64_t free running counter with a frequenzy of 1Mhz and I want to print that as hours, minutes, seconds and fraction: volatile uint64_t count = 0x62a54bc4 // for example uint64_t t = count; uint32_t frac, seconds, minutes, hours; frac = t % 100; t /= 100; seconds = t % 60; t /= 60; minutes = t % 60; t /= 60; hours = t; This results in 6 calls to __eabi_uldivmod, one for every modulo and every division, instead of just 3 calls. With long division being rather expensive that is a substantial waste of time.
[Bug web/65699] New: online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 Bug ID: 65699 Summary: online docs lacks version that it documents Product: gcc Version: unknown URL: https://gcc.gnu.org/onlinedocs/gccint/ Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: goswin-v-b at web dot de CC: goswin-v-b at web dot de The online docs do not mention what version of the compiler they document. When something doesn't work as documented this makes it hard to see if that something is no longer valid in the local version or describes something not yet present in the local version.
[Bug web/65700] New: Documentation of internals is inconsistent in itself and diverges from reality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65700 Bug ID: 65700 Summary: Documentation of internals is inconsistent in itself and diverges from reality Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: goswin-v-b at web dot de https://gcc.gnu.org/onlinedocs/gccint/Collect2.html says when collect2 is used it generates a temporary file listing the constructors and destructors and that the actual calls to the constructors are done from __main(). https://gcc.gnu.org/onlinedocs/gccint/Initialization.html now tells a quite different storry, including the .ctros/.dtors that are actually used on x86/x86_64. It still mentions __main() in connection with collect2 being used. On ARM what actually happens is that there is a .init_array section and the libc startup files are supposed to process that itself. Despite collect2 being used there is no __main() function that gets called for this. There is no .init section but still gcc does NOT insert a call to __main() when compiling main() like the docs say it would. Further the .init_array does not hold the constructors in reverse order. It actually holds a automatic constructor generated by gcc first and then all the functions manually declared as constructors. Care must be taken by the linker script to sort them by priority or they are random. So in the case of ARM the cinstructors need to be called in order, not in reverse order. Overall I have to say the documentation confuses things more than it actually helps. I don't know if that is because it hasn't been updated in a long time or never was complete or internally consistent in the first place. But it sure could use some love. If they can't be improved please at least add a comment where they are outdated or when they where last synced against the source so it becomes clear to the reader where they are lacking.
[Bug web/65699] online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 --- Comment #4 from Goswin von Brederlow --- Yes, a simple statement like that was exactly what I had in mind.
[Bug c++/65199] New: Linker failure with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65199 Bug ID: 65199 Summary: Linker failure with -flto Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: goswin-v-b at web dot de Host: x86_64-linux-gnu Target: x86_64-linux-gnu Build: arm-none-eabi I'm building a bare-metal kernel for a Raspberry Pi 2 (armv7) in c++. At some point this failed with "undefined reference to `memcpy'" so I implemented one as extern "C" void * memcpy(void *dest, const void *src, uint32_t n). But that gives a different error: % arm-none-eabi-g++ -O2 -W -Wall -fPIE -flto -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -ffreestanding -nostdlib -std=gnu++11 -fno-exceptions -fno-rtti -c -o main.o main.cc % arm-none-eabi-g++ -fPIE -nostdlib -O2 -flto boot.o font.o main.o -lgcc -Tlink-arm-eabi.ld -o kernel.elf `memcpy' referenced in section `.text' of /tmp/cc7IkgU6.ltrans0.ltrans.o: defined in discarded section `.text' of main.o (symbol from plugin) collect2: error: ld returned 1 exit status Running the same command to link but without -flto succeeds: % arm-none-eabi-g++ -fPIE -nostdlib -O2 boot.o font.o main.o -lgcc -Tlink-arm-eabi.ld -o kernel.elf
[Bug c++/65199] Linker failure with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65199 --- Comment #2 from Goswin von Brederlow --- That fixes it. Isn't it a gcc bug though not to detect that itself?
[Bug lto/65252] New: Link time optimization breaks use of filenames in linker scripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65252
Bug ID: 65252
Summary: Link time optimization breaks use of filenames in
linker scripts
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: arm-none-eabi
I'm building a kernel for a Rapsberry Pi 2 with -flto. Most of the code will be
linked to 0x8000. The kernel image will be loaded to 0x8000 and I have set
up LMA and VMA in my linker script accordingly. But I have some bootstrap code
(boot.S and early.cc) that needs to at the physical address. So I put the
following in my linker script:
ENTRY(_start)
PHYS_TO_VIRT = 0x8000;
SECTIONS
{
. = 0x8000;
.early : {
boot.o(.*)
early.o(.*)
}
/* rest of the code runs in higher half virtual address */
. = . + PHYS_TO_VIRT;
.text : AT(ADDR(.text) - PHYS_TO_VIRT) {
...
Using objdump -d I see the boot.o contents show up at 0x8000 exactly as it
should. But all the code from early.o only appears later in the .text section
and at the virtual adress. If I drop the -flto then everything works as
expected. It would be nice if -flto could preserve which file each function and
variable comes from so the linker can place them properly.
[Bug lto/65252] Link time optimization breaks use of filenames in linker scripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65252 --- Comment #2 from Goswin von Brederlow --- As long as it's only one C/C++ file that works. But if one has multiple files then -fno-lto would optimize less. I was thinking of a more general case than mine.
[Bug lto/65262] New: Link time optimization breaks use __attribute__((section("..."))) in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65262
Bug ID: 65262
Summary: Link time optimization breaks use
__attribute__((section("..."))) in templates
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
Created attachment 34911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34911&action=edit
Simple testcase
I'm trying to put a template member functions of a class into a different
section. Without -flto this works but with -flto the function reverts to the
.text section.
g++ -O2 -W -Wall -fvisibility=hidden -fno-inline -Tlink.ld -c -o main.o main.cc
g++ -O2 -W -Wall -fvisibility=hidden -fno-inline -Tlink.ld -o main main.o
g++ -O2 -W -Wall -fvisibility=hidden -fno-inline -Tlink.ld -flto -c -o
main.lto.o main.cc
g++ -O2 -W -Wall -fvisibility=hidden -fno-inline -Tlink.ld -flto -o main.lto
main.lto.o
Without link time optimization:
0200 ld .text.foo .text.foo
0210 g F .text.foo 0006 .hidden
foo()
0200 wF .text.foo 0006 .hidden
int foobar()
With link time optimization:
0820 ld .text.foo .text.foo
0100 l F .text 0006 int foobar()
0820 l F .text.foo 0006 foo()
[Bug lto/65262] Link time optimization breaks use __attribute__((section("..."))) in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65262 --- Comment #2 from Goswin von Brederlow --- The linker script is only there because the default script combines all .text.* into one hiding the effect. One could use different section names that the default script does not combine and work without a custom linker script. LTO is free to privatizes template instantiations. But if it doesn't inline the template then it should preserve the section attribute on it like it does for normal functions. All optimized clones of a normal functions are still in the same section the original function was in. I could understand if a template would end up in the section of the function causing the instantiation (although what if functions from different sections use the same instance?). But templates simply end up in the .text section no matter what they where originally or where they get instantiated. I don't know the internals but it looks to me like something should copy the section attribute from the template to the privatized function in LTO mode. You can't set a section on the template, you can't use a file scope in the linker, you can't even use __attribute__((always_inline)) and the behaviour differs from without -flto. How is that a WONTFIX?
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Additional Comments From b dot gunreben at web dot de 2005-07-19 16:50 --- I did some more tests and it looks like --disable-checking also disables the bug. At least --enable-checking was enough to reproduce it. My latest configuration with this bug was Configured with: ../configure --enable-languages=c,c++ --enable-checking Thread model: posix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c/44581] New: internal compiler error: in simplify_subreg
when trying to compile fftw3, I get the following error: gcc -O2 -g -mpa-risc-1-0 -c r2cf_16.i -fPIC r2cf_16.i: In function r2cf_16: r2cf_16.i:119:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5143 Please submit a full bug report, gcc is: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/hppa2.0-suse-linux/4.5/lto-wrapper Target: hppa2.0-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --build=hppa2.0-suse-linux Thread model: posix gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) attaching preprocessed source. -- Summary: internal compiler error: in simplify_subreg Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: b dot gunreben at web dot de GCC target triplet: hppa2.0-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
[Bug c/44581] internal compiler error: in simplify_subreg
--- Comment #1 from b dot gunreben at web dot de 2010-06-18 15:32 --- Created an attachment (id=20939) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20939&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
[Bug java/44876] New: internal compiler error: Segmentation fault
Hi, I am trying to compile Spring 2.0.3 framework jars on AIX with gcj 4.3.3. When I try to compile spring-2.0.6.jar to an so file, I get the following error: === org/springframework/aop/aspectj/annotation/InstantiationModelAwarePointcutAdvisorImpl$PerTargetInstantiationModelPointcut.java: In class 'org.springframework.aop.aspectj.annotation.InstantiationModelAwarePointcutAdvisorImpl$PerTargetInstantiationModelPointcut': org/springframework/aop/aspectj/annotation/InstantiationModelAwarePointcutAdvisorImpl$PerTargetInstantiationModelPointcut.java: In constructor '(org.springframework.aop.aspectj.annotation.InstantiationModelAwarePointcutAdvisorImpl,org.springframework.aop.aspectj.AspectJExpressionPointcut,org.springframework.aop.Pointcut,org.springframework.aop.aspectj.annotation.MetadataAwareAspectInstanceFactory,org.springframework.aop.aspectj.annotation.InstantiationModelAwarePointcutAdvisorImpl$1)': org/springframework/aop/aspectj/annotation/InstantiationModelAwarePointcutAdvisorImpl$PerTargetInstantiationModelPointcut.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. === I was able to compile other dependent libraries like aspectjrt etc. This is the commang I am using: gcj -shared -findirect-dispatch -fjni -fPIC -o /home/gcjtesting/samplespring/lib/spring-2.0.6.so /home/gcjtesting/samplespring/lib/spring-2.0.6.jar; -- Summary: internal compiler error: Segmentation fault Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: B dot Kameswararao at igate dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44876
[Bug c/21122] New: ICE in schedule_insns, at sched-rgn.c:2549
The code is taken from the multimedia package pd and reduced. It may be reproduced with # gcc -c -O2 d.i d.i: In function 'osc_perform': d.i:35: internal compiler error: in schedule_insns, at sched-rgn.c:2549 -- Summary: ICE in schedule_insns, at sched-rgn.c:2549 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: b dot gunreben at web dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-suse-linux-gnu GCC host triplet: hppa-suse-linux-gnu GCC target triplet: hppa-suse-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21122
[Bug c/21122] ICE in schedule_insns, at sched-rgn.c:2549
--- Additional Comments From b dot gunreben at web dot de 2005-04-20 14:13 --- Created an attachment (id=8688) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8688&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21122
[Bug c++/21123] New: ICE in cp_expr_size, at cp/cp-objcp-common.c:101
this code is from the package arts, preprocessed and reduced. The bug may be
reproduced with
# g++ -c mcop.ii
mcop.ii: In member function 'std::vector >
Arts::InterfaceRepo_base::_ZTv0_n12_NK4Arts18InterfaceRepo_base15_defaultPortsInEv()
const':
mcop.ii:134: internal compiler error: in cp_expr_size, at
cp/cp-objcp-common.c:101
--
Summary: ICE in cp_expr_size, at cp/cp-objcp-common.c:101
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b dot gunreben at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: hppa-suse-linux-gnu
GCC host triplet: hppa-suse-linux-gnu
GCC target triplet: hppa-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c++/21123] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Additional Comments From b dot gunreben at web dot de 2005-04-20 14:28 --- Created an attachment (id=8689) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8689&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c++/21123] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Additional Comments From b dot gunreben at web dot de 2005-04-22 08:01 --- I just tested on a compiler without additional patches at all. The version is g++ (GCC) 4.0.0 20050415, means CVS from april 15th. I still get the same bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug target/66960] Add interrupt attribute to x86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
Goswin von Brederlow changed:
What|Removed |Added
CC||goswin-v-b at web dot de
--- Comment #11 from Goswin von Brederlow ---
I think the design is fundamentally lacking in the following points:
1. interrupt handler must be declared with a mandatory pointer argument:
struct interrupt_frame;
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame)
{
...
}
and user must properly define the structure the pointer pointing to.
First how does one define the struct interrupt_frame properly? What is in
there? Is that just the data the CPU pushes to the stack? If so then gcc should
define the structure somewhere so code can be written cpu independent.
Since the frame pointer is passed as argument I assume the function prolog will
save the first argument register (on amd64) to stack. Is that to be included in
the struct interrupt_frame?
Secondly how does one access the original register contents? Some kernel
designs use a single kernel stack and switch tasks when returning to user
space. That means that one has to copy all the user registers into the thread
structure and reload a new set of user registers from the new thread on exit
from the interrupt handler. The above interface would not allow this.
2. exception handler:
The exception handler is very similar to the interrupt handler with a
different mandatory function signature:
typedef unsigned int uword_t __attribute__ ((mode (__word__)));
struct interrupt_frame;
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame, uword_t error_code)
{
...
}
and compiler pops the error code off stack before the 'IRET' instruction.
In a kernel there will always be some exception that simply prints a register
dump and stack backtrace. So again how do you access the original register
contents?
Secondly why pass error_code as argument if is already on the stack and could
be accessed through the frame pointer? The argument register (amd64) would have
to be saved on the stack too causing an extra push/pop. But if it is passed as
argument then why not pop it before the call to keep the stack frame the same
as for interrupts (assuming the saved registers are not included in the frame)?
If it is not poped or saved registers are included in the frame then the
exception stack frame differs from the interrupt frame (extra error_code and
extra register). They should not use the same structure, that's just confusing.
'no_caller_saved_registers' attribute
Use this attribute to indicate that the specified function has no
caller-saved registers. That is, all registers are callee-saved.
Does that include the argument registers (if the function takes arguments)?
Wouldn't it be more flexible to define a list of registers that the function
will clobber?
[Bug target/66960] Add interrupt attribute to x86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #13 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #12)
> (In reply to Goswin von Brederlow from comment #11)
> > I think the design is fundamentally lacking in the following points:
> >
> > 1. interrupt handler must be declared with a mandatory pointer argument:
> >
> > struct interrupt_frame;
> >
> > __attribute__ ((interrupt))
> > void
> > f (struct interrupt_frame *frame)
> > {
> > ...
> > }
> >
> > and user must properly define the structure the pointer pointing to.
> >
> > First how does one define the struct interrupt_frame properly? What is in
> > there? Is that just the data the CPU pushes to the stack? If so then gcc
> > should define the structure somewhere so code can be written cpu
> > independent.
>
> interrupt data is pushed onto stack by CPU:
>
> struct interrupt_frame
> {
> uword_t ip;
> uword_t cs;
> uword_t flags;
> uword_t sp;
> uword_t ss;
> };
>
> However, void * works if you need to access interrupt data. Interrupt
> handler should provide its working definition.
>
> > Since the frame pointer is passed as argument I assume the function prolog
> > will save the first argument register (on amd64) to stack. Is that to be
> > included in the struct interrupt_frame?
>
> No. The interrupt frame pointer points to interrupt data on stack
> pushed by CPU.
>
> > Secondly how does one access the original register contents? Some kernel
> > designs use a single kernel stack and switch tasks when returning to user
> > space. That means that one has to copy all the user registers into the
> > thread structure and reload a new set of user registers from the new thread
> > on exit from the interrupt handler. The above interface would not allow
> > this.
>
> The interrupt attribute provides a way to access interrupt data on stack
> pushed by CPU, nothing more and nothing less.
That design seriously limits the usability of this feature.
> >
> > 2. exception handler:
> >
> > The exception handler is very similar to the interrupt handler with a
> > different mandatory function signature:
> >
> > typedef unsigned int uword_t __attribute__ ((mode (__word__)));
> >
> > struct interrupt_frame;
> >
> > __attribute__ ((interrupt))
> > void
> > f (struct interrupt_frame *frame, uword_t error_code)
> > {
> > ...
> > }
> >
> > and compiler pops the error code off stack before the 'IRET'
> > instruction.
> >
> > In a kernel there will always be some exception that simply prints a
> > register dump and stack backtrace. So again how do you access the original
> > register contents?
>
> You need to do that yourself.
Which means __attribute__ ((interrupt)) can't be used for exceptions half the
time.
> > Secondly why pass error_code as argument if is already on the stack and
> > could be accessed through the frame pointer? The argument register (amd64)
> > would have to be saved on the stack too causing an extra push/pop. But if it
> > is passed as argument then why not pop it before the call to keep the stack
> > frame the same as for interrupts (assuming the saved registers are not
> > included in the frame)?
>
> error_code is a pseudo parameter, which is mapped to error code on stack
> pushed by CPU. You can write a simple code to see it yourself.
Couldn't the same trick be used for registers? Pass them as pseudo parameters
and they either resolve to the location on the stack where gcc did save them or
become the original register unchanged.
> > If it is not poped or saved registers are included in the frame then the
> > exception stack frame differs from the interrupt frame (extra error_code and
> > extra register). They should not use the same structure, that's just
> > confusing.
> >
> > 'no_caller_saved_registers' attribute
> >
> > Use this attribute to indicate that the specified function has no
> > caller-saved registers. That is, all registers are callee-saved.
> >
> > Does that include the argument registers (if the function takes arguments)?
>
> Yes.
>
> > Wouldn't it be more flexible to define a list of registers that the function
> > will clobber?
>
> How do programmer know which registers will be clobbered?
The programmer writes the function. He declares what registers will be
clobbered and gcc will add the necessary code to preserve any other registers
it uses inside the function.
[Bug target/66960] Add interrupt attribute to x86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #15 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #14)
> (In reply to Goswin von Brederlow from comment #13)
> > > > Secondly why pass error_code as argument if is already on the stack and
> > > > could be accessed through the frame pointer? The argument register
> > > > (amd64)
> > > > would have to be saved on the stack too causing an extra push/pop. But
> > > > if it
> > > > is passed as argument then why not pop it before the call to keep the
> > > > stack
> > > > frame the same as for interrupts (assuming the saved registers are not
> > > > included in the frame)?
> > >
> > > error_code is a pseudo parameter, which is mapped to error code on stack
> > > pushed by CPU. You can write a simple code to see it yourself.
> >
> > Couldn't the same trick be used for registers? Pass them as pseudo
> > parameters and they either resolve to the location on the stack where gcc
> > did save them or become the original register unchanged.
>
> No. We only do it for data pushed onto stack by CPU.
I was thinking of something like:
__attribute__ ((interrupt("save_regs")))
void
f (struct interrupt_frame *frame, uword_t error_code, struct regs regs)
{
kprintf("user SP = %#016x\n", regs.sp);
}
[Bug target/66960] Add interrupt attribute to x86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #17 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #16)
> (In reply to Goswin von Brederlow from comment #15)
>
> > > No. We only do it for data pushed onto stack by CPU.
> >
> > I was thinking of something like:
> >
> > __attribute__ ((interrupt("save_regs")))
> > void
> > f (struct interrupt_frame *frame, uword_t error_code, struct regs regs)
> > {
> > kprintf("user SP = %#016x\n", regs.sp);
> > }
>
> It is an interesting idea. But frame and err_code are created by caller,
> which is CPU, not by callee. You want to not only save all original
> registers of interrupted process, but also make them available to interrupt
> handler. This won't be supported without significant changes in
> infrastructure.
Is it a significant change?
On a normal function gcc creates a stackframe and pushes callee saved registers
that it later uses onto the stack. I'm suggesting doing much the same with 2
small changes:
1) push all registers unconditionally
2) make the address where the registers got pushed to known to the function
[Bug c/31069] New: execve doesn't work correct in some cases
This bug only occurs with gcc 4.x.x on hpux. In certain circumstances the parameter for the environment will be assigned as argument for the command. I've written some code which will show you the exact problem. You need openssl to reproduce this test. The expected output is: Generating a 1024 bit RSA private key ...++ ++ writing new private key to 'server.key' - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]:State or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, YOUR name) []:Email Address []: The same program compiled with gcc 4.x.x: unknown option MYVAR=TEST req [options] outfile where options are -inform arginput format - DER or PEM -outform arg output format - DER or PEM -in arginput file -out arg output file -text text form of request -pubkeyoutput public key -noout do not output REQ -verifyverify signature on REQ -modulus RSA modulus -nodes don't encrypt the output key -engine e use engine e, possibly a hardware device -subject output the request's subject -passinprivate key password source -key file use the private key contained in file -keyform arg key file format -keyout argfile to send the key to -rand file:file:... load the file (or the files in the directory) into the random number generator -newkey rsa:bits generate a new RSA key of 'bits' in size -newkey dsa:file generate a new DSA key, parameters taken from CA in 'file' -[digest] Digest to sign with (md5, sha1, md2, mdc2, md4) -config file request template file. -subj arg set or modify request subject -new new request. -batch do not ask anything during request generation -x509 output a x509 structure instead of a cert. req. -days number of days a certificate generated by -x509 is valid for. -set_serialserial number to use for a certificate generated by -x509. -newhdroutput "NEW" in the header lines -asn1-kludge Output the 'request' in a format that is wrong but some CA's have been reported as requiring -extensions .. specify certificate extension section (override value in config file) -reqexts ..specify request extension section (override value in config file) -utf8 input characters are UTF8 (default ASCII) -nameopt arg- various certificate name options -reqopt arg- various request text options best regards! Bernd -- Summary: execve doesn't work correct in some cases Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: b dot krumboeck at rewe-group dot at GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
[Bug c/31069] execve doesn't work correct in some cases
--- Comment #1 from b dot krumboeck at rewe-group dot at 2007-03-07 12:33 --- Created an attachment (id=13161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13161&action=view) example code to reproduce the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
[Bug c/31069] execve doesn't work correct in some cases
--- Comment #3 from b dot krumboeck at rewe-group dot at 2007-03-07 15:27 --- Oh, you're right! Thank you! I tried to debug for 3 days, without success. Linux, HPUX, GCC 4.X and GCC 3.4.2, . You are a hero! Once again, thank you very much. PS: Sorry for wasting your time. best regards! Bernd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
[Bug c/38227] New: gcc fails to correctly pass arguments with ms_abi function pointers
When calling function pointers that have been marked with __attribute__((ms_abi)) the arguments will not be passed correctly. A simple testcase is enough to expose the wrong behavior. -- Summary: gcc fails to correctly pass arguments with ms_abi function pointers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m dot b dot lankhorst at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug c/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2008-11-22 13:33 --- Created an attachment (id=16748) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16748&action=view) Minimal testcase Compile with amd64 compiler without optimizations and run it. Expected: Number is: 1234567890abcdef Actual result: Number is: 0 (May vary) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #4 from m dot b dot lankhorst at gmail dot com 2008-11-23 21:11 --- Patch seems to fix the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug c/38366] gcc doesn't call functions that are struct arguments correctly
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2008-12-02 09:08 --- Created an attachment (id=16806) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16806&action=view) testcase Testcase that should return '1 2 3 4 5 6 7', but on my computer returns '1 2 3 4 5 6 1' (last number being undefined) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38366
[Bug c/38366] New: gcc doesn't call functions that are struct arguments correctly
If a function pointer is part of a struct, and it is called from a function marked with ms_abi, the 7th argument will be placed wrongly on the stack. It is placed at 20(%rsp) instead of at (%rsp), which means that programs like wine will fail. Testcase attached -- Summary: gcc doesn't call functions that are struct arguments correctly Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m dot b dot lankhorst at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38366
[Bug middle-end/38299] internal error: segmentation fault
--- Comment #3 from grant dot b dot edwards at gmail dot com 2009-01-05 19:40 --- I've just run across the exact same problem using 3.4.4 to build an arm-elf 3.2.1 cross-compiler on Cygwin. Building the same exact same compiler using 3.4.6 on Linux works fine, so it appears to be something Cygwin-specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38299
[Bug c++/28498] New: fstack-protector causes crash in combination with -Os
When compiling c++ code, you can get an error similar to this one:
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:
In function '_RandomAccessIterator
std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, _Tp)
[with _RandomAccessIterator = __gnu_cxx::__normal_iterator > >, _Tp = QRect]':
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:2182:
internal compiler error: Segmentation fault
according to gcc -v, cc1plus was run with
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -quiet -v -D_GNU_SOURCE -D__PIC__
-DPIC windowgrabber.cc -fPIC -fstack-protector-all -quiet -dumpbase
windowgrabber.cc -mtune=pentiumpro -auxbase windowgrabber -Os -version -fPIC
-fstack-protector-all -o /tmp/cchIBKrS.s
I'll attach source
--
Summary: fstack-protector causes crash in combination with -Os
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot b dot lankhorst at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28498
[Bug middle-end/28498] fstack-protector causes crash in combination with -Os
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2006-07-26 17:42 --- Created an attachment (id=11949) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11949&action=view) The source mentioned in description Source that won't compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28498
[Bug c++/100127] New: [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
Bug ID: 100127
Summary: [coroutines] internal compiler error compiling promise
with custom awaiter
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: riki--b at hotmail dot it
Target Milestone: ---
Created attachment 50621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50621&action=edit
Preprocessed source
The following code (preprocessed source in attachments) does not compile and
causes a compiler segfault:
```
#include
#include
struct future
{
using value_type = int;
struct promise_type;
using handle_type = std::coroutine_handle;
handle_type _coroutine;
future(handle_type h) : _coroutine{h} {}
~future() noexcept{
if (_coroutine) {
_coroutine.destroy();
}
}
value_type get() {
auto ptr = _coroutine.promise()._value;
return *ptr;
}
struct promise_type {
std::optional _value = std::nullopt;
future get_return_object() {
return future{handle_type::from_promise(*this)};
}
void return_value(value_type val) {
_value = static_cast(val);
}
auto initial_suspend() noexcept {
class awaiter {
std::optional & value;
public:
explicit awaiter(std::optional & val) noexcept :
value{val} {}
bool await_ready() noexcept { return value.has_value(); }
void await_suspend(handle_type) noexcept { }
value_type & await_resume() noexcept { return *value; }
};
return awaiter{_value};
}
std::suspend_always final_suspend() noexcept {
return {};
}
void return_void() {}
void unhandled_exception() {}
};
};
future create_future()
{ co_return 2021; }
int main()
{ auto f = create_future(); }
```
Returning `std::suspend_never{}` instead of the awaiter compiles correctly.
Output of g++ -v -save-temps -std=c++20 -fcoroutines ${source}.cpp:
```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --ma
ndir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/ --enable-languag
es=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --
enable-__cxa_atexit --enable-cet=auto --enable-checking=release
--enable-clocale=gnu --enable-default-pi
e --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libibe
rty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-thr
eads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror gdc_
include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-m
arch=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test_bug.cpp -mtune=generic
-march=x86-64 -std=c++2a -fcoroutines -fpch-preprocess -o test_bug.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/
include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-m
arch=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -fpreprocessed test_bug.ii
-quiet -dumpbase test_bug.cp
p -mtune=generic -march=x86-64 -auxbase test_bug -std=c++2a -version
-fcoroutines -o test_bug.s
GNU C++17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl
version isl-0.21-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 1
[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
--- Comment #2 from Riccardo Brugo ---
(In reply to Iain Sandoe from comment #1)
> I think that this issue is already fixed in the released 10.3 branch and in
> master (will shortly become GCC11). Please could you try one of those?
>
> $ ./gcc-10/gcc-10/bin/g++ -std=c++20 -fcoroutines pr100127.C -S -save-temps
> pr100127.C: In function ‘future create_future()’:
> pr100127.C:54:8: error: the coroutine promise type
> ‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
> ‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
>54 | future create_future()
> |^
> pr100127.C:49:14: note: ‘return_void’ declared here
>49 | void return_void() {}
> | ^~~
> pr100127.C:31:14: note: ‘return_value’ declared here
>31 | void return_value(value_type val) {
> | ^~~~
>
> ===
>
> $ ./gcc-master/gcc-11-0-1/bin/g++ -std=c++20 -fcoroutines pr100127.C -S
> -save-temps
> pr100127.C: In function ‘future create_future()’:
> pr100127.C:54:8: error: the coroutine promise type
> ‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
> ‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
>54 | future create_future()
> |^
> pr100127.C:49:14: note: ‘return_void’ declared here
>49 | void return_void() {}
> | ^~~
> pr100127.C:31:14: note: ‘return_value’ declared here
>31 | void return_value(value_type val) {
> | ^~~~
Removing the `return_void` member function will trigger a compilation error in
trunk (https://godbolt.org/z/7vfT89KEx) and a segmentation fault in 10.3
(https://godbolt.org/z/7b37sPbfo)
[Bug sanitizer/97294] New: ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97294 Bug ID: 97294 Summary: ASAN "dynamic-stack-buffer-overflow" false positive with OpenMP reduction to std::vector Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: paulg-b at web dot de CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 49308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49308&action=edit Minimal example When the attached minimal example is compiled with g++ -fsanitize=address -fopenmp -o asan_omp_test asan_omp_test.cpp and executed, ASAN reports a dynamic-stack-buffer-overflow. I tested gcc 10.2.1 and 8.2 on different systems (one being the login node of a cluster, the other being my personal computer with a Fedora 32 OS). ASAN seems to report on the copy of the array-section invoked by the omp clause reduction(+ : ptr[:v.size()]) where ptr is a copy of v.data() and v is the std::vector. This does *not* happen when the std::vector is replaced by std::array. The same code does *not* report anything when compiled and ASAN-instrumented with clang 10.0.1. I first filed a issue https://github.com/google/sanitizers/issues/1326 and was sent here. The problem is also *not* reproducible in C when replacing the std::vector with dynamic memory allocated via calloc.
[Bug c/42079] New: missing unitialized warning on simple testcase
This code should warn that foo is used uninitialized, but it doesn't.. gcc 4.3
and gcc 4.4 both fail to report a warning
extern void do_something(void **foo);
extern int cond(void);
int main(int argc, char *argv[])
{
void *foo;
if (cond())
do_something(&foo);
*argv = foo;
return 0;
}
--
Summary: missing unitialized warning on simple testcase
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot b dot lankhorst at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42079
[Bug c/43869] New: ms_abi -> sysv_abi passing float arguments incorrectly
Float arguments are passed incorrectly from a ms_abi function to a sysv function, as can be witnessed by a simple testcase, which fails on all optimizations. I don't think this is a regression, as wine always failed on that testcase. -- Summary: ms_abi -> sysv_abi passing float arguments incorrectly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m dot b dot lankhorst at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug c/43869] ms_abi -> sysv_abi passing float arguments incorrectly
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2010-04-23 18:38 --- Created an attachment (id=20474) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20474&action=view) testcase testcase that fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug target/43869] ms_abi -> sysv_abi passing float arguments incorrectly
--- Comment #4 from m dot b dot lankhorst at gmail dot com 2010-04-25 14:41 --- Created an attachment (id=20483) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20483&action=view) Patch that fixes the testcase It appears that SSE_REGPARM_MAX will change based on ix86_cfun_abi(), so using SSE_REGPARM_MAX will cause sse regparm max to be 4, if calling a sysv function from a ms_abi function. The attached patch will clean up some of the issues. setup_incoming_varargs_64 will also assume the sysv abi now, since setup_incoming_varargs_ms_64 is a separate function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
[Bug c/104828] New: Wrong out-of-bounds array access warning on literal pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104828
Bug ID: 104828
Summary: Wrong out-of-bounds array access warning on literal
pointers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
Trying to access a pointer cast from an integer literal gives a out of bounds
warning:
--
#define UART0_BASE 0x3F201000
void putc(char c) {
volatile unsigned int *UART0_DR = (volatile unsigned int *)(UART0_BASE);
volatile unsigned int *UART0_FR = (volatile unsigned int *)(UART0_BASE +
0x18);
while (*UART0_FR & (1 << 5) ) { }
*UART0_DR = c;
}
--
:5:3: warning: array subscript 0 is outside array bounds of 'volatile
unsigned int [0]' [-Warray-bounds]
5 | *UART0_DR = c;
| ^
The error goes away if the pointer is global or static.
The error remains if the pointer is returned from a function with alloc_size
attribute:
--
#include
#include
#define UART0_BASE 0x3F201000
volatile uint32_t * make(uintptr_t addr, size_t size = 4) __attribute__
((alloc_size (2)));
volatile uint32_t * make(uintptr_t addr, size_t size) {
(void)size;
return (volatile uint32_t *)addr;
}
void putc(char c) {
volatile uint32_t *UART0_DR = make(UART0_BASE);
volatile uint32_t *UART0_FR = make(UART0_BASE + 0x18);
while (*UART0_FR & (1 << 5) ) { }
*UART0_DR = c;
}
--
:16:3: warning: array subscript 0 is outside array bounds of 'volatile
uint32_t [0]' [-Warray-bounds]
16 | *UART0_DR = c;
| ^
The warning goes away if the "make" helper is extern and can't be inlined.
Gcc 11.2 and before do not give this warning.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #29 from Goswin von Brederlow --- (In reply to Jakub Jelinek from comment #26) > That is nonsense. The amount of code in the wild that relies on (type > *)CONSTANT > working is insane, you can't annotate it all. And it has worked fine for > decades. The pointers aren't invalid, they point to valid objects in the > address space. > POSIX supports MAP_FIXED for a reason (and in many embedded cases one > doesn't even have an MMU and I/O or other special areas are mapped directly). A cast from integer to pointer is implementation defined behavior except for 1) 0 which must cast to NULL / nullptr 2) if the integer value was constructed by casting a pointer to integer of suitable size There is no garantee in the C standard that '(type *)CONSTANT' will actually point to the hardware address 'CONSTANT'. It's just how gcc happens to do it in most cases. So no, your code is not fine. It is fragile. It relies on implementation details of gcc. But lets not argue about that. Detecting NULL pointer access and offsets to it is a good thing, except where it isn't. It's unfortunate it also catches other stuff. Under AmigaOS the pointer to the exec.library (no program can work without that) is stored in address 4. So there isn't an universal value of "this is big enough not to be an offset to NULL". Detecting if an expression involves NULL might be hard. If it starts as NULL->member then it's easy. What about (&x - &x)+offsetof(X.member) or (uintptr_t)&x.member - (uintptr_t)&x or similar stuff you easily get with macros. On the other side (T*)0x45634534 should be easy to detect as not being NULL+offset. It's a literal. But the grey zone inbetween the easy cases might be to big to be useful. Alternatively an annotation for this would actually go nicely with another bug I reported: 'add feature to create a pointer to a fixed address as constexpr' [1]. The annotation would avoid the warning and also make it a pointer literal that can be used in constexpr (appart from accessing the address). It could also cause gcc to handle the case where CONSTANT can't just be cast to pointer and work. Like when using address authentication on ARMv8 CPUs, to name something modern. And the size of the object the pointer points to can be taken from its type, i.e. the pointer is to a single object and never an (infinite) array. If you want a pointer to an array then cast it to an array of the right size. -- [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104514
[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #38 from Goswin von Brederlow --- (In reply to Jonathan Wakely from comment #34) > (In reply to Goswin von Brederlow from comment #29) > > There is no garantee in the C standard that '(type *)CONSTANT' will actually > > point to the hardware address 'CONSTANT'. It's just how gcc happens to do it > > in most cases. So no, your code is not fine. It is fragile. It relies on > > implementation details of gcc. But lets not argue about that. > > Actually, lets. It relies on guaranteed behaviour of GCC: > https://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html > That's not going to change, and neither is the fact that the Linux kernel > depends on implementation-defined properties of GCC (where > "implementation-defined" is used in the formal sense, not "just an > implementation detail that might change tomorrow"). Thank you for agreeing with me that "It relies on implementation details of gcc". That's exactly what I said.
[Bug c++/104514] New: add feature to create a pointer to a fixed address as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104514 Bug ID: 104514 Summary: add feature to create a pointer to a fixed address as constexpr Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: goswin-v-b at web dot de Target Milestone: --- In the embedded and micro controller world memory mapped registers are very common. They can be declared as external object and fudged in using linker scripts, which prevents a lot of optimizations. Or they can be declared as pointers, in the most reduced form like this: int *p = (int*)0x12345678; My problem now is that this isn't a constexpr and can't be used in any constexpr code: foo.cc:1:20: error: ‘reinterpret_cast’ from integer to pointer 1 | constexpr int *p = (int*)0x12345678; |^~~~ While this is the right thing in general there should be a way to allow this special case. A way to tell the compiler that an object exists at a fixed address and still be a constexpr.
[Bug c/105521] New: missed optimization in modulo arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521
Bug ID: 105521
Summary: missed optimization in modulo arithmetic
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
I'm trying to compute (a*a)%n for uint64_t types on x86_64 using "gcc -O2 -W
-Wall" like this:
#include
#include
uint64_t sqrmod(uint64_t a, uint64_t n) {
assert(a < n);
unsigned __int128 x = a;
x *= a;
return x % n;
}
I expected to get the following code:
sqrmod:
cmpq%rsi, %rdi
jnb .L13 // assert(a < n) failure
movq%rdi, %rax
mul %rdi
div %rsi
movq%rdx, %rax
ret
The compiler does get the "mul" right but instead of the "div" it throws in a
call to "__umodti3". The "__umodti3" function is horribly long code that will
be worlds slower than a simple div.
Note: The "asset(a < n);" should tell the compiler that the "div" instruction
can not overflow and will not cause a #DivisionError. Without the assert the
compiler could (conditionally) add "a %= n;" for the same effect.
https://godbolt.org/z/cd57Wd4oo
[Bug target/105521] missed optimization in modulo arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521 --- Comment #3 from Goswin von Brederlow --- (In reply to Andrew Pinski from comment #1) > This requires having a, 64bit/32bit (and 128bit/64bit) pattern really. So > this is both a middle-end issue and a target issue. > > Note there might be another bug asking for the same optimization. > > Also note x86_64 might be the only popular target which has this kind of div > instruction so this might not get any attention as it is also a small > peephole where most people don't use 128bit integers either (they are > non-standard even). I know m68k had a 64bit/32bit pattern but it is indeed rare. On x86_64 a (32bit * 32bit = 64bit) % 32bit uses the 128bit/64bit DIV instruction and two extra truncation to 32bit for the input registers. On many cpus that is significantly (factor 3-10) slower than the 64bit/32bit version. This could potentially affect every / and % operation and preceding *, allowing for the faster opcodes with fewer bits to be used where the compiler can reason about the magnitude of the arguments.
[Bug libstdc++/105844] New: std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
Bug ID: 105844
Summary: std::lcm(5, 4) is UB but accepted in a
constexpr due to cast to unsigned
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
Running "gcc-12.1 -std=c++20 -O2 -W -Wall" on
#include
constinit int t = std::lcm(5, 4);
produces
t:
.long -1795017296
The standard says:
> The behavior is undefined if |m|, |n|, or the least common multiple of |m|
> and |n| is not representable as a value of type std::common_type_t.
Which is the case here, the lvm overflows and is undefined. The negative number
produced is not correct and the compile should fail.
The problem is the __absu function in casting the arguments to an
unsigned type:
// std::abs is not constexpr, doesn't support unsigned integers,
// and std::abs(std::numeric_limits::min()) is undefined.
template
constexpr _Up
__absu(_Tp __val)
{
static_assert(is_unsigned<_Up>::value, "result type must be unsigned");
static_assert(sizeof(_Up) >= sizeof(_Tp),
"result type must be at least as wide as the input type");
return __val < 0 ? -(_Up)__val : (_Up)__val;
}
/// Least common multiple
template
constexpr common_type_t<_Mn, _Nn>
lcm(_Mn __m, _Nn __n) noexcept
{
static_assert(is_integral_v<_Mn>, "std::lcm arguments must be integers");
static_assert(is_integral_v<_Nn>, "std::lcm arguments must be integers");
static_assert(_Mn(2) == 2, "std::lcm arguments must not be bool");
static_assert(_Nn(2) == 2, "std::lcm arguments must not be bool");
using _Up = make_unsigned_t>;
return __detail::__lcm(__detail::__absu<_Up>(__m),
__detail::__absu<_Up>(__n));
}
__lvm is called with unsigned arguments which do not overflow for the given
numbers. And any unsigned overflow would not be undefined behavior. The result
of __lcm is then converted back to the signed type, which is not UB.
I suggest the following changes:
// LCM implementation
template
constexpr _Tp
__lcm(_Tp __m, _Tp __n)
{
static_assert(__m == 0 || __n == 0 || __m / __detail::__gcd(__m, __n) <=
std::numeric_limits<_Tp>::max() / __n, "std::lcm not representable in commont
type");
return (__m != 0 && __n != 0)
? (__m / __detail::__gcd(__m, __n)) * __n
: 0;
}
/// Least common multiple
template
constexpr common_type_t<_Mn, _Nn>
lcm(_Mn __m, _Nn __n) noexcept
{
static_assert(is_integral_v<_Mn>, "std::lcm arguments must be integers");
static_assert(is_integral_v<_Nn>, "std::lcm arguments must be integers");
static_assert(_Mn(2) == 2, "std::lcm arguments must not be bool");
static_assert(_Nn(2) == 2, "std::lcm arguments must not be bool");
using _Cp = common_type_t<_Mn, _Nn>;
using _Up = make_unsigned_t>;
_Up t = __detail::__lcm(__detail::__absu<_Up>(__m),
__detail::__absu<_Up>(__n));
static_assert(t <= (_Up)std::numeric_limits<_Cp>::max(), "std::lcm not
representable in commont type");
return t;
}
[Bug libstdc++/105844] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 Goswin von Brederlow changed: What|Removed |Added CC||goswin-v-b at web dot de --- Comment #1 from Goswin von Brederlow --- Created attachment 53081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53081&action=edit Patch for numeric Patch for the proposed changes
[Bug libstdc++/105844] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 --- Comment #2 from Goswin von Brederlow --- I know the patch doesn't work yet, the static_asserts aren't constexpr. But hopefully it gives someone enough of an idea to fix it.
[Bug libstdc++/105844] std::lcm(50000, 49999) is UB but accepted in a constexpr due to cast to unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844 --- Comment #3 from Goswin von Brederlow --- Created attachment 53082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53082&action=edit Working patch for detecting UB This will abort if the arguments are too large instead of static_assert, best I could figure out that would work.
[Bug preprocessor/38161] New: #elif breaks
#ifndef FOO
#define FOO sizeof(void *)
#elif FOO
#endif
t.c:3:7: error: missing binary operator before token "("
I expect it's caused by the fix to bug #36320.
--
Summary: #elif breaks
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161
[Bug preprocessor/38161] [4.4 regression] #elif breaks
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2008-11-17 20:15 --- Subject: Re: [4.4 regression] #elif breaks Yes, I should have read the #36320 text more carefully. I merely noticed that its empty #elif cannot expand to anything correct, while my example can (and does in the real-life case which produced it). I thought C99 6.10p7 was what saved it: The preprocessing tokens within a preprocessing directive are not subject to macro expansion unless otherwise stated. but maybe not. 6.10.1p3 doesn't say anything about some #elif branches not being evaluated:-( Hopefully that's just overly standard-lawerly though. Maybe comp.std.c would have been a better place to ask. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161
[Bug c/40530] New: Suggestion: -Wsignless-bitfields
I imagine a bitfield which does not specify 'signed' or 'unsigned' will often be a bug in user code - maybe the programmer did not know or did not remember that 'int i:3;' can be unsigned. I suggest a warning for that in user code. Maybe included in -Wextra, but I cannot guess how much such correct code is around. The warning should be quiet about system headers, which may know how the system compiler treats such bitfields. -- Summary: Suggestion: -Wsignless-bitfields Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: h dot b dot furuseth at usit dot uio dot no http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40530
[Bug c++/29455] New: Issues with -Wchar-subscripts
[This is both a C and C++ bug report, not sure how to classify that.]
int a[256];
int A(char c) { return a[c]; } // C and C++ warnings, OK.
int D(void) { return a['%'];} // Spurious C++ warning, no C warning
int B(void) { return a['å'];} // C++ warning, missing C warning
int C(void) { return a['\300']; } // C++ warning, missing C warning
So,
g++ -Wchar-subscripts warns "array subscript has type 'char'" about
arr['%'] even though the index is guaranteed positive. gcc does not.
OTOH, gcc does not warn about a['\300'] or a['å'] (8-bit a-ring), even
with -fsigned-char which ensures that the subscript is negative.
Note, arr['@'] COULD be a bug in the program with characters like @ which
are not in the basic execution character set: C99 5.2.1p3; I haven't got
the C++ standard. Only characters in that character set are guaranteed
to be positive: C99 6.2.5p3. If the program is intended to be portable
to other character sets, it is buggy. Even if gcc doesn't support a
machine with that charset - if anyone does these days:-) So it might
make sense to have a -Wchar-subscripts=2 warning which only assumes the
basic execution character set, not the current character set.
In preprocessor expressions I don't know if it should check the source
or execution character set, or both...
--
Summary: Issues with -Wchar-subscripts
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-10-14 17:06 --- Subject: Re: Issues with -Wchar-subscripts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-10-14
17:52 ---
Subject: Re: Issues with -Wchar-subscripts
Sorry about the empty answer.
pinskia at gcc dot gnu dot org writes:
> 'a' in C is not of the type char but instead int so not warning there
> is correct really.
Hmm, yes, it fits the documentation. I guess what I'm asking is for a
change in the warning's spec. array['8-bit char'] is almost certainly
wrong in an iso646-derived charset, since for a portable program the
programmer can't know if the index is positive or negative. I don't
know if enough information is available in C at the time the warning is
given do do that, though.
> Also you forgot one thing '%' does not have to match up with the ANSI
> character set so it could be negative in signed char which means char
> (which could default to signed char) would be different.
No. In a conforming C implementation, the character *which C interprets
as '%'* must have a positive value. Maybe you are thinking of the
opposite case: What its glyph _looks like_ on some display device is out
of scope for the C standard.
In the 7-bit days we had screens with the Norwegian charset NS_4551-1,
but the C compiler (like most of the American-made computer) thought
it received ASCII. Thus we had to write
main() æ printf("Hello, world!Øn"); return 0; å
for the ASCII compiler to see
main() { printf("Hello, world!\n"); return 0; }
The ANSI Rationale blessed this behavior since it already was
common (and more readable than trigraphs), the example there was
the Yen sign. I can probably dig it up if you are interested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #5 from h dot b dot furuseth at usit dot uio dot no 2006-10-17
12:49 ---
Subject: Re: Issues with -Wchar-subscripts
pinskia at gcc dot gnu dot org writes:
> 'a' in C is not of the type char but instead int so not warning
> there is correct really.
How about a -Warray-bounds option, maybe in -Wall, which tries to
catch array[negative index] and (when the array length is known)
array[too large positive index]? That will also catch array['\300']
when the program meets a host where char is signed.
It'll give false alarms for fake variable-length arrays, but those are
not common and can be replaced with the real thing now. This, I mean:
struct Foo { blah blah; char array[1]; };
struct Foo *foo = malloc(sizeof(struct Foo) + strlen(str));
strcpy(foo->array, str);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug other/29534] New: ICE in "gcc -O -ftrapv" with decreasing array index
bash$ cat bug.c
int foo(int arr[]) {
int i = 2;
while (arr[--i]) ;
return i;
}
bash$ gcc -O -ftrapv -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
bash$ g++ -O -ftrapv -c bug.c
g++: Internal error: Segmentation fault (program cc1plus)
Compilation succeeds if -O is removed. OTOH, it still crashes
with -O -fno-:
bash$ gcc -O -fno-defer-pop -fno-delayed-branch \
-fno-guess-branch-probability -fno-cprop-registers -fno-loop-optimize \
-fno-if-conversion -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce \
-fno-tree-dominator-opts -fno-tree-dse -fno-tree-ter -fno-tree-lrs \
-fno-tree-sra -fno-tree-copyrename -fno-tree-fre -fno-tree-ch \
-fno-merge-constants -fno-omit-frame-pointer \
-ftrapv -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
--
Summary: ICE in "gcc -O -ftrapv" with decreasing array index
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29534
[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments
--- Comment #22 from h dot b dot furuseth at usit dot uio dot no 2007-08-20 22:45 --- Subject: Re: warn for uninitialized arrays passed as const* arguments manu at gcc dot gnu dot org writes: > But it seems that the current policy of GCC is to not assume that such > functions actually take this into account, since when optimizing > constants are not propagated beyond a call to such function. This is > either the intended behaviour or a missed-optimisation. > It would be nice if it would be a missed-optimisation. A "const" in a function parameter in C is not a promise to the compiler; it would break the C standard to optimize on it. > Otherwise, if this > is the intended behaviour, then both PRs are invalid as Andrew said. They are requests for warning messages, not error messages, because they are _likely_ to be programmer errors. That's what warnings are for. -Wuninitialized is giving false positives anyway, on code which the compiler cannot tell is correct but the programmer can. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
