[Bug target/79868] New: aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868
Bug ID: 79868
Summary: aarch64: diagnostic "malformed target %s value" not
translateable
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from config/aarch64/aarch64.c:
error ("malformed target %s value", pragma_or_attr);
Assuming that the %s placeholder can be either "pragma" or "attribute" (which
should be documented right above the above code line), this message cannot be
translated propertly into French.
le valeur d'attribute
le valeur du pragma
Depending on the inserted word, the outside sentence changes.
Therefore, instead of passing "const char *pragma_or_attr", that parameter
should be a boolean.
if (pragma)
error ("malformed target pragma value");
else
error ("malformed target attribute value");
[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868
--- Comment #1 from Roland Illig ---
Same for:
error ("target %s %qs is invalid", pragma_or_attr, token);
[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 --- Comment #2 from Roland Illig --- Also, the word "attribute" appeared as an untranslated literal: ret = aarch64_process_target_attr (args, "attribute"); This makes it impossible to do any proper translation into any language other than English.
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
--- Comment #10 from Matthias Klose ---
here is one more build failure seen with 20170221, with -O1 (works with -O0),
seen in the gtk-gnutella package:
$ gcc-6 -c -O1 -msecure-plt -mcpu=power8 fileinfo.i
fileinfo.c: In function 'file_info_retrieve_binary':
fileinfo.c:2113:1: internal compiler error: in push_reload, at reload.c:1349
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat fileinfo.i
typedef long a;
enum c { e, f, g, h, i, ab } j();
int l, n, o, p;
a q, r;
void *memcpy();
void b();
static int k(int *s) {
int m;
if (j(&m))
*s = m;
return !0;
}
void d(char s) {
int af[4];
int ag;
enum c ah;
char ai[24 << 11];
unsigned aj;
if (!k(&aj))
goto ak;
for (;;) {
if (!k(&ag))
goto ak;
switch (ah) {
case e:
b("");
b("bad length %d for GUID in fileinfo v%u for \"%s\"");
case i:
b("bad length %d for TTH in fileinfo v%u for \"%s\"", aj);
case ab:
if (ag % 24)
b("for \"%s\"", s);
case f:
if (20 == ag)
case h:
if (20 == ag)
o = 0;
break;
case g:
memcpy(af, ai, sizeof af);
b();
if (p) {
a al, am;
r = al << 2 | am;
n = af[2];
al = n;
l = __builtin_bswap32(af[3]);
am = q = n | l;
}
default:
b("%s0 unhandled field ID %u 0", __func__);
}
}
ak:;
}
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 --- Comment #11 from Matthias Klose --- Created attachment 40883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40883&action=edit preprocessed source (fileinfo.i)
[Bug target/79869] New: i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869
Bug ID: 79869
Summary: i18n: document placeholders for translators
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from config/arc/arc.c:
error ("%s is not available for %s architecture",
DOC, arc_selected_cpu->arch_info->name);
As a translator, I have no idea what the placeholder DOC might contain.
Therefore it should be documented above the function call:
/* TRANSLATORS: the first %s looks like "mfpu=fpus"
or "single precission FPX", the second %s looks like "???" */
While here: the first %s should probably be %qs, since it can consist of
multiple words.
[Bug target/79870] New: i18n: combine structurally identical diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79870 Bug ID: 79870 Summary: i18n: combine structurally identical diagnostics Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- As a translator, I currently have this (from config/arc/arc.c): operand %d should be a 6 bit unsigned immediate operand %d should be a 8 bit unsigned immediate operand %d should be a 3 bit unsigned immediate Translating each of these sentences individually is boring work for each translator. Please make the second number also a placeholder.
[Bug target/79871] New: i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79871
Bug ID: 79871
Summary: i18n: document placeholders for translators
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from config/arm/arm.c:
error ("%K%s %wd out of range %wd - %wd",
As a translator I have no idea what the first two placeholders are and why they
are written without a space between them. This should be documented like this:
/* TRANSLATORS: %K can be "...", %s can be "..." */
error ("%K%s %wd out of range %wd - %wd",
[Bug target/78807] Loop optimization trigger bus error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78807 --- Comment #4 from Mikael Pettersson --- On Solaris 10 / SPARC, this test case works fine when compiled by gcc-6.3.0, but SIGBUSes when compiled by gcc-5.4.0.
[Bug other/79872] New: document placeholder %K in gcc-internal-format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79872
Bug ID: 79872
Summary: document placeholder %K in gcc-internal-format
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
In config/aarch64/aarch64.c I found this code:
error ("%Klane %wd out of range %wd - %wd", exp, lane, low, high - 1);
It seems wrong to me that there is no space after the %K.
The gettext documentation doesn't mention the %K specifier at all.
(https://savannah.gnu.org/bugs/index.php?50461)
Please work together with the gettext people to create current and correct
documentation for the gcc-internal-format.
[Bug rtl-optimization/79873] New: function_reader::handle_insn_uids: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79873
Bug ID: 79873
Summary: function_reader::handle_insn_uids: use internal_error
instead of error
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from read-rtl-function.c:
error ("duplicate insn UID: %i", INSN_UID (insn));
As an i18n translator, I'm not willing to translate this into a human-readable
error message, since it looks like an internal compiler error. As such, there
is no benefit of having this error message in 100 different languages.
See PR/79856.
[Bug other/79874] New: symtab_node::verify_base: replace error with internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79874 Bug ID: 79874 Summary: symtab_node::verify_base: replace error with internal_error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- As detailed in PR/79596, as a translator I don't see any value in translating internal compiler error messages. The messages in symtab_node::verify_base all look to me like internal errors. Therefore they should call internal_error instead of error.
[Bug driver/79875] New: diagnostics: missing question mark after "did you mean"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79875 Bug ID: 79875 Summary: diagnostics: missing question mark after "did you mean" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from opts.c: error_at (loc, "unrecognized argument to -f%ssanitize%s= option: %q.*s;" " did you mean %qs", While fixing this, please grep the whole GCC source code whether there are similar places.
[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 --- Comment #3 from Richard Earnshaw --- Both pragma and attribute are keywords in the language. If the substituted value were placed in quotes, would that help?
[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868 --- Comment #4 from Roland Illig --- (In reply to Richard Earnshaw from comment #3) > Both pragma and attribute are keywords in the language. If the substituted > value were placed in quotes, would that help? No, it wouldn't. It would only confuse users. Imagine the following diagnostic: >> target »attribute« »__format__« is invalid Although "attribute" and "pragma" are both keywords in the language, they are not used as such in this diagnostic. Rather, they form part of the normal sentence structure.
[Bug fortran/79876] New: [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876 Bug ID: 79876 Summary: [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: fxcoudert at gcc dot gnu.org, howarth.at.gcc at gmail dot com, iains at gcc dot gnu.org, jakub at gcc dot gnu.org, tkoenig at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin16 Target: x86_64-apple-darwin16 Build: x86_64-apple-darwin16 Since r245745 I see the following failure on x86_64-apple-darwin16 with -m32/64 FAIL: libgomp.fortran/strassen.f90 -O execution test This is a latent bug exposed by this revisions and which appeared between revisions r242391 (2016-11-14, OK) and r242872 (2016-11-25, Illegal instruction) when the test is compiled with -finline-matmul-limit<32 (I didn't test the 32 values, but only 0, 16, and 31). % /opt/gcc/gcc7p-242872p3/bin/gfortran -O2 strassen_red.f90 -finline-matmul-limit=31 -fopenmp % ./a.out Illegal instruction The test succeeds with OMP_NUM_THREADS set to 1 on a machine with four cores, eight threads. I don't see the failure on another machine with darwin10 and two cores/threads. The test strassen_red.f90 is program strassen_matmul use omp_lib integer, parameter :: N = 1024 double precision, save :: A(N,N), B(N,N), C(N,N), D(N,N) double precision :: start, end call random_seed call random_number (A) contains recursive subroutine strassen (A, B, C, N) integer, intent(in) :: N double precision, intent(in) :: A(N,N), B(N,N) double precision, intent(out) :: C(N,N) double precision :: T(N/2,N/2,7) integer :: K, L if (iand (N,1) .ne. 0 .or. N < 64) then C = matmul (A, B) return end if K = N / 2 L = N / 2 + 1 !$omp task shared (A, B, T) call strassen (A(:K,:K) + A(L:,L:), B(:K,:K) + B(L:,L:), T(:,:,1), K) !$omp end task !$omp task shared (A, B, T) call strassen (A(L:,:K) + A(L:,L:), B(:K,:K), T(:,:,2), K) !$omp end task !$omp task shared (A, B, T) call strassen (A(:K,:K), B(:K,L:) - B(L:,L:), T(:,:,3), K) !$omp end task !$omp task shared (A, B, T) call strassen (A(L:,L:), B(L:,:K) - B(:K,:K), T(:,:,4), K) !$omp end task !$omp task shared (A, B, T) call strassen (A(:K,:K) + A(:K,L:), B(L:,L:), T(:,:,5), K) !$omp end task !$omp task shared (A, B, T) call strassen (A(L:,:K) - A(:K,:K), B(:K,:K) + B(:K,L:), T(:,:,6), K) !$omp end task !$omp task shared (A, B, T) call strassen (A(:K,L:) - A(L:,L:), B(L:,:K) + B(L:,L:), T(:,:,7), K) !$omp end task !$omp taskwait C(:K,:K) = T(:,:,1) + T(:,:,4) - T(:,:,5) + T(:,:,7) C(L:,:K) = T(:,:,2) + T(:,:,4) C(:K,L:) = T(:,:,3) + T(:,:,5) C(L:,L:) = T(:,:,1) - T(:,:,2) + T(:,:,3) + T(:,:,6) end subroutine strassen end
[Bug libfortran/79612] missing space in diagnostic: Incorrect rank of return array in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79612 --- Comment #4 from Dominique d'Humieres --- > I cannot think of this happening with normal code. An > internal error might be better, but internal_error does not > take printf-style arguments. This code has been introduced at revision r149792 (Jul 19 2009). AFAIU the above comment, the error can only trigger if the user code is miscompiled. Is this correct? If yes, should this error be suppressed or at least the message changed to something such as "Bad code: incorrect rank of return array in %s intrinsic is %ld, should be 1. Please report"? Note a duplicated 'must' in the comment /* Bounds checking for the return values of the iforeach functions (such as maxloc and minloc). The extent of ret_array must must match the rank of array. */
[Bug fortran/68800] Fortran FE produces many memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 Bug 68800 depends on bug 79335, which changed state. Bug 79335 Summary: [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79335 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/79229] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79229 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from vehre at gcc dot gnu.org --- No regressions reported, closing.
[Bug fortran/79335] [7 Regression] Conditional jump or move depends on uninitialised in value get_scalar_to_descriptor_type(tree_node*, symbol_attribute) (trans-expr.c:53)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79335 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #11 from vehre at gcc dot gnu.org --- Well, no regressions reported after two weeks, closing.
[Bug c++/70266] ICE on invalid code on x86_64-linux-gnu: unexpected expression ‘foo’ of kind overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70266 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Mar 5 17:13:16 2017 New Revision: 245901 URL: https://gcc.gnu.org/viewcvs?rev=245901&root=gcc&view=rev Log: /cp 2017-03-05 Paolo Carlini PR c++/70266 * except.c (build_must_not_throw_expr): Perform the implicit conversions on the condition. /testsuite 2017-03-05 Paolo Carlini PR c++/70266 * g++.dg/tm/pr70266.C: New. Added: trunk/gcc/testsuite/g++.dg/tm/pr70266.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog
[Bug c++/70266] ICE on invalid code on x86_64-linux-gnu: unexpected expression ‘foo’ of kind overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70266 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #4 from Paolo Carlini --- Fixed in trunk.
[Bug c++/79877] New: -Wstrict-overflow false positive or misunderstanding?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79877
Bug ID: 79877
Summary: -Wstrict-overflow false positive or misunderstanding?
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s-beyer at gmx dot net
Target Milestone: ---
Hi,
I have the following code:
$ cat foo.cc
#include
static int strict_overflow_warning(int bitmask) {
int max = -1;
for (int i = 31; i > max; i--) {
if (bitmask & (1 << i)) {
max = i;
}
}
return max;
}
static int no_strict_overflow_warning(int bitmask) {
int max = -1;
for (int i = 31; i >= 0; i--) {
if (bitmask & (1 << i)) {
max = i;
break;
}
}
return max;
}
int main(int argc, char *argv[]) {
std::cout << strict_overflow_warning(argc) << std::endl;
std::cout << no_strict_overflow_warning(argc) << std::endl;
std::cout << strict_overflow_warning(0) << std::endl;
std::cout << no_strict_overflow_warning(0) << std::endl;
std::cout << strict_overflow_warning(-argc) << std::endl;
std::cout << no_strict_overflow_warning(-argc) << std::endl;
return 0;
}
I get the following output (depending on g++ version and -O flag):
$ g++-7 -O3 -Wstrict-overflow foo.cc && ./a.out 2 3 4 5 6 7 8
foo.cc: In function ‘int main(int, char**)’:
foo.cc:5:21: warning: assuming signed overflow does not occur when assuming
that (X - c) <= X is always true [-Wstrict-overflow]
for (int i = 31; i > max; i--) {
~~^
foo.cc:5:21: warning: assuming signed overflow does not occur when assuming
that (X - c) <= X is always true [-Wstrict-overflow]
for (int i = 31; i > max; i--) {
~~^
3
3
-1
-1
31
31
$ g++-7 -O2 -Wstrict-overflow foo.cc && ./a.out 2 3 4 5 6 7 8
3
3
-1
-1
31
31
$ g++-6 -O3 -Wstrict-overflow foo.cc && ./a.out 2 3 4 5 6 7 8
3
3
-1
-1
31
31
The two functions should be semantically equivalent (as the output
indicates). Why does the version using i > max (instead of using i >= 0
and the break) show me the strict-overflow warning?
Thank you,
Stephan
[Bug tree-optimization/79878] New: verify_gimple_assign_single: replace error with internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79878 Bug ID: 79878 Summary: verify_gimple_assign_single: replace error with internal_error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In tree-cfg.c, the function verify_gimple_assign_single reports several errors that cannot be triggered by ordinary GCC users. Therefore, these errors should call internal_error() instead of error(). See bug 79856 and bug 79857.
[Bug c++/79877] -Wstrict-overflow false positive or misunderstanding?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79877 --- Comment #1 from Marc Glisse --- The message seems pretty clear to me. gcc has an optimization that turns i-1>i into false, and is telling you that it applied it (not that there is anything wrong with your code). In the other code, it doesn't apply that optimization, so the warning doesn't appear. Maybe we should just drop the warning if it causes more confusion than it helps find bugs...
[Bug target/79871] i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79871 --- Comment #1 from joseph at codesourcery dot com --- %K means to extract a location from a statement, including inlining context. See tree-pretty-print.c:percent_K_format. As such, the absence of a space is correct.
[Bug other/79874] symtab_node::verify_base: replace error with internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79874 --- Comment #1 from joseph at codesourcery dot com --- Without reference to whether it is the case for this particular error, there are some cases where the code structure is: * Make consistency checks, possibly reporting diagnostics from them. * If any such checks failed, call internal_error (which is fatal) at that point. In such cases, making the errors directly into internal errors would make the compiler exit earlier than intended; you'd need some concept of "internal error, but don't exit yet" to preserve semantics.
[Bug c++/79877] -Wstrict-overflow false positive or misunderstanding?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79877 --- Comment #2 from Stephan Beyer --- Hi, (In reply to Marc Glisse from comment #1) > The message seems pretty clear to me. gcc has an optimization that turns > i-1>i into false, and is telling you that it applied it (not that there is > anything wrong with your code). But it only applies it when doing some loop unrolling, doesn't it? Otherwise it would result in wrong behavior and the output wouldn't be the same. If this is the case, then the warning shouldn't be printed. > In the other code, it doesn't apply that > optimization, so the warning doesn't appear. Yes (that's why I wrote i >= 0 to see if it appears again). > Maybe we should just drop the warning if it causes more confusion than it > helps find bugs... The warning is a real problem in the case that can often be seen: when you turn on -O3 -Wall -Werror ... many people think that -Wall is so sensibly chosen by the compiler vendors that they can safely turn them into errors. However, in this case, -Wstrict-overflow is, according to you, more an information than an indication "that there is anything wrong with your code". Hence -Werror leading to an error somehow seems to be wrong behavior. On the other hand, warnings are mostly only an information about things going on implicitly, but you can usually make them explicit easily (e.g., variable assignments inside ifs by adding parentheses, implicit fallthroughs in switch/case by adding the [[fallthrough]] attribute, maybe-uninitialized warnings by initializing variables on declaration, etc.). In my example, however, the solution is to change the code into code using a break (which is considered bad style by some people) or by adding an extra bool variable (to avoid the break). And in another example, the solution may be totally different. It seems there is no "general" rule to get rid of these warnings before you experience them. Cheers Stephan
[Bug c/79879] New: Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879
Bug ID: 79879
Summary: Integer overflow in functions from scanf() family in
MinGW, Cygwin, Borland/Embarcadero C environments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wyporek at poczta dot onet.pl
Target Milestone: ---
Created attachment 40884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40884&action=edit
Exploit
Good morning,
I find out a strange and bad beaviour of functions from scanf() family when
reading one-byte int variable in MinGW, Cygwin and Borland/Embarcadero C
environments (on Windows, on Linux this doesn't happen). This bug is corelated
with MSVCRT library which isn't written in C99 standard (it's written in C89 i
think).
So, the point is, when you're reading one byte using scanf() function, AND you
are using %hhu format specifier, you have Integer Overflow bug in your code,
because MinGW links to old MSVCRT (C89 version) even if you compile with
-std=c99 parameter.
This works, because scanf() in old MSVCRT library doesn't know "h" format
specifier. BUT! The problem is, that scanf try to interpret format specifier
anyway, omits unsupported "h" specifier and it's loading full integer ("u") to
memory (it should omit not supported part of format - whole "%hhu" format part,
not just only "h"). The C99 specification says on 361 page: "If a conversion
specification is invalid, the behavior is undefined." - but it is WRONG,
because the behaviour SHOULD BE DEFINED AS OMITING THE WHOLE UNSUPPORTED PART
OF FORMAT (not only single specifier, but whole part).
In exploit (in attachment), compiler doesn't even display warnings (event if
you compile program with -std=c99 and -Wextra parameters). I compile using that
command:
gcc main.c -o main.exe -std=c99 -Wextra
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- GCC assumes C99 library if you specify -std=c99.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #2 from Andrew Pinski --- Please report this to MinGW and Cygwin projects (separately). IIRC mingw has a corrected version of scanf now. Cygwin uses newlib and not MSVCRT.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #3 from Lukas Wyporek --- >> Cygwin uses newlib and not MSVCRT. So why this bug is present also on Cygwin GCC? Newlib is also buggy?
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #4 from Andrew Pinski --- (In reply to Lukas Wyporek from comment #3) > >> Cygwin uses newlib and not MSVCRT. > > So why this bug is present also on Cygwin GCC? > Newlib is also buggy? Report it to them and find out. I don't know.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #5 from Lukas Wyporek --- Thank you for your time.
[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Revisions r242462 and r242518 are within the range. The failure triggers also if the tests are compiled with -O0 or with -fno-frontend-optimize.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #6 from Lukas Wyporek --- MinGW support told me that they can do nothing because MSVCRT is closed source library. And they told me to do direct request to GNU GCC maintainers with ask to provide warnings in compiler when somebody is using "%hhu" and linking to MSVCRT library. Should I open new request here?
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #7 from Andrew Pinski --- Try with -Wall -Wextra instead of just -Wextra. IIRC -Wformat is only enabled for -Wall and not with -Wextra.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #8 from Lukas Wyporek --- With -Wall -Wextra instead of just -Wextra the behaviour is the same - integer overflows. Best regards,
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #9 from Lukas Wyporek --- No, my mistake. -Wall shows warnings only if format parameter is LITERAL. When format parameter is pointer to string (buffer) - there are no warnings. Best regards,
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #10 from Andrew Pinski --- (In reply to Lukas Wyporek from comment #9) > No, my mistake. -Wall shows warnings only if format parameter is LITERAL. > When format parameter is pointer to string (buffer) - there are no warnings. Try -Wformat-security . This is not enabled by default.
[Bug target/79871] i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79871 --- Comment #2 from Roland Illig --- Thanks for the explanation. This leaves open the %s. Looking further in the code, I can see that %s is either the string "constant" or the string "lane". In other diagnostics, these words are usually translated (e.g. Konstante and Spur in German). These strings are not translated in this diagnostic, which means the German GCC users will be presented with something like this: file.c:13: error: Konstante hat keine Adresse file.c:17: error: constant 13 außerhalb des gültigen Bereichs 0 - 9 It is weird to have the word "constant" translated in one case but not in the other. Therefore it must not be passed as a placeholder.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #11 from Lukas Wyporek --- When "%hhu" format is literal, and -Wall parameter is used there are correct warnings - for example: main.c:11:23: warning: unknown conversion type character 'h' in format [-Wformat =] sscanf(buffer, "%hhu", &userNumber); === But when format is a pointer to string buffer, there are no warnings, even if I compile with that parameters: gcc main.c -o main.exe -Wall -Wextra -Wformat-security Best regards,
[Bug inline-asm/79880] New: Gcc refuses to encode vpgatherdd instruction (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79880
Bug ID: 79880
Summary: Gcc refuses to encode vpgatherdd instruction (x86-64)
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: kobalicek.petr at gmail dot com
Target Milestone: ---
I'm unable to encode `vpgatherdd xmm, mem, xmm` instruction in inline asm:
void test() {
__asm(".intel_syntax\n"
"vpgatherdd xmm4, [r13 + xmm3], xmm4\n"
".att_syntax\n");
}
It seems that ICC refuses this construct as well while clang is fine with that.
I'm not sure if it's bug or this form of the instruction is incorrect. But
according to X86 Architecture Reference Manual it's encodable.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #12 from Andrew Pinski --- Please read the documentation about -Wformat.
[Bug inline-asm/79880] Gcc refuses to encode vpgatherdd instruction (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79880 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- Report this to binutils as GCC just passes the string directly to them without modifying it in this case.
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #13 from Lukas Wyporek --- OK, so we can compile with -Wformat=2 (which can be used instead of group "-Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k"): gcc main.c -o main.exe -Wall -Wextra -Wformat=2 and the compiler will warn about that format is not string literal: "warning: format not a string literal, argument types not checked" Thank you Andrew, Are you Polish maybe?
[Bug c/79879] Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879 --- Comment #14 from Andrew Pinski --- (In reply to Lukas Wyporek from comment #13) > Thank you Andrew, > Are you Polish maybe? Of polish decent American.
[Bug target/78105] ICE during LTO bootstrap on AARCH64 with gold linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 PeteVine changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #14 from PeteVine --- I've finally put two and two together and identified the cause, --fix-cortex-a53-835769, which was kicking in for -mcpu=cortex-a53. Looks like an LTO gold linker bug, period. FWIW, an LTO bootstrapped gcc is actually slower, taking 2 more minutes to complete a --disable-bootstrap build (3% slowdown).
[Bug c/79881] New: -Wc++-compat should warn about sizeof character literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79881
Bug ID: 79881
Summary: -Wc++-compat should warn about sizeof character
literals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: max at maxbruckner dot de
Target Milestone: ---
The c++-compat warning should warn about uses of sizeof when used with
character literals, because in C++ sizeof(' ') is the same as sizeof(char)
whereas it is sizeof(int) in C, therefore this is not part of the common subset
between C and C++ and should be warned about.
[Bug target/78105] ICE during LTO bootstrap on AARCH64 with gold linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 --- Comment #15 from PeteVine --- Sorry wrong number :) I meant --enable-fix-cortex-a53-843419
[Bug c++/79882] New: Lack of bounds checking on -ftemplate-depth argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79882 Bug ID: 79882 Summary: Lack of bounds checking on -ftemplate-depth argument Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pefoley2 at pefoley dot com Target Milestone: --- -ftemplate-depth appears to not check for overflow: gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/python --enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0-r3 p1.3, pie-0.6.5' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --with-isl --disable-isl-version-check --enable-libsanitizer Thread model: posix gcc version 5.4.0 (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) g++ -std=c++11 -ftemplate-depth=4294967296 a.cc a.cc: In function ‘int main()’: a.cc:12:26: fatal error: template instantiation depth exceeds maximum of 0 (use -ftemplate-depth= to increase the maximum) g++ -std=c++11 -ftemplate-depth=4294967297 a.cc a.cc: In instantiation of ‘struct meme<2147483648u, int>’: a.cc:12:26: required from here a.cc:3:20: fatal error: template instantiation depth exceeds maximum of 1 (use -ftemplate-depth= to increase the maximum)
[Bug target/79883] New: avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 Bug ID: 79883 Summary: avr i18n: untranslated "interrupt" or "signal" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from config/avr/avr.c: const char *isr = cfun->machine->is_interrupt ? "interrupt" : "signal"; warning_at (loc, OPT_Wmisspelled_isr, "%qs appears to be a misspelled " "%s handler, missing __vector prefix", name, isr); This code results in mixed-language diagnostics, e.g.: warning: »functionname« scheint ein falsch geschriebener signal-Handler zu sein The word "signal-Handler" should be "Signal-Handler", but the part "signal" is actually the untranslated string literal. This should be fixed as in bug 79868.
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 --- Comment #1 from Andrew Pinski --- I think this is correctly untranslated as interrupt and signal here are keywords.
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 --- Comment #2 from Roland Illig --- Quoting myself from bug 79868: Although "interrupt" and "signal" are both keywords in the language, they are not used as such in this diagnostic. Rather, they form part of the normal sentence structure. For example in French, one might translate: le traiteur d'interrupt le traiteur du signal So depending on the inserted word, the outside sentence changes. Therefore these keywords cannot be inserted using placeholders but must be part of the whole sentence. (I don't know whether my French is completely correct, but I think that would be a reasonable translation.)
[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #2 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #1) > Revisions r242462 and r242518 are within the range. > > The failure triggers also if the tests are compiled with -O0 or with > -fno-frontend-optimize. A few questions: - Still happening after r245839 (which fixed a potential race condition)? - What / where is the illegal instruction happening? Is it in matmul_*_avx, matmul_*_avx2, ...? - What CPU are you running? - If you print __cpu_model.__cpu_vendor and __cpu_model.__cpu_features[0] from a debugger, what is the output? - What is the stack size for each thread? Are you maybe running into a stack limitation?
[Bug c/79884] New: Math functions with variable argument fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79884
Bug ID: 79884
Summary: Math functions with variable argument fail
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tino.calancha at gmail dot com
Target Milestone: ---
Consider the following snippet code:
#include
#include
int main ()
{
double param = 1024.0;
double result = sqrt (param);
printf ("sqrt(%.1f) = %.1f\n", param, result );
return 0;
}
$> gcc -Wall -Wextra file.c
file.o: In function `main':
file.c:(.text+0x23): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status
*) If i use:
double result = sqrt (1024.0);
instead of
double result = sqrt (param);
then, the program compiles.
System type:
Linux 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux
$> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170205 (Debian 6.3.0-6)
preprocessed file.i:
# 1 "file.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "file.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 27 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 364 "/usr/include/features.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 1 3 4
# 415 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/wordsize.h" 1 3 4
# 416 "/usr/include/x86_64-linux-gnu/sys/cdefs.h" 2 3 4
# 365 "/usr/include/features.h" 2 3 4
# 388 "/usr/include/features.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 1 3 4
# 10 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/gnu/stubs-64.h" 1 3 4
# 11 "/usr/include/x86_64-linux-gnu/gnu/stubs.h" 2 3 4
# 389 "/usr/include/features.h" 2 3 4
# 28 "/usr/include/stdio.h" 2 3 4
# 1 "/usr/lib/gcc/x86_64-linux-gnu/6/include/stddef.h" 1 3 4
# 216 "/usr/lib/gcc/x86_64-linux-gnu/6/include/stddef.h" 3 4
# 216 "/usr/lib/gcc/x86_64-linux-gnu/6/include/stddef.h" 3 4
typedef long unsigned int size_t;
# 34 "/usr/include/stdio.h" 2 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/types.h" 1 3 4
# 27 "/usr/include/x86_64-linux-gnu/bits/types.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/wordsize.h" 1 3 4
# 28 "/usr/include/x86_64-linux-gnu/bits/types.h" 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;
typedef long int __quad_t;
typedef unsigned long int __u_quad_t;
# 121 "/usr/include/x86_64-linux-gnu/bits/types.h" 3 4
# 1 "/usr/include/x86_64-linux-gnu/bits/typesizes.h" 1 3 4
# 122 "/usr/include/x86_64-linux-gnu/bits/types.h" 2 3 4
typedef unsigned long int __dev_t;
typedef unsigned int __uid_t;
typedef unsigned int __gid_t;
typedef unsigned long int __ino_t;
typedef unsigned long int __ino64_t;
typedef unsigned int __mode_t;
typedef unsigned long int __nlink_t;
typedef long int __off_t;
typedef long int __off64_t;
typedef int __pid_t;
typedef struct { int __val[2]; } __fsid_t;
typedef long int __clock_t;
typedef unsigned long int __rlim_t;
typedef unsigned long int __rlim64_t;
typedef unsigned int __id_t;
typedef long int __time_t;
typedef unsigned int __useconds_t;
typedef long int __suseconds_t;
t
[Bug other/79885] New: fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 Bug ID: 79885 Summary: fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jeremyhu at macports dot org Target Milestone: --- If gcc-6.3.0 is configured with --with-build-sysroot=/Applications/Xcode.app/.../MacOSXXX.sdk, the build will fail unless /usr/include is present on the system as well. The build fails during fix-includes with the message: The directory that should contain system headers does not exist: /usr/include I suspect this is because SYSTEM_HEADER_DIR is set to /usr/include rather than $SDKROOT/usr/include. Perhaps I'm misunderstanding the intention of --with-build-sysroot, but essentially, I want to build gcc against a given macOS SDK, and the system does not contain system headers installed at /. I'm testing a workaround of defining SYSTEM_HEADER_DIR explicitly, but it would be best if this issue were resolved properly upstream.
[Bug c/79884] Math functions with variable argument fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79884 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is a FAQ. Link against libm: -lm.
[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 --- Comment #1 from Jeremy Huddleston Sequoia --- And note that I'm not using --with-sysroot because I don't want this to affect the compiler installed by 'make install', just what is used to build gcc itself.
[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 --- Comment #2 from Andrew Pinski --- (In reply to Jeremy Huddleston Sequoia from comment #1) > And note that I'm not using --with-sysroot because I don't want this to > affect the compiler installed by 'make install', just what is used to build > gcc itself. You could have used --prefix instead. I suspect darwin is different for native builds in that the sysroot is always /.
[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #11 from Jerry DeLisle --- Created attachment 40885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40885&action=edit A preliminary patch. Any and all testing greatly appreciated. I am regression testing this now. I wanted to get it out tonight so others can be looking at it sooner. Need to think of some test cases.
[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #12 from Jerry DeLisle ---
Here is a modified test case where I test the iotype and if its is NAMELIST, I
format the output to what would be expected. Since there is no user defined
namelist read, it just uses default reading of the namelist.
MODULE m
IMPLICIT NONE
TYPE :: t
CHARACTER :: c
CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
END TYPE
CONTAINS
SUBROUTINE write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg
if (iotype.eq."NAMELIST") then
WRITE (unit, '(a,a,a)') 'x%c="',dtv%c,'",'
else
write (unit,*) dtv%c
end if
END SUBROUTINE
END MODULE
PROGRAM p
USE m
IMPLICIT NONE
character(len=50) :: buffer
TYPE(t) :: x
NAMELIST /nml/ x
x = t('a')
WRITE (buffer, nml)
write(*,nml)
print *, buffer
x = t('x')
print *, x%c
READ (buffer, nml)
print *, x%c
END
The output with the preliminary patch is:
$ ./a.out
&NML
x%c="a",
/
&NML x%c="a", /
x
a
So it appears the basic namelist to buffer I/O is working correctly. The next
step will be to decide exactly how to format the namelist writes/reads.
[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 --- Comment #2 from Jerry DeLisle --- Preliminary patch given in PR78854
[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 --- Comment #3 from Jeremy Huddleston Sequoia --- I'm not sure what you mean by using --prefix "instead" ... I'm using --prefix to establish where I want the tools to be installed to. As an example, if I wanted to install gcc to /opt/gcc6/bin/gcc, I'd use --prefix=/opt/gcc6. However, the system headers (i.e., /usr/include/stdlib.h) are located in the macOS SDK (not at /usr/include), so it looks like I should be passing --with-build-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk to configure. Or am I misunderstanding the purpose of this configure option? Our build system (MacPorts) is already setting up '-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk' in CPPFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS and adding '-Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk to LDFLAGS' ... which is sufficient for most other projects, but GCC's a difficult beast to tame. FWIW, I worked around this by just editing SYSTEM_HEADER_DIR in gcc/Makefile.in before running configure. Another related issue is that CPP and CXXCPP need to be explicitly set in the environment because the test for discovering them does not use CPPFLAGS and thus fails, so /lib/cpp is used as fallback (which is not correct).
[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 --- Comment #4 from Andrew Pinski --- Try --with-build-sysroot= instead.
[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 --- Comment #5 from Jeremy Huddleston Sequoia --- I don't really understand what you mean by "Try --with-build-sysroot= instead." ... --with-build-sysroot= *is* being used.
[Bug other/79885] fix-includes does not honor the value passed to --with-build-sysroot=, looks for /usr/include instead of looking within the SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 --- Comment #6 from Jeremy Huddleston Sequoia --- Got farther with the Makefile.in edit and setting of CPP and CXXCPP, but failing now because --sysroot=... is not getting passed to xg++ during configure-stage2-gcc: from gcc/config.log: configure:6449: /opt/local/var/macports/build/_Users_jeremy_src_macports_macports-ports_lang_gcc6/libgcc/work/build/./pr ev-gcc/xg++ ... conftest.cpp >&5 conftest.cpp:22:19: fatal error: stdio.h: No such file or directory #include ^ compilation terminated.
[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-06 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Good, I'll prepare patch.
[Bug c++/79857] cgraph_node::verify_node should call internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79857 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-06 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Ok, I'll prepare patch for that.
