Re: -Wconversion versus libstdc++

Paolo Carlini wrote: [...] Let's wait a bit more for other opinions, say one day or two, then I will start the actual work. As far as I can see, other compilers do not warn in such cases, and adding casts (*) isn't the cleanest practice in the world, thus my caution... FYI: HP aCC warns for s

Re: -Wconversion versus libstdc++

Paolo Carlini wrote: Martin Sebor wrote: FYI: HP aCC warns for some but not all of these types of lossy initializations. For example, a double to int conversion emits a warning but ptrdiff_t to size_t or other signed to unsigned conversions do not, probably because they're so common. I

Re: SSA Iterators

On 1/30/20 2:59 AM, Jonathan Wakely wrote: On Thu, 30 Jan 2020, 05:44 Nicholas Krause wrote: Greetings, I was looking into starting to cleaning up the SSA trees for various reasons and iterators seem to be the easiest to do. I searched the list to see if someone mentioned it before and I ran a

GCC Bugzilla (and other) timeouts

Bugzilla has been slow lately, and today to the point of timing out (I see the same problem with Git). This seems to be a recurring theme around the time of a GCC release. Is anyone else experiencing this problem and if so, does anyone know what the cause it and an ETA for a solution? Is the up

Re: GCC Bugzilla (and other) timeouts

On 2/26/20 1:32 AM, Jonathan Wakely wrote: On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: Bugzilla has been slow lately, and today to the point of timing out (I see the same problem with Git). This seems to be a recurring theme around the time of a GCC release. Is anyone else experiencing

Re: ctype_members.cc Comparison Always True

On 08/03/2015 12:35 PM, Joel Sherrill wrote: Hi Just noticed this building the head for arm-rtems4.11. Should the first comparison be eliminated and, maybe, a comment added? ctype_members.cc:216:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if (__wc >=

Re: Ubsan build of GCC 6.0 fails with: cp/search.c:1011:41: error: 'otype' may be used uninitialized in this function

On 09/09/2015 12:36 PM, Toon Moene wrote: See: https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00699.html Full error message: /home/toon/compilers/trunk/gcc/cp/search.c: In function 'int accessible_p(tree, tree, bool)': /home/toon/compilers/trunk/gcc/cp/search.c:1011:41: error: 'otype' may b

Re: Optimization bug?

On 09/19/2015 03:32 PM, Sören Brinkmann wrote: Hi Andrew, On Sat, 2015-09-19 at 11:34AM -0700, pins...@gmail.com wrote: On Sep 19, 2015, at 11:00 AM, Sören Brinkmann wrote: Hi, I recently came across some bug in my program that I could narrow down to the snipped below (also attached with

Re: Optimization bug?

On 09/20/2015 12:38 AM, Richard Biener wrote: On September 20, 2015 1:40:12 AM GMT+02:00, Martin Sebor wrote: On 09/19/2015 03:32 PM, Sören Brinkmann wrote: Hi Andrew, On Sat, 2015-09-19 at 11:34AM -0700, pins...@gmail.com wrote: On Sep 19, 2015, at 11:00 AM, Sören Brinkmann wrote

Re: Understand GCC test process

On 10/07/2015 07:57 AM, Sabrina Souto wrote: I was seeing these files but I could not put the puzzle pieces together in my mind, and after you explained, all pieces make sense now. Thanks for the explanation, Jonathan. The testing process is clear now, but I still not understanding what can expla

Re: UTF-8 quotation marks in diagnostics

On 10/21/2015 03:23 PM, D. Hugh Redelmeier wrote: Several of us don't want UTF-8 quotation marks in diagnostics in our environment (Jove subshells). We'd like a way to turn them off. We don't think that they are a bad idea but they are bad in our environment.

Re: UTF-8 quotation marks in diagnostics

On 10/22/2015 10:53 AM, Joseph Myers wrote: On Wed, 21 Oct 2015, Martin Sebor wrote: That would go against the usual (i.e., POSIX) expected effect of the environment variable. Specifically for GCC (or the c99 utility), POSIX requires LC_CTYPE to determine the locale used to parse the input

Re: UTF-8 quotation marks in diagnostics

Again, LC_CTYPE does *not* affect source file interpretation. I understand what you're saying. What I am saying is that if this is how c99 behaves it's in conflict with POSIX because LC_CTYPE is exactly how source file interpretation is specified to be controlled: LC_CTYPE Determine the

Re: C++ order of evaluation of operands, arguments

On 11/23/2015 04:01 PM, Jason Merrill wrote: There's a proposal working through the C++ committee to define the order of evaluation of subexpressions that previously had unspecified ordering: http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf I agree with much of this, but was

Re: C++ order of evaluation of operands, arguments

On 11/24/2015 02:55 AM, Andrew Haley wrote: On 23/11/15 23:01, Jason Merrill wrote: There's a proposal working through the C++ committee to define the order of evaluation of subexpressions that previously had unspecified ordering: http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.

Re: C++ order of evaluation of operands, arguments

On 11/25/2015 11:49 AM, Andrew Haley wrote: On 11/25/2015 06:25 PM, Martin Sebor wrote: The motivating example in the paper suggests that many C++ programmers expect a left to right order of evaluation here due to the commonality of constructs like chains of calls. Sure, I often see

Re: building gcc with macro support for gdb?

On 12/02/2015 06:48 PM, Peter Bergner wrote: On Wed, 2015-12-02 at 20:05 -0500, Ryan Burn wrote: Is there any way to easily build a stage1 gcc with macro support for debugging? I tried setting CFLAGS, and CXXFLAGS to specify "-O0 -g3" via the command line before running configure, but that only

Re: building gcc with macro support for gdb?

On 12/04/2015 10:32 AM, Tom Tromey wrote: "Martin" == Martin Sebor writes: Martin> To get around these, I end up using info macro to print the Martin> macro definition and using whatever it expands to instead. I Martin> wonder if someone has found a more convenient worka

-Wplacement-new on by default

Jason, I just want to make sure we still want the -Wplacement-new option I added some time ago enabled by default. I think I had initially intended it to be on because the original implementation was more permissive and didn't diagnose cases where (for example) the buffer spanned multiple member

Re: gcc-4.9.1 generating different code between two successive builds

On 12/20/2015 11:39 PM, Cole wrote: Hi, I am busy trying to generate a package for gcc that is consistent between two successive builds, and I am now down to the final few files. I am stuck with the file: cilk-abi-cilk-for.o, which is obviously built with -O2, but between two successive builds,

Re: gcc-4.9.1 generating different code between two successive builds

what others have done, and potentially anything else I may have missed. No we didn't. Unfortunately, most of the work we did back then was in a proprietary GCC fork. Martin Thanks /Cole On 21 December 2015 at 21:08, Martin Sebor wrote: On 12/20/2015 11:39 PM, Cole wrote: Hi, I am

Re: Question on repeating -march flags

On 12/23/2015 05:02 AM, Yuri D'Elia wrote: I couldn't find anything on the matter, but what happens if -march is repeated more than once? I would assume the usual behavior that the last flag "wins". This is correct for all -march= arguments except for native. Some -march= option processing ta

Re: How to use _Generic with bit-fields

On 02/19/2016 11:25 AM, Wink Saville wrote: I'm using gcc 5.3.0: $ gcc --version gcc (GCC) 5.3.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

Re: How to use _Generic with bit-fields

On 02/21/2016 06:44 PM, Wink Saville wrote: I've tried you hack, but it doesn't work with "long bit fields". Also, I've run into another problem. Instead of using unsigned char for the bit field I changed it to a long unsigned int:33 and now I can't print it without a warning. That's unfortunat

Re: How to use _Generic with bit-fields

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc z.c struct S { unsigned i: 31; } s; int i = _Generic (s.i, unsigned: 1); z.c:2:19: error: ‘_Generic’ selector of type ‘unsigned int:31’ is not compatible with any association

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

On 03/28/2016 01:56 PM, Florian Weimer wrote: In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though he provides the "-Werror=return-type" option, the compiler doesn't flag the warning/error about a control reaching the end of a non-void function, due to the presence of the "-w" opt

Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

On 03/31/2016 10:30 AM, Segher Boessenkool wrote: On Mon, Mar 28, 2016 at 04:32:50PM -0600, Martin Sebor wrote: On 03/28/2016 01:56 PM, Florian Weimer wrote: In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though he provides the "-Werror=return-type" option, the compil

Re: GCC 6 symbol poisoning and c++ header usage is fragile

On 04/21/2016 07:20 AM, Jonathan Wakely wrote: On 21 April 2016 at 13:33, Szabolcs Nagy wrote: On 21/04/16 12:52, Jonathan Wakely wrote: On 21 April 2016 at 12:11, Szabolcs Nagy wrote: the root cause is c++: c++ headers include random libc headers with _GNU_SOURCE ftm so all sorts of unexpecte

Re: Bug maintenance

On 04/28/2016 01:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value?

relying on static_assert to test constexpr changes

Many GCC tests for constexpr rely on static_assert to verify things work correctly. While testing some changes of my own, I was surprised to find the static_asserts pass even though my changes did not (see below). It took me a while to realize that, and it took printing the computed constant val

Re: relying on static_assert to test constexpr changes

On 04/28/2016 03:54 PM, Andrew Pinski wrote: On Thu, Apr 28, 2016 at 2:49 PM, Martin Sebor wrote: Many GCC tests for constexpr rely on static_assert to verify things work correctly. While testing some changes of my own, I was surprised to find the static_asserts pass even though my changes

r235766 incomplete?

Hi Jan, I just noticed the compilation errors in the attached file with the latest trunk. It seems as though your recent patch below may be incomplete: commit 46e5dccc6f188bd0fd5af4e9778f547ab63c9cae Author: hubicka Date: Mon May 2 16:55:56 2016 + The following change causes compila

Ada testsuite failures due to missing gnatlib

In my builds lately I've been noticing many Ada tests failing that didn't use to fail before. I don't think I'm doing anything different than before. The failures all seem to be due to the error below. Has something changed about how to run the Ada test suite or how to configure GCC to enable i

Re: Ada testsuite failures due to missing gnatlib

On 05/03/2016 03:47 PM, Eric Botcazou wrote: In my builds lately I've been noticing many Ada tests failing that didn't use to fail before. I don't think I'm doing anything different than before. The failures all seem to be due to the error below. Has something changed about how to run the Ada

Re: Ada testsuite failures due to missing gnatlib

On 05/03/2016 04:44 PM, Eric Botcazou wrote: There is no /build/gcc-trunk/gcc/gcc but presumably you meant /build/gcc-trunk/gcc/ada (which does exist). But there is no rts directory anywhere under the build tree. Then the build failed at some point and this should be in the log. Actually, I

Re: _Bool and trap representations

On 06/08/2016 12:36 AM, Alexander Cherepanov wrote: Hi! If a variable of type _Bool contains something different from 0 and 1 its use amounts to UB in gcc and clang. There is a couple of examples in [1] ([2] is also interesting). [1] https://github.com/TrustInSoft/tis-interpreter/issues/39 [2]

Re: _Bool and trap representations

There has been quite a bit of discussion among the committee on this subject lately (the last part is the subject of DR #451, though it's discussed in the context of uninitialized objects with indeterminate values). Are there notes from these discussions or something? Notes from discussions du

Re: _Bool and trap representations

On 06/17/2016 02:19 PM, Alexander Cherepanov wrote: On 2016-06-15 17:15, Martin Sebor wrote: There has been quite a bit of discussion among the committee on this subject lately (the last part is the subject of DR #451, though it's discussed in the context of uninitialized objects

Re: "error: static assertion failed: [...]"

On 07/13/2016 07:26 AM, Thomas Schwinge wrote: Hi! I had recently noticed that given: #ifndef __cplusplus /* C */ _Static_assert(0, "foo"); #else /* C++ */ static_assert(0, "foo"); #endif ..., for C we diagnose: [...]:2:1: error: static assertion failed: "foo"

Re: "error: static assertion failed: [...]"

From a diagnostics point-of-view, neither version is quoted: c/c-parser.c: error_at (assert_loc, "static assertion failed: %E", string); cp/semantics.c: error ("static assertion failed: %s", To be "quoted", it would need to use either %q or %<%>. Note that %qs would produce `foo' not "foo". Ne

DejaGnu directive matching multiple messages on the same line

When multiple diagnostics for a given line in a test are expected, I have been using the vertical bar ('|') in regular expression arguments to DejaGnu directives like dg-error and dg-warning on the assumption that all are matched. This use appears to be sanctioned by the GCC TestCaseWriting Wiki

Re: DejaGnu directive matching multiple messages on the same line

On 07/20/2016 02:28 PM, Jakub Jelinek wrote: On Wed, Jul 20, 2016 at 02:19:15PM -0600, Martin Sebor wrote: Is there a way to express a requirement that a single line cause two or more diagnostic messages (in any order) each matching one of the regex strings? Sure, and it is used many times in

Re: Proposal: readable and writable attributes on variables

On 08/30/2016 06:22 AM, Jens Bauer wrote: Hi all. I know it's possible to declare a variable 'read-only' by using 'const'. When working with microcontrollers (small ICs, which often requires you to write your code at driver-level), you need to be able to declare a structure member 'read-only'

Re: Proposal: readable and writable attributes on variables

On 08/31/2016 04:56 AM, Jens Bauer wrote: Hi Martin (and everyone else on the gcc list). I appreciate your input and kind reply to my proposal. :) On Tue, 30 Aug 2016 20:44:35 -0600, Martin Sebor wrote: This sounds reasonable and useful to me but to be fully integrated into the language

Re: Lessons learned from compiler error/warnings tests

On 09/09/2016 06:28 AM, Florian Weimer wrote: For compile-time fortify checks (such as the wrappers for type-safe open/openat), we need to add tests in glibc which examine the compiler output for warnings and errors. I do not want to add Dejagnu as a dependency to the glibc test suite, but I won

tree-prof parallel make check failures

I'm seeing a number of failures in different tests in the tree-prof directory when I run make check in parallel none of which are reproducible with -j1. I don't see anything about in Bugzilla or in recent test results. Has anyone noticed this or am I missing something? This is on a 56-core x86_

Re: tree-prof parallel make check failures

On 09/21/2016 07:39 AM, Marek Polacek wrote: On Tue, Sep 20, 2016 at 05:29:03PM -0600, Martin Sebor wrote: I'm seeing a number of failures in different tests in the tree-prof directory when I run make check in parallel none of which are reproducible with -j1. I don't see anythin

Re: sprintf warning on overlapping output

On 09/25/2016 03:46 AM, Bernd Edlinger wrote: Hi Martin, in the past I have seen (and fixed) code like sprintf(buf, "%s %d", buf, x); that may possibly work by chance, but usually produces undefined results. Do you see a way to enhance the warning for cases where the output buffer overlaps an

style convention: /*foo_p=*/ to annotate bool arguments

In a recent review Jason and I discussed the style convention commonly followed in the C++ front end to annotate arguments in calls to functions taking bool parameters with a comment along the lines of foo (1, 2, /*bar_p=*/true); I pointed out to Jason that in another code review, Jeff asked t

Re: style convention: /*foo_p=*/ to annotate bool arguments

This would have been easier if C++ had allowed the same default value to be given in both the declaration and the definition: void foo(int x, int y, bool bar_p = false); void foo(int x, int y, bool bar_p = false) { } It seems strange that this is not allowed. The standard says "A default argum

Re: style convention: /*foo_p=*/ to annotate bool arguments

On 10/04/2016 04:41 AM, Jonathan Wakely wrote: On 4 October 2016 at 10:21, David Brown wrote: On 04/10/16 01:48, Martin Sebor wrote: In a recent review Jason and I discussed the style convention commonly followed in the C++ front end to annotate arguments in calls to functions taking bool

VR_RANGE with inverted bounds

While processing the (p += i) expression below to validate the bounds of the pointer in I call get_range_info for i (in tree-object-size.c). The function returns the following VR_RANGE: [2147483648, -2147483649] rather than the expected [0, 1]. Is such a range to be expected or is it a bug? In g

Re: VR_RANGE with inverted bounds

On 10/07/2016 11:15 AM, Richard Biener wrote: On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor wrote: While processing the (p += i) expression below to validate the bounds of the pointer in I call get_range_info for i (in tree-object-size.c). The function returns the following VR_RANGE

Re: style convention: /*foo_p=*/ to annotate bool arguments

use it there but nowhere else? Thanks Martin On 10/03/2016 05:48 PM, Martin Sebor wrote: In a recent review Jason and I discussed the style convention commonly followed in the C++ front end to annotate arguments in calls to functions taking bool parameters with a comment along the lines of

Re: bootstrap possibly broken on trunk ?

On 10/13/2016 11:42 AM, Prathamesh Kulkarni wrote: Hi, I am getting the following error when bootstrapping trunk (tried with r241108) on x86_64-unknown-linux-gnu during stage-1: ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12: error: ISO C++ forbids declaration of \u2

anti-ranges of signed variables

I noticed that variables of signed integer types that are constrained to a specific subrange of values of the type like so: [-TYPE_MAX + N, N] are reported by get_range_info as the anti-range [-TYPE_MAX, TYPE_MIN - 1] for all positive N of the type regardless of the variable's actual

Re: anti-ranges of signed variables

On 11/11/2016 10:53 AM, Richard Biener wrote: On November 11, 2016 6:34:37 PM GMT+01:00, Martin Sebor wrote: I noticed that variables of signed integer types that are constrained to a specific subrange of values of the type like so: [-TYPE_MAX + N, N] are reported by get_range_info as

Re: anti-ranges of signed variables

On 11/11/2016 12:12 PM, Andrew Pinski wrote: On Fri, Nov 11, 2016 at 10:51 AM, Martin Sebor wrote: On 11/11/2016 10:53 AM, Richard Biener wrote: On November 11, 2016 6:34:37 PM GMT+01:00, Martin Sebor wrote: I noticed that variables of signed integer types that are constrained to a

Re: anti-ranges of signed variables

On 11/11/2016 12:30 PM, Martin Sebor wrote: On 11/11/2016 12:12 PM, Andrew Pinski wrote: On Fri, Nov 11, 2016 at 10:51 AM, Martin Sebor wrote: On 11/11/2016 10:53 AM, Richard Biener wrote: On November 11, 2016 6:34:37 PM GMT+01:00, Martin Sebor wrote: I noticed that variables of signed

use of exceptions in GCC

GCC is built with -fno-exceptions. I assume that's mainly to avoid having to catch and handle exceptions in what was originally C code. I also assume that also means that there's a policy or convention in place against throwing exceptions in GCC or making use of constructs that might throw (such

Re: use of exceptions in GCC

On 11/16/2016 07:36 PM, Segher Boessenkool wrote: On Wed, Nov 16, 2016 at 01:48:41PM -0700, Martin Sebor wrote: I'm also curious if there really is a policy/convention for dealing with exceptions in GCC, what it actually is/says. https://gcc.gnu.org/codingconventions.html#Exceptions T

Re: -Wformat-length and floats

On 11/29/2016 08:38 AM, Gerald Pfeifer wrote: This took me a bit to get to the bottom of, but I know believe that we need to work both on the documentation and implementation of -Wformat-length, in particular when it comes to floats. #include typedef struct M { float a, b, c; } M;

Re: -Wformat-length and floats

I'll see what I can do about documentation; any input on the above related to that will be helpful. This might be a good time to mention that I've thinking about writing up more detailed documentation than what may be suitable for the GCC manual and posting it either on the Wiki or someplace whe

Re: -Wformat-length and floats

On 11/29/2016 09:32 AM, Martin Sebor wrote: On 11/29/2016 08:38 AM, Gerald Pfeifer wrote: This took me a bit to get to the bottom of, but I know believe that we need to work both on the documentation and implementation of -Wformat-length, in particular when it comes to floats. #include

strange test failures

I'm seeing failures in a few C tests that I'm not sure what to make out of. The tests fail due to undefined symbols while linking even though they're not meant to link. Among these are a number (but not all) of the gcc.dg/divmod-[1-6]{-simode}.c tests. FAIL: gcc.dg/divmod-1.c (test for excess

Re: strange test failures

On 12/08/2016 05:32 PM, Jeff Law wrote: On 12/08/2016 04:47 PM, Martin Sebor wrote: I'm seeing failures in a few C tests that I'm not sure what to make out of. The tests fail due to undefined symbols while linking even though they're not meant to link. Among these are a numb

Re: strange test failures

On 12/10/2016 06:52 AM, Prathamesh Kulkarni wrote: On 9 December 2016 at 05:17, Martin Sebor wrote: I'm seeing failures in a few C tests that I'm not sure what to make out of. The tests fail due to undefined symbols while linking even though they're not meant to link. Am

Re: strange test failures

On 12/10/2016 11:03 AM, Martin Sebor wrote: On 12/10/2016 06:52 AM, Prathamesh Kulkarni wrote: On 9 December 2016 at 05:17, Martin Sebor wrote: I'm seeing failures in a few C tests that I'm not sure what to make out of. The tests fail due to undefined symbols while linking e

Re: not using push by gcc

On 02/02/2015 01:15 AM, Mr.reCoder wrote: Dear gcc developer, I have a code like this: #include void foo(int x) { int y; x++; y = 4; } int main(void) { foo(2); return 0; } and compiled with "gcc -o outexec srcfile.c" command. when disassemble the file we see that sending argume

Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference

On 02/20/2015 10:01 AM, Jeff Law wrote: On 02/20/15 05:10, Jakub Jelinek wrote: On Fri, Feb 20, 2015 at 12:06:28PM +0100, Florian Weimer wrote: On 02/19/2015 09:56 PM, Sandra Loosemore wrote: H, Passing the additional option in user code would be one thing, but what about library code? E

Re: Undefined behavior due to 6.5.16.1p3

On 03/09/2015 01:26 PM, Robbert Krebbers wrote: I was wondering whether GCC uses 6.5.16.1p3 of the C11 standard as a license to perform certain optimizations. If so, could anyone provide me an example program. In particular, I am interested about the "then the overlap shall be exact" part of 6.5

Re: Undefined behavior due to 6.5.16.1p3

On 03/11/2015 07:27 AM, Robbert Krebbers wrote: Dear Joseph, On 03/10/2015 11:01 PM, Joseph Myers wrote: and did "u.b.b2 = f (u.a);" instead of "u.b.b2 = u.a;", that would not be undefined (see 6.8.6.4 and GCC PR 43784). Thanks for the references, those are useful! But what about "long long"

Re: Undefined behavior due to 6.5.16.1p3

On 03/12/2015 03:10 AM, Vincent Lefevre wrote: On 2015-03-12 00:19:55 +0100, Robbert Krebbers wrote: On 03/11/2015 05:31 PM, Vincent Lefevre wrote: I disagree that it is an extension. The standard does not say that "one union member can be active at any time". The interpretation under which th

Re: Bug with compound literal initializer?

On 03/24/2015 03:26 PM, Alexey Neyman wrote: Hi, I am seeing a strange behavior when a compound initializer is used in a structure initialization. A test case: [[[ struct s { int y; unsigned long *x; }; struct s foo = { .y = 25, .x = (unsigned long [SZ]){}, }; ]]] If SZ is

Re: Bug with compound literal initializer?

Regarding undefined behavior: this object has static storage, so I think 6.7.9-10 from C11 should apply: Strictly speaking, once the behavior of a program is undefined, even well-defined constructs can have unexpected effects. But I do agree that dropping initialization for members with a valid

Re: is it time to mass change from .c to .cc in gcc/ ?

Started with the latter. By the way, what is the policy concerning getting write access to the wiki? You are expected to ask one of the existing editors who's willing to vouch for you to add you to the EditorGroup: http://gcc.gnu.org/wiki/EditorGroup Martin

Re: gcc -S vs clang -S

On 05/12/2015 07:40 PM, Andrew Pinski wrote: On Tue, May 12, 2015 at 6:36 PM, Fei Ding wrote: I think Thiago and Eric just want to know which code-gen is better and why... You need to understand for a complex process (CISC ISAs) like x86, there is no one right answer sometimes. You need to

Re: optimization question

On 05/18/2015 02:01 PM, mark maule wrote: I have a loop which hangs when compiled with -O2, but runs fine when compiled with -O1. Not sure what information is required to get an answer, so starting with the full src code. I have not attempted to reduce to a simpler test case yet. Typically a

Re: WPP capabilities in gcc

On 04/26/2015 11:47 AM, Shoham Peller wrote: You are completely right Jonathan. My Apologies. WPP is a tool I use in my work field on an every-day basis, so I thought it was known. Here is the Wikipedia page on WPP: http://en.wikipedia.org/wiki/Windows_software_trace_preprocessor In short, WPP

Re: optimization question

I'm not very familiar with the optimizations that are done in O2 vs O1, or even what happens in these optimizations. So, I'm wondering if this is a bug, or a subtle valid optimization that I don't understand. Any help would be appreciated. Another approach to debugging a suspected optimization

Re: warning: conversion from ‘int’ to ‘char’ may change value

On 09/17/2018 06:00 AM, Umesh Kalappa wrote: Hi All, When we try to compile the below case from trunk gcc we get the below warning (-Wconversion) i.e void start(void) { char n = 1; char n1 = 0x01; n &= ~n1; } $xgcc -S warn.c -nostdinc -Wconversion warning: conversion from ‘int’ to ‘char’

Re: warning: conversion from ‘int’ to ‘char’ may change value

On 09/20/2018 08:08 AM, Vincent Lefevre wrote: On 2018-09-17 10:03:48 -0600, Martin Sebor wrote: On 09/17/2018 06:00 AM, Umesh Kalappa wrote: Hi All, When we try to compile the below case from trunk gcc we get the below warning (-Wconversion) i.e void start(void) { char n = 1; char n1

Re: warning: conversion from ‘int’ to ‘char’ may change value

On 09/20/2018 01:29 PM, Jason Merrill wrote: On Thu, Sep 20, 2018 at 1:38 PM, Martin Sebor wrote: On 09/20/2018 08:08 AM, Vincent Lefevre wrote: On 2018-09-17 10:03:48 -0600, Martin Sebor wrote: On 09/17/2018 06:00 AM, Umesh Kalappa wrote: Hi All, When we try to compile the below case

references to individual options in GCC manual

Is there a way to include a reference to a specific option from within a .info file rather than to the section/node the option is defined in? It's cumbersome to use @xref and similar commands, and it's less not as helpful to point the reader to an entire section when referring to a specific item/

Re: references to individual options in GCC manual

On 10/25/2018 01:31 AM, Andreas Schwab wrote: On Okt 24 2018, Martin Sebor wrote: Is there a way to include a reference to a specific option from within a .info file rather than to the section/node the option is defined in? You can add an @anchor. Thanks. After adding the @anchor I can

Re: "aligned" attribute with too-large argument

On 10/29/2018 07:45 AM, Paul Koning wrote: I noticed an inconsistency in the handling of the aligned attribute. When applied to variables, I get an error message if the alignment is too large for the platform. But when applied to functions, there is no error check. The same applies to label

Re: "aligned" attribute with too-large argument

On 10/29/2018 09:19 AM, Paul Koning wrote: On Oct 29, 2018, at 10:54 AM, Martin Sebor wrote: On 10/29/2018 07:45 AM, Paul Koning wrote: I noticed an inconsistency in the handling of the aligned attribute. When applied to variables, I get an error message if the alignment is too large for

Re: Builtin mismatch warning

On 10/31/2018 12:15 PM, Paul Koning wrote: I noticed a curious inconsistency. Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this: void *alloca(); void* memcpy (); Those don't generate warnings in a just built V9.0 gcc for x86. And the testcase clearly doesn't expect warni

Re: Builtin mismatch warning

On 10/31/2018 03:10 PM, Paul Koning wrote: On Oct 31, 2018, at 4:21 PM, Martin Sebor wrote: On 10/31/2018 12:15 PM, Paul Koning wrote: I noticed a curious inconsistency. Some testcases (like gcc.dg/Wrestrict-4.c) have declarations like this: void *alloca(); void* memcpy (); Those don&#

Re: Not quoted option names in errors and warnings

On 11/15/2018 03:12 AM, Martin Liška wrote: Hi. I've done a quick grep of gcc/po/gcc.pot and I see quite a lot of missing quotations of option names (~400). Is it something we should fix? How important is that? That's quite a few... I've been fixing these as I notice them, usually as part of

Re: Not quoted option names in errors and warnings

On 11/20/2018 03:10 AM, Martin Liška wrote: On 11/15/18 5:54 PM, Martin Sebor wrote: On 11/15/2018 03:12 AM, Martin Liška wrote: Hi. I've done a quick grep of gcc/po/gcc.pot and I see quite a lot of missing quotations of option names (~400). Is it something we should fix? How importa

Re: Not quoted option names in errors and warnings

On 11/20/2018 12:54 PM, Martin Liška wrote: On 11/20/18 4:24 PM, Martin Sebor wrote: On 11/20/2018 03:10 AM, Martin Liška wrote: On 11/15/18 5:54 PM, Martin Sebor wrote: On 11/15/2018 03:12 AM, Martin Liška wrote: Hi. I've done a quick grep of gcc/po/gcc.pot and I see quite a lot of mi

question about attribute aligned for functions

GCC currently accepts the declaration of f0 below but ignores the attribute. On aarch64 (and I presume on other targets with a default function alignment greater than 1), GCC rejects f1 with an error, even though it accepts -falign-functions=1 without as much as a warning. Clang, on the other ha

Re: GCC Common-Function-Attributes/const

On 11/26/18 1:30 PM, cmdLP #CODE wrote: Dear GCC-developer team, The specification of the const-attribute is a bit ambiguous, it does not fully specify which global variables are allowed to be read from. Obviously constant global compile-time initialized variables can be accessed without problem

Re: GCC Common-Function-Attributes/const

[CC gcc list and Sandra] Thanks for the suggestions. I agree that the documentation should make it possible to answer at least the basic questions on your list. We'll see about incorporating them. In general, attributes that affect optimization are implemented at a level where higher-level dis

Re: question about attribute aligned for functions

On 11/26/18 3:37 PM, Jeff Law wrote: On 11/23/18 12:31 PM, Martin Sebor wrote: GCC currently accepts the declaration of f0 below but ignores the attribute.  On aarch64 (and I presume on other targets with a default function alignment greater than 1), GCC rejects f1 with an error, even though it

Re: question about attribute aligned for functions

On 11/27/18 11:57 AM, Martin Sebor wrote: On 11/26/18 3:37 PM, Jeff Law wrote: On 11/23/18 12:31 PM, Martin Sebor wrote: GCC currently accepts the declaration of f0 below but ignores the attribute.  On aarch64 (and I presume on other targets with a default function alignment greater than 1

Re: question about attribute aligned for functions

On 11/28/18 6:04 AM, Florian Weimer wrote: * Martin Sebor: At the same time, the following passes on x86_64: __attribute__ ((aligned (1))) void f1 (void) { } _Static_assert (__alignof__ (f1) == 1); // wrong alignof result __attribute__ ((aligned)) void f0 (void

write w/o approval policy (Re: [PATCH] clarify comments for implicit_p flag for built-ins)

On 11/28/18 6:35 AM, Richard Biener wrote: On Tue, Nov 27, 2018 at 3:52 AM Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01759.html If there are no objections or suggestions for tweaks I'll commit this updated comment this week. Please do not commit such chan

Re: question about attribute aligned for functions

On 11/28/18 9:07 PM, Jeff Law wrote: On 11/27/18 11:57 AM, Martin Sebor wrote: On 11/26/18 3:37 PM, Jeff Law wrote: On 11/23/18 12:31 PM, Martin Sebor wrote: GCC currently accepts the declaration of f0 below but ignores the attribute.  On aarch64 (and I presume on other targets with a default

  1   2   3   4   >