https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92096
--- Comment #5 from Roger Orr ---
Hello Jakub, I've checked; I no longer see this fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
--- Comment #23 from Roger Orr ---
That's good to hear -- thank you very much!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92096
--- Comment #3 from Roger Orr ---
A binary chop shows the fault starts with r276878.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92096
--- Comment #2 from Roger Orr ---
Hello Richard,
PR92037 appears to be resolved in revision 276804, which precedes the first of
my failing revisions (276902).
FWIW it was still failing last night with 276968
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
I using this invocation:
../gcc-trunk/configure --disable-bootstrap --enable-languages=c,c++
--enable-threads=posix --prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68957
--- Comment #3 from Roger Orr ---
Thanks Jon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68957
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When object modules compiled with -std=c+14 and -std=c++17 are linked together
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
The following code fails to compile:
CODE
template
void sizeof_mismatch()
{
static_assert(T == 0, "sizeof mismatch");
}
int main()
{
if constexpr(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #14 from Roger Orr ---
Confirmed: valgrind now builds successfully with revision 236769.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71252
--- Comment #15 from Roger Orr ---
Sorry for the noise; I'd not noticed there had been a relevant commit.
I'll re-check against trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #13 from Roger Orr ---
Ok, I'll try with trunk (I'd not noticed a relevant change had already been
submitted)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71252
--- Comment #13 from Roger Orr ---
The patch sadly does not appear to fix the (very similar looking) valgrind
compilation failure I posted in pr71269.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269#c7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #7 from Roger Orr ---
I've got a very similar problem, building valgrind with trunk revision 236644:
m_mallocfree.c: In function 'sanity_check_malloc_arena':
m_mallocfree.c:1055:13: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
--- Comment #6 from Roger Orr ---
Created attachment 38563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38563=edit
compiler invocation and output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71240
--- Comment #11 from Roger Orr ---
Thanks.
I can confirm this also successfully compiles the original code from which I
derived the simplified example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71240
--- Comment #1 from Roger Orr ---
(The example code compiles with gcc revision 236175, dated 20160512)
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
Created attachment 38545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38545=edit
Example code, fails with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71015
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71059
--- Comment #4 from Roger Orr ---
Thanks, fixes the ICE I had.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984
--- Comment #5 from Roger Orr ---
Still fails with gcc 6.1
Are there any plans on how (and when) to fix this, fairly serious, fault?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70712
--- Comment #5 from Roger Orr ---
Thank you.
I can confirm that the fix also resolves the original problem from which I
derived the sample program.
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
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
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #60 from Roger Orr ---
Thanks; I can now confirm that a full build of our application with distcc
works without problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #57 from Roger Orr ---
Created attachment 38232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38232=edit
Stripped down intermediate file
I've managed to reproduce the problem without including any proprietary code -
code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #55 from Roger Orr ---
Note - I should have added that I am not at all sure the fix above is
*correct*, simply that it prevents accessing the freed entry.
I don't know enough about how the code works to know whether the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #54 from Roger Orr ---
Unfortunately the patch does not help: the cached 'from' pointer is a pointer
into the old maps entry -- the one which has now been deallocated.
The first test, main_file_p, now (correctly) fails.
The second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #52 from Roger Orr ---
Ah - added print of *pfile->line_table at line 978 and compared with the value
when we error.
978 struct line_maps *line_table = pfile->line_table;
$3702 = {info_ordinary = {maps = 0x7fffec65d000,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #51 from Roger Orr ---
Thanks, I hope to try that on Monday.
The function gets called multiple times, so I need to identify the last time.
The memory must have changed *during* the call to do_linemarker as the new_file
variable is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #49 from Roger Orr ---
Alas, valgrind finds nothing untoward.
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" clean-stage1
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" all-stage1
valgrind /var/tmp/gcc-trunk-234481/build/gcc/cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #47 from Roger Orr ---
Sorry, I wasn't clear enough. I'm unfortunately not at present able to post the
whole source file.
The file I posted *only* contains the line directives, so people can confirm
whether there were any problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #45 from Roger Orr ---
While investigating the problem I am experiencing I have found it is stable
across g++ builds - I have tried a build using revision 234741 which has the
identical diagnostic output from the compilation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #44 from Roger Orr ---
Created attachment 38218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38218=edit
Intermediate file
I am as yet unable to upload the code for an example.
However, I've attached a file containing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #41 from Roger Orr ---
I have seen the message before: for example from a build with revision
line-map.c: file "/usr/include/asm/sockios.h" left but not entered
I've only noticed it with builds from gcc-trunk, which I tested with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #39 from Roger Orr ---
The resolution of this issue causes a problem for me as it results in
compilation errors in our build.
We are compiling with distcc which AIUI distributes the pre-processed
intermediate output.
With revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506
--- Comment #3 from Roger Orr ---
Tested: bootstrap build on cygwin with your patch completed successfully.
I used:
../gcctrunk/configure --enable-languages=c,c++ --prefix=/usr/share/gcc-trunk
make -j5
make install
Thank you :-)
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
The initialization of a VLA char array from a string literal in C++ mode is
surprising: the code appears to copy a string literal starting with the NUL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69487
--- Comment #2 from Roger Orr ---
A braced initializer of characters appears to work consistently with both
compile time and run time arrays.
char buffer[size] = { 'a', 'b' };
produces a buffer with 'a', 'b' and zero padded whether size is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #32 from Roger Orr ---
(In reply to Nick Clifton from comment #26)
> Hi Roger,
>
> > I've tried the patch (applied to 232400 as trunk seems to have other
> > problems on cygwin) and the build now completes successfully.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506
--- Comment #1 from Roger Orr ---
See also http://permalink.gmane.org/gmane.os.cygwin/156987
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
A complete build of gcc on cygwin, with change 232071 backed out (see pr66655),
works with revision 232453 but fails with revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #24 from Roger Orr ---
Thanks Nick.
I've tried the patch (applied to 232400 as trunk seems to have other problems
on cygwin) and the build now completes successfully.
Additionally, the test case no longer crashes.
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #18 from Roger Orr ---
What is the correct way forward with this issue?
Should we reopen this issue, or open a fresh one? (I'm not familiar enough with
the gcc use of bugzilla to know.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #17 from Roger Orr ---
As you say, there seems to be another, unrelated, problem with the current
trunk and cygwin.
However, I have now successfully built gcc version 232300 under cygwin with
this patch.
Unfortunately, if I try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #14 from Roger Orr ---
I don't know I'm afraid: I'm a very occasional mingw user and I haven't
(yet...) tried building gcc on mingw...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67515
--- Comment #10 from Roger Orr ---
Hello Yury, yes the problem with boost was reported as
https://svn.boost.org/trac/boost/ticket/11632
and the ticket contains a proposed solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68982
--- Comment #5 from Roger Orr ---
Thank you ;-)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
Created attachment 37093
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37093=edit
ice-example.cpp: Example program demonstrat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69000
--- Comment #2 from Roger Orr ---
Thanks: apologies that my bugzilla-fu failed to find the duplicate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66808
--- Comment #8 from Roger Orr ---
Thank you.
I've tested the fix and it successfully compiles works both the sample program
uploaded to my duplicate pr69000 and also my original presenting case.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
I notice that is no longer consistently prefixing forward with
std:: and this means ADL gets invoked, which causes trouble when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68982
--- Comment #2 from Roger Orr ---
Created attachment 37082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37082=edit
Example of failure, against code using boost 1.57.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66259
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
NCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67515
--- Comment #4 from Roger Orr ---
Ah - apologies -- I'd got the example by stripping down a call in boost::format
and didn't do a full enough check that the code was well formed: I'll report
that UB to boost.
However as Markus says the seg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67357
--- Comment #3 from Roger Orr rogero at howzatt dot demon.co.uk ---
The following code block also gives an ODR violation with the same versions of
gcc; in this case only a *single* translation unit is involved.
$ cat test.cxx
#include memory
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
The following code generates -Wodr warnings wih gcc 5.2.0
$ cat common.hxx
template typename T
struct values{
typedef T const CT;
};
$ cat test1.cxx
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67357
--- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk ---
The fault still occurs on gcc-5-branch, does not occur on gcc trunk.
I have also found that making a small change to the example in comment 5 of PR
66180 makes that fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343
--- Comment #1 from Roger Orr rogero at howzatt dot demon.co.uk ---
Fails for me (with a very slightly different label: Lubsan_type0) on gcc-trunk
(as of 2015-08-22) without needing the -m32:
$ /usr/share/gcc-trunk/bin/gcc -v
Using built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65152
--- Comment #3 from Roger Orr rogero at howzatt dot demon.co.uk ---
Note that this has been fixed in gcc-trunk (tested 22-Aug-2015)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Target Milestone: ---
Target: x86_64-redhat-linux
Created attachment 35667
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35667action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64181
--- Comment #1 from Roger Orr rogero at howzatt dot demon.co.uk ---
The optimization is also broken in the 5.0 head (5.0.0.20150328)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525
--- Comment #7 from Roger Orr rogero at howzatt dot demon.co.uk ---
Thanks!
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Created attachment 34188
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34188action=edit
Demonstration of the problem
In some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
Roger Orr rogero at howzatt dot demon.co.uk changed:
What|Removed |Added
CC||rogero
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63627
--- Comment #1 from Roger Orr rogero at howzatt dot demon.co.uk ---
Created attachment 33792
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33792action=edit
Example using __atomic_exchange_n that does not generate tsan warnings
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
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
When -fsanitize=address is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63559
--- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk ---
Hi Dmitry,
the false positives I've investigated seem to be down to spin-locked queues and
use of intel tbb concurrency data structures - AFAICT we don't have source
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
When declaring a variable with a bracketed constructor call, and using the same
external name for the first argument and a template instantiation used
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
If a function is declared with a default argument of a template type the
compiler fails if the constructor cannot be instantiated at the point of
definition of the function.
As I understand
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogero at howzatt dot demon.co.uk
Created attachment 30547
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30547action=edit
sample program -- I believe this should compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973
--- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk ---
Thank you. Aoplogies for the noise.
75 matches
Mail list logo
